I have a Cisco 1811 with Dual Wan Ethernet ports. F0 is my primary and F1 is my Backup. I used the backup interface command and it the system changes to F1 without a problem as long the F0 state is down. My problem is that F0 will be hooked to a wireless bridge. If the Radio portion goes down or the receiving bridge goes down, losing connectivity to my central office, the Ethernet line stays up and the router will not fail over to the backup interface? Any suggestions how to get around this???
Rather than using interface tracking, may I suggest the use of a floating static route to your remote office. That way if the route to the main office is down due to RF link failure, the static route will automatically be used to route the data instead.
ip route 10.1.1.0 255.255.255.0 f1 150
where 150 is the AD of the route and is higher than the AD of the route which is present in the routing table as the preffered point of exit.
When the RF link fails and no routing updates are recieved by the f0 interface, the route will be automatically removed from the routing table and the floating static route will become the preferred route. The opposite will be true when the link comes back up :)
Hope this helps!
In order to get your static routes to go down when a link goes down in such an environment, you need to use the reliable static routing feature, described at:
This feature is designed for situations like yours, where the interface remains up although there is a break further downstream. The static route will be brought down when you can no longer ping a specified address through it.
Here's a sample config that I use:
interface Ethernet 0
description Main Link
ip address 10.1.1.1 255.0.0.0
interface Ethernet 1
description Backup Link
ip address 192.168.1.1 255.0.0.0
ip sla monitor 1
type echo protocol ipIcmpEcho
ip sla monitor schedule 1 life forever start-time now
track 100 rtr 1 reachability
access list 101 permit icmp any host
route-map LOCAL_POLICY permit 10
match ip address 101
set ip next-hop 10.1.1.254
set interface null0
ip local policy route-map LOCAL_POLICY
ip route 0.0.0.0 0.0.0.0 10.1.1.254 track 100
ip route 0.0.0.0 0.0.0.0 192.168.1.254 254
Hope that helps - pls rate the post if it does.
Thanks for the help. The link was extremely helpful in understanding the process. Programmed with my IP's and it works like a champ. I've searched Cisco's site for several days but must have not been using the correct terminology. Again thanks for the help!!!!!!!
We have a customer in a similar position,
will this work if the customer is using NAT ?
We have tried object tracking in the past, but were unable to get around a bug in the NAT keepalives, ie if I were to keep a ping going to say www.google.com then once the connection switched the NAT table would not refresh for www.google.com.
This should work when using NAT as well. The NAT timeout for ICMP is 60s by default. Therefore, a translation entry for ICMP could be in the NAT table for up to 60 seconds, causing the problem you observed. You can always wind down the ICMP NAT timeout so that it switches quicker.
Hope that helps - pls rate the post if it does.
I was using icmp as an example, they actually use a stockmarket monitoring program, not exactly sure how the program runs but it has the exact same problem as described. The program once started gets a continious feed and the NAT doesn't have a chance to timeout. The only way the customer is able to resolve is to get all machines to close the app and then reopen later. As im sure with any customer they are never willing to do this.
I guess if i could find out the details I can do the same thing ? I don't happen to have a 1811 handy to do any testing on, is it possible to set the timeout on ports aswell as protocols ?
Already its a step closer.. thanks heaps !.
Use the following to set a NAT timeout on a specific TCP/UDP port:
ip nat translation port-timeout [tcp|udp]
Hope that helps,
So much I could kiss you ! :)
You have no idea how much sleep I lost previously due to this issue.
I am very much a *straight* guy but I will accept the compliments :-)
Pls do try this out first, though... it is not always easy to spot subtle issues with the solution until you configure it.
heh so am I thankfully :)
I will try to get a unit to test with. Im not 100% sure it'll fix the problem, as it still relies on a timeout and I suspect the program keeps a continuous stream.
What happens when it is able to ping the primary router again ?
The configuration doesnt look to automagically revert back to the original default route.
When the tracked object gets back to an 'up' state, the original default route will displace the other static route, assuming that the original default route has a better administrative distance than the backup route.