diff options
| -rw-r--r-- | INFO.yaml | 79 | ||||
| -rw-r--r-- | docs/development/overview/index.rst | 490 | ||||
| -rw-r--r-- | docs/release/installation/index.rst | 29 | ||||
| -rw-r--r-- | sdnvpn/artifacts/quagga_setup.sh | 20 | ||||
| -rw-r--r-- | sdnvpn/lib/quagga.py | 8 | ||||
| -rw-r--r-- | sdnvpn/test/functest/testcase_3.py | 12 |
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) |