docs/development/overview/index.rst

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