04-04-2014 11:02 AM - edited 03-04-2019 10:43 PM
Hello,
I've searched high and low for an answer to this but haven't found anything specific for my situation. We have 7 remote sites and one headquarter site. All sites are connected via a primary MPLS cloud and all remote sites have a local Comcast cable circuit terminated on an ASA for internet failover. IP SLA for the internet connection works as expected. Now, I understand how to configure IP SLA to track the availability of static default routes, but we use EIGRP at our remote locations for enterprise traffic. The idea is that we want to track our MPLS neighbor from the core switch at each remote site, in the event that the MPLS neighbor is no longer reachable, we want to install a static route for all LAN traffic to go through a VPN I have set up on the ASA back to the headquarter office. This static route would replace all redistributed EIGRP routes pointing out towards the MPLS provider until such time as the MPLS neighbor is once again reachable. I feel I'm missing something very simple but I just can't pinpoint it.
Any help is greatly appreciated,
-Mike
Solved! Go to Solution.
04-04-2014 11:54 AM
Mike
Is the above from a remote site ?
If so you have nothing to do because you already have a default route for internet anyway. If the MPLS network goes down the EIGRP routes are lost so the default route would be used not just for internet but also the other sites connected to the MPLS network.
So does each remote site have it's own internet connection ?
Sorry about all the questions,, just want to make sure i fully understand the current setup.
Jon
04-04-2014 11:11 AM
Mike
You are using EIGRP but how are the MPLS routes getting into EIGRP ?
Are you peering with BGP on the MPLS network and redistributing into EIGRP or something else.
Depending on how the EIGRP routes are working you may not need IP SLA ie. -
1) if you receive EIGRP from MPLS or redistribute BGP into EIGRP then you can just configure a floating static route on the core switch, no need for IP SLA
2) if the MPLS link fails you lose your routes via the MPLS network so the floating static is automatically used.
3) Whether or not the VPN is available is not really relevant because if the MPLS fails you only have the VPN to failover so you have no other option anyway.
But the above does depend on how the EIGRP routes are learnt.
Can you clarify ?
Jon
04-04-2014 11:22 AM
Thanks for the reply, Jon.
We indeed do redistribute our BGP learned routes into internal EIGRP routes for all devices in the LAN. Assuming I use the floating static with maybe a metric of 250 or so, I would need to redistribute that route in order for all other EIGRP speaking devices to learn...correct? Would that cause a problem while MPLS is up or does the high metric of 250 take care of any possible 'routing loops'?
-Mike
04-04-2014 11:31 AM
Mike
Sorry, ignore previous post.
Do you receive a default route via MPLS at the remote sites ?
Jon
04-04-2014 11:31 AM
The core switch is the first hop/default gateway for all devices including server, clients, and IP phones.
04-04-2014 11:34 AM
So what are the other L3 devices you were referring to used for ?
Also can you have a look at previous post as well as i amended it.
Jon
04-04-2014 11:44 AM
Jon,
We do not. We have a default 0.0.0.0 0.0.0.0 route configured on the core switch for all internet bound traffic. That route points to the ASA which terminates the Comcast circuit which is our primary internet connection. In response to your other post regarding the other EIGRP speaking devices, the layout is rather simple and looks basically like this at all remote sites:
MPLS<--->BGP/EIGRP Router<---->EIGRP Core Switch<----->EIGRP ASA<---->Comcast
-Mike
04-04-2014 11:54 AM
Mike
Is the above from a remote site ?
If so you have nothing to do because you already have a default route for internet anyway. If the MPLS network goes down the EIGRP routes are lost so the default route would be used not just for internet but also the other sites connected to the MPLS network.
So does each remote site have it's own internet connection ?
Sorry about all the questions,, just want to make sure i fully understand the current setup.
Jon
04-04-2014 11:56 AM
Geez! Sorry, I mistakenly marked your post as the correct answer.
The above is from a remote site and I thought it was as simple as just letting that default route do all the work for me, but testing didn't prove that to be the case. Each site does have its own internet connection. I may need to go back and test this set up again though (the default route part you mention). We've made so many different changes trying to make this work that we may have lost sight of the fact that the simplest configuration is usually the correct one.
04-04-2014 12:04 PM
Mike
No problem. I don't think you can undo a correct answer mark.
I would have thought from your description of how things are setup that if any of the BGP routes are no longer received from the MPLS network the default route should then route to the ASA for unknown networks.
Jon
04-04-2014 12:13 PM
I completely agree and I thought that was all that was needed, but strangely it did not work when we tested it. I'm going to check for any extraneous routing configuration that may be in there from previous attempts and test again tonight. Another concern is how do we dynamically route traffic over the VPN when the BGP routes for all sites are in the table, but the MPLS link is severely degraded? We saw this yesterday, MPLS was up and the route table was still populated but the link was unusable due to heavy latency and 90% packet drops.
04-04-2014 01:50 PM
Okay, let me know how the testing goes.
In terms of the performance issue that is more tricky.
PfR may be able to help but i couldn't say as i have no experience of it.
The followiing is just a suggestion which may or not work. The main issue is you still have the EIGRP routes on the core switch so directing traffic to the VPN with a default route wouldn't work.
So a possible solution would be -
1) monitor the state of the link on the MPLS router
2) if the link peformance is degraded then use EEM to do a shutdown on the BGP neighborship but leave the link up so it can still be monitored.
If the BGP neighborship is down obviously the EIGRP routes would not be on the core switch.
3) if the link performance becomes acceptable then you bring the BGP neighborship back up and the core switch receives the EIGRP routes again.
So you may be able to use IP SLA together with EEM to achieve this although i have never done it. The following is a link to similiar discussion in the EEM forum. It sends an e-mail alert for an IP SLA failure but you could modify this to do what you need -
https://supportforums.cisco.com/discussion/11587371/eem-script-alert-ip-sla-failures
Jon
04-08-2014 10:07 AM
Hi Jon,
Sure enough, failover with just default routes did work when we fully brought down our MPLS link. The next trick is going to be researching the EEM with IP SLA solution you suggested for a flapping or degraded link. Thanks again for your help and input!
-Mike
04-08-2014 10:11 AM
Mike
No problem, glad to have helped.
Thanks for getting back and letting me know it worked.
Jon
04-09-2014 05:49 AM
Hi Jon,
I did some research on EEM and IP SLA and I think you're right on the money as far as this being a solution for failover from a link that isn't completely down but maybe flapping or experiencing high latency and/or packet loss. I created an IP SLA operation and an EEM applet and had it checked out on this thread:
I won't be able to test it until Friday night but it looks promising. I'll post my results here once we're done testing.
-Mike
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