Vlan gaat down / vlan altijd up

[Rotty]

Ik zit met een klein probleempje. Wij hebben een core switch met trunk verbindingen naar verschillende gebouwen hier op het terrein (alle gebouwen hebben een eigen VLAN). Op de core switch zijn bijna alle vlans aangemaakt met ip adressen voor inter vlan routing. Daarnaast is er een vlan incl ip adres aangemaakt voor de route naar onze firewall toe . De koppeling naar onze firewall gaat eveneens over een trunk.

Nu merken wij dat als in een bepaald gebouw de switch down gaat (door stroomstoring bv.) dat een aantal vlan interfaces op de core switch down en up gaan. Wat het extra vervelend maakt is dat ook het vlan interface naar de firewall toe ook down en vervolgens weer op komt. Ik kan eigenlijk niet helemaal verklaren waarom dit gebeurt? Heeft dit met spanning tree timers te maken? Er zit dus geen poort geconfigureerd op het vlan wat down gaat aangezien de firewall middels een trunk is uitgekoppeld.

Wat ik eigenlijk zou willen is die vitruele interfaces altijd up blijft. Ik vond op internet het commando "no autostate" Iemand ervaring met soortgelijke situatie?

[CyBeR]

Het is supernuttig om te vermelden wat voor core switch je eigenlijk hebt...

[Rotty]

CyBeR schreef op maandag 15 augustus 2011 @ 16:28:
Het is supernuttig om te vermelden wat voor core switch je eigenlijk hebt...

Excuse me... cisco 3750 is de core switch (stack)... Helaas ondersteund het IOS (deze is verouderd) geen "no autostate" ... De switch die down gaat is een 2950..

[ Voor 5% gewijzigd door Rotty op 15-08-2011 17:12 ]

[Rotty]

Natuurlijk zijn er wel opties om dit op te lossen; ik zou bijvoorbeeld een interface op de core kunnen opofferen en deze in access mode zetten in dit vlan en er iets achterhangen maar goed dat is natuurlijk een waste van een toch wel dure switchpoort en eigenlijk een trieste oplossing.. Ik ben vooral benieuwd naar het hoe en waarom ..

ik heb namelijk meerdere trunks waarbij alle vlan's op allowed staan ik. Voor zover mij bekend is een vlan up als je er of een access port aan gekoppeld hebt met een actief device (e.g. mijn oplossing zoals ik hierboven aangeef) of een trunk port hebt geconfigureerd waar dit vlan ook over mag... Dit laatste is dus het geval ik heb meerdere trunks met nagenoeg alle vlans op allowed (iig de betreffende vlans mogen erover) dus snap ik niet waarom dit vlan down en up gaat? terwijl andere vlan gewoon up blijven....

[xares]

no shutdown?

Weet niet of dit werkt bij een VLAN? Of begrijp ik je verkeerd.

[Vorkie]

Voor een netwerk met 110 switches is het volgende ingesteld:


spanning-tree mode pvst
spanning-tree loopguard default
spanning-tree portfast default
spanning-tree extend system-id
spanning-tree vlan <VLAN> priority 8192

die laatste regel kan wel eens bepalend zijn...

[Kabouterplop01]

Als er geen actieve switchport in een L3 vlan meer is gaat het L3 vlan up/down.
Zover ik weet kun je het omzeilen met (no) keepalives, maar dan moet de L3 interface minimaal 1x up/up zijn geweest. Ik weet dat dat bijv werkt op een 6509, 18xx (router), maar ik weet niet of dat op een 3750 werkt.

[ Voor 20% gewijzigd door Kabouterplop01 op 15-08-2011 23:20 ]

[Rotty]

Vorkie schreef op maandag 15 augustus 2011 @ 20:29:
Voor een netwerk met 110 switches is het volgende ingesteld:


spanning-tree mode pvst
spanning-tree loopguard default
spanning-tree portfast default
spanning-tree extend system-id
spanning-tree vlan <VLAN> priority 8192

die laatste regel kan wel eens bepalend zijn...

Kijk de laatste regel zette mij inderdaad aan het denken... Het blijkt dat de switch die down gaat toevallig (eigenlijk niet toevallig) de root-bridge voor het vlan naar de firewall is .....Dus nogal logisch dat ie even het vlan van de firewall down gaat. Ik weet dat je per vlan de prio kan aanpassen maar was er ook niet een algemeen commando waarme je forced dat een bepalde switch altijd de root is ook als je later een nieuwe vlans aanmaakt (ik draai rapid pvst)

[bazkar]

Je wilt inderdaad de root van je spanning tree netwerk meestal niet aan het netwerk zelf overlaten en het is qua design meestal slim om de Layer 3 core (in dit geval je 3750) ook meteen root van je L2 spanning tree te maken.

spanning tree vlan X root primary

is het commando dat dit doet (dit geeft in de config een soortgelijke entry terug als in de post van Thanetrunner)

Als je meerdere cores zou hebben die HSRP draaien en waarvan bv. de ene de ene helft van de VLANs primary router is en de andere de andere helft, dan kun je ook nog rapid-pvst (rapid per vlan spanning tree) draaien om te zorgen dat de ene HSRP member root is voor de ene helft van de VLANs en de andere voor de andere helft.

In dat laatste geval is het slim om op de niet actieve HSRP member het commando:

spanning tree vlan x root secondary

te geven, zodat bij uitval van je primary HSRP router de spanning tree niet alsnog zelf op zoek gaat naar een root.

[Rotty]

bazkar schreef op dinsdag 16 augustus 2011 @ 09:42:
Je wilt inderdaad de root van je spanning tree netwerk meestal niet aan het netwerk zelf overlaten en het is qua design meestal slim om de Layer 3 core (in dit geval je 3750) ook meteen root van je L2 spanning tree te maken.

spanning tree vlan X root primary

is het commando dat dit doet (dit geeft in de config een soortgelijke entry terug als in de post van Thanetrunner)

Als je meerdere cores zou hebben die HSRP draaien en waarvan bv. de ene de ene helft van de VLANs primary router is en de andere de andere helft, dan kun je ook nog rapid-pvst (rapid per vlan spanning tree) draaien om te zorgen dat de ene HSRP member root is voor de ene helft van de VLANs en de andere voor de andere helft.

In dat laatste geval is het slim om op de niet actieve HSRP member het commando:

spanning tree vlan x root secondary

te geven, zodat bij uitval van je primary HSRP router de spanning tree niet alsnog zelf op zoek gaat naar een root.

Helemaal mee eens! Echter stel ik hierbij nog steeds de root per vlan in (vlan X) als ik dan later een nieuw vlan aanmaak en dit wordt vergeten wordt de oudste switch dan toch weer de root voor dat VLAN? (prio+mac). Ik meende mij te herinneren dat er ook een commando was om een root altijd de root te laten zijn ook voor later aan te maken vlans? <edit> dus gewoon een vlan range ingeven en klaar... bedankt voor het meedenken!

[Predator]

Kabouterplop01 schreef op maandag 15 augustus 2011 @ 23:17:
Als er geen actieve switchport in een L3 vlan meer is gaat het L3 vlan up/down.
Zover ik weet kun je het omzeilen met (no) keepalives, maar dan moet de L3 interface minimaal 1x up/up zijn geweest. Ik weet dat dat bijv werkt op een 6509, 18xx (router), maar ik weet niet of dat op een 3750 werkt.

Het juist commando daarvoor is "no autostate".
Maar op een switch met trunks is dat normaal nooit een probleem.

Dat is meestal handig op WAN routers met een switch aan de LAN kant en waar de VLAN 1 interface je local L3 interface is.
Geen actieve clients -> geen switch port online -> VLAN 1 down -> local subnet uit de WAN routering -> niet zo handig ;-)

bazkar schreef op dinsdag 16 augustus 2011 @ 09:42:
Je wilt inderdaad de root van je spanning tree netwerk meestal niet aan het netwerk zelf overlaten en het is qua design meestal slim om de Layer 3 core (in dit geval je 3750) ook meteen root van je L2 spanning tree te maken.

spanning tree vlan X root primary

is het commando dat dit doet (dit geeft in de config een soortgelijke entry terug als in de post van Thanetrunner)

spanning tree vlan X root primary

Geeft normaal hetzelfde als spanning tree vlan X 24576.
Je zet inderdaad best

code:

spanning tree vlan 1-1000 root primary

op je core switch.

Als je meerdere cores zou hebben die HSRP draaien en waarvan bv. de ene de ene helft van de VLANs primary router is en de andere de andere helft, dan kun je ook nog rapid-pvst (rapid per vlan spanning tree) draaien om te zorgen dat de ene HSRP member root is voor de ene helft van de VLANs en de andere voor de andere helft.

In dat laatste geval is het slim om op de niet actieve HSRP member het commando:

spanning tree vlan x root secondary

te geven, zodat bij uitval van je primary HSRP router de spanning tree niet alsnog zelf op zoek gaat naar een root.

Akkoord voor de secondary, maar ik zie geen reëel nut in het het verdelen van de spanning-tree root voor alle VLAN's over 2 L3 switches...

Vorkie schreef op maandag 15 augustus 2011 @ 20:29:
Voor een netwerk met 110 switches is het volgende ingesteld:


spanning-tree mode pvst
spanning-tree loopguard default
spanning-tree portfast default
spanning-tree extend system-id
spanning-tree vlan <VLAN> priority 8192

die laatste regel kan wel eens bepalend zijn...

110 switches en je core switch speelt mee in L2 spanning tree

[Kabouterplop01]

thnx for the explenation, added to more knowledge...

[bazkar]

Predator schreef op woensdag 17 augustus 2011 @ 22:51:
[...]

Akkoord voor de secondary, maar ik zie geen reëel nut in het het verdelen van de spanning-tree root voor alle VLAN's over 2 L3 switches...

Het nut is tweeledig als je uitgaat van een dubbele ster topology. Dat wil zeggen dat al je switches (of een gedeelte in ieder geval) 2 uplinks hebben, 1 naar beide cores.

Allereerst krijg je dan loadbalancing over je uplinks wat de performance ten goede kan komen (je 2 cores kunnen bv. met een dikkere lijn aan elkaar hangen dan er richting je andere switches gaat).

Bovendien heb je dan out of the box monitoring op je redundante links aangezien er geen passieve links zijn. Als er een link uitvliegt dan zie je een spanning-tree change. Als de passieve link er uit vliegt in een normale spanning tree merk je dat nauwelijks.

[Predator]

bazkar schreef op dinsdag 23 augustus 2011 @ 12:03:
[...]


Het nut is tweeledig als je uitgaat van een dubbele ster topology. Dat wil zeggen dat al je switches (of een gedeelte in ieder geval) 2 uplinks hebben, 1 naar beide cores.

Allereerst krijg je dan loadbalancing over je uplinks wat de performance ten goede kan komen (je 2 cores kunnen bv. met een dikkere lijn aan elkaar hangen dan er richting je andere switches gaat).

Bovendien heb je dan out of the box monitoring op je redundante links aangezien er geen passieve links zijn. Als er een link uitvliegt dan zie je een spanning-tree change. Als de passieve link er uit vliegt in een normale spanning tree merk je dat nauwelijks.

Cross stack LACP, VPc, VSS, take your pick ... all of those beat spanning-tree loadbalancing zowel op redundancy als op loadbalancing vlak ...

Convergence time is ook veel hoger, met uitzondering van een 2960s stack (10 secs dacht ik ?)
Al de rest is < 1 sec.

[bazkar]

Predator schreef op dinsdag 23 augustus 2011 @ 12:22:
[...]

Cross stack LACP, VPc, VSS, take your pick ... all of those beat spanning-tree loadbalancing zowel op redundancy als op loadbalancing vlak ...

Convergence time is ook veel hoger, met uitzondering van een 2960s stack (10 secs dacht ik ?)
Al de rest is < 1 sec.

Convergence time van rapid-pvst is in mijn ervaring ook altijd <1 sec

Cross-stack LACP kan niet als je meedere core switches in verschillende ruimtes hebt staan.

Lang niet alle L3 devices ondersteunen VSS (voor zover mij bekend is dat een cisco only techniek op 6500 en hoger/nieuwer) en dit geldt nog meer voor vpc dat alleen op een Nexus draait iirc.

Dus als je 2 server ruimtes hebt met in beide ruimtes een 3750 stack als collapsed core en je wilt je veldswitches allemaal dubbel uplinken naar beide cores dan is rapid-pvst in mijn ogen de beste oplossing.

[Predator]

Euhm, rapid-pvst is ook cisco only hé

Niet al je devices moeten dat ondersteunen, enkel de cores, en zooooo duur is nexus 5k nu ook weer niet.
VSS & VPc werken ook over grote afstanden, voor een 3750 stack heb je gelijk ivm je 2 serverzalen.
Maar dat is toch een vrij uitzonderlijke situatie ...

Als je maar 1 lokatie hebt, dan heb je meestal maar 1 serverzaal ivm de hoge kosten aan infrastructuurvoorzieningen in een serverzaal. Heb je 2 datacenters, dan zet je die 2de meestal wel een paar km verder

SPT kan goed werken, en lang goed werken, maar het is al jaren dat het gebruik ervan ontmoedigd wordt, en cross-chassis LACP aangemoedigd wordt voor redundante uplinks. Andere vendors hebben ook al dergelijke mogelijkheden.

Je begint er zelf al over met die VSS/VPc ivm cross-vendor interoperability, maar SPT is daarvoor slechter dan iets simpel als LACP. Wil je volledig rapid-pvst draaien zit je ook nog vast aan Cisco, ook voor de access layer...

Maar euh ... het kan best goed werken . Ik heb het zelf ook nog gebruikt toen er nog geen andere oplossingen waren. Ooit wel 1 keer wat raars gezien, maar dat was ook wel wat mijn eigen fout.
Een security appliance aangesloten die achteraf een SPT agent bleek te hebben en dus gewoon doodleuk meedeed in de SPT...
Behalve dat 1 akkefietje heb ik zelf ook nooit problemen mee gehad. Maar het is gewoon inferieur aan de huidige oplossingen die daarbovenop ook nog eens veel minder pitfalls hebben.

[Vorkie]

Predator schreef op woensdag 17 augustus 2011 @ 22:51:

[...]

110 switches en je core switch speelt mee in L2 spanning tree

Lang verhaal

gaat dan wel om de 6000 series in HSRP waar alle ser's verbonden zijn middels glas. Komt alweer uit 2005/6 maar "ff" een netwerk vervangen