[cisco] Object o.i.d. tracking t.b.v. redundancy

[idef1x]

Ik heb een cisco 836 DSL router aan internet hangen, welke communiceerd met een server hier op kantoor. Deze router heeft ook een ISDN backup, die inbeld op een router op kantoor, wanneer de DSL verbinding faalt.
Dit werkt verder prima, maar nu wil ik eigenlijk iets zien te implementeren dat de 836 router de server pingt, oid, om de bereikbaarheid hiervan via internet te testen. Indien deze test faalt moet de ISDN backup actief worden gemaakt.

De cisco docs verwijzen naar het SAA (Service Assurance Agent) gebeuren, waar men het over tracking object e.d. heeft, zodat je iets krijgt als :

code:

rtr 1
 type echo protocol ipIcmpEcho <te pingen server>
rtr schedule 1 start-time now life forever
access-list 101 permit icmp any host <te pingen server> echo
ip local policy route-map MY_LOCAL_POLICY
route-map MY_LOCAL_POLICY permit 10
  match ip address 101
  set ip next-hop <ISP next hop>
  set interface null0
track 123 rtr 1 reachability
ip route 0.0.0.0 0.0.0.0 <ISP next hop> track 123
ip route 0.0.0.0 0.0.0.0 <kantoor inbelrouter's IP address> 254

Welnu klinkt leuk en lijkt precies te doen wat ik wil bereiken, doch in de IOS ( 12.2(13) ) van de 836 kan je dat commando track 123 rtr ... niet geven

Cisco zelf lijkt aan te geven dat deze feature ook alleen maar bestaat in de enterprise IOS versies en aangezien dat betekend dat er een fix aantal routers dan geflashed moeten gaan worden, vraag ik me af of er nog andere manieren zijn om toch hetzelfde te bewerkstelligen met de standaard 836 IOS versie?
Alle tips/hints zijn natuurlijk welkom

[Yalopa]

wil je dit wel met ping?

stel nu:

DSL gaat 's nachts down, maar de lijn word niet gebruikt omdat er geen nood aan is, isdn neemt over, telefoonkost loopt voor niets...

[idef1x]

Hmm ja daar noem je iets...Dat wil ik idd ook weer niet, maar dat valt denk ik wel af te dichten met een juiste dialer profile en een juiste access list oid. Het gaat mij er in 1e instantie om dat de routering wordt bepaald a.d.h.v het wel of niet bereikbaar zijn van die server via internet. Die probes (of het nu icmp of tcp zou worden maakt mij in 1e instantie niet uit) moeten uiteraard niet over de ISDN lopen wanneer de routering omgegooid is, want dan blijft ie idd open staan. Ik denk dat dit ook wel afgevangen kan worden met een acces-list .

[Verwijderd]

Interessante feature, wist ik niet, ik weet wel dat het open en dicht zetten van een verbinding
met timed access-lists kan

[MeatGrinder]

Een mogelijke oplossing is het aanmaken van een GRE tunnel met keepalives tussen beide VPN eindpunten. De GRE tunnel beveilig je dan weer met ipsec. Voordeel hiervan is dat je op beide routers een tunnel interface hebt die naar een 'down' status gaat als er ergens in het pad tussen de routers iets mis gaat. Door middel van een floating static route (of een ander backup mechanisme) kun je de ISDN interface activeren in het geval van een storing.

[Adze]

Het is mogelijk een bgp sessie tussen de router en de server op te zetten en die de routering laten verzorgen. Valt de bgp sessie uit, dan schakel je middels floating static over op inbel...

Je kan eventueel het "backup interface" commando op je DSL interface gebruiken.

Of, zoals al genoemd werd, een tunnel maken tussen server en router.

[idef1x]

Misschien dat een GRE tunnel wel wat kan worden in dit verhaal. Dank voor de tip.

Het "backup interface" commanda kan ik hier niet gebruiken, want dan schakeld ie de ISDN pas in als de DSL link down gaat en niet wanneer er verder op in het netwerk (internet dus) connectiviteits problemen zijn. Tevens zou ik dan ook niet meer de mogelijkheid hebben om in te bellen op die 836 router vanaf kantoor, want de BRI wordt dan passief gezet.

BGP klinkt mij een beetje erge overkill in deze opzet

[ Voor 9% gewijzigd door idef1x op 14-01-2005 07:15 ]

[Verwijderd]

Kan je er geen nieuwere IOS die dat wel ondersteund op zetten dan?

Een andere optie is mogelijk dialer-watch configureren. Daar heb je waarschijnlijk ook een tunnel icm een routing protocol voor nodig.

[ Voor 52% gewijzigd door Verwijderd op 14-01-2005 07:38 ]

[Pogostokje]

Verwijderd schreef op vrijdag 14 januari 2005 @ 07:33:
Kan je er geen nieuwere IOS die dat wel ondersteund op zetten dan?

Dat is ofwel duur, ofwel illegaal.

[Verwijderd]

Pogostokje schreef op vrijdag 14 januari 2005 @ 08:54:
[...]

Dat is ofwel duur, ofwel illegaal.

Ik ziet het al idd, kan alleen met Enterprise IOS. Overheen gelezen

[ijdod]

Eea is nogal afhankelijk van de versie. Er komen erg veel features bij met elke release op de 830 serie. Hefet gevolgen voor flash een geheugen eisen, uiteraard. De 12.3.11T2 plus (c837-k9o3sy6-mz.123-11.T2) accepteert het genoemde track commando ondersteunt in elk geval op de 837.

[ Voor 8% gewijzigd door ijdod op 14-01-2005 13:14 ]

[idef1x]

ijdod schreef op vrijdag 14 januari 2005 @ 13:11:
De 12.3.11T2 plus (c837-k9o3sy6-mz.123-11.T2) accepteert het genoemde track commando ondersteunt in elk geval op de 837.

Hmmm dus de POTS versie doet ut wel....das interessant..toch nog maar eens bij onze leverancier navraag doen dan. Lijkt me dan sterk dat de 836 het dan niet aan zou kunnen.
Tnx voor de info

[idef1x]

Verwijderd schreef op vrijdag 14 januari 2005 @ 07:33:
Kan je er geen nieuwere IOS die dat wel ondersteund op zetten dan?

Ik begreep zelfs van de levernacier dat de versie die ik had top of the hill was voor deze router. Zet ik dus nu mijn bij.

Een andere optie is mogelijk dialer-watch configureren. Daar heb je waarschijnlijk ook een tunnel icm een routing protocol voor nodig.

Hmm ook een idee idd...Goeie tip...dank...
Ut wordt tijd om eens alle features in mijn kop te stampen denk ik

[idef1x]

Ola,

Het heeft even geduurd, maar ja "moest" tussendoor weer andere dingen doen van de baas..
Afijn de 836 met de image c836-k9o3s8y6-mz.123-8.YA kan ik inderdaad ook de juiste commando's geven. Nu nog eens kijken of ie inderdaad doet wat ik wilde...

Heb nog even het met een tunnel geprobeerd, maar die tunnel wilde niet down gaan vreemd genoeg. Zelfs niet wanneer ik de remote seriele interface op shut had gezet. Kennelijk wordt de tunnel niet gechecked op connectiviteit, zoals ik had gehoopt...

[Verwijderd]

De simpelste oplossing is inderdaad een pakketje versturen naar een andere router. Keepalive Op het moment dat er geen reply komt vindt de trigger op je router plaats om de ISDN BRI in te schakelen. Zodoende wordt deze getriggerd als er geen pakketjes over en weer gaan en niet pas zodra het dsl-signaal down gaat (want vaak is dit niet het geval). Succes...