sdnvpn:main
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
sdnvpn:main [2015/11/30 15:28] Tim Irnich [Yardstick] added test case 2 |
sdnvpn:main [2015/12/01 12:22] (current) Ana Cunha |
||
|---|---|---|---|
| Line 13: | Line 13: | ||
| The tests should be written independently from the used backend, i.e. they should pass regardless which backend is deployed. For the CI pipeline we are aiming at one Jenkins job per supported backend which deploys the backend and runs the backend-independent tests against it. | The tests should be written independently from the used backend, i.e. they should pass regardless which backend is deployed. For the CI pipeline we are aiming at one Jenkins job per supported backend which deploys the backend and runs the backend-independent tests against it. | ||
| + | |||
| ==== Manual deployment procedures as starting point for installer development ==== | ==== Manual deployment procedures as starting point for installer development ==== | ||
| Line 24: | Line 25: | ||
| === Step 1: BGPVPN installation === | === Step 1: BGPVPN installation === | ||
| - | BGPVPN extends the Neutron API with VPN support. | + | BGPVPN extends the Neutron API with VPN support. Installation procedure: |
| - | + | * pip install the Python files | |
| - | - Install BGPVPN | + | * Install the Neutron extensions, example can be found at [[https://github.com/openstack/networking-bgpvpn/blob/master/devstack/plugin.sh]] |
| - | * deb/rpm package | + | |
| - | * pull from repo | + | |
| === Bagpipe backend === | === Bagpipe backend === | ||
| Line 40: | Line 39: | ||
| - ODL: activate VPN Service feature in karaf | - ODL: activate VPN Service feature in karaf | ||
| - | - step 2 | + | - Add to local.conf: NETWORKING_BGPVPN_DRIVER="BGPVPN:OpenDaylight:networking_bgpvpn.neutron.services.service_drivers.opendaylight.odl.OpenDaylightBgpvpnDriver:default" |
| ===== Test cases and CI ===== | ===== Test cases and CI ===== | ||
| Line 54: | Line 53: | ||
| === ODL VPN Service tests === | === ODL VPN Service tests === | ||
| - | RF tests for ODL VPN service using ODL REST API. The ODL integration-test repository is already cloned by Functest, the only thing that needs to be done is to include the vpnservice test suite in the list of tests to be run by Functest. | + | Name: ODL VPN Service API tests |
| + | Description: Robot Framework tests for ODL VPN service using ODL REST API. | ||
| + | |||
| + | The ODL integration-test repository is already cloned by Functest, the only thing that needs to be done is to include the vpnservice test suite in the list of tests to be run by Functest. | ||
| - Create VPN instance and check command return code | - Create VPN instance and check command return code | ||
| Line 73: | Line 75: | ||
| === OpenStack Neutron BGPVPN API tests === | === OpenStack Neutron BGPVPN API tests === | ||
| - | RF tests for BGPVPN Neutron API extensions. These tests will be kept in the SDN VPN repository for the time being and possibly be moved to the networking-bgpvpn repo at a later stage. | + | Name: OpenStack Neutron BGPVPN API tests |
| + | Description: Robot Framework tests for BGPVPN Neutron API extensions | ||
| + | |||
| + | These tests will be kept in the SDN VPN repository for the time being and possibly be moved to the networking-bgpvpn repo at a later stage. | ||
| - Create BGPVPN and check if the main parameters of the created object are correct. | - Create BGPVPN and check if the main parameters of the created object are correct. | ||
| Line 88: | Line 93: | ||
| ==== Yardstick ==== | ==== Yardstick ==== | ||
| - | 2 compute nodes N1 and N2 are used during the tests. | + | 2 compute nodes Node1 and Node2 are used during the tests. |
| Common test setup procedure: | Common test setup procedure: | ||
| Line 97: | Line 102: | ||
| * tbd | * tbd | ||
| - | === Test Case 1 === | + | === Test Case 1 - VPN provides connectivity between subnets === |
| - | test scope: VPNs provide connectivity across subnets if configured accordingly. | + | Name: VPN connecting Neutron networks and subnets |
| + | Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly. | ||
| Test setup procedure: | Test setup procedure: | ||
| - | * set up VM1 and VM2 on N1 and VM3 on N2, all having ports in the same Neutron Network N1 and all having 10.10.10/24 addresses (this subnet is denoted SN1 in the follwowing) | + | * set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1 and all having 10.10.10/24 addresses (this subnet is denoted SN1 in the following) |
| - | * Set up VM4 on N1 and VM5 on N2, both having ports in Neutron Network N2 and having 10.10.11/24 addresses (this subnet is denoted SN2 in the following) | + | * Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2 and having 10.10.11/24 addresses (this subnet is denoted SN2 in the following) |
| Test execution: | Test execution: | ||
| - | * Create VPN1 with eRT<>iRT (so that connected subnets should not rech each other) and associate SN1 to it | + | * Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other) and associate SN1 to it |
| * Ping from VM1 to VM2 should work | * Ping from VM1 to VM2 should work | ||
| * Ping from VM1 to VM3 should work | * Ping from VM1 to VM3 should work | ||
| Line 117: | Line 123: | ||
| * Ping from VM1 to VM4 should work | * Ping from VM1 to VM4 should work | ||
| * Ping from VM1 to VM5 should work | * Ping from VM1 to VM5 should work | ||
| - | Jira task in Yardstick for the Test 1: https://jira.opnfv.org/browse/YARDSTICK-185?jql=project%20%3D%20YARDSTICK | ||
| - | === Test Case 2 === | + | Jira task in Yardstick for the Test 1: https://jira.opnfv.org/browse/YARDSTICK-185 |
| - | Test scope: using VPNs to isolate tenants incl. overlapping IP address ranges | + | === 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: | Test setup procedure: | ||
| - | * set up VM1 and VM2 on N1 and VM3 on N2, all having ports in the same Neutron Network N1. | + | * 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 from 10.10.10/24 (this subnet is denoted SN1 in the follwowing) | + | * VM1 and VM2 have IP addresses in a subnet SN1 with range 10.10.10/24 |
| - | * VM3 has an IP address from 10.10.11/24 (this subnet is denoted SN2 in the following) | + | * VM3 has an IP address in a subnet SN2 with range 10.10.11/24 |
| - | * Set up VM4 on N1 and VM5 on N2, both having ports in Neutron Network N2 | + | * Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2 |
| - | * VM4 has an address from SN1, VM5 has an address from SN2 | + | * VM4 has an address in a subnet SN1b with range 10.10.10/24 |
| + | * VM5 has an address in a subnet SN2b with range 10.10.11/24 | ||
| Test execution: | Test execution: | ||
| Line 136: | Line 145: | ||
| * Create VPN2 with iRT=eRT=RT2 and associate N2 to it | * Create VPN2 with iRT=eRT=RT2 and associate N2 to it | ||
| * ping from VM4 to VM5 should work | * ping from VM4 to VM5 should work | ||
| - | * ping from Vm4 to VM1 and VM3 should not work | + | * ping from VM4 to VM1 and VM3 should not work |
| + | |||
| + | Jira task in Yardstick for the Test2: https://jira.opnfv.org/browse/YARDSTICK-192 | ||
| + | |||
| + | [TM Comments:] | ||
| + | - I reformulated the above to account for the fact that one Neutron Subnet cannot be associated to more than one Network | ||
| + | - let's assume VM3 and VM5 have been allocated the same address 10.10.11.2; in that case: | ||
| + | - "ping from VM1 to VM3 should work" translates to "on VM1 a ping to 10.10.11.2 succeeds" | ||
| + | - "ping from VM1 to VM5 should not work" translates to "on VM1 a ping to 10.10.11.2 fails" | ||
| + | - of course, both cannot be simultaneously true, so the test above is incorrect in that case | ||
| + | - I think that the right way to check for proper support of address overlap is to check that, when VM1 exchanges with 10.10.11.2, VM1 is actually talking with VM3 and not VM5. A way to achieve that is to use a real protocol connection (HTTP, SSH, netcat...) and have something returned to check who is the destination; for instance VM3 would serve a file with "I am VM3" in it, and VM5 a file with "I am VM5" in it ; VM1 would check that it received "I am VM3". Similarly VM4 can check that it talks with VM5. | ||
sdnvpn/main.1448897290.txt.gz · Last modified: 2015/11/30 15:28 by Tim Irnich
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
