03-01-2006 01:53 PM - edited 03-03-2019 11:55 AM
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
Solved! Go to Solution.
03-01-2006 02:40 PM
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
03-02-2006 11:04 AM
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
03-01-2006 02:10 PM
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
03-01-2006 02:18 PM
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
03-01-2006 02:24 PM
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
03-01-2006 02:36 PM
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
03-01-2006 02:40 PM
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
03-02-2006 10:52 AM
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!
03-02-2006 11:04 AM
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
03-02-2006 11:26 AM
Aha!
Now I see.
thank you
03-02-2006 12:59 PM
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
03-02-2006 01:11 PM
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.
03-02-2006 01:29 PM
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
03-02-2006 01:51 PM
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,
03-02-2006 02:56 PM
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
03-02-2006 07:40 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide