diff options
| author | Alexander Skorichenko <askorichenko@netgate.com> | 2021-07-14 16:43:37 -0400 |
|---|---|---|
| committer | Alexander Skorichenko <askorichenko@netgate.com> | 2021-07-14 16:43:37 -0400 |
| commit | 24f569e9ccea56695ff57be71a6e108f9a7867b2 (patch) | |
| tree | 23ddf386fb63dab3c9ab89d87d39525663f1ebd9 /lib/routemap_cli.c | |
| parent | a95ba7a7c8820b3f16b191f34738d2ed2e43823f (diff) | |
bgpd: Clear capabilities field when resetting a bgp neighbor
Currently, the following sequence of events between peers could
result in erroneous capability reports on the peer
with enabled dont-capability-negotiate option:
- having some of the capabilities advertised to a bgp neighbor,
- then disabling capability negotiation to that neighbor,
- then resetting connection to it,
- and no capabilities are actually sent to the neighbor,
- but "show bgp neighbors" on the host still displays them
as advertised to the neighbor.
There are two possibilities for establishing a new connection
- the established connection was initiated by us with bgp_start(),
- the connection was initiated on the neighbor side and processed by
us via bgp_accept() in bgp_network.c.
The former case results in "show bgp neighbors" displaying only
"received" in capabilities, as the peer's cap is initiated to zero
in bgp_start().
In the latter case, if bgp_accept() happens before bgp_start()
is called, then new peer capabilities are being transferred
from its previous record before being zeroed in bgp_start().
This results in "show bgp neighbors" still displaying
"advertised and received" in capabilities.
Following the logic of a similar af_cap field clearing,
treated correctly in both cases, we
- reset peer's capability during bgp_stop()
- don't pass it over to a new peer structure in bgp_accept().
This fix prevents transferring of the previous capabilities record
to a new peer instance in arbitrary reconnect scenario.
Signed-off-by: Alexander Skorichenko <askorichenko@netgate.com>
Diffstat (limited to 'lib/routemap_cli.c')
0 files changed, 0 insertions, 0 deletions
