ON THIS PAGE
 

APPENDIX: EZ-LAG Utilizing Bridged Overlay Example

Note:

Review the known limitations of this approach shared in the L2 WAN Router Attach Details !

Using a bridged overlay across the entire fabric can be a practical option for smaller deployments. It is particularly useful when customers want to migrate from legacy MC-LAG configurations without modifying the existing WAN router implementation. Another benefit is the ability to continue using DHCP server and relay services on the WAN router, since all VLANs connected to the fabric can send their broadcast requests directly to it.

When using bridged overlay on the EVPN fabric side, we use ESI-LAG configuration which required that the WAN router to be able to support the following:

  • The WAN router must support IEEE 802.ad Link Aggregation.
  • The WAN router must support active LACP.
  • The redundant WAN router must support a first-hop redundancy protocol such as VRRP, enabling the default gateway IP address on the LAN interface to move between the active WAN router nodes.

The fully virtual example lab used in the below example used the following configuration:

  • The WAN router was a pair of Juniper Networks® SRX Series Firewalls.
  • The SRX Series Firewalls were managed by Juniper Mist cloud as WAN Edge spoke/standalone.
  • The SRX Series Firewalls were virtual SRX3 VMs with APP-ID licenses.
  • The SRX Series Firewalls used chassis cluster mode and HA links created for state sharing.
  • The EVPN Multihoming fabric was built with two collapsed-core vJunos-switch VMs and two access vJunos-switch VMs. You can find instructions on how to use vJunos-switch VMs together with Juniper Mist cloud in the following NCE.
  • Linux-based desktop VMs emulating wired clients were attached to the access switches.
  • The topology and connected interfaces are shared in the topology below.
Figure 1: Virtual Lab for EVPN MH Bridged Overlay Virtual Lab for EVPN MH Bridged Overlay

When using SRX Series Firewalls in chassis cluster mode, special attention must be given to the LAG configuration toward the EVPN fabric, since VRRP is not used in SRX chassis clusters. The recommended design operates as follows:

  • Only a single reth-interface is configured using four links between the SRX chassis cluster nodes.
  • Ensure the reth-interface is configured as a LAG with active LACP enabled.
  • All four chassis cluster interfaces will run active LACP simultaneously.
  • The SRX chassis cluster determines which chassis cluster node is active at any given time.
    • The standby node does not respond to ARP requests.
    • Only the ae0 or ae1 interfaces on the fabric learn the active SRX remote MAC address as the default gateway for the VLANs.
  • You need two fabric ae* interface LAGs configured.
    • These interfaces must be ESI-LAG interfaces from fabric nodes.
    • These interfaces must have the same ae-index key towards the same SRX chassis cluster node.
Figure 2: SRX chassis cluster to EVPN Fabric redundancy SRX chassis cluster to EVPN Fabric redundancy

Fabric Configuration

We intentionally do not present the complete fabric creation workflow here in order to focus on the components required to understand bridged overlay operation and the associated configuration changes. For more information on configuring EVPN Multihoming, refer to the following JVD.

Switch Template

Below is the output from the JSON file that was used for the switch template for this fabric.

In this example, we created the following six VLANs. Make sure that only the VLAN name and VLAN ID are configured. Do not assign any IPv4 or IPv6 subnets, as doing so would defeat the purpose of using a bridged overlay.

  • Network=1
    • Name=vlan1031
    • VLAN ID=1031
  • Network=2
    • Name=vlan1033
    • VLAN ID=1033
  • Network=3
    • Name=vlan1081
    • VLAN ID=1081
  • Network=4
    • Name=vlan1088
    • VLAN ID=1088
  • Network=5
    • Name=vlan1091
    • VLAN ID=1091
  • Network=6
    • Name=vlan1099
    • VLAN ID=1099

Next, configure a port profile. We intentionally avoid using a predefined profile such as the “uplink” profile so that we can control which VLANs from the fabric are shared with the WAN router in case of a misconfiguration. Configure the port profile as follows:

  • Name=fabric-uplink
  • Port Enabled=Checked
  • Mode=Trunk
  • Port Network=None
  • Trunk Networks=vlan1031 and vlan1033 and vlan1081 and vlan1088 and vlan1091 and vlan1099

Fabric Configuration

When creating the EVPN Multihoming fabric you can use the default settings with no changes needed. Step through the Campus Fabric dialogue until you reach the Configure Networks page. Here you will do the following:

  • Import the six VLANs from the switch template.
  • Under the “OTHER IP CONFIGURATION” section, ensure that no IP addresses appear since none of your networks should have any subnets defined, just the VLAN IDs.
  • VRF Configuration
    • Disabled=Checked
    • Instances=None configured.
  • DHCP Relay=Disabled
  • Access ESI-LAG Name=fabric
  • Trunk Networks=ensure your six VLANs are automatically added.
Figure 3: EVPN Fabric without VRF for Bridged Overlay EVPN Fabric without VRF for Bridged Overlay

Finalize the Campus Fabric dialogue.

Select the fabric that you just created.

Add the wired client port configuration on the access switches (not shown here).

Next, create the fabric uplink configuration on the collapsed-core switches core1 and core2.

On core1 and core2, apply the following port configuration::

  • First Uplink Port:
    • Port ID=ge-0/0/3
    • Interface=L2 interface
    • Configuration Profile=fabric-uplink
    • Port Aggregation=Enabled
    • AE Index=0 (all links to WAN-Router Node0 have this ID)
    • ESI-LAG=Checked MANDATORY
  • Second Uplink Port:
    • Port ID=ge-0/0/4
    • Interface=L2 interface
    • Configuration Profile=fabric-uplink
    • Port Aggregation=Enabled
    • AE Index=1 (all links to WAN-Router Node0 have this ID)
    • ESI-LAG=Checked MANDATORY

WAN Router Setup

Before configuring the WAN Edge template, be sure to do the following:

  • Deploy two SRX Series Firewalls with the required HA links, initially as standalone devices..
  • Install the necessary App-ID licenses on both devices.
  • Navigate to Organization -> Site Configuration and enable the option My SRX devices have an App Track license.
  • Adopt or claim the SRX Series Firewalls so they appear in the Mist Inventory.
  • Select both SRX Series Firewalls in the inventory and assign them to the appropriate site. During the site assignment process, enable cluster mode.
  • Allow approximately 15 minutes for the process to complete.
  • Then, navigate to WAN Edges -> Site and review the WAN Edge cluster status. Confirm that AppSecure is running as shown below:
Figure 4: vSRX3 chassis cluster with AppSecure enabled vSRX3 chassis cluster with AppSecure enabled

Now you can build a WAN Edge Template (or Hub Profile).

Below is the output from the JSON file that was used as the WAN Edge template:

If you decide not to import the above JSON, the same configuration can also be created through the Juniper Mist portal as described below for reference. Follow these steps:.

Navigate to Organization -> Applications and add a custom application for “fabric” with all RFC1918 networks. Create the following application:

  • Name=fabric
  • Type=Custom Apps
  • IP Addresses=10.0.0.0/8 and 172.16.0.0/12 and 192.168.0.0/16

Under Organization -> Networks, add the subnets for each of the six VLANs.

  • Network=1
    • Name=vlan1031
    • Subnet IP Address=10.31.31.0
    • Prefix Length=24
    • VLAN ID=1031
    • Access to Mist Cloud=Enabled
  • Network=2
    • Name=vlan1033
    • Subnet IP Address=10.33.33.0
    • Prefix Length=24
    • VLAN ID=1033
    • Access to Mist Cloud=Enabled
  • Network=3
    • Name=vlan1081
    • Subnet IP Address=10.81.81.0
    • Prefix Length=24
    • VLAN ID=1081
    • Access to Mist Cloud=Enabled
  • Network=4
    • Name=vlan1088
    • Subnet IP Address=10.88.88.0
    • Prefix Length=24
    • VLAN ID=1088
    • Access to Mist Cloud=Enabled
  • Network=5
    • Name=vlan1091
    • Subnet IP Address=10.91.91.0
    • Prefix Length=24
    • VLAN ID=1091
    • Access to Mist Cloud=Enabled
  • Network=6
    • Name=vlan1099
    • Subnet IP Address=10.99.99.0
    • Prefix Length=24
    • VLAN ID=1099
    • Access to Mist Cloud=Enabled

In our design, we used dynamic IP addresses on the WAN interfaces for our lab.

Figure 5: WAN-Interfaces for our Lab example WAN-Interfaces for our Lab example

The next step is to configure the LAN interfaces according to the design shown. Set up the following six LAN IP gateway interfaces:

  • Gateway=1
    • Network=vlan1031
    • IP Address=10.31.31.1
    • Prefix Length=24
  • Gateway=2
    • Network=vlan1033
    • IP Address=10.33.33.1
    • Prefix Length=24
  • Gateway=3
    • Network=vlan1081
    • IP Address=10.81.81.1
    • Prefix Length=24
  • Gateway=4
    • Network=vlan1088
    • IP Address=10.88.88.1
    • Prefix Length=24
  • Gateway=5
    • Network=vlan1091
    • IP Address=10.91.91.1
    • Prefix Length=24
  • Gateway=6
    • Network=vlan1099
    • IP Address=10.99.99.1
    • Prefix Length=24

Next, enable DHCP and configure a DHCP server for each VLAN. The complete DHCP server configuration for all VLANs is shown below:

  • VLAN=1
    • Network=vlan1031
    • DHCP=Server
    • IP Start=10.31.31.10
    • IP End=10.31.31.250
    • Gateway=10.31.31.1
    • DNS Servers=8.8.8.8, 9.9.9.9
  • VLAN=2
    • Network=vlan1033
    • DHCP=Server
    • IP Start=10.33.33.10
    • IP End=10.33.33.250
    • Gateway=10.33.33.1
    • DNS Servers=8.8.8.8, 9.9.9.9
  • VLAN=3
    • Network=vlan1081
    • DHCP=Server
    • IP Start=10.81.81.10
    • IP End=10.81.81.250
    • Gateway=10.81.81.1
    • DNS Servers=8.8.8.8, 9.9.9.9
  • VLAN=4
    • Network=vlan1088
    • DHCP=Server
    • IP Start=10.88.88.10
    • IP End=10.88.88.250
    • Gateway=10.88.88.1
    • DNS Servers=8.8.8.8, 9.9.9.9
  • VLAN=5
    • Network=vlan1091
    • DHCP=Server
    • IP Start=10.91.91.10
    • IP End=10.91.91.250
    • Gateway=10.91.91.1
    • DNS Servers=8.8.8.8, 9.9.9.9
  • VLAN=6
    • Network=vlan1099
    • DHCP=Server
    • IP Start=10.99.99.10
    • IP End=10.99.99.250
    • Gateway=10.99.99.1
    • DNS Servers=8.8.8.8, 9.9.9.9

Then, configure the LAN interfaces connected to the fabric into a LAG:

  • Interface=ge-0/0/2,ge-0/0/3,ge-7/0/2,ge-7/0/3
  • Port Aggregation=Checked/Enabled
    • Disable LACP=Unchecked
    • Enable Force Up=Unchecked
    • AE Index=0
  • Redundant=Checked/Enabled
    • Redundant Index=3
    • Redundant Group=3
    • Primary Node=node0
  • Networks=vlan1031 and vlan1033 and vlan1081 and vlan1088 and vlan1091 and vlan1099

The result should appear as shown below:

Figure 6: SRX chassis cluster LAN-interfaces SRX chassis cluster LAN-interfaces

The traffic steering rules are straightforward, as outlined below:

  • Create a LAN traffic steering rule using ECMP and include all six VLAN interface.
  • Create a WAN traffic steering rule that includes both WAN interfaces.
Figure 7: Traffic Steering Traffic Steering
Note:

The following two application policy rules assume you have two SRX Series Firewalls. If you are using two physical Juniper® Session Smart® Routers as the WAN router, do not configure LAN for traffic steering in the first application policy rule as shown below. Instead, leave the Traffic Steering field empty in the first application policy rule.

For Application Policies you need to configure the following:

  • Rule=1
    • Name=branch-hairpin
    • Network=vlan1031 and vlan1033 and vlan1081 and vlan1088 and vlan1091 and vlan1099
    • Application=fabric
    • Traffic Steering=LAN
  • Rule=2
    • Name=towards-internet
    • Network=vlan1031 and vlan1033 and vlan1081 and vlan1088 and vlan1091 and vlan1099
    • Application=any
    • Traffic Steering=WAN

On the SRX Series Firewalls, add the configuration below to allow ping access to the LAN interfaces on the SRX chassis cluster. This is a recommended best practice for troubleshooting, and some applications may also depend on it.

Testing Your Configuration

The following section outlines the steps used to test and validate the configuration and traffic flow within this network design.

We start with the desktop1 VM attached to the access1 switch.

Below, we review the status of collapsed core1 switch using a remote console connection:

Below, we review the status of the SRX chassis cluster using a remote console connection: