Needing some assistance with an IP SLA setup that I'm having some issues wrapping my head around. I have a router that has two connections to a remote site router. One connection from HQ-Rtr has a serial connection to an MPLS cloud using BGP as it's routing protocol. The other connection is an Ethernet connection to an ASA (which uses an IPSEC tunnel to the remote router). Here is what I'd like to do. I'd like to use the MPLS cloud connection as the primary connection. Once it fails, I would want the Ethernet connection to the ASA to kick in. However, I would like it to fall BACK over to the MPLS cloud connection in the event that the Serial connection comes back online.
With that said, I know I'll have to use IP SLA to make this work but I'm running into an issue getting it to fall BACK to the primary route. I'm not sure why. I'm basically doing the following:
track 1 ip sla 1 reachability
ip sla auto discovery
ip sla 1
icmp-echo a.a.a.a source-interface Serial1/0
ip sla schedule 1 life forever start-time now
ip route 22.214.171.124 255.255.255.0 x.x.x.x track 1 (learned via bgp from cloud, metric 20)
ip route 126.96.36.199 255.255.255.0 y.y.y.y 25
So, to me.....this says as long as I can ping a.a.a.a from source int s1/0, the route for network 188.8.131.52 should go to x.x.x.x. Then once it fails, it falls over to y.y.y.y. It requires the 25 cost so that it doesn't take precedence over the x.x.x.x route. Am I seeing this correctly so far? Then once x.x.x.x comes back online, it SHOULD fall back over to that one being it has the lower cost route of 20. Is this right?
Well regardless it's not working quite as expected so someone had mentioned something about setting another IP SLA up with a 'Boolean and' statement. I'm not 100% sure about this so if anyone can explain this to me and how it would work in the above scenario or why it would be done, then that would help also. Here is what they suggested:
track 2 list boolean and
object 1 not
and to change my routes to look like the following:
------Remove route for x.x.x.x all-together-------
ip route 184.108.40.206 255.255.255.0 y.y.y.y track 2
I'm guessing (and I do mean guessing) this says to monitor track 1 and if track 1 is NOT true (false) then apply the route for y.y.y.y?
Can someone take a look and help me with the concept, I guess maybe I'm in left field here but I'm struggling a bit on making this work.
Thanks in advance,
Solved! Go to Solution.
Okay that makes more sense, I though it was me :-)
So when you shutdown the loopback interface on router A your MPLS central site router doesn't receive the route and so should failover to the ASA ?
So what route is the MPLS router showing for that loopback ie. prefix and mask when it's a BGP route.
And what route are you using on the central site router to point to the ASA, again prefix and mask.
Not you at all. :) I'm was just trying to understand the concept and implement into my scenario, hopefully eliminating a lot of the convoluted portions. However, some of those pieces you needed and I wasn't giving them. I do apologize.
Routing entry for xx.xxx.1.164/32
Known via "bgp xxxxx", distance 20, metric 0
Tag xxxxx, type external
Last update from xx.xxx.253 01:18:48 ago
Routing Descriptor Blocks:
* xx.xxx.3.253, from xx.xxx.3.253, 01:18:48 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag xxxxx
MPLS label: none
Central site router looks like this:
ip route xx.xxx.1.164 255.255.255.255 xx.xxx.2.226 200
Okay I think the issue is this.
You are redistributing statics into BGP. So what happens is that when your MPLS link is up you receive the loopback via BGP and it has an AD of 20 so goes into the IP routing table because it has a better AD.
When the MPLS link fails your static route with an AD of 200 is placed into the IP routing table and redistributed into BGP.
When the MPLS link comes back up your router receives the same route from the PE router.
Now your MPLS router has two routes in BGP for the same destination and prefix.
The one from the PE has a weight of 0 but the static that was redistributed locally has a weight of 32768 because that is the weight assigned to locally generated routes.
The higher the weight the better so BGP sticks with the route via the ASA.
The usual solution to this is to modify the routes received from the PE so they have a weight > 32768 and so once the MPLS link comes back up they are preferred and installed in the IP routing table.
You can do that as a test if you want however you are just unfortunate in that you have hit this issue with your test because in production it wouldn't occur.
The reason being you would have a summary route or default static route pointing to your ASA so the more specific routes via MPLS are always used if they are available.
Hope that makes sense.