docs/development/overview/index.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. SPDX-License-Identifier: CC-BY-4.0
   3 .. (c) OPNFV, Ericsson AB and others.
   4
   5 =======
   6 SDN VPN
   7 =======
   8
   9 The BGPVPN feature enables creation of BGP VPNs on the Neutron API according to the OpenStack
  10 BGPVPN blueprint at `Neutron Extension for BGP Based VPN <https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-vpn>`_.
  11
  12 In a nutshell, the blueprint defines a BGPVPN object and a number of ways
  13 how to associate it with the existing Neutron object model, as well as a unique
  14 definition of the related semantics. The BGPVPN framework supports a backend
  15 driver model with currently available drivers for Bagpipe, OpenContrail, Nuage
  16 and OpenDaylight. The OPNFV scenario makes use of the OpenDaylight driver and backend
  17 implementation through the ODL NetVirt project.
  18
  19 ====================
  20 SDNVPN Testing Suite
  21 ====================
  22
  23 An overview of the SDNVPN Test is depicted here. A more detailed description of each test case can
  24 be found at `SDNVPN Testing <https://wiki.opnfv.org/display/sdnvpn/SDNVPN+Testing>`_.
  25
  26 BGPVPN Tempest test cases
  27 """""""""""""""""""""""""
  28
  29 #. Create BGPVPN passes
  30 #. Create BGPVPN as non-admin fails
  31 #. Delete BGPVPN as non-admin fails
  32 #. Show BGPVPN as non-owner fails
  33 #. List BGPVPNs as non-owner fails
  34 #. Show network associated BGPVPNs as non-owner fails
  35 #. List network associated BGPVPNs as non-owner fails
  36 #. Associate/Deassociate a network to a BGPVPN resource passes
  37 #. Update route targets on a BGPVPN passes
  38 #. Update route targets on a BGPVPN as non-admin fails
  39 #. Reject the creation of BGPVPN with invalid route targets passes
  40 #. Reject the update of BGPVPN with invalid route targets passes
  41 #. Reject the association on an invalid network to a BGPVPN passes
  42 #. Reject the diassociation on an invalid network to a BGPVPN passes
  43 #. Associate/Deassociate a router to a BGPVPN resource passes
  44 #. Attach the subnet of an associated network to an associated router of the same BGVPN passes
  45
  46
  47
  48 Functest scenario specific tests
  49 """"""""""""""""""""""""""""""""""
  50 - **Test Case 1**: VPN provides connectivity between subnets, using network association
  51
  52   Name: VPN connecting Neutron networks and subnets
  53   Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
  54   Test setup procedure:Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1
  55
  56   Moreover all ports have 10.10.10/24 addresses (this subnet is denoted SN1 in the following)
  57   Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
  58   Moreover all ports have 10.10.11/24 addresses (this subnet is denoted SN2 in the following)
  59
  60   Test execution:
  61    * Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
  62    * Associate SN1 to VPN1
  63    * Ping from VM1 to VM2 should work
  64    * Ping from VM1 to VM3 should work
  65    * Ping from VM1 to VM4 should not work
  66    * Associate SN2 to VPN1
  67    * Ping from VM4 to VM5 should work
  68    * Ping from VM1 to VM4 should not work (disabled until isolation fixed upstream)
  69    * Ping from VM1 to VM5 should not work (disabled until isolation fixed upstream)
  70    * Change VPN 1 so that iRT=eRT
  71    * Ping from VM1 to VM4 should work
  72    * Ping from VM1 to VM5 should work
  73
  74 - **Test Case 2**: Tenant separation
  75
  76   Name: Using VPNs for tenant separation
  77   Description: Using VPNs to isolate tenants so that overlapping IP address ranges can be used
  78
  79   Test setup procedure:
  80    * Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1.
  81    * VM1 and VM2 have IP addresses in a subnet SN1 with range 10.10.10/24
  82    * 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)
  83    * VM2: 10.10.10.12, running an HTTP server which returns "I am VM2" for any HTTP request
  84    * VM3 has an IP address in a subnet SN2 with range 10.10.11/24
  85    * VM3: 10.10.11.13, running an HTTP server which returns "I am VM3" for any HTTP request
  86    * Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
  87    * VM4 has an address in a subnet SN1b with range 10.10.10/24
  88    * VM4: 10.10.10.12 (the same as VM2), running an HTTP server which returns "I am VM4" for any HTTP request
  89    * VM5 has an address in a subnet SN2b with range 10.10.11/24
  90    * VM5: 10.10.11.13 (the same as VM3), running an HTTP server which returns "I am VM5" for any HTTP request
  91
  92   Test execution:
  93     * Create VPN 1 with iRT=eRT=RT1 and associate N1 to it
  94     * HTTP from VM1 to VM2 and VM3 should work
  95       It returns "I am VM2" and "I am VM3" respectively
  96     * HTTP from VM1 to VM4 and VM5 should not work
  97       It never returns "I am VM4" or "I am VM5"
  98     * Create VPN2 with iRT=eRT=RT2 and associate N2 to it
  99     * HTTP from VM4 to VM5 should work
 100       It returns "I am VM5"
 101     * HTTP from VM4 to VM1 and VM3 should not work
 102       It never returns "I am VM1" or "I am VM3"
 103
 104
 105 - **Test Case 3**: Data Center Gateway integration
 106
 107   Name: Data Center Gateway integration
 108   Description: Investigate the peering functionality of BGP protocol, using a Zrpcd/Quagga router
 109   and OpenDaylight Controller
 110
 111   Test setup procedure:
 112    * Search in the pool of nodes and find one Compute node and one Controller nodes, that have OpenDaylight controller running
 113    * Start an instance using ubuntu-16.04-server-cloudimg-amd64-disk1.img image and in it run the Quagga setup script
 114    * Start bgp router in the Controller node, using odl:configure-bgp
 115
 116   Test execution:
 117    * Set up a Quagga instance in a nova compute node
 118    * Start a BGP router with OpenDaylight in a controller node
 119    * Add the Quagga running in the instance as a neighbor
 120    * Check that bgpd is running
 121    * Verify that the OpenDaylight and gateway Quagga peer each other
 122    * Start an instance in a second  nova compute node and connect it with a new network, (Network 3-3).
 123    * Create a bgpvpn (include parameters route-distinguisher and route-targets) and associate it with the network created
 124    * Define the same route-distinguisher and route-targets on the simulated quagga side
 125    * Check that the routes from the Network 3-3 are advertised towards simulated Quagga VM
 126
 127 - **Test Case 4**: VPN provides connectivity between subnets using router association
 128
 129   Functest: variant of Test Case 1.
 130    * Set up a Router R1 with one connected network/subnet N1/S1.
 131    * Set up a second network N2.
 132    * Create VPN1 and associate Router R1 and Network N2 to it.
 133    * Hosts from N2 should be able to reach hosts in N1.
 134
 135    Name: VPN connecting Neutron networks and subnets using router association
 136    Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
 137
 138    Test setup procedure:
 139     * Set up VM1 and VM2 on Node1 and VM3 on Node2,
 140     * All VMs have ports in the same Neutron Network N1 and 10.10.10/24 addresses
 141     * (this subnet is denoted SN1 in the following).
 142     * N1/SN1 are connected to router R1.
 143     * Set up VM4 on Node1 and VM5 on Node2,
 144     * Both VMs have ports in Neutron Network N2 and having 10.10.11/24 addresses
 145     * (this subnet is denoted SN2 in the following)
 146
 147    Test execution:
 148     * Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
 149     * Associate R1 to VPN1
 150       Ping from VM1 to VM2 should work
 151       Ping from VM1 to VM3 should work
 152       Ping from VM1 to VM4 should not work
 153     * Associate SN2 to VPN1
 154       Ping from VM4 to VM5 should work
 155       Ping from VM1 to VM4 should not work
 156       Ping from VM1 to VM5 should not work
 157     * Change VPN1 so that iRT=eRT
 158       Ping from VM1 to VM4 should work
 159       Ping from VM1 to VM5 should work
 160
 161 - **Test Case 7** - Network associate a subnet with a router attached to a VPN and verify floating IP
 162   functionality (disabled, because of ODL Bug 6962)
 163
 164   A test for https://bugs.opendaylight.org/show_bug.cgi?id=6962
 165
 166   Setup procedure:
 167    * Create VM1 in a subnet with a router attached.
 168    * Create VM2 in a different subnet with another router attached.
 169    * Network associate them to a VPN with iRT=eRT
 170    * Ping from VM1 to VM2 should work
 171    * Assign a floating IP to VM1
 172    * Pinging the floating IP should work
 173
 174 - **Test Case 8** - Router associate a subnet with a router attached to a VPN and
 175   verify floating IP functionality
 176
 177   Setup procedure:
 178    * Create VM1 in a subnet with a router which is connected with the gateway
 179    * Create VM2 in a different subnet without a router attached.
 180    * Assoc the two networks in a VPN iRT=eRT
 181    * One with router assoc, other with net assoc
 182    * Try to ping from one VM to the other
 183    * Assign a floating IP to the VM in the router assoc network
 184    * Ping it
 185
 186 - **Test Case 9** - Check fail mode in OVS br-int interfaces
 187
 188   This testcase checks if the fail mode is always 'secure'.
 189   To accomplish it, a check is performed on all OVS br-int interfaces, for all OpenStack nodes.
 190   The testcase is considered as successful if all OVS br-int interfaces have fail_mode=secure
 191
 192 - **Test Case 10** - Check the communication between a group of VMs
 193
 194   This testcase investigates if communication between a group of VMs is interrupted upon deletion
 195   and creation of VMs inside this group.
 196
 197   Test case flow:
 198    * Create 3  VMs:  VM_1  on compute 1, VM_2 on compute 1, VM_3 on compute 2.
 199    * All VMs ping each other.
 200    * VM_2  is deleted.
 201    * Traffic is still flying between VM_1 and VM_3.
 202    * A new VM, VM_4  is added to compute 1.
 203    * Traffic is not interrupted and VM_4 can be reached as well.
 204
 205
 206 - **Testcase 11**: test Opendaylight resync and group_add_mod feature mechanisms
 207
 208   This is testcase to test Opendaylight resync and group_add_mod feature functionalities
 209
 210   Sub-testcase 11-1:
 211    * Create and start 2 VMs, connected to a common Network.
 212      New groups should appear in OVS dump
 213    * OVS disconnects and the VMs and the networks are cleaned.
 214      The new groups are still in the OVS dump,
 215      cause OVS  is not connected anymore, so it is not notified that the groups are deleted
 216    * OVS re-connects.
 217      The new groups should be deleted, as Opendaylight has to resync the groups totally and
 218      should remove the groups since VMS are deleted.
 219
 220   Sub-testcase 11-2:
 221    * Create and start 2 VMs, connected to a common Network.
 222      New groups should appear in OVS dump
 223    * OVS disconnects.
 224      The new groups are still in the OVS dump, cause OVS is not connected anymore,
 225      so it is not notified that the groups are deleted
 226    * OVS re-connects.
 227      The new groups should be still there, as the topology remains. Opendaylight Carbon's
 228      group_add_mod mechanism should handle the already existing group.
 229    * OVS re-connects.
 230      The new groups should be still there, as the topology remains.
 231      Opendaylight Carbon’ group_add_mod mechanism should handle the already existing group.
 232
 233 - **Testcase 12**: Test Resync mechanism between Opendaylight and OVS
 234   This is the testcase to validate flows and groups are programmed correctly
 235   after resync which is triggered by OVS del-controller/set-controller commands
 236   and adding/remove iptables drop rule on OF port 6653.
 237
 238   Sub-testcase 12-1:
 239    * Create and start 2 VMs, connected to a common Network
 240      New flows and groups were added to OVS
 241    * Reconnect the OVS by running del-ontroller and set-controller commands
 242      The flows and groups are still intact and none of the flows/groups
 243      are removed
 244    * Reconnect the OVS by adding ip tables drop rule and then remove it
 245      The flows and groups are still intact and none of the flows/groups
 246      are removed
 247
 248 - **Testcase 13**: Test ECMP (Equal-cost multi-path routing) for the extra route
 249
 250   This testcase validates spraying behavior in OvS when an extra route is
 251   configured such that it can be reached from two nova VMs in the
 252   same network.
 253
 254   Setup procedure:
 255    * Create and start VM1 and VM2 configured with sub interface set to same ip address in both VMs,
 256      connected to a common network/router.
 257    * Update the VM1 and VM2's Neutron ports with allowed address pairs for sub interface ip/mac
 258      addresses.
 259    * Create BGPVPN with two route distinguishers.
 260    * Associate router with BGPVPN.
 261    * Update the router with above sub-interface ip address with nexthops set to VMs ip addresses.
 262    * Create VM3 and connected to the same network.
 263    * Ping sub-interface IP address from VM3.