Active/Standby F5 Across Different ACI Pods

Mukesh Chanderia
Feb 11
4 min read

Normal L3Out vs Floating L3Out Explained

Understanding Cisco ACI Multi-Pod Architecture

In a Cisco ACI Multi-Pod design:

Each Pod has an independent IS-IS control plane
Endpoint learning is maintained through COOP
Inter-pod communication uses MP-BGP
Pods are interconnected via the IPN (Inter-Pod Network)

Each Pod effectively behaves like an independent availability zone.

When deploying:

Active F5 in Pod 1
Standby F5 in Pod 2

You achieve true failure domain isolation, significantly improving resiliency.

Key Benefits of Active/Standby Across Pods

1️⃣ Availability Zone Resilience

If Pod 1 experiences:

Power failure
Fabric outage
Border leaf failure

The Standby F5 in Pod 2 can take over without dependency on Pod 1.

This architecture dramatically improves application uptime.

2️⃣ Improved Traffic Symmetry (vs Active/Active)

In Active/Standby mode:

Only one F5 processes traffic at a time
The VIP is advertised only by the active unit

This reduces asymmetric routing risks commonly seen in Active/Active deployments.

Note:Whether SNAT or PBR is required depends on routing architecture and gateway placement. Active/Standby alone does not automatically remove those requirements.

3️⃣ Seamless Failover with Network Failover

For cross-pod deployments:

Hard-wired failover is not suitable (distance limitations)
Network Failover must be used
Failover is detected via heartbeat over IP
GARP and routing updates ensure fabric convergence

During Failover:

Active F5 withdraws VIP advertisement
Standby F5 begins advertising VIP
ACI updates routing
MP-BGP propagates the route change across Pods

Deploying with Normal L3Out in Multi-Pod

Design Characteristics

In a Normal L3Out:

Interfaces are explicitly bound to specific leaf nodes
Routing adjacency exists only on those defined leaves

Configuration Model

Create a single L3Out under the Tenant
Under Logical Node Profile:
- Add leaf nodes from Pod 1 (Active F5)
- Add leaf nodes from Pod 2 (Standby F5)
Configure explicit interface paths (SVI or routed interfaces)
All nodes must belong to the same VRF

Routing Behavior

Active F5 advertises VIP via BGP (or OSPF)
ACI installs route toward Pod 1
Upon failover, Pod 2 advertises VIP
MP-BGP propagates route change across Pods

Deploying with Floating L3Out in Multi-Pod

Floating L3Out provides greater flexibility and is often preferred when:

Using F5 VE
Devices may move between racks
You want simplified interface management

Key Architectural Components

Anchor Nodes

Leaf switches directly connected to F5 devices must be configured as Anchor Nodes.

If F5 appliances exist in both Pods:

Leaf(s) in Pod 1 must be Anchor
Leaf(s) in Pod 2 must also be Anchor

Only Anchor nodes:

Establish routing adjacency
Advertise routes

Floating SVI

Floating L3Out uses:

A Floating SVI
A Floating IP address

Anchor nodes use a Primary IP.Non-anchor nodes use the Floating IP for consistent forwarding behavior.

Important distinction:

Only Anchor nodes run routing protocols
Non-anchor nodes do not form adjacency
Non-anchor nodes forward traffic internally to Anchor nodes

Critical Multi-Pod Restriction

Cisco documentation recommends avoiding designs where:

Anchor node is in Pod 1
Non-anchor node handling traffic is in Pod 2

Why?

Floating L3Out relies on internal next-hop propagation. Cross-pod anchor/non-anchor combinations may lead to suboptimal or unsupported forwarding behavior.

Best Practice:

If F5 devices exist in multiple Pods, configure leaf nodes in each Pod as Anchor nodes.

Normal L3Out vs Floating L3Out

Feature	Normal L3Out	Floating L3Out
Interface Binding	Explicit per leaf path	Domain-based
Routing Adjacency	On configured leafs	On Anchor nodes
Multi-Pod Setup	Add nodes from both Pods	Add Anchor nodes in both Pods
Best Use Case	Physical, fixed devices	Virtual/mobile deployments
Data Plane Flexibility	Limited to border leaves	Fabric-wide forwarding
Scale	Lower	Better

When Should You Choose Each?

Choose Normal L3Out When:

F5 devices are physical and static
You prefer deterministic border routing
Simplicity is priority

Choose Floating L3Out When:

Using F5 VE
Device mobility is required
You want forwarding flexibility
You want reduced operational complexity

Lab Guide: Active/Standby F5 Across ACI Multi-Pod

1️⃣ Lab Topology

Pod-1Leaf101 / Leaf102 → F5-A (Active)

Pod-2Leaf201 / Leaf202 → F5-B (Standby)

Tenant: TENANT1VRF: PROD-VRFRouting: BGPVIP: 172.16.100.100/32

Scenario 1 – Normal L3Out

What Happens

Routed interfaces explicitly configured
Each leaf has its own IP toward F5
BGP adjacency forms per leaf
Upon failover, standby advertises VIP

Verification Commands

Check BGP Peers:

Leaf# show external-l3 bgp

Check BGP per Tenant/VRF:

Leaf#show external-l3 bgp tenant TENANT1 vrf PROD-VRF

Check specific leaf:

Leaf#show external-l3 bgp tenant TENANT1 vrf PROD-VRF node 101

Check interfaces:

Leaf#show external-l3 interfaces tenant TENANT1 vrf PROD-VRF node 101

Troubleshooting:

Leaf#show events tenant TENANT1 vrf PROD-VRF external-l3 bgp node 101

Expected Behavior:

All four leafs show BGP adjacency
Each leaf has independent SVI

Scenario 2 – Floating L3Out (Recommended)

What Changes

Only Anchor nodes form BGP
Floating SVI created once
Non-anchor nodes forward without BGP adjacency
Floating IP exists in BD

Anchor Design

Pod-1:

Leaf101 (Anchor)
Leaf102 (Anchor)

Pod-2:

Leaf201 (Anchor)
Leaf202 (Anchor)

All others automatically operate as non-anchor nodes.

Verification

Check BGP on Anchor:

Leaf# show external-l3 bgp tenant TENANT1 vrf PROD-VRF node 101

Expected:

BGP UP

Check Non-Anchor:

Leaf# show external-l3 bgp tenant TENANT1 vrf PROD-VRF node 103