Floating Static Route Issue

[brianschaefer]

I have 7 sites running EIGRP and one primary internet/wan connection. One of our buildings has an issue where they loose connectivity a couple of times a month (another issue entirely).  We put a cable modem backup for a couple of vlans that need the internet to complete daily operations. I setup a floating static route with an AD of 250 for the cable modem backup link. Last night they lost internet for a few minutes, then it came back. The floating static route worked, but never went back to the primary internet connection.  Is this normal? do I have to manually clear all the routes and let EIGRP reconverge? or is there a better way to accomplish this?

[lgijssel]

No, this is not normal. When the EIGRP route is advertized, it must override the floater, that's how it should work.

In your case, it looks as if the dynamic route was never advertized again after the outage.

The problem is likely in your eigrp config, not with the floating static route.

regards,

Leo

[Jon Marshall]

Brian

No it is not normal. Once the original route reappears it should replace the floating static as long as  -

1) the AD is less which i assume it is as the floating static in your example has 250

2) the prefix and mask of the route are exactlty the same.

Jon

[brianschaefer]

I forgot to add that the floating static route I am using is for 0.0.0.0 0.0.0.0.0

"1) the AD is less which i assume it is as the floating static in your example has 250"

what is the AD for the gateway of last resort advertised by EIGRP? is it the same as EIGRP external of 170?

"2) the prefix and mask of the route are exactlty the same."

not sure I am following this one

[Jon Marshall]

brianschaefer wrote:
I forgot to add that the floating static route I am using is for 0.0.0.0 0.0.0.0.0
"1) the AD is less which i assume it is as the floating static in your example has 250"
what is the AD for the gateway of last resort advertised by EIGRP? is it the same as EIGRP external of 170?
"2) the prefix and mask of the route are exactlty the same."
not sure I am following this one

2) Simply meant the network and the subnet mask of the route must be the same.

Can you draw or explain how exactly things are connected and where you are seeing the route problem ie. is there a 3rd router receiving EIGRP routes from both the primary and backup router and is there where you are having problems.

How is this default-route being propogated to othe routers ie. presumably redistributing the static route into EIGRP for backup but what about the primary link.

The key thing to remember is AD 250 is only local to backup router so once it is redsitributed it will be AD 170 on other routers. If you are also redistributing from primary router then all other routers see both redistributed routes as AD170.

Jon

[niro]

I don't mean to hijack the thread but I had the exact same issue last week, have a floating static route took over when an MPLS line went down, when it came back up the static route was still in effect.  I fixed it by removing the static route and re-adding it, at which point the advertised route from BGP took over. 

What OS are you using, maybe a bug?  This happened to me on 12.2.53.SE

[brianschaefer]

no problem..

I don't think it's a code issue, but I am using 12.4(24)T1

[brianschaefer]

"Can you draw or explain how exactly things are connected and where you  are seeing the route problem ie. is there a 3rd router receiving EIGRP  routes from both the primary and backup router and is there where you  are having problems."

My drawing isn't 100% accurate, all links terminate into a vlan on a switch which is then trunked to the router. I started my day at the Head End site. I could ping across the wan to the remote buildings but no internet. I did not verify if other sites could access the internet, I was kind of under the gun to just get it working. I didn't even really have time to check much, I suspected it was the cable modem when a traceroute for the internet was going over the dark fiber. I shut down the interface for the cable modem and the internet came back. Event logs in head end router showed flapping events over night

"How is this default-route being propogated to othe routers ie.  presumably redistributing the static route into EIGRP for backup but  what about the primary link."

I redistribute connected & static. Our ISP is using EIGRP also, and we advertise routes to each other.

"The key thing to remember is AD 250 is only local to backup router so  once it is redsitributed it will be AD 170 on other routers. If you are  also redistributing from primary router then all other routers see both  redistributed routes as AD170."

I think this is the problem. What can I do to remidy this part? The one site really only needs the backup link, but it would be nice for the head end to be able to use it because my reporting server is housed there, so it can notify me that the primary link went down

[Jon Marshall]

Brian

I think this is the problem. What can I do to remidy this part? The one site really only needs the backup link, but it would be nice for the head end to be able to use it because my reporting server is housed there, so it can notify me that the primary link went down

What you could try first is influencing EIGRP metrics on the head-end router so the metric is better via the ISP link. When both routes have same AD then the metric comes into play so you could modify the delay on the connection between the head-end router and the cable modem router so that under normal conditions the ISP route is chosen.

If this doesn't work then you could look to use IP SLA on the head-end router. Track the primary route via the ISP and if it the link goes down then insert a new route on the head-end router pointing to the cable modem router. This may be a better option. IP SLA code has changed so many times but it would look something like this on 12.4(24)T - this would all be on headend router -

ip sla 1

icmp-echo

timeout    <-- you don't necessarily need this unless the link is quite slow

frequency 10 <-- this is in seconds and you can change it to what you want ie. how often the ping happens

ip sla schedule 1 life forever start-time now

track 10 ip sla 1 reachability

ip route 0.0.0.0 0.0.0.0 track 10

ip route 0.0.0.0 0.0.0.0 250

basically you setup a ping that runs and this checks whether it gets a response. If it does the primary route stays in the routing table. If it the ping stops working the primary route is removed and your floating static is inserted into the routing table. If the ping starts working again then the floating static is removed and the primary route is inserted again.

Jon

[brianschaefer]

Jon,

I like your first Idea:

"What you could try first is influencing EIGRP metrics on the head-end router so the metric is better via the ISP link"

what was your thoughts on how to influence it?

-Brian

[Jon Marshall]

Brian

Quick follow up. The IP SLA would work in previous post but i noticed you say you are receiving EIGRP routes from ISP. If you do then thse should be AD 90 if you are both using same EIGRP process so actually it should work without normally.

You could then redstribute default-route on cable modem router and when it got to headend router it would be AD 170 so the ISP AD 90 route should be preferred. Is the ISP using the same EIGRP process and if so are they sending you a default-route ?

Jon

[vdadlaney]

Hi Brian,

In addition to Jon's previous post where he requested if you could confirm if you are running the same EIGRP process with the ISP and if you are receiving a default route could you please post the output of the "show ip route 0.0.0.0" from your Head End Router and also provide the running config of your cable modem router where you specify the redistribution metric for the floating static route when everything is normal and you are routing out via the ISP link. This is a guess on my part without the information above but I do believe that Jon nailed the issue before as being a case of a worse metric because what I think is happening is that you are learning a default route (Again this is a Guess?) from the ISP and it is with a AD of 170 however the metric for that route received from the ISP and advertised to the Primary Router is higher than the metric for the same route over the Dark Fiber from your backup cable modem router and hence the headend router is choosing to go towards your cable modem backup router. The metric in EIGRP is directly related to the interface so if you are using a FastE interface for your ISP link and using a GigE link for your dark fiber this could account for the difference. If this is the case than you could specify a higher delay when you redistribute the floating static route so that it will only be preferred when the ISP route disappears. HTH

Regards,

Vikram

[Jon Marshall]

Brian

Just a very quick note.

IP SLA ping test is primarily used when you are not exchanging routes with your provider, which is a very common situation. As you are though i do think it would better to work out why it is favouring the cable modem connection and not the ISP connection.

Jon

[brianschaefer]

This is really a reply to Jon and Vikram

sorry about the delay in re-post, I had some outages that kept me busy for the last few days.

I wanted to post some more info so you can get a better idea of what is going on..

Head-End#sh ip route 0.0.0.0

Routing entry for 0.0.0.0/0, supernet

  Known via "eigrp 50", distance 170, metric 130816, candidate default path, type external

  Redistributing via eigrp 50

  Last update from 10.254.104.1 on FastEthernet0/1.767, 4d00h ago

  Routing Descriptor Blocks:

  * 10.254.104.1, from 10.254.104.1, 4d00h ago, via FastEthernet0/1.767

      Route metric is 130816, traffic share count is 1

      Total delay is 110 microseconds, minimum bandwidth is 20000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 6/255, Hops 1

Dark-Fiber-Site#sh run | b router eigrp 50

router eigrp 50

redistribute connected

redistribute static

passive-interface GigabitEthernet0/0.4

passive-interface GigabitEthernet0/0.5

passive-interface GigabitEthernet0/1.92

network XXX.XXX.0.0 0.0.255.255

network 10.254.253.0 0.0.0.7

network 10.254.254.0 0.0.0.7

network XXX.XXX.XXX.0

no auto-summary

no eigrp log-neighbor-changes

!

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 XXX.XXX.XXX.XXX 250

**** Additional Notes ****

ISP Link = FastE

Dark Fiber = 2 paths @ GigE (10.254.253.0 & 10.254.254.0)

[Richard Burts]

Brian

It is not clear to me whether the floating static route is configured on the head end router and points over the dark fiber, or whether the floating static is configured on the router with the cable modem and is then advertised to the head end.

If the floating static is configured on the router with the cable modem, then the situation would be that after a failure which activated the cable modem that the head end would be receiving advertised default routes from both the ISP and the cable modem router. In this case it becomes important to look at the metric advertised by both routers, since the head end router will see both advertised default routes with the same Administrative Distance.

One potential solution might be to configure an offset list on the head end which would increase the metric of any routes advertised from the cable modem router (or the offset list could specify that it would affect only the advertised default route).

HTH

Rick