Maximum aantal Cisco switches in STP

[Dieter]

Hallo,

ik ben op zoek of er een beperking staat op Spanning-Tree (PVST, Rapid-PVST). Met name een beperking op het aantal switches binnen een lus. In de Cisco documentatie (het gaat hier over een Cisco Catalyst netwerk) kan ik nergens een beperkend aantal terug vinden ...

Wat zijn jullie ervaringen hiermee ?

[paella]

Er staat me iets bij van 7...? Maar heb ik geen docs voor. Anderen kunnen vast wel iets produceren.

[BrammeS]

paella schreef op donderdag 25 oktober 2007 @ 11:02:
Er staat me iets bij van 7...? Maar heb ik geen docs voor. Anderen kunnen vast wel iets produceren.

standaard is de network diameter idd 7, maar ik geloof dat cisco adviseert om niet meer dan 5 of 6 te gebruiken.

om diameter aan te passen gebruik je:

Switch(config)# spanning-tree vlan vlan-id root {primary | secondary} [diameter diameter]

[ Voor 19% gewijzigd door BrammeS op 25-10-2007 13:16 . Reden: typo en toevoeging ]

[Dieter]

Ok, bedankt hier ben ik al iets mee ... kunnen jullie me ook vertellen wat het effect is van dit te negeren ? 15 Switches in een ring te plaatsen ?

Werkt spanning tree gewoonweg niet of is het 'niet aangeraden?'

[paella]

Dat heeft met het convergen te maken. Als de weg te lang is, kan STP niet meer goed convergeren naar loop-free. Geloof dat daar zelfs een berekening op los te laten is... Brammes, jij?

[ Voor 25% gewijzigd door paella op 25-10-2007 14:12 ]

[JackBol]

paella schreef op donderdag 25 oktober 2007 @ 14:11:
Dat heeft met het convergen te maken. Als de weg te lang is, kan STP niet meer goed convergeren naar loop-free. Geloof dat daar zelfs een berekening op los te laten is... Brammes, jij?

hello-timer is 2 seconde, de forward-delay is 15 seconde. Als je meer dan 7 nodes hebt, zou het kunnen zijn dat je hello interval uit de forward-delay loopt en dat je topologie nooit convergeert.

Met STP is dit een theoretisch issue, met RSTP niet meer omdat daar links met negotiations werkt.

Verder zou ik de tree nooit meer dan 3 nodes laten spannen. (dwz, access switch rechtstreeks naar 2 distributie switches) Routen is processor-technisch even 'duur' als switchen tegenwoordig, dus je moet je broadcast domains niet onnodig groot maken.

[Dieter]

Bedankt, zeer duidelijk!

[boner]

Je kunt ook proberen om een loop-free netwerk te ontwerpen. 9 van de 10 keer is dat mogelijk!

[paella]

Hoe los je je redundantie op dan?

[BrammeS]

boner schreef op vrijdag 26 oktober 2007 @ 08:49:
Je kunt ook proberen om een loop-free netwerk te ontwerpen. 9 van de 10 keer is dat mogelijk!

Waarom zou je dat willen? Ik ben dagelijks bezig om juist loops te creëren in netwerken. daar hebben ze juist dit soort mechanismes voor uitgevonden.

Zo hoort een netwerk design er ongeveer uit te zien:

[ Voor 16% gewijzigd door BrammeS op 26-10-2007 10:59 ]

[boner]

brammes.
ALs je de verbindingen tussen de core en de distributie L3 maakt. De verbindingen tussen de twee cores net als de verbindingen tussen de twee distibutie switches ook L3. En de rest L2 dan heb je ene prima werkend netwerk. ZO stabiel als maar kan.

Als alles L3 is moet je eens alle STP driehoeken uittellen. Hoe lang denk je dat een switch bezig is om alles door te rekenen? Of aangezien STP geen backup verbindingen berekent maar pas als het nodig is. Hoe lang denk je dat het duur om te herberekenen na een error?

In mijn situatie heb je dat niet. L3 met OSPF heeft wel een backup pad klaar. EN kan dat zeer snel, vaak binnen de TCP timeout, inzetten. REsultaat. STP vrij en beresnel en betrouwbaar.

[paella]

Dat is dan ook een stuk duurder stuk netwerk.

[boner]

paella schreef op maandag 29 oktober 2007 @ 22:45:
Dat is dan ook een stuk duurder stuk netwerk.

Welk type core en distributie switches wil jij dan gebruiken. Die ik gebruik zijn altijd L2/L3. Toegegeven de software is duurder, maar dat valt reuze mee als je de totale kosten van het netwerk, dus inclusief de manuren, bekijkt. Ook is betrouwbaarheid wel een paar dubbeltjes waard.

[paella]

De netwerken die ik gebruik (zit intern bij een bedrijf), hebben nooit de 3 lagen. Tot nu toe altijd maar 2, een core en een access layer (of is het dan distribution en access?). Dus dan is het altijd beetje "behelpen"

[Dieter]

Mmh, de complete layer 3 opzet is best wel goed ... momenteel zijn we niet verder gekomen dan spanning-tree ivm redundancy. Moet echt eens wat vakliteratuur er op na houden...

[Question Mark]

boner schreef op maandag 29 oktober 2007 @ 15:28:
ALs je de verbindingen tussen de core en de distributie L3 maakt. De verbindingen tussen de twee cores net als de verbindingen tussen de twee distibutie switches ook L3. En de rest L2 dan heb je ene prima werkend netwerk. ZO stabiel als maar kan.

Hoe ga je de verbinding tussen Access- en distributieswitches dan redundant maken?

[BrammeS]

boner schreef op maandag 29 oktober 2007 @ 15:28:
brammes.
ALs je de verbindingen tussen de core en de distributie L3 maakt. De verbindingen tussen de twee cores net als de verbindingen tussen de twee distibutie switches ook L3. En de rest L2 dan heb je ene prima werkend netwerk. ZO stabiel als maar kan.

Als alles L3 is moet je eens alle STP driehoeken uittellen. Hoe lang denk je dat een switch bezig is om alles door te rekenen? Of aangezien STP geen backup verbindingen berekent maar pas als het nodig is. Hoe lang denk je dat het duur om te herberekenen na een error?

In mijn situatie heb je dat niet. L3 met OSPF heeft wel een backup pad klaar. EN kan dat zeer snel, vaak binnen de TCP timeout, inzetten. REsultaat. STP vrij en beresnel en betrouwbaar.

Ik ben het helemaal met je eens maar bovenstaand plaatje komt rechtstreeks van Cisco. en is hun visie op een goed netwerk.

paella schreef op dinsdag 30 oktober 2007 @ 07:22:
De netwerken die ik gebruik (zit intern bij een bedrijf), hebben nooit de 3 lagen. Tot nu toe altijd maar 2, een core en een access layer (of is het dan distribution en access?). Dus dan is het altijd beetje "behelpen"

Ik kom eigenlijk ook alleen maar netwerken tegen met een access en een core layer.

Dieter schreef op dinsdag 30 oktober 2007 @ 08:33:
Mmh, de complete layer 3 opzet is best wel goed ... momenteel zijn we niet verder gekomen dan spanning-tree ivm redundancy. Moet echt eens wat vakliteratuur er op na houden...

Kijk de situatie in het voorbeeld hierboven heeft waarschijnlijk geen of weinig raakvlak meer met jou situatie.

[ Voor 30% gewijzigd door BrammeS op 30-10-2007 10:06 . Reden: toevoeging ]

[boner]

BrammeS schreef op dinsdag 30 oktober 2007 @ 10:01:
[...]


Ik ben het helemaal met je eens maar bovenstaand plaatje komt rechtstreeks van Cisco. en is hun visie op een goed netwerk.

Dat kan ik zien dat het zo bij Cisco vandaan komt. Ook Cisco zegt echter dat STP zoveel mogelijk voorkomen dient te worden. En geloof me, ik werk nu ongeveer 15 jaar met Cisco samen.

Echter is mijn stelling op dat plaatje 100% van toepassing.

[...]


Ik kom eigenlijk ook alleen maar netwerken tegen met een access en een core layer.

Dan zit de distribuitie functie in de core. Men noemt dat ook vaan Collapsed Core. Maar een echt groot netwerk kan het beste wel met drie lagen worden opgebouwd.

[...]


Kijk de situatie in het voorbeeld hierboven heeft waarschijnlijk geen of weinig raakvlak meer met jou situatie.

[JackBol]

boner schreef op maandag 29 oktober 2007 @ 15:28:
brammes.
Of aangezien STP geen backup verbindingen berekent maar pas als het nodig is. Hoe lang denk je dat het duur om te herberekenen na een error?

RSTP doet dat <50ms.

In mijn situatie heb je dat niet. L3 met OSPF heeft wel een backup pad klaar. EN kan dat zeer snel, vaak binnen de TCP timeout, inzetten.

Zelfs met OSPF fast Hello timers duurt het 3 seconde voordat je adjacency down gaat en je topologie herconvergeert.


Get your facts straight als je iemand corrigeert.

L2 is altijd sneller dan L3, je hebt alleen een intelligence-penalty.

[ Voor 7% gewijzigd door JackBol op 30-10-2007 16:28 ]

[boner]

Denk je dat een netwerk zoals hierboven staat getekend alles binnen 50 ms herberekend heeft? Met een beetje pech lopen over de getekende fysieke verbindingen ook nog eens alle VLAN trunks, met alle VLANS's op allowed.

RSTP werkt alleen maar lekker als je ook alle priority's netjes vantevoren hebt gezet, en het netwerk altijd een enkele keuze heeft voor het alternatieve pad. Zo niet dan zal ook rapid spanning tree niet zo heel erg rapid zijn.

Als je naar Cisco luistert, en die hebben het toch heel aardig in de smiezen, dan hoor je dat 9 van de 10 netwerk verstoringen komen door een verkeerd gebruik van STP.

De regel bij Cisco is dan ook om alleen STP te gebruiken als het echt niet anders kan.

[A_De2]

@boner: De regel om alleen STP te gebruiken als het echt niet anders kan. Geldt dat ook voor RSTP? En misschien een hele simpele vraag maar waarom zou je STP gebruiken als je ook RSTP hebt?

[BrammeS]

boner schreef op woensdag 31 oktober 2007 @ 07:42:

De regel bij Cisco is dan ook om alleen STP te gebruiken als het echt niet anders kan.

Dat vind ik toch wel raar, Ik ben nu het bcmsn boek aan het lezen en eigenlijk alle genoemde netwerkmodellen zijn zo opgebouwd dat stp of rstp noodzakelijk is. Waarom zouden ze aan de andere kant roepen dat je dit eigenlijk niet moet gebruiken.

[JackBol]

BrammeS schreef op donderdag 01 november 2007 @ 11:17:
[...]


Dat vind ik toch wel raar, Ik ben nu het bcmsn boek aan het lezen en eigenlijk alle genoemde netwerkmodellen zijn zo opgebouwd dat stp of rstp noodzakelijk is. Waarom zouden ze aan de andere kant roepen dat je dit eigenlijk niet moet gebruiken.

dat roept cisco ook helemaal niet. dat denkt boner alleen...

[Bl@ckbird]

_DH schreef op donderdag 01 november 2007 @ 23:17:
[...]
dat roept cisco ook helemaal niet. dat denkt boner alleen...

Ik merk dat Cisco dat de laatste tijd wel begint te roepen... (Dus Boner heeft gelijk.)
Maar er is een nuance:

Cisco is een Amerikaans bedrijf en is gewend aan grote Enterprise omgevingen. ( Het Campus LAN )
Hiervoor gebruikt Cisco het 3 lagen model: Core, Distributie en Access.

Voor nevenvestigingen ( Branch Offices ) gebruikt Cisco het Collapsed Core ontwerp:
Core en Access ( Core+ Distributie zijn één laag. )

De meeste netwerken zijn in Nederland van het Branch Office type. (Qua netwerk grootte.)

Vanwege de kosten adviseert Cisco bij het Collapsed Core model geen fully routed netwerk.
Bij het Campus LAN is het een alternatief.

Zie ook de Solution Reference Network Design Guides.
En dan met name deze en deze.

BrammeS schreef op donderdag 01 november 2007 @ 11:17:
[...]
Dat vind ik toch wel raar, Ik ben nu het bcmsn boek aan het lezen en eigenlijk alle genoemde netwerkmodellen zijn zo opgebouwd dat stp of rstp noodzakelijk is. Waarom zouden ze aan de andere kant roepen dat je dit eigenlijk niet moet gebruiken.

Het duurt altijd een tijd voordat dit soort inzichten in het trainingsmateriaal verschijnt.

[boner]

_DH schreef op donderdag 01 november 2007 @ 23:17:
[...]


dat roept cisco ook helemaal niet. dat denkt boner alleen...

Bij een vrij grote bank heb ik meerdere malen met SE's van Cisco gesprekken hierover gevoerd. In al die gesprekken waarin STP of een willekeurig familielid van STP werd besproken gaven ze allemaal aan dat het ook zonder STP is op te lossen en dat STP loos beter was! 90% van alle major TAC cases in grote verstoringen zouden STP related zijn.

Een Lusloos ontwerp verdient de voorkeur. Als er dan toch lussen moeten, bijvoorbeeld omdat je subnets over locaties moet verdelen, dan alleen maar doen als je met de hand de prioriteiten goed en doordacht instelt.

Dat is de moderne Cisco filosofie.

Overigens is het drie lagen model niet op switches maar op routers gebaseerd. En niet zo heel erg lang geleden hadden routers nog een beperkt aantal interfaces. Nu zit de router in een switch en heeft veel meer mogelijkheden. In feite is de router, dmv netflow, meer richting L2 gegaan. Maar dit terzijde.

[bazkar]

Wij hebben hier ook een Collapsed core model met lussen naar de acces en PV- RSTP actief.
Uiteraard wil je voor al je VLAN's dan aangeven wie primary en wie secondary root is.
PST inrichten en 'hopen' dat het netwerk zelf wel uitvind hoe het optimaal moet draaien in geval van storing is wel erg wishful thinking.

Overigens hebben wij dus inderdaad het probleem dat de VLAN's (en dus de subnetten) verdeeld zitten over het hele netwerk en routeren in een evt. distributielaag is dus zinloos.

[JackBol]

Bl@ckbird schreef op vrijdag 02 november 2007 @ 00:14:
[...]


Ik merk dat Cisco dat de laatste tijd wel begint te roepen... (Dus Boner heeft gelijk.)

Spanning-Tree zal altijd nodig zijn voor in je access netwerk. Je wil hier de redundantie namelijk altijd op L2 hebben, tenzij je je hosts wil laten participeren in een routed protocol. Maar dat wil waarschijnlijk niemand.

Verder komt STP in de distributie eigenlijk niet voor, maar een switched redundante core kan best interessant zijn. Het is veel schaalbaarder dan een routed core, dus het is maar net wat je nodig hebt in je omgeving, die 5e 9, of schaalbaarheid.

boner schreef op vrijdag 02 november 2007 @ 07:20:
[...]

Bij een vrij grote bank heb ik meerdere malen met SE's van Cisco gesprekken hierover gevoerd.

SE'ers zijn ook niet almachtig vergeet nooit zelf na te denken als je een SE'er over de vloer krijgt...

[Bl@ckbird]

_DH schreef op vrijdag 02 november 2007 @ 20:14:
[...]
SE'ers zijn ook niet almachtig ...

Ik me een sessie herinneren over bovenstaand onderwerp, enige tijd geleden, tijdens een dag voor Cisco partners. Dit geeft aan, dat dit idee organisatie breed gedragen wordt. Aangezien hier diverse online documentatie van is, wordt dit direct vanuit San Jose gestuurd.

_DH schreef op vrijdag 02 november 2007 @ 20:14:
[...]
...vergeet nooit zelf na te denken als je een SE'er over de vloer krijgt...

Dat is sowieso handig

[JackBol]

Bl@ckbird schreef op zondag 04 november 2007 @ 18:59:
Ik me een sessie herinneren over bovenstaand onderwerp, enige tijd geleden, tijdens een dag voor Cisco partners. Dit geeft aan, dat dit idee organisatie breed gedragen wordt.

Ik moet toch een beetje bijkeren. Cisco is inderdaad bezig STP de nek om te draaien. Met die nieuwe VS-S720 zijn ze nu zelfs zover dat FHRPs niet meer nodig zijn... Helaas wel een flinke investering!

[digibaro]

_DH schreef op dinsdag 30 oktober 2007 @ 16:27:
[...]

RSTP doet dat <50ms.


[...]


Zelfs met OSPF fast Hello timers duurt het 3 seconde voordat je adjacency down gaat en je topologie herconvergeert.


Get your facts straight als je iemand corrigeert.

L2 is altijd sneller dan L3, je hebt alleen een intelligence-penalty.

Klein detail OSPF kan sneller schakelen, schakeltijden van 1 sec en lager zijn mogelijk...