Kaskadierung zwischen zwei HP Procurve 2810-24g Switchen über VLAN
Hallo Leute ich habe ein Problem bei dem ich nicht so ganz weiter kommen.
Ausgangs Situation:
Wir haben eine neue Anbindung zu einem Externen Kunden bekommen. Die Anbindung erfolgt über zwei Router (Redundant) über die DATEN und VOICE Laufen sollen.
Voice und Daten sind über VLAN's getrennt.
Ich habe die Roter jetzt jeweils auf einen HP Procurve 2810-24g Switchen gesteckt (Jeweils Port 23)
Auf der Switch sind die VLAN's (111 und 112) Konfiguriert und beide für Port 23 Tagged. Das DATEN VLAN 111 Greife ich auf Port 22 (Tagged 111) über die Firewall ab auf der auch das VLAN 111 Konfiguriert ist.
Jeweils eine Firewall auf Port 22 pro Switch.
Voice wird später über Port 21 weiter gegeben. Der Port 21 ist Tagged für VLAN ID 112.
Kaskadierung:
Auf Port 24 habe ich Momentan beide VLANS Tagged und habe beide Switche miteinander verbunden.
Problem:
Soweit Funktioniert die generelle Verbindung aber die Kaskadierung geht wohl nicht.
Ich kann nur Router_1 Pingen, wenn ich einen HA switch auf der Firewall mache kann ich nur Router_2 Pingen.
Ich habe jetzt schon verschiedene Einstellungen ausprobiert auf dem Switch ( Port 24 beide VLAN's Tagged, statt einem normalen Kabel ein Crossover Kabel, nur ein VLAN Tagged / Untagged)
Irgendwie bin ich mit meinem Latin am ende.
Ich hoffe ihr könnt mir weiter helfen.
Hier ist die Netzwerk Skizze
PS:Beide Untagged war blödsin
Ausgangs Situation:
Wir haben eine neue Anbindung zu einem Externen Kunden bekommen. Die Anbindung erfolgt über zwei Router (Redundant) über die DATEN und VOICE Laufen sollen.
Voice und Daten sind über VLAN's getrennt.
DATEN:
HSPR 192.168.1.62
Router_1 192.168.1.60
Router_2 192.168.1.61
VLAN ID 111
VOICE:
HSPR 192.168.1.46
Router_1 192.168.1.44
Router_2 192.168.1.45
VLAN ID 112
Ich habe die Roter jetzt jeweils auf einen HP Procurve 2810-24g Switchen gesteckt (Jeweils Port 23)
Auf der Switch sind die VLAN's (111 und 112) Konfiguriert und beide für Port 23 Tagged. Das DATEN VLAN 111 Greife ich auf Port 22 (Tagged 111) über die Firewall ab auf der auch das VLAN 111 Konfiguriert ist.
Firewall:
Zwei Firewalls im HA cold standby Modus
Voice wird später über Port 21 weiter gegeben. Der Port 21 ist Tagged für VLAN ID 112.
Kaskadierung:
Auf Port 24 habe ich Momentan beide VLANS Tagged und habe beide Switche miteinander verbunden.
Problem:
Soweit Funktioniert die generelle Verbindung aber die Kaskadierung geht wohl nicht.
Ich kann nur Router_1 Pingen, wenn ich einen HA switch auf der Firewall mache kann ich nur Router_2 Pingen.
Ich habe jetzt schon verschiedene Einstellungen ausprobiert auf dem Switch ( Port 24 beide VLAN's Tagged, statt einem normalen Kabel ein Crossover Kabel, nur ein VLAN Tagged / Untagged)
Irgendwie bin ich mit meinem Latin am ende.
Ich hoffe ihr könnt mir weiter helfen.
Hier ist die Netzwerk Skizze
PS:Beide Untagged war blödsin
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 235715
Url: https://administrator.de/forum/kaskadierung-zwischen-zwei-hp-procurve-2810-24g-switchen-ueber-vlan-235715.html
Ausgedruckt am: 22.12.2024 um 18:12 Uhr
84 Kommentare
Neuester Kommentar
Moin,
kannst du da ggfs mal ein Bild dazu malen? So genau blick ich, vorallem bei der Plazierung der FWs, nicht durch.
Was für Subnetze verwendest Du? So wie du das beschrieben hast, könnte man annehmen das die Ip Ranges der VLANs nicht disjunkt sind.
Normalerweise müssen beide Ports an beiden Switchen als Trunk konfiguriert sein und die VLANs jeweils tagged führen.
lg,
Slainte
kannst du da ggfs mal ein Bild dazu malen? So genau blick ich, vorallem bei der Plazierung der FWs, nicht durch.
Was für Subnetze verwendest Du? So wie du das beschrieben hast, könnte man annehmen das die Ip Ranges der VLANs nicht disjunkt sind.
Port 24 beide VLAN's Untagged,
Wie hast du das denn hinbekommen? Normalerweise müssen beide Ports an beiden Switchen als Trunk konfiguriert sein und die VLANs jeweils tagged führen.
lg,
Slainte
Geht mir genauso....ziemlich verwirrend und vermutlich technisch auch falsch...
Das mit Port 24 ist wirklich ein Wunder ! Wie man das auf HP Switches hinbekommt....Respekt !
Übrigens Grundlagen zu so einem Szenario kannst du hier nachlesen inkl. HP Konfig:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Macht vielleicht Sinn bevor wir hier ins Eingemachte gehen...?!
Ein ziemlicher Knackpunkt ist da noch:
Voice und Daten VLAN sind in einem gemeinsamen IP Netz aber in getrennten VLANs wie Kollege Slainte schon richtig bemerkt hat.
Das geht so niemals, da diese Netze nicht mehr zu routen sind und die redundanten Router damit überflüssig wären weil sinnlos.
Wie gesagt: total unverständlich ist das Design... Normalerweise macht man das mit einem einzigen tagged Link auf dem beide VLANs laufen und geht damit auf den Router oder das Routerpärchen was hier vermutlich mit VRRP in einem Redundanz Verbund rennt ??
Aber wie gesagt ein Bild sagt mehr als tausend Worte....
(Und bitte jetzt KEINE externen Bilderlinks hier ! Thread oben mit Klick auf "Bearbeiten" editieren, Bilder hochladen oben klicken und Bild hochladen. Den Image URL kann man hier in jeglichen Text reinpasten mit einem Rechtsklick !!)
Das mit Port 24 ist wirklich ein Wunder ! Wie man das auf HP Switches hinbekommt....Respekt !
Übrigens Grundlagen zu so einem Szenario kannst du hier nachlesen inkl. HP Konfig:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Macht vielleicht Sinn bevor wir hier ins Eingemachte gehen...?!
Ein ziemlicher Knackpunkt ist da noch:
Voice und Daten VLAN sind in einem gemeinsamen IP Netz aber in getrennten VLANs wie Kollege Slainte schon richtig bemerkt hat.
Das geht so niemals, da diese Netze nicht mehr zu routen sind und die redundanten Router damit überflüssig wären weil sinnlos.
Wie gesagt: total unverständlich ist das Design... Normalerweise macht man das mit einem einzigen tagged Link auf dem beide VLANs laufen und geht damit auf den Router oder das Routerpärchen was hier vermutlich mit VRRP in einem Redundanz Verbund rennt ??
Aber wie gesagt ein Bild sagt mehr als tausend Worte....
(Und bitte jetzt KEINE externen Bilderlinks hier ! Thread oben mit Klick auf "Bearbeiten" editieren, Bilder hochladen oben klicken und Bild hochladen. Den Image URL kann man hier in jeglichen Text reinpasten mit einem Rechtsklick !!)
OK, die Skizze bringt endlich Licht ins Dunkel !! Hätte man auch vorher machen können
Die Netze haben eine 28 Bit Maske, gehen also dann im VLAN 112 von .1.32 bis .1.46 und im VLAN 111 von .1.49 bis .1.62 im Host IP Adress Bereich.
Damit ist man dann vom Routing auf der sicheren Seite und alles korrekt so.
Der Rest stimmt soweit auch perfekt was die Ports der Switches anbetrifft:
Hier kann man jetzt einen wichtigen Zwischentest machen:
Einen fatalen Fehler sieht man dann aber:
Der Firewall Port 22 an beiden Switches ist tagged !!
Das darf niemals sein wenn auf der Firewall nicht auch ein Port konfiguriert ist der 802.1q VLAN Tags supportet ! (Siehe o.a. VLAN Routing Tutorial am Beispiel der pfSense Firewall tagged Ports !)
Kann deine Firewall KEIN Tagging dann ist die Firewall ein Endgerät ! Und dann muss logischerweise der Switchport Port 22 untagged sein der in die Firewall reingeht !
Das solltest du wasserdicht prüfen ob die Firewall tagged Frames da überhaupt verstehen kann !!
Endgeräte verstehen normal KEIN VLAN Tagging, können also .1q getaggte Pakete NICHT lesen ! Vergiss das nicht !
Der Rest sieht sonst OK aus wenn der tagged Voice Port auch wieder auf einen Switch geht der Tagging versteht ! Gleiches Thema hier....
Die Netze haben eine 28 Bit Maske, gehen also dann im VLAN 112 von .1.32 bis .1.46 und im VLAN 111 von .1.49 bis .1.62 im Host IP Adress Bereich.
Damit ist man dann vom Routing auf der sicheren Seite und alles korrekt so.
Der Rest stimmt soweit auch perfekt was die Ports der Switches anbetrifft:
- Routerports jeweils 23 ist tagged in den VLANs 111 und 112
- Verbindungsports der Switches untereinander ebenfalls tagged in den VLANs 111 und 112
Hier kann man jetzt einen wichtigen Zwischentest machen:
- Ping der Router IPs untereinander im VLAN 111 muss möglich sein !
- Ping der Router IPs untereinander im VLAN 112 muss möglich sein !
- Ein "show hsrp" sollte anzeigen das HSRP mit Master und Slave und den HSRP VIP IP Adressen aktiv ist und die Router sich per HSRP "sehen" !!
Einen fatalen Fehler sieht man dann aber:
Der Firewall Port 22 an beiden Switches ist tagged !!
Das darf niemals sein wenn auf der Firewall nicht auch ein Port konfiguriert ist der 802.1q VLAN Tags supportet ! (Siehe o.a. VLAN Routing Tutorial am Beispiel der pfSense Firewall tagged Ports !)
Kann deine Firewall KEIN Tagging dann ist die Firewall ein Endgerät ! Und dann muss logischerweise der Switchport Port 22 untagged sein der in die Firewall reingeht !
Das solltest du wasserdicht prüfen ob die Firewall tagged Frames da überhaupt verstehen kann !!
Endgeräte verstehen normal KEIN VLAN Tagging, können also .1q getaggte Pakete NICHT lesen ! Vergiss das nicht !
Der Rest sieht sonst OK aus wenn der tagged Voice Port auch wieder auf einen Switch geht der Tagging versteht ! Gleiches Thema hier....
Ist bei Billigheimer HP nicht supportet bzw. der hat das Feature nicht ! Deshalb musst du damit leben. Stört aber auch nicht.
Bei anderen geht das mit "no switchport native vlan x" ...nützt dir aber vermutlich nix als HP Knecht.
Das was du oben mit "Trunk einrichten" bezeichnest hat mit deinem eigentlichen Problem nicht das geringste zu tun !!
Ein "Trunk" bezeichent das Aggregieren, also Zusammnfassen von mehreren parallelen Links z.B. zur Bandbreiten- bzw. Durchsatzerhöhung zwischen Switches oder zw. Switch und Server. Generell bezeichent man das als Link Aggregation (LAG). Dazu werden die Standards 802.3ad und LACP benutzt.
Du hast hier aber gar keinen Trunk ! In so fern ist deine obige Konfig dazu auch völliger Unsinn !! Sorry...hört sich so ein bischen an als wenn du sinnfrei ohne Kenntniss der Materie blind was probierst.
Was du da machst mit trunk 24 Trk1 Trunk definiert einen statischen Trunk (noch nichtmal einen mit LACP !) mit dem logischen Namen "Trk1" in dem aber nur ein einziger Port ist ! Fragt man sich WO denn da der Trunk ist ??
Dir leuchtet vermutlich selber ein das das ziemlicher Blödsinn ist und mit deiner eigentlichen Aufgabenstellung rein gar nix zu tun hat.
Wenn,... dann macht ja ein Trunk nur Sinn mit mehreren Ports als z.B. den Ports 23 und 24 um dann z.B. 2 GiG Bandbreite zw. den Switches zu realisieren mit:
<config>#trunk 23,24 Trunk1 LACP
Analog muss man das natürlich synchron auch auf dem anderen Switch machen auf den beteiligten 2 Ports dort !
Was du da gemacht hast ist sinnfreier Unsinn ohne Nachdenken ! Tip: Lies besser mal das Switch Handbuch damit du weisst was du da machst...
Für dich reicht schlicht und einfach ein:
vlan 111
name "Daten"
tagged 24
exit
vlan 112
name "Voice"
tagged 24
exit
auf den Verbindungsport 24 der HP Gurken wenn du nur einen einzigen Verbindungsport hast ohne Aggregierung !
Bei anderen geht das mit "no switchport native vlan x" ...nützt dir aber vermutlich nix als HP Knecht.
Das was du oben mit "Trunk einrichten" bezeichnest hat mit deinem eigentlichen Problem nicht das geringste zu tun !!
Ein "Trunk" bezeichent das Aggregieren, also Zusammnfassen von mehreren parallelen Links z.B. zur Bandbreiten- bzw. Durchsatzerhöhung zwischen Switches oder zw. Switch und Server. Generell bezeichent man das als Link Aggregation (LAG). Dazu werden die Standards 802.3ad und LACP benutzt.
Du hast hier aber gar keinen Trunk ! In so fern ist deine obige Konfig dazu auch völliger Unsinn !! Sorry...hört sich so ein bischen an als wenn du sinnfrei ohne Kenntniss der Materie blind was probierst.
Was du da machst mit trunk 24 Trk1 Trunk definiert einen statischen Trunk (noch nichtmal einen mit LACP !) mit dem logischen Namen "Trk1" in dem aber nur ein einziger Port ist ! Fragt man sich WO denn da der Trunk ist ??
Dir leuchtet vermutlich selber ein das das ziemlicher Blödsinn ist und mit deiner eigentlichen Aufgabenstellung rein gar nix zu tun hat.
Wenn,... dann macht ja ein Trunk nur Sinn mit mehreren Ports als z.B. den Ports 23 und 24 um dann z.B. 2 GiG Bandbreite zw. den Switches zu realisieren mit:
<config>#trunk 23,24 Trunk1 LACP
Analog muss man das natürlich synchron auch auf dem anderen Switch machen auf den beteiligten 2 Ports dort !
Was du da gemacht hast ist sinnfreier Unsinn ohne Nachdenken ! Tip: Lies besser mal das Switch Handbuch damit du weisst was du da machst...
Für dich reicht schlicht und einfach ein:
vlan 111
name "Daten"
tagged 24
exit
vlan 112
name "Voice"
tagged 24
exit
auf den Verbindungsport 24 der HP Gurken wenn du nur einen einzigen Verbindungsport hast ohne Aggregierung !
OK, das mit Trunk und Etherchannel und LAG ist auch verwirrend und kann so zu Missverständnissen führen wie man hier sieht.
Du solltest das aber zwingend entfernen von Port 24, denn diese Konfig ist schlicht falsch und kann böse Side Effects haben. Gerade wenn man wie du diesen Trunk statisch definiert hat !!
Besser also wieder weg damit !
Poste hier bitte mal den Auszug dieser VLAN Konfig für Port 24 von beiden Switches, dann kann man das checken.
Das simple Taggen der beiden Ports reicht wirklich aus bei den HP Möhren und auch bei allen anderen Herstellern. Das ist simpler VLAN Standard.
Du solltest das aber zwingend entfernen von Port 24, denn diese Konfig ist schlicht falsch und kann böse Side Effects haben. Gerade wenn man wie du diesen Trunk statisch definiert hat !!
Besser also wieder weg damit !
So hatte ich es ja gemacht und es hat eben nicht Funktioniert, daher ja meine anfrage hier.
Das MUSS auch so klappen. Du hast ganz sicher einen Fehler in der Switchkonfig.Poste hier bitte mal den Auszug dieser VLAN Konfig für Port 24 von beiden Switches, dann kann man das checken.
Das simple Taggen der beiden Ports reicht wirklich aus bei den HP Möhren und auch bei allen anderen Herstellern. Das ist simpler VLAN Standard.
Blöde Frage.
Nicht das der Effekt an der Subnetzmaske liegt. Damit habe ich bei manchen Herstellern schon eigenartige Effekte erlebt. Da sind dann meist kreative Konfigurationen betroffen.
Mich wundert immer noch der enge Rahmen, der kaum Platz für Endgeräte läßt, aber total sicher/redundant ist. 14 IPs wovon 5 schon fest benutzt sind.
Da deine Firewalll im Netz/VLAN111 ist, benötigt sie keinen getaggten Zugang zum Switch.
Gruß
Netman
P.S.: die Bezeichnung Trunck kommt auch vor, wenn man eine Port bezeichnet, der das Voice-VLAN getaggt und das Datenvlan ungetaggt ausliefert. Also lieber genau schauen um was es bei der immer wieder missverständlichen Bezeichnung geht.
Nicht das der Effekt an der Subnetzmaske liegt. Damit habe ich bei manchen Herstellern schon eigenartige Effekte erlebt. Da sind dann meist kreative Konfigurationen betroffen.
Mich wundert immer noch der enge Rahmen, der kaum Platz für Endgeräte läßt, aber total sicher/redundant ist. 14 IPs wovon 5 schon fest benutzt sind.
Will da nichts zerschießen da auf dem Default VLAN Port 1-19 Clients und andere Switche drauf Hängen.
Wenn du nicht von Switch zu switch oder Gateway zu Gateway denkst, sondern von Endgerät zu Endgerät oder zum Service im Internet und dazu den kompletten TraceRT betrachtest. - Gibt es da Unterschiede?Da deine Firewalll im Netz/VLAN111 ist, benötigt sie keinen getaggten Zugang zum Switch.
Gruß
Netman
P.S.: die Bezeichnung Trunck kommt auch vor, wenn man eine Port bezeichnet, der das Voice-VLAN getaggt und das Datenvlan ungetaggt ausliefert. Also lieber genau schauen um was es bei der immer wieder missverständlichen Bezeichnung geht.
Nicht das der Effekt an der Subnetzmaske liegt.
Kann ja eigentlich nicht sein, denn der TO bewegt sich ja in einem reinen Layer 2 Umfeld. Die Switches haben also keine Ahnung von IP und Adressen sondern forwarden nur nach Mac Adresse. Obwohl bei HP weiss man nie aber sowas simples sollten auch die hinbekommen...?!Die 28 Bit Maske geht ja in Ordnung wenn da nur eine Router Firewall Verbindung mit realisiert wird. Wenn dort allerdings auch Voice Endgeräte drin sein sollen könnte es in der Tat recht knapp werden. Aber mit einer Zahnarztpraxis oder einem Rechtsanwaltsbüro mit 4 Mitarbeitern reicht das dicke....
Sinn macht es mal 2 Laptops zu nehmen egal welche IP nur im gleichen IP Netz müssen sie sein, das Konstrukt aufzubauen und den beiden Laptops untagged Ports in beiden VLANs zu geben und zu sehen das die sich pingen können.
Möglich wäre noch eine Spanning Tree Inkompatibilität. Bei den Routern hört sich das nach Cisco an und die sprechen PVSTP+ wenn dort STP aktiviert ist. Billigheimer HP kann keinerlei irgendwie geartetes PVSTP. Somit ist ein STP Szenario nicht kompatibel und kann zu bösen Side Effects führen. Wie gesagt...ist nur relevant falls STP überhaupt konfiguriert ist.
Zitat von @Shinak:
Also ich habe jetzt auf beiden Switchen Port 20 als Untagged für VLAN 111 gesetzt und jeweils einen Laptop dran gehängt und die können sich nicht pingen.
Scherz: Die sind doch im selben VLAN! Die können sich auch arpen. Aber da hast du deine Uplinks, die Links ziwschen den Switchen nicht im Griff. Diese Ports müssen getaggt sein und die VLANS 111 und 112 beinhalten. Das gleiche gilt für die Router-uplink-Ports. Wenn ich richtig gezählt habe, sind das mindestens drei Links.Also ich habe jetzt auf beiden Switchen Port 20 als Untagged für VLAN 111 gesetzt und jeweils einen Laptop dran gehängt und die können sich nicht pingen.
Es geht um die Nachbar-VLANs 111 und 112
Wird noch spannend.
Ob wir das bis Ostern hin kriegen.
#edit: Der Downloadlink ist echt doof: keine Name, nicht mal die PDF Extension.
Aber; Wie haben dir hier schon mindestens 10 mal erklärt, das das, was du in dem Manual siehst (Ein Verweis auf die Seite wäre fruchtbar) ABSOLUT nicht das ist, worüber du mit uns diskutierst.
Trunk kann sein:
- Etherchannel, Gigachannel, LAG/LACP -- die Nutzung von mehreren Ports für eine höhere Summenbandbreite.
- Konfiguration für VoIP, wo die Telefone getaggt und die PCs ungetaggt aus ihrem jeweiligen VLAN versorgt werden. -- Nutzung für Telefon und PC an einem Switchport.
- VLAN uplink, der alle VLANs getaggt beinhaltet. -- Nutzung zwischen zwei Switches oder zwischen Switches und Routern oder zwischen Switches und Firewalls.
Gruß Netman
Das sieht ja eigentlich korrekt aus. Auf dem int 24 kannst du das LACP komplett ausschalten ("no lacp"), ansonsten passt das imo.
Die beiden Switches "sehen" sich ja, oder ("show cdp neigh")?
Du könntest auch erstmal den Switches IPs in den 111er und 112er VLANs verpassen und checken ob die von den Routern/der Firewall/den Laptops aus gepingt werden können.
Aber wie gesagt: die konfig ist imo eigentl. korrekt und sollte so funktionieren.
Die beiden Switches "sehen" sich ja, oder ("show cdp neigh")?
Du könntest auch erstmal den Switches IPs in den 111er und 112er VLANs verpassen und checken ob die von den Routern/der Firewall/den Laptops aus gepingt werden können.
Aber wie gesagt: die konfig ist imo eigentl. korrekt und sollte so funktionieren.
sprachst du nicht die ganze zeit von 2 VLANs und nun hast du drei, wobei du dem default VLAN viel verbietest.
Wo kommt das her und wofür wird es benutzt?
Und die IPS sind nicht mit dem 111er und dem 112er verbunden. Wie erreichst du das Netz denn?
Wenn wir weiter fragen kommen noch ein paar hundert Geräte und Konfigurationen vor
Gruß
Netman
vlan 1
name "DEFAULT_VLAN"
forbid 21-24
untagged 1-19
name "DEFAULT_VLAN"
forbid 21-24
untagged 1-19
Wo kommt das her und wofür wird es benutzt?
Und die IPS sind nicht mit dem 111er und dem 112er verbunden. Wie erreichst du das Netz denn?
Wenn wir weiter fragen kommen noch ein paar hundert Geräte und Konfigurationen vor
Gruß
Netman
Zitat von @aqui:
Billigheimer HP kann keinerlei irgendwie geartetes PVSTP. Somit ist ein STP Szenario
nicht kompatibel und kann zu bösen Side Effects führen. Wie gesagt...ist nur relevant falls STP überhaupt
konfiguriert ist.
Billigheimer HP kann keinerlei irgendwie geartetes PVSTP. Somit ist ein STP Szenario
nicht kompatibel und kann zu bösen Side Effects führen. Wie gesagt...ist nur relevant falls STP überhaupt
konfiguriert ist.
Moin,
bei HP heisst das MSTP, funktioniert auch. ;o)
VG,
Thomas
Zitat von @Shinak:
Selbes Problem ich kann im Moment die .56 Pingen aber die .57 nicht. Wenn ich jetzt einen HA change an der FW machen würde
könnte ich die .57 Pingen und die .56 nicht. Ich Teste das ganze gleich nochmal mit einem Laptop den ich direkt auf einen der
Switche hängen, dann kann ich auch das VOICE VLAN testen.
Selbes Problem ich kann im Moment die .56 Pingen aber die .57 nicht. Wenn ich jetzt einen HA change an der FW machen würde
könnte ich die .57 Pingen und die .56 nicht. Ich Teste das ganze gleich nochmal mit einem Laptop den ich direkt auf einen der
Switche hängen, dann kann ich auch das VOICE VLAN testen.
Moin,
du sprichst immer von HA change, kann es sein das deine Firewall die Ports aktiv/passiv fährt? Dann wäre das Verhalten by design...
Vielleicht hab ich es ja überlesen, wer ist der Hersteller der Firewall?
VG,
Thomas
Interessant, wie du siehst gehen diverse Ports auf dem zweiten HP Switch ins Blocking, und das nicht mal wenige!
Sicher wäre es gut, wenn du nochmal den kompletten Netzaufbau mit allen beteiligten Switches darstellen könntest.
Auf dem zweiten Switch gehen die Ports 2-6, 13 und 24 ins Blocking, sind die denn wirklich alle miteinander auf diesen Ports verbunden?
Als aktiven Uplink zeigt dir der zweite Switch den Port 1, da solltest du die VLANs auch drauf taggen.
Aber ich denke, hier liegt definitiv ein Fehler in deiner Spanning-Tree respektive VLAN-Konfiguration vor.
Ich weiß nicht, wie @aqui das sieht, aber eine Skizze des kompletten Netzes inkl. der Verbindungen der Switches untereinander
würde helfen!
Sicher wäre es gut, wenn du nochmal den kompletten Netzaufbau mit allen beteiligten Switches darstellen könntest.
Auf dem zweiten Switch gehen die Ports 2-6, 13 und 24 ins Blocking, sind die denn wirklich alle miteinander auf diesen Ports verbunden?
Als aktiven Uplink zeigt dir der zweite Switch den Port 1, da solltest du die VLANs auch drauf taggen.
Aber ich denke, hier liegt definitiv ein Fehler in deiner Spanning-Tree respektive VLAN-Konfiguration vor.
Ich weiß nicht, wie @aqui das sieht, aber eine Skizze des kompletten Netzes inkl. der Verbindungen der Switches untereinander
würde helfen!
Moin,
lg,
Slainte
Ok nur warum wird das geblockt
Schau dir mal an was (M)STP macht. Es verhindert das du dir deine Switches "im Kreis" verkabelst und so einen Broadcaststorm produzierst. Wenn STP Ports blockt bedeutet das, das eine Schleife im Netzwerk existiert.bzw. wie kann ich es ändern.
Verkabelung überprüfen & Schleifen auflösen. Am besten beginnst du, in dem du dir auf jeden switch "sh cdp neigh" ansiehst, dann weist du zumindest wer mit wem direkt verbunden ist.lg,
Slainte
Warum hat der Switch von 2006 keine Console?
So steht es im Quick Manual:
Dokument: 2810-QIG-June2006-59913844.pdf
Es gibt auch ein komplettes Manual. Such einfach nach hp procurve 2810 manual
Gruß Netman
So steht es im Quick Manual:
Using the Console Setup Screen
The quickest and easiest way to minimally configure the switch for management and password protection in your network is to use a direct console connection to the switch, start a console session, and access the Switch Setup screen.
1. Connect a terminal device to the console port and display the switch console command (CLI) prompt (the default display). ProCurve#
2. At the prompt, enter the setup command to display the Switch Setup screen. The Setup screen with the default settings is shown below.
The quickest and easiest way to minimally configure the switch for management and password protection in your network is to use a direct console connection to the switch, start a console session, and access the Switch Setup screen.
1. Connect a terminal device to the console port and display the switch console command (CLI) prompt (the default display). ProCurve#
2. At the prompt, enter the setup command to display the Switch Setup screen. The Setup screen with the default settings is shown below.
6. Connect a Console to the Switch
The console can be accessed through these methods:
■ Out-of-band: The switch comes with a console cable for connecting a PC or VT-100 terminal directly to the Console port on the front of the switch. The console cable is a DB-9 to RJ45 connector.
■ In-Band: Access the console using Telnet from a PC or UNIX station on the network, and a VT-100 terminal emulator. This method requires that you first configure the switch with an IP address and subnet mask by using either out-of-band console access or through DHCP/Bootp.
The Switch can simultaneously support one out-of-band console session through the Console Port and one in-band Telnet console session.
The console can be accessed through these methods:
■ Out-of-band: The switch comes with a console cable for connecting a PC or VT-100 terminal directly to the Console port on the front of the switch. The console cable is a DB-9 to RJ45 connector.
■ In-Band: Access the console using Telnet from a PC or UNIX station on the network, and a VT-100 terminal emulator. This method requires that you first configure the switch with an IP address and subnet mask by using either out-of-band console access or through DHCP/Bootp.
The Switch can simultaneously support one out-of-band console session through the Console Port and one in-band Telnet console session.
Dokument: 2810-QIG-June2006-59913844.pdf
Es gibt auch ein komplettes Manual. Such einfach nach hp procurve 2810 manual
Gruß Netman
So, hier das Resultat vom Laboraufbau gemäß deines Designs:
Beachtet man das alles sieht die Konfiguration dieses sehr simplen Designs so aus:
Switch 1:
Switch-2 dann entsprechend:
Das Szenario funktioniert fehlerfrei !
Wenn man die Firewall "simuliert" mit einem Switch und so den Loop in VLAN 111 dann geht erwartungsgemäß der Port 20 an Switch 2 in den Blocking Mode.
Traffic im VLAN 111 an Switch-2 was an die Firewall geht läuft also so über den Switch-Uplink Port 25 auf Switch-1 und dann dort via Port 20 an die Firewall.
Simuliert man den Ausfall vom Firewall Port 20 an Switch 1 schaltet RSTP sofort um auf Port 20 an Switch-2 wie es soll.
Ein zusätzliches sh mac-address vlan 111 zeigt dies eindeutig wie die Mac Adressen auf den Ports verteilt durch sind durch die RSTP Topologie.
Ein in den Testports 21 und 22 angeschlossener Laptop zeigt wunderbar die durchgängige Verbindung der LANs in VLAN-1 und VLAN-111 (Ping der Router- und Firewall IP Adresse) sowie VLAN-112.
Ein Ping der Routerports in den VLANs 111 und 112 ist fehlerlos möglich. Der HSRP/VRRP Status der Router zeigt sauber Master und Slave Seite an was auch die korrekt funktionierende HSRP/VRRP Funktion dokumentiert.
Ein simples Standardszenario was genau macht was es soll...
Wo genau ist denn nun noch dein Problem... ??
- 2 HP Switches per tagged Uplink verbunden an Port 25 (entspricht deinem Port 24)
- Tagged Router Uplink für die VLANs 111 und 112 an jedem Switch zum jeweiligen Router an Port 23
- Je einen untagged Testport pro Switch in jedem VLAN um die Connectivity in den VLANs sicher zu testen. 21=VLAN-111, 22=VLAN-112
- Firewall Port untagged in VLAN 111 an Port 20 (entspricht deinem Port 22)
- RSTP Spanning Tree aktiviert, denn das ist zwingend erforderlich, da die Firewall Verbindung auf dem beide Switches hängen sonst einen Loop erzeugen würde. Spanning Tree zu aktivieren ist hier also essentiell. Achtung: Einer der Switches sollte hier immer RSTP Rootbridge sein, was man mit der Spanning Tree Priority festlegt in Modulo 4096er Schritten !! spanning-tree force-version rstp-operation priority 3 ist hier das Kommando auf Switch-1. Switch-2 behält die Default Priority 8. Wenn möglich sollte am Firewall Switchport auch RSTP aktiviert sein. Muss aber nicht zwingend wenn der Firewall Switch RSTP Pakete "durchschleift" ! Dies ist zwingend zu prüfen !! Keinesfalls darf die Firewall RSTP Pakete der Switches blocken, denn das erhöht die Gefahr eines Loops im Netz !!
Beachtet man das alles sieht die Konfiguration dieses sehr simplen Designs so aus:
Switch 1:
hostname "HP-Switch-1"
time timezone 60
time daylight-time-rule Western-Europe
no cdp run
interface 20
name "Firewall"
exit
interface 21
name "Testport_VLAN-111"
exit
interface 22
name "Testport_VLAN-112"
exit
interface 23
name "Tagged_Uplink_Router"
exit
interface 25
name "Uplink_Switch-2"
exit
ip default-gateway 192.168.100.254
sntp server 130.149.17.21 4
timesync sntp
sntp unicast
snmp-server community "public" Unrestricted
vlan 1
name "DEFAULT_VLAN"
untagged 1-19,23-26
ip address 192.168.100.1 255.255.255.0
no untagged 20-22
ip igmp
exit
vlan 111
name "Data"
untagged 20-21
tagged 23,25
exit
vlan 112
name "Voice"
untagged 22
tagged 23,25
exit
spanning-tree
spanning-tree priority 3
hostname "HP-Switch-2"
time timezone 60
time daylight-time-rule Western-Europe
no cdp run
interface 20
name "Firewall"
exit
interface 21
name "Testport_VLAN-111"
exit
interface 22
name "Testport_VLAN-112"
exit
interface 23
name "Tagged_Uplink_Router"
exit
interface 25
name "Uplink_Switch-1"
exit
ip default-gateway 192.168.100.254
sntp server 130.149.17.21 4
timesync sntp
sntp unicast
snmp-server community "public" Unrestricted
vlan 1
name "DEFAULT_VLAN"
untagged 1-19,23-26
ip address 192.168.100.2 255.255.255.0
no untagged 20-22
ip igmp
exit
vlan 111
name "Data"
untagged 20-21
tagged 23,25
exit
vlan 112
name "Voice"
untagged 22
tagged 23,25
exit
spanning-tree
Das Szenario funktioniert fehlerfrei !
Wenn man die Firewall "simuliert" mit einem Switch und so den Loop in VLAN 111 dann geht erwartungsgemäß der Port 20 an Switch 2 in den Blocking Mode.
Traffic im VLAN 111 an Switch-2 was an die Firewall geht läuft also so über den Switch-Uplink Port 25 auf Switch-1 und dann dort via Port 20 an die Firewall.
Simuliert man den Ausfall vom Firewall Port 20 an Switch 1 schaltet RSTP sofort um auf Port 20 an Switch-2 wie es soll.
Ein zusätzliches sh mac-address vlan 111 zeigt dies eindeutig wie die Mac Adressen auf den Ports verteilt durch sind durch die RSTP Topologie.
Ein in den Testports 21 und 22 angeschlossener Laptop zeigt wunderbar die durchgängige Verbindung der LANs in VLAN-1 und VLAN-111 (Ping der Router- und Firewall IP Adresse) sowie VLAN-112.
Ein Ping der Routerports in den VLANs 111 und 112 ist fehlerlos möglich. Der HSRP/VRRP Status der Router zeigt sauber Master und Slave Seite an was auch die korrekt funktionierende HSRP/VRRP Funktion dokumentiert.
Ein simples Standardszenario was genau macht was es soll...
Wo genau ist denn nun noch dein Problem... ??
Kann ich das im Laufenden betrieb ändern ohne das es Auswirkungen auf die anderen gesteckten Komponenten usw. hat
Ja, das kannst du. Es wird zwar einen kurzen Topology Change geben aber das geht so schnell das Endgeräte das nicht merken.Was mit der Firewall und RSTP gemeint ist ist klar. Die Firewall wird vermutlich einen embedded Switch im Gerät haben, oder ?
Also das deren LAN Port z.B. ein 4er Port Switch mit RJ45 Ports sind.
Muss ja auch irgendwie so sein, denn deine Firewall wird mit dem LAN Port ja an BEIDE Switches angeschlossen. Folglich muss sie also mindestens 2 RJ-45 Ports haben die an ihrem LAN Port hängen. Diese 2 Ports müssen dann als Bridge oder Switch definiert sein also in einer gemeinsamen Layer 2 Domain stecken.
Über diese beiden Ports und dann mit der Verbindung der beiden Switches hättest du jetzt ohne Spanning Tree einen L2 Loop gesteckt und dein Netzwerk würde loopen und kollabieren !!
Deshalb ist hier irgendeine Art von Spanning Tree zwingend erforderlich um den Loop zu verhindern.
Wenn die FW nun selber Spanning Tree kann (an den 2 RJ-45 Ports) umso besser, dann kann sie aktiv am Spanning Tree partizipieren.
Oft können (billige) Firewalls das aber nicht. Dann musst du aber sicherstellen das BPDU Pakete (STP Pakete) über die 2 Ports passieren können, damit der STP sauber funktionieren kann. Oft wird das STP oder BPDU "Flooding" genannt.
Wenn du das Kommando "spanning-tree force-version rstp-operation priority 3" gilt das in der Tat global für den gesamten Switch.
Diese Billigswitches von HP supporten kein STP per VLAN.
Auf dem Switch 2 bleibt das in der Default Einstellung !
Ein show spanning tree sollte dir aber auf BEIDEN Switches zeigen das der Spanning Tree aktiv ist also entsprechenden Output anzeigen !
OK, dann sind die FW nur einbeinig angebunden. Das war aus deiner obigen Schilderung und der Zeichnung nicht so ganz klar, deshalb der Hinweis. Den kannst du dann aber ignorieren. Bei einbeiniger Anbindung natürlich kein Loop...klar !
Du kannst mit "sh span det" auch sehen welcher Switch der Root Switch bzw. Root Bridge ist. Wenn du das Kommando "spanning-tree force-version rstp-operation priority 3" dort ausführst passiert rein gar nichts, denn dann bleibt der Root Root und es passiert keinerlei Topo Change. Das soll ja nur im Spanning Tree festlegen wer die Root Bridge ist.
Da die Loop Ports auf Switch 1 auf Forwarding stehen kannst du davon ausgehen das der 1 auch die Root Bridge ist. Kannst du aber am "sh span det" auch an der Mac Adresse sehen !
Generell komisch ist das aber schon das die Ports 2,3,4,5,6,7,13 und 24 auf Blocking stehen !!!
Gerade bei 24 darf das niemals der Fall sein, denn das ist ja der Uplink zwischen den beiden Switches !
Leider schreibst du nicht WAS an 2,3,4,5,6,7 und 13 angeschlossen ist aber es muss ja etwas sein was einen Loop im Netzwerk erzeugt ?!
Wie gesagt das kann normal sein in einem Redundanz Szenario aber niemals in deinem Schaubild mit nur den 2 Switches die du oben aufgemalt hast.
Wenn die Firewalls wie du sagst nur einbeinig dran sind kann es niemals in diesem design ein Loopszenario geben. Hier erzählst du uns also nur die halbe Wahrheit, denn die geblockten Ports lassen darauf schliessen das das noch mehr redundante Links im Spiel sind.
Wie gesagt gerade der Port 24 kann und darf nicht sein, denn sonst nehmen ALLE Verbindungen in die VLANs 1, 111 und 112 vollkommen andere Wege die NICHT über die von dir angegebenen Ports laufen !
Bevor wir hier weitermachen solltest du also dringenst nochmal was zur Netzwerk Topologie hier posten, denn so einfach wie du die darstellt ist sie garantiert nicht, das zeigen deine show Outputs !!
Es muss also ein himmelweiter Unterschied sein zwischen den Ports 1 und 2-6 !!!
WAS also ist da WIE angeschlossen !
Du kannst mit "sh span det" auch sehen welcher Switch der Root Switch bzw. Root Bridge ist. Wenn du das Kommando "spanning-tree force-version rstp-operation priority 3" dort ausführst passiert rein gar nichts, denn dann bleibt der Root Root und es passiert keinerlei Topo Change. Das soll ja nur im Spanning Tree festlegen wer die Root Bridge ist.
Da die Loop Ports auf Switch 1 auf Forwarding stehen kannst du davon ausgehen das der 1 auch die Root Bridge ist. Kannst du aber am "sh span det" auch an der Mac Adresse sehen !
Generell komisch ist das aber schon das die Ports 2,3,4,5,6,7,13 und 24 auf Blocking stehen !!!
Gerade bei 24 darf das niemals der Fall sein, denn das ist ja der Uplink zwischen den beiden Switches !
Leider schreibst du nicht WAS an 2,3,4,5,6,7 und 13 angeschlossen ist aber es muss ja etwas sein was einen Loop im Netzwerk erzeugt ?!
Wie gesagt das kann normal sein in einem Redundanz Szenario aber niemals in deinem Schaubild mit nur den 2 Switches die du oben aufgemalt hast.
Wenn die Firewalls wie du sagst nur einbeinig dran sind kann es niemals in diesem design ein Loopszenario geben. Hier erzählst du uns also nur die halbe Wahrheit, denn die geblockten Ports lassen darauf schliessen das das noch mehr redundante Links im Spiel sind.
Wie gesagt gerade der Port 24 kann und darf nicht sein, denn sonst nehmen ALLE Verbindungen in die VLANs 1, 111 und 112 vollkommen andere Wege die NICHT über die von dir angegebenen Ports laufen !
Bevor wir hier weitermachen solltest du also dringenst nochmal was zur Netzwerk Topologie hier posten, denn so einfach wie du die darstellt ist sie garantiert nicht, das zeigen deine show Outputs !!
Es muss also ein himmelweiter Unterschied sein zwischen den Ports 1 und 2-6 !!!
WAS also ist da WIE angeschlossen !
Allein der Begriff default VLAN sollte dir schon richtig viel zu denken geben.
Aus deiner Sicht sit das das erste VLAN, das es eben gibt und was da ist.
Aber es ist etwas anderes und ein default VLAN sollte nicht für die Endgeräte benutzt werden. Das ist etwas für die Infrastruktur.
Also es ist alles, nur nicht egal.
Gruß
Netman
Aus deiner Sicht sit das das erste VLAN, das es eben gibt und was da ist.
Aber es ist etwas anderes und ein default VLAN sollte nicht für die Endgeräte benutzt werden. Das ist etwas für die Infrastruktur.
Also es ist alles, nur nicht egal.
Gruß
Netman
Sind diese Switches ALLES HP Switches ?? Und....
Sind alle die Sub Switches irgendwie redundant angebunden so wie in einen klassichen Design wie hier:
Core wäre hier MS und Access SS. Oder sind die alle nur einbeinig zusammengesteckt ohne jegliche Redundanz ??
Nach deine o.a. Aufstellung nein denn die SS Switche sind alle beidbeinig an die MS angeschlossen und damit dann alles redundant nach der o.a. Zeichnung, richtig ??
Da wäre es dann auch vollkommen kontraproduktiv wenn einer der Access Switches eine höhere Prio hat. Das solltest du dann schnellstens wieder entfernen !!
Einer der MS Master oder Root Switches MUSS hier die Root Bridge sein und der 2te Master die Backup Root ! NICHT die SS Switches ! Die haben Default STP Prio.
Hier musst du also einen auf Priority 4096 setzen und den anderen auf Priority 8192 (immer Modulo 4096) die Access Teile sollten alle in der Default Priority verbleiben !!
Grund der Frage: Hast du durchgängig ein Single Span Spanning Tree im Einsatz (HP Default) oder sind die Master Switches irgend ein anderes Fabrikat ??
Du musst wasserdicht sicherstellen das du durchgängig im gesamten Netz ein Single Span Spanning Tree einsetzt. Und...es muss durchgängig RSTP (Rapid STP) aktiviert sein !
Es dürfen nirgends irgendwelche Switches sein die ein Per VLAN STP laufen haben PVSTP oder Cisco PVSTP+ oder auch MSTP die sind nicht kompaibel und können zu unvorhergesehenen Topologie Änderungen führen.
Checke also akribisch ob das so umgesetzt ist auf den Switches sonst kommen wir hier nicht weiter.
Irgendwas ist dort nämlich inkonsistent bei dir im STP wenn auf deinem Access Switch so viele Ports in den Blocking Mode gehen !!
Es sind ja die Ports 1 bis 13 was vermuten lässt das da irgendwas nicht stimmt mit dem STP.
Sind alle die Sub Switches irgendwie redundant angebunden so wie in einen klassichen Design wie hier:
Core wäre hier MS und Access SS. Oder sind die alle nur einbeinig zusammengesteckt ohne jegliche Redundanz ??
Nach deine o.a. Aufstellung nein denn die SS Switche sind alle beidbeinig an die MS angeschlossen und damit dann alles redundant nach der o.a. Zeichnung, richtig ??
Da wäre es dann auch vollkommen kontraproduktiv wenn einer der Access Switches eine höhere Prio hat. Das solltest du dann schnellstens wieder entfernen !!
Einer der MS Master oder Root Switches MUSS hier die Root Bridge sein und der 2te Master die Backup Root ! NICHT die SS Switches ! Die haben Default STP Prio.
Hier musst du also einen auf Priority 4096 setzen und den anderen auf Priority 8192 (immer Modulo 4096) die Access Teile sollten alle in der Default Priority verbleiben !!
Grund der Frage: Hast du durchgängig ein Single Span Spanning Tree im Einsatz (HP Default) oder sind die Master Switches irgend ein anderes Fabrikat ??
Du musst wasserdicht sicherstellen das du durchgängig im gesamten Netz ein Single Span Spanning Tree einsetzt. Und...es muss durchgängig RSTP (Rapid STP) aktiviert sein !
Es dürfen nirgends irgendwelche Switches sein die ein Per VLAN STP laufen haben PVSTP oder Cisco PVSTP+ oder auch MSTP die sind nicht kompaibel und können zu unvorhergesehenen Topologie Änderungen führen.
Checke also akribisch ob das so umgesetzt ist auf den Switches sonst kommen wir hier nicht weiter.
Irgendwas ist dort nämlich inkonsistent bei dir im STP wenn auf deinem Access Switch so viele Ports in den Blocking Mode gehen !!
Es sind ja die Ports 1 bis 13 was vermuten lässt das da irgendwas nicht stimmt mit dem STP.
Da rächt sich dann wieder die Wahl vom Billigheimer HP. Der Cisco SG-200 hat wenigstens beide Arten von Spanning Tree und das sogar beim 8 Port Modell...aber egal...
Damit schliesst sich dann ein redundantes Szeanrio mit dem 1810er Gurken aus. Die darf man dann nur einbeinig anschliessen oder... muss absolut sicher stellen das die BPDU Pakete transparent durchswitchen. Das machen nicht alle....
Wenn sie es nicht machen, dann sollte man niemals mit redundanten Links arbeiten mit der HW. Solche Homeuser Teile haben auch nichts in einem redundanten Firmennetzwerk zu suchen !! Löst aber natürlich nicht das Problem.
Du solltest also erstmal checken ob die BPDUs der anderen Switches passieren lassen, dann kann man sie gefahrlos einsetzen, sonst nicht.
Es entbindet dich aber auch nicht die beiden "MS" Switches als Root Bridge und Backup Root Bridge zu definieren. Im Gegenteil es macht das noch zwingender erforderlich. Das ist ein Muss in so einem redundanten Design !
Damit schliesst sich dann ein redundantes Szeanrio mit dem 1810er Gurken aus. Die darf man dann nur einbeinig anschliessen oder... muss absolut sicher stellen das die BPDU Pakete transparent durchswitchen. Das machen nicht alle....
Wenn sie es nicht machen, dann sollte man niemals mit redundanten Links arbeiten mit der HW. Solche Homeuser Teile haben auch nichts in einem redundanten Firmennetzwerk zu suchen !! Löst aber natürlich nicht das Problem.
Du solltest also erstmal checken ob die BPDUs der anderen Switches passieren lassen, dann kann man sie gefahrlos einsetzen, sonst nicht.
Es entbindet dich aber auch nicht die beiden "MS" Switches als Root Bridge und Backup Root Bridge zu definieren. Im Gegenteil es macht das noch zwingender erforderlich. Das ist ein Muss in so einem redundanten Design !
OK, das sieht einigermaßen OK aus...allerdings nur einigermaßen, den mit deiner Beschreibung oben welcher Switch WO angeschlossen ist kann es nicht übereinstimmen !
Bei Switches SW1 und SW2 sind ja jeweils redundant mit ihren beiden Uplinks je an MS1 und MS2 verbunden.
Gehen wier mal davon aus das MS1 der Root Switch ist mit der höchsten Priority wie es sein sll und MS2 mit der zweithöchsten also Backup Root und alles Access Switches haben die Standard Prio.
Angeschlossen sind sie ja wie oben im "14:06" Bild !
Wenn die Anschlüsse so stimmen und der STP so richtig definiert ist dann müssten auf dem SW1 UNF auch auf SW2 jeweils die Ports an denen der Uplink zu MS2 angeschlossen ist in den Blocking Status gehen, denn diese Ports haben aus STP Sicht die schlechtesten Costs.
Genau DAS ist aber bei dir nicht der Fall !!
Vielmehr ist bei SW1 jeder Port im Forwarding Mode was so niemals sein kann sollte deine Angabe stimmen.
Und bei SW2 ist fast alles relevante im Blocking Mode...auch das kann so nach deiner Netzdesign Beschreibung nicht stimmen !
Irgendwas ist also noch oberfaul in deinem Desin und/oder deiner Verkabelung !
Außerdem zeigen die Switches nun oben MSTP an statt RSTP ?!
Hast du jetzt alles global auf MSTP Spanning Tree umgestellt statt RSTP ??
Wenn ja arbeitest du da ggf. dann mit unterschiedlichen Priottities in den einzelnen MSTP Instances ??
Du machst der Community hier echt das Leben schwer denn mit jedem Posting zeigst du hier gravierende sich widersprechende Netzwerk Konfigs so das man immer wieder aufs neue anfangen muss, was etwas frustrierend ist.
Nimmt man sich jetzt nur mal deinen beiden Master (Core) Switches vor mit den beiden relevanten Switches 1 und 2 dann sollte das Design gemäß deiner o.a. Port Verkabelungsliste ja so aussehen, richtg ?!:
Fraglich laut deiner Port Liste ist der Port 24 der zusammen mit dem Port 13 beide Master Switches verbindet. Das aber witzigerweise nur für die VLANs 111 und 112.
Sinnvoll fragt man sich was der Unsinn soll ??
Es macht doch viel mehr Sinn den Port 13 UND den Port 24 auf beiden MS Switches in einen Trunk (Link Aggregation) zusammenzuführen und den für ALLE VLANs als Uplink zwischen den beiden Core Switches einzurichten wie es auch allgemein in einem Standard Redundanz Szenario so üblich ist.
Strukturell sähe dasdann so aus:
Das nämlich verhindert gefürchtete STP Inkonsistenzen zw. den verschiedenen VLANs und löst durch Trunking und der damit verbundenen Bandbreitenerhöhung zw.den Core Switches auch evtl. Performance Engpässe hier, da ein L2 Forwarding ja nur auf dem Root Switch im Core passiert. Auch das ein simples Standardszenario.
Wenn du also alles so eingerichtet hast wie in der o.a. Zeichnung müsstest du auch das dazu korrespondierende STP Blocking Verhalten sehen. Was übrigens identisch ist für alle so angebundenen "SS" Switches !
Fazit: Du musst also hier den Verkabelungs bzw. STP Kincken finden sonst drehen wir uns hier weiter im Kreis !
Bei Switches SW1 und SW2 sind ja jeweils redundant mit ihren beiden Uplinks je an MS1 und MS2 verbunden.
Gehen wier mal davon aus das MS1 der Root Switch ist mit der höchsten Priority wie es sein sll und MS2 mit der zweithöchsten also Backup Root und alles Access Switches haben die Standard Prio.
Angeschlossen sind sie ja wie oben im "14:06" Bild !
Wenn die Anschlüsse so stimmen und der STP so richtig definiert ist dann müssten auf dem SW1 UNF auch auf SW2 jeweils die Ports an denen der Uplink zu MS2 angeschlossen ist in den Blocking Status gehen, denn diese Ports haben aus STP Sicht die schlechtesten Costs.
Genau DAS ist aber bei dir nicht der Fall !!
Vielmehr ist bei SW1 jeder Port im Forwarding Mode was so niemals sein kann sollte deine Angabe stimmen.
Und bei SW2 ist fast alles relevante im Blocking Mode...auch das kann so nach deiner Netzdesign Beschreibung nicht stimmen !
Irgendwas ist also noch oberfaul in deinem Desin und/oder deiner Verkabelung !
Außerdem zeigen die Switches nun oben MSTP an statt RSTP ?!
Hast du jetzt alles global auf MSTP Spanning Tree umgestellt statt RSTP ??
Wenn ja arbeitest du da ggf. dann mit unterschiedlichen Priottities in den einzelnen MSTP Instances ??
Du machst der Community hier echt das Leben schwer denn mit jedem Posting zeigst du hier gravierende sich widersprechende Netzwerk Konfigs so das man immer wieder aufs neue anfangen muss, was etwas frustrierend ist.
Nimmt man sich jetzt nur mal deinen beiden Master (Core) Switches vor mit den beiden relevanten Switches 1 und 2 dann sollte das Design gemäß deiner o.a. Port Verkabelungsliste ja so aussehen, richtg ?!:
Fraglich laut deiner Port Liste ist der Port 24 der zusammen mit dem Port 13 beide Master Switches verbindet. Das aber witzigerweise nur für die VLANs 111 und 112.
Sinnvoll fragt man sich was der Unsinn soll ??
Es macht doch viel mehr Sinn den Port 13 UND den Port 24 auf beiden MS Switches in einen Trunk (Link Aggregation) zusammenzuführen und den für ALLE VLANs als Uplink zwischen den beiden Core Switches einzurichten wie es auch allgemein in einem Standard Redundanz Szenario so üblich ist.
Strukturell sähe dasdann so aus:
Das nämlich verhindert gefürchtete STP Inkonsistenzen zw. den verschiedenen VLANs und löst durch Trunking und der damit verbundenen Bandbreitenerhöhung zw.den Core Switches auch evtl. Performance Engpässe hier, da ein L2 Forwarding ja nur auf dem Root Switch im Core passiert. Auch das ein simples Standardszenario.
Wenn du also alles so eingerichtet hast wie in der o.a. Zeichnung müsstest du auch das dazu korrespondierende STP Blocking Verhalten sehen. Was übrigens identisch ist für alle so angebundenen "SS" Switches !
Fazit: Du musst also hier den Verkabelungs bzw. STP Kincken finden sonst drehen wir uns hier weiter im Kreis !
Laut der aktuellen Konfig vom TO stimmt m.M.n. die Switch Priority vom Switch 2 nicht, die ist noch auf dem Default Wert 32768.
Ich denke nicht, dass wir hier ohne eine detailgenaue Skizze weiterkommen, wie @aqui schon länger meint.
Ist denn sichergestellt, dass BPDU-Pakete die Uplinks transparent passieren können?
Auch ein Auszug der aktuell laufenden Konfig auf beiden Switchen wäre sicher nützlich (sh run)
Ich denke nicht, dass wir hier ohne eine detailgenaue Skizze weiterkommen, wie @aqui schon länger meint.
Ist denn sichergestellt, dass BPDU-Pakete die Uplinks transparent passieren können?
Auch ein Auszug der aktuell laufenden Konfig auf beiden Switchen wäre sicher nützlich (sh run)
@daniel.shl
Vorsicht das du das hier nicht verwechselst oder durcheinander bringst !!!
Die Switch Priority muss ausschliesslich nur bei den MS Switches also den beiden Core Switches angegeben werden genau wie es in der o.a. Topologieskizze geschschildert ist. Z.B. MS1=Root=4096 und MS2"=Backup Root=8192
Die mit "SS" bezeichneten Access Switches können allesamt mit der Standard Prio arbeiten, denn der Root Path des STP Protokolls wird so zwingend duch die Root und Backup Root vorgegeben !!
Das macht natürlich nur Sinn wenn alle "SS" Switches so wie in der "14:06 Zeichnung" oben beidbeinig an die MS Switches angeschlossen sind, was ja der Fall ist wenn man der Liste des TOs hier trauen kann !
Für einbeinig angebundenen Geräte ist das irrelevant da hier natürlich kein STP wirkt.
Vorsicht das du das hier nicht verwechselst oder durcheinander bringst !!!
Die Switch Priority muss ausschliesslich nur bei den MS Switches also den beiden Core Switches angegeben werden genau wie es in der o.a. Topologieskizze geschschildert ist. Z.B. MS1=Root=4096 und MS2"=Backup Root=8192
Die mit "SS" bezeichneten Access Switches können allesamt mit der Standard Prio arbeiten, denn der Root Path des STP Protokolls wird so zwingend duch die Root und Backup Root vorgegeben !!
Das macht natürlich nur Sinn wenn alle "SS" Switches so wie in der "14:06 Zeichnung" oben beidbeinig an die MS Switches angeschlossen sind, was ja der Fall ist wenn man der Liste des TOs hier trauen kann !
Für einbeinig angebundenen Geräte ist das irrelevant da hier natürlich kein STP wirkt.
Hi @aqui,
laut deiner Skizze stimmt das mit den STP-Prios schon
Die letzten Auszüge aus den Konfigurationen der Switches 1 und 2 vom TO, welche ich einfach mal als aktuell laufend bezeichnen würde, zeigen, dass beim Switch 1 (MS-1) die STP Prio auf 12288 steht,
beim Switch 2 (MS-2) auf dem default Wert 32768. Somit dürften alle relevanten Switche nur eine Root Bridge und keine Backup Root sehen...
Viele Grüße
laut deiner Skizze stimmt das mit den STP-Prios schon
Die letzten Auszüge aus den Konfigurationen der Switches 1 und 2 vom TO, welche ich einfach mal als aktuell laufend bezeichnen würde, zeigen, dass beim Switch 1 (MS-1) die STP Prio auf 12288 steht,
beim Switch 2 (MS-2) auf dem default Wert 32768. Somit dürften alle relevanten Switche nur eine Root Bridge und keine Backup Root sehen...
Viele Grüße
So wie ich das verstanden habe hat der TO hier aber NICHT die MS Switches gepostet sondern das sind Konfigs der Switches SS1 und SS2.
Aber auch wenn das der Fall wäre, wäre dann diese STP Prio ebenfalls FALSCH.
Du hast also so oder so Recht !!
Zur Sicherheit sollte das der TO aber nochmal selber klären und ggf. korrigieren.
Sofern er denn überhaupt noch Internesse an einer Lösung dieses Problems interessiert ist.
Das Feedback von ihm geht ja mittlerweile leider gegen Null...
Aber auch wenn das der Fall wäre, wäre dann diese STP Prio ebenfalls FALSCH.
Du hast also so oder so Recht !!
Zur Sicherheit sollte das der TO aber nochmal selber klären und ggf. korrigieren.
Sofern er denn überhaupt noch Internesse an einer Lösung dieses Problems interessiert ist.
Das Feedback von ihm geht ja mittlerweile leider gegen Null...
Hi,
abgesehen davon, dass du die STP Prios nicht wie von @aqui vorgeschlagen mit 4096 für die Root Bridge und 8192 für die Backup-Root Bridge vergeben hast,
verstehe ich eines nicht:
Laut deiner Zeichnung sind deine beiden "Core-Switche" MS-1 und MS-2 direkt über das Interface 24 verbunden.
Switch 2 blockt diese Verbindung aufgrund eines Loops und sieht als seinen Root-Port (also quasi aktiven Uplink) Interface 1.
Bist du wirklich sicher, dass alle Switches so verbunden sind, wie in deiner Zeichnung?
Falls ja, würde ich testhalber folgendes versuchen:
1.) das Kommando lacp passive für das Interface 24 herausnehmen (warum ist das eigentlich aktiv?)
2.) die redundante Verbindung zu den 1810-er Gurken trennen und schauen, ob dann alles rennt, wie gewünscht.
btw: die Firmware auf den 2810ern ist hornalt, da würde ich ggf. mal ein aktuelles Release aufspielen.
abgesehen davon, dass du die STP Prios nicht wie von @aqui vorgeschlagen mit 4096 für die Root Bridge und 8192 für die Backup-Root Bridge vergeben hast,
verstehe ich eines nicht:
Laut deiner Zeichnung sind deine beiden "Core-Switche" MS-1 und MS-2 direkt über das Interface 24 verbunden.
Switch 2 blockt diese Verbindung aufgrund eines Loops und sieht als seinen Root-Port (also quasi aktiven Uplink) Interface 1.
Bist du wirklich sicher, dass alle Switches so verbunden sind, wie in deiner Zeichnung?
Falls ja, würde ich testhalber folgendes versuchen:
1.) das Kommando lacp passive für das Interface 24 herausnehmen (warum ist das eigentlich aktiv?)
2.) die redundante Verbindung zu den 1810-er Gurken trennen und schauen, ob dann alles rennt, wie gewünscht.
btw: die Firmware auf den 2810ern ist hornalt, da würde ich ggf. mal ein aktuelles Release aufspielen.
Dein Root Switch 1 hat immer noch eine falsche Priority !!! Switch Priority : 0
Das musst du ändern ! Der Root Switch muss die Priority 4096 haben und der Backup die 8192 ! Du darfst keine Priority 0 haben, denn das ist im STP nicht definiert und kann zu unvorhersehbaren Zuständen führen.
Weiterhin zeigen die beiden Core Systeme immer noch MSTP Spanning Tree an, denn man kann immer nich die Instances sehen. MSTP musst du abschalten !
Ansonsten sieht das STP Verfahren schon besser aus. Da die 1810er Billigsysteme kein aktives STP können "schleifen" die durch. Das heisst BPDU STP Packete sehen den einfach als Kabel das durchgeht, deshalb sind die redundanten Links am 2ten Core alle auf Blocking wie erwartet. Port 1 MUSS hier auch auf Blocking gehen, da die Anbindung ja vollkommen identisch ist zu den anderen 1810ern, es hier also keinerlei Unterschiede geben darf !!
Abgesehen von einer Lösung haben solche Billigsystem die nichtmal ein minimalstes Spanning Tree supporten in so einen Redundanzszenario gar nichts zu suchen !!
Was hat dich bloß geritten so einen Schrott da reinzudesignen, denn diese Teile können jetzt nicht aktiv am STP teilnehmen. Damit konterkariert man vollkommen so ein eigentlich sehr sinnvolles und redundantes Szenario.
Beispiel mal die Billigswitches von Cisco der SG-200 oder SF 200er Serie haben allesamt STP an Bord sogar bis runter zum kleinsten 8Port Modell. Wenn das die 1810er nicht mal können ist das Schrott und eigentlich ein NoGo für das Design..
Aber nungut wir bekommen das schon zum Fliegen
Das musst du ändern ! Der Root Switch muss die Priority 4096 haben und der Backup die 8192 ! Du darfst keine Priority 0 haben, denn das ist im STP nicht definiert und kann zu unvorhersehbaren Zuständen führen.
Weiterhin zeigen die beiden Core Systeme immer noch MSTP Spanning Tree an, denn man kann immer nich die Instances sehen. MSTP musst du abschalten !
Ansonsten sieht das STP Verfahren schon besser aus. Da die 1810er Billigsysteme kein aktives STP können "schleifen" die durch. Das heisst BPDU STP Packete sehen den einfach als Kabel das durchgeht, deshalb sind die redundanten Links am 2ten Core alle auf Blocking wie erwartet. Port 1 MUSS hier auch auf Blocking gehen, da die Anbindung ja vollkommen identisch ist zu den anderen 1810ern, es hier also keinerlei Unterschiede geben darf !!
Abgesehen von einer Lösung haben solche Billigsystem die nichtmal ein minimalstes Spanning Tree supporten in so einen Redundanzszenario gar nichts zu suchen !!
Was hat dich bloß geritten so einen Schrott da reinzudesignen, denn diese Teile können jetzt nicht aktiv am STP teilnehmen. Damit konterkariert man vollkommen so ein eigentlich sehr sinnvolles und redundantes Szenario.
Beispiel mal die Billigswitches von Cisco der SG-200 oder SF 200er Serie haben allesamt STP an Bord sogar bis runter zum kleinsten 8Port Modell. Wenn das die 1810er nicht mal können ist das Schrott und eigentlich ein NoGo für das Design..
Aber nungut wir bekommen das schon zum Fliegen
Nein, sorry musst du nicht. die HP 28er Serie kann nix anderes als MSTP aber solange die alle in der Default Instance drin sind sind die kompatibel zu RSTP
ftp://ftp-boi.external.hp.com/pub/networking/software/2810-AdvTrafficMgmt-July2007-59914733.pdf Kapitel 5
Was aber wichtig ist ist das Switch 1 (Root) auf priority 1 gesetzt ist und Switch 2 (Backup Root) auf priority 2
Damit hat der eine Root dann 4096 und der Backup 8192 wie es sein soll. Das wäre der erste Schritt.
2ter Fehler der noch besteht:
Port 24 ist ja jetzt richtig der einzige Verbindungsport zwischen den beiden Switches. Natürlich kannst du mit 2 Ports hier auch eine Link Aggreagtion mit LACP machen was fehlerfrei klappt, aber lass das erstmal das können wir machen wenn der Rest sauber funktioniert.
Erstmal so wenig parallele Baustellen wie nötig...!!
Port 24 das hast du..
vlan 1
name "DEFAULT_VLAN"
forbid 21-23
untagged 1-18
ip address 192.168.100.2 255.255.255.0
tagged 24
no untagged 19-23
exit
Das tagged 24 auf den Switches 1 und 2 ist etwas ungewöhnlich bei HP ProCurves, denn in der Regel können die das Default VLAN, und das ist ja hier den VLAN 1, nicht taggen auf einem Uplink Trunk. Es wird immer untagged übertragen.
Du solltest also nochmal ganz sicher stellen das dein VLAN 1 auch HIER über diesen Port 24 zwischne den beiden Switches 1 und 2 übertragen werden.
Passiert das nicht rennen sie als "Umweg" über den Uplink eines der Uplink Switches TS-SSx was natürlich dann wieder eine Loop Gefahr mit sich bringt da diese kein STP können.
Ziehe also dazu auf dem Root Switch mal alle Uplinks ab und checke ob due VLAN 1 Connectivity hast zw. den Switches 1 und 2 indem du da mal pingst auf Systemen die im VLAN hängen.
Das Abziehen musst du deshalb machen damit du den "Umweg" unterbrichst und damit VLAN 1 Traffic zwingend nur über Port 24 gehen kann.
Du kannst das auch sehen mit dem Kommando sh mac das dir dann alle Ziel Mac Adressen auf Switch 2 nur via Port 24 anzeigt ! Dann ist alles richtig mit Port 24
Ist das erforlgreich kannst du die Access switch Uplinks wieder aufstecken.
Router Anbindung mit Port 23 jeweils tagged in VLAN 111 und 112 ist OK !
Etwas unklar ist noch die Ports für die Firewall die du in der Zeichnung nicht richtig beschriftet hast.
Es sieht so aus das jeweils der Port 7 aus dem VLAN 1 beider Switches untagged auf das FW Cluster geht und...
Jeweils der Port 22 aus dem VLAN 111 untagged auf das FW Cluster, richtig ?
Auf die Uplink Ports 1 bis 6 der beiden Switches gehen ja nur die 1810er Ports die so oder so nur einzig im VLAN 1 sind. An diesen Switches angeschlossene Clients "sehen" also nur das VLAN 1
Diese Ports 1 bis 6 müssen alle auf dem Backup Root Switch ins Blocking gehen, auf dem Root Switch ins Forwarding. So wäre es mit der Prio 1 und 2 auf den zwei 2810ern zu erwarten.
Ein ungelöstes Kardinalsproblem hast du noch auf den beiden 2810er Switches !!
Normal routen diese Switches als zentrale Instanz zwischen den VLANs. Du hast ihnen ja dafür auch eine IP Adresse im VLAN gegeben !
Da du aber nun 2 aktive Gateway IPs hast auf den Switches hast du nun ein gateway Problem für die Endgeräte, denn welches willst du jetzt nehmen ?? SW1 oder SW2 ??
Normalerweise löst man das mit VRRP und einer virtuellen IP Adresse die wandern kann falls einer der Switches mal ausfällt.
http://www.hp.com/rnd/support/manuals/pdf/release_06628_07110/Bk2_Ch12_ ...
Ob die 2810er das supporten musst du im Manual nachsehen !
Sollten sie kein VRRP oder irgendeine andere Art der Gateway Redundanz supporten kannst du auf dem Backup Root Switch komplett außer VLAN 1 (Switch Managment) die IPs entfernen und das Gateway auf die Root Switch IPs legen. Logisch, denn dann bringt einen Layer 3 Gateway Redundanz nix.
Wie gesagt das ist nur erforderlich wenn die Switches auch zwischen den VLANs oder nur einigen VLANs routen sollen.
Wenn du NICHT zentral routen willst mit den VLAN Switches sondern das extern über die Firewalls erledigen willst dann darfst du natürlich KEINE IP Adressen in den VLANs 111 und 112 auf den Switches 1 und 2 definieren !!!
Warum nicht ?!:
Sowie du das gemacht hast, fungiert der Switch sofort als Router und hebelt dir damit dann deine Firewall Sicherheit aus, denn ein Client kann dann problemlos OHNE jede FW Zugriffsbeschränkung über die HPs in andere VLANs routen.
Wenn du das also nicht willst: WEG mit den IPs auf den beiden Switches 1 und 2.
Einzig nur die IP im Default VLAN 1 sollte und muss bleiben damit du den Switch managen kannst !
Soll nur zwischen Voice 112 und VLAN 1 geroutet werden auf den Switches, entfernst du einfach die IP nur im Data VLAN. Alles darus muss dann über die FW routen da es nichts anderes gibt...logisch.
Regel: Alles was zwingend über die FW geroutet werden soll oder muss darf NICHT eine IP auf den beiden Switches bekommen !
Achtung: Routen die Switches oder routen sie einen Teil der VLANs dann müssen sie beide eine Default Route auf Router oder Firewall bekommen je nachdem wer im lokalen Netzwerk bei dir das zentrale Routing macht zw. den VLAN bzw. IP Segmenten und ins Internet.
Hier musst du dich also entscheiden...
Wenn das alles sicher geklärt und angepasst ist in der Konfig, ist soweit alles sauber in der Switch Konfig 1 und 2.
Folgende Tests müssen dann klappen:
ftp://ftp-boi.external.hp.com/pub/networking/software/2810-AdvTrafficMgmt-July2007-59914733.pdf Kapitel 5
Was aber wichtig ist ist das Switch 1 (Root) auf priority 1 gesetzt ist und Switch 2 (Backup Root) auf priority 2
Damit hat der eine Root dann 4096 und der Backup 8192 wie es sein soll. Das wäre der erste Schritt.
2ter Fehler der noch besteht:
Port 24 ist ja jetzt richtig der einzige Verbindungsport zwischen den beiden Switches. Natürlich kannst du mit 2 Ports hier auch eine Link Aggreagtion mit LACP machen was fehlerfrei klappt, aber lass das erstmal das können wir machen wenn der Rest sauber funktioniert.
Erstmal so wenig parallele Baustellen wie nötig...!!
Port 24 das hast du..
vlan 1
name "DEFAULT_VLAN"
forbid 21-23
untagged 1-18
ip address 192.168.100.2 255.255.255.0
tagged 24
no untagged 19-23
exit
Das tagged 24 auf den Switches 1 und 2 ist etwas ungewöhnlich bei HP ProCurves, denn in der Regel können die das Default VLAN, und das ist ja hier den VLAN 1, nicht taggen auf einem Uplink Trunk. Es wird immer untagged übertragen.
Du solltest also nochmal ganz sicher stellen das dein VLAN 1 auch HIER über diesen Port 24 zwischne den beiden Switches 1 und 2 übertragen werden.
Passiert das nicht rennen sie als "Umweg" über den Uplink eines der Uplink Switches TS-SSx was natürlich dann wieder eine Loop Gefahr mit sich bringt da diese kein STP können.
Ziehe also dazu auf dem Root Switch mal alle Uplinks ab und checke ob due VLAN 1 Connectivity hast zw. den Switches 1 und 2 indem du da mal pingst auf Systemen die im VLAN hängen.
Das Abziehen musst du deshalb machen damit du den "Umweg" unterbrichst und damit VLAN 1 Traffic zwingend nur über Port 24 gehen kann.
Du kannst das auch sehen mit dem Kommando sh mac das dir dann alle Ziel Mac Adressen auf Switch 2 nur via Port 24 anzeigt ! Dann ist alles richtig mit Port 24
Ist das erforlgreich kannst du die Access switch Uplinks wieder aufstecken.
Router Anbindung mit Port 23 jeweils tagged in VLAN 111 und 112 ist OK !
Etwas unklar ist noch die Ports für die Firewall die du in der Zeichnung nicht richtig beschriftet hast.
Es sieht so aus das jeweils der Port 7 aus dem VLAN 1 beider Switches untagged auf das FW Cluster geht und...
Jeweils der Port 22 aus dem VLAN 111 untagged auf das FW Cluster, richtig ?
Auf die Uplink Ports 1 bis 6 der beiden Switches gehen ja nur die 1810er Ports die so oder so nur einzig im VLAN 1 sind. An diesen Switches angeschlossene Clients "sehen" also nur das VLAN 1
Diese Ports 1 bis 6 müssen alle auf dem Backup Root Switch ins Blocking gehen, auf dem Root Switch ins Forwarding. So wäre es mit der Prio 1 und 2 auf den zwei 2810ern zu erwarten.
Ein ungelöstes Kardinalsproblem hast du noch auf den beiden 2810er Switches !!
Normal routen diese Switches als zentrale Instanz zwischen den VLANs. Du hast ihnen ja dafür auch eine IP Adresse im VLAN gegeben !
Da du aber nun 2 aktive Gateway IPs hast auf den Switches hast du nun ein gateway Problem für die Endgeräte, denn welches willst du jetzt nehmen ?? SW1 oder SW2 ??
Normalerweise löst man das mit VRRP und einer virtuellen IP Adresse die wandern kann falls einer der Switches mal ausfällt.
http://www.hp.com/rnd/support/manuals/pdf/release_06628_07110/Bk2_Ch12_ ...
Ob die 2810er das supporten musst du im Manual nachsehen !
Sollten sie kein VRRP oder irgendeine andere Art der Gateway Redundanz supporten kannst du auf dem Backup Root Switch komplett außer VLAN 1 (Switch Managment) die IPs entfernen und das Gateway auf die Root Switch IPs legen. Logisch, denn dann bringt einen Layer 3 Gateway Redundanz nix.
Wie gesagt das ist nur erforderlich wenn die Switches auch zwischen den VLANs oder nur einigen VLANs routen sollen.
Wenn du NICHT zentral routen willst mit den VLAN Switches sondern das extern über die Firewalls erledigen willst dann darfst du natürlich KEINE IP Adressen in den VLANs 111 und 112 auf den Switches 1 und 2 definieren !!!
Warum nicht ?!:
Sowie du das gemacht hast, fungiert der Switch sofort als Router und hebelt dir damit dann deine Firewall Sicherheit aus, denn ein Client kann dann problemlos OHNE jede FW Zugriffsbeschränkung über die HPs in andere VLANs routen.
Wenn du das also nicht willst: WEG mit den IPs auf den beiden Switches 1 und 2.
Einzig nur die IP im Default VLAN 1 sollte und muss bleiben damit du den Switch managen kannst !
Soll nur zwischen Voice 112 und VLAN 1 geroutet werden auf den Switches, entfernst du einfach die IP nur im Data VLAN. Alles darus muss dann über die FW routen da es nichts anderes gibt...logisch.
Regel: Alles was zwingend über die FW geroutet werden soll oder muss darf NICHT eine IP auf den beiden Switches bekommen !
Achtung: Routen die Switches oder routen sie einen Teil der VLANs dann müssen sie beide eine Default Route auf Router oder Firewall bekommen je nachdem wer im lokalen Netzwerk bei dir das zentrale Routing macht zw. den VLAN bzw. IP Segmenten und ins Internet.
Hier musst du dich also entscheiden...
Wenn das alles sicher geklärt und angepasst ist in der Konfig, ist soweit alles sauber in der Switch Konfig 1 und 2.
Folgende Tests müssen dann klappen:
- Ping von Clients im VLAN 1 untereinander egal wo sie angeschlossen sind 2810 oder 1810
- Ping von einem Client in VLAN 1 an die HP IP 192.168.100.1 und .2
- Ping von einem Client in VLAN 1 an Firewall IP sofern dort Ping (ICMP) erlaubt ist !
- Ping von Clients im "Data" VLAN 111 an den 2810ern und zur Firewall
- Ping von Clients im "Voice" VLAN 112 untereinander und zu beiden HP IPs.
Nein, RSTP native können die Switches nicht. Die arbeiten immer fest auf MSTP...siehe Handbuch !
MSTP kann aber im STP oder RSTP Modus laufen. Das kannst du mit dem "force" Kommando erzwingen. RSTP ist natürlich hier erste Wahl, was du ja auch gemacht hast.
Aber egal... es sieht ja jetzt genau so aus wie es soll und funktioniert auch sauber !! Genau das wollten wir !
Port 24 STP Problem:
Das ist ein erwartetes Verhalten...leider, weil die sch... 1810er das Grundübel sind.
Die beidbeinige Verbindung über die 1810er ist ja aus STP Sicht quasi inexistent weil die 1810er ja kein STP unterstützen und das wie bei einem direkten Draht nur "durchschleifen". Aus STP Sicht ist das also quasi ein paralleles Kabel zum Port 24 wo du den Port 1 von Switch 1 mit dem Port 1 von Switch 2 direkt verbindest. Den 1810 dazwischen "sieht" STP nicht.
Da der SW1 Root ist und SW2 Backup Root ist der Port 24 am SW2 der Port, der "am weitesten weg" ist vom Root Switch und folglich hat der die schlechteste Cost und geht damit in Blocking Mode. "Works as designed" also.
Nicht gut, zeigt aber das generell das STP sauber rennt.
Man bekommt das aber ganz einfach mit entspr. Konfig gefixt:
Du konfigurierst einfach eine bessere Path Cost auf dem Port 24:
spanning-tree <port-list> path-cost xyz
Also final spanning-tree eth24 path-cost 10000 was du auf beiden Seiten also SW1 und SW2 konfigurierst sollte das Problem fixen.
ftp://ftp-boi.external.hp.com/pub/networking/software/2810-AdvTrafficMgmt-July2007-59914733.pdf Seite 5-24
Damit gaukelst du eine bessere Leitung vor und wenn du nun die Backup Links der 1810er aufsteckst sollten diese am SW2 in den Blocking Mode gehen.
Soviel zum Thema 1810er Schrottswitches....
Gut das es Workarounds gibt um diesen Mist wenigstens halbwegs zu integrieren...
MSTP kann aber im STP oder RSTP Modus laufen. Das kannst du mit dem "force" Kommando erzwingen. RSTP ist natürlich hier erste Wahl, was du ja auch gemacht hast.
Aber egal... es sieht ja jetzt genau so aus wie es soll und funktioniert auch sauber !! Genau das wollten wir !
Port 24 STP Problem:
Das ist ein erwartetes Verhalten...leider, weil die sch... 1810er das Grundübel sind.
Die beidbeinige Verbindung über die 1810er ist ja aus STP Sicht quasi inexistent weil die 1810er ja kein STP unterstützen und das wie bei einem direkten Draht nur "durchschleifen". Aus STP Sicht ist das also quasi ein paralleles Kabel zum Port 24 wo du den Port 1 von Switch 1 mit dem Port 1 von Switch 2 direkt verbindest. Den 1810 dazwischen "sieht" STP nicht.
Da der SW1 Root ist und SW2 Backup Root ist der Port 24 am SW2 der Port, der "am weitesten weg" ist vom Root Switch und folglich hat der die schlechteste Cost und geht damit in Blocking Mode. "Works as designed" also.
Nicht gut, zeigt aber das generell das STP sauber rennt.
Man bekommt das aber ganz einfach mit entspr. Konfig gefixt:
Du konfigurierst einfach eine bessere Path Cost auf dem Port 24:
spanning-tree <port-list> path-cost xyz
Also final spanning-tree eth24 path-cost 10000 was du auf beiden Seiten also SW1 und SW2 konfigurierst sollte das Problem fixen.
ftp://ftp-boi.external.hp.com/pub/networking/software/2810-AdvTrafficMgmt-July2007-59914733.pdf Seite 5-24
Damit gaukelst du eine bessere Leitung vor und wenn du nun die Backup Links der 1810er aufsteckst sollten diese am SW2 in den Blocking Mode gehen.
Soviel zum Thema 1810er Schrottswitches....
Gut das es Workarounds gibt um diesen Mist wenigstens halbwegs zu integrieren...
Eins steht ja noch aus damits perfekt wird....!!!
Ggf. jetzt nochmal den Trunk testen zw. SW1 und SW2 zur Bandbreitenerhöhung zw. den Switches
!!!
Also an Port 25 (wenn der frei ist) genau die gleichen Konfigs machen in den VLANs wie an 24 an beiden 2810 Switches.
Dann...
ProCurve(config)# interface 24-25 lacp active
eingeben auf beiden Switches und eine Strippe ziehen zwischen beiden auf Port 25 genau wie 24.
Und.... vergiss die Spanning Tree Cost 10000 nicht für den 2ten LACP Trunk Link !!! Dieser muss vollkommen identisch sein zu dem von Port 24 !!!
Fertisch....
Dann checken mit show lacp oder show trunk ob sich der 2er Trunk sauber gebildet hat.
Und das nächste Mal kaufst du hoffentlich KEINE schrottigen 1810er mehr für so ein Design !!!
Wenn der Trunk dann auch noch rennt Zeit also den "Monsterthread" hier langsam zu schliessen
Wie kann ich einen Beitrag als gelöst markieren?
Und....
zu guter Letzt solltest du eigentlich dem "zwichen" oben in der Überschrift noch final ein "s" gönnen. Verdient hat es das !!
(Geht mit Klick auf "Bearbeiten")
Ggf. jetzt nochmal den Trunk testen zw. SW1 und SW2 zur Bandbreitenerhöhung zw. den Switches
!!!
Also an Port 25 (wenn der frei ist) genau die gleichen Konfigs machen in den VLANs wie an 24 an beiden 2810 Switches.
Dann...
ProCurve(config)# interface 24-25 lacp active
eingeben auf beiden Switches und eine Strippe ziehen zwischen beiden auf Port 25 genau wie 24.
Und.... vergiss die Spanning Tree Cost 10000 nicht für den 2ten LACP Trunk Link !!! Dieser muss vollkommen identisch sein zu dem von Port 24 !!!
Fertisch....
Dann checken mit show lacp oder show trunk ob sich der 2er Trunk sauber gebildet hat.
Und das nächste Mal kaufst du hoffentlich KEINE schrottigen 1810er mehr für so ein Design !!!
Wenn der Trunk dann auch noch rennt Zeit also den "Monsterthread" hier langsam zu schliessen
Wie kann ich einen Beitrag als gelöst markieren?
Und....
zu guter Letzt solltest du eigentlich dem "zwichen" oben in der Überschrift noch final ein "s" gönnen. Verdient hat es das !!
(Geht mit Klick auf "Bearbeiten")
Der "IT Manager" sollte wirklich nochmal auf die Manager Schule und lernen was IT ist...
Tip zum LAG: Nimm besser zusammenhängende Ports ! Das ist vom Management einfacher und manche Billig HW supportet auseinanderliegende Ports im LAG nicht. Um dem bei HP gleich vorzubeugen solltest du ggf. den Port 23 "umlegen" auf Port 20 und den LAG dann mit 23 und 24 machen.
OK, dann harren wir mal auf die nächste Woche und den LAG Test...es bleibt also noch etwas spannend hier
Tip zum LAG: Nimm besser zusammenhängende Ports ! Das ist vom Management einfacher und manche Billig HW supportet auseinanderliegende Ports im LAG nicht. Um dem bei HP gleich vorzubeugen solltest du ggf. den Port 23 "umlegen" auf Port 20 und den LAG dann mit 23 und 24 machen.
OK, dann harren wir mal auf die nächste Woche und den LAG Test...es bleibt also noch etwas spannend hier