Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring LACP for EVPN Active-Active Multihoming

 

This example shows how to configure the Link Aggregation Control Protocol (LACP) on multihomed customer edge (CE) and provider edge (PE) devices in an Ethernet VPN (EVPN) active-active multihomed network.

Requirements

This example uses the following hardware and software components:

  • Four MX Series 5G Universal Routing Platforms with MPC interfaces only, of which:

    • Two routers are configured as PE devices connected to a common multihomed customer site.

    • One router is configured as a remote PE device connected to a single-homed customer site.

    • One router is configured as the core provider device.

  • Two CE devices, of which:

    • One CE device is multihomed to the two PE devices.

    • One CE device is single-homed to the remote PE device.

  • Junos OS Release 17.1 or later running on all the PE devices.

Before you begin:

  1. Configure the device interfaces and enable MPLS on all the interfaces of the PE devices.

  2. Configure OSPF or any other IGP between the core provider device and the PE devices.

  3. Configure MPLS and a label-switched path (LSP) from the ingress PE device to the remote egress PE device.

  4. Configure an internal BGP session between the PE devices.

    Note

    We recommend that you configure Bidirectional Forwarding Detection (BFD) on the BGP session for faster detection of core isolation and better convergence.

Overview

Starting with Junos OS Release 17.1, an extra level of redundancy can be achieved in an EVPN active-active multihoming environment by configuring LACP on both the endpoints of the multihomed CE-PE link. The multihomed devices are configured with aggregated trunk links, where the link aggregation group (LAG) interfaces of the CE-PE link can either be in the active or in the standby state. When the LAG interface is in the active state, data traffic is transmitted over the CE-PE link. When the LAG interface is in the standby state, data traffic is blocked and only control traffic for communicating LAG interface state is transmitted over the link.

The LAG interface state is monitored and operated by LACP to ensure fast convergence on isolation of a multihomed PE device from the core. When there is a core failure, a traffic black hole can occur at the isolated PE device. However, with the support for LACP on the CE-PE link, at the time of core isolation, the CE-facing interface of the multihomed PE device is set to the standby state, thereby blocking data traffic transmission from and toward the multihomed CE device. After the core recovers from the failure, the interface state is switched back from standby to active.

The support for LACP for EVPN active-active multihoming is applicable to both EVPN with MPLS and EVPN with VXLAN.

When LACP is configured on the CE-PE link, isolation of the multihomed PE device from the core is handled as follows:

  1. When the EVPN BGP peers are null for a multihomed PE device, the PE device is isolated from the core. The CE devices connected to the isolated PE device are notified about the core failure by the isolated PE device.
  2. On learning about the core failure, data traffic is not forwarded from the CE device to the isolated multihomed PE device. Instead, the traffic is diverted to the other multihomed PE devices that belong to the same LAG. This helps in preventing traffic black holes at the isolated PE device.
  3. If the multihomed CE device uses the LAG for load balancing traffic to multiple active multihomed PE devices, then the LACP configuration along with the same system ID configured on all the multihomed PE devices for that given LAG, triggers an LACP out-of-sync to all the attached multihomed CE links.

When configuring LACP on the multihomed devices, be aware of the following considerations:

  • The LAG link can operate either in the active or in the standby state regardless of the UP/DOWN operational state.

  • On system reboot, the LACP link on the multihomed PE device is in the active state.

  • When the control plane goes down or when the BGP-EVPN session is down, LACP is notified to run multiplexer state machine for the aggregation port and move the link from active to standby.

  • An interface is not treated as up unless it operates in the active state and its operational state is also up.

  • The following features are not supported with LACP on EVPN active-active multihoming:

    • Ethernet segment identifier (ESI) value auto-derivation from LACP system ID.

    • Redundancy coverage for non-LAG interfaces.

    • Redundancy coverage for core isolation with static LAGs.

    • Node isolation.

    • Access failures for LACP with EVPN active-active multihoming.

Topology

Figure 1 illustrates an EVPN active-active multihoming network with LACP configured on the multihomed CE and PE devices. Device CE1 is single-homed and is connected to a remote PE device, PE1. Device PE2 and Device PE3 connect to a common multihomed CE—CE2. Device P is the core device to which all the PE devices (PE1, PE2, and PE3) are connected.

The endpoints of the multihomed devices—Device CE2, Device PE2, and Device PE3—are configured with LACP on the CE-PE link.

Figure 1: LACP Support in EVPN Active-Active Multihoming
LACP
Support in EVPN Active-Active Multihoming

Core isolation of Device PE3 is handled as follows:

  1. After LACP is configured on the multihomed CE-PE links, the LACP configuration and operational data is synchronized between the LACP peers to operate as a LAG.

    The synchronization between the LACP peers happens with the exchange of control PDUs, and is required for the following reasons:

    • To determine the state of the links in the Ethernet bundle—all-active or standby.

    • To detect and handle CE device misconfiguration when LACP Port Key is configured on the PE device.

    • To detect and handle miswiring between CE and PE devices when LACP Port Key is configured on the PE device.

    • To detect and react to actor or partner churn when the LACP speakers are not able to converge.

  2. After Device PE2 and Device PE3 establish BGP session with at least one peer, the state of the CE-PE link is set to unblocking mode by LACP.
  3. When there is a core failure, and the BGP EVPN peers of Device PE2 becomes null, Device PE2 is isolated from the core. This can cause a traffic black hole at Device PE2. To prevent this situation, the LAG interface of Device PE2 that is facing Device CE2 is changed from the active state to the standby state by LACP.
  4. An out-of-sync notification is sent from LACP on the attached multihomed CE2 link to block traffic transmission between Device CE2 and Device PE2.
  5. When the control plane recovers, that is when Device PE2 establishes BGP session with other EVPN PEs, the LAG interface of Device PE2 is switched back from standby to active by LACP.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Device CE1

Device CE2

Device PE1

Device PE2

Device PE3

Device P

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE2:

Note

Repeat this procedure for other multihomed PE devices after modifying the appropriate interface names, addresses, and other parameters.

  1. Specify the number of aggregated Ethernet interfaces to be created on Device PE2.
  2. Configure Device PE2 interfaces that connect to Device P and Device PE3, respectively.
  3. Configure Device PE2 interfaces within the ae0 aggregated bundle toward the multihomed Device CE2.
  4. Configure active-active multihoming on the aggregated Ethernet interface.
  5. Configure LACP on the CE-PE link of Device PE2.
  6. Configure the loopback interface of Device PE2.
  7. Configure the router ID and autonomous system number for Device PE2.
  8. Enable chained composite next hop for EVPN on Device PE2.
  9. Configure MPLS on all the interfaces of Device PE2, excluding the management interface.
  10. Configure an internal BGP group for Device PE1 to peer with the other EVPN PE devices.
  11. Configure OSPF and LDP on all the interfaces of Device PE2, excluding the management interface.
  12. Configure an EVPN routing instance on Device PE2 and assign the routing instance parameters.

Results

From configuration mode, confirm your configuration by entering the show chassis, show interfaces, show routing-options, show protocols, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device CE2:

Note

Repeat this procedure for other multihomed CE devices after modifying the appropriate interface names, addresses, and other parameters.

  1. Specify the number of aggregated Ethernet interfaces to be created on Device CE2.
  2. Configure Device CE2 interfaces within the ae0 aggregated bundle toward Device PE2 and Device PE3.
  3. Configure LACP on the CE-PE links on Device CE2.
  4. Configure the loopback interface of Device CE2.

Results

From configuration mode, confirm your configuration by entering the show chassis, show interfaces, show routing-options, show protocols, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying BGP Session Status

Purpose

Verify that Device PE2 has established BGP peering with other EVPN PE devices.

Action

From operational mode, run the show bgp summary command.

user@PE2> show bgp summary

Meaning

Device PE2 has established BGP peering with the other EVPN PE devices—Device PE1 and Device PE3.

Verifying LACP Interface Status of Multihomed PE Device

Purpose

Verify the LACP interface state on Device PE2.

Action

From operational mode, run the show lacp interfaces and show interfaces ae* terse commands.

user@PE2> show lacp interfaces
user@PE2> show interfaces ae* terse

Meaning

The LACP LAG interface state is active when there is BGP peering with other EVPN PE devices. The physical interface state of the aggregated Ethernet interfaces are up and operational.

Verifying LACP Interface State of Isolated PE Device

Purpose

Verify the LACP interface state of Device PE2 when no BGP EVPN peers have been established.

Action

From operational mode, run the show lacp interfaces and show interfaces ae* terse commands.

user@PE2> show lacp interfaces
user@PE2> show interfaces ae* terse

Meaning

Because of core isolation, the LAG interface state is in standby, blocking traffic to-and-from Device CE2. As a result, the physical interface state of the aggregated Ethernet interface is also down until the LACP link state switches back to active on core failure recovery.

Verifying EVPN Routing Instance

Purpose

Verify the EVPN routing instance parameters on Device PE2.

Action

From operational mode, run the show evpn instance extensive command.

user@PE2> show evpn instance extensive

Meaning

The output provides the following information:

  • EVPN routing instance

  • Mode of operation of each interface

  • Neighbors of the routing instance

  • Number of different routes received from each neighbor

  • ESI attached to the routing instance

  • Number of Ethernet segments on the routing instance

  • Designated forwarder (DF) election roles for each ESI in an EVPN instance (EVI)

  • VLAN ID and MAC labels for the routing instance