Routing issues with IP SLA

[Sam Smiley]

I have a 2811 with the following config; one outside interface connected to a T1, one physical inside interface (three VLAN sub inside interfaces) and a tunnel spoke in a GRE network. On the inside physical  interface there are three VLANs; core, LAN & management; the core VLAN is for servers that need to access the T1 interface solely, the LAN segment has a cable modem for Internet access for the LAN. The goal is that if the cable access goes down the LAN segment will access the Internet through the T1. I have attached a confg for the router.

There is a routing problem with the config; it comes from the way the two default routes are loaded. In the attached config the routes are as follows:

ip route 0.0.0.0 0.0.0.0 10.24.41.1 10 track 100
ip route 0.0.0.0 0.0.0.0 72.54.xx.xx track 200

The LAN inside interface is 10.24.41.21, the next hop to the cable modem is 10.24.41.1. The next hop for the T1 is the 72.54.xx.xx, the problems come with the routing for the GRE tunnel, in the current config all of the GRE routes are built correctly and traffic is flowing as expected. The problem with the current config is that when the cable modem route goes down the LAN segment doesn't fail over to the T1 as desired.

If I change the routes and remove the metric the failover works as expected:

ip route 0.0.0.0 0.0.0.0 10.24.41.1 track 100
ip route 0.0.0.0 0.0.0.0 72.54.xx.xx track 200

The issue with this is that once these routes are enabled all of the EIGRP GRE routes disappear and I am unable to communicate with the remote offices or any VPN remote software clients. It should also be noted here that once track 100 is down (cable modem) the GRE routes come back immediately.

Any help to find my missing GRE routes would be appreciated.

Regards,
Sam

[Jon Marshall]

Sam

This is a weird one.

You are using PBR to send the traffic to the cable modem so actually this seems to be working back to front ie.

1) you use PBR to send the traffic to cable modem

2) with your original configuration the cable modem route should not be in the routing table anyway as long as the T1 is up because it has a higher AD.

3)  if the cable modem goes down the PBR next hop should become unavailable in which case the routing table is used and the cable modem route was never in the routing table ie. it wasn't originally because of the AD and it certainly won't be now because of the failed IP SLA.

So it should work.

What is even more unclear is why when you change the cable modem route so it doesn't have an AD that means failover works. Changing the route so it has the same AD as the T1 route means both routes are in the IP routing table.

If both links are up then this wouldn't affect your PBR ie. those clients would still be sent via the cable modem.

But for the servers which use the T1 you are not doing PBR so they will use the routing table and there are now two equal cost routes in the routing table which means they could use either as far as i can see.

So I'm not sure what is going on.

I'm assuming the cable modem is not meant to failover for the T1 ie. it is only the T1 that is meant to be backing up the cable modem.

If that is the case then i would suggest firstly just removing the cable modem route altogether because it's not needed ie. you are using PBR. If PBR fails that means the cable modem is down so it will just use the routing table.

I can't see what that cable modem route is doing for you ?

I may be misunderstanding what you are trying to do so please come back and clarify if needed.

Jon

[Sam Smiley]

Very good point Jon, thanks for the suggestion. I have been tinkering with this for a couple of days now. The route to the cable router is from the original config which was that the cable route would be the first AD. The results were the same no matter which route is first. I tried several things with this config to get this working in the last couple of days.

It doesn't make any sense to me to lose the EIGRP routes since the outside interface isn't affected by the PBR. I'll drop the route from the table this evening after everyone has left.

You are correct in that there is no need to route the core network to the cable router; the core VLAN services remote VPN and local users. Worst case would be to drop the remote users.

Regards,
Sam

[Jon Marshall · Accepted solution]

Sam

Couple of other points when you test -

1) The address 75.75.75.75 that you are tracking for the cable modem route.

I did a quick DNS lookup and it is a Comcast IP address. Be aware that if that IP is reachable from the internet then you may find that the ping still works via the T1 line.

If it does then your track will stay up and PBR will continue to use the cable modem even if it is down.

If that IP is only meant to be reachable via the cable modem then the easiest solution is to add a static host route on your router for that IP and point it to the cable modem.

Then if it goes down the ping will not work via the T1.

2) the second permit statement in your PBR configuration. I'm not sure what that is doing. It's kind of the reverse logic to my first post ie. you only want to do PBR for the cable modem so just leave the rest to the routing table where you have the T1 route.

It probably won't make any difference but if all else fails then worth a try.

Be interested to hear how it goes.

Jon

[Sam Smiley]

Jon, just a note to say that adding the static route for 75.75.75.75 solved it. I did remove the route to the cable modem but it had no effect. I believe what was happening was that when the routes had an equal metric the sla had a proper route to 75.75.75.75 through the cable modem. however once the metric changed it no longer had the appropriate route and was going out the T1 interface which as you pointed out was keeping the PBR up pointing to the cable modem.

Again thanks for the help!

Regards,
Sam

[Jon Marshall]

Sam

I think you may well be right although when both routes were in the routing table it could have used either one to get to the Comcast IP.

So it may just have been chance it picked the cable modem route.

Still, glad to hear it's working and thanks for letting me know.

Jon