7
Ab wann lohnt sich MSTP gegenüber PVST
Ich bin zurzeit dabei das Netzwerk meines OSZs zu optimieren. Dort wird über Performanceprobleme geklagt und nach einem Blick in die Coreswitche (4506 und 4507) konnte ich mir denken wo das Problem liegt:
Das HSRP wurde so konfiguriert, dass über 90% der Vlans über einen Switch laufen, zudem ist dieser Switch auch Root für so gut wie alle Vlans.
Meine Idee zur optimierung wäre jetzt, als allererstes die Last auf beide Switche zu verteilen und anschließend MSTP zu integrieren! Ich gehe davon aus, dass mit nur noch 2 Instancen des Spanning Tree die Performance erheblich steigt.
Bis jetzt läuft PVST+. Meine Frage an euch wäre, ob und wieviel sich die Performance steigern wird wenn alles korrekt implementiert wurde?
Habe ich etwas übersehen oder einen Gedankenfehler?
(Die Topologie sieht so aus, dass die Coreswitche = Distributionswitche sind und es quasi nur einen Accesslayer und eine Provideredge gibt.)
Viele Grüße
Das HSRP wurde so konfiguriert, dass über 90% der Vlans über einen Switch laufen, zudem ist dieser Switch auch Root für so gut wie alle Vlans.
Meine Idee zur optimierung wäre jetzt, als allererstes die Last auf beide Switche zu verteilen und anschließend MSTP zu integrieren! Ich gehe davon aus, dass mit nur noch 2 Instancen des Spanning Tree die Performance erheblich steigt.
Bis jetzt läuft PVST+. Meine Frage an euch wäre, ob und wieviel sich die Performance steigern wird wenn alles korrekt implementiert wurde?
Habe ich etwas übersehen oder einen Gedankenfehler?
(Die Topologie sieht so aus, dass die Coreswitche = Distributionswitche sind und es quasi nur einen Accesslayer und eine Provideredge gibt.)
Viele Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 190348
Url: https://administrator.de/contentid/190348
Printed on: April 19, 2024 at 05:04 o'clock
7 Comments
Latest comment
Operative Such Zentrale oder was ist OSZ ? ...aber egal, kommen wir mal zum Thema....
Ob du einen Gedankenfehler machst oder nicht ist schwer zu sagen. Nach dem WIE zu urteilen, wie du diese Fragestellung angehst, ist aber davon auszugehen.
Erstmal muss man festhalten das Spanning Tree per se einmal rein gar nichts mit der Performance eines Switches zu tun hat oder nur ganz am Rande !!
Es dient lediglich dazu Loops in einem Netzwerk zu verhindern, nicht mehr und nicht weniger. Hier machst du also schon einen gehörigen Denkfehler.
MSTP und PVSTP+ benutzen lediglich andere BPDU Multicast Mac Adressen. Eine Frage ob das eine oder andere nun sinnvoll ist, ist also eher eine kosmetische oder eine philosophische Frage aber keine technische.
Das 90% des Traffics über den Primary Switch rennt, der vermutlich (R)STP Root Switch und auch Primary Switch im HSRP ist, ist also mehr oder weniger normal und üblich bei einer einfachen Standard Konfiguration ohne per VLAN Priority Steuerung in der STP Priority.
Ob damit die Performance schlecht ist kann man aufgrund deiner doch recht oberflächlichen Schilderung hier von extern nicht wirklich beurteilen.
Du hast es ja noch nicht einmal geschafft ein show cpu oder show proc cpu hier zu posten um mal die CPU Belastung des/der Switches zu beurteilen.
Ein weiterer sehr wichtiger Aspekt wäre einmal ein "show interface" der Uplink Interfaces zum Access zu machen !
Hier kannst du sofort die kurz- und langfristige Auslastung dieser Links sehen. Solange die Durchsnittslast dort pro Link unter 50% liegt wäre keinerlei Performance Engpass vorhanden !
Zu all diesen grundlegenden Daten, die ein kundiger Netzwerker kennen sollte, machst du hier aber keinerlei sachliche Angaben die eine saubere Beurteilung zulassen.
Es hört sich so an als ob du im freien Fall einfach mal ein bischen ins Blaue schiesst mit technischen Halbwahrheiten. Was erwartest du nun von uns was wir dir raten sollen ??
Ob das der richtige Weg ist eine Optimierung deines Netzwerk Designs hinzubekommen kannst du selbst besser beurteilen als das Forum hier.
Ob du einen Gedankenfehler machst oder nicht ist schwer zu sagen. Nach dem WIE zu urteilen, wie du diese Fragestellung angehst, ist aber davon auszugehen.
Erstmal muss man festhalten das Spanning Tree per se einmal rein gar nichts mit der Performance eines Switches zu tun hat oder nur ganz am Rande !!
Es dient lediglich dazu Loops in einem Netzwerk zu verhindern, nicht mehr und nicht weniger. Hier machst du also schon einen gehörigen Denkfehler.
MSTP und PVSTP+ benutzen lediglich andere BPDU Multicast Mac Adressen. Eine Frage ob das eine oder andere nun sinnvoll ist, ist also eher eine kosmetische oder eine philosophische Frage aber keine technische.
Das 90% des Traffics über den Primary Switch rennt, der vermutlich (R)STP Root Switch und auch Primary Switch im HSRP ist, ist also mehr oder weniger normal und üblich bei einer einfachen Standard Konfiguration ohne per VLAN Priority Steuerung in der STP Priority.
Ob damit die Performance schlecht ist kann man aufgrund deiner doch recht oberflächlichen Schilderung hier von extern nicht wirklich beurteilen.
Du hast es ja noch nicht einmal geschafft ein show cpu oder show proc cpu hier zu posten um mal die CPU Belastung des/der Switches zu beurteilen.
Ein weiterer sehr wichtiger Aspekt wäre einmal ein "show interface" der Uplink Interfaces zum Access zu machen !
Hier kannst du sofort die kurz- und langfristige Auslastung dieser Links sehen. Solange die Durchsnittslast dort pro Link unter 50% liegt wäre keinerlei Performance Engpass vorhanden !
Zu all diesen grundlegenden Daten, die ein kundiger Netzwerker kennen sollte, machst du hier aber keinerlei sachliche Angaben die eine saubere Beurteilung zulassen.
Es hört sich so an als ob du im freien Fall einfach mal ein bischen ins Blaue schiesst mit technischen Halbwahrheiten. Was erwartest du nun von uns was wir dir raten sollen ??
Ob das der richtige Weg ist eine Optimierung deines Netzwerk Designs hinzubekommen kannst du selbst besser beurteilen als das Forum hier.
Hallo und danke erstmal für deine Antwort.
Ich denke ich habe meine Frage nicht präzise genug ausgedrückt.
Es geht hier hauptsächlich um die Fragestellung ob die Verwendung von MSTP bei 80-90 Vlans schon eine Performancesteigerung hervorruft, daher habe ich keinen weiteren Bezug auf die show-Befehle genommen.
Aber trotzdem möchte ich mich für eventuell fehlende Informationen entschuldigen, ich bin zum ersten noch in der Ausbildung und zum zweiten bewege ich mich hier zum ersten mal in "freier Wildbahn" und nicht in einer Laborumgebung.
Ich bin dabei den CCNP zu machen (Selbststudium 2/3 Modulen vorhanden) und kenne vieles was nicht in den Büchern steht nicht.
Und Spanningtree hat meines erachtens sehr wohl was mit Performance zu tun, pvst+ hat in diesem Fall über 80 Instancen welche jede einzeln im Speicher sitzt und eigene BPDUs versendet und entsprechend auch CPU-resourcen verbraucht. Mit MSTP wären es nur 2 BPDUs und 2 Instanzen.
In den Cisco-Büchern wurde beschrieben, dass genau aus diesem Grund (Performance und Bandbreite) dieses Protokoll entwickelt wurde, was sich auch aus anderen quellen bestätigen lässt.
Dass dieses Design mit der vollen Last auf dem Primär-Switch üblich ist wusste ich nicht, trotzdem finde ich es effektiver die Lasten zu verteilen.
ps:OSZ -> Oberstufenzentrum (google).
Ich denke ich habe meine Frage nicht präzise genug ausgedrückt.
Es geht hier hauptsächlich um die Fragestellung ob die Verwendung von MSTP bei 80-90 Vlans schon eine Performancesteigerung hervorruft, daher habe ich keinen weiteren Bezug auf die show-Befehle genommen.
Aber trotzdem möchte ich mich für eventuell fehlende Informationen entschuldigen, ich bin zum ersten noch in der Ausbildung und zum zweiten bewege ich mich hier zum ersten mal in "freier Wildbahn" und nicht in einer Laborumgebung.
Ich bin dabei den CCNP zu machen (Selbststudium 2/3 Modulen vorhanden) und kenne vieles was nicht in den Büchern steht nicht.
Und Spanningtree hat meines erachtens sehr wohl was mit Performance zu tun, pvst+ hat in diesem Fall über 80 Instancen welche jede einzeln im Speicher sitzt und eigene BPDUs versendet und entsprechend auch CPU-resourcen verbraucht. Mit MSTP wären es nur 2 BPDUs und 2 Instanzen.
In den Cisco-Büchern wurde beschrieben, dass genau aus diesem Grund (Performance und Bandbreite) dieses Protokoll entwickelt wurde, was sich auch aus anderen quellen bestätigen lässt.
Dass dieses Design mit der vollen Last auf dem Primär-Switch üblich ist wusste ich nicht, trotzdem finde ich es effektiver die Lasten zu verteilen.
ps:OSZ -> Oberstufenzentrum (google).
OK, mit einigen Ausführen hast du zum Teil Recht. Hast du in deinen Büchern denn wenigstens mal gelesen WO der Unterschied zwischen MSTP und PVSTP+ in puncto Performance denn technisch genau liegt ?
MSTP hat ebenso einzelne Instanzen wie PVSTP+. (Konfig Kommando heisst auch "Instances"). D.h. vom Aufbau sind die STP Protokolle gleich und verbrauchen genaus so viele Resourcen. MSTP sogar noch etwas mehr, da es auf RSTP basiert und eine Forwarding Datenbank unterhalten muss aber das weisst du ja als angehender CCNA sicher auch selber.
Gut, man kann mehrere VLANs (auch mehr als 2) zu einer MSTP Instanz zusammenziehen, was die Anzahl der BPDU Generierung verringert, das hat aber wieder den Nachteil das du entscheiden musst WEN du zusammenlegst. Der Nachteil ist wenn es in einer MSTP Instanz im STP "rumpelt" werden alle anderen VLANs auch in Mitleidenschaft gezogen, deshalb ist MSTP nicht immer sinnvoll und PVRSTP vorzuziehen.
Allerdings sind die STP Unterschiede eher kosmetisch als das sie ins Gewicht fallen würden. Du schiesst hier eher mit Kanonen auf Spatzen. Was sagt denn ein "show proc cpu" auf deinem Switch, da kannst du den Performanceanteil an der Gesamtperformance doch ablesen. Das dürfte auch bei 80 VLANs nicht über 3 bis 5% liegen also lächerlich. An der Forwarding Rate und Speed des Switches ändert das gar nix nur wenn du das STP Protokoll änderst.
Orientier dich also mal an der Realität !
Das das die Port Bandbreite ändern oder beeinflussen soll ist totaler Quatsch. Die Passage im Cisco Buch musst du uns dann mal zeigen hier... Und das ein BPDU Frame alle 3 Sekunden merklichen Einfluss auf eine Port Performance hat gehört wohl auch eher ins Reich der Märchen.
PVSTP gab es lange vor MSTP und MSTP ist nicht aus Performance entwickelt worden, das ist Unsinn, sondern als kleinstes gemeinsames Vielfaches in Besug auf einen weltweiten PVST Standard, denn für Ciscos PVSTP+ Implementation und die der anderen Premium Hersteller gibt es keinen Standard, die sind proprietär also inoperabel mit anderen Herstellern. Damit man also Billiggurken von HP an solche Netze bekommt muss man entweder zur Steinzeit des STP zurückkehren in der Konfig mit Single Span oder kann als Kompromiss zu einem VLAN STP Verfahren MSTP nehmen in heterogenen Netzen oder eben nur passic durchschleifen wenn man auf PVSTP nicht verzichten will. So ist die Geschichte richtig...
Cisco selber hat PVSTP+ als Default laufen auf allen seinen Produkten. Vielleicht fragst du dich als CCNA in spe mal warum ?!
Die STP Priority Verteilung der VLANs kann Sinn machen wenn man überlastete Uplinks hat. Das wäre ein gangbarer Weg um eine sinnvolle Traffic Verteilung zu machen. Übrigens ist das ganz unabhängig vom verwendeten STP Protokoll.
Deshalb ja auch der Tip oben VORHER einmal auf den Uplink Interfaces nachzusehen wie dort die Traffic Auslastung ist.
Ein simples show interface sagt dir das sofort oder, wenn du eine längere Betrachtung machen willst, mit einem kleinen grafischen SNMP Tool wie STG z.B.:
http://leonidvm.chat.ru/
Übrigens zeigt das o.a. Tool auch die Switch Performance an die man via SNMP rauslesen kann.
Damit hat man die Auslastung schwarz auf weiss und kann sich an Fakten halten statt in die STP Kristallkugel zu sehen ! Lernt man das nicht auch so als CCNA ??
Mit dem STP Balancing lauert aber der Teufel im Detail. Du musst zwingend aufpassen wie die STP Priority pro VLAN zur VRRP/HSRP Switch Priority steht.
Bei Layer 3 Traffic kannst du unterschiedliche Routing Wege haben so das hin was über Switch 1 geht und zurück über Switch 2. Das ist generell kein Problem bei TCP/IP aber manche Applikationen mögen das nicht so gerne speziell solche auf UDP Basis die laufzeitkritisch sind.
Also wenn man das VLAN Load Balancing über STP Priorität anfasst dann genau hinsehen für den Layer 3 Traffic zwischen den VLANs. Das erspart späteren Frust.
MSTP hat ebenso einzelne Instanzen wie PVSTP+. (Konfig Kommando heisst auch "Instances"). D.h. vom Aufbau sind die STP Protokolle gleich und verbrauchen genaus so viele Resourcen. MSTP sogar noch etwas mehr, da es auf RSTP basiert und eine Forwarding Datenbank unterhalten muss aber das weisst du ja als angehender CCNA sicher auch selber.
Gut, man kann mehrere VLANs (auch mehr als 2) zu einer MSTP Instanz zusammenziehen, was die Anzahl der BPDU Generierung verringert, das hat aber wieder den Nachteil das du entscheiden musst WEN du zusammenlegst. Der Nachteil ist wenn es in einer MSTP Instanz im STP "rumpelt" werden alle anderen VLANs auch in Mitleidenschaft gezogen, deshalb ist MSTP nicht immer sinnvoll und PVRSTP vorzuziehen.
Allerdings sind die STP Unterschiede eher kosmetisch als das sie ins Gewicht fallen würden. Du schiesst hier eher mit Kanonen auf Spatzen. Was sagt denn ein "show proc cpu" auf deinem Switch, da kannst du den Performanceanteil an der Gesamtperformance doch ablesen. Das dürfte auch bei 80 VLANs nicht über 3 bis 5% liegen also lächerlich. An der Forwarding Rate und Speed des Switches ändert das gar nix nur wenn du das STP Protokoll änderst.
Orientier dich also mal an der Realität !
Das das die Port Bandbreite ändern oder beeinflussen soll ist totaler Quatsch. Die Passage im Cisco Buch musst du uns dann mal zeigen hier... Und das ein BPDU Frame alle 3 Sekunden merklichen Einfluss auf eine Port Performance hat gehört wohl auch eher ins Reich der Märchen.
PVSTP gab es lange vor MSTP und MSTP ist nicht aus Performance entwickelt worden, das ist Unsinn, sondern als kleinstes gemeinsames Vielfaches in Besug auf einen weltweiten PVST Standard, denn für Ciscos PVSTP+ Implementation und die der anderen Premium Hersteller gibt es keinen Standard, die sind proprietär also inoperabel mit anderen Herstellern. Damit man also Billiggurken von HP an solche Netze bekommt muss man entweder zur Steinzeit des STP zurückkehren in der Konfig mit Single Span oder kann als Kompromiss zu einem VLAN STP Verfahren MSTP nehmen in heterogenen Netzen oder eben nur passic durchschleifen wenn man auf PVSTP nicht verzichten will. So ist die Geschichte richtig...
Cisco selber hat PVSTP+ als Default laufen auf allen seinen Produkten. Vielleicht fragst du dich als CCNA in spe mal warum ?!
Die STP Priority Verteilung der VLANs kann Sinn machen wenn man überlastete Uplinks hat. Das wäre ein gangbarer Weg um eine sinnvolle Traffic Verteilung zu machen. Übrigens ist das ganz unabhängig vom verwendeten STP Protokoll.
Deshalb ja auch der Tip oben VORHER einmal auf den Uplink Interfaces nachzusehen wie dort die Traffic Auslastung ist.
Ein simples show interface sagt dir das sofort oder, wenn du eine längere Betrachtung machen willst, mit einem kleinen grafischen SNMP Tool wie STG z.B.:
http://leonidvm.chat.ru/
Übrigens zeigt das o.a. Tool auch die Switch Performance an die man via SNMP rauslesen kann.
Damit hat man die Auslastung schwarz auf weiss und kann sich an Fakten halten statt in die STP Kristallkugel zu sehen ! Lernt man das nicht auch so als CCNA ??
Mit dem STP Balancing lauert aber der Teufel im Detail. Du musst zwingend aufpassen wie die STP Priority pro VLAN zur VRRP/HSRP Switch Priority steht.
Bei Layer 3 Traffic kannst du unterschiedliche Routing Wege haben so das hin was über Switch 1 geht und zurück über Switch 2. Das ist generell kein Problem bei TCP/IP aber manche Applikationen mögen das nicht so gerne speziell solche auf UDP Basis die laufzeitkritisch sind.
Also wenn man das VLAN Load Balancing über STP Priorität anfasst dann genau hinsehen für den Layer 3 Traffic zwischen den VLANs. Das erspart späteren Frust.
Guten Abend,
einerseits hast du gute Tipps im Schlepptau, andererseits machst du mich hier total nieder.
Aber gut ich arbeite mal eins nach dem anderem ab:
Die Unterschiede kann man natürlich bis ins kleinste Detail ausarbeiten, aber mir reicht die arbeitsweise von MSTP, welche in diesem Fall das Bündeln der Vlans ist, welches ich brauche um Instanzen/ CPU-Leistung zu sparen.
Selbstverständlich hat MSTP mehrere Instanzen, soll es ja auch um die Lasten zu verteilen, sonst würde mir das CSTP ausreichen. Aber MSTP hat halt nur 2 oder 4 Instanzen statt 80 und sendet halt nur 2 oder 4 BDPUs und hat auch nur 4 Spanningtree Instanzen die (ich vermute mal) leichter zu Troubleshooten sind da es übersichtlicher ist.
Ich mache nicht den CCNA sondenr den CCNP und im CCNA wird nur das Grundprinziep von STP gelehrt und im CCNP wird auch nicht so sehr ins Detail gegangen, ich denke sowas wird in den Design- oder CCIE-Zertifikaten behandelt.
Die Problemstellung wen ich mit wen zusammenlege ging mir auch schon durch den kopf, ist aber in diesem Mittelgroßen Netz noch übersichtlich. Dass es bei STP-Problemen mehrere Vlans betrifft habe ich garnicht bedacht, das ist ein echt guter Hinweis, ich würde dann wohl mehr als 2 Instanzen verwenden (4 oder 8) wenn ich denn MSTP implemetieren sollte.
Das ich da mit Kanonen auf Spatzen schieße war genau dass was ich hören wollte, denn das war eigentlich meine (vielleicht unglücklich ausgedrückte) Frage. Die CPU-Last sah im laufenden Betrieb soweit ganz gut aus, allerdings konnte man in der History vernehmen, dass die Last teilweise bei 100% lag und ich bzw. meine Lehrer zu diesen Zeiten nicht an den Geräten sind/waren/sein werden um zu prüfen welcher Prozess da solch ein peak auslöst. Der Nagios-Zuständige hat permanent Termindruck und ist vorerst nicht ansprechbar, allerdings muss ich zugeben, dass ich bei meinem ersten Troubleshooting auch garnicht daran gedacht habe und dass solltest du mir auch nicht übel nehmen denn kein Profi fällt vom Himmel und hat den vollen Durchblick.
Zitat von dir:"Das das die Port Bandbreite ändern oder beeinflussen soll ist totaler Quatsch. Die Passage im Cisco Buch musst du uns dann mal zeigen hier..."
Mit freuden kann ich dir mitteilen wo und in welchem Buch sich diese Passage befindet!
Zitat:"Each instance uses some amount of the switch CPU and memory resources. The more instances that are in use, the fewer CPU resources will be available for switching." S. 205 CCNP SWITCH 642-813 Official Certification Guide ISBN-13: 978-1-58720-243-8
Was die Geschichte von MSTP angeht, habe ich mir dass nur hergeleitet und deine Varriante klingt mir ziemlich logisch.
Klar wird Cisco die proprietären Protokolle bevorzugen, meistens liegt der Sinn der Protokolle darin, dass es keine besseren gibt und wenn dann diese erst später entwickelt und eingeführt wurden.
Was die Traffic-Auslastung betrifft sind mir im ersten Moment die Hände gebunden, es gibt zwar einen Netflow-Server, dieser muss aber erst eingerichtet werden, das Problem in diesem OSZ ist, dass die Netzwartung etc. nebenher läuft und niemand so viel Zeit hat.
Das mit den unterschiedlichen Routingwegen ist wirklich ein guter Hinweis, das werde ich nochmal prüfen, notfalls könnte man zusätzlich routemaps einbinden oder?
Trotz der Meinungs- und Wissensverschiedenheiten finde ich die Diskussion sehr lehrreich und interessant.
Ich hoffe aber trotzdem, dass noch jemand seine Meinung zu dem Thema gibt, eventuell ist es doch Sinnvoller pvst+ laufen zu lassen.
Ansonsten wünsche ich eine gute Nacht
lg
einerseits hast du gute Tipps im Schlepptau, andererseits machst du mich hier total nieder.
Aber gut ich arbeite mal eins nach dem anderem ab:
Die Unterschiede kann man natürlich bis ins kleinste Detail ausarbeiten, aber mir reicht die arbeitsweise von MSTP, welche in diesem Fall das Bündeln der Vlans ist, welches ich brauche um Instanzen/ CPU-Leistung zu sparen.
Selbstverständlich hat MSTP mehrere Instanzen, soll es ja auch um die Lasten zu verteilen, sonst würde mir das CSTP ausreichen. Aber MSTP hat halt nur 2 oder 4 Instanzen statt 80 und sendet halt nur 2 oder 4 BDPUs und hat auch nur 4 Spanningtree Instanzen die (ich vermute mal) leichter zu Troubleshooten sind da es übersichtlicher ist.
Ich mache nicht den CCNA sondenr den CCNP und im CCNA wird nur das Grundprinziep von STP gelehrt und im CCNP wird auch nicht so sehr ins Detail gegangen, ich denke sowas wird in den Design- oder CCIE-Zertifikaten behandelt.
Die Problemstellung wen ich mit wen zusammenlege ging mir auch schon durch den kopf, ist aber in diesem Mittelgroßen Netz noch übersichtlich. Dass es bei STP-Problemen mehrere Vlans betrifft habe ich garnicht bedacht, das ist ein echt guter Hinweis, ich würde dann wohl mehr als 2 Instanzen verwenden (4 oder 8) wenn ich denn MSTP implemetieren sollte.
Das ich da mit Kanonen auf Spatzen schieße war genau dass was ich hören wollte, denn das war eigentlich meine (vielleicht unglücklich ausgedrückte) Frage. Die CPU-Last sah im laufenden Betrieb soweit ganz gut aus, allerdings konnte man in der History vernehmen, dass die Last teilweise bei 100% lag und ich bzw. meine Lehrer zu diesen Zeiten nicht an den Geräten sind/waren/sein werden um zu prüfen welcher Prozess da solch ein peak auslöst. Der Nagios-Zuständige hat permanent Termindruck und ist vorerst nicht ansprechbar, allerdings muss ich zugeben, dass ich bei meinem ersten Troubleshooting auch garnicht daran gedacht habe und dass solltest du mir auch nicht übel nehmen denn kein Profi fällt vom Himmel und hat den vollen Durchblick.
Zitat von dir:"Das das die Port Bandbreite ändern oder beeinflussen soll ist totaler Quatsch. Die Passage im Cisco Buch musst du uns dann mal zeigen hier..."
Mit freuden kann ich dir mitteilen wo und in welchem Buch sich diese Passage befindet!
Zitat:"Each instance uses some amount of the switch CPU and memory resources. The more instances that are in use, the fewer CPU resources will be available for switching." S. 205 CCNP SWITCH 642-813 Official Certification Guide ISBN-13: 978-1-58720-243-8
Was die Geschichte von MSTP angeht, habe ich mir dass nur hergeleitet und deine Varriante klingt mir ziemlich logisch.
Klar wird Cisco die proprietären Protokolle bevorzugen, meistens liegt der Sinn der Protokolle darin, dass es keine besseren gibt und wenn dann diese erst später entwickelt und eingeführt wurden.
Was die Traffic-Auslastung betrifft sind mir im ersten Moment die Hände gebunden, es gibt zwar einen Netflow-Server, dieser muss aber erst eingerichtet werden, das Problem in diesem OSZ ist, dass die Netzwartung etc. nebenher läuft und niemand so viel Zeit hat.
Das mit den unterschiedlichen Routingwegen ist wirklich ein guter Hinweis, das werde ich nochmal prüfen, notfalls könnte man zusätzlich routemaps einbinden oder?
Trotz der Meinungs- und Wissensverschiedenheiten finde ich die Diskussion sehr lehrreich und interessant.
Ich hoffe aber trotzdem, dass noch jemand seine Meinung zu dem Thema gibt, eventuell ist es doch Sinnvoller pvst+ laufen zu lassen.
Ansonsten wünsche ich eine gute Nacht
lg
OK, Antworten auch der Reihe nach:
Keiner will dich hier niedermachen, mach dich mal frei von sowas. Der Sinn der deutlichen Worte ist das man in der IT besser nicht mutmasst oder Kristallkugel gucken betreibt wie du es anfangs oben gemacht hast sondern sich auf verlässliche Fakten stützt. Sowas lernt man ja auch als CCNwasauchimmer ebenso.
Dein Argument mit der Traffic Auslastung und NetFlow ist auch irgendwie nicht nachvollziehbar. WAS bitte sehr hat denn NetFlow in diesem Umfeld zu suchen..? Gar nix !
Einzig ein simples show interface musst du auf dem Core Switch machen um dir die Uplink Auslastung einmal anzusehen...das dauert 3 Minuten und NetFlow benötigt man dazu nicht !
Oder benutze die o.a. SNMP Tools damit ist das auch in 3 Minuten erledigt...ohne NF.
Das Zitat aus dem Buch ist Unsinn oder es ist für Laien oder Anfänger geschrieben damit die es einfacher verstehen, denn das Paket Forwarding bzw. Switching passiert in den Port ASICS, direkt auf den IO Karten und hat mit der CPU rein gar nix zu tun. Jeder der sich den internen Aufbau der 4500er Switches ansieht im Cisco Dokument weiss das. Als CCNP hast du ja Zugriff auf diese Paket Flow Dokumente und kannst dir genau ansehen WIE die Hardware dieses Switches aufgebaut ist mit Port Asics und Switch Fabric. Die CPU der Management Karte ist in eine Paket Forwarding Entscheidung weder im Layer 2 noch Layer 3 involviert...das ist technischer Unsinn.
Die CPU bedient lediglich sowas wie L3 Routing Protokolle, ARP Caches usw. usw. also Prozesse die nicht lastabhängig sind.
Eine 100% CPU Last zeugt eher von einem temporären Loop im Netzwerk durch fehlende Loop Protection oder fehlende BPDU Guard Konfigs wenn externen Devices den Spanning Tree stören und man das nicht abgesichert hat. Oder eben durch Unwissende gesteckte Loops und man kein Loop Protection konfiguriert hat.
Lokales Routing sofern multiple IP Adressen oder Secondary IPs am Port sind ist auch so ein Grund, denn dann geht der Switch ins Process Switching über die CPU und das geht dann zu Lasten der CPU. Das sind aber alles Fehlkonfigurationen oder ein fehlerhaftes IP Design und logischerweise hilft da dann auch niemals die Umstellung des STP protokolls um das zu fixen, da die Ursachen ja ganz woanders liegen !
All das sind solche typischen Gründe und auch die wirst du mit NetFlow nicht rausbekommen und nur bedingt mit Nagios.
Von außen gesehen hast du vermutlich also ganz andere Probleme als nur Spanning Tree aber das ist jetzt nur im freien Fall geraten ohne dein Netzwerk Design und die dedizierte Konfig des Switches zu kennen.
Scheinbar hast du ja selber auch keine handfesten Daten was CPU Last und Uplink Auslastung betrifft oder kannst nicht auf sowas zugreifen. Dann endet sowas meist in Raterei oder Trial and Error ausprobieren ohne Plan und Erwartungshaltung.
Du solltest dir also mal alle Daten besorgen und dann einen Plan machen. Es ist doch arg zu bezweifeln das 3 oder 4 weniger STP Prozesse eine 50%ige Entlastung der CPU bringen die ja per se mit dem Traffic Forwarding nichts zu tun hat. Vermutlich sitzt du da einem Trugschluss auf, was dich aber nicht von einer MSTP Installation abbringen soll. Nur zu.. wenn du meinst es hilft und bringt Verbesserung. Du kennst die vorhanden Infrastruktur sicher besser als Forumsteilnehmer die es nur durch deine (sorry.. Anfänger)Brille gesehen beurteilen könnnen. In so fern ist das nicht einfach.
Wie gesagt, eine Wichtung der PVST Instanzen ist aber ein gangbarer und sicher sinnvoller Weg um eine bessere Auslastung der Uplinks zu bekommen...keine Frage. Da bist du sicher auf dem richtigen Weg was eine Performance Verbesserung betrifft.
Bedenke aber immer den Paketweg im Layer 2 und Layer 3 und die Gefahren die da lauern können. Wenn man das aber sauber macht ist das unkritisch. Routemaps ist wohl Overkill und solltest du besser bleiben lassen, denn das ist nichts fürs local switching. Außerdem verkompliziert es unnötig deine Konfig und kann in ungünstigen Fällen kontraproduktiv sein, da es den Switch wieder ins CPU Switching zwingt bei einem local reroute.
Mit einer sinnvollen STP Proritätensteuerung und HSRP Priority bekommt man das auch problemlos hin.
Keiner will dich hier niedermachen, mach dich mal frei von sowas. Der Sinn der deutlichen Worte ist das man in der IT besser nicht mutmasst oder Kristallkugel gucken betreibt wie du es anfangs oben gemacht hast sondern sich auf verlässliche Fakten stützt. Sowas lernt man ja auch als CCNwasauchimmer ebenso.
Dein Argument mit der Traffic Auslastung und NetFlow ist auch irgendwie nicht nachvollziehbar. WAS bitte sehr hat denn NetFlow in diesem Umfeld zu suchen..? Gar nix !
Einzig ein simples show interface musst du auf dem Core Switch machen um dir die Uplink Auslastung einmal anzusehen...das dauert 3 Minuten und NetFlow benötigt man dazu nicht !
Oder benutze die o.a. SNMP Tools damit ist das auch in 3 Minuten erledigt...ohne NF.
Das Zitat aus dem Buch ist Unsinn oder es ist für Laien oder Anfänger geschrieben damit die es einfacher verstehen, denn das Paket Forwarding bzw. Switching passiert in den Port ASICS, direkt auf den IO Karten und hat mit der CPU rein gar nix zu tun. Jeder der sich den internen Aufbau der 4500er Switches ansieht im Cisco Dokument weiss das. Als CCNP hast du ja Zugriff auf diese Paket Flow Dokumente und kannst dir genau ansehen WIE die Hardware dieses Switches aufgebaut ist mit Port Asics und Switch Fabric. Die CPU der Management Karte ist in eine Paket Forwarding Entscheidung weder im Layer 2 noch Layer 3 involviert...das ist technischer Unsinn.
Die CPU bedient lediglich sowas wie L3 Routing Protokolle, ARP Caches usw. usw. also Prozesse die nicht lastabhängig sind.
Eine 100% CPU Last zeugt eher von einem temporären Loop im Netzwerk durch fehlende Loop Protection oder fehlende BPDU Guard Konfigs wenn externen Devices den Spanning Tree stören und man das nicht abgesichert hat. Oder eben durch Unwissende gesteckte Loops und man kein Loop Protection konfiguriert hat.
Lokales Routing sofern multiple IP Adressen oder Secondary IPs am Port sind ist auch so ein Grund, denn dann geht der Switch ins Process Switching über die CPU und das geht dann zu Lasten der CPU. Das sind aber alles Fehlkonfigurationen oder ein fehlerhaftes IP Design und logischerweise hilft da dann auch niemals die Umstellung des STP protokolls um das zu fixen, da die Ursachen ja ganz woanders liegen !
All das sind solche typischen Gründe und auch die wirst du mit NetFlow nicht rausbekommen und nur bedingt mit Nagios.
Von außen gesehen hast du vermutlich also ganz andere Probleme als nur Spanning Tree aber das ist jetzt nur im freien Fall geraten ohne dein Netzwerk Design und die dedizierte Konfig des Switches zu kennen.
Scheinbar hast du ja selber auch keine handfesten Daten was CPU Last und Uplink Auslastung betrifft oder kannst nicht auf sowas zugreifen. Dann endet sowas meist in Raterei oder Trial and Error ausprobieren ohne Plan und Erwartungshaltung.
Du solltest dir also mal alle Daten besorgen und dann einen Plan machen. Es ist doch arg zu bezweifeln das 3 oder 4 weniger STP Prozesse eine 50%ige Entlastung der CPU bringen die ja per se mit dem Traffic Forwarding nichts zu tun hat. Vermutlich sitzt du da einem Trugschluss auf, was dich aber nicht von einer MSTP Installation abbringen soll. Nur zu.. wenn du meinst es hilft und bringt Verbesserung. Du kennst die vorhanden Infrastruktur sicher besser als Forumsteilnehmer die es nur durch deine (sorry.. Anfänger)Brille gesehen beurteilen könnnen. In so fern ist das nicht einfach.
Wie gesagt, eine Wichtung der PVST Instanzen ist aber ein gangbarer und sicher sinnvoller Weg um eine bessere Auslastung der Uplinks zu bekommen...keine Frage. Da bist du sicher auf dem richtigen Weg was eine Performance Verbesserung betrifft.
Bedenke aber immer den Paketweg im Layer 2 und Layer 3 und die Gefahren die da lauern können. Wenn man das aber sauber macht ist das unkritisch. Routemaps ist wohl Overkill und solltest du besser bleiben lassen, denn das ist nichts fürs local switching. Außerdem verkompliziert es unnötig deine Konfig und kann in ungünstigen Fällen kontraproduktiv sein, da es den Switch wieder ins CPU Switching zwingt bei einem local reroute.
Mit einer sinnvollen STP Proritätensteuerung und HSRP Priority bekommt man das auch problemlos hin.
Hallo aqui,
Netflow hatte ich noch im Hinterkopf weil ich ursprünglich die Lasten nach Traffic-Analysen verteilen wollte, die Idee hat sich aber mittlerweile erledigt.
Deinen Rat mit den show interface werde ich gerne annehmen, ich habe heute mitbekommen, dass es noch mehr Probleme im Netz gibt und ich denke mal ich werde mir noch einiges mehr anschauen müssen bzw. doch mal genauer hinschauen und nich in die "Kristallkugel" schauen.
Dass die Aussage im Buch Unsinn oder für Laien ist glaube ich ganz und gar nicht. Ich möchte dir als Anfänger nicht was erzählen wollen und lasse mich auch gerne beraten/belehren, aber Spanningtree hat sehr wohl was mit der CPU zu tun.
Die Aussage bezieht sich auf den Traffic, den die 80 Vlans im Intervall verursachen (Es mag vielleicht bei 80 Vlans nicht viel ausmachen). Die CPU muss aber die 80 BPDUs bearbeiten und die Topologien berechnen etc, dies geschieht im Controlplane und läuft über die CPU. Das Switching an sich läuft (ausser bei cef) auch kurzzeitig über das Controlplane.
Dass die Informationen nicht ausreichen ist mir mittlerweile klar, ich habe die Frage-/Problemstellung auch weit unterschäzt muss ich zugeben.
Ich habe mir heute noch mal kurz den Switch angeschaut und die CPU-Durchschnitts-Last liegt bei 70%. Ich hatte leider keine Zeit zu schauen welcher Prozess am meisten verbraucht.
Das dass Spanningtree an anderen Stellen falsch designt ist ist richtig, dass habe ich mir heute nochmal angesehen und dass sind Sachen an die ich vorher nicht gedacht habe. Ich werde denke ich mal übers Wochenende die HSRP-Lastenverteilung vorbereiten und einen Rollbackplan bereitlegen. Das mit dem MSTP überlege ich mir glaube ich nochmal, ich denke dazu sollte ich mir noch mehr Informationen zu den Switchen einholen. Ich hätte nicht gedacht, dass ein lauffähiges Netz so viele Probleme parrallel haben kann.
Nachdem ich die HSRP- und Rootbridgeaufteilung hoffentlich erfolgreich implementiert habe werde ich mich um die Feinheiten die dort an fast jeder Stelle fehlen kümmern. Uplinkfast, Backbonefast, Loopguards, Rootguards und was sich noch zum tunen eignet. Soweit ich sehen konnte läuft auch kein RSTP. Das Problem liegt denke ich mal auch daran, dass auch Labore mit unkonfigurierten Switchen am Hausnetz hängen (normalerweise nur mit einem Port). Aber dazu muss ich mir nochmal ne Menge Informationen einholen welche aus Zeitgründen schwer zu bekommen sind und anschließend nochmal genauer nachlesen.
Auf jedenfall hast du mir schonmal weitergeholfen, ich wusste dass es komplex wird aber nicht so umfangreich. Die Routemaps werden denke mal auch nicht nötig sein.
Ich denke wir treffen uns nochmal in einem anderem Beitrag.
Bis dahin ein schönes Wochenende und vielen Dank erstmal.
Nachtrag: Mein unstrukturiertes vorgehen bitte ich zu entschuldigen, es gibt so viel zu bedenken und beachten, es wird wohl noch ein wenig dauern bis ich da einen Durchblick habe.
Netflow hatte ich noch im Hinterkopf weil ich ursprünglich die Lasten nach Traffic-Analysen verteilen wollte, die Idee hat sich aber mittlerweile erledigt.
Deinen Rat mit den show interface werde ich gerne annehmen, ich habe heute mitbekommen, dass es noch mehr Probleme im Netz gibt und ich denke mal ich werde mir noch einiges mehr anschauen müssen bzw. doch mal genauer hinschauen und nich in die "Kristallkugel" schauen.
Dass die Aussage im Buch Unsinn oder für Laien ist glaube ich ganz und gar nicht. Ich möchte dir als Anfänger nicht was erzählen wollen und lasse mich auch gerne beraten/belehren, aber Spanningtree hat sehr wohl was mit der CPU zu tun.
Die Aussage bezieht sich auf den Traffic, den die 80 Vlans im Intervall verursachen (Es mag vielleicht bei 80 Vlans nicht viel ausmachen). Die CPU muss aber die 80 BPDUs bearbeiten und die Topologien berechnen etc, dies geschieht im Controlplane und läuft über die CPU. Das Switching an sich läuft (ausser bei cef) auch kurzzeitig über das Controlplane.
Dass die Informationen nicht ausreichen ist mir mittlerweile klar, ich habe die Frage-/Problemstellung auch weit unterschäzt muss ich zugeben.
Ich habe mir heute noch mal kurz den Switch angeschaut und die CPU-Durchschnitts-Last liegt bei 70%. Ich hatte leider keine Zeit zu schauen welcher Prozess am meisten verbraucht.
Das dass Spanningtree an anderen Stellen falsch designt ist ist richtig, dass habe ich mir heute nochmal angesehen und dass sind Sachen an die ich vorher nicht gedacht habe. Ich werde denke ich mal übers Wochenende die HSRP-Lastenverteilung vorbereiten und einen Rollbackplan bereitlegen. Das mit dem MSTP überlege ich mir glaube ich nochmal, ich denke dazu sollte ich mir noch mehr Informationen zu den Switchen einholen. Ich hätte nicht gedacht, dass ein lauffähiges Netz so viele Probleme parrallel haben kann.
Nachdem ich die HSRP- und Rootbridgeaufteilung hoffentlich erfolgreich implementiert habe werde ich mich um die Feinheiten die dort an fast jeder Stelle fehlen kümmern. Uplinkfast, Backbonefast, Loopguards, Rootguards und was sich noch zum tunen eignet. Soweit ich sehen konnte läuft auch kein RSTP. Das Problem liegt denke ich mal auch daran, dass auch Labore mit unkonfigurierten Switchen am Hausnetz hängen (normalerweise nur mit einem Port). Aber dazu muss ich mir nochmal ne Menge Informationen einholen welche aus Zeitgründen schwer zu bekommen sind und anschließend nochmal genauer nachlesen.
Auf jedenfall hast du mir schonmal weitergeholfen, ich wusste dass es komplex wird aber nicht so umfangreich. Die Routemaps werden denke mal auch nicht nötig sein.
Ich denke wir treffen uns nochmal in einem anderem Beitrag.
Bis dahin ein schönes Wochenende und vielen Dank erstmal.
Nachtrag: Mein unstrukturiertes vorgehen bitte ich zu entschuldigen, es gibt so viel zu bedenken und beachten, es wird wohl noch ein wenig dauern bis ich da einen Durchblick habe.
Hallo dq28....
Es hat auch niemans behauptet das Spanning Tree nichts mit der CPU zu tun hat. Im Gegenteil das STP wird von der Switch CPU kontrolliert. In der Beziehung hast du zweifelsohne Recht.
Kernaussage des Satzes oben war aber das eine Traffic Forwarding Entscheidung also das Behandeln des Produktivtraffics auf dem Switch rein gar nix mit der CPU zu tun hat.
In so fern ist es dem Switch aus Sicht der Traffic Performance also wie schnell Traffic von Poart A nach Port B kommt vollkommen unabhängig von der Switch CPU, denn dieser Prozess findet ausschliesslich in den Port ASICs statt. OK, nicht das allererste Paket, das wird an alle Ports geflutet, da die Mac Adresse noch nicht im der Mac Forwarding Tabelle der ASICs ist.
Für die CPU ist das vollkommen vernachlässigbar. Das ist so als ob du ein Editor Prigramm auf einer Quadcore CPU startest...
Wenn du mal umrechnechst wieviel BPDUs die 80 VLANs in 3 Sekunden (Update Intervall) generieren und was allein ein Port Interface bewältigen kann mit 1 GiG ist das eher marginal... Aber ich denek mal zu dem Thema ist alles gesagt.
Das die 70% Last vom STP kommt ist eher unwahrscheinlich. Auch mit 160 VLANs würde der niemals so hoch sein. Da ist irgend was anderes noch zemlich im Argen in der Konfig oder im Netz selber.
Beim HSRP Lastenverteilen, denke auch immer daran welchen eg dann das Layer 2 Paket nimmt, denn das ist ausschlaggebend für den Traffic Flow.
Wenn du z.B. über Router A im HSRP Priority routest, das Paket aber durch STP Block an dessen Interface nicht geforwardet werden kann rennt es immer erst über die Querverbindung zu Router B und dann auf den Uplink.
Im Zweifel kann das also eine überflüssige Vervielfachung des Traffics und damit der Linkbelastung und der Laufzeit nach sich ziehen.
Also lautet der Tip: Genau hinsehen auf beiden Layern !
Wernn es Wildwuchs mit anderen unkonfigurierten Switches gibt dort solltest du immer BPDU Giard aktivieren, damit die dir deinen STP nicht stören können, das ist schon einwichtiger Punkt.
Wenn möglich solltest du auch auf PVRSTP umstellen, denn das hat eine erheblich schnellere Konvergenzeit und erfordert keine komplette Umstellung wie bei MSTP.
Viel Erfolg und ebenso ein schönes Wochenende.
How can I mark a post as solved?
nicht vergessen wenns das denn nun gewesen ist !
Es hat auch niemans behauptet das Spanning Tree nichts mit der CPU zu tun hat. Im Gegenteil das STP wird von der Switch CPU kontrolliert. In der Beziehung hast du zweifelsohne Recht.
Kernaussage des Satzes oben war aber das eine Traffic Forwarding Entscheidung also das Behandeln des Produktivtraffics auf dem Switch rein gar nix mit der CPU zu tun hat.
In so fern ist es dem Switch aus Sicht der Traffic Performance also wie schnell Traffic von Poart A nach Port B kommt vollkommen unabhängig von der Switch CPU, denn dieser Prozess findet ausschliesslich in den Port ASICs statt. OK, nicht das allererste Paket, das wird an alle Ports geflutet, da die Mac Adresse noch nicht im der Mac Forwarding Tabelle der ASICs ist.
Für die CPU ist das vollkommen vernachlässigbar. Das ist so als ob du ein Editor Prigramm auf einer Quadcore CPU startest...
Wenn du mal umrechnechst wieviel BPDUs die 80 VLANs in 3 Sekunden (Update Intervall) generieren und was allein ein Port Interface bewältigen kann mit 1 GiG ist das eher marginal... Aber ich denek mal zu dem Thema ist alles gesagt.
Das die 70% Last vom STP kommt ist eher unwahrscheinlich. Auch mit 160 VLANs würde der niemals so hoch sein. Da ist irgend was anderes noch zemlich im Argen in der Konfig oder im Netz selber.
Beim HSRP Lastenverteilen, denke auch immer daran welchen eg dann das Layer 2 Paket nimmt, denn das ist ausschlaggebend für den Traffic Flow.
Wenn du z.B. über Router A im HSRP Priority routest, das Paket aber durch STP Block an dessen Interface nicht geforwardet werden kann rennt es immer erst über die Querverbindung zu Router B und dann auf den Uplink.
Im Zweifel kann das also eine überflüssige Vervielfachung des Traffics und damit der Linkbelastung und der Laufzeit nach sich ziehen.
Also lautet der Tip: Genau hinsehen auf beiden Layern !
Wernn es Wildwuchs mit anderen unkonfigurierten Switches gibt dort solltest du immer BPDU Giard aktivieren, damit die dir deinen STP nicht stören können, das ist schon einwichtiger Punkt.
Wenn möglich solltest du auch auf PVRSTP umstellen, denn das hat eine erheblich schnellere Konvergenzeit und erfordert keine komplette Umstellung wie bei MSTP.
Viel Erfolg und ebenso ein schönes Wochenende.
How can I mark a post as solved?
nicht vergessen wenns das denn nun gewesen ist !
