summaryrefslogtreecommitdiff
path: root/lib/command.h
diff options
context:
space:
mode:
authorDonald Sharp <sharpd@cumulusnetworks.com>2017-09-29 13:36:54 -0400
committerDonald Sharp <sharpd@cumulusnetworks.com>2017-09-29 13:36:54 -0400
commit9790f44f390f870afab8dfdebe822f4c83bea902 (patch)
treefb48fb1b020ab69b44888a6f3071283390a3ab62 /lib/command.h
parentc00ad29fc4a75ba64f42999c7a3aa8fc60b52c81 (diff)
bgpd: Fix peer group copying of data for late activation
If we are configuring a peer in multiple address families and assigning the peer group valid configuration. If you delay the non-automatically address family activation you will not copy the peer group data into that peer. Suppose we enter this: router bgp 65001 bgp router-id 6.0.0.17 neighbor ISL peer-group neighbor ISL advertisement-interval 0 neighbor ISL timers connect 5 neighbor ISL timers 3 10 address-family ipv4 unicast neighbor ISL allowas-in 1 neighbor swp31s0 interface neighbor swp31s0 peer-group ISL address-family ipv6 unicast neighbor ISL allowas-in 1 We've assigned allowas-in to the ISL peer group. Now suppose we have a peer start connection to swp31s0. We startup and auto copy the v4 peer group information onto the peer. We do not copy the v6 peer group information because it has not started yet. Now at a later time if we enter: address-family ipv6 unicast neighbor ISL activate We start the swp31s0 peer in v6, but we are not copying the peer group data into the v6 swp31s0 peer data structure. As such we are not respecting the v6 peer group config. This Change modifies and renames the non_peergroup_activate_af function to peer_activate_af. We also call the function peer_group2peer_config_copy_af if the peer is part of a peer group. The static function peer_group2peer_config_copy_af I have moved to higher up so we don't have to add a static function declaration Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Diffstat (limited to 'lib/command.h')
0 files changed, 0 insertions, 0 deletions