-.. _sdnvpn-overview:
-
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) Tim Irnich, (tim.irnich@ericsson.com) and others
+.. SPDX-License-Identifier: CC-BY-4.0
+.. (c) OPNFV, Ericsson AB and others.
=======
SDN VPN
=======
-A high-level description of the scenarios is provided in this section.
-For details of the scenarios and their provided capabilities refer to
-the scenario description document:
-http://artifacts.opnfv.org/danube/sdnpvn/scenarios/os-odl_l2-bgpvpn/index.html
-
The BGPVPN feature enables creation of BGP VPNs on the Neutron API according to the OpenStack
-BGPVPN blueprint at https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-vpn.
+BGPVPN blueprint at `Neutron Extension for BGP Based VPN <https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-vpn>`_.
+
In a nutshell, the blueprint defines a BGPVPN object and a number of ways
how to associate it with the existing Neutron object model, as well as a unique
definition of the related semantics. The BGPVPN framework supports a backend
SDNVPN Testing Suite
====================
-An overview of the SDNVPN Test is depicted here. More details for each test case are provided:
-https://wiki.opnfv.org/display/sdnvpn/SDNVPN+Testing
-
- BGPVPN Tempest test cases
- - Create BGPVPN passes
- - Create BGPVPN as non-admin fails
- - Delete BGPVPN as non-admin fails
- - Show BGPVPN as non-owner fails
- - List BGPVPNs as non-owner fails
- - Show network associated BGPVPNs as non-owner fails
- - List network associated BGPVPNs as non-owner fails
- - Associate/Deassociate a network to a BGPVPN resource passes
- - Update route targets on a BGPVPN passes
- - Update route targets on a BGPVPN as non-admin fails
- - Reject the creation of BGPVPN with invalid route targets passes
- - Reject the update of BGPVPN with invalid route targets passes
- - Reject the association on an invalid network to a BGPVPN passes
- - Reject the diassociation on an invalid network to a BGPVPN passes
- - Associate/Deassociate a router to a BGPVPN resource passes
- - Attach the subnet of an associated network to an associated router of the same BGVPN passes
-
-
-
- Functest scenario specific tests:
-
- Test Case 1 - VPN provides connectivity between subnets, using network association
- Name: VPN connecting Neutron networks and subnets
- Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
-
- Test setup procedure:
- Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1
- Moreover all ports have 10.10.10/24 addresses (this subnet is denoted SN1 in the following)
- Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
- Moreover all ports have 10.10.11/24 addresses (this subnet is denoted SN2 in the following)
-
- Test execution:
- Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
- Associate SN1 to VPN1
- Ping from VM1 to VM2 should work
- Ping from VM1 to VM3 should work
- Ping from VM1 to VM4 should not work
- Associate SN2 to VPN1
- Ping from VM4 to VM5 should work
- Ping from VM1 to VM4 should not work (disabled until isolation fixed upstream)
- Ping from VM1 to VM5 should not work (disabled until isolation fixed upstream)
- Change VPN 1 so that iRT=eRT
- Ping from VM1 to VM4 should work
- Ping from VM1 to VM5 should work
-
- Test Case 2 - tenant separation
- Name: Using VPNs for tenant separation
- Description: Using VPNs to isolate tenants so that overlapping IP address ranges can be used
-
- Test setup procedure:
- Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1.
- VM1 and VM2 have IP addresses in a subnet SN1 with range 10.10.10/24
- VM1: 10.10.10.11, running an HTTP server which returns "I am VM1" for any HTTP request
- (or something else than an HTTP server)
- VM2: 10.10.10.12, running an HTTP server which returns "I am VM2" for any HTTP request
- VM3 has an IP address in a subnet SN2 with range 10.10.11/24
- VM3: 10.10.11.13, running an HTTP server which returns "I am VM3" for any HTTP request
- Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
- VM4 has an address in a subnet SN1b with range 10.10.10/24
- VM4: 10.10.10.12 (the same as VM2), running an HTTP server which returns "I am VM4" for any HTTP request
- VM5 has an address in a subnet SN2b with range 10.10.11/24
- VM5: 10.10.11.13 (the same as VM3), running an HTTP server which returns "I am VM5" for any HTTP request
-
- Test execution:
- Create VPN 1 with iRT=eRT=RT1 and associate N1 to it
- HTTP from VM1 to VM2 and VM3 should work
- It returns "I am VM2" and "I am VM3" respectively
- HTTP from VM1 to VM4 and VM5 should not work
- It never returns "I am VM4" or "I am VM5"
- Create VPN2 with iRT=eRT=RT2 and associate N2 to it
- HTTP from VM4 to VM5 should work
- It returns "I am VM5"
- HTTP from VM4 to VM1 and VM3 should not work
- It never returns "I am VM1" or "I am VM3"
-
-
- Test Case 3 - Data Center Gateway integration
- Name: Data Center Gateway integration
- Description: Investigate the peering functionality of BGP protocol,
- using a Zrpcd/Quagga router and OpenDaylight Controller
-
- Test setup procedure:
- Search in the pool of nodes and find one Compute node and one Controller nodes, that have OpenDaylight controller running
- Start an instance using ubuntu-16.04-server-cloudimg-amd64-disk1.img image and in it run the Quagga setup script
- Start bgp router in the Controller node, using odl:configure-bgp
-
- Test execution:
- Set up a Quagga instance in a nova compute node
- Start a BGP router with OpenDaylight in a controller node
- Add the Quagga running in the instance as a neighbor
- Check that bgpd is running
- Verify that the OpenDaylight and gateway Quagga peer each other
- Start an instance in a second nova compute node and connect it with a new network, (Network 3-3).
- Create a bgpvpn (include parameters route-distinguisher and route-targets) and associate it with the network created
- Define the same route-distinguisher and route-targets on the simulated quagga side
- Check that the routes from the Network 3-3 are advertised towards simulated Quagga VM
-
- Test Case 4 - VPN provides connectivity between subnets using router association
- Functest: variant of Test Case 1.
- Set up a Router R1 with one connected network/subnet N1/S1.
- Set up a second network N2.
- Create VPN1 and associate Router R1 and Network N2 to it.
- Hosts from N2 should be able to reach hosts in N1.
-
- Name: VPN connecting Neutron networks and subnets using router association
- Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
-
- Test setup procedure:
- Set up VM1 and VM2 on Node1 and VM3 on Node2,
- All VMs have ports in the same Neutron Network N1 and 10.10.10/24 addresses
- (this subnet is denoted SN1 in the following).
- N1/SN1 are connected to router R1.
- Set up VM4 on Node1 and VM5 on Node2,
- Both VMs have ports in Neutron Network N2 and having 10.10.11/24 addresses
- (this subnet is denoted SN2 in the following)
-
- Test execution:
- Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
- Associate R1 to VPN1
- Ping from VM1 to VM2 should work
- Ping from VM1 to VM3 should work
- Ping from VM1 to VM4 should not work
- Associate SN2 to VPN1
- Ping from VM4 to VM5 should work
- Ping from VM1 to VM4 should not work
- Ping from VM1 to VM5 should not work
- Change VPN1 so that iRT=eRT
- Ping from VM1 to VM4 should work
- Ping from VM1 to VM5 should work
-
- Test Case 7 - Network associate a subnet with a router attached to a VPN and
- verify floating IP functionality (disabled, because of ODL Bug 6962)
-
- A test for https://bugs.opendaylight.org/show_bug.cgi?id=6962
-
- Setup procedure:
- Create VM1 in a subnet with a router attached.
- Create VM2 in a different subnet with another router attached.
- Network associate them to a VPN with iRT=eRT
- Ping from VM1 to VM2 should work
- Assign a floating IP to VM1
- Pinging the floating IP should work
-
- Test Case 8 - Router associate a subnet with a router attached to a VPN and
- verify floating IP functionality
-
- Setup procedure:
- Create VM1 in a subnet with a router which is connected with the gateway
- Create VM2 in a different subnet without a router attached.
- Assoc the two networks in a VPN iRT=eRT
- One with router assoc, other with net assoc
- Try to ping from one VM to the other
- Assign a floating IP to the VM in the router assoc network
- Ping it
-
- Test Case 9 - Check fail mode in OVS br-int interfaces
- This testcase checks if the fail mode is always “secure”.
- To accomplish it, a check is performed on all OVS br-int interfaces, for all OpenStack nodes.
- The testcase is considered as successful if all OVS br-int interfaces have fail_mode=secure
-
-
- Test Case 10 - Check the communication between a group of VMs
- This testcase investigates if communication between a group of VMs is interrupted upon deletion
- and creation of VMs inside this group.
-
- Test case flow:
- Create 3 VMs: VM_1 on compute 1, VM_2 on compute 1, VM_3 on compute 2.
- All VMs ping each other.
- VM_2 is deleted.
- Traffic is still flying between VM_ 1 and VM_3.
- A new VM, VM_ 4 is added to compute 1.
- Traffic is not interrupted and VM_4 can be reached as well.
-
-
- Testcase 11: test Opendaylight resync and group_add_mod feature mechanisms
- This is testcase to test Opendaylight resync and group_add_mod feature functionalities
-
- Sub-testcase 11-1:
- Create and start 2 VMs, connected to a common Network.
- New groups should appear in OVS dump
- OVS disconnects and the VMs and the networks are cleaned.
- The new groups are still in the OVS dump,
- cause OVS is not connected anymore, so it is not notified that the groups are deleted
- OVS re-connects.
- The new groups should be deleted, as Opendaylight has to resync the groups totally and
- should remove the groups since VMS are deleted.
-
- Sub-testcase 11-2:
- Create and start 2 VMs, connected to a common Network.
- New groups should appear in OVS dump
- OVS disconnects.
- The new groups are still in the OVS dump, cause OVS is not connected anymore,
- so it is not notified that the groups are deleted
- OVS re-connects.
- The new groups should be still there, as the topology remains. Opendaylight Carbon's
- group_add_mod mechanism should handle the already existing group.
- OVS re-connects.
- The new groups should be still there, as the topology remains.
- Opendaylight Carbon’ group_add_mod mechanism should handle the already existing group.
-
- Testcase 12: Test Resync mechanism between Opendaylight and OVS
- This is the testcase to validate flows and groups are programmed correctly
- after resync which is triggered by OVS del-controller/set-controller commands
- and adding/remove iptables drop rule on OF port 6653.
-
- Sub-testcase 12-1:
- Create and start 2 VMs, connected to a common Network
- New flows and groups were added to OVS
- Reconnect the OVS by running del-ontroller and set-controller commands
- The flows and groups are still intact and none of the flows/groups
- are removed
- Reconnect the OVS by adding ip tables drop rule and then remove it
- The flows and groups are still intact and none of the flows/groups
- are removed
-
- Testcase 13: Test ECMP (Equal-cost multi-path routing) for the extra route
- This testcase validates spraying behavior in OvS when an extra route is
- configured such that it can be reached from two nova VMs in the
- same network.
-
- Setup procedure:
- Create and start VM1 and VM2 configured with sub interface set to same ip
- address in both VMs, connected to a common network/router.
- Update the VM1 and VM2's Neutron ports with allowed address pairs for sub
- interface ip/mac addresses.
- Create BGPVPN with two route distinguishers.
- Associate router with BGPVPN.
- Update the router with above sub-interface ip address with nexthops set to
- VMs ip addresses.
- Create VM3 and connected to the same network.
- Ping sub-interface IP address from VM3.
+An overview of the SDNVPN Test is depicted here. A more detailed description of each test case can
+be found at `SDNVPN Testing <https://wiki.opnfv.org/display/sdnvpn/SDNVPN+Testing>`_.
+
+BGPVPN Tempest test cases
+"""""""""""""""""""""""""
+
+#. Create BGPVPN passes
+#. Create BGPVPN as non-admin fails
+#. Delete BGPVPN as non-admin fails
+#. Show BGPVPN as non-owner fails
+#. List BGPVPNs as non-owner fails
+#. Show network associated BGPVPNs as non-owner fails
+#. List network associated BGPVPNs as non-owner fails
+#. Associate/Deassociate a network to a BGPVPN resource passes
+#. Update route targets on a BGPVPN passes
+#. Update route targets on a BGPVPN as non-admin fails
+#. Reject the creation of BGPVPN with invalid route targets passes
+#. Reject the update of BGPVPN with invalid route targets passes
+#. Reject the association on an invalid network to a BGPVPN passes
+#. Reject the diassociation on an invalid network to a BGPVPN passes
+#. Associate/Deassociate a router to a BGPVPN resource passes
+#. Attach the subnet of an associated network to an associated router of the same BGVPN passes
+
+
+
+Functest scenario specific tests
+""""""""""""""""""""""""""""""""""
+- **Test Case 1**: VPN provides connectivity between subnets, using network association
+
+ Name: VPN connecting Neutron networks and subnets
+ Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
+ Test setup procedure:Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1
+
+ Moreover all ports have 10.10.10/24 addresses (this subnet is denoted SN1 in the following)
+ Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
+ Moreover all ports have 10.10.11/24 addresses (this subnet is denoted SN2 in the following)
+
+ Test execution:
+ * Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
+ * Associate SN1 to VPN1
+ * Ping from VM1 to VM2 should work
+ * Ping from VM1 to VM3 should work
+ * Ping from VM1 to VM4 should not work
+ * Associate SN2 to VPN1
+ * Ping from VM4 to VM5 should work
+ * Ping from VM1 to VM4 should not work (disabled until isolation fixed upstream)
+ * Ping from VM1 to VM5 should not work (disabled until isolation fixed upstream)
+ * Change VPN 1 so that iRT=eRT
+ * Ping from VM1 to VM4 should work
+ * Ping from VM1 to VM5 should work
+
+- **Test Case 2**: Tenant separation
+
+ Name: Using VPNs for tenant separation
+ Description: Using VPNs to isolate tenants so that overlapping IP address ranges can be used
+
+ Test setup procedure:
+ * Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1.
+ * VM1 and VM2 have IP addresses in a subnet SN1 with range 10.10.10/24
+ * VM1: 10.10.10.11, running an HTTP server which returns "I am VM1" for any HTTP request (or something else than an HTTP server)
+ * VM2: 10.10.10.12, running an HTTP server which returns "I am VM2" for any HTTP request
+ * VM3 has an IP address in a subnet SN2 with range 10.10.11/24
+ * VM3: 10.10.11.13, running an HTTP server which returns "I am VM3" for any HTTP request
+ * Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
+ * VM4 has an address in a subnet SN1b with range 10.10.10/24
+ * VM4: 10.10.10.12 (the same as VM2), running an HTTP server which returns "I am VM4" for any HTTP request
+ * VM5 has an address in a subnet SN2b with range 10.10.11/24
+ * VM5: 10.10.11.13 (the same as VM3), running an HTTP server which returns "I am VM5" for any HTTP request
+
+ Test execution:
+ * Create VPN 1 with iRT=eRT=RT1 and associate N1 to it
+ * HTTP from VM1 to VM2 and VM3 should work
+ It returns "I am VM2" and "I am VM3" respectively
+ * HTTP from VM1 to VM4 and VM5 should not work
+ It never returns "I am VM4" or "I am VM5"
+ * Create VPN2 with iRT=eRT=RT2 and associate N2 to it
+ * HTTP from VM4 to VM5 should work
+ It returns "I am VM5"
+ * HTTP from VM4 to VM1 and VM3 should not work
+ It never returns "I am VM1" or "I am VM3"
+
+
+- **Test Case 3**: Data Center Gateway integration
+
+ Name: Data Center Gateway integration
+ Description: Investigate the peering functionality of BGP protocol, using a Zrpcd/Quagga router
+ and OpenDaylight Controller
+
+ Test setup procedure:
+ * Search in the pool of nodes and find one Compute node and one Controller nodes, that have OpenDaylight controller running
+ * Start an instance using ubuntu-16.04-server-cloudimg-amd64-disk1.img image and in it run the Quagga setup script
+ * Start bgp router in the Controller node, using odl:configure-bgp
+
+ Test execution:
+ * Set up a Quagga instance in a nova compute node
+ * Start a BGP router with OpenDaylight in a controller node
+ * Add the Quagga running in the instance as a neighbor
+ * Check that bgpd is running
+ * Verify that the OpenDaylight and gateway Quagga peer each other
+ * Start an instance in a second nova compute node and connect it with a new network, (Network 3-3).
+ * Create a bgpvpn (include parameters route-distinguisher and route-targets) and associate it with the network created
+ * Define the same route-distinguisher and route-targets on the simulated quagga side
+ * Check that the routes from the Network 3-3 are advertised towards simulated Quagga VM
+
+- **Test Case 4**: VPN provides connectivity between subnets using router association
+
+ Functest: variant of Test Case 1.
+ * Set up a Router R1 with one connected network/subnet N1/S1.
+ * Set up a second network N2.
+ * Create VPN1 and associate Router R1 and Network N2 to it.
+ * Hosts from N2 should be able to reach hosts in N1.
+
+ Name: VPN connecting Neutron networks and subnets using router association
+ Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
+
+ Test setup procedure:
+ * Set up VM1 and VM2 on Node1 and VM3 on Node2,
+ * All VMs have ports in the same Neutron Network N1 and 10.10.10/24 addresses
+ * (this subnet is denoted SN1 in the following).
+ * N1/SN1 are connected to router R1.
+ * Set up VM4 on Node1 and VM5 on Node2,
+ * Both VMs have ports in Neutron Network N2 and having 10.10.11/24 addresses
+ * (this subnet is denoted SN2 in the following)
+
+ Test execution:
+ * Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
+ * Associate R1 to VPN1
+ Ping from VM1 to VM2 should work
+ Ping from VM1 to VM3 should work
+ Ping from VM1 to VM4 should not work
+ * Associate SN2 to VPN1
+ Ping from VM4 to VM5 should work
+ Ping from VM1 to VM4 should not work
+ Ping from VM1 to VM5 should not work
+ * Change VPN1 so that iRT=eRT
+ Ping from VM1 to VM4 should work
+ Ping from VM1 to VM5 should work
+
+- **Test Case 7** - Network associate a subnet with a router attached to a VPN and verify floating IP
+ functionality (disabled, because of ODL Bug 6962)
+
+ A test for https://bugs.opendaylight.org/show_bug.cgi?id=6962
+
+ Setup procedure:
+ * Create VM1 in a subnet with a router attached.
+ * Create VM2 in a different subnet with another router attached.
+ * Network associate them to a VPN with iRT=eRT
+ * Ping from VM1 to VM2 should work
+ * Assign a floating IP to VM1
+ * Pinging the floating IP should work
+
+- **Test Case 8** - Router associate a subnet with a router attached to a VPN and
+ verify floating IP functionality
+
+ Setup procedure:
+ * Create VM1 in a subnet with a router which is connected with the gateway
+ * Create VM2 in a different subnet without a router attached.
+ * Assoc the two networks in a VPN iRT=eRT
+ * One with router assoc, other with net assoc
+ * Try to ping from one VM to the other
+ * Assign a floating IP to the VM in the router assoc network
+ * Ping it
+
+- **Test Case 9** - Check fail mode in OVS br-int interfaces
+
+ This testcase checks if the fail mode is always 'secure'.
+ To accomplish it, a check is performed on all OVS br-int interfaces, for all OpenStack nodes.
+ The testcase is considered as successful if all OVS br-int interfaces have fail_mode=secure
+
+- **Test Case 10** - Check the communication between a group of VMs
+
+ This testcase investigates if communication between a group of VMs is interrupted upon deletion
+ and creation of VMs inside this group.
+
+ Test case flow:
+ * Create 3 VMs: VM_1 on compute 1, VM_2 on compute 1, VM_3 on compute 2.
+ * All VMs ping each other.
+ * VM_2 is deleted.
+ * Traffic is still flying between VM_1 and VM_3.
+ * A new VM, VM_4 is added to compute 1.
+ * Traffic is not interrupted and VM_4 can be reached as well.
+
+
+- **Testcase 11**: test Opendaylight resync and group_add_mod feature mechanisms
+
+ This is testcase to test Opendaylight resync and group_add_mod feature functionalities
+
+ Sub-testcase 11-1:
+ * Create and start 2 VMs, connected to a common Network.
+ New groups should appear in OVS dump
+ * OVS disconnects and the VMs and the networks are cleaned.
+ The new groups are still in the OVS dump,
+ cause OVS is not connected anymore, so it is not notified that the groups are deleted
+ * OVS re-connects.
+ The new groups should be deleted, as Opendaylight has to resync the groups totally and
+ should remove the groups since VMS are deleted.
+
+ Sub-testcase 11-2:
+ * Create and start 2 VMs, connected to a common Network.
+ New groups should appear in OVS dump
+ * OVS disconnects.
+ The new groups are still in the OVS dump, cause OVS is not connected anymore,
+ so it is not notified that the groups are deleted
+ * OVS re-connects.
+ The new groups should be still there, as the topology remains. Opendaylight Carbon's
+ group_add_mod mechanism should handle the already existing group.
+ * OVS re-connects.
+ The new groups should be still there, as the topology remains.
+ Opendaylight Carbon’ group_add_mod mechanism should handle the already existing group.
+
+- **Testcase 12**: Test Resync mechanism between Opendaylight and OVS
+ This is the testcase to validate flows and groups are programmed correctly
+ after resync which is triggered by OVS del-controller/set-controller commands
+ and adding/remove iptables drop rule on OF port 6653.
+
+ Sub-testcase 12-1:
+ * Create and start 2 VMs, connected to a common Network
+ New flows and groups were added to OVS
+ * Reconnect the OVS by running del-ontroller and set-controller commands
+ The flows and groups are still intact and none of the flows/groups
+ are removed
+ * Reconnect the OVS by adding ip tables drop rule and then remove it
+ The flows and groups are still intact and none of the flows/groups
+ are removed
+
+- **Testcase 13**: Test ECMP (Equal-cost multi-path routing) for the extra route
+
+ This testcase validates spraying behavior in OvS when an extra route is
+ configured such that it can be reached from two nova VMs in the
+ same network.
+
+ Setup procedure:
+ * Create and start VM1 and VM2 configured with sub interface set to same ip address in both VMs,
+ connected to a common network/router.
+ * Update the VM1 and VM2's Neutron ports with allowed address pairs for sub interface ip/mac
+ addresses.
+ * Create BGPVPN with two route distinguishers.
+ * Associate router with BGPVPN.
+ * Update the router with above sub-interface ip address with nexthops set to VMs ip addresses.
+ * Create VM3 and connected to the same network.
+ * Ping sub-interface IP address from VM3.
Code Review / sdnvpn.git / commitdiff