summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--INFO.yaml79
-rw-r--r--docs/development/overview/index.rst490
-rw-r--r--docs/release/installation/index.rst29
-rw-r--r--sdnvpn/artifacts/quagga_setup.sh20
-rw-r--r--sdnvpn/lib/quagga.py8
-rw-r--r--sdnvpn/test/functest/testcase_3.py12
6 files changed, 359 insertions, 279 deletions
diff --git a/INFO.yaml b/INFO.yaml
new file mode 100644
index 0000000..3968ad8
--- /dev/null
+++ b/INFO.yaml
@@ -0,0 +1,79 @@
+---
+project: 'SDN Distributed Routing and VPN'
+project_creation_date: 'September 1st, 2015'
+project_category: 'Collaborative Development'
+lifecycle_state: 'Incubation'
+project_lead: &opnfv_sdnvpn_ptl
+ name: 'Tim Irnich'
+ email: 'tim.irnich@ericsson.com'
+ id: 'timirnich'
+ company: 'ericsson.com'
+ timezone: 'Unknown'
+primary_contact: *opnfv_sdnvpn_ptl
+issue_tracking:
+ type: 'jira'
+ url: 'https://jira.opnfv.org/projects/sdnvpn'
+ key: 'sdnvpn'
+mailing_list:
+ type: 'mailman2'
+ url: 'opnfv-tech-discuss@lists.opnfv.org'
+ tag: '[sdnvpn]'
+realtime_discussion:
+ type: irc
+ server: 'freenode.net'
+ channel: '#opnfv-sdnvpn'
+meetings:
+ - type: 'gotomeeting+irc'
+ agenda: # eg: 'https://wiki.opnfv.org/display/'
+ url: # eg: 'https://global.gotomeeting.com/join/819733085'
+ server: 'freenode.net'
+ channel: '#opnfv-meeting'
+ repeats: 'weekly'
+ time: # eg: '16:00 UTC'
+repositories:
+ - 'sdnvpn'
+committers:
+ - <<: *opnfv_sdnvpn_ptl
+ - name: 'Prem Sankar Gopannan'
+ email: 'prem.sankar.g@ericsson.com'
+ company: 'ericsson.com'
+ id: 'premsankar74'
+ - name: 'Nikolas Hermanns'
+ email: 'nikolas.hermanns@ericsson.com'
+ company: 'ericsson.com'
+ id: 'enikher'
+ - name: 'Jose Lausuch'
+ email: 'jalausuch@suse.com'
+ company: 'suse.com'
+ id: 'jose.lausuch'
+ - name: 'Thomas Morin'
+ email: 'thomas.morin@orange.com'
+ company: 'orange.com'
+ id: 'tmmorin'
+ - name: 'Thomas Sounapoglou'
+ email: 'soth@intracom-telecom.com'
+ company: 'intracom-telecom.com'
+ id: 'tomsou'
+ - name: 'Periyasamy Palanisamy'
+ email: 'periyasamy.palanisamy@ericsson.com'
+ company: 'ericsson.com'
+ id: 'pperiyasamy'
+ - name: 'Periyasamy Palanisamy'
+ email: 'periyasamy.palanisamy@ericsson.com'
+ company: 'ericsson.com'
+ id: 'pperiyasamy'
+ - name: 'Nikos Karandreas'
+ email: 'nick@intracom-telecom.com'
+ company: 'intracom-telecom.com'
+ id: 'nick_kar'
+ - name: 'Dimitrios Tsiolakis'
+ email: 'dmts@intracom-telecom.com'
+ company: 'intracom-telecom.com'
+ id: 'dimitris_'
+tsc:
+ # yamllint disable rule:line-length
+ approval: 'http//meetbot.opnfv.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-09-01-13.59.html'
+ # yamllint enable rule:line-length
+ changes:
+ - type: 'promotion'
+ link: '(Helpdesk#26575)'
diff --git a/docs/development/overview/index.rst b/docs/development/overview/index.rst
index 021ace9..4511e0a 100644
--- a/docs/development/overview/index.rst
+++ b/docs/development/overview/index.rst
@@ -1,20 +1,14 @@
-.. _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
@@ -26,238 +20,244 @@ implementation through the ODL NetVirt project.
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.
diff --git a/docs/release/installation/index.rst b/docs/release/installation/index.rst
index 2625ef9..ded6a78 100644
--- a/docs/release/installation/index.rst
+++ b/docs/release/installation/index.rst
@@ -1,8 +1,6 @@
-.. _sdnvpn-installation:
-
.. 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 feature installation
@@ -71,8 +69,8 @@ install the following packages:
fuseiso genisoimage blackbox xterm python-pip \
python-git python-dev python-oslo.config \
python-pip python-dev libffi-dev libxml2-dev \
- libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \
- expect curl python-netaddr p7zip-full
+ libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \
+ expect curl python-netaddr p7zip-full
sudo pip install GitPython pyyaml netaddr paramiko lxml scp \
python-novaclient python-neutronclient python-glanceclient \
@@ -87,17 +85,14 @@ First of all the opnfv-fuel repository needs to be cloned:
git clone ssh://<user>@gerrit.opnfv.org:29418/fuel
-To check out a specific
-version of OPNFV, checkout the appropriate branch:
+To check out a specific version of OPNFV, checkout the appropriate branch:
::
cd fuel
- git checkout stable/<colorado|danube|euphrates|fraser>
+ git checkout stable/gambia
Now download the corresponding OPNFV Fuel ISO into an appropriate folder from
-the website
-::
- https://www.opnfv.org/software/downloads/release-archives
+the website https://www.opnfv.org/software/downloads/release-archives
Have in mind that the fuel repo version needs to map with the downloaded
artifact. Note: it is also possible to build the Fuel image using the
@@ -226,19 +221,21 @@ Virtual deployment using Apex installer
=======================================
Prerequisites
-^^^^^^^^^^^^^
+-------------
+
For Virtual Apex deployment a host with Centos 7 is needed. This installation
was tested on centos-release-7-2.1511.el7.centos.2.10.x86_64 however any other
Centos 7 version should be fine.
Build and Deploy
-^^^^^^^^^^^^^^^^
-Download the Apex repo from opnfv gerrit and checkout stable/danube:
+----------------
+
+Download the Apex repo from opnfv gerrit and checkout stable/gambia:
::
git clone ssh://<user>@gerrit.opnfv.org:29418/apex
cd apex
- git checkout stable/danube
+ git checkout stable/gambia
In apex/contrib you will find simple_deploy.sh:
::
diff --git a/sdnvpn/artifacts/quagga_setup.sh b/sdnvpn/artifacts/quagga_setup.sh
index fbd229f..b3bf786 100644
--- a/sdnvpn/artifacts/quagga_setup.sh
+++ b/sdnvpn/artifacts/quagga_setup.sh
@@ -9,22 +9,22 @@ echo 'ubuntu:opnfv' | chpasswd
sleep 100
# Variables to be filled in with python
-NEIGHBOR_IP=$1
-OWN_IP=$2
+NEIGHBOR_IP={0}
+OWN_IP={1}
# directly access the instance from the external net without NAT
-EXT_NET_MASK=$3
-IP_PREFIX=$4
-RD=$5
-IRT=$6
-ERT=$7
+EXT_NET_MASK={2}
+IP_PREFIX={3}
+RD={4}
+IRT={5}
+ERT={6}
-if [[ $(getent hosts | awk '{print $2}') != *"$(cat /etc/hostname | awk '{print $1}')"* ]]
+if [[ $(getent hosts | awk '{{print $2}}') != *"$(cat /etc/hostname | awk '{{print $1}}')"* ]]
then
-echo "127.0.1.1 $(cat /etc/hostname | awk '{print $1}')" | tee -a /etc/hosts
+echo "127.0.1.1 $(cat /etc/hostname | awk '{{print $1}}')" | tee -a /etc/hosts
fi
quagga_int=''
-for net_int in $(netstat -ia | awk 'NR>2{print $1}');
+for net_int in $(netstat -ia | awk 'NR>2{{print $1}}');
do
if [ -z "$(ifconfig | grep $net_int)" ]
then
diff --git a/sdnvpn/lib/quagga.py b/sdnvpn/lib/quagga.py
index 0ea206e..f11e188 100644
--- a/sdnvpn/lib/quagga.py
+++ b/sdnvpn/lib/quagga.py
@@ -48,10 +48,10 @@ def gen_quagga_setup_script(controller_ip,
ip_prefix, rd, irt, ert):
with open(COMMON_CONFIG.quagga_setup_script_path) as f:
template = f.read()
- script = template % (controller_ip,
- fake_floating_ip,
- ext_net_mask,
- ip_prefix, rd, irt, ert)
+ script = template.format(controller_ip,
+ fake_floating_ip,
+ ext_net_mask,
+ ip_prefix, rd, irt, ert)
return script
diff --git a/sdnvpn/test/functest/testcase_3.py b/sdnvpn/test/functest/testcase_3.py
index fc22fa4..b06915a 100644
--- a/sdnvpn/test/functest/testcase_3.py
+++ b/sdnvpn/test/functest/testcase_3.py
@@ -174,6 +174,8 @@ def main():
(floatingip_ids, instance_ids, router_ids, network_ids, image_ids,
subnet_ids, interfaces, bgpvpn_ids, flavor_ids) = ([] for i in range(9))
+ quagga_vm = None
+ fake_fip = None
try:
_, flavor_id = test_utils.create_custom_flavor()
@@ -394,18 +396,20 @@ def main():
logger.error("exception occurred while executing testcase_3: %s", e)
raise
finally:
- test_utils.detach_instance_from_ext_br(quagga_vm, compute)
+ if quagga_vm is not None:
+ test_utils.detach_instance_from_ext_br(quagga_vm, compute)
test_utils.cleanup_nova(nova_client, instance_ids, flavor_ids)
test_utils.cleanup_glance(glance_client, image_ids)
test_utils.cleanup_neutron(neutron_client, floatingip_ids,
bgpvpn_ids, interfaces, subnet_ids,
router_ids, network_ids)
- bgp_nbr_disconnect_cmd = ("bgp-nbr -i %s -a 200 del"
- % fake_fip['fip_addr'])
+ if fake_fip is not None:
+ bgp_nbr_disconnect_cmd = ("bgp-nbr -i %s -a 200 del"
+ % fake_fip['fip_addr'])
+ test_utils.run_odl_cmd(controller, bgp_nbr_disconnect_cmd)
bgp_server_stop_cmd = ("bgp-rtr -r %s -a 100 del"
% controller_ext_ip)
odl_zrpc_disconnect_cmd = "bgp-connect -p 7644 -h 127.0.0.1 del"
- test_utils.run_odl_cmd(controller, bgp_nbr_disconnect_cmd)
test_utils.run_odl_cmd(controller, bgp_server_stop_cmd)
test_utils.run_odl_cmd(controller, odl_zrpc_disconnect_cmd)