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
Having encountered a problem described in #7738, I've found that there's no possibility to completely disable sending RA messages when extended-nexthop BGP capability is enabled (and in some other cases). I've described the way to reproduce the problem in the issue. There's a similar discussion #15994 where it's said that RA are used for unnumbered BGP peers, but we don't use them and still need the extended-nexthop capability.
After looking into the source, I came to the conclusion that the suppress-ra command is intended to enable RA (in "no" form), but not to disable it. I suggest adding a new command disable-ra that will disable it completely, disregarding other conditions, so as not to break the routing in the network.
I've prepared a patch available there(updated link), so I'm ready to make a PR with the described functionality. But since it affects public configs, I decided to discuss it here beforehand.
P.S. I've also noticed that while RA can be enabled by bgpd and vrrpd (aside from vty), there are pieces of code (e.g. BGP_RA_CONFIGURED) that assume only BGP in their names. Hypothetically, it might lead to a situation where, say, vrrpd will disable RA despite bgpd still wanting it. I haven't tried to reproduce it. Should I make an issue for it?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello.
Having encountered a problem described in #7738, I've found that there's no possibility to completely disable sending RA messages when extended-nexthop BGP capability is enabled (and in some other cases). I've described the way to reproduce the problem in the issue. There's a similar discussion #15994 where it's said that RA are used for unnumbered BGP peers, but we don't use them and still need the extended-nexthop capability.
After looking into the source, I came to the conclusion that the
suppress-ra
command is intended to enable RA (in "no" form), but not to disable it. I suggest adding a new commanddisable-ra
that will disable it completely, disregarding other conditions, so as not to break the routing in the network.I've prepared a patch available there (updated link), so I'm ready to make a PR with the described functionality. But since it affects public configs, I decided to discuss it here beforehand.
P.S. I've also noticed that while RA can be enabled by bgpd and vrrpd (aside from vty), there are pieces of code (e.g. BGP_RA_CONFIGURED) that assume only BGP in their names. Hypothetically, it might lead to a situation where, say, vrrpd will disable RA despite bgpd still wanting it. I haven't tried to reproduce it. Should I make an issue for it?
Beta Was this translation helpful? Give feedback.
All reactions