As the current L3VPN service stands end-of-Oxygen release,
it is able to realize a VPN orchestrated by Neutron BGPVPN API.
-However, this orchestration is subjected heavily to timing
+However, this orchestration is subjected heavily to timing
and nature of how the orchestration was performed.
-To explain, piecemeal creating a Neutron BGPVPN using
+To explain, piecemeal creating a Neutron BGPVPN using
Openstack BGPVPN REST API (or) CLI and making
sure it is realized and then deleting the same Neutron BGPVPN
(via RESTAPI or CLI) would succeed.
-However, when the orchestration pattern on Openstack BGPVPN
+However, when the orchestration pattern on Openstack BGPVPN
API is turned to be driven through an automation script (or)
if the script uses Heat templates to automate and manage BGPVPNs,
the runs will expose failure to properly realize such orchestrated
VPNs in the OpenDaylight control plane (and thence data plane too).
-The failures themselves will go unnoticed to the Openstack
+The failures themselves will go unnoticed to the Openstack
Orchestrator (or user) since the Openstack Neutron will
provide a consistent view of available (or active) VPNs
while the VPNs being realized in OpenDaylight would be
Out of scope
------------
-a. Network-associated EVPNs
+a. Network-associated EVPNs
b. Router-associated EVPNs
Use Case Summary
----------------
This deals with making BGPVPN workflows inside ODL more robust when used with Neutron
-BGPVPN APIs. To add, when such Neutron BGPVPN APIs are applied through HOT templates,
+BGPVPN APIs. To add, when such Neutron BGPVPN APIs are applied through HOT templates,
the VPNs have to be realized consistently in both the control-plane datastores and
data-plane flows/routes.
RIB - Routing Information Base - Represents the routes held inside the ODL controller Quagga BGP.
-FIB - Forwarding Information Base - Represents the routes held inside ODL controller.
+FIB - Forwarding Information Base - Represents the routes held inside ODL controller.
For all the router-driven BGPVPNs below, please assume that two subnets (one IPv4 and one IPv6) are
associated to the router.
For the template types and their contents, please see CSIT section.
-UC 1: A net-driven BGPVPN creation with Network association
+UC 1: A net-driven BGPVPN creation with Network association
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (single HOT template)
template 1 - Create a VPN1 with RD1
Also make sure all of the VM IPs (and their secondaries) must be realized into VPN1.
Delete stack with template 1, make sure VPN1 disappears from the ODL controller.
-UC 2: A net-driven BGPVPN cycled through multiple Networks association
+UC 2: A net-driven BGPVPN cycled through multiple Networks association
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (multiple HOT templates)
template 1 - Create a VPN1 with RD1
template 3 - Create Network2, Create Subnet2, Boot VMs on the Network2, Associate Network2 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE C
-template 3 type - TYPE C
+template 2 type - TYPE C
+template 3 type - TYPE C
Create stack with template 1, make sure VPN1 appears in the ODL controller.
template 3 - Create Network2, Create Subnet2, Boot VMs on the Network2, Associate Network2 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE C
-template 3 type - TYPE C
+template 2 type - TYPE C
+template 3 type - TYPE C
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
template 2 - Create Network1, Create Subnet1, Boot VMs on the Network1, Associate Network1 into VPN1
template 3 - Create Network2, Create Subnet2 (same CIDR as Subnet1), Boot VMs on the Network2, Associate Network2 into VPN1
-template 1 type - TYPE B
-template 2 type - TYPE C
-template 3 type - TYPE C
+template 1 type - TYPE B
+template 2 type - TYPE C
+template 3 type - TYPE C
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
must be realized into VPN1.
-Delete stack with template 2
+Delete stack with template 2
All of the VM IPs (and their secondaries) on Network1 must be removed from VPN1.
Create stack with template 3
UC 2.5: Two net-driven BGPVPNs cycled through with same RouteDistinguisher and same Network
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
template 1 - Create Network1, Create Subnet1, Boot VMs on the Network1
-template 2 - Create a VPN1 with RD1 and associate Network1 to VPN1
+template 2 - Create a VPN1 with RD1 and associate Network1 to VPN1
template 3 - Create a VPN2 with RD1 and associate Network1 to VPN2
-template 1 type - TYPE D
-template 2 type - TYPE E
-template 3 type - TYPE E
+template 1 type - TYPE D
+template 2 type - TYPE E
+template 3 type - TYPE E
Create stack with template 1, make sure all the VMs appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
Delete stack with template 3, make sure that Network1 must be removed from VPN2.
Delete stack with template 1, make sure all the VMs disappear from the ODL controller.
-UC 2.6: A net-driven BGPVPN ordering VPN deletion before network deletion
+UC 2.6: A net-driven BGPVPN ordering VPN deletion before network deletion
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
template 1 - Create a VPN1 with RD1
template 2 - Create Network1, Create Subnet1, Boot VMs on the Network1, Associate Network1 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE C
+template 2 type - TYPE C
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
All of the VM IPs (and their secondaries) on Network1 must be removed from VPN1.
Make sure ELAN traffic continues to work.
-Delete stack with template 2
+Delete stack with template 2
Make sure all the VMs, Networks disappear from the ODL controller.
UC 2.7: A net-driven BGPVPN ordering network deletion before VPN deletion without disassociating the network
template 3 - Associate Network1 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE D
-template 3 type - TYPE F
+template 2 type - TYPE D
+template 3 type - TYPE F
Create stack with template 1, make sure VPN1 appears in the ODL controller.
-Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
+Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
must be realized into VPN1.
Create stack with template 3, and ensure all of the VM IPs (and their secondaries)
on Router1 must be realized into VPN1.
Delete stack with template 1, VPN1 must disappear from the ODL controller.
Delete stack with template 3, the stack deletion must fail and this is normal.
-UC 2.8: A router-driven BGPVPN creation with SingleStack Router association
+UC 2.8: A router-driven BGPVPN creation with SingleStack Router association
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (single HOT template)
-template 1 - Create a VPN1 with RD1. Create Network1, Create Subnet1, Boot VMs on the Network1,
+template 1 - Create a VPN1 with RD1. Create Network1, Create Subnet1, Boot VMs on the Network1,
Create Router1, Add Subnet1 to Router1 and Associate Router1 into VPN1
template 1 type - TYPE M
Delete stack with template 1, make sure VPN1 disappears from the ODL controller along with
removal of VM IPs from the VPN1.
-UC 2.9: A router-driven BGPVPN creation with DualStack Router association
+UC 2.9: A router-driven BGPVPN creation with DualStack Router association
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (single HOT template)
template 1 - Create a VPN1 with RD1. Create Network1, Create IPv4 Subnet11, Create IPv6 Subnet12
Also make sure all of the VM IPv4 and IPv6s (and their secondaries) on the Router1 must be realized into VPN1.
Delete stack with template 1, make sure VPN1 disappears from the ODL controller.
-UC 2.10: A router-driven BGPVPN cycled through with association and disassociation
+UC 2.10: A router-driven BGPVPN cycled through with association and disassociation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (multiple HOT templates)
template 1 - Create a VPN1 with RD1
template 3 - Associate Router1 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE O
-template 3 type - TYPE Q
+template 2 type - TYPE O
+template 3 type - TYPE Q
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
Delete stack with template 2, Router1 must disappear from the ODL controller.
Delete stack with template 1, VPN1 must disappear from the ODL controller.
-UC 2.10 variation 2 - A router-driven BGPVPN cycled through with association and disassociation
+UC 2.10 variation 2 - A router-driven BGPVPN cycled through with association and disassociation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (multiple HOT templates)
template 1 - Create a VPN1 with RD1.
template 3 - Associate Router1 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE O
-template 3 type - TYPE Q
+template 2 type - TYPE O
+template 3 type - TYPE Q
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
template 2 - Create Network1, Create IPv4 Subnet1, Create IPv6 Subnet2, Boot VMs on the Network1
Create Router1, Add Subnet1 to Router1, Add Subnet2 to Router1, Associate Router1 into VPN1
-template 1 type - TYPE B
+template 1 type - TYPE B
template 2 type - TYPE P
Create stack with template 1, make sure VPN1 appears in the ODL controller.
-Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
+Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
must be realized into VPN1.
Delete stack with template 2, make sure that Router2 must be removed from VPN1.
Create Router1, Add Subnet1 to Router1, Add Subnet2 to Router1
template 3 - Associate Router1 into VPN1
-template 1 type - TYPE B
-template 2 type - TYPE O
-template 3 type - TYPE Q
+template 1 type - TYPE B
+template 2 type - TYPE O
+template 3 type - TYPE Q
Create stack with template 1, make sure VPN1 appears in the ODL controller.
-Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
+Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
must be realized into VPN1.
Create stack with template 3, and ensure all of the VM IPs (and their secondaries)
on Router1 must be realized into VPN1.
Delete stack with template 1, VPN1 must disappear from the ODL controller.
Delete stack with template 3, the stack deletion must fail and this is normal.
-UC 2.12: A router-driven BGPVPN ordering VPN deletion before router deletion
+UC 2.12: A router-driven BGPVPN ordering VPN deletion before router deletion
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
template 1 - Create a VPN1 with RD1
template 2 - Create Network1, Create IPv4 Subnet1, Create IPv6 Subnet2, Boot VMs on the Network1
Create Router1, Add Subnet1 to Router1, Add Subnet2 to Router1, Associate Router1 to VPN1
template 1 type - TYPE B
-template 2 type - TYPE P
+template 2 type - TYPE P
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
All of the VM IPs (and their secondaries) on Router1 must be removed from VPN1.
Make sure ELAN traffic and Router1 traffic continues to work.
-Delete stack with template 2
+Delete stack with template 2
Make sure all the VMs, Routers disappear from the ODL controller.
-UC 2.13: Two router-driven BGPVPNs cycled through with same RouteDistinguisher and same Router
+UC 2.13: Two router-driven BGPVPNs cycled through with same RouteDistinguisher and same Router
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
template 1 - Create Network1, Create IPv4 Subnet1, Create IPv6 Subnet2, Boot VMs on the Network1
Create Router1, Add Subnet1 to Router1, Add Subnet2 to Router1
template 2 - Create a VPN1 with RD1 and Associate Router1 into VPN1
template 3 - Create a VPN2 with RD1 and Associate Router1 into VPN2
-template 1 type - TYPE O
-template 2 type - TYPE R
-template 3 type - TYPE R
+template 1 type - TYPE O
+template 2 type - TYPE R
+template 3 type - TYPE R
Create stack with template 1, make sure all the VMs appears in the ODL controller.
-Create stack with template 2, all of the VM IPs (and their secondaries) on Router1
+Create stack with template 2, all of the VM IPs (and their secondaries) on Router1
must be realized into VPN1.
Delete stack with template 2.
b. VPN Engine (VpnInstanceListener and VpnInterfaceManager)
c. BGP Engine (BGPManager)
d. VRF Engine (FIBManager)
-e. NAT Engine (NATService)
+e. NAT Engine (NATService)
f. EVPN Engine (EVPN in ELANManager)
All of the above engines enhancement is to enable safe parallel processing of multiple vpn-instances
---------------
VPN Engine:
^^^^^^^^^^^
-Currently Oper/VpnInstanceOpData is keyed by vrf-id (aka Route Distinguisher) and this kind
+Currently Oper/VpnInstanceOpData is keyed by vrf-id (aka Route Distinguisher) and this kind
of keying was all OK as we serviced only one VPNInstance at a time that would carry this vrf-id.
As we move to public cloud, the customers will start to use the neutron bgpvpn api
This specific VpnInstanceOpData datastore is referred by many services within ODL and so such services
must be updated on their consumption/production of information into this datastore.
-One more new model that maps a given RD (route-distinguisher) to an Active VpnInstance will be
+One more new model that maps a given RD (route-distinguisher) to an Active VpnInstance will be
required for use by the BGPEngine.
VRF Engine:
^^^^^^^^^^^
The VRFEngine does not use vpn-instance-uuid at all and uses only vrfTables as the
primary datastore for representing the FIB. This vrfTables has vrf-id (route-distinguisher)
-as the key, to maintain the FIB.
+as the key, to maintain the FIB.
This engine will be enhanced such that vrfTables become a child to a vpn-instance-uuid keyed
container thereby enabling multiple vpninstances to be managed regardless of whether such vpn-instances
^^^^^^^^^^^
The BGP Engine within ODL is primarily responsible for:
a. Pushing a route from its external neighbor into ODL
-b. Removing a route from its external neighbor from ODL
+b. Removing a route from its external neighbor from ODL
c. Advertising an ODL managed route to its external neighbor
d. Withdrawing an ODL managed route to its external neighbor
Since there can be more than one VpnInstance that can use a given route-distinguisher at a time within
Opendaylight (a situation where previous vpn-instance is being deleted while a new vpn-instance with same
RD being created), BGP Engine needs to know which of the vpn-instances out of the
-these to choose to import a route when it comes from an external neighbor (case a).
+these to choose to import a route when it comes from an external neighbor (case a).
-This is because, BGP Engine (and Quagga which has real BGP logic) within ODL operates only with
+This is because, BGP Engine (and Quagga which has real BGP logic) within ODL operates only with
route-distinguishers and not with vpn-instances. This is the same case with the other
-BGP neighbors too that talk to ODL BGP Engine.
+BGP neighbors too that talk to ODL BGP Engine.
As a result the BGP Engine will continue to work only with route-distinguishers but it will make a call
to the VpnEngine to figure out to which all vpn-instances an incoming route must be written to (case a).
^^^^^^^^^^^^^^^^^^
There are race conditions within the NeutronVPN that gets triggered when HOT templates are executed primarily in the
Neutron BGPVPN management path. These race conditions are around the Neutron Router, Neutron BGPVPN, Neutron Subnet
-and Neutron Network resources access and their management within NeutronVPN. So this engine will be enhanced to
+and Neutron Network resources access and their management within NeutronVPN. So this engine will be enhanced to
close out these race-conditions.
Pipeline changes
Yang changes
------------
-Changes will be needed in ``fib-rpc.yang`` , ``odl-fib.yang``
+Changes will be needed in ``fib-rpc.yang`` , ``odl-fib.yang``
to address this feature.
Changes will be needed in ``odl-l3vpn.yang`` and ``odl-fib.yang``
Usage
=====
-The feature can be excited by Openstack Neutron BGPVPN REST APIs (or) by
+The feature can be excited by Openstack Neutron BGPVPN REST APIs (or) by
Openstack Neutron BGPVPN CLIs.
As part of this spec implementation, we will actually be exciting Neutron BGPVPN
TYPE A
^^^^^^^
.. code-block:: none
- :caption: TYPE A
+ :caption: TYPE A
description: BGPVPN networking example TYPE A (admin)
heat_template_version: '2013-05-23'
TYPE C
^^^^^^^
.. code-block:: none
- :caption: TYPE C
+ :caption: TYPE C
description: BGPVPN networking example TYPE C (admin)
heat_template_version: '2013-05-23'
TYPE D
^^^^^^^
.. code-block:: none
- :caption: TYPE D
+ :caption: TYPE D
description: BGPVPN networking example TYPE D (admin)
heat_template_version: '2013-05-23'
type: OS::Neutron::BGPVPN-NET-ASSOCIATION
properties:
bgpvpn_id: "default VPN"
- network_id: "default Net1"
+ network_id: "default Net1"
TYPE F
^^^^^^^
type: OS::Neutron::BGPVPN-NET-ASSOCIATION
properties:
bgpvpn_id: "default VPN"
- network_id: "default Net1"
+ network_id: "default Net1"
TYPE M
^^^^^^^
bgpvpn_id: { get_resource: BGPVPN1 }
router_id: { get_resource: Router }
-TYPE N
+TYPE N
^^^^^^^
.. code-block:: none
:caption: TYPE M
properties:
network: { get_resource: Net2 }
cidr: 30.1.1.0/24
-
+
SubNet22:
type: OS::Neutron::Subnet
properties:
TYPE O
^^^^^^^
.. code-block:: none
- :caption: TYPE 0
+ :caption: TYPE 0
description: BGPVPN networking example (admin)
type: OS::Neutron::BGPVPN-ROUTER-ASSOCIATION
properties:
bgpvpn_id: "default VPN"
- router_id: "default Router"
+ router_id: "default Router"
TYPE R
^^^^^^^
.. code-block:: none
- :caption: TYPE R
+ :caption: TYPE R
description: BGPVPN networking example TYPE P (tenant)
heat_template_version: '2013-05-23'
type: OS::Neutron::BGPVPN-ROUTER-ASSOCIATION
properties:
bgpvpn_id: "default VPN"
- router_id: "default Router"
+ router_id: "default Router"
Documentation Impact
Code Review / netvirt.git / blobdiff