Cisco back-up router/switch voor inter-vlan routing

[Verwijderd]

Ik heb een vraag waarvan ik niet zeker weet of er een antwoord op is.

Ik heb een netwerk met een flinke Cisco router, met daaronder een enorme hoeveelheid switches (redundant uitgevoerd) waarop de vlans lopen (incl. VTP e.d.). Er zijn vier vlans in totaal: 10, 20, 30 en 100. De servers lopen op vlan 100, de overige zijn voor de verschillende gebruikers groepen.

Wanneer de router uitvalt zou het mooi zijn als de layer3 switch de inter-vlan routering oppakt, en er voor zorgt dat de client computers als nog bij de servers kunnen komen. Dit is wenselijk omdat de shares, home directories en interne mail dan nog bereikbaar is. Het internet en de ACLs zijn dan niet meer beschikbaar, maar daar valt (voor korte tijd) mee te leven.

Wat is de beste manier om dit gedaan te krijgen? Alvast bedankt!

Zeer simpel netwerk overzicht:

[TrailBlazer]

VLAN interfaces in combinatie met HSRP.

[Verwijderd]

zoek eensop HSRP, VRRP of GLBP, alledrie protocollen voor router-redundancy. Je moet dan tussen de L2-switch en de L3 switch een trunk maken waar alle VAN's in zitten (zoals je waarschijnlijk nu al naar je router hebt).

Overigens: waarom laat je de L3 switch niet sowieso de inter-VLAN routering oppakken? Dat doet hij waarschijnlijk veel sneller (want in hardware) dan de router (die dat in software doet).

[rvnieuwh]

Ik zou zeggen: zet het Default Gateway address richting de Layer 3 Switch.
Bij ons staat dus de L3 Switch (in jouw plaatjes als voorbeeld) tussen de Router en de Switch.
Zo is het iig bij ons ingeregeld op de zaak.
Dan kan de rest uitvallen (richting de buitenwereld) maar blijft alles intern lekker doorwerken.

[TrailBlazer]

dat kan ook alleen dan kan je niet meer internetten als je L3 switch eruit ligt. Je zou dan eigenlijk de L3 switch redundant willen hebben.

[johnkeates]

Daar zijn dacht ik protocollen voor, als ik me niet vergis vallen VLAN configuraties (deels?) onder het algemene routing configuratie idee. Wat je nodig hebt is een protocol (misschien dat je BGP er voor kan misbruiken) waarmee je floating static routes kan 'synchroniseren' tussen verschillende routeringsplatformen. Als de Layer3 switch alleen maar RIP heeft kan dat wat lastiger worden. Ik weet van de software van beide routers niet of ze het toestaan om zelf scripts/acties te runnen als er een fail event plaatsvindt.. Misschien dat je eerder met CARP aan de slag moet, daar kan je ook Vlan's in gebruiken met de juiste instellingen..

Het is maar een idee, CARP, misschien dat je juist meer met andere protocollen moet werken voor dat soort redundante oplossingen, OSLRD is voor wifi bedacht maar kan ook met bedrade netwerken met vlan's gebruikt worden. OSPF is voor wat anders bedacht, maar kan met de juiste configuratie ook werken als redundante oplossing van routing informatie. (Om dat er maar 1 route tegelijk mogelijk is en bij een fail de route wegvalt en een andere gemaakt wordt heb je een soort automatische omschakeling naar nieuwe routing informatie - ik heb alleen geen idee hoe dat terugvalt bij herstel.. in de praktijk nooit last mee gehad)

In principe heb je gewoon een soort routing table nodig dat constant bijgewerkt wordt en bij het uitvallen van de router actief wordt. De vraag is waar je dat wil doen. Als de Layer 3 switch het kan zou ik het daar doen, om dat die de servers 'beschermt'.

[WhizzCat]

offtopic:
OSPF kan je met behulp van Priority en fallback zo instellen dat een bepaalde route voorkeur heeft en als die route weer beschikbaar is, weer terug switched via de "core router".

Als ik zou moeten kiezen, zou ik de Router er uit halen en een 2e L3 switch d'r in zetten of een 2e router. Je gaat nu nl. HSRP of VRRP (wat niet eens kan op Cisco afaik) doen op 2 verschillende devices, dat is niet erg handig, ook niet vanuit beheer oogpunt. Mocht het écht niet anders willen, zou ik toch OSPF gaan onderzoeken. Dat is de meest "compatible" oplossing denk ik. Mocht je nog 3rd party apparatuur willen inzetten bv.

[TrailBlazer]

dude wat ben je van plan? Dit is echt met een slagschip een mug aanvallen. HSRP kan echt alles wat je wil in dit geval.

[Verwijderd]

Ik zou inderdaad de layer3 switch als gateway kunnen laten functioneren, en hem al het inter-vlan verkeer laten verwerken. Alleen mis ik dan mij ACLs e.d. , en dat is niet echt een oplossing. Dit omdat we in dit netwerk strak willen kunnen filteren in het verkeer, de gebruikers van vlan 30 mogen bijvoorbeeld onder geen beding in vlan 10 of 20 komen.

HSRP, VRRP en GLBP heb ik even bekeken, maar is dit niet meer iets om te gebruiken tussen bijvoorbeeld twee verschillende locaties? Ik heb het idee dat ik het complete netwerk in stukjes moet hakken met deze protocollen. Met als gevolg enorme investeringen en een netwerk dat een stuk complexer is. Of zie ik nu een hoop beren op de weg?

[TrailBlazer]

Nee HSRP wordt juist binnen een site gebruikt. Binnen het klassieke core distributie access design doen de 2 distributie routers HSRP met elkaar voor alle VLAN's. Als je trouwens strak verkeer wil filteren koop dan een firewall. Ik ben redelijk strict daarin. Een router routeerd en filtert niet.

[battler]

Zo zou het moeten denk ik voor jouw situatie. Je zou zelf even het Datacenter gedeelte moeten bekijken dit is afhankelijk van het aantal servers e.d maar ook daar zou je VRRP kunnen gebruiken. ACL's op beide distributie switches dan hoef je je daar ook geen zorgen meer over te maken?

[ Voor 68% gewijzigd door battler op 26-04-2010 14:08 ]

[Predator]

Je zoekt oplossing voor problemen die niet bestaan.

Zoals al door meerdere personen gezegd gebruik je HSRP/VRRP/GLBP.
Een router als inter-vlan router gebruiken is iets wat je normaal alleen in kleine LAN's en bijkantoren doet.
Anders doe je dat op een ML switch. Als je niet vies bent bent van (onduidelijke) ACL's in een router in deze opzet maakt dat weinig uit of je die ACL's naar de ML switch verhuist, tenzij ze stateful zijn.

Zie schema battler (alleen zonder de bovenste 2 ML switches). Gebruik L2 redudantie uplink protocollen (Spanning-tree met uplinkfast/backbonefast of flexlinks of portchannel als je ML switches multichassis portchannel kan). Zo los je L2 redundantie op.
De L3 redundantie doe je dan met bv. HSRP of GLBP (GLBP heeft weinig nut bij ML switches vind ik omdat je daar geen performance issues hebt).

Wil je echt duidelijke filtering koop dan een firewall(cluster). Zoals trailblazer zegt, daar zijn die dingen voor gemaakt. Zeker als je vaak wijzigen moet uitvoeren. Want een router/switch ACL is echt niet overzichtelijk.


Ik begrijp ook niet goed dat je van enorme hoeveelheiden rendundante switches spreekt en dan maar 1 ML switch en 1 router hebt

[ Voor 10% gewijzigd door Predator op 26-04-2010 15:05 ]

[battler]

Ik was ook in de veronderstelling dat het router-on-a-stick niet meer werd gebruikt. Ik heb vrij weinig ervaring met netwerken maar volgens mij gebruik je een router nu alleen nog maar voor media vertaling. Zeker als je een hoop access switches hebt zoals je al aangeeft dan is dit concept onwenselijk.

[ Voor 25% gewijzigd door battler op 26-04-2010 15:22 ]

[Predator]

battler schreef op maandag 26 april 2010 @ 15:21:
Ik was ook in de veronderstelling dat het router-on-a-stick niet meer werd gebruikt. Ik heb vrij weinig ervaring met netwerken maar volgens mij gebruik je een router nu alleen nog maar voor media vertaling.

Dat is misschien wel iets te kort door de bocht.

Er is nog altijd een verschil tussen een router en een ML switch in functionaliteit. Veel WAN access is nu ook al ethernet geworden en de 'media vertaling' is zeker te kort door de bocht.

Je kan ook nog altijd een router-on-a-stick/one-armed router inzetten om te router tussen 2 (of meer) VLAN's. Als de andere VLAN bv een externe partij interconnectie is. Die shit wil je niet configuren in je L3 LAN core.

[battler]

Strikt genomen hoeft dat toch ook niet op core? In een ideale situatie komt het toch binnen op je Edge Distribution?

_{Dit gaat mijn petje al redelijk te boven dus hecht hier niet/nauwelijks waarde aan.}

[ Voor 29% gewijzigd door battler op 26-04-2010 15:47 ]

[Verwijderd]

WhizzCat schreef op maandag 26 april 2010 @ 13:51:
Als ik zou moeten kiezen, zou ik de Router er uit halen en een 2e L3 switch d'r in zetten of een 2e router. Je gaat nu nl. HSRP of VRRP (wat niet eens kan op Cisco afaik) doen op 2 verschillende devices, dat is niet erg handig, ook niet vanuit beheer oogpunt.

HSRP en VRRP kunnen prima tussen 2 verschillende devices.
en VRRP kan ook prima op een Cisco geconfigureerd worden. In principe: vervang "standby" door "vrrp" en je configureert het net als HSRP... (in principe, want er zijn wel wat verschillen).

Mocht het écht niet anders willen, zou ik toch OSPF gaan onderzoeken. Dat is de meest "compatible" oplossing denk ik. Mocht je nog 3rd party apparatuur willen inzetten bv.

En hoe ga je dan je clients en servers naar de juiste gateway sturen? Of ga je die ook allemaal van OSPF voorzien?

[Verwijderd]

De tekening is een enorme versimpeling van de huidige situatie, daar waar 'switch' staat moet eigenlijk 'switches' staan. Ook gebruik ik geen router on a stick, maar heeft elk vlan gewoon zijn eigen poortje op de router. Dit is qua beheer het fijnst en qua snelheid het beste. Op die manier kunnen we elke vlan specifiek routeren.

Allereerst ga ik de ACLs maar eens verplaatsen naar de twee switches in de distributie laag die het meest dichtbij de router staat in de core.

Vervolgens die twee switches als layer 3 uitvoeren, om daarin aan te geven dat het verkeer voor vlan 100 de ene kant op moet en al het overige verkeer naar de router.

In hoeverre is het nog belangrijk om de core router dubbel uit te voeren als ik de distributie laag al een route heb naar het vlan 100 netwerk? Op die manier is er alleen geen internet meer, maar dat is niet het grootste punt. Wel vraag ik me af wat dan je gateway zal worden?

[Predator]

Waarom move je nu toch gewoon niet alle inter-vlan naar 2 ML switches zoals iedereen zegt ?

Even een illustratief VB'tje met HSRP:

ML L3 switch 1 (active)

code:

interface Vlan100
 description ### Server VLAN Active ###
 ip address 10.100.0.2 255.255.255.0
 standby version 2
 standby ip 10.100.0.1
 standby preempt
 standby name HSRP_SERVER
!
interface Vlan10
 description ### Clients_A VLAN Active ###
 ip address 10.10.0.2 255.255.255.0
 standby version 2
 standby ip 10.10.0.1
 standby preempt
 standby name HSRP_CLIENTA
!
ip route 0.0.0.0 0.0.0.0 [IP router]

ML L3 switch 2 (standy)

code:

interface Vlan100
 description ### Server VLAN Standby ###
 ip address 10.100.0.3 255.255.255.0
 standby version 2
 standby ip 10.100.0.1
 standby priority 99
 standby preempt
 standby name HSRP_SERVER
end

interface Vlan10
 description ### Clients_A VLAN Standby ###
 ip address 10.10.0.3 255.255.255.0
 standby version 2
 standby ip 10.10.0.1
 standby preempt
 standby priority 99
 standby name HSRP_CLIENTA
!
ip route 0.0.0.0 0.0.0.0 [IP router]

Op je router routeer je dan de interne vlan subnetten naar het HSRP adres van de ML switches.

Je kan nog interface tracking en authenticatie toevoegen als je wilt.

De migratie kan je zelfs heel snel doen zonder al te veel miserie, als je weet wat je doet.
Procedure:
• Espresso of redbull drinken
• Interface herconfiguren op de router met HSRP router met een hogere prio (bv 110).
Natuurlijk behoudt je als HSRP standby IP het huidige interface IP (en neem je voor de router zelf een nieuw).
Zo verandert er voor je client (bijna) niets. Er komt wel een nieuw MAC adres overeen (tenzij je standby use-bia gebruikt) met het DF GW adres met er komt ook een GARP om dat op te lossen.
• Beide ML switches volledig configureren (de 2de met laagste prio zal niet deelnemen voorlopig).
• Je router is dan active and je hoogste ML switch is dan standby.
• Prio verlagen op de router van HSRP op de interface naar de laagste prio van allemaal.
• Hierdoor zal je hoogste ML switch actief worden en je lagere ML switch standby. De router (met nu de laagste HSRP prio) doet dan niet meer mee.
• De routering loopt nu nog wel assymetrisch omdat je router nog zijn interfaces voor de vlan's allemaal heeft + de routering.
Maar dat geeft niet als je geen Unicast RPF (anti-spoof) actief hebt. Anders kuis je dat op samen met de aanpassing HSRP prio op de router 2 stappen geleden.
• Check alles OK
• Koffie'tje drinken
• Routering op de router opkuisen.
• Interfaces opkuisen op de router (delete/shutdown van de nu onnodige interfaces)
• ACL/QoS .e.d. overzetten naar de ML switches.
• Volledige opkuis op de router
• Laatste koffie'tje drinken

Ik heb zo'n dingen gewoon al online gedaan zonder enige downtime.
Desnoods doe je eerst alles eens met een test VLAN...

[Predator]

battler schreef op maandag 26 april 2010 @ 15:47:
Strikt genomen hoeft dat toch ook niet op core? In een ideale situatie komt het toch binnen op je Edge Distribution?

_{Dit gaat mijn petje al redelijk te boven dus hecht hier niet/nauwelijks waarde aan.}

Niet te veel de Cisco design pap opeten zonder te kijken of er brokken inzitten

[battler]

Ik ben van plan een theoretische netwerkdesginer te worden .

_{Disclaimer: Ik zit nog op school en heb net mijn CCDA gehaald.}

[TrailBlazer]

dat heet architect en die denken enkel in wolkjes en lijntjes. Vervolgens zeggen ze de details doen er op dit moment niet toe en flikkeren ze het geheel over de schutting

[Verwijderd]

TrailBlazer schreef op dinsdag 27 april 2010 @ 13:00:
dat heet architect en die denken enkel in wolkjes en lijntjes. Vervolgens zeggen ze de details doen er op dit moment niet toe en flikkeren ze het geheel over de schutting

Klopt details over configs zijn voor de jongens op de werkvloer, de ccna-ers en ccnp-ers

De architecten/consultants, trekken de juiste lijntjes, bepale welke apparaat met wel apparaat verbonden wordt, en wat de verbinding is. Simpel toch

[Verwijderd]

Predator schreef op dinsdag 27 april 2010 @ 10:20:
{uitleg}

Dat gaat hem worden dan. Ik kan dit helaas niet testen in Packet Tracer, dus eens kijken of ik het eerst op layer3 switches kan testen. Nog nooit gedaan namelijk, erg bedankt voor de hulp allen!

[TrailBlazer]

zorg ook dat je STP root de L3 switch is die ook de HSRP master is. Als je het echt goed doet zorg je ook dat de HSRP master het hoogste echte ip heeft. Dit is eigenlijk alleen van belang als je multicast verkeer hebt.

[Verwijderd]

Het lijkt me niet dat hij STP nodig heeft als het plaatje in zijn post z'n volledige topologie betreft.

[battler]

De tekening is een enorme versimpeling van de huidige situatie, daar waar 'switch' staat moet eigenlijk 'switches' staan. Ook gebruik ik geen router on a stick, maar heeft elk vlan gewoon zijn eigen poortje op de router. Dit is qua beheer het fijnst en qua snelheid het beste. Op die manier kunnen we elke vlan specifiek routeren.