cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1191
Views
0
Helpful
15
Replies

BGP in Dual Homing setup not failing over correctly

marioderosa2008
Level 1
Level 1

Hi all,

we have dual homed BGP connections to our sister company network but the failover testing is failing.

If i shutdown the WAN interface on the primary router, after about 5 minutes, everything converges and fails over fine.

But, if i shut the LAN interface down on the primary router, we never regain connectivity to the sister network.

Our two ASR's have an iBGP relationship  and I can see that after a certain amount of time, the BGP routes with a next hop of the primary router get flushed from BGP and the prefferred exit path is through the secondary router. This bit works OK, but i believe that the return traffic is still attempting to return over the primary link...

To add to this, we have two inline firewalls on each link which are only performing IPS, no packet filtering.

Any pointers would be great.

thanks

Mario                

15 Replies 15

JohnTylerPearce
Level 7
Level 7

Marioderosa,

Do you have Provider Independent address space or Provider Assigend address space?

JohnTylerPearce
Level 7
Level 7

Marioderosa,

So from my understanding this setup is two ASR routers, one is the Primary and the other is Secondary, and they are connected to each otehr through an iBGP connection.

But, if i shut the LAN interface down on the primary router, we never regain connectivity to the sister network.

Do you have another route to take to your sister network if the LAN interface is down on the primary router?

Our two ASR's have an iBGP relationship  and I can see that after a certain amount of time, the BGP routes with a next hop of the primary router get flushed from BGP and the prefferred exit path is through the secondary router. This bit works OK, but i believe that the return traffic is still attempting to return over the primary link...

I'm assuming this is on the secondary router?

Jon Marshall
Hall of Fame
Hall of Fame

Mario

In addition to John's post it sounds like BGP is still advertising the routes from the primary router when you shut the LAN interface down.

Have you checked with "sh ip bgp x.x.x.x advertised-routes" (where x.x.x.x is the peer address) when you shut the LAN interface down.

It's not obvious how you are advertising the routes eg. -

1) redistribute an IGP into BGP where the IGP routes arebeing learnt via the LAN interface

2) use "network ..." statements but you still need matching routes in the IP routing table which must be learnt somehow

So can you check if your are still advertising the routes when you shut the interface down and also clarify how the routes are beng advertised ?

Jon

Hi Jon / John...

yes we can see that despite the LAN interface going down, there is a summary address still being advertised to our sister AS with a lower MED... so ther return traffic is still trying to come back through the primary link..

I found that our loopback interface was sitting in the summary range, so i have removed this.... and it still gets advertised....

i have also noticed that the LAN interface that I have shutdown is also in that summary range, but I have sht it down...

The next thing i will check is to see if there are any static's to null 0 or something..... just waiting for the router to reboot.

Thanks

Mario

OK, there are no static's at all...

I have even gone to the extent of ensureing that there are no network statements in OSPF... i have configured the OSPF process under the interface configuration instead....

However, the summary address is still being advertised out when the LAN interface is shut down...

Now there are no statics... no network statements, only BGP aggregate addresses... and the summary is still advertised.

I'm at a loss... can we use interface object tracking to dynamicaly increase the MED advertised to the eBGP neighbor, so that when an interface goes down, our primary site is no longer preffered?

thanks

mario

Mario

A summary address will be advertised as long as there is at least one route in the BGP table that falls within the summary range.

What is the summary range and what does the BGP table show when the LAN interface is shut ?

Jon

Hi John,

right... please look at the output below which is the partial BGP table during a link failure...

10.128.0.0/9 is the problematic summary that still keeps getting advertised out when we do not want it to during a failure....

now there are prefixes in the BGP table which fall within that large summary address space. But I am sure that they are all routes that are being advertised to us from the eBGP peer...

*> 10.128.0.0/9     0.0.0.0                            32768 i

s> 10.128.56.16/32  172.17.17.241                 150      0 2856 64619 i

s> 10.128.56.140/32 172.17.17.241                 150      0 2856 64619 i

s> 10.160.0.0/21    172.17.17.241                 150      0 2856 64611 i

s> 10.160.14.0/24   172.17.17.241                 150      0 2856 64611 i

s> 10.160.16.0/24   172.17.17.241                 150      0 2856 64611 i

s> 10.200.16.8/30   172.17.17.241                 150      0 2856 65008 ?

s> 10.200.16.12/30  172.17.17.241                 150      0 2856 65006 ?

s> 10.255.245.0/24  172.17.17.241                 150      0 2856 64548 ?

s> 10.255.253.4/32  172.17.17.241                 150      0 2856 64548 ?

s> 10.255.253.10/32 172.17.17.241                 150      0 2856 64548 ?

s> 10.255.255.8/30  172.17.17.241                 150      0 2856 6670 ?

s> 10.255.255.10/32 172.17.17.241                 150      0 2856 ?

s> 10.255.255.12/30 172.17.17.241                 150      0 2856 6670 ?

s> 10.255.255.14/32 172.17.17.241                 150      0 2856 ?

i would not expect summary addresses to still be advertised if the specific prefixes are coming from eBGP... am i wrong?

thanks for everything so far...

Mario De Rosa

Apologies, i meant Jon, not John... sorry

Mario

i would not expect summary addresses to still be advertised if the specific prefixes are coming from eBGP... am i wrong?

This is one of those things that need testing and i don't have anything to test with.

If the advertisements that fall within the summary range are coming from an EBGP peer then you would not expect a summary address to be advertised back out to the same peer.

I had a similiar problem recently on these forums concerning a network statement under BGP and it receiving the route that matched the network statement from the same peer it would be advertising it to. John Blakely kindly did some testing for me and in that instance it did not advertise it to the peer.

But i can't say for sure without testing.

Why are you receiving routes within the summary range from an EBGP peer though ?

Jon

Jon,

I agree, that's a bit odd. I see that the 2856 AS belons to (RIPE Network Coordination Centre (RIPE)

You can clearly see that this is local, since the weight is 32768

*> 10.128.0.0/9     0.0.0.0                            32768 i

But as Jon pointed out, you are receiving the 'internal subnets' that belong to your summary network from your eBGP peer.

You pointed out, that the paste job, is during a link failure. Is this the Router connected to the Primary and or Secondary during failover?

Also, are both routers connected to the same eBGP AS?

marioderosa2008
Level 1
Level 1

Thanks for your persistence with this.

The output is from the primary router when I pull out the LAN interface cable.

Both of our routers are in the same AS 65007
Both eBGP neighbours are in the same AS 2856...

What's out my query using tracking objects???

Thanks
Mario

Sent from Cisco Technical Support iPhone App

Mario

If both routers are in the same AS are you allowing routes recevied from the EBGP peer with the same AS in ie. do you have this configured on your primary and secondary routers -

router bgp

neighbor x.x.x.x  allowas-in   <--- where x.x.x.x is the EBGP peer

If so i suspect that is where the more specific routes are coming from but again i can't say for sure whether this would mean a summary could then be advertised back to the same EBGP peer you are receiving the more specific routes from.

In terms of object tracking you may need to do something like this in the end but it would be worth working out why you are receiving the more specific routes because the solution may be simpler.

Jon

marioderosa2008
Level 1
Level 1

Hi Jon,

I do not have that in my config no.

The reason why we are receiving those specific prefixes is because we are peering with a sister company and our IP addressing overlaps.

We want to advertise summaries so that routing between sites in the same network is not affected due to more specific networks in the routing table.

We are slowly sorting out the IP addressing schemes but it will take a long time.

Mario

Sent from Cisco Technical Support iPhone App

Mario

Okay, that makes more sense.

I am still slighlty surprised it is advertising the summary due to more specific from the same neighbor.

Until you get the addressing sorted the easiest thing may be to use something like EEM where if the LAN interface goes down you also shut the WAN interface down so the route cannot be advertised. Or instead of shutting the interface you could add a "nieghbor x.x.x.x shut" command to take down the BGP peering.

You may want to post in the EEM forum where they can probably help.

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: