2.1.3. Hub and Spoke Case

2.1.3.1. Description

There are 2 hosts (compute nodes). SDN Controller A and vRouter A are provided by Vendor A, and run on host A. SDN Controller B and vRouter 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 Fig. 2.3:

../_images/l3vpn-hub-spoke.png

In L3VPN Blue, vFW(H) is acting the role of hub (a virtual firewall). The other 3 VNFsVMs 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.

2.1.3.2. Derrived Requirements

2.1.3.2.1. Northbound API / Workflow

Exemplary vFW(H) Hub VRF is as follows:

  • RD1 10.1.1.5 IP_OVR1 Label1
  • RD1 0/0 IP_OVR1 Label1
  • Label 1 Local IF (10.1.1.5)
  • RD3 10.3.7.9 IP_OVR1 Label2
  • RD2 10.1.1.6 IP_OVR2 Label3
  • RD4 10.3.7.10 IP_OVR2 Label3

Exemplary VNF1(S) Spoke VRF is as follows:

  • RD1 0/0 IP_OVR1 Label1
  • RD3 10.3.7.9 IP_OVR1 Label2

Exemplary workflow is described as follows:

  1. Create Network
  2. Create VRF Policy Resource
2.1. Hub and Spoke
  1. Create Subnet
  2. Create Port

4.1. Subnet

4.2. VRF Policy Resource, [H | S]

2.1.3.2.2. Data model objects

  • TBD

2.1.3.2.3. Orchestration

  • TBD

2.1.3.2.4. Dependencies on compute services

  • TBD

2.1.3.2.5. Current implementation

Different APIs have been developed to support creating a 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.

2.1.3.2.5.1. BGPVPN

Support for creating and managing L3VPNs is in general available in OpenStack Neutron by means of the BGPVPN API [BGPVPN]. However, the [BGPVPN] API does not support creating the Hub-and-Spoke topology as outlined above, i.e. setting up specific VRFs of vFW(H) and other VNFs(S) within one L3VPN to direct the traffic from vFW(H) to VNFs(S).

The [BGPVPN] API currently supports the concepts of network- and router-associations. An association in principle maps to a VRF that interconnects either subnets of a Neutron network (network association) or the networks connected by a router (router association). It does not yet allow for creating VRFs per VM port (port associations) as illustrated in Hub-and-Spoke use case. The functionality of port association is needed, however, to create separate VRFs per VM in order to implement the Hub-and-Spoke use case. Furthermore, the functionality of setting up next-hop routing table, labels, I-RT and E-RT etc in VRF is also required 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 hub
  1. Create a separate Neutron network for every “spoke”
neutron net-create spoke-i
  1. For every network (hub and spokes), create two subnets
neutron subnet-create <hub/spoke-i network UUID> 10.1.1.0/24 neutron subnet-create <hub/spoke-i network UUID> 10.3.7.0/24
  1. 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>
  1. 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>
  1. Associate the hub network with the hub VRF
bgpvpn-net-assoc-create hub --network <hub network-UUID>
  1. Associate each spoke network with the corresponding spoke VRF
bgpvpn-net-assoc-create spoke-i --network <spoke-i network-UUID>

After step 7, VMs can be booted on the corresponding networks.

The resulting network topology tries to resemble our target topology as shown in Fig. 2.3, 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.

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

2.1.3.2.6. Gaps in 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] The [BGPVPN] project lacks port-associations

    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. This method is also not scalable.

    Within the [BGPVPN] project, design work on port-association has started. The timeline for this feature is however not defined yet. As a result, creating a clean Hub-and-Spoke topology is current not yet supported by the [BGPVPN] API.

  • [L3VPN-HS-GAP2] Creating a clean hub-and-spoke topology is current not yet supported by the [NETWORKING-SFC] API.