cisco 1600 als isdn fallback

[sbE 10]

hallo,

 

ich habe hier in einem recht kleinen netzwerk (10 - 15 mitarbeiter) einen cisco 1600 übrig, welcher einmal für eine isdn-verbindung zwischen aussenstandort und zentrale benutzt wurde. seit geraumer zeit ist nun ein anderer router (bzw. eine routerlösung) per dsl im internet und baut eine vpn-verbindung zur zentrale auf.

 

folgender gedanke...

 

der 1600er soll der standardgateway für das lan werden und bei ausfall der vpn-verbindung (die ja an dem anderen router konfiguriert ist), das isdn-fallback zur zentrale aufbauen.

 

die geschichte mit den administrativen distanzen kenne ich nur im zusammenhang mit dynamischem routing. aber genau da liegt das problem...dynamisches routing will man nicht haben.

 

nun ist die frage welche andere lösung es gibt!? object tracking habe ich mir auch schon angeschaut, aber dieses feature gibts erst seit ios 12.3 - nur hat das diesre router nicht.

[sbE 10]

keiner eine idee? :(

[daking 10]

Hola,

 

du kannst das via HSRP lösen, da sollte das tracking bei älteren IOS Ver funktionieren.

einfach den VPN router als aktiven HSRP Router definieren und das interface überwachen.

Geht das Interface runter (bei der VPN Verbindung kann es sein, dass das interface nicht runter geht sondern nur die crypto Verbindung => tunnel interface) sinkt die HSRP Prio und der ISDN Router wird das aktive def Gateway => ISDN Backup

 

!

int fa0/0

standby 1 ip x.x.x.x

standby 1 priority x

standby 1 timers 1 3

standby 1 track tunnel 0 < decrement value>

!

 

Ciao

 

Thomas

[sbE 10]

ich denke das wird schlecht möglihc sein, da als vpn-router eine linux-appliance zum einsatz kommt. hsrp ist dann wohl zu viel des guten.

[Wurstbläser 10]

Hallo sBE

 

... mal ne ganz doofe Frage: wer will dynamisches Routing nicht haben? Ich bin mir ziemlich sicher daß Herr Dijkstra, Herr OSPF und Frau Rip genau an Euch gedacht haben als sie sich ihre Routingprotokolle ausgedacht haben ...

 

Musst Du denn gleich an die Administrativen Distancen - die sind doch eh nur innerhalb des Routers von Interesse. Auch statische Routen haben ja ne AD. Warum sollten den nicht zwei Routen mit zwei verschiedenen Metriken funktionieren, eine über den Tunnel, die andere über ISDN?

 

Gruss

Robert

[sbE 10]

Warum sollten den nicht zwei Routen mit zwei verschiedenen Metriken funktionieren, eine über den Tunnel, die andere über ISDN?

t

 

habe ich probiert - funzt leider nicht.

 

1. route über eth0 zu vpn-router ins web

2. route über bri0

 

wenn ich nun den vpn-router vom internet trenne macht der 1600er gar nix. der ping der workstation geht ins leere und der 1600er denkt gar nicht daran die zweite route zu "probieren". ziehe ich aber das lan-kabel des 1600 (eth0 down) springt die 2. route an und baut eine isdn-verbindung auf. aber das soll ja nicht ziel der übung sein.

[daking 10]

Hola,

 

warum sollte die statisch route mit der besseren AD auch "runter gehen". So klappt das nicht.

 

Die einzige etwas komische Möglichkeit währe auf der Gegenseite auch einen "kleinen" Cisco zu installieren. Zwischen den beiden einen Tunnel (keinen crypto tunnel) der über das VPN geroutet wird aufbauen ;Keepalives setzen. Falls das VPN ausfällt geht das Line proto des Tunnels down. Sollte dan via track mit der alten sw gehen.

 

Vielleicht hilft das ?!

 

=> kannst dann auch AD benutzen, da die route aus dem routing table verschwindet, wenn das tunnel interface line down ist...

 

Ciao

[sbE 10]

@darking

 

das klingt gar nicht mal so schlecht..."track interface xyz"...

 

nur weiß ich aus dem stehgreif gar nicht wie ich mit dem ciscos so einen tunnel realisiere. hast du vielleicht kurzer hand einen link für mich? cisco benutzt ja meist irgendwelche berzeichnungen, die ohne ahnung des syntax (oder eines teils davon) schwerlich zu finden sind.

[daking 10]

Hola,

 

local - remote einfach umgedreht

 

!

interface tunnel 0

ip address xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx

tunnel source <locales externes interface>

tunnel destination <remote interface =! tunnel ip>

tunnel path-mtu-discovery

keepalive x x

!

 

dann kannst du zwar ein Track auf das interface machen, ob du ein tracking auf routen machen kannst ist jedoch fraglich. Denke du kannst das tracking mit 16xx nur mit HSRP machen...

 

Ist jedoch kein Problem, da du nun mit AD arbeiten kannst, da der Tunnel runter geht falls dir die VPN Verbindungen über den XXXX Device abbrechen.

 

Ciao

[sbE 10]

super...ich danke dir. ich werd's mal testen.

[Wurstbläser 10]

Hallo sbE

 

darf ich nochmal nachfragen warum so eine einfache Lösung nicht in Betracht kommt? Wenn ihr eine Linux/VPN Appliance habt, die außer einem einzigen VPN Tunnel in die Zentrale keine andere Route anbieten kann, müßte man doch eigentlich nur vor diesem Gateway EINE Routing-Entscheidung zu dem ISDN-Ersatz-Gateway treffen: entweder über einen weiteren Router, oder zur Not der Routingtabellen der Hosts selbst. Dazu sind doch Router gebaut - da nützt es doch nichts wenn man sich eine Black-Box hinstellt wo man an der einen Seite eine IP eingestellt bekommt und sonst darf man ein Kabel einstecken hoffen. Dan kann man doch nur seine eigenen Router davorsetzen!?

 

(Ich bin jetzt mal davon ausgegangen das Deine Linux-Appl 2x Ethernet in/out hat, und Dein C16001xeth in und 1x ISDN out. Mit 2 Ethernetschnittstellen im 1600 könnte man den ganzen Router vor die Linux-Kiste stellen - theoretisch auch mit einer secondary IP - das ist aber nicht so "schön")

 

Gruss

Robert

[daking 10]

Hola,

 

natürlich währe es einfacher das Routing an der Appliance vorzunehmen. Ist die jedoch nicht möglich muss man zu einer Lösung kommen.

Routing am Host würde ich auf keinen Fall machen, da ist der administrative Aufwand etwas hoch. Mir ist auch nicht klar wir der Host dann merken soll wenn der primäre Pfad ausfällt.

 

Ciao