Single-active multihoming service model

The following shows an example of PE1 configuration that provides single-active multihoming to CE2, as shown in Figure 1.

*A:PE1>config>service>system>bgp-evpn# info 
----------------------------------------------
  route-distinguisher 10.1.1.1:0
  ethernet-segment "ESI2" create
    esi 01:12:12:12:12:12:12:12:12:12
    multi-homing single-active
    service-carving
    sdp 1 
    no shutdown

*A:PE1>config>redundancy>evpn-multi-homing# info 
----------------------------------------------
    boot-timer 120
    es-activation-timer 10

*A:PE1>config>service>vpls# info 
----------------------------------------------
  description "evpn-mpls-service with single-active multihoming"
  bgp
  bgp-evpn
    evi 10
    mpls bgp 1
      no shutdown
      auto-bind-tunnel resolution any
  spoke-sdp 1:1 create 
  exit

The PE2 example configuration for this scenario is as follows:

*A:PE1>config>service>system>bgp-evpn# info 
----------------------------------------------
  route-distinguisher 10.1.1.1:0
  ethernet-segment "ESI2" create
    esi 01:12:12:12:12:12:12:12:12:12
    multi-homing single-active
    service-carving
    sdp 2 
    no shutdown

*A:PE1>config>redundancy>evpn-multi-homing# info 
----------------------------------------------
    boot-timer 120
    es-activation-timer 10

*A:PE1>config>service>vpls# info 
----------------------------------------------
  description "evpn-mpls-service with single-active multihoming"
  bgp
  bgp-evpn
    evi 10
    mpls bgp 1
      no shutdown
      auto-bind-tunnel resolution any
  spoke-sdp 2:1 create 
  exit

In single-active multihoming, the non-DF PEs for a specified ESI block unicast and BUM traffic in both directions (upstream and downstream) on the object associated with the ESI. Other than that, single-active multihoming is similar to all-active multihoming with the following differences:

• The ethernet-segment is configured for single-active: service>system>bgp-evpn>eth-seg>multi-homing single-active.

• The advertisement of the ESI-label in an AD per-ESI is optional for single-active Ethernet-Segments. The user can control the no advertisement of the ESI label by using the service system bgp-evpn eth-seg multi-homing single-active no-esi-label command. By default, the ESI label is used for single-active ESs too.

• For single-active multihoming, the Ethernet-Segment can be associated with a port and sdp, as well as a lag-id, as shown in Figure 1, where:

  • port is used for single-active SAP redundancy without the need for lag.

  • sdp is used for single-active spoke SDP redundancy.

  • lag is used for single-active LAG redundancy

    Note: In this case, key, system-id, and system-priority must be different on the PEs that are part of the Ethernet-Segment).

• For single-active multihoming, when the PE is non-DF for the service, the SAPs/spoke SDPs on the Ethernet-Segment are down and show StandByForMHProtocol as the reason.

• From a service perspective, single-active multihoming can provide redundancy to CEs (MHD, Multi-Homed Devices) or networks (MHN, Multi-Homed Networks) with the following setup:

  • LAG with or without LACP

    In this case, the multihomed ports on the CE are part of the different LAGs (a LAG per multihomed PE is used in the CE). The non-DF PE for each service can signal that the SAP is operationally down if eth-cfm fault-propagation-enable {use-if-tlv | suspend-ccm} is configured.

  • Regular Ethernet 802.1q/ad ports

    In this case, the multihomed ports on the CE/network are not part of any LAG. Eth-cfm can also be used for non-DF indication to the multihomed device/network.

  • Active-standby PWs

    In this case, the multihomed CE/network is connected to the PEs through an MPLS network and an active/standby spoke SDP per service. The non-DF PE for each service makes use of the LDP PW status bits to signal that the spoke SDP is operationally down on the PE side.