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

BGP OSCILLATION

madmin.kz
Level 1
Level 1

Hello

I am trying to reproduce the BGP OSCILLATION route problem. Is short terms, it is the problem with BGP best path selection mechanism with using IGP metric to next hop step and MED. The problem is described here:

https://www.diva-portal.org/smash/get/diva2:1007297/FULLTEXT01.pdf

 

I have created similar topology, and faced with one issue. 

R1#sh ip bgp

Network               Next Hop        Metric LocPrf        Weight  Path
* i 1.1.1.1/32       192.168.67.6  2        100 0 300  0           300
*>i                       192.168.45.5  1        100 0 200i  0           200

 

As we can see, we have two paths to prefix 1.1.1.1/32 and these paths are from different ASNs. 

 

R1#sh ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 1246
Paths: (2 available, best #2, table default)
Advertised to update-groups:
9 10
Refresh Epoch 1
300, (Received from a RR-client)
192.168.67.6 (metric 15) from 192.168.17.7 (192.168.67.7)
Origin IGP, metric 2, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
200, (Received from a RR-client)
192.168.45.5 (metric 20) from 192.168.14.4 (192.168.45.4)
Origin IGP, metric 1, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

 

Here is the problem I faced. According to BGP best path selection algorithm, MED is not used if paths come from different ASNs.  Therefore, lowest IGP metric to next hop must be used. But for unknown reason, BGP prefers path with higher metric. 

Any ideas why?

 

 

 

 

15 Replies 15

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @madmin.kz ,

examining your show output

 

>>

R1#sh ip bgp

Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.1/32 192.168.67.6 2 100 0 300 0 300
*>i 192.168.45.5 1 100 0 200i 0 200

 

We can say that R1 has received the prefix 1.1.1.1/32 over two i BGP sessions note the leftmost i.

 

This is confirmed from outer show

 

R1#sh ip bgp 1.1.1.1/32

300, (Received from a RR-client)
192.168.67.6 (metric 15) from 192.168.17.7 (192.168.67.7)

 

and

200, (Received from a RR-client)
192.168.45.5 (metric 20) from 192.168.14.4 (192.168.45.4)

 

You are right the path with lowest MED is picked up as best.

 

post the BGP configuration of R1.

if bgp always-compare med

is configured this would explain what you see.

 

Hope to help

Giuseppe

 

 

Hi!

Here is the bgp config:

R1#sh run | s bgp
router bgp 100
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 192.168.12.2 remote-as 100
neighbor 192.168.14.4 remote-as 100
neighbor 192.168.17.7 remote-as 100
!
address-family ipv4
neighbor 192.168.12.2 activate
neighbor 192.168.14.4 activate
neighbor 192.168.14.4 route-reflector-client
neighbor 192.168.17.7 activate
neighbor 192.168.17.7 route-reflector-client
exit-address-family
R1#

 

As you can see, always-compare MED isn't configured. I even tried to use no bgp always-compare-med in configuration, but it seems it is disabled by default. 

Hello @madmin.kz ,

it is true that the AS path attribute is different but the two advertisements are received on iBGP sessions.

 

However, the iBGP advertisement coming from the iBGP next-hop with the lowest IGP metric should be picked up as the MED comparison should not happen.

 

see

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html?dtid=osscdc000283#anc2

 

Are you using real devices in your lab,  or are you using an emulation tool like GNS3 or VIRL/CML  or EVE.NG ?

 

Hope to help

Giuseppe

 

Hi!

I am using EVE-NG with IOL images. 

Hello @madmin.kz ,

OK it is an emulated scenario.

What  happens if you remove route-reflector-client statements on R1 router BGP section ?

Try to issue a

clear ip bgp neigh *  

on R1

 

Hope to help

Giuseppe

 

I will try it tomorrow and post result. 

I removed RR statement on R1 as you asked:

 

R1#sh ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 2
Paths: (3 available, best #3, table default)
Not advertised to any peer
Refresh Epoch 1
300
192.168.67.6 (metric 15) from 192.168.17.7 (192.168.67.7)
Origin IGP, metric 2, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
200
192.168.45.5 (metric 20) from 192.168.14.4 (192.168.45.4)
Origin IGP, metric 1, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
300
192.168.36.6 (metric 140) from 192.168.12.2 (192.168.23.2)
Origin IGP, metric 1, localpref 100, valid, internal, best
Originator: 192.168.36.3, Cluster list: 192.168.23.2
rx pathid: 0, tx pathid: 0x0
R1#

HHH.png

Hi

Both these features aren't enabled. I have posted bgp configuraiton above. 

Hello

Is med actualy being used for path selction or is it being ignored and lowest igp metric being used,
What IGP is being used?

sh ip route 192.168.67.6

sh ip route 192.168.45.5

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

As you can see from show ip bgp output path with lower MED is being used instead of path with lowest IGP metric. 

show ip bgp 

please share the output i found some difficult to get 200i under local preference.

R1#show ip bgp
BGP table version is 80848, local router ID is 192.168.17.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.1/32 192.168.67.6 2 100 0 300 i
*>i 192.168.45.5 1 100 0 200 i
R1#

comment update below.

Review Cisco Networking products for a $25 gift card