(baystack) switches route bepaling in een ring

[Verwijderd]

Hallo,

Ik heb bij een klant van ons een 5-tal 350 en een 2-tal 450 switches staan die dmv. een glasvezel ring verbonden zijn. Op de switches zijn een aantal PLC's aangesloten die 24 uur per dag met elkaar communiceren. In deze PLC's zitten bewakingstimers geprogrammeerd die controleren of de communicatie werkt. Als een PLC merkt dat er >20 seconden geen nieuwe data is binnengekomen meldt hij een communicatie probleem en legt de evt. (communicatie-) betreffende actieve processen plat.
Het idee om de switches in een ring te plaatsen is dat als er 1 switch uitvaltl de communicatie in stand blijft omdat elke switch 2 routes heeft om een andere switch te bereiken! Deze theorie klopt met de praktijk, echter het probleem is dat die switches een bepaalde tijd nodig hebben om bij een uitval van 1 van de switches tot aktie over te gaan en proberen via een de andere weg te communiceren. En juist die tijd wil ik graag verkorten! Ik denk dat het zo'n 30 sec. duurt, na een uitval, voordat iedereen weer communiceert met elkaar. Probleem 2 is dat na herstel van zo'n switch er weer vrolijk wordt besloten om de routes weer om te gooien. Oftewel 2 keer gaat het netwerk even >30 sec. plat.... met vervelende gevolgen in de fabriek!

De vraag is: 1. kun je dat hele proces van routes bepalen versnellen en 2. hoe kun je dat dan configureren?
Opm.: het heeft volgens mij te maken met spanning tree maar ik heb geen idee hoe en wat je daar moet veranderen...

Bij voorbaat hartelijk dank!

Peter

[kell.nl]

Ik ken die baystacks niet, maar het is idd spanning tree.
Je zou kunnen kijken of de switches ook RSTP (rapid spanning tree protocol) ondersteunen.
Deze convergeert sneller.
Anders zou je moeten kijken of je met de timers kan spelen.

Hier een document van Cisco over de timers en hoe je ze kan instellen op cisco switches.
http://www.cisco.com/en/U...ote09186a0080094954.shtml

/edit

En een extra linkje naar een pdf van Baystack hoe je de timers kunt aanpassen op een 350 (de 450 mag je zelf zoeken).
Ik zie er geen RSTP bij staan.

http://www25.nortelnetwor...es/bstack/450/210245c.pdf

[ Voor 24% gewijzigd door kell.nl op 15-01-2004 13:36 . Reden: Extra link ]

[killercow]

Mijn baystack 450 in telecity geeft voor zover ik getest hebt geen enkele vertraging als hij spanning tree gebruikt en er een link doodvalt.
Ik heb spanning tree op learning staan voor de poorten die in de tree opgenomen worden, ze herkennen de tree dan autmatisch en gaan hem drect gebruiken, ik gebruik een redundant link, (geen ring) naar 2 cisco machines die blijkbaar aangeven een tree te vormen met zo'n 2en. hoe je en of je die baystack ook moet laten vertellen dat hij een tree vromt met een andere baystack weet ik niet.

[kell.nl]

killercow schreef op 15 januari 2004 @ 14:27:
Mijn baystack 450 in telecity geeft voor zover ik getest hebt geen enkele vertraging als hij spanning tree gebruikt en er een link doodvalt.
Ik heb spanning tree op learning staan voor de poorten die in de tree opgenomen worden, ze herkennen de tree dan autmatisch en gaan hem drect gebruiken, ik gebruik een redundant link, (geen ring) naar 2 cisco machines die blijkbaar aangeven een tree te vormen met zo'n 2en. hoe je en of je die baystack ook moet laten vertellen dat hij een tree vromt met een andere baystack weet ik niet.

Weet je zeker dat je hier geen trunk c.q. etherchannel mee bedoeld?
Dus 2 fysieke verbindingen tussen twee switches die als 1 logisch geheel worden gezien?
Bij spanning tree heb je namelijk altijd iets van downtime.

[Verwijderd]

Ja, timers en wat ja al niet meer kunt aanpassen in zo'n ding. Heb er nu drie gewijzigd:

Hello Time (default:2 nu 1 sec.)
Maximum Age Time (20 nu 6 sec.)
Forward Delay (15 nu 4 sec.)

Maar ik heb geen idee of deze verkorte tijden het probleem oplossen...

[kell.nl]

Verwijderd schreef op 16 januari 2004 @ 10:46:
Ja, timers en wat ja al niet meer kunt aanpassen in zo'n ding. Heb er nu drie gewijzigd:

Hello Time (default:2 nu 1 sec.)
Maximum Age Time (20 nu 6 sec.)
Forward Delay (15 nu 4 sec.)

Maar ik heb geen idee of deze verkorte tijden het probleem oplossen...

Dit scheelt behoorlijk in tijd.
Even rekenen:

eerst duurde het tussen 2*15=30 int het gunstigste geval (loss of link) en 2*15+20=50 seconden in het slechtste geval (geen loss of link, maar ook geen verkeer mogelijk)

Met de nieuwe timers ligt het tussen 2*4=8 seconden en 2*4+6=14 seconden.

Een stuk minder dus. De berekeningen zijn grof genomen, er komt bij elke waarde een beetje bij, maar die extra berekening (diameter etc.) heb ik er gemakshalve uitgelaten.

Als het trouwens 1 bepaalde link (of switch) er steeds onderuit gaat, dan is het verstandig om handmatig een root bridge te kiezen. Je kan hiervoor het beste de switch kiezen die het verst van de fout afzit. (Dit scheelt in die restwaarde die ik hierboven niet meereken

Ik zou met deze timers wel je netwerk de komende tijd goed in de gaten houden. Het zijn nogal... tja.. niet conservatieve waardes.
Als je links hebt die "flappen" (snel up/down gaan achter elkaar) dan kun je met deze timers loops introduceren. Al gebeurt dat in een ring niet snel.
1 tip voor het controleren: In een ring zonder fouten staat er maar 1 poortje (van alle switches, niet per switch) op blocking. Dit is normaliter altijd de dezelfde (en is ook uit te rekenen)

[Verwijderd]

Jaja, dat van die blocking klopt, heb ik gecontroleerd en is nog steeds dezelfde port op de dezelfde switch. Ze hebben nl. vanochtend de proef op de som genomen en nu bleven de gevolgen uit (dus de fabriek bleef doordraaien)! Wel nog even afwachten maar ik heb er wel een goed gevoel over nu. Heb een evaluatie versie van de Optivity switch manager gedownload en bij de help kwam ik dit bij de "forward delay" tegen:

>
Value (in hundredths of a second) that controls how fast a port changes its spanning state when moving towards the Forwarding state. The value determines how long the port stays in each of the Listening and Learning states, that precede the Forwarding state. The value is also used when a topology change has been detected and is underway. This ages all dynamic entries in the Forwarding Database.
Note: This value is the one that this bridge is currently using, in contrast to dot1dStpBridge ForwardDelay which is the value that this bridge and all others would start using if/when this bridge were to become the root.]
<

Wat niet in de handleiding stond en wat ik mij afvroeg werd hier in beantwoord met "this ages all... forwarding database." Oftewel deze age-time telt (volgens mij) niet mee als er een verandering in de netwerk topology plaatsvindt!

Niet conservatieve waarden, tja heb maar meteen de korste tijden mogelijk gekozen. Netwerk wordt niet zwaar belast trouwens of maakt dat niet zoveel uit. Flappen? Nou, in dit geval is er door iemand gewoon even de spanning van een switch gehaald, dus gelukkig geen aan/uit situaties. Zal ook niet snel gebeuren omdat allen achter een UPS zitten en de twee belangrijkste (450) zijn van een redundante voeding voorzien. Waarom? omdat de APC UPSsen tijdens hun zelftest i.g.v. een UPS storing heel even de spanning niet doorgeven... en dan wordt je switch af en toe spontaan geherstart.. (ook al een keer gehad! maar gelukkig levert dat weer een trap op die je kunt afvangen en zo blijven we lekker bezig) Om het verhaal af te maken, de 450 zit eenmaal op een UPS en eenmaal direct op het net (tja, wel weer zonder netfilter ja... maar goed)

Nogmaals bedankt voor je hulp, kell.nl, wordt zeer gewaardeerd!