Practical Mapping Guide - F5 BIG-IP TMOS Modules to Feature-Scoped CNFs

 

Introduction

BIG-IP TMOS and BIG-IP CNFs solve similar problems with very different deployment and configuration models. In TMOS you deploy whole modules (LTM, AFM, DNS, etc.), while in CNFs you deploy only the specific features and data plane functions you need as cloud native components.

Modules vs feature scoped services

• In TMOS, enabling LTM gives you a broad set of capabilities in one module: virtual servers, pools, profiles, iRules, SNAT, persistence, etc., all living in the same configuration namespace.
  
  
• In CNFs, you deploy only the features you actually need, expressed as discrete custom resources: for example, a routing CNF for more precise TMM routing, a firewall CNF for policies, or specific CRs for profiles and NAT, rather than bringing the entire LTM or AFM module along “just in case”.

Configuration objects vs custom resources

• TMOS configuration is organized as objects under modules (for example: LTM virtual, LTM pool, security, firewall policy, net vlan), managed via tmsh, GUI, or iControl REST.
  
  
• CNFs expose those same capabilities through Kubernetes Custom Resources (CRs): routes, policies, profiles, NAT, VLANs, and so on are expressed as YAML and applied with GitOps-style workflows, making individual features independently deployable with a version history.

Coarse-grained vs precise feature deployment

• On TMOS, deploying a use case often means standing up a full BIG-IP instance with multiple modules enabled, even if the application only needs basic load balancing with a single HTTP profile and a couple of firewall rules.
  
  
• With CNFs, you can carve out exactly what you need: for example, only a precise TMM routing function plus the specific TCP/HTTP/SSL profiles and security policies required for a given application or edge segment, reducing blast radius and resource footprint.

BIG-IP Next CNF Custom Resources (CRs) extend Kubernetes APIs to configure the Traffic Management Microkernel (TMM) and Advanced Firewall Manager (AFM), providing declarative equivalents to BIG-IP TMOS configuration objects. This mapping ensures functional parity for L4-L7 services, security, and networking while enabling cloud-native scalability. Focus here covers core mappings with examples for iRules and Profiles.

What are Kubernetes Custom Resources 

Think of Kubernetes API as a menu of objects you can create: Pods (containers), Services (networking), Deployments (replicas). CRs add new menu items for your unique needs. You first define a CustomResourceDefinition (CRD) (the blueprint), then create CR instances (actual objects using that blueprint).

How CRs Work (Step-by-Step)

1. Create CRD - Define new object type (e.g., "F5BigFwPolicy") 
2. Apply CRD - Kubernetes API server registers it, adding new REST endpoints like /apis/f5net.com/v1/f5bigfwpolicies
3. Create CR - Write YAML instances of your new type and apply with kubectl
4. Controllers Watch - Custom operators/controllers react to CR changes, creating real resources (Pods, ConfigMaps, etc.)

 

CR examples 

Networking and NAT Mappings

Networking CRs handle interfaces and routing, mirroring, TMOS VLANs, Self-IPs and NAT mapping.

 

Example: F5BigNetVlan CR sets VLAN tags and IPs, applied via kubectl apply, propagating to TMM like tmsh create net vlan.

Security and Protection Mappings

Protection CRs map to AFM and DoS modules for threat mitigation.

Example: F5BigFwPolicy references rule-lists and zones, equivalent to tmsh creating security firewall policy.

 

Traffic Management Mappings

Traffic CRs proxy TCP/UDP and support ALGs, akin to LTM Virtual Servers and Pools.

Example: GRPCRoute CR defines backend endpoints and profiles, mapping to tmsh create ltm virtual.

Profiles Mappings with Examples

Profiles CRs customize traffic handling, referenced by Traffic Management CRs, directly paralleling TMOS profiles.

Profiles attach to Virtual Servers/Ingresses declaratively, e.g., spec.profiles: [{ name: "my-tcp", context: "tcp" }].

iRules Support and Examples

CNF fully supports iRules for custom logic, integrated into Traffic Management CRs like Virtual Servers or FTP/RTSP. iRules execute in TMM, preserving TMOS scripting.

• Example CR Snippet:

apiVersion: k8s.f5net.com/v1

kind: F5BigCneIrule

metadata:

  name: cnfs-dns-irule

  namespace: cnf-gateway

spec:

  iRule: >

    when DNS_REQUEST {

      if { [IP::addr [IP::remote_addr] equals 10.10.1.0/24] } {

        cname cname.siterequest.com

      } else {

        host 10.20.20.20

      }

    }

This mapping facilitates TMOS-to-CNF migrations using tools like F5Big-Ip Controller for CR generation from UCS configs. For full CR specs, refer to official docs.

 

The updated full list of CNF CRs per release can be found over here,  https://clouddocs.f5.com/cnfs/robin/latest/cnf-custom-resources.html

 

Conclusion

In this article, we examined how BIG-IP Next CNF redefines the TMOS module model into a feature-scoped, cloud-native service architecture.

By mapping TMOS objects such as virtual servers, profiles, and security policies to their corresponding CNF Custom Resources, we illustrated how familiar traffic management and security constructs translate into declarative Kubernetes workflows.

 

Related content 

• F5 Cloud-Native Network Functions configurations guide 

• BIG-IP Next Cloud-Native Network Functions (CNFs) 

• CNF DNS Express 

• BIG-IP Next for Kubernetes CNFs - DNS walkthrough 

• BIG-IP Next for Kubernetes CNFs deployment walkthrough | DevCentral 

• BIG-IP Next Edge Firewall CNF for Edge workloads | DevCentral 

• Modern Applications-Demystifying Ingress solutions flavors | DevCentral