EVPN IRB: Symmetric vs Asymmetric Routing Models

Two leaves, two subnets, a host in each. Traffic between them has to be routed somewhere. In an EVPN-VXLAN fabric there are two ways to do that — IRB (Integrated Routing and Bridging) in asymmetric or symmetric mode — and the choice quietly decides how your fabric scales, how much config every leaf carries, and how hard troubleshooting gets.

Most people pick whatever the platform defaults to and never think about it again. That works until it doesn’t.

The Forwarding Question

Inter-subnet traffic between two VTEPs has to be routed (different subnets) and bridged (VXLAN is an L2 overlay). The difference between the two models is where the routing happens.

Asymmetric IRB: route-bridge

The ingress leaf does all the routing. It receives the frame, routes from the source VLAN into the destination VLAN, then bridges the result across the fabric in the destination L2 VNI:

ingress leaf:  bridge(src VNI) -> route -> bridge(dst VNI) -> VXLAN
egress leaf:   bridge(dst VNI) -> host

The packet travels in the destination VNI. The egress leaf only bridges — it never routes this flow.

The catch: the ingress leaf must have an SVI and the destination VNI configured locally, even if it hosts no servers in that subnet. So every leaf needs every VLAN/VNI that any of its hosts might talk to. In a fabric with hundreds of tenants, that is VNI sprawl on every box.

Symmetric IRB: route-route-bridge

Each leaf routes into a shared transit L3 VNI. The packet crosses the fabric in the L3 VNI, and the egress leaf routes again into the destination subnet:

ingress leaf:  bridge(src VNI) -> route into L3 VNI -> VXLAN
egress leaf:   route out of L3 VNI -> bridge(dst VNI) -> host

Both leaves route — hence “symmetric.” The key win: a leaf only needs the VLANs of the hosts actually attached to it, plus the single per-VRF L3 VNI. No sprawl.

Why Symmetric Won

Asymmetric is simpler to reason about for two subnets in a lab. Symmetric is what survives a real multi-tenant DC. Every modern fabric design standardizes on symmetric IRB, and it is what the NX-OS associate-vrf / L3 VNI config produces.

What Symmetric Looks Like in Config

The defining element is the per-VRF L3 VNI tied into the NVE interface (NX-OS):

vlan 999
  vn-segment 50999          # L3 VNI

vrf context TENANT-A
  vni 50999
  rd auto
  address-family ipv4 unicast
    route-target both auto evpn

interface Vlan999
  no shutdown
  vrf member TENANT-A
  ip forward                 # L3 VNI SVI: routed, no IP, no anycast

interface nve1
  member vni 50999
    associate-vrf            # this makes it the transit L3 VNI

interface Vlan999 with ip forward and no address is the core-facing routed interface for the L3 VNI. Tenant SVIs (Vlan10, Vlan20) keep their anycast gateways; this one just routes between leaves.

On Junos the equivalent is a routing-instance of type vrf with a VXLAN-encapsulated IRB and the L3 VNI under protocols evpn:

routing-instances {
    TENANT-A {
        instance-type vrf;
        interface irb.10;
        interface irb.20;
        route-distinguisher 10.255.1.11:999;
        vrf-target target:65000:50999;
        protocols evpn { ip-prefix-routes { advertise direct-nexthop; encapsulation vxlan; vni 50999; } }
    }
}

Reading the Routes

The Type-2 (MAC/IP) and Type-5 (IP-prefix) routes tell you which model is in play.

• Asymmetric leans on Type-2 routes with both MAC and IP — the ingress leaf needs the host route in the destination VNI.
• Symmetric uses Type-5 routes carrying the L3 VNI and a router-MAC, so the egress leaf knows to route, not just bridge.

# NX-OS: confirm Type-5 routes carry the L3 VNI and router-mac
show bgp l2vpn evpn route-type 5

# Look for the routes tagged with the L3 VNI (50999) and a Router MAC
# in the path attributes. If you only see Type-2, you're asymmetric.

# Junos
show route table bgp.evpn.0 evpn-etype 5 extensive
# Each prefix should show VNI 50999 and an encapsulation of VXLAN

The Troubleshooting Payoff

With symmetric IRB the path is deterministic, which makes failures readable:

# Does the tenant VRF have the remote subnet via the L3 VNI?
show ip route vrf TENANT-A 10.10.20.0/24
# next-hop = remote VTEP, %TENANT-A, via L3 VNI 50999

# Is the router-MAC of the remote VTEP installed?
show l2route evpn mac-ip all
show forwarding vrf TENANT-A route 10.10.20.5

If the Type-5 route is present but traffic still drops, the usual culprit is a missing or mismatched router-MAC, or the L3 VNI not associated to the VRF on one leaf. With asymmetric IRB the same symptom could be any leaf missing any VLAN, which is a much larger haystack.

The Router-MAC Is the Linchpin

Symmetric IRB hinges on one thing most people never inspect until it breaks: the per-VTEP router-MAC. A Type-5 route does not carry a host MAC — it carries an IP prefix plus the L3 VNI and the router-MAC of the originating VTEP, attached as a BGP extended community. The egress leaf uses that router-MAC as the inner destination MAC when it routes the packet out of the L3 VNI. Get the router-MAC wrong on either side and the Type-5 route installs cleanly while the data plane silently drops every routed packet.

# NX-OS: the router-MAC carried in a received Type-5 route (BGP ext-community)
show bgp l2vpn evpn route-type 5 10.10.20.0/24
# Path attributes should carry:  Router MAC: 5e00.0011.0007  and  VNI 50999

# the local VTEP's own router-MAC and NVE source
show nve interface nve1 detail

Compare the Router-MAC in the received Type-5 route against the remote leaf’s actual system MAC:

# On the remote (originating) leaf
show running-config | include "router-mac\|system-mac"
show forwarding vrf TENANT-A adjacency        # rewrite info, inner DMAC = remote router-MAC

If the route is present, the L3 VNI matches, and traffic still drops, the rewrite adjacency is where the truth lives — show forwarding ... adjacency shows the actual inner MAC the ASIC will stamp. A mismatch there versus the advertised Router-MAC is a programming or template bug, and no amount of staring at the BGP table reveals it.

Asymmetric’s Hidden Cost: ARP and ND Scale

The VNI-sprawl argument is the headline against asymmetric IRB, but the quieter killer is host-table scale. Because the ingress leaf routes directly into the destination L2 VNI, it must resolve ARP/ND for every remote host it talks to, and it installs those entries locally. On a chatty multi-tenant fabric the ARP table on a single leaf can balloon to the sum of every host any of its locally-attached servers ever contacted.

# Asymmetric: watch this climb on a busy leaf
show ip arp vrf TENANT-A summary
show forwarding vrf TENANT-A adjacency stats        # host adjacencies installed

# Symmetric: this stays bounded to locally-attached hosts + remote subnets
show ip route vrf TENANT-A summary                  # prefixes, not hosts

Symmetric IRB bounds the table to prefixes via Type-5, not hosts via Type-2, so the egress leaf resolves ARP only for the hosts physically attached to it. On platforms with a fixed host-route TCAM scale (most fixed leaves), asymmetric IRB is the design that hits the ceiling first — and the failure mode is ugly: silent host-route eviction, intermittent drops, and a counter you were not watching.

The MTU Tax of Double Encapsulation

Symmetric IRB routes the packet twice and still wraps it in VXLAN, so the inner payload is the full tenant frame and the outer header is the usual 50-byte VXLAN overhead. The trap is hosts that send 1500-byte frames into a fabric whose underlay is also 1500 — the encapsulated packet is 1550 and gets dropped or fragmented at the first transit hop. The symptom is classic and misleading: ping works, small flows work, large transfers and TLS handshakes hang.

# Underlay links and the L3 VNI SVI must carry the jumbo MTU
show interface Ethernet1/1 | include MTU
show interface Vlan999 | include MTU         # the ip forward L3 VNI interface
# Both should read 9216, not 1500

# Prove it end to end across the L3 VNI, DF-bit set so nothing fragments
ping 10.10.20.5 vrf TENANT-A df-bit packet-size 9000 source 10.10.10.1

Set 9216 on every underlay link and on the L3 VNI SVI fabric-wide. This bites symmetric IRB harder than asymmetric only because symmetric is the model you actually deploy at scale — the failure shows up the first time a backup job or a database replication stream pushes full-size frames.

The Standardization Call

Pick symmetric IRB and configure every tenant the same way: tenant SVIs with anycast gateways, one L3 VNI per VRF, associate-vrf on the NVE. Resist the urge to mix — a fabric where some VRFs are symmetric and some are asymmetric is the worst of both, because now troubleshooting requires first figuring out which model this particular tenant uses.

The two-subnet lab will work either way. Build for the fabric you will have in two years, not the one on your bench today.