BGP Prefix Oscillation - Next Hop Problem

[kfarrington]

Hello All,

I have two MPLS CE routers each with a /32 loopback on them.

R1 has 10.199.1.3

R2 has 10.199.1.4

These routers run EIGRP and BGP and they connect via two fastethernets back to a pair L3 backbone switches.

The L3 backbone runs interface EIGRP summarisation for the 10.199.0.0/18 towards the CE routers. (On 4 interrouter vlans)

Now, as I received the loopback address of R2 on R1, I get it from iBGP and also have the summary from the backbone of the 10.199.0.0/18.

I would asume, that the iBGP route would go into the RT as it is a more specific match than the summary on the CE.

The problem

-----------

The route oscilates in and out of the routing table and BGP table. This I think is becasue the loopback is also the iBGP peer address,

so the router is receiving a BGP route from 10.199.1.4/32 from (next hop) 10.199.1.4.

It goes into the BGP table for exactly 60 seconds, and then drops from the table and the route uses the summary to get to R2 loopback via EIGRP.

Is this a common problem, and is this behaviour documented ?

ie, learning a prefix of x with the next hop being x?

Kind regards,

Ken

When route is learned via iBGP

R1>sh ip bgp 10.199.1.4

BGP routing table entry for 10.199.1.4/32, version 258775

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Flag: 0x820

Advertised to peer-groups:

Masergy

Local, (received & used)

10.199.1.4 (metric 28416) from 10.199.1.4 (10.199.1.4)

Origin IGP, metric 0, localpref 100, valid, internal, best

When route is learned via summary route in EIGRP

R1>sh ip bgp 10.199.1.4

BGP routing table entry for 10.199.1.4/32, version 259499

Paths: (1 available, no best path)

Flag: 0x820

Not advertised to any peer

Local, (received & used)

10.199.1.4 (inaccessible) from 10.199.1.4 (10.199.1.4)

Origin IGP, metric 0, localpref 100, valid, internal

R1>

R1>sh ip route 10.199.1.4

Routing entry for 10.199.1.4/32

Known via "bgp 65000", distance 200, metric 0, type internal

Redistributing via eigrp 69

Last update from 10.199.1.4 00:00:57 ago

Routing Descriptor Blocks:

* 10.199.1.4, from 10.199.1.4, 00:00:57 ago

Route metric is 0, traffic share count is 1

AS Hops 0

R1>sh ip route 10.199.1.4

Routing entry for 10.199.1.4/32

Known via "bgp 65000", distance 200, metric 0, type internal

Redistributing via eigrp 69

Last update from 10.199.1.4 00:00:58 ago

Routing Descriptor Blocks:

* 10.199.1.4, from 10.199.1.4, 00:00:58 ago

Route metric is 0, traffic share count is 1

AS Hops 0

R1>sh ip route 10.199.1.4

Routing entry for 10.199.1.4/32

Known via "bgp 65000", distance 200, metric 0, type internal

Redistributing via eigrp 69

Last update from 10.199.1.4 00:00:59 ago

Routing Descriptor Blocks:

* 10.199.1.4, from 10.199.1.4, 00:00:59 ago

Route metric is 0, traffic share count is 1

AS Hops 0

R1>sh ip route 10.199.1.4

Routing entry for 10.199.0.0/18

Known via "eigrp 1", distance 90, metric 28416, type internal

Redistributing via eigrp 1

Advertised by bgp 65000

Last update from 10.199.3.21 on FastEthernet0/0, 1d22h ago

Routing Descriptor Blocks:

* 10.199.3.25, from 10.199.3.25, 1d22h ago, via FastEthernet0/1

Route metric is 28416, traffic share count is 1

Total delay is 110 microseconds, minimum bandwidth is 100000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

10.199.3.21, from 10.199.3.21, 1d22h ago, via FastEthernet0/0

Route metric is 28416, traffic share count is 1

Total delay is 110 microseconds, minimum bandwidth is 100000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

R1>

[kfarrington]

With further testing in the lab. I think this statement may be true, but cannot see it in any bgp design documents. Tested on 12.2 and 12.3.

You should not iBGP peer (maybe bgp peer) to a peer without having a host route in your IGP to that peer.

ie, if you have a summary route that you use to get to that peer, and you are learning the host route via iBGP, you could have problems.

or

if you have the following, you are leanrning a host route from iBGP and that same host address is your ibgp next hop, you could have problems.

I would be interested in anyones views on these statements?

Kindest regards,

Ken

[Kevin Dorrell]

"You should not iBGP peer (maybe bgp peer) to a peer without having a host route in your IGP to that peer. ie, if you have a summary route that you use to get to that peer, and you are learning the host route via iBGP, you could have problems."

That is interesting. I knew that iBGP will not select a route unless it is underpinned by an IGP or static route, but I didn't realise that that also takes into account the specificity of the route. That is the BGP synchronization contraint, and is step #2 in the BGP path selection algorithm. But I have never read that the mask has to be the same as offered by the IGP. But if I think about it, it is consistent with the rest of the philosophy of BGP.

Here is a document about BGP path selection:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

But that document misses out the first two steps of the algorithm that I learned when I was studying, namely (1) If next hop is inaccessible, drop the path, (2) If the path is 'i' and sync is enabled, and path not in IGP, then drop the path.

I wonder what happens if you switch off synchronization?

I would be interested to hear the opinion of the more experienced BGP users.

Kevin Dorrell

Luxembourg

[kfarrington]

Just a note on that, This is only my interpretation, and not fact. So please dont take that as gospal. Its just what I am experiencing at the moment, and is causing oscillation.

Thx for the doc also :))

Kind regards,

Ken

[Harold Ritter · Accepted solution]

This is correct.

- You should make sure that the route to the iBGP peer is as specific as possible (/32 is ideal).

- You should also make sure that the route to the iBGP peer is not learnt via BGP, which could cause route oscillation.

Here's a document demonstrating the route oscillation behavior. Although this documents illustrate the issue in an eBGP context, the behavior is the same with iBGP.

http://www.cisco.com/warp/public/459/bgp-rec-routing.html

Hope this helps,

[kfarrington]

perfecto - thx all.

Its only cause we were using summarisation in the lab that we noticed this.

Wont forget it in a hurry, thats 4 sure :))