Fix initialization of configured families for bgp neighbor
The code used to rely on bgp open messages exchanged with the remote
router to handle the negotiation. This does not work as desired in the
case where there are multiple representations for a bgp-router. In the
scenario described in the bug, there was a bgp-router object of type
control-node in cluster A (in which it actually exists) and another
bgp-router object of type external-control-node in cluster B (in order
to represent the same control-node in cluster B). The problem happened
because the bgp-routers were configured with different adddress families
for a legitimate reason. Another bgp-router in cluster B was configured
to peer with the external-control-node, but the actual bgp negotiation
obviously happens with the control-node in cluster A (and a different
set of address families).
Fix by skipping address families that are not configured on the remote
bgp-router when populating the address family list for a neighbor.
Reviewed: https:/ /review. opencontrail. org/28959 github. org/Juniper/ contrail- controller/ commit/ 456f800719f0d8e 5f10e2c962312cc 50935bff1f
Committed: http://
Submitter: Zuul (<email address hidden>)
Branch: R3.0
commit 456f800719f0d8e 5f10e2c962312cc 50935bff1f
Author: Nischal Sheth <email address hidden>
Date: Mon Feb 13 14:07:49 2017 -0800
Fix initialization of configured families for bgp neighbor
The code used to rely on bgp open messages exchanged with the remote control- node in cluster B (in order control- node, but the actual bgp negotiation
router to handle the negotiation. This does not work as desired in the
case where there are multiple representations for a bgp-router. In the
scenario described in the bug, there was a bgp-router object of type
control-node in cluster A (in which it actually exists) and another
bgp-router object of type external-
to represent the same control-node in cluster B). The problem happened
because the bgp-routers were configured with different adddress families
for a legitimate reason. Another bgp-router in cluster B was configured
to peer with the external-
obviously happens with the control-node in cluster A (and a different
set of address families).
Fix by skipping address families that are not configured on the remote
bgp-router when populating the address family list for a neighbor.
Change-Id: I6d130cc59673dc dc42013678b4f93 f6f6dfafad2
Closes-Bug: 1664343