BGP router address family list is not enforced in negotiation with peer

[Ato]

===> Let's assume a control node is configured to support all the address families:

{
    "bgp-router": {
        "bgp_router_parameters": {
            "address": "10.0.0.85",
            "address_families": {
                "family": [
                    "route-target",
                    "inet-vpn",
                    "inet6-vpn",
                    "e-vpn",
                    "erm-vpn"
                ]
            },
[...]
            "router_type": "control-node",
[...]

===> Then the BGP router object for a remote peering is configured with a subset of these address families:

{
    "bgp-router": {
        "bgp_router_parameters": {
            "address": "10.1.1.87",
            "address_families": {
                "family": [
                    "route-target",
                    "e-vpn",
                    "erm-vpn"
                ]
            },
[...]
            "router_type": "external-control-node", # same happens with router_type "router"
        }

===> The address family list in the remote BGP router object 10.1.1.87 is not really taken into account. The AF negotiation only considers the configuration of the local control node 10.0.0.85, which supports all address families (according to the configuration at the beginning of this description). In other words, if 10.1.1.87 supports inet(6)-vpn, the BGP session between 10.0.0.85 and 10.1.1.87 will negotiate and exchange inet(6)-vpn prefixes.

===> As a result, it is not possible today to federate two clusters for L2 AFs while peering CN with the SDN gateway for L3 AFs.

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/28723
Submitter: Nischal Sheth (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/28724
Submitter: Nischal Sheth (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/28723
Committed: http://github.org/Juniper/contrail-controller/commit/c300fbd525367df5169fa988c9e9acbb6c34cd71
Submitter: Zuul (<email address hidden>)
Branch: master

commit c300fbd525367df5169fa988c9e9acbb6c34cd71
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
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.

Change-Id: I6d130cc59673dcdc42013678b4f93f6f6dfafad2
Closes-Bug: 1664343

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/28724
Committed: http://github.org/Juniper/contrail-controller/commit/519c27ad335dc9db7b7788d5f1321b46b3b5e1c7
Submitter: Zuul (<email address hidden>)
Branch: R3.2

commit 519c27ad335dc9db7b7788d5f1321b46b3b5e1c7
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
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.

Change-Id: I6d130cc59673dcdc42013678b4f93f6f6dfafad2
Closes-Bug: 1664343

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/28957
Submitter: Nischal Sheth (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/28959
Submitter: Nischal Sheth (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/28959
Committed: http://github.org/Juniper/contrail-controller/commit/456f800719f0d8e5f10e2c962312cc50935bff1f
Submitter: Zuul (<email address hidden>)
Branch: R3.0

commit 456f800719f0d8e5f10e2c962312cc50935bff1f
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
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.

Change-Id: I6d130cc59673dcdc42013678b4f93f6f6dfafad2
Closes-Bug: 1664343

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/28957
Committed: http://github.org/Juniper/contrail-controller/commit/3aa73d49ed477c997cf3438349a3262af52e1ba6
Submitter: Zuul (<email address hidden>)
Branch: R3.1

commit 3aa73d49ed477c997cf3438349a3262af52e1ba6
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
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.

Change-Id: I6d130cc59673dcdc42013678b4f93f6f6dfafad2
Closes-Bug: 1664343
(cherry picked from commit 519c27ad335dc9db7b7788d5f1321b46b3b5e1c7)