BGP not dropping route

[christopher_hall]

Problem:

We have setup IPSLA on a core switch and are having problems with BGP not dropping Route_1.

Setup:

We've setup IPSLA (on Switch_01) in our network to determine if a route, Route_1, is available. If it is available, then traffic flows normally. All locations that need to use the services provided by Route_1 learn about this through BGP. If Route_1 is not available, then Route_1 is dropped and Route_2 is used, which points to an alternative location in another LAN across our WAN.

It appears that IPSLA is working correctly. We unplug the router that connects to the services requested through Route_1 and the route is dropped by Switch_01 and it uses Route_2 to direct traffic to WAN_01. The problem is that WAN_01 (connected directly to Switch_01) never drops Route_1 from it's routing table and I don't think that Route_2 gets updated by BGP, so all 12 of our locations continue to come to our primary location where IPSLA is setup. Configs are attached.

Equipment:

Switch_01 = Catalyst 3560

WAN_01 = 2811

BGP:

Switch_01 and WAN_01 are bgp neighbors.

So the million dollar question(s) is/are: how long does it take for bgp to converge? As mentioned above, the WAN_01 is directly connected (is BGP neighbors with) Switch_01. We've had the router unplugged for about 15 minutes. The behavior we're experiencing is that when Switch_01 chooses Route_02 and takes the next hope to WAN_01, WAN_01 sends that traffic back to Switch_01. I can't ID any static routes that would be sending this back, nor is the Default Gateway doing do.

Thanks,

Chris

[Jon Marshall]

Chris

I don't think you need to track the route on the W Columbia switch because you only want traffic to go via the W Columbia path if the Ops side fails.

The additional routes point back the other way and i personally think this is confusing the issue ie. each side should only point to it's respective JConnect router, i can't (at the moment) see the logic of having a route pointing back the other way.

In terms of your route-map you can either add the network an existing access list that the "match ip address ..." references or add another acl and then add it to the "set ...." line.

Jon

[Jon Marshall]

Chris

Forgot to add. Once you have updated the config you will need to do a "clear ip bgp 10.20.128.110 soft out" on the W Columbia switch for it to take effect.

Once you have done it can you then log onto a remote site and test that the path to 10.15.1.0/24 is still going via the Ops router which it should.

If all that works then you can test (if possible) losing the JConnect link. The remote site should then use the W Columbia path. Once you bring the link back up it should then go back via the Ops path.

Jon

[Jon Marshall]

Chris

Apologies, it's a bit late here and i missed this one.

I'm not real clear on why this was done, but based on your information above, we should:

1.) Add a static route on the w columbia switch pointing to the 10.15.1.0/24:

     ip route 10.15.0.0 255.255.255.0 10.20.128.16 250

Yes you should but you don't need or want the 250 at the end. It should not be floating static, it should just be a normal static route.

Jon

[christopher_hall]

Thanks Jon. We're going to review and test the beginning of the week. I'll post back the results.

Chris

[Jon Marshall]

Chris

One final point that might be relevant.

If there are end devices etc. that connect to 10.15.1.0/24 in the W Columbia site ie. not clients from across the AVPN cloud then you will need to track the route added to the W Columbia switch.

This is because if the link fails on JConnect2 and you still want W Columbia internal clients to get to 10.15.1.0/24 you would presumably want them to go via the other path ie. via the AVPN cloud.

If this is what you want then you need to make sure the static route is removed if the link fails.

Apologies for all the additional bits, just a bit tired so it's taking me a while to work it all through.

Hope it all goes well.

Jon