diff options
Diffstat (limited to 'docs/requirements/use_cases/l3vpn_hub_and_spoke.rst')
| -rw-r--r-- | docs/requirements/use_cases/l3vpn_hub_and_spoke.rst | 270 |
1 files changed, 0 insertions, 270 deletions
diff --git a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst deleted file mode 100644 index 17459b6..0000000 --- a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst +++ /dev/null @@ -1,270 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Bin Hu - -Hub and Spoke Case ------------------- - -Description -~~~~~~~~~~~ - -In a traditional Hub-and-spoke topology there are two types of network entities: -a central hub and multiple spokes. The corresponding VRFs of the hub and the -spokes are configured to import and export routes such that all traffic is -directed through the hub. As a result, spokes cannot communicate with each other -directly, but only indirectly via the central hub. Hence, the hub typically -hosts central network functions such firewalls. - -Furthermore, there is no layer 2 connectivity between the VNFs. - -In addition, in this use case, the deployed network infrastructure comprises -equipment from two different vendors, Vendor A and Vendor B. There are 2 hosts -(compute nodes). SDN Controller A and vForwarder A are provided by Vendor A, and -run on host A. SDN Controller B and vForwarder B are provided by Vendor B, and run -on host B. - -There is 1 tenant. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and 10.3.7.0/24. - -The network topology is shown in :numref:`l3vpn-hub-spoke-figure`: - -.. figure:: images/l3vpn-hub-spoke.png - :name: l3vpn-hub-spoke-figure - :width: 100% - -In L3VPN Blue, vFW(H) is acting the role of ``hub`` (a virtual firewall). -The other 3 VNF VMs are ``spoke``. vFW(H) and VNF1(S) are spawned on host A, -and VNF2(S) and VNF3(S) are spawned on host B. vFW(H) (10.1.1.5) and VNF2(S) -(10.1.1.6) are attached to subnet 10.1.1.0/24. VNF1(S) (10.3.7.9) and VNF3(S) -(10.3.7.10) are attached to subnet 10.3.7.0/24. - - -Derived Requirements -~~~~~~~~~~~~~~~~~~~~~ - -Northbound API / Workflow -+++++++++++++++++++++++++ - -.. Georg: this needs to be made more readable / explanatory - -Exemplary vFW(H) Hub VRF is as follows: - -* RD1 10.1.1.5 IP_vForwarder1 Label1 -* RD1 0/0 IP_vForwarder1 Label1 -* Label 1 Local IF (10.1.1.5) -* RD3 10.3.7.9 IP_vForwarder1 Label2 -* RD2 10.1.1.6 IP_vForwarder2 Label3 -* RD4 10.3.7.10 IP_vForwarder2 Label3 - -Exemplary VNF1(S) Spoke VRF is as follows: - -* RD1 0/0 IP_vForwarder1 Label1 -* RD3 10.3.7.9 IP_vForwarder1 Label2 - -Exemplary workflow is described as follows: - -1. Create Network - -2. Create VRF Policy Resource - - 2.1. Hub and Spoke - -3. Create Subnet - -4. Create Port - - 4.1. Subnet - - 4.2. VRF Policy Resource, [H | S] - - - -Current implementation -++++++++++++++++++++++ - -Different APIs have been developed to support creating a L3 network topology and -directing network traffic through specific network elements in specific order, -for example, [BGPVPN]_ and [NETWORKING-SFC]_. We analyzed those APIs regarding -the Hub-and-Spoke use case. - - -BGPVPN -'''''' - -Support for creating and managing L3VPNs is in general available in OpenStack -Neutron by means of the BGPVPN API [BGPVPN]_. The [BGPVPN]_ API currently -supports the concepts of network- and router-associations. An association maps -Neutron network objects (networks and routers) to a VRF with the following -semantics: - -* A *network association* interconnects all subnets and ports of a Neutron - network by binding them to a given VRF -* a *router association* interconnects all networks, and hence indirectly all - ports, connected to a Neutron router by binding them to a given VRF - -It is important to notice that these associations apply to entire Neutron -networks including all ports connected to a network. This is due to the fact -that in the Neutron, ports can only exist within a network but not individually. -Furthermore, Neutron networks were originally designed to represent layer 2 -domains. As a result, ports within the same Neutron network typically have layer -connectivity among each other. There are efforts to relax this original design -assumption, e.g. routed networks, which however do not solve the problem at hand -here (see the gap analysis further down below). - -In order to realize the hub-and-spoke topology outlined above, VRFs need to be -created on a per port basis. Specifically, ports belonging to the same network -should not be interconnected except through a corresponding configuration of a -per-port-VRF. This configuration includes setting up next-hop routing table, -labels, I-RT and E-RT etc. in order to enable traffic direction from hub to -spokes. - -It may be argued that given the current network- and router-association mechanisms, -the following workflow establishes a network topology which aims to achieve the desired -traffic flow from Hub to Spokes. The basic idea is to model separate VRFs per VM -by creating a dedicated Neutron network with two subnets for each VRF in the -Hub-and-Spoke topology. - -1. Create Neutron network "hub" - ``neutron net-create --tenant-id Blue hub`` - - -2. Create a separate Neutron network for every "spoke" - ``neutron net-create --tenant-id Blue spoke-i`` - - -3. For every network (hub and spokes), create two subnets - ``neutron subnet-create <hub/spoke-i UUID> --tenant-id Blue 10.1.1.0/24`` - - ``neutron subnet-create <hub/spoke-i UUID> --tenant-id Blue 10.3.7.0/24`` - - -4. Create the Neutron ports in the corresponding networks - ``neutron port-create --tenant-id Blue --name vFW(H) --fixed-ip subnet_id=<hub UUID>,ip_address=10.1.1.5`` - - ``neutron port-create --tenant-id Blue --name VNF1(S) --fixed-ip subnet_id=<spoke-i UUID>,ip_address=10.3.7.9`` - - ``neutron port-create --tenant-id Blue --name VNF2(S) --fixed-ip subnet_id=<spoke-i UUID>,ip_address=10.1.1.6`` - - ``neutron port-create --tenant-id Blue --name VNF3(S) --fixed-ip subnet_id=<spoke-i UUID>,ip_address=10.3.7.10`` - - -5. Create a BGPVPN object (VRF) for the hub network with the corresponding import - and export targets - ``neutron bgpvpn-create --name hub-vrf --import-targets <RT-hub RT-spoke> --export-targets <RT-hub>`` - - -6. Create a BGPVPN object (VRF) for every spoke network with the corresponding import - and export targets - ``neutron bgpvpn-create --name spoke-i-vrf --import-targets <RT-hub> --export-targets <RT-spoke>`` - - -7. Associate the hub network with the hub VRF - ``bgpvpn-net-assoc-create hub --network <hub network-UUID>`` - - -8. Associate each spoke network with the corresponding spoke VRF - ``bgpvpn-net-assoc-create spoke-i --network <spoke-i network-UUID>`` - - -9. Add static route to direct all traffic to vFW VNF running at the hub. - - **Note:** Support for static routes not yet available. - - ``neutron bgpvpn-static-route-add --tenant-id Blue --cidr 0/0 --nexthop-ip 10.1.1.5 hub`` - -After step 9, VMs can be booted with the corresponding ports. - -The resulting network topology intents to resemble the target topology as shown in -:numref:`l3vpn-hub-spoke-figure`, and achieve the desired traffic direction from Hub to Spoke. -However, it deviates significantly from the essence of the Hub-and-Spoke use case as -described above in terms of desired network topology, i.e. one L3VPN with multiple -VRFs associated with vFW(H) and other VNFs(S) separately. And this method of using -the current network- and router-association mechanism is not scalable when there are large -number of Spokes, and in case of scale-in and scale-out of Hub and Spokes. - -The gap analysis in the next section describes the technical reasons for this. - - -Network SFC -''''''''''' - -Support of Service Function Chaining is in general available in OpenStack Neutron through -the Neutron API for Service Insertion and Chaining project [NETWORKING-SFC]_. -However, the [NETWORKING-SFC]_ API is focused on creating service chaining through -NSH at L2, although it intends to be agnostic of backend implementation. It is unclear whether -or not the service chain from vFW(H) to VNFs(S) can be created in the way of L3VPN-based -VRF policy approach using [NETWORKING-SFC]_ API. - -Hence, it is currently not possible to configure the networking use case as described above. - -.. **Georg: we need to look deeper into SFC to substantiate our claim here.** - - -Gaps in the Current Solution -++++++++++++++++++++++++++++ - -Given the use case description and the currently available implementation in -OpenStack provided by [BGPVPN]_ project and [NETWORKING-SFC]_ project, -we identify the following gaps: - - -[L3VPN-HS-GAP1] No means to disable layer 2 semantic of Neutron networks -'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' - -Neutron networks were originally designed to represent layer 2 broadcast -domains. As such, all ports connected to a network are in principle -inter-connected on layer 2 (not considering security rules here). In contrast, -in order to realize L3VPN use cases such as the hub-and-spoke topology, -connectivity among ports must be controllable on a per port basis on layer 3. - -There are ongoing efforts to relax this design assumption, for instance by means -of routed networks ([NEUTRON-ROUTED-NETWORKS]_). In a routed network, a Neutron network -is a layer 3 domain which is composed of multiple layer 2 segments. A routed -network only provides layer 3 connectivity across segments, but layer 2 -connectivity across segments is **optional**. This means, depending on the -particular networking backend and segmentation technique used, there might be -layer 2 connectivity across segments or not. A new flag ``l2_adjacency`` -indicates whether or not a user can expect layer 2 connectivity or not across -segments. - -This flag, however, is ready-only and cannot be used to overwrite or disable the -layer 2 semantics of a Neutron network. - - -[L3VPN-HS-GAP2] No port-association available in the BGPVPN project yet -''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' - -Due to gap [L3VPN-HS-GAP1], the [BGPVPN]_ project was not yet able to implement -the concept of a port association. A port association would allow to associate -individual ports with VRFs and thereby control layer 3 connectivity on a per -port basis. - -The workflow described above intents to mimic port associations by means of -separate Neutron networks. Hence, the resulting workflow is overly complicated -and not intuitive by requiring to create additional Neutron entities (networks) -which are not present in the target topology. Moreover, creating large numbers -of Neutron networks limits scalability. - -Port associations are on the road map of the [BGPVPN]_ project, however, no -design that overcomes the problems outlined above has been specified yet. -Consequently, the time-line for this feature is unknown. - -As a result, creating a clean Hub-and-Spoke topology is current not yet -supported by the [BGPVPN]_ API. - - -[L3VPN-HS-GAP3] No support for static routes in the BGPVPN project yet -'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' - -In order to realize the hub-and-spoke use case, a static route is needed to -attract the traffic at the hub to the corresponding VNF (direct traffic to the -firewall). Support for static routes in the BGPVPN project is available for the -router association by means of the Neutron router extra routes feature. However, -there is no support for static routes for network and port associations yet. - -Design work for supporting static routes for network associations has started, -but no final design has been proposed yet. - -.. -.. [L3VPN-HS-GAP4] Creating a clean hub-and-spoke topology is current not yet supported by the NETWORKING-SFC API. -.. [Georg: We need to look deeper into SFC before we can substantiate our claim] - |