5
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.
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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 205891
Url: https://administrator.de/contentid/205891
Ausgedruckt am: 05.11.2024 um 23:11 Uhr
5 Kommentare
Neuester Kommentar
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:
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:
Wenn du das beachtest sollte das fehlerlos zum Fliegen kommen...!
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:
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
Wenn du das beachtest sollte das fehlerlos zum Fliegen kommen...!
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)
Trunk SW2 (keine Verbindung zum Access Switch da Vlan100 native)
Trunk EV-SW1 (keine Verbindung zum Access Switch da Vlan100 native)
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 trunkTrunk 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 trunkTrunk 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
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 !
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 !
Servus,
ich hatte auf einem Switch folgendes globale Config-Zeile übersehen:
diese hab ich entfernt und auf allen Trunk Ports gecheckt ob das native Vlan eingetragen ist, jetzt funktioniert es.
Danke noch mal
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
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.
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.
