EVPN Multihoming - Non-Fabric

Supported hardware

Platform	Supported hardware models or family	Minimum Software
Catalyst 9300X	All Catalyst 9300X models	Cisco IOS XE 17.18.5
Catalyst 9300	All Catalyst 9300 models	Cisco IOS XE 17.18.5
Catalyst 9300L	All Catalyst 9300L models	Cisco IOS XE 17.18.5
MS390	MS390 family	Cisco IOS XE 17.18.5
Catalyst 9500 High Performance	Catalyst 9500-24Y4C, 9500-48Y4C, and 9500-32C	Cisco IOS XE 17.18.5

Catalyst 9500X is a different platform family and is not included in this support list.

Supported software

EVPN Multi-Homing is generally available (GA) with Cisco IOS XE 17.18.5. Confirm the supported software release and Dashboard eligibility of both members before deployment.

Deployment and upgrade recommendations

Use matching switch platforms and supported Cisco IOS XE releases where possible. Matching the peers provides consistent capabilities and behavior, although identical hardware and software are not mandatory for every supported pairing.

During a staged upgrade, one member can remain in service while the other is upgraded and restarted. Different supported software versions may coexist temporarily during that change. Return both members to the same recommended release after the upgrade and validate platform and release compatibility before starting.

Before creating the pair, confirm Dashboard connectivity, available Loopback /32 addresses, a /31 or /30 inter-ES subnet, and at least two compatible inter-ES interfaces per member. Size the inter-ES connection for traffic redirected during a failure. Identify the management VLAN, required service VLANs, gateway placement, DHCP relay, and downstream port settings.

Configuration overwrite warning: Saving the workflow applies configuration immediately. Dashboard replaces the configuration of physical interfaces selected for a new routed inter-ES port-channel. Record their current settings and confirm cabling before saving. For an eligible existing port-channel, verify its members, addressing, and operational state.

Workflow scope

Item	Working assumption
Starting state	Two standalone Distribution switches with an established traditional upstream network.
Downstream device	A Layer 2 Access switch with G1/0/1 connected to Distribution-5 and G1/0/2 connected to Distribution-6.
Dashboard path	VLAN 3 carries management traffic; its gateway initially resides on Distribution-5.
Target state	A non-fabric EVPN-MH pair with a downstream port-channel spanning both Distribution switches.
Continuity objective	Preserve the management path through Distribution-5 while the second path is prepared. A brief interruption can occur while the Access-side and Distribution-side aggregates are completed.

The diagrams distinguish the downstream Layer 2 links from the routed Layer 3 inter-ES connection. Upstream connections represent the existing network, whose routing and gateway placement must be considered during the conversion.

Step	Topology state	Primary action	Continuity check
1	Standalone Distribution switches	Establish the current VLAN 3 gateway and management path.	The Access switch reaches Dashboard through Distribution-5.
2	Access switch temporarily single-homed	Disable the Distribution-6 Access-facing interface.	Management and required forwarding remain available through Distribution-5.
3	EVPN-MH peer configuration deployed	Create and save the non-fabric pair.	Inter-ES connectivity and direct BGP EVPN peering are operational.
4	Gateways and aggregates prepared	Prepare the gateway design, VLANs, and both sides of the port-channel.	Keep the second path disabled until the configuration is consistent.
5	Dual-homed target state	Enable the Distribution-6 interface and verify the completed bundle.	Management and service traffic forward through the intended VLANs.

Step 1 Establish the traditional Layer 2 state

Confirm that both Distribution switches and the Access switch are online in Dashboard before changing the topology. In this example, the Access switch reaches Dashboard through VLAN 3 and the gateway on Distribution-5. DHCP relay is already configured there, and the two Access uplinks are not yet one distributed port-channel.

Verify the following:

• The two Distribution switches are available for EVPN-MH pair creation.

• Access interface G1/0/1 connects to Distribution-5 and G1/0/2 connects to Distribution-6.

• VLAN 3 provides the Access switch management path and is allowed on the relevant interfaces.

• The current VLAN 3 gateway, DHCP relay, and upstream routing work correctly.

• The existing Layer 2 topology is loop-free and the intended Distribution-5 path forwards traffic.

• The interfaces reserved for the inter-ES connection can be converted and bundled into a routed port-channel.

Step 2 Disable redundant Distribution Access path

Administratively disable the Distribution-6 interface facing the Access switch. Keep the Access-switch interface and Distribution-5 interface enabled. This leaves one working path while the peer configuration, gateways, and aggregates are prepared.

Confirm that the Access switch retains its management address, reaches Dashboard, and can reach required downstream and upstream services through Distribution-5. If the remaining path is unstable, stop the conversion and restore the previous working configuration.

For multiple Access switches, isolate each relevant Distribution-6 Access-facing interface in this preparation step. Complete and verify each downstream bundle before re-enabling its second path.

Step 3 Create the EVPN Multi-Homing pair

Navigate to Switching > Configure > EVPN Multi-Homing and create the non-fabric EVPN-MH pair. Enter a recognizable pair name and select exactly two eligible switches or stacks as members.

The Dashboard screenshots use the example device names Leaf-5 and Leaf-6. These correspond to Distribution-5 and Distribution-6 in this non-fabric procedure; the names are device labels.

Configure the EVPN-MH peer settings

Review the addresses, VLANs, and interfaces for both members before saving.

Dashboard field	What to enter	Important note
BGP ASN	The autonomous system number used by both EVPN-MH members.	Used for the direct BGP EVPN peer relationship.
Allowed Multihomed VLANs	The management and service VLANs that require EVPN-MH on the pair, including VLAN 3 in this example.	Enables EVPN treatment for the selected VLANs on both members. Also allow these VLANs on the downstream port-channels.
Loopback interface	An existing or new Loopback interface on each member.	Loopback100 cannot be selected in this workflow.
Loopback IP address	A unique /32 IPv4 address for each member.	The direct BGP EVPN session uses these peer addresses.
EVPN-MH Port-Channel	At least two compatible inter-ES interfaces on each member, or an eligible existing port-channel.	These interfaces provide the routed connection between the members.
Inter-ES IP addresses	One address per member from the same /31 or /30 subnet.	Dashboard enables OSPF on the routed inter-ES link.

The addressing example uses Loopback99 with 10.1.99.1/32 and 10.1.99.2/32, and inter-ES addresses 29.29.29.0/31 and 29.29.29.1/31. Replace these sample values with the addressing plan for the deployment.

Save and verify the applied configuration

Saving the non-fabric workflow immediately creates and pushes the EVPN-MH configuration to both switches. Monitor configuration status until both members have applied the changes. Keep the Distribution-6 Access-facing interface disabled.

Verify the routed inter-ES port-channel, OSPF adjacency, reachability to the peer Loopback, and direct BGP EVPN session before continuing. If either member has not applied the configuration or the peer relationship is down, resolve that condition before converting the Access connection.

Step 4 Prepare the gateway and aggregate links

Prepare the required management and service VLANs on the pair. Confirm that they are included in Allowed Multihomed VLANs and that the downstream trunk configuration carries them. Preserve VLAN 3 throughout the change.

For the illustrated design, the pair hosts the VLAN 3 gateway. After the EVPN-MH peer configuration is operational, prepare Distribution-6 with the same shared gateway IP and EVPN anycast-gateway treatment as Distribution-5. Match the gateway MAC behavior and DHCP relay destinations required by the EVPN-MH design. Verify upstream reachability and DHCP server access before enabling the second path.

The shared gateway address is the default gateway for attached devices. It is not a unique management address for each Distribution switch. Simply configuring a duplicate IP on an ordinary SVI is insufficient; use the supported EVPN anycast-gateway configuration. Do not combine an anycast-gateway SVI with FHRP such as HSRP or VRRP.

If the deployment keeps its gateways on external devices, retain that gateway placement and verify the Layer 2 path to those gateways. Apply the existing upstream routing design; enable or adjust SVI route advertisement only where that design requires it.

• Verify the management and service VLANs on both members.

• Prepare locally hosted shared gateways where required by the design.

• Match DHCP relay and validate the return path.

• Keep the Distribution-6 Access-facing interface disabled until both aggregates are ready.

Create downstream port-channels

Workflow boundary: Configure downstream port-channels separately under Switching > Switch ports after the EVPN-MH pair is operational.

1. Filter by the Access switch name and select the two uplink interfaces connected to the pair.

2. Select Aggregate to create the Access-side port-channel.

3. Select both EVPN-MH members and their corresponding Access-facing interfaces.

4. Select Aggregate to create the distributed port-channel across the pair.

5. Match LACP, interface speed, port type, native VLAN, and allowed VLANs on all participating interfaces.

6. Allow VLAN 3 and the required service VLANs on both sides of the aggregate. Keep the Distribution-6 Access-facing interface disabled until the settings are consistent.

The Access switch may temporarily lose its in-band Dashboard connection after the Access-side port-channel is created and before the Distribution-side aggregate is complete. Complete the corresponding aggregate and verify that VLAN 3 is permitted before re-enabling the second path. A working management path during the preparation steps does not guarantee uninterrupted connectivity during aggregation.

Step 5 Enable the second Access path

Enable the previously disabled Distribution-6 interface. Confirm that the Access switch forms one complete port-channel with member links to both Distribution switches.

• Verify that Access interface G1/0/2 is enabled and remains in the aggregate.

• Confirm that both Access uplinks are bundled and forwarding according to the port-channel state.

• Confirm that the corresponding aggregate is operational on both Distribution switches.

• Check that VLAN 3 and the required service VLANs are allowed consistently.

• Verify the Access switch's Dashboard connection, client gateway reachability, DHCP operation, and upstream forwarding.

Workflow overview

1. Verify that the Access switch reaches Dashboard through its dedicated management network.

2. Create the non-fabric pair and configure the BGP ASN, Allowed Multihomed VLANs, Loopbacks, and inter-ES port-channel.

3. Save the workflow. Dashboard immediately pushes the peer configuration to both members.

4. Verify the inter-ES connection and direct BGP EVPN session.

5. Prepare management and service gateways where hosted on the pair, then create the downstream port-channels.

6. Confirm that both uplinks are bundled and that all required data VLANs are configured consistently.

7. Verify endpoint forwarding and continued management reachability through the Out-Of-Band network.

Verify Dashboard state

• Both members are online and shown as the intended EVPN-MH pair.

• Configuration has been applied successfully to both members.

• The downstream aggregate is operational on the Access switch and both Distribution switches.

• The Access switch remains reachable using its intended in-band or Out-Of-Band management path.

• The required management and service VLANs are included in the EVPN-MH configuration and allowed on the appropriate trunks.

Verify BGP EVPN Peerings

Each member should establish a direct BGP EVPN session with the other member using the configured Loopback addresses. Check the routed inter-ES link and peer reachability before investigating EVPN state.

show ip ospf neighbor
show ip route <peer-loopback-address>
show bgp l2vpn evpn summary
show etherchannel summary
show l2vpn evpn multihoming core-tracking

Confirm that the peer session is established and the Ethernet Segment-facing interfaces are not disabled by a core-isolation condition. Resolve missing adjacencies, missing routes, or a non-established peer session before accepting the deployment.

Verify client learning and forwarding

Use a known endpoint behind the dual-homed Access switch. Confirm reachability to its default gateway and the upstream network, then check its MAC and IP information on both members.

The illustrative endpoint uses IP address 192.0.2.210, MAC address 0011.2233.4455, VLAN 1101, EVI 1101, and downstream port-channel Po2. These values are examples. EVI and VLAN identifiers are not necessarily identical in every deployment.

Verify local learning on Distribution-5 and Distribution-6

Run the applicable commands on both members, replacing the example identifiers:

show l2vpn evpn mac ip evi 1101
show l2vpn evpn evi 1101 detail
show l2vpn evpn ethernet-segment
show l2vpn evpn ethernet-segment forwarder
show mac address-table vlan 1101
show ip arp
show vlan id 1101
show etherchannel summary

Check the endpoint in the EVPN MAC/IP table and confirm that its MAC address, VLAN, EVI, and IP binding, when learned, match the intended service. The endpoint's local attachment or synchronized peer reachability should be consistent with the downstream Ethernet Segment and Po2.

The ordinary dynamic MAC and ARP tables can reflect local data-plane learning differently on each member. Do not require those tables to be identical as proof of synchronization; use the EVPN MAC/IP information to evaluate synchronized reachability.

Verify that the Ethernet Segment operates in all-active mode with the expected forwarders. A designated-forwarder role can prevent duplicate broadcast, unknown-unicast, and multicast (BUM) traffic on one member. This behavior does not by itself indicate a failure of active/active unicast forwarding.

What the checks confirm

1. The endpoint belongs to the expected VLAN and EVI.

2. The same endpoint identity is represented consistently in the EVPN state on both members.

3. Its attachment and peer synchronization correspond to the intended downstream port-channel.

4. The Ethernet Segment and aggregate are operational across the pair.

5. The endpoint reaches the correct gateway and upstream network.

Control-plane state alone does not prove resilience. Complete the forwarding tests below before accepting the deployment.

Expected verification results

• The pair is online and the peer configuration is applied on both members.

• The inter-ES aggregate, OSPF adjacency, and direct BGP EVPN session are operational.

• The downstream port-channel includes the intended interfaces on the Access switch and both members.

• Required VLANs are present and consistently allowed, including the management VLAN where applicable.

• EVPN endpoint state and gateway reachability agree with the intended design.

• The Access switch retains or regains its expected Dashboard path after the conversion.

• Traffic continues through the surviving path during the supported failure tests.

If only one Distribution switch learns the endpoint

Distinguish local data-plane learning from synchronized EVPN reachability. If the expected endpoint state is absent on one member, verify:

• Both Access uplinks belong to the port-channel and are enabled.

• The corresponding Distribution interfaces belong to the intended aggregate.

• The previously isolated Distribution-6 interface is enabled.

• The service VLAN is in Allowed Multihomed VLANs and permitted on each participating trunk.

• VLAN 3 remains allowed when it carries the Access switch management path.

• Layer 2, LACP, native VLAN, and allowed-VLAN settings agree across the bundle.

• Both members have applied the peer configuration and the direct BGP EVPN session is established.

• The endpoint is connected to the expected Access port and is generating traffic.

Validate resiliency

During the planned maintenance window, test a single downstream-link failure, failure of one physical inter-ES member link, and failure or reload of one EVPN-MH member. Test one condition at a time and confirm recovery before proceeding.

Observe client forwarding, gateway reachability, the Access switch's management path, and the peer and aggregate states. Restore each failed component and verify that the configuration returns to its expected operational state.