The project aims to integrate the OpenStack Neutron BGPVPN project and its supported backends into the OPNFV reference platform.

The different BGPVPN backends should be supported through deployment options that can be selected when running the installers:

1. Bagpipe backend
2. OpenContrail backend (unclear if supported in Brahmaputra - contributors needed)
3. ODL backend (tests will only pass with ODL Beryllium)

ONOS is currently not supported by the OpenStack Neutron BGPVPN extension (networking-bgpvpn repository).

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.

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).

• The OpenStack version supported by the installer is Liberty
• The ODL version supported by the installer is Beryllium

BGPVPN extends the Neutron API with VPN support.

1. Install BGPVPN
   • deb/rpm package
   • pull from repo

1. step 1
2. step 2

1. ODL: activate VPN Service feature in karaf
2. step 2

The aim is to run the same suite of tests for all supported backends, i.e. within the CI pipeline a separate Jenkins job is needed for each deployment option (deploy the option, run the common tests).

Within Functest the basic functionality of the ODL VPN Service is verified using the ODL REST API directly. We re-use the robot framework test suite that has been developed for this purpose in ODL. The OpenStack Neutron BGPVPN API is verified using a second suite of robot framework tests that is located in the OPNFV SDN VPN repository (may be moved to OpenStack networking-bgpvpn repo later).

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.

1. Create VPN instance and check command return code
2. Check if VPN instance is present
3. Create IETF VM interface and check return code
4. Verify IETF VM interface
5. Create VPN interface for IETF interface
6. Verify VPN interface
7. Verify FIB entry after create
8. Delete VM VPN interface
9. Verify after deleting VM VPN interface
10. Delete VPN instance
11. Verify after deleting VPN instance
12. Delete VM IETF interface
13. Verify after deleting VM IETF interface
14. Verify FIB entry after delete

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.

1. Create BGPVPN and check if the main parameters of the created object are correct.
2. Create BGPVPN with malformatted route target (e.g. ASN:NN) should fail.
3. Create BGPVPN with invalid route target (e.g. 65536:0) should fail.
4. Getting the VPN list works without producing an error.
5. Updating an existing BGPVPN works.
6. Displaying parameters of an existing BGPVPN works.
7. Deleting a BGPVPN works.
8. Associating an existing BGPVPN with a Neutron network works
9. Getting the associated Neutron network works.
10. Deleting the network association works.

2 compute nodes N1 and N2 are used during the tests.

Common test setup procedure:

• tbd

Common test teardown procedure:

• Yardstick framework removes the VMs after the test execution
• tbd

test scope: VPNs provide connectivity across subnets if configured accordingly.

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 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)

Test execution:

• Create VPN1 with eRT<>iRT (so that connected subnets should not rech 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?jql=project%20%3D%20YARDSTICK

Test scope: using VPNs to isolate tenants incl. overlapping IP address ranges

Test setup procedure:

• set up VM1 and VM2 on N1 and VM3 on N2, 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)
• VM3 has an IP address from 10.10.11/24 (this subnet is denoted SN2 in the following)
• Set up VM4 on N1 and VM5 on N2, both having ports in Neutron Network N2
• VM4 has an address from SN1, VM5 has an address from SN2

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