Junos EVPN-VXLAN CRB Fabric: Step-by-Step Config

Modern data center fabrics are IP fabrics: BGP-based EVPN signals reachability in the control plane while VXLAN encapsulates frames in the data plane. Juniper's official example walks through a complete centrally routed bridging (CRB) fabric — two QFX spines, four QFX leaves, three VLANs, and full inter-VLAN routing done on the spines via IRB interfaces. This article condenses that configuration into the key building blocks: underlay eBGP, overlay iBGP, IRB gateways, VLAN-to-VNI mapping, and the verification commands that prove the fabric works.

CRB Architecture in a Nutshell

In a CRB design, integrated routing and bridging (IRB) interfaces are defined on the spine devices only — all inter-VLAN routing happens centrally at the spine layer. Leaves perform pure L2 bridging and VXLAN encapsulation. Each VLAN maps to a unique VXLAN Network Identifier (VNI); each IRB interface carries a unique subnet and serves as the default gateway for its VLAN, using a virtual gateway address for redundancy.

The alternative — edge-routed bridging (ERB) — places the IRB interfaces on the leaves, so a leaf routes between its own locally attached VLANs and only crosses the fabric for traffic destined to a remote rack. CRB is simpler to reason about and produces a single, consistent gateway per subnet no matter where the workload lives; ERB scales better for east-west traffic because routing decisions happen one hop from the server and traffic is not hairpinned through the spine. Choosing between them is one of the first design decisions in any EVPN-VXLAN project, and the rest of this guide assumes CRB because that is what the reference configuration builds.

Spine 1: Underlay Configuration

• Configure the L3 fabric interfaces and a loopback that serves as the VXLAN source address.
• Enable BGP multipath so all equal-cost paths through the underlay are used.
• Configure a load-balancing policy (per-packet) and a policy to advertise direct/loopback routes into the underlay.

set policy-options policy-statement export-direct term 1 from protocol direct
set policy-options policy-statement export-direct term 1 then accept
set routing-options autonomous-system 65001

The underlay is deliberately boring: it advertises only loopbacks and fabric link addresses, so the ECMP set the overlay depends on stays stable. The per-packet load-balancing policy matters more than it looks, because VXLAN adds a large outer header and naive hashing on the inner frame can pin a single flow onto one member link.

Spine 1: Overlay and Access Profile

• Configure an iBGP group for the EVPN address family, peering with the other spine and the leaves.
• Configure VXLAN encapsulation and no-gateway-community for EVPN.
• Define IRB interfaces for VLANs 101/102/103, each with its own subnet and virtual-gateway-address.
• Map VLANs to VNIs (e.g., VLAN 101 → VNI 10101) and set a route target per VNI.

set protocols bgp group overlay type internal
set protocols bgp group overlay local-address 10.0.0.1
set protocols bgp group overlay family evpn signaling
set protocols bgp group overlay neighbor 10.0.0.2
set protocols evpn encapsulation vxlan
set protocols evpn no-gateway-community
set switch-options vtep-source-interface lo0.0

Every VTEP needs a stable, routable source address — the loopback. If the VTEP source flaps, every remote VTEP tears down its tunnel to that device and all traffic to the attached VLANs black-holes until the tunnels re-establish. That is why the loopback is protected by the underlay and never used for anything else.

Leaf Configuration

Leaves in a CRB fabric have no IRB interfaces — only L2 functionality:

• eBGP group toward the spines for underlay routing; iBGP group for the EVPN overlay.
• Configure VXLAN encapsulation and how multicast/BUM traffic is replicated.
• Create a virtual-switch routing instance, map VLANs to the same VNIs used on the spines, and set route targets.
• Configure the access interface as a trunk (or untagged access) carrying the server VLAN.

set routing-instances evpn-vs instance-type virtual-switch
set routing-instances evpn-vs protocols evpn encapsulation vxlan
set routing-instances evpn-vs protocols evpn extended-vni-list all
set routing-instances evpn-vs vlan V101 vlan-id 101
set routing-instances evpn-vs vlan V101 l3-interface irb.101

Because a CRB leaf has no gateway, the VLAN-to-VNI mapping on the leaf and the spine must match byte for byte. A typo in one VNI number produces the classic symptom of "the tunnel is up but the host is unreachable" — the frames are being encapsulated and delivered to a VNI that no remote device is bridging.

VLAN-to-VNI and Route Target Planning

VNI numbering is a design choice, but a disciplined scheme pays off. A common convention is a fixed offset: VLAN 101 maps to VNI 10101, VLAN 102 to 10202, and so on, so the VLAN id is always recoverable from the VNI. Route targets are the other half of the story: the EVPN route target tells the receiving VTEP which VNI's routing table a route belongs to, so every VNI needs its own route target even if the communities look repetitive. Documenting both tables in a spreadsheet before touching the CLI prevents the most common EVPN misconfiguration, in which a route is advertised but imported into the wrong VRF.

BUM Traffic: Multicast or Ingress Replication

Broadcast, unknown-unicast and multicast frames must reach every VTEP that has a member in the VLAN. You can either use the underlay multicast group (PIM in the fabric) or ingress replication, where the ingress VTEP sends a copy to each remote VTEP in the flood list. Ingress replication keeps the underlay unicast-only and is the more common choice in smaller CRB fabrics; the trade-off is that the flooding load is generated by the ingress device and grows linearly with the number of VTEPs.

Underlay Addressing and Loopback Discipline

The underlay is the part of the fabric nobody notices until it breaks. Give every spine and leaf a /32 loopback from a dedicated range, for example 10.0.0.0/22, and make the point-to-point fabric links use unnumbered or /31 addresses from a completely separate block. The separation matters because the loopback block is what appears as the VTEP source and as the BGP next hop for EVPN routes; keeping it small, static and easy to filter makes it trivial to write a prefix list that refuses to leak anything else into the underlay. A common mistake is to advertise the fabric links along with the loopbacks, which inflates the underlay routing table and makes every fabric link failure a topology change the whole fabric must reconverge around instead of a local ECMP membership change.

Loopback addressing should also be predictable enough to read at a glance: if the last octet of the loopback encodes the device role and rack, an operator can look at a route and know where it lands without consulting the documentation. That habit pays for itself the first time someone has to debug a tunnel that is up on three spines and down on the fourth.

Designing for Failure: ECMP and Failure Domains

Every leaf should reach every spine over at least two independent paths, and the underlay should carry all of them as equal-cost next hops so that a single link loss is a silent ECMP adjustment rather than a BGP event. This is where the per-packet load-balancing policy from the spine configuration earns its keep: VXLAN adds a 50-byte outer header, and if the PFE hashes only on the outer header every flow between two VTEPs can land on the same member link and saturate it while the rest sit idle. Hashing on the inner frame keeps the fabric balanced.

Failure domains should also be explicit. A spine failure in a two-spine CRB fabric halves the routing capacity, so the design assumes both spines are separate failure domains with independent power and management. On the leaf side, each server should dual-home to two leaves and use ESI-LAG so that a leaf failure moves the bond without the server noticing; the EVPN ESI route target and LACP system ID must agree across both leaves or the bond will flap rather than fail cleanly.

Scaling the Fabric Beyond Four Leaves

The reference design uses two spines and four leaves, but the same building blocks scale out by adding leaves and keeping the underlay full-mesh at the spine layer. What changes as the fabric grows is the BUM replication cost and the EVPN routing table. With ingress replication, each VTEP's flood list grows with the number of remote VTEPs, so past roughly a dozen racks the per-VTEP replication load becomes the limiting factor and the design usually switches to multicast in the underlay or introduces a second tier. The EVPN table also grows with the number of MAC addresses, not the number of devices, which is why host route scale — not device count — is the number to quote when someone asks how large the fabric can get.

Verification

show route table serverBD.inet.0          # IRB routes present?
show evpn vxlan tunnel                   # VTEP tunnels established
show bgp summary                         # EVPN neighbors up
show evpn instance extensive
show ethernet-switching table
show arp no-resolve
ping 10.101.0.2 routing-instance serverBD count 5

The sample outputs show the IRB interface routes for all three VLANs in the routing instances and successful ping tests between servers in different VLANs. When something does break, work outward from the fabric: confirm the two VTEPs can ping each other's loopbacks, confirm the EVPN session advertises the MAC, then confirm the ARP entry is present in the right VNI. Each step isolates a layer.

Common Pitfalls and Design Trade-offs

• Mismatched VNI or route target between leaf and spine — the tunnel is up but traffic never arrives.
• VTEP source on a re-usable interface that can flap, tearing down all tunnels.
• Assuming ERB and CRB configurations are interchangeable; moving the IRB changes where routing happens and how flooding is scoped.
• Ignoring the MTU cost of encapsulation; VXLAN adds 50 bytes, so the underlay must carry jumbo frames or the server MTU must be reduced.
• Under-provisioning BUM replication when the fabric grows past a few racks.

For design context, compare with our VXLAN MP-BGP EVPN design guide, the HPE Aruba EVPN-VXLAN Fabric Composer article, and 400G spine / 100G leaf link consistency. Before you commit any fabric, read our VXLAN MTU and fragmentation guide and the Juniper EVPN ESI-LAG multihoming guide for the multi-homed server case.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/evpn/topics/example/evpn-vxlan-irb-within-data-center.html