Symmetric and Asymmetric IRB
Both IRB models solved the same problem differently. This lesson contrasts them at the level a SONiC operator needs — what each requires on every VTEP, how the L3VNI does or does not appear, and the operational tradeoffs — with a hard caveat: identify what your specific lab image supports before assuming either workflow.
Prerequisites: Lessons 4.1, 4.3, 4.4
Learning objectives
- →Contrast asymmetric and symmetric IRB in terms of what each VTEP must hold and configure.
- →Explain the role of the L3VNI and type-5 routes in the symmetric model.
- →Enumerate the operational tradeoffs (scale, config symmetry, MAC/ARP scale) of each.
- →State the verification step to confirm which model your image supports before designing a workflow.
Choosing an IRB model dictates your config template, your scaling limits, and your troubleshooting commands. Picking one your image does not fully support is a costly late discovery.
Inter-subnet forwarding — the thing tenants actually ask for — lives or dies on the IRB model, so this is where design meets daily operations.
| In the analogy | In SONiC |
|---|---|
| The origin terminal must stock every destination tenant's labels | Asymmetric IRB |
| A shared transit label (L3VNI) both terminals understand for cross-tenant handoff | Symmetric IRB |
| The neutral transit-lane label used only between terminals | L3VNI |
Where the analogy stops working
The label analogy hides the real cost driver: asymmetric IRB forces every VTEP to hold ARP/ND and MAC state for *all* subnets it routes to, which is the scaling wall. It also hides that whether symmetric IRB, asymmetric IRB, or only L2 (no IRB) is available is entirely image/version dependent in SONiC — the analogy makes both look equally on-the-shelf when your image may stock only one.
Do not assume your SONiC image supports symmetric IRB, asymmetric IRB, or L3VNI routing at all. Support and defaults vary by version, distribution, and ASIC/SAI. Confirm on the actual lab image first: check show evpn vni for L2 vs L3 VNIs, look for L3VNI/VRF-VNI support in the image's docs, and validate a routed cross-subnet flow in a lab before committing a design. Treat everything below as the model to verify, not a guaranteed workflow.
Asymmetric vs symmetric IRB
| Aspect | Asymmetric IRB | Symmetric IRB |
|---|---|---|
| Forwarding model | Route-in, bridge-out in destination VNI | Route-in, route-across L3VNI, route-out |
| VNIs per VTEP | Must configure *every* VNI it talks to | Only locally attached VNIs + shared L3VNI |
| Route type used | Relies on type-2 MAC/IP across all VNIs | type-5 IP prefixes over the L3VNI |
| State/scale cost | ARP/MAC for all remote subnets → scaling wall | Only local host state + prefixes → scales better |
| Config symmetry | Asymmetric VNI use forward vs return | Symmetric; easier templating |
| Typical modern choice | Simpler mentally, limited scale | Preferred at scale — if the image supports L3VNI |
What the L3VNI actually is
In the symmetric model the L3VNI is a per-VRF transit VNI that carries routed traffic between VTEPs. type-5 routes advertise tenant prefixes tagged with the VRF's route target and the L3VNI; the ingress VTEP routes the packet into the L3VNI, ships it, and the egress VTEP routes it out into the destination subnet. No VTEP needs to know the destination subnet's L2VNI unless a host is locally attached there.
This is why symmetric IRB scales: a VTEP holds host/ARP state only for subnets with local hosts, plus routed prefixes — not the full L2 state of every subnet in the fabric.
Confirming what your image exposes
show evpn vni # look for VNIs typed as 'L3' (VRF) vs 'L2'
show evpn vni detail # VRF binding, L3VNI, router MAC per VNI
show bgp l2vpn evpn route type prefix # are type-5 routes present at all?
vtysh -c 'show version' # FRR version — feature availability varies
show version # SONiC image/build — record it in the lab logRun these on the actual lab image before choosing a model. The presence/labels here tell you what is realistically available.
Operational tradeoffs at a glance
| Dimension | Asymmetric | Symmetric |
|---|---|---|
| VNI provisioning | All VNIs on all routing VTEPs | Local VNIs + one L3VNI per VRF |
| ARP/ND scale | High (all remote subnets) | Lower (local subnets only) |
| Troubleshooting focus | type-2 across many VNIs | type-5 + L3VNI + router MAC |
| Failure blast radius | VNI sprawl → more to misconfigure | Tighter, but L3VNI is a shared dependency |
| Image dependency | Verify L2 IRB support | Verify L3VNI/type-5 support — often the gating factor |
- For a symmetric-IRB fabric, verify the router MAC and L3VNI as first-class objects, not afterthoughts.
- For asymmetric IRB, confirm the destination VNI exists on the ingress VTEP — a missing VNI there is the classic break.
- Always record the image/build; an inter-subnet workflow that 'worked in class' may not exist on a different image.
Key takeaways
- ✓Asymmetric = route-in/bridge-out, every VNI everywhere; symmetric = route via shared L3VNI with type-5.
- ✓Symmetric scales better but depends on L3VNI/type-5 support in your image.
- ✓IRB model dictates config template, scale, and troubleshooting commands.
- ✓Confirm your specific image's IRB support before designing any inter-subnet workflow.
Tested against: SONiC 202305 / 202311 lineage · Upstream (community) unless noted · SONiC-VS (virtual) baseline · last reviewed 2026-07. Exact commands and behavior can vary by SONiC release, image, hardware platform, and enterprise distribution.
Knowledge check
You are designing inter-subnet forwarding and want the symmetric IRB model so VTEPs only hold local subnet state plus a shared L3VNI. Before committing the design, what is the single most important thing to confirm?