3750er
Goto Top

Frage zur Konfiguration von Switchen zur Vermeidung eines Loops bei redundanter Anbindung

Hallo,

unsere Netzwerk (Access-)Infrastruktur besteht aus Cisco 3750, Cisco 3750G und Cisco 3560 Switchen.

Wenn mehrere Cisco 3750 bzw. Cisco 3750G zum Einsatz kommen sind diese gestackt. Kommen Cisco 3560 und Cisco 3750 zum Einsatz sind diese mit LWL (über SFPs) verbunden.

Wir haben also beispielsweise folgende Konstellation:

1. Untergeschoss (Technik-/Serverraum):
WAN-Anbindung über 2 Router (wg. Backup / HSRP; vom WAN-Provider gemanaged)
1x Cisco 3560
3x Cisco 3750 (Stack)
Verbindung untereinander: Cisco 3560 Gi 0/1 an Cisco 3750 Gi 1/0/2 und Cisco 3560 Gi 0/2 an Cisco 3750 Gi 2/0/1 (Etherchannel)
Router 1 hängt an Cisco 3750 FA 1/0/1
Router 2 hängt an Cisco 3750 FA 2/0/1

Erdgeschoss (Verteilerschrank):
3x Cisco 3750 (Stack)

1. Obergeschoss (Verteilerschrank):
2x Cisco 3750 (Stack)


Die Verbindungen zwischen den Stockwerken werden per LWL (jeweils über SFPs) hergestellt. Es bestehen folgende Verbindungen:

1. Untergeschoss nach Erdgeschoss
Cisco 3750 (1. Untergeschoss) Gi 1/0/1 nach Cisco 3750 (Erdgeschoss) Gi 1/0/1

Erdgeschoss nach 1. Obergeschoss
Cisco 3750 (Erdgeschoss) Gi 3/0/2 nach Cisco 3750 (1. Obergeschoss) Gi 1/0/1

1. Obergeschoss nach 1. Untergeschoss
Cisco 3750 (1. Obergeschoss) Gi 2/0/2 nach Cisco 3750 (1. Untergeschoss) Gi 2/0/2


Wir bilden also über die LWL-Strecken einen "Ring" wegen der Redundanz.


Es kommen 2 VLANs zum Einsatz:
VLAN 1 = default = "normales Netz"
VLAN 99 = separates DSL-Netzwerk
Die VTP-Domäne ist auf den Standort begrenzt. VTP-Server ist der Cisco 3750 Stack im 1. Untergeschoss, alle anderen sind VTP-Clienten.


Auf allen Switchports haben wir als Spanning-Tree folgende Konfiguration:

spanning-tree mode pvst
spanning-tree loopguard default
spanning-tree logging
spanning-tree portfast default
spanning-tree portfast bpduguard default
spanning-tree extend system-id

errdisable recovery cause bpduguard
errdisable recovery cause loopback


die LWL-Uplink-Interfaces haben deshalb folgende Konfiguration:

switchport trunk encapsulation dot1q
switchport mode trunk
spanning-tree portfast disable


So.... nun meine eigentlichen Fragen.....

Wäre es sinnvoll die Anschlüsse der beiden Backup-Router ebenfalls in einem Etherchannel zu bündeln (auch wenn theoretisch immer nur ein Router aktiv ist?)?
Spanning-Tree soll mir (selbständig) einen Loop vermeiden (die LWL-Strecken im "Ring").... gab es bei Euch mit sowas schonmal Probleme?
Was sollten / können wir bei den Switchen noch konfigurieren? Was macht Sinn? Was macht keinen Sinn?

Bin im Switching-Thema relativ neu und möchte mir auf diese Weise noch einige Tipps und Kniffe holen!!

Danke & Gruß
Ralf

30ff5af29f94be4cadf7c7d40d5df6b0

Content-Key: 132487

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

Ausgedruckt am: 29.03.2024 um 05:03 Uhr

Mitglied: aqui
aqui 30.12.2009, aktualisiert am 20.11.2023 um 16:21:09 Uhr
Goto Top
Vorweg erstmal ist das ein klassisches Allerwelts Netzwerkdesign an dem es nichts auszusetzen gibt ! Ein groben Fehler hast du im Spanning Tree...ggf. aber nur im Thread nicht erwähnt...Unten dazu mehr..
Zu deinen Fragen:
"...Wäre es sinnvoll die Anschlüsse der beiden Backup-Router ebenfalls in einem Etherchannel zu bündeln ?"
A.: Nein, das macht keinen Sinn, jedenfalls dann nicht wenn die WAN Geschwindigkeit nicht höher ist als die LAN Anbindung der Router !!
Etherchannel oder Trunking ist kein Redundanz Mechanismus sondern dient zur Erhöhung der Bandbreite. Da du aber schon HSRP zur Redundanz einsetzt ist das allso nicht unbedingt sinnvoll !

"...Spanning-Tree soll mir selbständig einen Loop vermeiden "
A.: Ja, das ist logisch und ja auch der tiefere Sinn von Spanning Tree. Hier ist vermutlich auch einer deiner kosmetischen Konfig Fehler. Generell ist deine RSTP Konfig richtig da gibts nichts zu meckern.
Einen sehr wichtigen Aspekt bei STP hast du aber unterschlagen:
Beim Spanning Tree solltest du zwingend immer die Rootbridge vorgeben denn sonst kaspern sich die Switches die Rootbridge selber aus und das kann dann im Zweifelsfall einer der Edge Switches sein mit fatalen Folgen für die Performance im Netz !
Dein zentraler (Core) Switch ist der Stack im 1. Untergeschoss und dieser sollte somit auch die Rootbridge im RSTP darstellen. Um das sicherzustellen vergibst du ihm einfach eine simple Priority. Per Default ist die Bridge Priority bei allen Switches im RSTP grundsätzlich auf den Wert 32768 (hex 0x8000) gesetzt !
Priority Werte sind durch die Bridge ID prinzipbedingt immer Vielfache von 4096.

Aufbau der Bridge ID:
Der Default Prio Wert von 32768 ist Standard ! (Alle oberen 4 Bits der Bridge ID gesetzt. 0 ist verboten!)
bridgeid.

Ein kleinerer Wert erhöht die Priority. Wenn du also dem Stack im 1. Untergeschoss die RSTP Priority 4096 konfigurierst ist dieser Switch immer Rootswitch und dein "Ring" damit logischerweise kein Ring, denn sowas gibt es im Ethernet nicht !
Die Rootbridge sorgt dann dafür das die am weitesten entfernten und mit der niedrigsten Cost versehen Links in den Blocking Modus gehen und dein Ethernet damit loopfrei halten.
Das ist ein ganz klassisches Verfahren in jedem Netz und damit gibt es keinerlei Probleme !!!

"...Was sollten / können wir bei den Switchen noch konfigurieren?"
A.: Mmmmhhh, das kommt drauf an was für DICH denn sinnvoll ist ??
Generell gilt immer als goldener Design Grundsatz das man keinen Produktiv Traffic im Default VLAN 1 haben sollte sondern dafür immer separate VLANs nehmen sollte aus Sicherheitsgründen. Das VLAN 1 sollte rein fürs Management der Switches und Netzkomponenten im Allgemeinen dienen ! Ggf. berücksichtigst du das noch in deiner Konfig !
Der Rest ist mehr oder minder kosmetisch wie...
Die korrekte Uhrzeit fürs Log mit:
service timestamps debug datetime localtime
service timestamps log datetime localtime
clock timezone MET 1
clock summer-time MEST recurring last Sun Mar 2:00 last Sun Oct 3:00

Korrekte Port Bezeichnungen für die Uplinks und Server / Router etc. mit description <name>
Passwörter um den Zugriff zu verhindern.
Ggf. einen SNMP Trapserver oder Log Server um Systemmeldungen mitschneiden zu können bei Fehlern
einen Name Server bzw. SNMP Server
Das sind aber mehr oder weniger alles kosmetische Dinge mit Ausnahme des VLAN Designs oben die dir das Mangement erleichtern und sind nicht zwingend erforderlich.
Generell hast du schon bis auf die RSTP Priority alles korrekt berücksichtigt !!
Mitglied: 3750er
3750er 30.12.2009 um 12:15:48 Uhr
Goto Top
Hallo aqui,

vielen Dank für Deine super schnelle und ausführliche Antwort!!

Das mit der Rootbridge im STP werde ich mir zu Herzen nehmen und auf unseren einzelnen Standorten statisch vorgeben! - Muss mir irgendwie seit meiner Cisco Schulung entfallen sein *schäm* face-wink

Vielleicht wurde es dort aber auch einfach nicht erwähnt, denn das mit dem "kein Produktiv-Traffic im VLAN 1" wurde dort definitiv nicht erwähnt face-sad Klingt aber absolut logisch und ist nachvollziehbar. Leider werde ich es nicht (so ohne weiteres bzw. so schnell) schaffen das ganze bei uns umzustellen..... 60 Standorte / 150-200 Switche.... alles produktiv face-wink

Die Timestamps habe ich analog zu Deinem Tipp bei uns bereits aktiv, ebenso die Zeitzoneneinstellungen. Benutzername + Passwort werden zur Authentifizierung benötigt, Radius ist (derzeit) nicht im Einsatz. Trap- und Logserver sollen in Form von Nagios im nächsten Jahr folgen. Die Descriptions bin ich nach und nach am Pflegen....... ("gewachsene Strukturen") face-wink

Ist leider nicht immer einfach wenn man eine "neue Aufgabe" übernimmt und intern keinen zum Fragen hat. Also nochmal herzlichen Dank für Deine Hilfe!!

Gruß
Ralf
Mitglied: aqui
aqui 30.12.2009, aktualisiert am 20.11.2023 um 16:19:31 Uhr
Goto Top
Die Lehrer bei Schulungen sind meist reine Theoretiker die oft keinen oder sehr wenig Bezug zur Praxis haben und auch die Hardware intern nicht kennen, deshalb werden solche Basiscs meistens nicht erwähnt...leider.
Um ganz sicher zu gehen kannst du die Root Bridge Priority übrigens auf 4096 setzen, denn dann kann kein anderer Switch sie unterbieten und du erzwingst damit die Root Bridge Selection.
⚠️ Der Prioritywert "0" ist nicht supportet!

Wenns das denn war bitte
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !
Mitglied: 3750er
3750er 30.12.2009 um 12:49:02 Uhr
Goto Top
Jepp, ich glaube das sollte es gewesen sein face-wink

DANKE!!

Gruß
Ralf