CEF load-balancing also redundant?

[luthierone]

Hello,

I have cef load balancing working on parallel connections between our main site and a regional office. I verify this by "sh ip cef xxx.xxx.xxx.0"

It shows two paths to the other network on each side. I then took down an interface on one end to see if ALL traffic would then take the only available route left. It didn't. Most of the traffic then failed to move. My question is:

Is CEF also redundant, or do I need to configure something else in order to get fail-over to work? See attached file for topology.

thank you

[pkhatri]

Howdy,

CEF does not need anything else in order for such a failover setup to work.

When you say you shut down the Fa2/0 interface, which router were you then checking the traffic on ? Was it router B ? If so, did Fa0/0 on router B go down when you did that ?

With ethernet interfaces connected via LAN switches, the line protocol will stay up even if the remote ethernet router port is shut down. Because the interface stays up, the static route stays up. CEF simply acts on the information in the routing table which keeps on indicating that the route is up.

In order to get around this, you need to use reliable static routes:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5413/products_feature_guide09186a00801d862d.html

Hope that helps - pls rate the post if it does.

Paresh

[luthierone]

Thanks for the quick reply,

you've given me more to think about. Yes the interface on the other end does stay up. However I created my static routes specifying the next hop and not the interface. I thought maybe that would get around this issue. Something intersting to note though:

I have a couple of special static routes (specific ip addresses) that always go over connection 1, but I made a backup route for these over connection 2 with an ip route statement and a high administrative distance. When I killed the interface, these special routes moved over. Why would that work and not the other routes for the whole network? I will check out that document you sent in the meantime.

Thank you again

[pkhatri]

Ok, so my suspicion was correct and that is why it's not working.

This behaviour is dependent on the type of link. With Ethernet, as long as the local port is plugged into a switch, it will always stay up no matter what happens at the other end. There is no end-to-end keepalive for Ethernet. With ATM links, you can use OAM loopback cells to detect when there is a break in connectivity so that interface is brought down if the end-to-end connectivity is no longer there. With PPP links, you cannot have any other devices between the two router ports (by definition) so if one goes down, so does the other.

If you need help configuring up the reliable static routes, let me know as I can post a sample config I have that works quite well.

Hope that helps - pls rate the post if it does.

Paresh

[luthierone]

Thank you,

You will probably think this is crazy but one link is an atm to frame relay and the other is a ipsec vpn. But both are about the same latency and bandwidth. But like you said, the nature of these types of links are that one end stays up when the other goes down. I think the document you linked me to is what I needed. I already read it and am ready to implement it on the network. I will have to customize it, of course, because of the link types. But it is definately doable.

thanks

[pkhatri · Accepted solution]

Cool... as I said, post back if you run into problems getting it to work as it can seem a bit tricky when doing it for the first time.

Paresh

[luthierone]

Hello,

It works great. However I only did some minimal steps:

Create the monitor:

ip sla monitor 1

type echo protocol ipIcmpEcho 10.10.10.3

timeout 1000

threshold 2

frequency 2

ip sla monitor schedule 1 life forever start-time now

Create tracking object:

track 10 rtr 1 reachability

Use the track in a route statement:

ip route 192.168.33.0 255.255.255.0 10.10.10.3 track 10

The cisco documentation has you make a routing policy and a route map. I couldn't think of why to do this. If it works without should I do it?

thanks for all of the help!

[pkhatri · Accepted solution]

Hey Mate,

The reason you need a route policy is to ensure that the pings sent by the ip sla monitor always go out through the interface being monitored. If you don't do that, they will go out through whatever interface is available. Since the point of this exercise is to monitor the tracked interface, you need to ensure that the pings use that interface, so that you will know when it is no longer available.

Hope that helps - pls rate the post if it does.

Paresh

[luthierone]

Aha!

Now I see.

thank you

[luthierone]

Hello,

Maybe I should start a new thread if I keep having questions, but one more:

Can I force the pings to go out the interface I want with:

type echo prot ipIcmpEcho 10.10.10.3 source-interface fa2/0

Or does that just use the ip address of the interface as the source address in the icmp packet?

The reason I ask is that i don't quite understand how to use the route policy in my case. I don't have a backup link, but rather two load-balanced links with redundancy. So would I need two route maps?

thanks

[luthierone]

OK,

A little more reading now I understand what the route-map is doing. But in my case the next-hop IS the target IP address that is being monitored (one link is dedicated frame-relay and the other is a vpn) is it OK to use that for the next-hop? I'll try.

[pkhatri]

Hi again,

In answer to your first question, setting the source-interface to fa2/0 simply changes the source IP of the packet - it will still get routed out of the best interface for that route.

Now, I would advise that you monitor an address within the core of your network at the other site. That helps to detect failures that are further downstream of the link. It is quite possible that the link stays up but a link downstream of it fails and the static route will stay up.

If you are tracking two routes, do the following:

- monitor two different IP addresses for the two tracked objects

- use the same local-policy but tweak the route-map so that the next-hop is set based on which address is being pinged. This will allow you to send the pings over the two different links based on where they are going

Hope that helps - pls rate the post if it does.

Paresh

[luthierone]

Yup,

That's exactly what I did, and it tested successfully.

Just to clarify:

The address I am monitoring is the core on the far side. It's just that there are no stops (that are layer 3 ip) in between on the frame network.

thanks,

[pkhatri]

Well, if that is the case, then that address should do just as well for monitoring purposes as anything else.

Glad to see you got it all working.

Paresh

[luthierone]

Once again, thank you so much for all of the help, you have been very helpful. Do you know of any solutions that will do the object tracking automatically? I came across the GLBP protocol on cisco's site, but I don't know that this applies to my situation.

good day