Closed gitneep closed 1 year ago
It needs some investigation, but with a finger in the air, I would suggest an issue with next-hop self - if so using an IP should hide the issue until it can be fixed.
Changed the code to always convert "self" to the "IP" upon parsing the configuration.
This worked, getting all the prefixes announced with Next Hop now, thanks for the fast response!
Hi, can anyone think of a reason why on BGP UPDATE messages, half the time the Next Hop attribute is included and the other half it isn’t, for prefixes that are otherwise completely the same apart from the actual numbers and go out during the same group of updates upon restarting a BGP session? They also both get shown with announce route [prefix] next-hop self in the log, but then when looking in the pcap using tcpdump, one has:
And the next has:
This is causing problems on a Cisco IOS XR router:
Subsequently the prefixes are dropped and not installed in the routing table. The prefixes that are included in the updates that do have the Next Hop attribute listed however /are/ included.
This is with python3-exabgp version 4.2.21 on Ubuntu 20.04, and the Cisco is running IOS XR 5.1.3 (I know it's old but this will have to do for now).
Running exabgp -d yields the following for one of the prefixes that suffers from the missing Next Hop attribute as seen by tcpdump:
Run an IGP BGP peering session with 1000+ prefixes announced, catch everything on port 179 with tcpdump -v and look for the UPDATE messages, then notice that some have Next Hop and some don't.
Expected behavior would be that the Next Hop attribute is included for all prefixes, and not for some and not for others, as part of the same group of update messages.