Default Static Route Failover

[jsmcniel88]

We have a dedicated T3 (se 1/0) and two back up T1s (se 0/0/0 and se 0/1/0). The previous engineer added static routes like so:

Cisco IOS Software, 3800 Software (C3845-IPBASE-M), Version 12.4(3h), RELEASE SOFTWARE (fc2)

#show ip int brief

Interface                  IP-Address      OK? Method Status                Protocol

GigabitEthernet0/0         207.1X.162.129  YES NVRAM  up                    up     

GigabitEthernet0/1         10.143.199.1    YES NVRAM  administratively down down   

Serial0/0/0                1X0.81.61.46    YES NVRAM  up                    up     

Serial0/1/0                160.81.X7.170   YES NVRAM  up                    up     

Serial1/0                  1X0.81.76.26    YES NVRAM  up                    up     

ip route 0.0.0.0 0.0.0.0 Serial1/0

ip route 0.0.0.0 0.0.0.0 1X0.81.X6.25 5

ip route 6X.41.1X8.253 255.255.255.255 Null0

Our issue is that when the t3 link fails the Internet fails over to the two t1s, when the t3 link comes back up I have to manually shut the T1s interfaces to fail the route back over to the t3. My question is what is the best way to solve this problem so the routes will fail over automatically back to the t3 when the link comes back up.

I have a read a little about IP SLAs but not sure if that is the way to go. I also do not see that command in this IOS so what IOS do i need to go to? Or can this be done another way using IPBASE?

Thanks

[sleepyshark]

(pardon my lack of memory here)...

I ran into the same issue 4-5 years back and i'm ALMOST positive that the route with the higher metric would fail over, but there was no method to fail back unless you down the secondary - which would cause it to look again for the primary.

I believe this has to with the static routing becuase I remember we had to use some other type of routing (OSPF/BGP/EIGRP) to accomplish what we wanted to do.

I'm trying to remember way back about the configs and what we did, but keep coming to the conclusion that static routing WOULD allow for fail-over but had a lot of limitations on failback. 

Are there any CCNP/CCIE's who can chime in here?

I do know that BGP would easily solve your problem, if both circuits are on the same ISP, it would be even easier for you - just have them send you partial-routes (which would avoid costly router upgrades)....

Sean

[mccmhtac1]

You only need to add the AD to the floating or failover route. To me your config is already setup that way.

I would find out what the IP address's are on the other end of the backup T1s first thing just to verify your failover routing.

I am not sure if you can use BGP over a ISP connection. Curious what others may say. I would do some testing of the failover routing. If you only

failover to one T1 disable the other before you test.

[Richard Burts]

Brian

Most certainly you can use BGP over an ISP connection. That is where BGP is most commonly used

to the original poster

Given what you have told us about the addressing of the T1s I find it difficult to see how the ISP can "bond" them in the way that IP networks usually use the term. If you are not getting good answers about it from the previous engineer, then perhaps you can ask the ISP for some clarification.

It looks to me like the failover is to a single T1 (assuming that the static routes shown in your post are all of the static routes). Adding a second floating static route to use the second T1 should be fairly straightforward.

But none of this addresses what I believe was the original problem which is that the router failed over from T3 to T1 but did not fail back when T3 came back. Can you tell us any more about this? Does it happen often? Or is it a rare thing? Would you be able to post output of show interface and show ip route during the problem?

Adding AD to the routes is quicker and easier than upgrading the IOS. So I would try them first. But frankly I am not optimistic that it would fix the underlying problem.

HTH

Rick

[jsmcniel88]

Ok so I called the ISP and dug in a little more. Turns out the subnets were wrong on the T1s and these are not bonded at all anywhere. The floating static was never set to fail to the 2nd T1 so we were only using one for backup.

So I re-did the subnets for the next hops on the T1 and re-did the routes using the next hops and added the AD to the route list. Since the subnets were wrong before I am greatly confused how this would have ever worked in the first place.

When I shut down the T3 the first T1 route is placed in the route table. The speeds show to be at T1 speeds. When I bring the T3 back up however the speed does not change. The route table shows the T3 route back in however it appears it is still using the T1 route. Only if i shut BOTH T1s down do I get the T3 speed.

So I am pretty stumped. Only thing I can think is maybe this is a bug in this IOS release and I need to upgrade to a more recent code.

Here is the new output after I made the changes. I have the two T1s shut down for now.

interface Serial0/0/0

ip address 160.81.61.46 255.255.255.252

shutdown

!

interface Serial0/1/0

ip address 160.81.37.170 255.255.255.252

shutdown

!

interface Serial1/0

description Outside PL#595550

ip address 160.81.76.26 255.255.255.252

no ip unreachables

ip nbar protocol-discovery

load-interval 30

dsu bandwidth 44210

scramble

service-policy input block-p2p

!

ip classless

ip route 0.0.0.0 0.0.0.0 160.81.76.25

ip route 0.0.0.0 0.0.0.0 160.81.64.45 5

ip route 0.0.0.0 0.0.0.0 160.81.37.169 10

ip route 64.41.168.253 255.255.255.255 Null0

Gateway of last resort is 160.81.76.25 to network 0.0.0.0

     64.0.0.0/32 is subnetted, 1 subnets

S       64.41.168.253 is directly connected, Null0

     160.81.0.0/30 is subnetted, 1 subnets

C       160.81.76.24 is directly connected, Serial1/0

     207.14.162.0/25 is subnetted, 1 subnets

C       207.14.162.128 is directly connected, GigabitEthernet0/0

S*   0.0.0.0/0 [1/0] via 160.81.76.25

[mccmhtac1]

I would need to see sh ip route, sh ip int brief, and sh ip protocol

before, during, and after the failure of the T3.

[Richard Burts]

to the original poster

I would like to respond to several parts of your post:

- thank you for the additional information and for confirming that the serial links were not bonded. That confirms what we were seeing in the configs.

- the original config was working even though the IP addressing was not correct. It is one of the aspects of point to point serial interfaces that if you have a route in the routing table that sends packets down the serial interface then they will be delivered to the neighbor router even if its real IP address is not what you have represented in your config. So your backup static route was sending it down the serial interface and the next hop router was processing them without regard to the mismatch between what your route thought was the next hop address.

- what you have configured here will result in a primary default route, a backup (floating) default route, and a backup to the backup default route. And only 1 T1 will be used at a time. This is because of the different Administrative Distance in your floating static routes. You have configured this

ip route 0.0.0.0 0.0.0.0 160.81.76.25

ip route 0.0.0.0 0.0.0.0 160.81.64.45 5

ip route 0.0.0.0 0.0.0.0 160.81.37.169 10

and if you change it to this

ip route 0.0.0.0 0.0.0.0 160.81.76.25

ip route 0.0.0.0 0.0.0.0 160.81.64.45 5

ip route 0.0.0.0 0.0.0.0 160.81.37.169 5

then you will use both of the T1s is the T3 goes down.

- I do not understand what you are telling us about speeds when the T3  is shut down. Where (or how) are you seeing indication of the speed? And I am still not certain what you are telling us about the routing behavior when the T3 comes back up. After you bring the T3 back up try doing a traceroute and see which path the router is using.

HTH

Rick