1x1speed
Goto Top

Native Vlan über Trunk nicht erreichbar

Hallo,

ich habe an ein paar Switchen ein merkwürdiges Verhalten. Vorerst einmal ein par Worte zum Netzwerk.
Das Core Netz besteht aus 4 Switchen SW1-SW2-SW3-SW4 welche über Trunk Ports in einem Ring miteinander verbunden sind. SW1 und SW2 sind Cisco 3750 und machen das interne Routing der VLans per HRSP. SW1 und SW2 haben die Rolle der VTP Server.

Einen Teil der Etagenverteiler Switche EV-SW1 (Cisco2960) sind derzeit an SW3 angeschlossen. Nun ist die endgültige Verkabelung abgeschlossen und Patchfelder aufgelegt, so dass ich die Etagenverteiler EV-SW1,EV-SW2 und EV-SW3 im Ring an SW1 und SW2 patchen möchte.

Nun hab ich auf SW1 und SW 2 die Trunk Ports konfiguriert analog der alten Trunk Config auf SW3, das Native Vlan ist bei mir Vlan100 und hab EV-SW1 - auf SW1 gepatcht. Merkwürdigerweise ist das Vlan100 und damit auch das Management Interface von EV-SW1 nicht mehr erreichbar. Die Clients welche an dem Switch EV-SW1 hängen funktionieren und haben alle ihre jeweiligen VLans.

Sobald ich den Switch EV-SW1 wieder an den alten Port auf SW3 stecke ist Vlan100 auf dem EV-SW1 wieder erreichbar.

Die Trunks sind identsich konfigiuriert und ich bekomme auch keinerlei Fehlermeldungen im Log sobald ich wieder auf SW1 umstecke nur der ARP-Eintrag vom Interface Vlan100 des EV-SW1 verschwindet auf den Core Systemen SW1 und SW2.

Vlan100 ist auch in der Vlan-Database auf EV-SW1 vorhanden.

Das gleiche Verhalten haben auch alle anderen 2960er die ich in den Ring mit übernehmen möchte.

Momentan bin ich da ein wenig ratlos.

Content-Key: 205891

Url: https://administrator.de/contentid/205891

Ausgedruckt am: 28.03.2024 um 09:03 Uhr

Mitglied: aqui
aqui 01.05.2013 aktualisiert um 12:38:30 Uhr
Goto Top
Generell einmal eine Anmerkungen zu einer Rindstruktur bei 2-3 Switches und mehr: Sowas ist im Ethernet Umfeld immer kontraproduktiv, da du in einem redundanten Netzwerk Szenario in die Gefahr läufst das Spanning Tree Failover Zeiten bis zu 6 bis 10 Minuten dauern können und so das Netzwerk lahmlegen.
Das gilt sowohl für Ciscos Defualt PVSTP+ und auch PVRSTP+.
Sternszenarien sind bei Ethernet Designs also wenn möglich immer zwingend vorzuziehen bei einer Redundanz.

Ein klassisches redundantes Ethernet Design sähe z.B. so aus:
e2b75ce5cbdc8294c56f44c74324ad0d-switchnetz
Wenn möglich sollte man sich daran orientieren und Ringstrukturen immer vermeiden.

Was dein Problem anbetrifft wäre ein Konfigauszug der Trunk Konfigs sehr hilfreich hier.
Es gibt 2 Punkte die du beachten musst:
  • Die Management IP Adresse muss unter interface vlan 100 auf allen Switches definiert sein !
  • Die Uplink Konfigs der Trunks sähe so aus: switchport mode trunk, switchport trunk allow vlan all und switchport trunk native vlan 100
Letzteres muss konsequent an allen Uplink Ports und zwar beidseitig konfiguriert sein !
Wenn du das beachtest sollte das fehlerlos zum Fliegen kommen...!
Mitglied: 1x1speed
1x1speed 19.05.2013 um 08:23:55 Uhr
Goto Top
Hi Aqui,

vielen Dank für Deine ausführliche Antwort. Ich habe nun die Patchung nicht als Ring, sondern nach dem klassisched Design geändert. Wenn die Access Switche an den beiden Cores hängen, dann kommt eine Verbindung auf dem Management Interfache Vlan100 nur zustande, wenn ich aus der Trunk Config das Vlan100 nicht auch als Native konfiguriere, wie es vorher der Fall war.

Hier noch mal die alten Trunk Configs bei denen Native Vlan auch das 100er ist

Trunk SW1 (keine Verbindung zum Access Switch da Vlan100 native)
interface Gi1/0/24
 description Trkunk EV-SW1 Gi1
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 100
 switchport trunk allowed vlan 1,10,15,20,25,30,100
 switchport mode trunk

Trunk SW2 (keine Verbindung zum Access Switch da Vlan100 native)
interface Gi1/0/24
 description Trkunk EV-SW1 Gi2
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 100
 switchport trunk allowed vlan 1,10,15,20,25,30,100
 switchport mode trunk


Trunk EV-SW1 (keine Verbindung zum Access Switch da Vlan100 native)
interface Gi0/1
 description Trkunk SW1 Gi1/0/24
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 100
 switchport trunk allowed vlan 1,10,15,20,25,30,100
 switchport mode trunk

interface Gi0/2
 description Trkunk SW2 Gi1/0/24
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 100
 switchport trunk allowed vlan 1,10,15,20,25,30,100
 switchport mode trunk
Mitglied: aqui
Lösung aqui 19.05.2013, aktualisiert am 10.02.2015 um 11:39:57 Uhr
Goto Top
Ein "native VLAN" bedeutet immer nur das alle Pakete die untagged an diesem Port anliegen in das VLAN geforwardet werden was "native" ist ! Bzw. aus dem VLAN 100 untagged an diesem Trunk geforwardet werden.
Man kann also so das Verhalten normalerweise VLAN1 Traffic so zu forwarden auf andere VLANs umlenken.
Das Kommando behandelt also einzig und allen die Tatsache WIE mit untagged Traffic an Trunk Ports umgegangen wird, nicht mehr und nicht weniger !
Wenn du also an so einen konfigurierten Trunk Port einen herstellerfremden Access Switch ankorkst, dann forwardet der in der Regel untagged Traffic immer vom VLAN 1 (Defualt) !
Bei vielen Billigswitches lässt sich das auch nicht ändern. Darauf musst du also achten das du hier keinen VLAN Mismatch hast !
Und nochwas lauert im Detail:
Da du einen Cisco einsetzt macht der im Default PVSTP+ also ein proprietäres "Per VLAN" Spanning Tree Verfahren, was nur eine ganz kleine Anzahl anderer Hersteller wie z.B. Brocade, Extreme auch supporten.
Der Großteil der Hersteller speziell die Billigheimer wie HP usw. aber nicht !
Koppelst du nun solche Switches mit einem solchen Trunkport an kommt es unweigerlich zu nicht vorhersehbaren STP Problemen die in einem Blocking des native VLANs enden können. Der Grund ist das die STP Verfahren nicht kompatibel sind !
Vergiss also das auch nicht. Transparent funktioniert das nur in einer reinen Cisco Umgebung so !!
Ist das mixed muss man etwas tricksen !
Mitglied: 1x1speed
1x1speed 10.02.2015 um 11:43:40 Uhr
Goto Top
Servus,

ich hatte auf einem Switch folgendes globale Config-Zeile übersehen:

vlan dot1q tag native 

diese hab ich entfernt und auf allen Trunk Ports gecheckt ob das native Vlan eingetragen ist, jetzt funktioniert es.

Danke noch mal
Mitglied: aqui
Lösung aqui 10.02.2015, aktualisiert am 12.02.2015 um 09:32:28 Uhr
Goto Top
Ja richtig, damit wird global das Native VLAN getagged was in der Regel bei 98% aller Switch Hersteller unüblich ist. Das Gros überträgt auf tagged Uplinks das native oder Default VLAN immer untagged.
Auch wenn du das Kommando oben in der globalen Konfig hast kann man oft auf dem Interface sowas wie :
interface ethernet 1/1
switchport mode trunk
switchport trunk allow vlan all
no switchport trunk tag native vlan

konfigurieren.
Damit lässt sich das dann das native VLAN Tagging bei einigen Herstellern auch portbasierend deaktivieren.