Gå til innhold

Anbefalte innlegg

Om man hadde gått for dot1q løsning må man huske på at CDP, stp,vtp og andre kontroll protokoller ikke går over dot1qtunnelen og man må lage egen tunnel for de med layer 2 protocol tunneling: l2protocol-tunnel. Den må konfigueres på hver edge switch.

 

Vekker til live en gammel tråd her :)

Et spørsmål: Når man configurerer l2protocol-tunnel, må det settes på samme porten som dot1q-tunnelen starter (og slutter)? Altså i ISP'en sine switcher?

 

Lurer på om dette er akkurat den kommandoen jeg har lett etter. Vi har nemlig opplevd en del rare problemer med vlan (trunk) over en dot1q-tunnel levert av ISP'en vår, men har liksom ikke klart å sette fingeren på hvorfor.

Hvis svaret på spørsmålet over er JA, så skal jeg ringe ISP ASAP og få dem til å sette på disse kommandoene.

 

Og digre virtuelle klemmer deles ut for å gi meg hint om denne kommandoen :!:

Lenke til kommentar
Videoannonse
Annonse

ja de må settes på samme porten der man har dot1q tunneling. Med kun dot1q tunneling vil ikke CDP, STP etc gå over default. Med dot1q tunneling bør også ISP slå av sin egen cdp på porten for å gjøre det mest mulig transparent. Skal man finne på å gjøre noe slik på sitt eget nettverk bør man huske å sette MTU på 1504 igjennom lag 2 i hele transmit pathen.

Endret av VictorOsborn
Lenke til kommentar
hva er egentlig problemet?

 

I "korte" trekk er det at en lokasjon i nettverket nå har fått to veier å gå, der vi kjører spanning-tree på et vlan, og så en ip-adresse på det vlan'et. Det står en L3-switch på hver "ende", og med en del L2-switcher i mellom, som er satt opp med trunk.

Så i teorien skulle man tro at hvis man kuttet ene linken så skulle den andre ta over, både på L2 og L3. Men når jeg kutter den linken som står og virker i dag, så slutter alt å virke på lokasjonen. Ingen ping, telnet osv.

Jeg ser i switchene vha. sh spanning-tree vlan 209 at veien til VLAN Root endres, men det kommer altså ikke opp.

Det merkelige er at linken kommer opp av og til, etter at jeg har prøvd å pinge meg innover i switchene.

Det virker som trafikken "går seg" vill før den kommer fram til gatewayen sin.

 

Jeg trodde kanskje at dette hadde med den q-in-q-tunnellen å gjøre, men det ser ikke sånn ut. Det er jo faktisk den veien som står og virker i dag.

 

Etter å ha prøvd en del forskjellige ting, står jeg igjen med følgende "unnskyldinger":

 

- For mange hopp

- Noe av utstyret på veien takler ikke dette (Vi bruker Witelcom-radioer på noen strekk)

- En eller annen inkompabilitet mellom C3550/C3560/C2960/C2950-switcher. Alle disse 4 typer switcher blir brukt på veien.

 

Sitter faktisk og prøver å lage en tegning over dette nå, kan legge den ut hvis noen skulle finne det interessant :)

Lenke til kommentar

ja lag en liten tegning, høres ut som det er noe som kan løses ganske greit.

 

ta gjerne en show run på configene du har.

 

Når du gjøre lag 2 trafic enginering så bruker du riktig metode. Kjøre sh span vlan 204 bortover og sjekker hvilke porter som er åpne. For å forandre vei hvis feks en port er i block state forandre du med plassering av rot, port priority for å forandre directy connected switcher downstream, bruke cost for å forandre upstream og downstream.

 

så sjekker man feilover på lag 2.

 

Etterpå kan man sjekke lag 3 feilover.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...