APPENDIX: WAN Router Integration into the Fabric
In general, there are several possible ways to attach a WAN router to a campus fabric.
- Via a Layer 2 forwarding method:
- The fabric uplinks are configured as ESI-LAGs and contain one or more tagged VLANs (one for each VRF) to communicate with the WAN router.
- It is also necessary that you configure the IP address of the WAN router interface manually as the next-hop IP address for default-forwarding on each fabric VRF as already shown above.
- The WAN router itself needs to understand standard IEEE 802.3ad LAG with active LACP.
- If you have more than one WAN router attached for redundancy, it is advised to provide failover mechanisms between them for the interface IP addresses towards the fabric. VRRP is recommended.
- Routes between fabric and WAN router are only statically configured.
- Via a Layer 3 forwarding method:
- The fabric uplinks are configured as Layer 3 peer-to-peer IP links.
- Per fabric VRF, a peer-to-peer link needs to be established with the WAN router.
- Usually, there are multiple peer-to-peer links on a single physical uplink. Those are further segmented via tagged VLANs to provide isolation on the uplinks.
- There is no need to manually configure next-hops for each VRF inside the fabric as it is assumed that the propagation of the default gateways will be obtained from the WAN router through a routing protocol.
- Between the fabric and the WAN router, a routing protocol must be established to exchange routes.
- The campus fabric supports exterior BGP and OSPF as routing protocols towards the WAN router.
The details of such integration are explained in a JVD extension for all fabric types.
For simplicity, in this JVD we have chosen to utilize the Layer 2 exit through the ESI-LAG as the stretched VLAN, which is not intended to be used in production.
Remember that you chose to deploy the border gateway capability on the Juniper Networks® EX9204 Switches during the Campus Fabric Core-Distribution deployment, represented below:

Mist enables the EX9204 to translate between VXLAN traffic within the campus fabric and standard Ethernet switching for external connectivity—in this case an MX router. Let’s verify the ESI status on the core switches.

We must configure the ESI-LAG since Mist does not configure this automatically. Add a port profile on the core switch interfaces facing the WAN router.
The following represents an existing port profile applied to each MX router facing EX9204 switch ports (on Core2, the switch port is xe-1/0/1).

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

Note that LACP is up, and this infers that there is an existing configuration on the MX router.

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

The EVPN database is confirmed on both Core1 and 2 and VXLAN tunnels are established between distribution and core switches. We have also verified Desktop1 and 2 are present in Core1 and 2’s EVPN databases.
Let's check to see if the core has the Desktop1 MAC address.

We next verify if Desktop1’s MAC address is learned via VTEP interfaces on Core1:

Dist1 does show both desktop MAC and ARP entries which once again validates control plane operational status within the campus fabric. Additionally, we have also learned the MAC addresses that are located on the WAN router indicated below in yellow.

Then, confirm the EVPN database now has the ESI entry. The MX router IP address for each VLAN ending in .254 is also present in the EVPN database. Back to Desktop1 to see if it can cross the fabric.

Last step is to verify Desktop1 can ping Desktop2:


Conclusion: The connectivity within the campus fabric and externally have been verified. Desktops can communicate with each other through the campus fabric, each in an isolated VRF, then forwarded to the MX router through the dual-homing ESI-LAG on both Core1 and 2 for routing between VRFs or routing instances. Internet connectivity was also verified from each desktop.