08-20-2004 11:40 AM - edited 03-02-2019 05:54 PM
If there are 2 sites that each have their own internet connection, with a ppp link in the middle (cisco 1720 routers), can the internet connectivity be made to fail over to the other site automatically?
Given the following scenario:
Site 1:Cisco 1720 router
--------------------------------------
FastEthernet0: 10.0.1.1 255.255.255.0
Serial0: 172.16.1.1 255.255.255.252
encap HDLC
ip subnet-zero
Router EIGRP 100
network 172.16.0.0
network 10.0.0.0
no auto-summary
ip route 0.0.0.0 0.0.0.0 10.0.1.254 (sonicwall firewall)
client configuration: DHCP
10.0.1.50-10.0.1.200
SNM: 255.255.255.0
DG: 10.0.1.1
Site 2:Cisco 1720 router
--------------------------------------
FastEthernet0: 10.0.2.1 255.255.255.0
Serial0: 172.16.1.2 255.255.255.252
encap HDLC
ip subnet-zero
Router EIGRP 100
network 172.16.0.0
network 10.0.0.0
no auto-summary
ip route 0.0.0.0 0.0.0.0 10.0.2.254 (sonicwall firewall)
client configuration: DHCP
10.0.2.50-10.0.2.200
SNM: 255.255.255.0
DG: 10.0.2.1
How can these sites internet connections be made redundant? For
example, sine the routers on each side each have a default route to
the local firewall (a sonicwall device), how can I configure these
routers so that, if the sonicwall locally is unresponsive (i.e. the
local internet connectiion is down), the router automatically routes
the connection to the default gateway of the router on the other side
of the WAN?
There has to be an easy way to make this happen. Any help is
appreciated.
Thanks!
Joe Keegan
08-23-2004 08:54 AM
The problem I see is that the internet connection is not directly connected to your Cisco 1720, and so your router doesn't know if the internet connection goes down.
Is there a way to run a routing protocol between your Sonicwall and Cisco router? If you could run, say RIP between them, then your Cisco router would know when the internet connection is down. Then redistribute RIP into EIGRP, and both of your WAN routers could have a feasible successor to 0.0.0.0.
It will be interesting to see other solutions posted.
08-23-2004 10:44 AM
An easy solution to this kind of issue is to use floating static routes. A floating static route is a static route with an administrative distance higher than normal. So long as the normal static route is usable it is used but if it becomes unusable then the floating static route is used. In your case your site 2 1720 could have configured ip route 0.0.0.0 0.0.0.0 172.16.1.1 250. The 250 at the end is what makes it a floating static route.
The difficulty with this solution is what would make the original static route (ip route 0.0.0.0 0.0.0.0 10.0.2.254) unusable. If your router Fast Ethernet interface went down then the floating static could be used. But the chances are much greater that the difficulty will be at the sonicwall than that your interface would go down. If you could set up some kind of dynamic routing so that the sonciwall advertised a default route to you, then if there were a problem with the firewall and the default stopped being advertised then the floating static route could work.
HTH
Rick
08-23-2004 04:44 PM
This is actually fairly easy to do, but it is not straightforward. You need to use SAA RTR to detect when one of the SonicWalls is no longer useful, and have that knowledge tracked in a static route defining your default route.
Do not use a floating static route to the other end of the router-to-router link for your backup static route. (Consider what happens if both SonicWall routers go down). Instead, redistribute the tracked static route into your routing protocol so the other router can learn that you have a default route, and set the admin distance on the tracked static route to more desirable than the routing protocol.
Warning: the SAA RTR capabilities required are only available today in 12.3T, which puts you on the bleeding edge of IOS releases, so budget extra time to work around any bugs you encounter.
Good luck and have fun!
Vincent C Jones
08-23-2004 08:21 PM
I started getting into the SAA RTR commands. I am currently trying to run an SAA RTR ping and track that ping for reachability, but my IOS only knows how to track interfaces or routes, not RTR objects.
Any thoughts as to why? I'm running 12.3(2)T7 on a 1700 router.
Here's what I did with RTR:
rtr 1
type echo protocol ipIcmpEcho 167.206.112.3 (internet DNS server)
rtr schedule 1 life forever start-time now
then, as per someone's advice, I tried to do:
track 123 rtr 1 reachability
but my track command won't accept that.
Am I missing anything?
08-24-2004 05:52 AM
This feature was introduced in one to the 12.3T releases, you may not have a recent enough version of 12.3T (current at 12.3(8)T, IIRC).
Vincent C Jones
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide