Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

EVPN-VXLAN Campus Architectures

 

Validated Architectures for EVPN-VXLAN Campus Networks

Juniper Networks supports several options for an EVPN-VXLAN based campus network. This page introduces these options, and provides links to detailed configuration examples that show you how to deploy and validate your choice of campus architecture.

Figure 1 shows the supported options for an EVPN-VXLAN campus network.

Figure 1: Options for an EVPN-VXLAN Based Campus
Options for an EVPN-VXLAN
Based Campus

EVPN Multihoming: ESI LAG

Describes a collapsed core architecture where the Layer 3 VXLAN gateway function is configured only on the core devices. A collapsed core architecture is less complex and easier to configure than other EVPN-VXLAN campus architectures. In this model the functionality associated with the distribution layer is “collapsed” into the core devices. As a result the architecture is comprised of only the access and core layers.

EVPN multihoming eliminates the need for Spanning Tree Protocol (STP) across the campus network by providing the multihoming capabilities from the access layer to the core layer.

The characteristics of EVPN multihoming include:

  • Well suited for small to medium campus networks

  • Optimal for North to South traffic flows, i.e., inter-campus traffic

  • Easy migration from legacy technologies such as Virtual Chassis Fabric (VCF) or MC-LAG, which are based on routing at the core layer

  • Simpler configuration as IRB interfaces are defined only on the devices in the core layer

  • Eliminates need for STP; supports active-active forwarding over all links

Refer to Overview of a Collapsed Core with EVPN Multihoming in a Campus Network for details on how to deploy and validate an EVPN multihoming campus architecture.

Campus Fabric Core-Distribution: Centrally-routed Bridging

Describes an architecture where the Layer 3 VXLAN gateway function is configured only on the core devices. This is accomplished by defining Integrated Routing and Bridging (IRB) interfaces on the core devices to provide Layer 3 routing services. A Centrally-routed bridging architecture is often referred to as CRB.

In this model the distribution layer provides a Layer 2 VXLAN gateway function to bridge traffic between the endpoints on the same virtual network (VN). In contrast, traffic between VNs must be routed at the core layer. In this case, the distribution layer first bridges the inter VN traffic to it’s default gateway, which is instantiated as an IRB in the core layer. Once at the core, the traffic is de-capsulated, routed, and then re-encapsulated into a VXLAN tunnel associated with the destination VN. At that point the traffic is bridged to the destination endpoint in the distribution layer.

The characteristics of CRB include:

  • Well suited for small to medium campus networks

  • Optimal for North to South traffic flows, i.e., inter-campus traffic

  • Easy migration from legacy technologies such as Virtual Chassis Fabric (VCF) or MC-LAG, which are based on routing at the core layer

  • Simpler configuration as IRB interfaces are defined only on the devices in the core layer

  • Support for distribution devices that cannot perform Layer 3 VXLAN gateway functions

Refer to How to Configure an EVPN-VXLAN Fabric for a Campus Network With CRB for details on how to deploy and validate a CRB based campus architecture.

Campus Fabric Core-Distribution: Edge-routed Bridging

Describes an architecture where the Layer 2 and 3 VXLAN gateway functions are configured on the distribution devices. In this case the Integrated Routing and Bridging (IRB) interfaces are defined on the distribution devices to provide Layer 3 routing services. An Edge-routed bridging architecture is often referred to as ERB.

In this model the core layer provides IP underlay routing only. All bridging and routing in the overlay is performed at the distribution layer. This means the core layer does not need to provide VXLAN encapsulation or decapsulation services. All VXLAN Tunnel Endpoint (VTEP) functions occur at the distribution layer devices.

The characteristics of ERB include:

  • Well suited for small to medium campus networks

  • Optimal for East West traffic flows, i.e., intra-campus traffic

  • Support for core devices that cannot perform VXLAN gateway functions

  • Reduced need for gateway relearning in the event of device failure; smaller blast radius when compared to CRB

  • Better interoperability in a multi-vendor switch fabric

Refer toOverview of EVPN-VXLAN Campus Fabric with ERB for details on how to deploy and validate an ERB based campus architecture.

IP Clos

The IP Clos architecture pushes VXLAN Layer 2 gateway functionality, i.e., bridging, into the access layer. As with ERB, the distribution layer continues to provide Layer 2 and Layer 3 VXLAN gateway services. IP Clos can be characterizes as access layer bridging with distribution layer routing.

This model is also referred to as “end-to-end” given that VXLAN tunnel are now terminated at the access layer, in contrast to both the CRB and ERB architectures, where the access layer does not provide any VXLAN functionality.

As with ERB, in an IP Clos campus the core layer provides only IP underlay routing. with no need for VXLAN encapsulation or decapsulation functionality. All VXLAN Tunnel Endpoint (VTEP) functions now occur at the access and distribution layer devices.

The characteristics of IP Clos include:

  • Ideal for medium and large campus networks

  • Optimal for East West traffic flows, i.e., intra-campus traffic

  • Support for core devices that cannot perform VXLAN gateway functionality

  • Access layer segmentation for improved scaling

  • Ideal when a Layer 3 VXLAN gateway is needed at access

  • Well suited for mobility and IoT devices

  • Reduced need for gateway relearning in the event of device failure; smaller blast radius when compared to CRB

Refer toHow to Configure an IP Clos Fabric for a Campus Network for details on how to deploy and validate a IP Clos based campus architecture.