11
Problem bei VLAN Trunk mit LACP zwischen HP und Cisco
Hallo zusammen,
folgende situation:
- Ubuntu server 14.04 mit DHCP für verschiedene Ranges
- Cisco SG300 L3 Switch welcher das Routing zwischen den VLAN's übernimmt (1[default],10,20,30)
- An dem Cisco ist ein HP Procurve 1810 mit einem 4 Gbit Trunk (LACP angebunden). Von dem aus Sternförmig noch weitere Switche Hp 1810), ebenfalls mit Trunk's per LACP
Folgendes Problem, ich erhalte im VLAN 10 ip Adressen nur am Ciscound am ersten HP 1810 der direkt am Cisco hängt,---
auf allen weiteren Geräten kommen keine Anfragen an. dies gilt nur für das VLAN10 alle anderen VLANS gehen... ich habe ander der configuration nichts geändert... heute morgen um 5 gab es einen Stromausfall, der cisco hat aber eine gespeicherte config, daran liegts nicht.. es ist alles wie vorher nur dass die Endgeräte alle keine Verbindung zum gateway (was das vlan interface am cisco ist)
@@---Gibt es beim Cisco irgendein mechanismus der eine art von "hops" vorgibt. ---@
Die Kommunikation aus allen anderen VLAN's funktioinert nahtlios, nur das eine VLAN ist betroffen... ich habe keine Ahnung mehr.
Edit: die discover anfragen kommen auch und ein offer wird rauscgeschikt, aber es kommt nicht zum ack im vlan 10
Gruß und danke,
Markus
folgende situation:
- Ubuntu server 14.04 mit DHCP für verschiedene Ranges
- Cisco SG300 L3 Switch welcher das Routing zwischen den VLAN's übernimmt (1[default],10,20,30)
- An dem Cisco ist ein HP Procurve 1810 mit einem 4 Gbit Trunk (LACP angebunden). Von dem aus Sternförmig noch weitere Switche Hp 1810), ebenfalls mit Trunk's per LACP
Folgendes Problem, ich erhalte im VLAN 10 ip Adressen nur am Cisco
auf allen weiteren Geräten kommen keine Anfragen an. dies gilt nur für das VLAN10 alle anderen VLANS gehen... ich habe ander der configuration nichts geändert... heute morgen um 5 gab es einen Stromausfall, der cisco hat aber eine gespeicherte config, daran liegts nicht.. es ist alles wie vorher nur dass die Endgeräte alle keine Verbindung zum gateway (was das vlan interface am cisco ist)
@@---Gibt es beim Cisco irgendein mechanismus der eine art von "hops" vorgibt. ---@
Die Kommunikation aus allen anderen VLAN's funktioinert nahtlios, nur das eine VLAN ist betroffen... ich habe keine Ahnung mehr.
Edit: die discover anfragen kommen auch und ein offer wird rauscgeschikt, aber es kommt nicht zum ack im vlan 10
Gruß und danke,
Markus
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: 302391
Url: https://administrator.de/contentid/302391
Ausgedruckt am: 25.11.2024 um 07:11 Uhr
11 Kommentare
Neuester Kommentar
ergänzung: ich erhalte folgende Meldung wenn ich den lacp modus umschalte zwischen active und passive (quasi nur um zu debuggen was passiert)
...
Link-I-Up: Po1
Link-I-Up: Vlan 20
Link-I-Up: Vlan 30
...
da fehlt eindeutig das VLAN 10, in der runnning conf ist aber alle normal
interface Port-channel1
description sw-00--sw-08
switchport trunk allowed vlan add 10,20,30
switchport default-vlan tagged
...
Link-I-Up: Po1
Link-I-Up: Vlan 20
Link-I-Up: Vlan 30
...
da fehlt eindeutig das VLAN 10, in der runnning conf ist aber alle normal
interface Port-channel1
description sw-00--sw-08
switchport trunk allowed vlan add 10,20,30
switchport default-vlan tagged
Die Port Channel Konfig ist nicht richtig und vermutlich kommt es dann hier zu Spanning Tree Problematiken die dir den Port blocken.
Auf der Billigschiene macht Cisco kein PVSTP wie sonst in den Catalyst Produkten, sondern ebenfalls wie HP und andere Billigheimer auch das simple Global Spanning Tree. Ein einziger globaler STP Prozess pro Switch für alle VLANs.
Deine Port Channel konfig hat aber den gravierenden Fehler das sie das Default VLAN tagged !! Das ist falsch.
Das kann und macht der HP nicht. Dort ist das default VLAN 1 immer untagged auf tagged Uplinks !!
Ändere also entsprechend dahin deine Konfig, dann kommt das sofort zum Fliegen.
Das Switchport Kommando solltest du dann auch auf switchport trunk allowed vlan add 1,10,20,30 anpassen damit es 100% kompatibel zur HP Gurke ist.
Nochwas zum LACP:
Normal nimmt man immer beide Seiten auf ACTIVE, sprich also das beide Seiten negotiaten. In der Regel funktioniert das problemlos.
Es kann in seltenen Fällen aber mal dazu führen das sich beide Seiten dann nicht einigen können wer active und wer passive ist im LACP.
In einem solchen Fall macht es dann Sinn eine Seite fest auf ACTIVE zu setzen und die andere dann fest auf PASSIVE. Mit welcher Kombination es klappt muss man dann ausprobieren.
In der Regel bekommt man so auch widerspenstige LACP Kandidaten immer in den Griff.
Wichtig:
Der Cisco sollte unbedingt eine höhere RSTP Priority haben !!!
Setze diese also im Setup auf RSTP und auf eine Priority z.B. 8192. Die HP Gurken kannst du im Default belassen (RSTP Mode).
Beachte auch die diese Schrotteile nur in der aktuellsten Firmware überhaupt RSTP supporten.
Damit ist immer sichergestellt das der Cisco der STP Root Switch Switch ist. Das ist zwingend erforderlich, da er das Routing macht zw. den VLANs.
Diese Dinge musst du entsprechend einrichten, damit das sauber funktioniert !
Auf der Billigschiene macht Cisco kein PVSTP wie sonst in den Catalyst Produkten, sondern ebenfalls wie HP und andere Billigheimer auch das simple Global Spanning Tree. Ein einziger globaler STP Prozess pro Switch für alle VLANs.
Deine Port Channel konfig hat aber den gravierenden Fehler das sie das Default VLAN tagged !! Das ist falsch.
Das kann und macht der HP nicht. Dort ist das default VLAN 1 immer untagged auf tagged Uplinks !!
Ändere also entsprechend dahin deine Konfig, dann kommt das sofort zum Fliegen.
Das Switchport Kommando solltest du dann auch auf switchport trunk allowed vlan add 1,10,20,30 anpassen damit es 100% kompatibel zur HP Gurke ist.
Nochwas zum LACP:
Normal nimmt man immer beide Seiten auf ACTIVE, sprich also das beide Seiten negotiaten. In der Regel funktioniert das problemlos.
Es kann in seltenen Fällen aber mal dazu führen das sich beide Seiten dann nicht einigen können wer active und wer passive ist im LACP.
In einem solchen Fall macht es dann Sinn eine Seite fest auf ACTIVE zu setzen und die andere dann fest auf PASSIVE. Mit welcher Kombination es klappt muss man dann ausprobieren.
In der Regel bekommt man so auch widerspenstige LACP Kandidaten immer in den Griff.
Wichtig:
Der Cisco sollte unbedingt eine höhere RSTP Priority haben !!!
Setze diese also im Setup auf RSTP und auf eine Priority z.B. 8192. Die HP Gurken kannst du im Default belassen (RSTP Mode).
Beachte auch die diese Schrotteile nur in der aktuellsten Firmware überhaupt RSTP supporten.
Damit ist immer sichergestellt das der Cisco der STP Root Switch Switch ist. Das ist zwingend erforderlich, da er das Routing macht zw. den VLANs.
Diese Dinge musst du entsprechend einrichten, damit das sauber funktioniert !
Auf der Billigschiene macht Cisco kein PVSTP wie sonst in den Catalyst Produkten, sondern ebenfalls wie HP und andere Billigheimer auch das simple Global Spanning Tree. Ein einziger globaler STP Prozess pro Switch für alle VLANs.
Es ist in dem Netzwerk kein Spanning Tree eingerichtet, reicht es nicht wenn ich es einfach auf den Switchen deaktiviere? Oder braucht der Cisco das
zwingend?
Deine Port Channel konfig hat aber den gravierenden Fehler das sie das Default VLAN tagged !! Das ist falsch.
Und genau da ist der Haken, ich kann mich nicht erinnern diesen Wert gesetzt zu haben. Ich vermute das hängt mit der default Config vom Cisco zusammen. Es gibt im Menü einen Punkt: " Standard-VLAN-ID nach Neustart: 1" Kann das sein?
Das adden funktioniert nicht, da es sich um das Default VLAN handelt welches vom Cisco vorgegeben ist.
sw-00(config-if)#switchport trunk allowed vlan add 1,10,20,30
VLAN 1 : VLAN was not created by user.
Ich erhalte in dem VLAN1 ja meine IP's ohne Probleme, es ist das VLAN 10 was mit Probleme bereitet, welches im Port Channel nicht aktiv geschaltet wird.
VLAN1 ist default bzw. management vlan auf allen Switchen. Und auf allen Trun Ports bei HP sind alle VLAN's tagged.
Die Konstellation hat ohne Probleme seit zwei Monaten funktioniert, ein reboot der Switche durch den Stromausfall und schon geht nichts mehr...
Es ist in dem Netzwerk kein Spanning Tree eingerichtet, reicht es nicht wenn ich es einfach auf den Switchen deaktiviere?
Das stimmt wenigstens für die Cisco Seite de facto NICHT. Dort ist RSTP im Default immer aktiv ! Es sei denn du hast das willentlich im Setup deaktiviert.Wäre ein Risiko bei 802.3ad Link Aggregation, denn sollte es mal zu einem Loop kommen hast du keinerlei Mechanismus der das verhindert. Mit Link Aggregation nutzt man eigentlich immer auch STP
Natürlich kannst du das deaktivieren aber dann muss es auf jdem Switch deaktiviert sein nicht nur auf einigen, denn das führt zu unberechenbarem Verhalten.
Andersrum genau so. Aktiviert muss es auch auf ALLEN Switches sein.
Ob STP generell rennt kannst du übrigens blitzschnell mit dem Wireshark sehen. Irgendwo anschliessen und checken ob BPDU Frames gesendet werden.
ich kann mich nicht erinnern diesen Wert gesetzt zu haben.
Das musst du auch nicht. Fakt ist aber das er falsch gesetzt ist !Mit der Cisco Konfig hat das nichts zu tun. Bei JEDEM Hersteller ist das Default VLAN bzw. native VLAN 1 in der Default Konfig.
Und auf allen Trun Ports bei HP sind alle VLAN's tagged.
Diese Aussage ist schlicht falsch !!Sorry aber das Default VLAN beim HP ist definitiv NICHT getagged auf einem tagged Uplink. Hier irrst du gewaltig.
Wenn es nur das VLAN 10 betrifft und beide Seiten des Uplinks sind vorschriftsmässig getagged, dann kann es eigentlich nur STP sein was dir da per Blocking dazwischenfunkt.
Hier rennen SG-200 und SG-300 seit Jahren völlig unauffällig mit allerlei ProCurve Gurken.
Es sei denn du hast das willentlich im Setup deaktiviert.
Ja, habe ich, aus dem beschriebenen Grund das in dem Netzwerk kein Spanning Tree konfiguriert ist (bis jetzt)
Die Switche sind gut "unter" verschluss und übersichtlich verkabelt, weswegen ich mir da aktuell keine Sorgen mache, später vielleicht mal. Aber im Moment haben andere Dinge priorität.
jdem Switch deaktiviert sein nicht nur auf einigen
Ist es.Das musst du auch nicht. Fakt ist aber das er falsch gesetzt ist !
Wenn ich es aber dort rausnehme kann ich es trotzdem nicht per switchport trunk allowed vlan add 1,10,20,30 hinzufügen.Sorry aber das Default VLAN beim HP ist definitiv NICHT getagged auf einem tagged Uplink.
Wie soll dann die IP Vergabe im VLAN1 denn über die Switche hinweg stattfinden wenn es nicht getaggt auf den Trunks ist?
Hier ist es nämlich getagged
Deine Port Channel konfig hat aber den gravierenden Fehler das sie das Default VLAN tagged !! Das ist falsch. Das kann und macht der HP nicht. Dort ist das default VLAN 1 immer untagged auf tagged Uplinks !!
Wenn ich also das VLAN1 auf den HP Switches wieder auf untaggen setze bei den trunks, dann kann ich den Eintrag in der Port Channel so belassen?
interface Port-channel1
description sw-00--sw-08
switchport trunk allowed vlan add 10,20,30
switchport default-vlan tagged
Also ist "HP untagged" dann kompatibel zu "Cisco default vlan tagged" auf den Trunks? Weil anders bekomme ich die Daten ja nicht durchs Netz.
Hier ist es nämlich getagged
Die Angabe ist widersprüchlich.... Einerseits steht ein U beim physischen Port und T beim Trunk.Was gilt nun. Generell kann man das Default VLAN bei den HPs nicht taggen in so fern verwundert das.
Nimm am besten einen Wireshark, schliesse den an einen der Tagged Uplinks an und sehe dir die Frames an ob die getagged oder nicht getagged sind.
Das klärt das Thema ganz sicher ohne raten zu müssen !
wieder auf untaggen setze bei den trunks, dann kann ich den Eintrag in der Port Channel so belassen?
Nein natürlich nicht, denn dann ist dein native VLAN ja untagged !switchport default-vlan tagged stimmt dann nicht und müsste auf "untagged" gesetzt werden.
Also ist "HP untagged" dann kompatibel zu "Cisco default vlan tagged" auf den Trunks?
Nein, natürlich nicht !!!Sorry wenn das missverstandlich war. Untagged und Tagged müssen auf beiden Enden immer gleich sein, sonst kommen die natürlich niemals zueinander !
. Einerseits steht ein U beim physischen Port und T beim Trunk. Was gilt nun. Generell kann man das Default VLAN bei den HPs nicht taggen in so fern verwundert das.
Die zu den Trunk gehörigen physischen Ports sind die ausgegrauten, die kann ich nicht beeinflusse nachdem ich den Trunk erstellt habe. Ich muss dann für jedes VLAN auf dem TRK1-3 halt (T)agged oder (U)ntagged setzen.
Die physischen Ports sind einfach nur nicht in die VLAN's verteilt wo sie hingehören weil ich sie provisorisch in das default gezogen hab wiel VLAN10 ja nicht geht. Deswegen alle gleich.
Wie gesagt, nimm dir den Wireshark zur Hand und sieh dir den Traffic an am Trunk. Da kannst du sofort sehen ob VLAN 10 richtig getagged wird und welcher Traffic untagged der des Default VLANs ist.
Irgendwas ist da de facto in der Konfig mau. Cisco und HP spielen wenigstens im Billigsegment fehlerlos miteinander.
(Obwohl sich der Cisco sich sicher ekelt eine üble HP Billiggurke an einem seiner Ports zu haben
)
Aktuellste Firmware hast du auf beide Switches geflasht ??
Irgendwas ist da de facto in der Konfig mau. Cisco und HP spielen wenigstens im Billigsegment fehlerlos miteinander.
(Obwohl sich der Cisco sich sicher ekelt eine üble HP Billiggurke an einem seiner Ports zu haben
)Aktuellste Firmware hast du auf beide Switches geflasht ??
Also ich habs in den Griff bekommen, muss aber ehrlich sagen ich weiß nicht zu 100% woran es lag. Es gibt beim Cisco neben der allgemeinen "Spanning Tree" Funktion (welche aus war) noch individuell eine Einstellungsmöglichkeit pro LAG, dort habe ich es deaktiviert und ich vermute daran lags. An den Trunks habe ich nichts geändert, ich muss aber ehrlich sagen ich hab den Fehler nicht nochmal reproduziert weil ich keine Lust mehr hatte :D
muss aber ehrlich sagen ich weiß nicht zu 100% woran es lag.
Schade eigentlich, das wär mal spannend gewesen.noch individuell eine Einstellungsmöglichkeit pro LAG,
Welches Menü ist das genau ?Aber gut wenns nun alles rennt wie es soll...
Schade eigentlich, das wär mal spannend gewesen
Ich wollte das nochmal nachstellen, bzw. es versuchen. Nur hatte ich keine Zeit mehr zu experimentieren weil das Netz musste wieder laufen.
