Tungsten Fabric implements cloud tenants’ virtual networks as Layer 3 overlays. Tenant traffic gets encapsulated into one of the supported protocols and is carried over the infrastructure network between 2 compute nodes or a compute node and an edge router device.
In addition, Tungsten Fabric is capable of exchanging encapsulated traffic with external systems in order to build advanced virtual networking topologies, for example, BGP VPN connectivity between 2 MOSK clouds or a MOSK cloud and a cloud tenant premises.
MOSK supports the following encapsulation protocols:
- MPLS over Generic Routing Encapsulation (GRE)
A traditional encapsulation method supported by several router vendors, including Cisco and Juniper. The feature is applicable when other encapsulation methods are not available. For example, an SDN gateway runs software that does not support MPLS over UDP.
- MPLS over User Datagram Protocol (UDP)
A variation of the MPLS over GRE mechanism. It is the default and the most frequently used option in MOSK. MPLS over UDP replaces headers in UDP packets. In this case, a UDP port stores a hash of the packet payload (entropy). It provides a significant benefit for equal-cost multi-path (ECMP) routing load balancing. MPLS over UDP and MPLS over GRE transfer Layer 3 traffic only.
- Virtual Extensible LAN (VXLAN)
Available since MOSK 22.1 TechPreview
The combination of VXLAN and EVPN technologies is often used for creating advanced cloud networking topologies. For example, it can provide transparent Layer 2 interconnections between Virtual Network Functions running on top of the cloud and physical traffic generator appliances hosted somewhere else.
ENCAP_PRIORIY parameter defines the priority in which the
encapsulation protocols are attempted to be used when setting the BGP VPN
connectivity between the cloud and external systems.
By default, the encapsulation order is set to
The cloud operator can change it depending their needs in the
custom resource as it is illustrated in Configuring encapsulation.
The list of supported encapsulated methods along with their order is shared between BGP peers as part of the capabilities information exchange when establishing a BGP session. Both parties must support the same encapsulation methods to build a tunnel for the network traffic.
For example, if the cloud operator wants to set up a Layer 2 VPN between the cloud and their network infrastructure, they configure the cloud’s virtual networks with VXLAN identifiers (VNIs) and do the same on the other side, for example, on a network switch. Also, VXLAN must be set in the first position in encapsulation priority order. Otherwise, VXLAN tunnels will not get established between endpoints, even though both endpoints may support the VXLAN protocol.
However, setting VXLAN first in the encapsulation priority order will not enforce VXLAN encapsulation between compute nodes or between compute nodes and gateway routers that use Layer 3 VPNs for communication.
TFOperator custom resource allows you to define encapsulation settings
for your Tungsten Fabric cluster.
TFOperator CR must be the only place to configure
the cluster encapsulation. Performing these configurations through
the TF web UI, CLI, or API does not provide the configuration persistency,
and the settings defined this way may get reset to defaults during the
cluster services restart or update.
Defining the default values for encapsulation parameters in the TF operator CR is unnecessary.
Defines the encapsulation priority order.
Defines the Virtual Network ID type. The list of possible values includes:
Typically, for a Layer 2 VPN use case, the
controllers: tf-config: provisioner: containers: - env: - name: VXLAN_VN_ID_MODE value: automatic - name: ENCAP_PRIORITY value: VXLAN,MPLSoUDP,MPLSoGRE name: provisioner