bgp: T9450: do not re-send a peer-group member's inherited activate

FRR only prints a peer-group member's own "neighbor X activate" when
the member's AFI/SAFI activation state differs from its peer-group's
(bgp_config_write_peer_af(), bgpd/bgp_vty.c). A member bound to a
group that already carries the same address-family is activated for
it automatically at bind time (peer_group_bind(), bgpd/bgpd.c), so
the member's own line was never needed there and frr-reload was
re-applying it on every reload.

Render the member's own "activate" only when its peer-group does not
already carry the same address-family. Applies to both
"neighbor ... peer-group" and "neighbor ... interface peer-group"
members. A member whose group drops the address-family later still
gets its own "activate" back, matching FRR deactivating it
(peer_deactivate()).

When a peer-group gains an address family that some members already
carry, frr-reload deletes those members' own "activate" before it adds
the group's, so each such member is deactivated and reactivated once
(one session reset, or with dynamic capability one withdraw and
re-advertise of that address family) at that commit. Before this
change that commit did not reset them. The end state is correct and
per-AF overrides survive the reset; this is a one-time cost at the
commit that changes the group's address-family, not a lasting
functional loss.

0 files changed, 0 insertions, 0 deletions