VLAN trunking support for IPVLAN, MACVLAN and SRIOV

VLAN tagging by the applications running in pods is supported. The worker node’s networking stack or the CNI is not involved in setting up the VLAN or adding the VLAN information to the application traffic. This makes it suitable for containerized NFVs that support VLAN tagging.

FSC supports this design, and it is used to set up the respective sub-interfaces across network segments on the TORs.

Note: If this is not setup correctly or ahead of time, the data traffic from containers can be dropped without warning.

Design

When POD-based VLAN tagging is not used, Network Attachment Definition (NAD) CRDs have a “master interface” field in the Spec where an untagged host interface or a VLAN-tagged host sub-interface needs to be specified. This design implicitly maps a NAD to a VLAN-tagged interface on the worker node. The same VLAN-tagged interface can be re-used in another NAD. However, when a NAD is specified, the user knows that it belongs to a VLAN-tagged interface or untagged interface.

When POD-based VLAN Tagging is used, the master interface in the NAD CRD does not include a VLAN tag and is not automatically assumed to be untagged either. In this case the fabric needs to be configured with multiple overlay services, each with their own VLAN. The user configuring VLAN Trunking must know what VLANs will be used by each POD to be able to configure the WorkloadConnectivityIntent of the FSC environment correctly.

WCI NAD:VLAN specifier

When using POD-based VLAN tagging, the WorkloadConnectivityIntent needs to contain information to reflect that a NAD will be used for VLAN Trunking. To do so, in the WorkloadConnectivityIntent, instead of using the NAD Name as the value in the subnet CNIs, it is now possible to use "NAD:VLAN". This is further referenced as a "qualified NAD", where a regular (non-VLAN Trunk NAD) is referred to as a "non-qualified NAD".

A NAD:VLAN pair is part of only one subnet and one tenant. The VLAN indicates the sub-interface that needs to be created under that network-instance (subnet) and workload-evpn (tenant).

The same NAD can be specified across different subnets and different tenants. However, it must be tagged by a unique VLAN specifier.

The VLAN specifiers can be:

  • Any number between 1 to 4094 for type VLAN-Value type
  • 0 for VLAN-untagged type

When a NAD is qualified with a VLAN, it cannot be used as a non-qualified NAD in WCI. However, both approaches can coexist in the WCI with different NAD names.

Webhook checks are added to notify the user of errors or unsupported cases.

Note: Unsupported NAD:VLAN pairs:
  • X-Y for VLAN-range type.
  • * for VLAN-any type.

The following is a sample Workload Connectivity Intent in which a single NAD is present in multiple WorkloadConnectivityIntents with different VLANs.

apiVersion: fsc.fss.nokia.com/v1
kind: WorkloadConnectivityIntent
metadata:
  name: tenant1
  namespace: fsc-system
spec:
  type: "IRB"
  namespace: default
  subnets:
    - name: "subnet1"
      type: "bridged"
      cni:
        - "nad1:0"
        - "nad1:200"
---
apiVersion: fsc.fss.nokia.com/v1
kind: WorkloadConnectivityIntent
metadata:
  name: tenant2
  namespace: fsc-system
spec:
  type: "IRB"
  namespace: default
  subnets:
    - name: "subnet2"
      type: "bridged"
      cni:
        - "nad1:300"

NAD injection

For non-qualified NADs, when a NAD is added or removed from the WCI, the FSC-CNI is injected to the NAD. With qualified NADs with the same NAD name, when the first NAD:VLAN is added to the WCI, the FSC-CNI is injected to the NAD. Subsequent NAD:VLAN references do not inject the FSC-CNI again, as it is already present.

Support for dynamic allocation of VLANS

Adding VLANs to a qualified NAD that has pods deployed is supported. This is achieved by adding the new VLANs with the qualified NADs to the existing WCI's subnets, or creating a new WCI with the subnet with the NAD:VLAN pair. The VLANs are programmed without having to redeploy the pods. When deleting NAD:VLAN pairs from a WCI, the changes are not pushed to the fabric until pods are deleted/redeployed.

Webhook restrictions

The following additional checks have been implemented in the webhook for this feature:

  1. If a NAD:VLAN is referenced, no "NAD" (without VLAN) can be used anywhere else and vice versa.
  2. For NAD:VLAN, checks for malformed NAD as well as the VLAN range (should be between 0 and 4094).
  3. For NAD:VLAN where VLAN is configured as '*".
  4. Dynamic deletion of NAD:VLAN when the deployment/pod for the NAD is existing and the VLANs are deployed.
  5. For NAD:X-Y where a range of VLANs “X-Y” is specified.