HPE Aruba DC Fabric: EVPN-VXLAN with Fabric Composer

Building a data center fabric by hand is error-prone: underlay addressing, overlay VNI planning, VSX pairs, and BGP route reflectors all have to line up perfectly. HPE Aruba Networking's Fabric Composer automates most of that work through a guided setup process that provisions the routed underlay, the EVPN-VXLAN overlay, and VMware vCenter integration in one flow. Based on the official HPE Aruba Validated Solution Guide, this article explains the key design decisions — naming conventions, address blocks, VTEP loopbacks, and VNI numbering — plus the end-to-end configuration sequence you need to understand even when the wizard does the typing.

Physical Topology and Fabric Roles

The validated design uses spine and leaf switches: leaves act as the VXLAN Tunnel Endpoints (VTEPs), spines provide underlay transit and run BGP route reflectors for the overlay. Server access switches connect as VSF stacks below the leaf pair. A clear naming convention that encodes type, role, and location — for example RSVDC-FB1-SP1 (Spine 1) and RSVDC-FB1-LF1-1 (Leaf pair 1, member 1) — simplifies operation at production scale.

Fabric Composer Prerequisites

The guided setup is only as good as what it is allowed to touch. Work through this list before starting the wizard, because every item you skip becomes an error message halfway through provisioning.

• Switches installed and cabled. Spine-to-leaf and leaf-to-server cabling must match the design, including the split-port breakout cabling if 40G/100G ports are broken out into 4x10G/4x25G. Fabric Composer discovers switch topology from LLDP, so a missing link shows up as a missing port.
• A clean AOS-CX baseline on every switch. Out-of-band management addressing, a reachable default gateway, DNS and NTP should already be in place. If you are starting from factory defaults, the AOS-CX initial configuration guide covers exactly those steps.
• Credentials with full administrative rights on the switches, plus SNMP and REST access, because Fabric Composer provisions the switches programmatically rather than through the console.
• Platform support and licensing. Only supported AOS-CX platforms can join the fabric, and EVPN-VXLAN functionality generally requires the appropriate switch licence. Confirm your model against the validated design's supported-platform list before ordering hardware.
• Accurate time. BGP, certificate validation and logging all depend on consistent clocks. NTP is configured by the wizard, but the management path must already let the switches reach the time source.
• Reserved address blocks. Underlay point-to-point links, loopbacks, VSX transit and keepalive links, and VTEP addresses — all allocated as one coherent plan before the first switch is assigned.
• A VMware vCenter account if you plan to use the integration (host onboarding, VM-to-switch visibility). The integration is optional but changes how host ports are provisioned.

One more prerequisite that is organisational rather than technical: agree the naming convention up front. Fabric Composer derives hostnames, descriptions and profiles from switch names, and renaming a switch after it joins the fabric is far more disruptive than getting the name right on day one.

Underlay and Overlay Addressing

Fabric Composer allocates addresses automatically from network ranges you provide:

• Leaf-spine links: a /24 block from which /31 point-to-point L3 links are carved (example 10.255.0.0/23).
• Loopback / VSX transit / keepalive: unique /32 loopbacks per switch plus /31 transit and keep-alive links (example 10.250.0.0/23).
• VTEP addresses: a single /32 loopback common to both ToR peers in a VSX pair, defining one logical VTEP per rack (example 10.250.2.0/24).

VNI Numbering Scheme

Plan VNI values before the wizard runs so they never overlap:

• L2 VNI = VLAN ID + 10000 (VLAN 100 → L2 VNI 10100).
• L3 VNI = overlay number + 100000 (Overlay 1 → L3 VNI 100001).

Each L3 VNI maps to a VRF; each L2 VNI maps to a VLAN ID. iBGP carries the EVPN address family between leaves, with two spines acting as route reflectors and all leaves as clients.

MAC Address Best Practices

Use a Locally Administered Address (LAA) — x2/x6/xA/xE-xx-xx-xx-xx-xx — for the switch virtual MAC, VSX system MAC, or Active Gateway MAC. Reuse the same Active Gateway MAC for every Active Gateway IP assignment, since only a small number of unique virtual MACs can be configured per switch.

VSX Design for the Leaf Pair

Each rack's top-of-rack leaf pair is designed as a single logical device, and this is where most of the operational complexity in an Aruba EVPN fabric lives. The components to understand:

• ISL (inter-switch link). A LAG carrying VSX control traffic, synchronised state, and any traffic that must traverse the peer. On high-capacity platforms you dedicate 100G ports to it; sharing the ISL with production data is possible but makes failure analysis harder.
• Keepalive path. A small routed link (typically through the management network or a direct L3 path) used for heartbeat when the ISL fails. Without it, a broken ISL produces a split-brain in which both members believe they are primary — and in a VXLAN fabric a split-brain means duplicate VTEPs and unpredictable forwarding.
• VSX system MAC and role priority. A shared system MAC makes the pair look like one device to LACP and spanning tree; role priorities decide who becomes primary and keeps behaviour deterministic across a reload.
• Active Gateway. A virtual gateway MAC and IP shared by both members gives hosts an active/active default gateway with sub-second failover, and it is the same virtual MAC that should be reused for every Active Gateway assignment on the pair.
• One logical VTEP per rack. Both members announce the same VTEP loopback address, which is what keeps remote leaves from caring which member a host is attached to.

Because the failure modes are subtle, treat VSX health as a first-class monitored condition — our VSX split-brain, ISL and keepalive recovery guide covers the diagnostics and the recovery order, and the VSX configuration guide walks through the underlying CLI if you need to build or audit one by hand.

Route Reflectors and the iBGP Overlay

EVPN uses MP-BGP, and BGP does not accept a route learned from one iBGP peer and re-advertised to another without a helper — hence the full mesh, or a route reflector. Fabric Composer's validated design places both spines in the route-reflector role and every leaf as a client, which removes the n-squared session problem entirely: a leaf peers only with the two spines, yet learns routes from every other leaf.

Design points that matter:

• Two reflectors, not one. A single spine as a reflector means an outage of that switch partitions overlay reachability across the whole fabric. Two spines give redundancy even though only one active path is used per prefix.
• Deterministic reflector identification. Reflector IDs are usually derived from loopback addresses. In multi-fabric or merge scenarios, cluster IDs may need to be set explicitly so that route handling stays predictable — see BGP route reflector cluster-id configuration.
• AFI/SAFI activation. The L2VPN EVPN address family is peer-specific. Missing activation on a single session produces a leaf that distributes its own VNIs but learns nobody else's — a symptom that looks like a data-plane problem but is purely a control-plane omission.
• Fast convergence. BFD on the fabric-facing links, tuned OSPF timers and graceful restart all shorten the window in which forwarding and the control plane disagree. Underlay routing itself is OSPF in the validated design, which is simple, well understood and easy to verify with show ip ospf neighbors.

If you are coming from another vendor, the concepts are identical but the knob placement differs; the Cisco Nexus 9000 VXLAN BGP EVPN design guide and Junos EVPN-VXLAN CRB walkthrough make useful comparison reading, and the fabric-layer decision itself is covered in leaf-spine versus traditional three-tier.

Guided Setup Sequence

Fabric Composer's guided setup follows this order: switch discovery → fabric creation → switch assignment → switch profiles and split ports → NTP/DNS → VSX configuration on ToR leaf pairs → leaf/spine IP assignment → OSPF underlay → iBGP overlay → EVPN mapping of VLANs to VNIs. After the wizard, you still configure host onboarding, MC-LAG for hosts, border leaf routing, PIM-SM/IGMP for overlay multicast, and testing loopbacks.

What the Wizard Is Actually Doing

It is worth knowing the intent behind each guided step, because when something fails you will be reading the resulting configuration rather than the wizard.

• Switch discovery and fabric creation. The switches are discovered by IP range and LLDP adjacency, and the fabric object groups them.
• Switch assignment and profiles. Each switch gets a role (spine, leaf, border leaf) and a profile that determines the baseline features — LLDP, loopback, multicast, storm control, spanning tree.
• Split ports. High-speed ports are broken out into logical interfaces before addressing is assigned, so the address plan must already account for the larger port count.
• NTP and DNS for the fabric. Applied consistently to every member so timestamps and names agree.
• VSX on the ToR leaf pairs. ISL, keepalive, system MAC, role priority and Active Gateway are provisioned as a unit.
• Leaf and spine IP assignment. Point-to-point /31 links from the underlay block, plus /32 loopbacks for router IDs and VTEPs.
• OSPF underlay. The routed fabric links are brought up with OSPF, providing loopback reachability across the fabric.
• iBGP overlay. Sessions are established to the route reflectors with the EVPN address family activated.
• EVPN overlay mapping. VLANs are mapped to L2 VNIs and VRFs to L3 VNIs, and the corresponding EVPN instances are created on the leaf pair.

Steps that remain manual afterwards are deliberate: host onboarding, MC-LAG for dual-attached hosts, border leaf routing toward the core or WAN, and multicast (PIM-SM plus IGMP) where the workload requires overlay multicast. Treat the wizard as the underlay and overlay factory, not as a full configuration management system.

Host Onboarding After the Wizard

Once the overlay exists, the recurring work is getting servers attached correctly. Two patterns dominate:

• Single-attached host. The switch port is configured as an access port in the server VLAN, and the VLAN is already mapped to an L2 VNI by the wizard, so the host simply appears in the overlay. Nothing else is required on the fabric.
• Dual-attached host (MC-LAG on the leaf pair). The server bonds its two NICs to the pair. The LAG is provisioned on both VSX members with matching settings, and because both members share a system MAC the server sees a single LACP partner. Match the server-side bonding mode (LACP active) and MTU before troubleshooting anything on the fabric.

The classic host-onboarding mistake is MTU. The underlay must carry a 50-byte-larger frame than the server's largest payload, so fabric links are set to jumbo (typically 9000) while server ports may be 1500. Get that wrong and small pings succeed while backups and live migrations hang. The mechanics are covered in VXLAN MTU and fragmentation.

Verifying the Fabric from the CLI

Fabric Composer reports success, but the operational truth is on the switches. Run these from any leaf:

leaf# show lldp neighbor-info
leaf# show vsx status
leaf# show ip ospf neighbors
leaf# show bgp l2vpn evpn summary
leaf# show evpn evi
leaf# show vxlan vtep
leaf# show vxlan address-table
leaf# show interface vxlan1

Read them as a chain: LLDP proves the cabling matches the design; VSX status proves the leaf pair is healthy with a valid ISL and keepalive; OSPF neighbours prove underlay reachability to both spines; the BGP summary proves the EVPN address family is established with routes exchanged; show evpn evi proves VLANs are mapped to VNIs; and show vxlan vtep plus show vxlan address-table prove that remote MACs are actually being learned through the tunnel. If the first four are good and the last two are empty, the problem is host-side or VLAN-to-VNI mapping, not the fabric.

A quick end-to-end test that exercises the whole stack: place two hosts in the same VLAN on different leaf pairs and ping between them, then check that each leaf learned the other's MAC with the peer's VTEP address as the next hop. Then move to a different VLAN on the same pair — a failure there is an L2 VNI mapping problem rather than a tunnel problem.

Day-2 Operations and Configuration Drift

Automation solves the deployment day and creates a new problem: the fabric's intended state lives in the tool while reality lives on the switches. Someone pastes an ACL into a leaf at 2 a.m. during an incident, and the next time the profile is pushed the change either survives silently or is overwritten.

• Back up before and after every change. Configuration backup tooling should be in place from day one — the patterns in Oxidized network configuration backup apply directly to AOS-CX fabrics.
• Treat profiles as the source of truth. Anything you need permanently belongs in the profile; anything you do by hand is temporary and will be lost at the next push. Record that decision in the change ticket.
• Monitor the failure modes that matter. VSX role changes, ISL flaps, BGP session resets, and VTEP reachability. The scripting approach in the ArubaOS-CX NAE guide can watch the relevant counters and raise alerts before a user notices.
• Plan for growth with reserved space. VNIs, VTEP /32s and the underlay /31 range should all have headroom, because renumbering a VNI in production means touching every switch that carries it.
• Document the naming and numbering scheme. New engineers read the fabric through names and numbers; a scheme that exists only in someone's head does not scale past two racks.

Troubleshooting Fabric Deployment

• A switch is not discovered. Check reachability from the Fabric Composer appliance (ping and port 443), confirm the credentials, and verify the switch is a supported model with a supported software release. LLDP must be enabled if topology-based discovery is used.
• The wizard fails partway with an IP conflict. Two address blocks were reserved for the same purpose, or an existing loopback reuses an address from the underlay range. Audit the plan; the fix is almost always re-allocation, not a retry.
• VSX does not form. The most common causes are a member port in the ISL LAG that is administratively down, a keepalive path that is not routed, and mismatched VSX settings on the two members. show vsx status on both members and compare the ISL and keepalive columns side by side.
• EVPN routes are missing on one leaf. Compare show bgp l2vpn evpn summary across leaves. A single session in a non-established state usually means an AFI/SAFI activation or an underlay reachability problem rather than an overlay one.
• Remote hosts are unreachable but each side sees its local host. This is a VTEP or VNI mapping problem: confirm both pairs announce the expected VTEP loopback and that the VLAN-to-VNI mapping matches on both ends.
• Large transfers hang while pings work. MTU. Confirm jumbo frames on all fabric links and on the host NICs, then verify with a large, DF-bit-set ping across the overlay.
• Hosts on a dual-attached server get duplicate or unstable connectivity. LACP mode or MTU mismatch between the server bond and the leaf pair — the same class of problem described in EVPN multihoming versus MLAG, where the DF election and ESI concepts explain why the design choice matters.

FAQ

Do I have to use Fabric Composer, or can I build the fabric by hand? You can build it by hand; nothing in EVPN-VXLAN requires the tool. The tool's value is consistency and speed at scale — hand-built fabrics drift between racks within months.

Is OSPF underlay mandatory? No, but it is the validated default for the reference design. eBGP or IS-IS underlays also work, with different convergence characteristics and more configuration to maintain.

Can I mix switch models in one fabric? Yes, within the same supported platform and release family. Keep the leaf pairs homogeneous — asymmetric pairs complicate both VSX and capacity planning.

How many VNIs can a leaf carry? Platform-dependent, typically in the hundreds to low thousands, but the practical limit is usually how many you can operate rather than what the ASIC supports.

Do I need multicast in the overlay? Only if workloads require it. Unicast replication is fine for smaller fabrics; multicast (PIM-SM plus IGMP) is the standard answer as broadcast and BUM traffic grows.

How do I extend the fabric to a second site? That is a multi-fabric or multi-site design with border gateways rather than a single stretched VSX domain — see VXLAN EVPN multi-site border gateway design.

What about spanning tree in the fabric? The fabric is routed and loop-free by design, so spanning tree becomes a host-edge concern: enable BPDU guard and loop protection on server ports rather than relying on STP for fabric resilience.

If you are comparing implementations, see our VXLAN with MP-BGP EVPN design and configuration guide, the 400G spine / 100G leaf link consistency article, and for the multi-chassis side of leaf pairs the Arista EOS MLAG explainer. For the host-side network underneath the fabric, the Proxmox VE VLAN-aware bridge and LACP bond guide shows how server bonds and VLAN tagging are configured on the hypervisor.

原文链接：https://arubanetworking.hpe.com/techdocs/VSG/docs/050-dc-deploy/esp-dc-deploy-120-fabric-deploy/