Cisco SG200-50 - Storm Control fehlerhaft

[-Overlord-]

Hallo Leute

Ich habe hier gerade ein Testequip auf dem Schreibtisch liegen: 3x Cisco SG200-50 Switche, alle 3 mit RSTP und eigentlich auch Storm Control. Hab an einem Port nun einen kleinen Switch rangehangen und an diesen einen Computer, ein IP Telefon und damit dann die Schleife gelegt (auch schon indem ich einfach nur 2 Ports verbunden hab). Laut Wireshark gehts sofort los mit Broadcaststurm, aber der Port schaltet sich nicht ab. Folgendes hab ich eingestellt:

Storm Control Rate Treshold: 3500 kbit/sec
Storm Control Mode: Broadcast only

Mein Möglichleiten hat man in dem schimmelligen Smart Managed Switch leider nicht. Auf jeden Fall passiert nicht das was passieren soll (Port abschalten). Das ich nicht mal den Trab einstellen kann, stört mich nicht - aber dass gar nix passiert Es passiert, was passieren soll:

-Switch ist nicht mehr erreichbar
-Switch ist erreichbar, aber die Pings sind recht hoch

Ich hab auch schon gespielt mit der Port Security, aber auch das hat nix gebracht Mittlerweile glaub ich einfach, dass die Funktion von dem Switch einfach fehlerhaft ist. Der Switch hat die aktuellste Firmware: 1.2.7.76

Hab ich was übersehen/falsch konfiguriert? Jemand eine Idee?

Danke schon mal

Greetz
Overlord

 

[Masamune2]

Wo steht denn das der Port ausgehen soll? Ich kenns jetzt nur von HP Geräten aber da wird der Port nicht deaktiviert sondern lediglich die Anzahl der Pakete pro Sekunde beschränkt. Schau dir im Wireshark mal die Übertragungsrate an, die sollte eignetlich nicht über 3500 kbit/s gehen.

Um Schleifen zu verhinden gibt es bei HP auch noch die Loop-Protection Funktion. Vielleicht bietet Cisco hier was ähnliches (bezweifle ich aber bei Smart managed Switchen)

 

[sirbondness]

bei Cisco heißt der Spass "bpduguard"

 

[webmi]

bpduguard ist was anders, hat mit einer schleifendetection erstmal nichts zu tun.

wenn ich dich richtig verstanden habe, möchtest du sehen, wie der switch einen loop erkennt und du möchtest, dass der switch den port daraufhin abschaltet?

mit dem broadcastbefehl sagst du dem switch, er soll nur eine bestimmte menge an broadcasts durchlassen.
führt im falle eines loops dazu, dass der port nicht zugeblasen wird, sondern eben nur eine definierte menge x durchgeblasen wird.

portsecurity ist auch ganz was anders...

:-)

 

[sirbondness]

mhh..ist es nicht das was er sucht ?

Das BPDU Protokoll von Cisco sendet kleine Datenpakete über die Ports wenn ein Port das Datenpaket zurück bekommt, erkennt er somit einen Loop und deaktiviert den Port.

aber ich lasse mich gerne belehren !

 

[webmi]

jetzt verstehe ich auch erst, was er machen will. er möcht eoffenbar zwei switche loopen. ich dachte er loop einen switch mit einem kabel...

wenn du mit zwei switchen einen loop steckst, erkennt der stp das und schält einen port in blcoking einen in forwarding, das verhindert schleifenfreiheit, das stimmt. mit diesem prinzip wird dann der tree erstellt.

dachte er hat zwei ports auf einem switch un möchte diese loopen.

 

[Masamune2]

Ich kann hier wieder nur für HP sprechen aber auch da sind Loop-Protection und BPDU-Filter zwei verschiedene Dinge.

Bei der Loop Protection wird ein BPDU-Paket mit einer bestimmten Signatur über einen Port rausgeschickt und gewartet ob es über einen anderen Port wieder rein kommt. Ist das der Fall wird der Port deaktiviert.

Beim BPDU-Filter werden BPDU Pakete komplett verweigert wodurch Spanning-Tree auf diesen Ports nicht mehr funktioniert und somit auch niemand die SPT Berechnungen mit gefälschten Paketen stören kann.

 

[sirbondness]

und ich war der Meinung das bpduguard=loop protection wäre......

 

[-Overlord-]

Hier mal das klassische Beispiel:

http://www.nwlab.net/know-how/Cisco/storm-control.html

Da die Switche allerdings SmartManaged sind, hab ich nur die begrenzen Möglichkeiten das via Webinterface einzustellen. Also ist das in den Smart Managed System wohl gar nicht vorgesehen, dass die Ports sich abschalten wenn ein zu hoher Broadcast ist?

Portsecurity ist mir klar, die sollte auch aktiv sein auf 1 oder 2 Mac Adressen, wichtiger ist mir aber das StormControl (wie in dem Anwendungsfall unter dem Link oben).

 

[webmi]

wenn du zwei switche loopst, erkennt der rstp das und versetzt die ports anhand von best. kosten in jeweils Blocking, Listening, Learning, Forwarding. deaktiviert wird der port dabei nciht. also im sinne von shutdown.
er sendet lediglich keine packete über dieses interface, sodass hier eben kein loop entsteht.
das ganze ist teil des spanning tree prozesses. fällt das forwarding interface nämlich aus, so erkennt der rstp das und schält den anderen weg zur verwendung frei. dein switch macht alles richtig.

es ist generell nicht vorgesehen, dass sich die ports abschalten, sie gehen lediglich ein einen der von mir erwähnten stati. das ist spanning tree

 

[-Overlord-]

Das mit RSTP stimmt, ja. Allerdings sollte das nur die Cisco Switche betreffen und die Kaskadierung zwischen den Switchen. Sobald an einem Port allerdings ein Broadcast Storm aufgrund eines kleineren (z.B. Netgear) Switches passiert, sollte das das RSTP gar nicht interessieren.

Und meinst du das das mit dem Storm Control generell nicht geht ,oder nur nicht bei den schimmeligen Small Business Switchen? Weil der Befehl "storm-control action shutdown" den man im Catalyst eingeben kann, arbeitet ja genau so - der Port wird beim Übertritt des Schwellwertes deaktiviert.

 

[webmi]

ja, strom controll setzt einen wert und eine aktion beim überschreiten des wertes. wenn du auf dem interface also mehr broadcasttraffic hast, als es der schwellwert erlaubt, tritt die aktion ein. wenn der swtich diese option bietet, handelt er in der regel auch entsprechend ^^

 

[-Overlord-]

ja, strom controll setzt einen wert und eine aktion beim überschreiten des wertes. wenn du auf dem interface also mehr broadcasttraffic hast, als es der schwellwert erlaubt, tritt die aktion ein. wenn der swtich diese option bietet, handelt er in der regel auch entsprechend ^^

Das ist der Knackpunkt... der Switch macht nix! Aber vermutlich hast du recht.. die Sturmsteuerung beschränkt nur den Transfer, aber schaltet den Port nicht ab (sinnlos Feature in dem Fall)

 

[webmi]

naja, wenn du einen storm hast, beschränkt diese funktion den traffic zumindest, sodass das netzwerk funktionfähig bleibt.
normalerweise knallt dir der loop bzw der broadcaststorm das ganze netz dicht, mit deiser beschränkung eben nicht.
sinnlos ist das nicht.

 

[-Overlord-]

naja, wenn du einen storm hast, beschränkt diese funktion den traffic zumindest, sodass das netzwerk funktionfähig bleibt.
normalerweise knallt dir der loop bzw der broadcaststorm das ganze netz dicht, mit deiser beschränkung eben nicht.
sinnlos ist das nicht.

Mhhmm.. in meiner kleinen Testumgebung kann ich leider nicht feststellen ob das so arbeitet wie es soll. Sei es mit 3500 kbit/s oder 10000000 kbit/s oder gar komplett deaktiviertem Storm Control - kein Unterschied