EVPN firewall policy: centralized gateway vs distributed IRB

Two EVPN designs put the tenant gateway in different places, and the firewall sees different traffic in each. With a centralized gateway, inter-subnet traffic reaches the firewall because that is where routing happens. With distributed IRB, leaves route locally and the firewall sees nothing unless you insert it deliberately. Neither model is wrong. What is wrong is attaching a firewall at the border and assuming the fabric delivers traffic to it.

Two models, two different inspection points

Name the flows that need inspection first, because the two models treat them differently.

Same-subnet traffic is the row people forget. Two hosts on one VLAN talk through bridging, and no routed firewall sits in that path unless a separate Layer 2 inspection design intercepts it. That is true in both models, so it is a design gap rather than a comparison between them.

The other three rows are where the models actually diverge.

Centralized gateway: simple inspection, real transit cost

Keep the tenant VLANs as Layer 2 services and place their routing gateways on the firewall. Inter-subnet traffic then travels to that gateway and back, potentially even when both hosts sit on the same leaf. The inspection point is unambiguous, which is the whole argument for the design. The cost is transit load on the firewall plus a central capacity and availability dependency you now have to engineer.

Scope the change to the tenant gateways you intend. Removing every VLAN address is too broad when management, underlay and platform interfaces have separate duties. Check for a second active gateway as well, because one that still routes around the firewall defeats the design quietly.

This model is easier to explain to an auditor. It is not automatically cheaper to run.

Distributed IRB: fast path, no inspection by default

With distributed anycast gateways, each leaf routes tenant traffic locally, and RFC 9135 describes why that avoids the backhaul of a centralized gateway. The benefit is real, and it has a direct consequence: inspection cannot be inferred from where the firewall is plugged in. A firewall attached to a border leaf sees external traffic and whatever you explicitly redirect to it.

Insert the service with a mechanism the platform actually supports: policy-based redirection, a service node, or controlled inter-VRF routing through the firewall. Match the intended traffic at its real ingress point. A policy written on a host-facing interface does not cover a packet arriving from the overlay.

Read the installed routes rather than the intended default. A more-specific tenant prefix imported directly can bypass the default route that points at the firewall, and nothing in the configuration will look wrong.

Symmetry is a routing property, not an inspection guarantee

Symmetric IRB describes how ingress and egress provider edge nodes handle routing and bridging for a flow. It says nothing about whether both directions reach the same stateful device. ECMP, anycast and firewall high availability all affect which node sees the return traffic, and the cluster's supported state model decides whether that is acceptable.

Follow the return path explicitly for every flow you care about. NAT is not a universal substitute for that work, and designs that lean on it usually find the gap during a failover rather than during the build.

Walk one required flow and one deliberately excluded flow, in both directions, before you sign the design off.

How to choose, and what to test either way

Choose the centralized gateway when inspection coverage matters more than transit capacity and you can afford the central dependency. Choose distributed IRB when local routing is the point, and budget for explicit service insertion instead of assuming it.

Then test the routing you actually installed, because that is where the two designs differ most:

show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefix

Include service-node failure and recovery in the test. A fallback route that quietly bypasses inspection is a different decision from a planned fail-open policy, and only one of them is usually intended. The finished design names where each traffic class routes, where it is inspected, and what happens when that inspection path is unavailable.