You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
This is causing problems on a Cisco IOS XR router:
RP/0/RSP0/CPU0:Mar 28 13:56:22.332 : bgp[1046]: [default-rtr] (ip4u): UPDATE from [removed], prefix [removed] (path ID: none) DENIED due to:
RP/0/RSP0/CPU0:Mar 28 13:56:22.332 : bgp[1046]: [default-rtr] (ip4u): malformed update 'treat-as-withdraw';
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: