09-10-2021 12:21 AM
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?
09-10-2021 02:35 AM
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
09-10-2021 03:19 AM - edited 09-10-2021 03:22 AM
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.
09-10-2021 05:32 AM - edited 09-10-2021 08:30 AM
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
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
09-14-2021 07:56 PM
Hi!
I am using EVE-NG with IOL images.
09-14-2021 09:55 PM
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
09-15-2021 08:11 PM
I will try it tomorrow and post result.
09-19-2021 08:07 PM
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#
09-10-2021 08:10 AM
09-14-2021 07:59 PM
Hi
Both these features aren't enabled. I have posted bgp configuraiton above.
09-14-2021 10:27 PM - edited 09-16-2021 03:29 AM
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
09-15-2021 08:09 PM
As you can see from show ip bgp output path with lower MED is being used instead of path with lowest IGP metric.
09-15-2021 08:00 AM
show ip bgp
please share the output i found some difficult to get 200i under local preference.
09-15-2021 08:10 PM
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#
09-16-2021 12:59 PM - edited 09-20-2021 06:20 AM
comment update below.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide