Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?



Verification of the Campus Fabric Core Distribution CRB deployment. See Figure 1 . Currently, there are two desktops to validate the fabric. Let’s take a quick look to see if Desktop1 can connect internally and externally.

Text Description automatically generated

Validation steps:

  • Confirmed local IP address, vlan and default gateway were configured on Desktop1.
  • Can ping default gateway – indicates that we can reach access switch.
  • Ping to WAN router failed ( – we need to troubleshoot.

Start by validating campus fabric in the Mist UI, by selecting the Campus Fabric option under the Organization tab on the left-hand side of the UI.

Remote shell access into each device within the campus fabric is supported here as well as visual representation of the following capabilities:

  • BGP peering establishment
  • Transmit/receive traffic on a link-by-link basis
  • Telemetry, such as lldp, from each device that verifies the physical build

BGP Underlay Purpose

Verifying the state of eBGP between core and distribution layers is essential for EVPN VXLAN to operate as expected. This network of point-to-point links between each layer supports:

  • Load balancing using ECMP for greater resiliency and bandwidth efficiencies.
  • bfd, bi-directional forwarding, to decrease convergence times during failures.
  • Loopback reachability to support VXLAN tunneling.

Without requiring verification at each layer, the focus can be on Dist1/2 and their eBGP relationships with Core1/2. If both distribution switches have “established” eBGP peering sessions with both core switches, you can move to the next phase of verification.


Verify that BGP sessions are established from core devices with distribution devices to ensure loopback reachability, bfd session status, and load-balancing using ECMP.


Operational data can be gathered through the Campus Fabric section of the Mist UI or using an external application such as SecureCRT or Putty.

Verification of BGP Peering


Access Remote Shell via the bottom right of the campus fabric, from the switch view or via Secure Shell (SSH).

Text Description automatically generated

From the BGP summary, we can see that the underlay (10.255.240.X) peer relationships are established indicates that the underlay links are attached to the correct devices and the links are up.

It also shows the overlay (192.168.255.x) relationships are established and that it is peering at the correct loopback addresses. This demonstrates loopback reachability.

We can also see routes received; time established are roughly equal which looks good so far.

If BGP is not established then go back and validate the underlay links and addressing, and that the loopback addresses are correct. Loopback addresses should be pingable from other loopback addresses.

Verification of BGP connections can be performed on any of the other switches (not shown).

The primary goal of eBGP in the underlay is to provide loopback reachability between core and distribution devices in the campus fabric. This loopback is used to terminate VXLAN tunnels between devices. The following shows loopback reachability from Dist1 to all devices in the campus fabric:

Text Description automatically generated


eBGP sessions are established between Core-Distribution layers in the campus fabric. Loopback reachability has also been verified between core and distribution devices.

Let’s verify the routes are established to the to the core and other devices across multiple paths. For example, Dist1 should leverage both paths through Core1/2 to reach Dist2 and vice versa.

Dist1: ECMP Loopback reachability to Dist2 through Core1/2

Text Description automatically generated

Dist2: ECMP Loopback reachability with Dist1 through Core1/2

Text Description automatically generated

This can be repeated for Core1/2 to verify ECMP load balancing.

Finally, we validate BFD for fast converge in the case of a link or device failure:

Text Description automatically generated

Meaning: At this point, BGP underlay and overlay are operational through the verification of eBGP between corresponding layers of the campus fabric and that loopback routes are established between core and distribution layers.

EVPN VXLAN Verification Between Core and Distribution Switches

Since the desktop can ping its default gateway, we can assume the Ethernet-switching tables are correctly populated, vlan and interface-mode are correct. If pinging the default gateway failed, then troubleshoot underlay connectivity.

Verification of the EVPN Database on Both Core Switches


A picture containing graphical user interface Description automatically generated


Graphical user interface Description automatically generated

Both core switches have identical EVPN databases which is expected. Notice the entries for desktop1 ( and desktop2 ( present in each core switch. These entries are learned through the campus fabric from the ESI LAGs off DIst1/2. is associated with irb.1099 and we see VNI of 11099. Let's just double check VLAN-VNI mapping on the distribution and core switches and verify the presence of L3 on the core.



Text Description automatically generated

Verification of VXLAN Tunneling Between Distribution and Core Switches


Text Description automatically generated


Text Description automatically generated

Finally, let us validate that Core1 is receiving Desktop 1’s MAC address through MP-BGP via Type2 EVPN routes.

Text Description automatically generated


The EVPN database is confirmed on both Core1/2 and VXLAN tunnels are established between distribution and core switches. We have also verified Desktop1/2 are present in Core1/2’s EVPN database.

We next verify if Desktop1’s MAC address is mapped to the correct VTEP interface on Core1:

Text Description automatically generated

Notice Desktop1’s MAC address (52:54:00:74:a0:6f) is learned through both Dist1/2 switches.

Text Description automatically generated

Now, we verify if the Core has Desktop1 and Desktop 2’s MAC and ARP entries:

Graphical user interface Description automatically generated with medium confidence

From an EVPN-VLAN perspective everything is correct. This includes the fact that both Desktop addresses are present once again verifying campus fabric connectivity. Maybe we are looking in the wrong place. Let's look at the connection between core and WAN router.

External Campus Fabric Connectivity Through the Border GW Core EX9204 Switches

Remember that you chose to deploy the Border GW capability on the EX9204 switches during the Campus Fabric Core-Distribution deployment, represented below:

Diagram Description automatically generated

Mist enables the EX9204 to translate between VXLAN traffic within the campus fabric and standard Ethernet switching for external connectivity, in this case a SRX Series Firewalls. Let’s verify the Ethernet Segment Identifier (ESI) status on the core switches.

We must configure the ESI-LAG and Mist does not configure this automatically. Add a Port profile on core switches interfaces facing the WAN router.

The following represents an existing Port Profile applied to each SRX Series Firewalls facing EX9204 port:

Graphical user interface, text, application Description automatically generated

Save the configuration and then verify the changes on the core switch.

Text Description automatically generated

Note that LACP is up, and this infers there is an existing configuration on the SRX Series Firewalls.

A picture containing graphical user interface Description automatically generated

Then confirm the EVPN database now has the ESI entry. Back to Desktop1 to see if it can cross the fabric.

Text Description automatically generated

Last step is to verify desktop1 can ping desktop2.

Text Description automatically generated

Meaning: Connectivity within the campus fabric and externally have been verified. Desktops communicate with each other through the campus fabric, each in an isolated VRF, then forwarded to the SRX Series Firewalls through the dual homing ESI-LAG on both Core1/2 for routing between VRFs or routing instances. Internet connectivity was also verified from each Desktop.

EVPN Insights

Mist Wired Assurance provides you with real-time status related to the health of the Campus Fabric Core Distribution CRB deployment using telemetry such as BGP neighbor status and TX/RX port statistics. The following screenshots are taken from the Campus Fabric Core Distribution CRB build by accessing the Campus Fabric option under the Organization/Wired of the Mist Portal:

Graphical user interface, application, table Description automatically generated

Graphical user interface, application Description automatically generated

From this view, Mist also provides remote accessibility into each device’s console through the Remote Shell option as well as rich telemetry through the Switch Insights option. Remote Shell has been demonstrated throughout this document when displaying real-time operational status of each device during the verification stage.

Switch Insights of Dist1 displays historical telemetry including BGP peering status critical to the health of the campus fabric:

Graphical user interface, application, table Description automatically generated