Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring Basic EVPN-MPLS Active-Standby Multihoming

This example shows how to configure active-standby multihoming in an Ethernet VPN (EVPN) fabric with MPLS.

Requirements

This example uses the following hardware and software components:

  • Four MX Series 5G Universal Routing Platforms running Junos OS Release 14.1 (or later), with MPC interfaces, acting as provider edge (PE) and provider (P) routers.

  • Two customer edge (CE) devices.

Note:

We support active-standby multihoming in EVPN fabrics only with MPLS.

QFX Series switches support EVPN-VXLAN with active-active multihoming; they don't support EVPN with MPLS or multihoming in active-standby mode.

Overview and Topology

Figure 1 illustrates a simple EVPN topology. Routers PE1 and PE2 are provider edge (PE) routers connected to multihomed customer edge (CE) router CE1. An additional PE, router PE3, is a remote PE in the EVPN fabric connected to CE2, a single-homed CE router.

Figure 1: Simple EVPN Multihomed TopologySimple EVPN Multihomed Topology

The network has the following characteristics:

  • All PE and P routers are running OSPF.

  • There is an IBGP mesh between all PE routers.

  • MPLS (RSVP) LSPs are configured between all PE routers.

  • On routers PE1 and PE2, each device’s CE-facing interface uses the same Ethernet Segment Identifier (ESI).

For simplicity and consistency of configuration, this example configures the following elements on the three PE devices as part of setting up the EVPN:

  • An EVPN instance (EVI) named EVPN-RI using instance-type virtual-switch. The example enables protocols evpn in the instance.

    Note:

    You can use another instance type instead of virtual-switch that the device supports for EVPN instances, such as instance-type evpn.

  • A route distinguisher for the EVI that is unique on each PE device.

  • A route target extended community for the EVPN instance using the vrf-target statement.

    Note:

    With this statement, the device automatically sets import and export routing policies based on the specified community. Because this configuration uses the same route target value on all of the PE devices, they can share routes using those implicit routing policies. The example doesn't need to explicitly configure import and export policies for route sharing.

This example configures the following elements on the two multihoming peer PE devices PE1 and PE2 to which CE1 is multihomed:

  • The interfaces that connect to the multihomed CE.

  • An Ethernet Segment (ES) identifier (ESI) associated with those interfaces. The ESI values must match on the multihoming peer PE devices.

  • Single-active mode for ES operation.

See EVPN Multihoming Overview and Configuring EVPN-MPLS Active-Standby Multihoming for more detail on the required configuration elements and steps.

Note that we support configuring the following elements on EVPN PEs, but we don't include them in this configuration because the example focuses only on the basic required elements:

  • In addition to an EVPN instance, you usually configure Layer 3 (L3) VRF (virtual routing and forwarding) routing instances on the EVPN PE devices using the vrf instance type. L3 VRF instances enable separation or route sharing among multiple tenants at different sites supported by the PEs in the EVPN fabric.

  • If needed, you can configure multiple EVPN instances to set up more than one EVPN with the same set of PEs. In contrast with L3 VRF instances, multiple EVPN instances work at Layer 2 (L2) to further separate how the traffic can be forwarded within or routed between particular VLANs or bridge domains that the EVPN fabric supports.

Configuration

CLI Quick Configuration

The configurations for each device are as follows:

CE1

CE2

PE1

PE2

PE3

P1

Verification

Confirm that the configuration is working properly.

Verifying OSPF

Purpose

Verify that OSPF is working properly.

Action

Verify that Router P1 has adjacencies established with all PE devices.

Meaning

Adjacencies have been established with the PE devices.

Verifying BGP

Purpose

Verify that BGP is working properly.

Action

Verify that MP-IBGP peerings are established using EVPN signaling between all PE devices.

Meaning

EVPN-signaled MP-IBGP peerings have been established between all PE devices.

Verifying MPLS

Purpose

Verify that MPLS is working properly.

Action

Verify that MPLS LSPs are established between all PE devices.

Meaning

LSPs have been established between PE devices.

Verifying EVPN Configuration and Multihoming Status

Purpose

Verify that EVPN is configured properly.

Action

Verify that the EVPN routing instances and ESIs are configured and functioning correctly, and confirm that single-active multihoming is enabled.

Meaning

From the outputs above, the following can be determined:

  • All three PE devices confirm that PE1 and PE2 are using single-active mode.

  • PE1 and PE2 are using the same ESI.

  • PE1 is elected as the designated forwarder (DF), and its CE-facing interface is put into a state of Up/Forwarding.

  • PE2 is elected as the backup designated forwarder (BDF), and its CE-facing interface is put into a state of Up/Blocking.

Verifying Route Exchange and ESI Autodiscovery

Purpose

Verify that EVPN signaling is working properly.

Action

Verify that autodiscovery and other signaling information is being shared between PE devices.

Meaning

The outputs above show two EVPN route types:

  • Route Type 1: Ethernet Auto-Discovery (AD) Route - These routes are advertised on a per-EVI and per-ESI basis. Ethernet AD routes are required when a CE device is multihomed. When a CE device is single-homed, the ESI will be zero.

  • Route Type 3: Inclusive Multicast Ethernet Tag Route - This route sets up a path for broadcast, unknown unicast, and multicast (BUM) traffic from a PE device to the remote PE device on a per VLAN, per ESI basis.

The outputs above show the following information:

  • 1:192.168.x.x:10::112233445566778899::0/304 AD/EVI - This is the per-EVI AD Type 1 EVPN route. As the DF (and active device), Router PE1 has advertised this route to Routers PE2 and PE3.

  • 1:192.168.x.x:0::112233445566778899::FFFF:FFFF/304 AD/ESI - This is the per Ethernet segment AD Type 1 EVPN route. As the multihomed devices, Routers PE1 and PE2 have advertised this route to each other and to Router PE3.

  • 3:192.168.x.x:10::10::192.168.x.x/304 IM - This is the route used to set up a path for BUM traffic. Each PE device has advertised this route to the other PE device.

Verifying Ethernet Segment (ES) Route Exchange

Purpose

Verify that ES route information is being shared correctly.

Action

Verify that the local and advertised autodiscovery routes per Ethernet segment and the Ethernet segment routes are received.

Meaning

The outputs above show two EVPN route types:

  • Route Type 1: Ethernet Auto-Discovery (AD) Route - These routes are advertised on a per-EVI and per-ESI basis. Ethernet AD routes are required when a CE device is multihomed. When a CE device is single-homed, the ESI will be zero.

  • Route Type 4: Ethernet Segment Route - PE devices that are connected to the same Ethernet Segment will discover each other through the ES route.

The outputs above show the following information:

  • 1:192.168.x.x:0::112233445566778899::FFFF:FFFF/304 AD/ESI - This is the per Ethernet segment AD Type 1 EVPN route. In the outputs above, each PE device shows its own route.

  • 4:192.168.x.x:0::112233445566778899:192.168.x.x/304 ES - This is the ES route for the local ESI. In the outputs above, each PE device shows both its own route and the one advertised by the other PE device.