I85PREP
⌘ K
Aruba Data Center Professional study materials
Aruba Data Center Professional study resources

Asymmetric IRB and a stateful firewall that only sees half the flow

Aruba Data Center Professional · Put your knowledge to work in context.

All case studies

Asymmetric IRB and a stateful firewall that only sees half the flow

A financial-services tenant hosts 900 VMs across three VRFs (PROD, DEV, SHARED-SERVICES) on a two-spine, twelve-leaf EVPN fabric. Two hard requirements: (a) PROD must reach SHARED-SERVICES through a stateful firewall, while DEV must not; (b) east-west traffic between two VMs on the same leaf must never leave the leaf. The current design uses asymmetric IRB with a central border leaf. Operations reports that PROD-to-SHARED traffic hairpins through the border, the firewall logs and sees only one direction of each flow, and that after a vMotion the new leaf answers ARP for the moved VM while the old leaf still holds the MAC.

1. Explain why asymmetric IRB produces these symptoms and specify the overlay change you would make.

Read the worked answer

Both models use one L3 VNI per VRF; they differ in who routes and which VNI the packet carries.

  • Asymmetric IRB: the ingress VTEP routes into the destination VRF and tunnels the packet in the destination VRF's L3 VNI, which the egress VTEP bridges. It is fast and simple, but every VTEP must hold every VRF, and a packet's VNI changes between directions. A stateful firewall in the path sees ingress in one VNI and the return in another - hence half-flows and dropped sessions. Compounding it, a central border doing all inter-VRF routing forces the hairpin.
  • Symmetric IRB: every VTEP routes and re-encapsulates using its own L3 VNI; the receiving VTEP routes again into the destination VRF. Each hop is VRF-aware, the VNI is consistent per direction, and you can place a service VTEP so both directions traverse it.

The change: enable distributed anycast gateway (identical gateway IP and virtual MAC on all twelve leaves), one L3 VNI per VRF, and route at the leaf so same-leaf traffic never leaves the leaf. For PROD-to-SHARED, steer through a service leaf/VRF that hosts the firewall so ingress and egress follow symmetric paths. Leave DEV's VRF out of the service VRF's import list so it never touches the firewall.

Verification: confirm the anycast MAC is identical fabric-wide, check that inter-VRF lookups resolve locally (show evpn mac-ip, L3 VNI state) with no border hop, and confirm the firewall session table shows both directions for PROD flows and no entries for DEV.

2. Design the route-target scheme so PROD reaches SHARED through the firewall but DEV does not, and explain the constraint you must not violate.

Read the worked answer

The constraint: one L3 VNI maps to exactly one VRF. You cannot stretch a single VNI across PROD and SHARED to "make them talk" - that collapses the segmentation you are being paid to provide, and it breaks the firewall placement.

Scheme:

  • Unique RD per VRF (auto-derived per VTEP) and a unique route-target pair per VRF, with explicit import/export lists - never wildcard *:* import on a fabric carrying regulated data.
  • Do not directly leak PROD into SHARED. Build a transit VRF on the service leaf that represents the firewall: PROD exports into the firewall-transit VRF, and the transit VRF exports into SHARED. Each leg gets its own VNI, and the firewall is a routed hop on the service leaf. That gives you one-directional control per leg and a clean audit boundary.
  • Only if a leak is unavoidable, put the SHARED RT in PROD's import list and PROD's RT in SHARED's import list - a leak is bidirectional; document it as an exception with an expiry date.
  • DEV imports nothing from PROD and exports nothing to SHARED.

Note: the same subnet appearing on all twelve leaves is not a leak - that is distributed anycast gateway at L2/L3. Keep that distinction explicit in the design document, because reviewers frequently confuse the two and over-engineer per-leaf subnets.

3. How would you triage the post-vMotion MAC/ARP symptom, and what is the most likely root cause?

Read the worked answer

Mechanism: with an anycast gateway, every leaf answers ARP for a VM from its EVPN MAC/IP table. If the old leaf still holds the type-2 route, it keeps answering and black-holes the traffic - the VM pings its own gateway and reaches nothing.

Triage order:

  1. show evpn mac-ip on the old and new leaf for the VM's MAC. Compare the MAC mobility sequence number: the higher sequence must win. If the old entry carries the sticky bit or an equal sequence, it will not be replaced.
  2. Look for a genuine duplicate MAC - the same MAC/IP advertised from two VTEPs with no mobility event, plus a rising duplicate-MAC counter. That is usually the guest VM itself: a leftover bridged adapter, a stale port group, or a cloned MAC.
  3. Temporarily disable ARP/ND suppression on both leaves. If the symptom clears, the fault is the suppression cache; if it persists, the route never moved and you are chasing the control plane.
  4. Confirm the anycast gateway MAC is identical on all leaves and the VM does not hold a static ARP entry pointing at the old gateway MAC.

Most likely root cause in a design that just changed IRB mode: the mobility event did not propagate because the old leaf still considers the entry authoritative - commonly sticky MACs (static/port-security entries or a manual static MAC) followed by a stale suppression cache. Fix: clear the sticky condition, confirm the sequence-number handoff, and add the two show commands to the vMotion runbook so it is a two-minute check rather than an escalation.