The current BGPaas implementation introduces major limitations when dealing with HA.
The problem is described in LP 1738049 -"bgpaas requires predictable selection of control node at vrouter to manage HA deployments" where a first "quick and dirty" fix is implemented. In this scenario, the order to control node can be configured in the vrouter-agent config file so as to have better predictability. This is a first level improvement which can help in POC, however it is very hard to operate and will not actually solve all scenarios (noticeably most VEPC solutions, where sub second convergence is a must have).
This LP is created to track the following enhancement which relies on the definition of extra metadata IPs dedicated to each Control Node.
Let's take an example of a 10/24 is a virtual network, where by default the following IPs will be hosted by the vrouter:
- .1 = Gateway
- .2 = metadata
With the current implementation, the VM can set up two BGP peers to .1 and .2 (neighbor 10.0.0.1 + neighbor 10.0.0.2). This approach will not work in case of fat Telco VNF such as VEPC, RAN / IMS etc...) because a same VN will be shared accross several computes. Two different computes (one hosting the .1 and the other the .2 bgpaas peers) can elect a same control node as the BGPaas peer. In case of failure of this CN, both peer will fail which result in slow convergence due to peer failure detection + reconnexion (non carrier class).
This enhancement proposes to - optionally - add dedicated metadata IPs to Virtual Networks where HA is requested. In this example, assuming we have 3 Control Nodes, we would have the following:
- 10.0.0.1 -> GW
- 10.0.0.2 -> Metadata
- 10.0.0.3 -> CN1 bgpaas
- 10.0.0.4 -> CN2 bgpaas
- 10.0.0.5 -> CN3 bgpaas
#1 This must be optional: default bgpaas is ok for non carrier class scenarios
#2 The relationship must be a 1:1 relationship 10.0.0.3 is mapped to Control Node X, while 10.0.0.4 is mapped to Control node Y
# This must be compliant with the distrbuted compute architecture (several control nodes).
=> pending question/point of vigilance to be discussed together with engineering/customers/VEPC vendors:
# shall we re-use .1 and .2 or mandate the introduction of extra IPs ?
# how to effectively define the mapping of CN to VN IPs (new "bgpaas-metadata-ip-preference" object where we can make sure that ?) ?
# need to adjust the ipam too
thanks !
In bgp_schema.xsd, we already have a reference from bgp-as-a-service to bgp-router today. This bgp-router is of type bgpaas-client.
We can add another reference to the same bgp-as-as-service object, to the desired bgp-router (where in router_type of the bgp-router shall be "control-node).
Also, we can add bgpaas-
diff --git a/schema/
index dc8f15f..911e28e 100644
--- a/schema/
+++ b/schema/
@@ -2507,6 +2507,10 @@ targetNamespace="http://
<!--#IFMAP-
Property(
'Ip address of the BGP peer.') -->
+<xsd:element name="bgpaas-
+<!--#IFMAP-
+ Property(
+ 'Ip address that maps to the Control-Node BGP Router.') -->
<xsd:element name="bgpaas-
<!--#IFMAP-
Property(
The desired 1:1 mapping can be enforced by UI/provisioning scripts but I wonder if that needs to be enforced by the back-end at all..