BIG-IP networking is a strict dependency chain: physical interfaces at the bottom, then trunks, then Virtual Local Area Networks (VLANs), then self-IPs, then routes. Each layer exists on the one below, status flows upward, and traffic decisions read the chain downward. The blueprint asks you to explain the relationships and their status and statistics, which rewards walking the chain deliberately.

Interfaces and trunks

An interface is a physical port with speed, duplex, and an up-or-down status visible in show net interface, counters included - the first stop when drops or errors are suspected. A trunk aggregates interfaces into one logical link, normally negotiated with the Link Aggregation Control Protocol (), for bandwidth and for surviving a member failure. Illustrating the use of a trunk is straightforward: two cables to the switch behave as one faster, more durable link, and show net trunk reports the working member count - a trunk running on fewer members than configured is degraded but up, a state worth alarming on.

VLANs: tagged or untagged

A is assigned interfaces or trunks, and each assignment is tagged or untagged. Untagged means frames leave the port bare and the port belongs to exactly one VLAN - access-port behavior. Tagged means frames carry the 802.1Q VLAN identifier, letting one interface or trunk carry many VLANs - the normal pattern on a trunk into a switch. The distinguishing rule for the exam: untagged pairs one VLAN with the port, tagged multiplexes many, and both ends of the cable must agree or traffic silently lands in the wrong broadcast domain.

Self-IPs: the device's own addresses

A self-IP gives the BIG-IP an address on a VLAN - the address monitors source from, config sync and failover peers reach, and servers use as their gateway. Floating self-IPs belong to a traffic group and move on failover; static self-IPs stay with the device. Every self-IP carries the port lockdown setting covered in management access. The dependency reads: no VLAN, no self-IP; VLAN down because its last interface died, self-IP unreachable.

Routes and the egress decision

Which VLAN, route, and egress address traffic uses is a routing decision: destination matched against the routing table (per route domain), the chosen route naming a gateway reachable on some VLAN through some self-IP. For traffic the device originates or forwards to servers, the source is the self-IP on the egress VLAN - unless Secure Network Address Translation () rewrites it, the subject of SNAT and return traffic.

Status cascades

The chain is also a failure model. Interface down: trunk degrades or dies; a VLAN whose last died takes its self-IPs with it; routes via those self-IPs stop resolving; monitors sourced from them go dark, marking healthy servers down. Compare interface status first, then walk upward - the dependencies of interfaces, trunks, VLANs, and self-IPs, in exactly the blueprint's order.

This series, in order

This article opens the series BIG-IP foundations, from interface to pool member. It lays the dependency chain from interface to self-IP that everything else stands on; the parts first finish the box (segmentation, management access, the services it relies on), then follow one connection in the order the BIG-IP handles it, and end with how the platform spreads that work across cores and carves itself into guests.

  1. Route Domains: Layer 3 Segmentation Inside One BIG-IP. A separate routing table with an ID, so tenants with overlapping address spaces share one device: the percent-sign notation and strict isolation.
  2. Management Access on BIG-IP: the Management IP, Port Lockdown, and Access Lists. The two doors into a BIG-IP: the management address, and what port lockdown really permits on a self-IP.
  3. The System Services Behind a Healthy BIG-IP: DNS, NTP, SNMP, Syslog. DNS, , and remote syslog: four small configurations with an outsized blast radius.
  4. How a BIG-IP Virtual Server Works. The front door: the listening address and port, the profile stack, persistence, the pool member and the source translation.
  5. BIG-IP Virtual Server Types, and What Each One Actually Does. From a full proxy that terminates and re-originates connections to a packet-by-packet forwarder: what each type actually does.
  6. Profiles on a Virtual Server. Protocol, application, SSL and persistence profiles stacked into the behaviour of one virtual server, and how they inherit.
  7. BIG-IP Pools and Load-Balancing Methods. The pool of backend members, and the split between static methods and the dynamic ones that react to load.
  8. BIG-IP Load-Balancing Methods, and What Each One Weighs. The documented methods along two axes: whether they react to live state at all, and what exactly they weigh.
  9. Where Do the Requests Go? Simulating BIG-IP LTM Distribution. From the rule to the outcome: why Ratio is a full cycle, and how priority group activation leaves members idle.
  10. How LTM Health Monitors Decide Up or Down. Send and receive strings, interval and timeout, and where the monitor is attached: how fast a failure is noticed.
  11. BIG-IP Persistence Methods, and What Each Keys On. Cookie, source address, SSL session or an iRule value: what each method keys on, and where each one breaks.
  12. SNAT and the Return-Traffic Problem. Why the member's reply must come back through the BIG-IP, and how SNAT makes it.
  13. OneConnect: Reuse Is a Grouping Problem, and SNAT Rewrites the Groups. Idle server-side connections handed to the next eligible request, the source mask that defines eligible, and what SNAT does to the groups.
  14. Protocol Profiles: Living TCP, Frozen TCP, and the Two Fast Paths. Living TCP profiles, the frozen legacy trio, and the two fast paths that trade the full proxy for speed.
  15. CMP: The Cores You Paid For, and the iRule Lines That Give Them Back. One TMM per core, the demoted virtual server that runs everything on one, and static:: as the cure.
  16. vCMP: Hosts, Guests, and How Resources Are Carved. One platform carved into independent guests: the host and guest model, the lifecycle, and how cores drive memory.