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 10:38] Tim Irnich [Deployment options] some clarifications |
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 ==== | ||
| - | Baseline: | + | ==== Manual deployment procedures as starting point for installer development ==== |
| - | * OpenStack Liberty | + | |
| - | - Install BGPVPN | + | In the following we outline a manual deployment procedure which will serve as input to installer development work (i.e.this procedure is what the installer needs to automate). |
| - | * deb/rpm package | + | |
| - | * pull from repo | + | === Baseline assumptions === |
| + | |||
| + | * The OpenStack version supported by the installer is Liberty | ||
| + | * The ODL version supported by the installer is Beryllium | ||
| + | |||
| + | === Step 1: BGPVPN installation === | ||
| + | |||
| + | BGPVPN extends the Neutron API with VPN support. Installation procedure: | ||
| + | * pip install the Python files | ||
| + | * Install the Neutron extensions, example can be found at [[https://github.com/openstack/networking-bgpvpn/blob/master/devstack/plugin.sh]] | ||
| === Bagpipe backend === | === Bagpipe backend === | ||
| Line 32: | 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 46: | 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 63: | Line 73: | ||
| - Verify FIB entry after delete | - Verify FIB entry after delete | ||
| - | === OpenStack Neutron BGPVPN API extension 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 80: | 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: |
| - | * set up VM1 and VM2 on N1 and VM3 on N2, all having 10.10.10/24 addresses | + | * tbd |
| - | * Set up VM4 on N1 and VM5 on N2, both having 10.10.11/24 addresses | + | |
| - | + | ||
| - | Test 1: | + | |
| - | * Ping from VMx to VMy should not work | + | |
| - | * Create VPN1 (add parameters) and associate 10.10.10./24 subnet | + | |
| - | * Ping from VMx to VMy should work | + | |
| - | + | ||
| - | Jira task in Yardstick for the Test 1: https://jira.opnfv.org/browse/YARDSTICK-185?jql=project%20%3D%20YARDSTICK | + | |
| Common test teardown procedure: | Common test teardown procedure: | ||
| - | * tbd | ||
| * Yardstick framework removes the VMs after the test execution | * Yardstick framework removes the VMs after the test execution | ||
| + | * tbd | ||
| + | |||
| + | === Test Case 1 - VPN provides connectivity between subnets === | ||
| + | |||
| + | 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 and all having 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 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) and associate SN1 to it | ||
| + | * 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 VPN 1 so that iRT=eRT | ||
| + | * Ping from VM1 to VM4 should work | ||
| + | * Ping from VM1 to VM5 should work | ||
| + | |||
| + | Jira task in Yardstick for the Test 1: https://jira.opnfv.org/browse/YARDSTICK-185 | ||
| + | |||
| + | === 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 | ||
| + | * VM3 has an IP address in a subnet SN2 with range 10.10.11/24 | ||
| + | * 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 | ||
| + | * VM5 has an address in a subnet SN2b with range 10.10.11/24 | ||
| + | |||
| + | Test execution: | ||
| + | * Create VPN 1 with iRT=eRT=RT1 and associate N1 to it | ||
| + | * ping from VM1 to VM2 and VM3 should work | ||
| + | * ping from VM1 to VM4 and VM5 should not work | ||
| + | * Create VPN2 with iRT=eRT=RT2 and associate N2 to it | ||
| + | * ping from VM4 to VM5 should 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.1448879889.txt.gz · Last modified: 2015/11/30 10:38 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
