F5SPKVlan

Note

Deprecated as of 2.4.0. Use an Infra resource instead.

Overview

Function

Declares a VLAN object in the TMM configuration for a CNE instance, including the associated interfaces, self IP addresses, and traffic settings.

Names

Singular name	Plural name	Short name
f5-spk-vlan	f5-spk-vlans	—

API group and version

k8s.f5net.com/v1

Scope

Namespace

Specification

spec

Field	Required	Default	Description
interfaces array	Yes	—	One or more interfaces to associate with the VLAN object. Each interface is a string of 0 to 32 characters. Must contain at least one item.
name string	No	""	Name of the VLAN object in the TMM configuration. Maximum length is 255 characters.
tag integer	No	0	Tagging ID applied to the VLAN object. Accepted values: 0 to 4094. When this value is set to 0, the frames for this VLAN are emitted without an 802.1Q tag on the attached interfaces. Otherwise, the frames for this VLAN will be emitted with an 802.1Q tag.
selfip_v4s array	No	[]	List of IPv4 Self IP addresses associated with the VLAN. Each TMM replica receives an IP address in element order.
prefixlen_v4 integer	No	24	Subnet mask to use with the IPv4 Self IP addresses. Accepted values: 0 to 32.
selfip_v6s array	No	[]	List of IPv6 Self IP addresses associated with the VLAN. Each TMM replica receives an IP address in element order.
prefixlen_v6 integer	No	120	Subnet mask to use with the IPv6 Self IP addresses. Accepted values: 0 to 128.
allowed_services array	No	[]	List of protocols and protocol service ports this VLAN accepts.
mtu integer	No	1500	Maximum transmission unit, in bytes, that can be transmitted over a network connection. Accepted values: 576 to 9198.
trunk_hash string	No	src-dst-ipport	Hashing algorithm used to distribute packets across bonded interfaces. Accepted values: src-dst-mac, dst-mac, index, src-dst-ipport, static. When set to static, interfaces must contain exactly two items.
bonded boolean	No	false	Combines multiple interfaces into a single bonded interface. Accepted values: true, false.
internal boolean	No	false	Turns routing annotations for internal pods on or off. Set this on the internal VLAN. You can turn it on for only one VLAN. Accepted values: true, false.
category string	No	external	Unique, user-defined category for the VLAN configuration. Must be 1 to 255 characters.
cmp_hash string	No	DEFAULT	Hashing algorithm to use for the VLAN. Accepted values: DEFAULT, SRC_ADDR, DST_ADDR, SRC_DST_ADDR_PORT.
pod_hash string	No	DISABLED	Pod hashing algorithm to use for DAG. Accepted values: DISABLED, SRC_ADDR, DST_ADDR.
auto_lasthop string	No	AUTO_LASTHOP_DEFAULT	Auto last hop feature that sends return traffic to the MAC address that transmitted the request. Accepted values: AUTO_LASTHOP_DEFAULT, AUTO_LASTHOP_ENABLED, AUTO_LASTHOP_DISABLED.
vrf string	No	""	Name of the VRF (tenant) this VLAN belongs to. When you don’t set this, the VLAN is created in the default route domain. This field is immutable after creation. Maximum length is 255 characters.
active_interface string	No	""	Preferred active interface for ACTIVE_STANDBY LAG mode. Must be one of the interfaces listed in interfaces. When you don’t set this, the first interface in the list is the initial active interface. Maximum length is 32 characters.

spec.allowed_services[]

Field	Required	Default	Description
protocol string	No	—	Type of protocol traffic accepted by the VLAN. Accepted values: tcp, udp, or a protocol number from 0 to 255. Maximum length is 32 characters.
port string	No	""	Service port traffic accepted by the VLAN. Maximum length is 5 characters.

Scaling TMM

When scaling the TMM Pod beyond a single instance in the Project, the spec.selfip_v4s and spec.selfip_v6s parameters must be configured to provide unique self IP addresses to each TMM replica. The first self IP address in the list is applied to the first TMM Pod, the second IP address to the second TMM Pod, continuing through the list.

Annotate Internal facing interfaces

An annotation must be added to the Host node in order to establish static routes that will direct traffic to the TMM pod on the DPU. The IP’s CIDR range must match the “internal” network’s CIDR range.

kubectl get nodes -o yaml | grep node-primary-ifaddr

k8s.ovn.org/node-primary-ifaddr: '{"ipv4":"10.144.175.15/24","ipv6":"2620:128:e008:4018::15/128"}'

Note

If node node-primary-ifaddr annotation is not added already, use below command to annotate the node:

kubectl annotate node <host node name> k8s.ovn.org/node-primary-ifaddr='{"ipv4":"<IPv4 Address/subnet>","ipv6":"<IPv6 Address/subnet>"}'

Install an External and Internal F5SPKVLAN CR

Use the following steps to install an external and internal F5SPKVLAN CR, and verify the BIG-IP Next for Kubernetes TMM configuration.

1. Copy the example CRs into a YAML file:

   Example external VLAN CR:

   apiVersion: "k8s.f5net.com/v1"
   kind: F5SPKVlAN
   metadata:
     namespace: f5-bnk
     name: "vlan-external"
   spec:
     name: vlan-external
     tag: 3805
     bonded: true
     interfaces:
       - "1.1"
     selfip_v4s: 
       - "192.168.10.100"
       - "192.168.10.101"
       - "192.168.10.102"
     prefixlen_v4: 24
     selfip_v6s:
       - "aaaa::100"
       - "aaaa::101"
       - "aaaa::102"
     prefixlen_v6: 64
     mtu: 9000
     trunk_hash: src-dst-ipport
     auto_lasthop: "AUTO_LASTHOP_ENABLED"
   

   Example internal VLAN CR:

   apiVersion: "k8s.f5net.com/v1"
   kind: F5SPKVLAN
   metadata:
     namespace: f5-bnk
     name: "vlan-internal"
   spec:
     name: vlan-internal
     tag: 3805
     internal: true
     interfaces:
       - "1.2"
     selfip_v4s: 
       - "10.144.175.100"
       - "10.144.175.101"
       - "10.144.175.102"
     prefixlen_v4: 24
     selfip_v6s:
       - "aaaa::100"
       - "aaaa::101"
       - "aaaa::102"
     prefixlen_v6: 64
     mtu: 9000
     trunk_hash: src-dst-ipport
     auto_lasthop: "AUTO_LASTHOP_DISABLED"
   

2. Install the F5SPKVLAN CRs:

   kubectl apply -f spk-int-vlan.yaml
   

   kubectl apply -f spk-ext-vlan.yaml
   

3. Verify the status of the installed CR:

   kubectl get f5-spk-vlans -n f5-bnk
   

   In this example, the CR has installed successfully.

   NAME            READY   MESSAGE                                          AGE
   vlan-external   True    CR config sent to all grpc endpoints             2m20s
   vlan-internal   True    CR config sent to all grpc endpoints             2m20s
   

4. To verify the self IP address configuration, log in to the BIG-IP Next for Kubernetes TMM container:

   In this example, TMM is installed in the f5-bnk Project:

   kubectl exec -it deploy/f5-tmm -n f5-bnk -- bash
   

5. List the interfaces and grep for the spec.name value:

   In this example, the VLAN spec.name is internal and the self IP address is 192.168.10.100:

   ip addr | grep -E 'internal|external'
   

   7:  vlan-external: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 
       inet 192.168.10.100/24 brd 10.20.0.0 scope global external
   8:  vlan-internal: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
       inet 10.144.175.100/24 brd 10.144.175.0 scope global internal
   

   Note

   With multiple VLAN CRs, selfIP from first index in all CRs will be assigned to same TMM. This TMM will have device name as DP-0. SelfIPs from second index in all CRs will be assigned to same TMM, and has the device name as DP-1 and so on.

6. TMM device assignments

   • Expected behaviour:

     • Device names are assigned to TMM pods based on smallest count between maxActiveReplicas and Least available selfIPs among all VLAN CRs.

     • TMM specific configurations other than VLAN such as snatpool, egress, and others can be configured on TMM pods only after VLAN configurations are applied.

     • If more than one TMM pods have device name assigned, all those TMM pods will have same number of VLAN interfaces (with unique selfIP) created even if selfIP count is different among the VLAN CRs.

     • TMM pods that are not assigned with a device name will remain in standby mode until any of the assigned TMM pod goes down or selfIP count is increased. TMMs on standby will continue receiving non-TMM specific configurations.

   • Active and Standby TMMs:

     • Active replicas are the TMM Pods that the controller sets up to handle traffic, but only if the CRs are set up to allow it.

     • When TMMs are scaled beyond the maxActiveReplicas, they will not be configured with self and snat IPs, even if such IPs are available for use. These additional TMMs are designated as Standbys TMMs, which means they are kept in a state of readiness to be quickly configured to take over the responsibilities of any Active TMM that may fail. This feature is particularly beneficial for the user who wish to minimize the duration of traffic interruption that can occur when a TMM Pod goes down. However, it is essential that users can allocate the necessary resources to support these additional TMMs. For example, if a user sets maxActiveReplicas to 4 and deploys a total of 6 TMMs, then 2 of those TMMs will be designated as standbys, ready to activate as needed.

     • If the minimum number of selfIPs across all VLANs is less than maxActiveReplicas, the effective maxActiveReplicas is limited to that minimum. For example, with ‘maxActiveReplicas’ set to 6, VLAN CR A having 6 self IPs, and VLAN CR B having 4 self IPs, the effective maxActiveReplicas is 4. Thus, only 4 TMMs can be configured for traffic processing.