Ethernet virtual private networks

The 7705 SAR generates route type 2 for advertising MAC addresses. If mac-advertisement is enabled, the router generates MAC advertisement routes for the following:

• learned MAC addresses on SAPs or SDP bindings

• conditional static MAC addresses

  Note: The unknown-mac-route command is not supported for EVPN-MPLS services.

Route type 2 uses the fields and values shown in EVPN-MPLS route type 2 and type 3 (required routes and communities) and described in the following table. For type 2 BGP route key processing, the following fields are considered to be part of the prefix in the NLRI: Ethernet tag ID, MAC address length, MAC address, IP address length, and IP address.

Route type 3 is used for setting up the flooding tree (BMU flooding) for a specified VPLS service. The received inclusive multicast routes add entries to the VPLS flood list in the 7705 SAR. Ingress replication is supported as the tunnel type in route type 3 when BGP-EVPN MPLS is enabled.

Route type 3 uses the fields and values shown in EVPN-MPLS route type 2 and type 3 (required routes and communities) and described in the following table. For type 3 BGP route key processing, the following fields are considered to be part of the prefix in the NLRI: Ethernet tag ID, IP address length, and originating router IP address.

The 7705 SAR generates route type 1 for advertising for multihoming functions. The system can generate the following two subtypes of Ethernet auto-discovery (AD) routes:

• Ethernet AD per-ESI route (Ethernet segment ID)

• Ethernet AD per-EVI route (EVPN instance)

The Ethernet AD per-ESI route uses the fields and values shown in EVPN route type 1 and type 4 and described in the following table. For type 1 BGP route key processing, the following fields are considered to be part of the prefix in the NLRI: Ethernet segment identifier and Ethernet tag ID.

The system can send either a separate Ethernet AD per-ESI route per service or several Ethernet AD per-ESI routes aggregating the route targets for multiple services. While both alternatives can interoperate, RFC 7432 states that the EVPN AD per-ES route must be sent with a set of route targets corresponding to all the EVIs defined on the Ethernet segment. Either alternative can be enabled using the ad-per-es-route-target command options.

The default option, evi-rt, configures the system to send a separate AD per-ES route per service.

The evi-rt-set route-distinguisher ip-address option, when enabled, allows the aggregation of routes; that is, a single AD per-ES route with the associated RD (ip-address:1) and a set of EVI route targets are advertised (to a maximum of 128 route targets). If the number of EVIs defined in the Ethernet segment is significantly large for the packet size, the system will send more than one route. For example:

• AD per-ES route for EVI-route-set 1 is sent with RD ip-address:1

• AD per-ES route for EVI-route-set 2 is sent with RD ip-address:2

The Ethernet AD per-EVI route uses the fields and values shown in EVPN route type 1 and type 4 and described in the following table.

The 7705 SAR generates route type 4 for multihoming Ethernet segment (ES) discovery and designated forwarder (DF) election.

The Ethernet segment route uses the fields and values shown in EVPN route type 1 and type 4 and described in the following table. For type 4 BGP route key processing, the following fields are considered to be part of the prefix in the NLRI: Ethernet segment ID, IP address length, and originating router IP address.

EVPN route type 5 (IP prefix route) is supported for MPLS tunnels. The route fields for route type 5 are shown in the following figure and described in the table. For type 5 BGP route key processing, the following fields are considered to be part of the prefix in the NLRI: Ethernet tag ID, IP prefix length, and IP prefix.

All the routes in EVPN-MPLS are sent with the RFC 5512 tunnel encapsulation extended community, with the tunnel type value set to MPLS.

The router generates route type 5 for advertising IP prefixes in EVPN. The router generates IP prefix advertisement routes for:

• IP prefixes existing in a VPRN linked to the integrated routing and bridging (IRB) backhaul r-VPLS service

  The IRB interface refers to an r-VPLS service bound to a VPRN IP interface.

The following routes are sent with the RFC 5512 BGP tunnel encapsulation extended community: route type 2 (MAC/IP), route type 3 (inclusive multicast Ethernet tag), and route type 1 (Ethernet AD per-EVI). Route type 4 (Ethernet segment) and route type 1 (AD per-ESI) routes are not sent with this extended community.

The router processes the following BGP tunnel-encapsulation tunnel values registered by IANA for RFC 5512:

• MPLS encapsulation: 10

Any other tunnel value gives the route ‟treat-as-withdraw” status.

If the encapsulation value is MPLS, the BGP validates the high-order 20 bits of the label field, ignoring the low-order 4 bits.

If the encapsulation extended community is not present in a received route, BGP treats the route as an MPLS-based configuration of the config>router>bgp>group>neighbor>def-recv-evpn-encap mpls command. The command is also available at the bgp and group levels.

EVPN can be used in MPLS networks where PEs are interconnected through any type of tunnel, including RSVP-TE, segment routing TE, LDP, BGP, segment routing IS-IS, and segment routing OSPF. The selection of the tunnel to be used in a VPLS service with BGP-EVPN MPLS enabled is based on the auto-bind-tunnel command, which is similar to the way that VPRN services operate.

EVPN-MPLS is modeled using a VPLS service where EVPN-MPLS bindings can coexist with SAPs and SDP bindings. The following output shows an example of a VPLS service with EVPN-MPLS.

*A:PE-1>config>service>vpls# info 
----------------------------------------------
  description "evpn-mpls-service"
  bgp
  bgp-evpn
    evi 10
    mpls
      no shutdown
      auto-bind-tunnel resolution any
  sap 1/1/1:1 create 
  exit
  spoke-sdp 1:1 create

The bgp-evpn context must be enabled when MPLS is not shutdown. In addition to the mpls>no shutdown command, the minimum set of commands needed to set up the EVPN-MPLS instance are the bgp-evpn>evi and the bgp-evpn>mpls>auto-bind-tunnel resolution commands. Users can also configure other command options. The minimum set and optional commands are listed below:

• evi value – the EVPN identifier value (EVI value) is unique in the system and can have a value between 1 and 65535. The EVI value is used for the service-carving algorithm (which is used for multihoming, if configured) and for auto-deriving route target and route distinguishers in the service.

  If the evi value is not specified, its value is 0 and no route distinguisher or route targets are auto-derived from it. If the evi value is specified and no other route distinguisher or route targets are configured in the service, the following derivations apply:

  • the route distinguisher is derived from system-ip:evi value

  • the route target is derived from autonomous-system:evi value

  Note: When the vsi-import and vsi-export policies are configured, the route target must be configured in the policies and the policy values take preference over the values of auto-derived route targets. The operational route target for a service is displayed using the show service id service-id bgp command.

  When the evi command is configured, a config>service>vpls>bgp command is required—even if the context is empty—to allow the user to see the correct information when using the show>service>id service-id>bgp and show>service>system>bgp-route-distinguisher commands.

  Although it is not mandatory, if multihoming is not configured, the configuration of the evi command is enforced for EVPN services with SAPs or SDP bindings defined in the ethernet-segment command. See EVPN multihoming in VPLS services for more information about the ethernet-segment command.

The following options are specific to EVPN-MPLS and defined in the bgp-evpn>mpls context:

• control-word – this command is required, as per RFC 7432, to avoid frame disordering. The user can enable and disable it so that interoperability with other vendors can be guaranteed.

• auto-bind-tunnel – this command is required and allows the user to decide what type of MPLS transport tunnels are used for a particular instance. The command is used in the same way as it is used in VPRN services.

  For BGP-EVPN MPLS, bgp is explicitly added to the resolution-filter in EVPN (bgp is implicit in VPRNs).

• force-vlan-vc-forwarding – this command allows the system to preserve the VLAN ID and P-bits of the service-delimiting qtag in a new tag added in the customer frame before sending the customer frame to the EVPN core.

• split-horizon-group – this command allows the association of a user-created split horizon group with all the EVPN-MPLS destinations. See EVPN and VPLS integration for more information.

• ecmp – this command, when set to a value greater than 1, activates aliasing to the remote PEs that are defined in the same all-active multihoming Ethernet segment. See EVPN multihoming in VPLS services for more information.

• ingress-replication-bum-label – this command is only enabled when the user wants the PE to advertise a label for BMU traffic (Inclusive Multicast Ethernet Tag routes, route type 3) that is different from the label advertised for unicast traffic (with the MAC/IP routes). This is useful to avoid potential transient packet duplication in all-active multihoming.

In addition to the options above, the following bgp-evpn commands are also available for EVPN-MPLS services:

• [no] mac-advertisement

• mac-duplication and settings

When EVPN-MPLS is established among some PEs in the network, EVPN unicast and multicast bindings are created on each PE to the remote EVPN destinations. A specified ingress PE creates:

• a unicast EVPN-MPLS destination binding to a remote egress PE as soon as a MAC/IP route is received from that egress PE

• a multicast EVPN-MPLS destination binding to a remote egress PE, only if the egress PE advertises an Inclusive Multicast Ethernet Tag route (route type 3) with a BMU label. This is only possible if the egress PE is configured with ingress-replication-bum-label.

The unicast and multicast bindings, as well as the MAC addresses learned on them, can be checked using the show commands in the following example. In the example, the remote PE 192.0.2.69 is configured with no ingress-replication-bum-label and PE 192.0.2.70 is configured with ingress-replication-bum-label. Therefore, ‟Dut” has a single EVPN-MPLS destination binding to PE 192.0.2.69 and two bindings (unicast and multicast) to PE 192.0.2.70.

*A:Dut# show service id 1 evpn-mpls  

===============================================================================
BGP EVPN-MPLS Dest
===============================================================================
TEP Address     Egr Label     Num. MACs   Mcast           Last Change
                 Transport                                
-------------------------------------------------------------------------------
192.0.2.69      262118        1           Yes             06/11/2015 19:59:03
                ldp                                        
192.0.2.70      262139        0           Yes             06/11/2015 19:59:03
                ldp                                        
192.0.2.70      262140        1           No              06/11/2015 19:59:03
                ldp                                        
192.0.2.72      262140        0           Yes             06/11/2015 19:59:03
                ldp                                        
192.0.2.72      262141        1           No              06/11/2015 19:59:03
                ldp                                        
192.0.2.73      262139        0           Yes             06/11/2015 19:59:03
                ldp                                        
192.0.2.254     262142        0           Yes             06/11/2015 19:59:03
                bgp                                        
-------------------------------------------------------------------------------
Number of entries : 7
-------------------------------------------------------------------------------
===============================================================================

*A:Dut# show service id 1 fdb detail 

===============================================================================
Forwarding Database, Service 1
===============================================================================
ServId    MAC               Source-Identifier        Type     Last Change
                                                     Age      
-------------------------------------------------------------------------------
1         00:ca:fe:ca:fe:69 eMpls:                   EvpnS    06/11/15 21:53:48
                            192.0.2.69:262118
1         00:ca:fe:ca:fe:70 eMpls:                   EvpnS    06/11/15 19:59:57
                            192.0.2.70:262140
1         00:ca:fe:ca:fe:72 eMpls:                   EvpnS    06/11/15 19:59:57
                            192.0.2.72:262141
-------------------------------------------------------------------------------
No. of MAC Entries: 3
-------------------------------------------------------------------------------
Legend:  L=Learned O=Oam P=Protected-MAC C=Conditional S=Static
===============================================================================

The 7705 SAR EVPN implementation supports draft-ietf-bess-evpn-vpls-seamless-integ so that EVPN-MPLS and VPLS can be integrated into the same network and within the same service. This feature is useful for the integration between both technologies and for the migration of VPLS services to EVPN-MPLS.

The following behavior enables the integration of EVPN and SDP bindings in the same VPLS network. An illustration and configuration example follow the list:

• Systems with EVPN endpoints and SDP bindings to the same far end bring down the SDP bindings.

  • The router allows the establishment of an EVPN endpoint and an SDP binding to the same far end but the SDP binding is kept operationally down. Only the EVPN endpoint is operationally up. This is true for spoke SDPs and mesh SDPs.

  • If there is an existing EVPN endpoint to a specified far end and the establishment of a spoke SDP is attempted, the spoke SDP is set up but kept operationally down with an operational flag indicating that there is an EVPN route to the same far end.

  • If there is an existing spoke SDP and a valid (used) EVPN route arrives, the EVPN endpoint is set up and the spoke SDP is brought operationally down with an operational flag indicating that there is an EVPN route to the same far end.

  • If there is an SDP binding and EVPN endpoint to different far-end IP addresses on the same remote PE, both links will be operationally up. This can happen if the SDP binding is terminated in an IPv6 address or IPv4 address that is different from the system address where the EVPN endpoint is terminated.

• The user can add spoke SDPs and all the EVPN-MPLS endpoints in the same split horizon group.

  • The split-horizon-group group-name command under the vpls>bgp-evpn>mpls context allows the EVPN-MPLS endpoints to be added to a split horizon group.

  • The bgp-evpn>mpls>split-horizon-group must reference a user-configured split horizon group. User-configured split horizon groups can be configured within the service>vpls context. The same group-name can be associated with SAPs, spoke SDPs, and EVPN-MPLS endpoints.

  • If the split-horizon-group command is not used, the default split horizon group—which contains all the EVPN endpoints—is still used, but it is not possible to refer to it on SAPs and spoke SDPs.

• The system disables the advertisement of MAC addresses learned on SAPs and spoke SDPs that are part of an EVPN split horizon group.

  • When the SAPs and spoke SDPs are configured within the same split horizon group as the EVPN endpoints, MAC addresses are still learned on them but are not advertised in EVPN.

  • The SAPs and spoke SDPs added to an EVPN split horizon group should not be part of any EVPN multihomed ES. In this case, the PE still advertises the AD per-EVI route for the SAP or spoke SDP, attracting EVPN traffic that could not be forwarded to that SAP or SDP binding.

The following figure shows an example of EVPN-VPLS integration. In this example, if EVPN and SAPs and spoke SDPs are part of the same split horizon group, the traffic arriving on the SAPs and spoke SDPs is not forwarded to EVPN.

The spoke SDPs on PE2 are not part of an split horizon group, so they can forward traffic to EVPN. Spoke SDPs on PE5 are part of same split horizon group, so they cannot forward traffic to EVPN.

A CLI configuration example for PE1, PE5, and PE2 is provided below.

*A:PE1>config>service# info 
----------------------------------------------
vpls 1 customer 1 create
  split-horizon-group "SHG-1" create 
  bgp
    route-target target:65000:1
  bgp-evpn
    evi 1
    mpls
      no shutdown
      split-horizon-group SHG-1
  spoke-sdp 12:1 create
  exit
  sap 1/1/1:1 create
  exit

PE5#config>service# info 
----------------------------------------------
vpls 1 customer 1 create
    split-horizon-group "SHG-1" create
    exit
    stp
        shutdown
    exit
    endpoint "vpls20" create
    exit
    sap 1/1/7:2 create
        no shutdown
    exit
    spoke-sdp 64:2 split-horizon-group "SHG-1" endpoint "vpls20" create
        no shutdown
    exit
    spoke-sdp 65:2 split-horizon-group "SHG-1" endpoint "vpls20" create
        no shutdown
    exit
    no shutdown

*A:PE2>config>service# info 
----------------------------------------------
vpls 1 customer 1 create
  end-point CORE create
    no suppress-standby-signaling
  spoke-sdp 21:1 end-point CORE
    precedence primary
  spoke-sdp 25:1 end-point CORE

PE1, PE3, PE4, and PE5 have BGP-EVPN enabled in VPLS-1. PE2 has active/standby spoke SDPs to PE1 and PE5. In this configuration:

• EVPN endpoints are instantiated within the same split horizon group, for example, SHG-1

• manual spoke SDPs from PE1 and PE5 to PE2 are not part of SHG-1

EVPN MAC advertisements are as follows:

• MAC addresses learned on FEC128 spoke SDPs are advertised normally in EVPN.

• MAC addresses learned on spoke SDPs that are part of SHG-1 are not advertised in EVPN because SHG-1 is the split horizon group used for bgp-evpn>mpls. This prevents any data plane MAC addresses learned on the split horizon group from being advertised in EVPN.

BMU operation on PE1 is as follows:

• When CE1 sends BMU traffic, PE1 floods it to all the active bindings.

• When CE2 sends BMU traffic, PE2 sends it to PE1 (active spoke SDP) and PE1 floods it to all the bindings and SAPs.

• When CE5 sends BMU traffic, PE5 floods it to the EVPN PEs. PE1 will flood the traffic to the active spoke SDP and SAPs but never to the EVPN PEs because they are part of the same split horizon group.

In a VPLS service, a single route distinguisher (RD) is used per service.

The following rules apply:

• The VPLS RD is selected based on the following precedence:

  • a manual RD always take precedence when configured

  • if there is no manual configuration, the RD is derived from the bgp-evpn>evi configuration

  • if there is no manual or evi configuration, there will not be an RD and the service will fail

• The selected RD is displayed in the ‟Oper Route Dist” field of the show>service>id>bgp command.

• The service supports dynamic RD changes, such as a new manual RD configuration.

  Note: When the RD changes, the active routes for that VPLS are withdrawn and readvertised with the new RD.

• If the manual mechanism to derive the RD for a specified service is removed from the configuration, the system will select a new RD based on the above rules. In this case, the routes are withdrawn, the new RD is selected from the evi configuration, and the routes are readvertised with the new RD.

  Note: This reconfiguration will fail if the new RD already exists in a different VPLS or Epipe service.

EVPN multihoming implementation is based on the concept of the Ethernet segment and configured through the ethernet-segment command. An Ethernet segment is a logical structure that can be defined in one or more PEs and identifies the CE (or access network) that is multihomed to the EVPN PEs. An Ethernet segment is associated with port, LAG, or SDP objects and is shared by all the services defined on those objects. For virtual Ethernet segments, individual VID or VC-ID ranges can be associated with the port, LAG, or SDP objects defined in the Ethernet segment.

Each Ethernet segment has a unique identifier called the Ethernet segment identifier (ESI) that is 10 bytes long and is manually configured in the router.

This section describes the behavior of the EVPN multihoming implementation in an EVPN-MPLS service and includes the following topics:

• EVPN all-active multihoming

• EVPN single-active multihoming

EVPN-VPWS uses route type 1 and route type 4; it does not use route types 2 or 3. The following figure shows the encoding of the required extensions for the Ethernet AD per-EVI routes. The encoding follows the guidelines described in draft-ietf-bess-evpn-vpws.

If the advertising PE has an access SAP-SDP or spoke SDP that is not part of an Ethernet segment (ES), the PE populates the fields of the AD per-EVI route with the following values:

• Ethernet tag ID field is encoded with the value configured by the user in the service>epipe>bgp-evpn>local-ac-name>eth-tag value command

• RD and MPLS label values are encoded as specified in RFC 7432

• ESI is 0

• the route is sent along an EVPN Layer 2 attributes extended community, as specified in IETF draft-ietf-bess-evpn-vpws, where:

  • type and subtype are 0x06 and 0x04, as allocated by IANA

  • flag C is set if control-word is configured in the service

  • P- and B-flags are zero

  • Layer 2 MTU is encoded with service-mtu configured in the Epipe service

If the advertising PE has an access SAP-SDP or spoke SDP that is part of an ES, the AD per-EVI route is sent with the information described in the preceding list, with the following minor differences:

• the ESI encodes the corresponding non-zero value

• the P- and B-flags are set in the following cases:

  • all-active multihoming

    • all PEs that are part of the ES always set the P-flag

    • the B-flag is never set in the all-active multihoming ES case

  • single-active multihoming

    • only the DF PE sets the P-flag for an EVI and the remaining PEs send it as P=0

    • only the backup DF PE sets the B-flag

      If more than two PEs are present in the same single-active ES, the backup PE is the winner of a second DF election (excluding the DF). The remaining non-DF PEs send B=0.

ES and AD per-ES routes are also advertised and processed for the Ethernet segment, as described in RFC 7432. The ESI label sent with the AD per-ES route is used by BMU traffic on VPLS services; it is not used for Epipe traffic.

BGP-EVPN can be enabled in Epipe services with either SAPs or spoke SDPs at the access, as shown in the following figure.

EVPN-VPWS is supported in MPLS networks that also run EVPN-MPLS in VPLS services. From a control plane perspective, EVPN-VPWS is a simplified point-to-point version of RFC 7432 for E-Line services for the following reasons:

• EVPN-VPWS does not use inclusive multicast or MAC/IP routes.

• Ethernet AD per-EVI routes are used to advertise the local attachment circuit identifiers at each side of the VPWS instance. The attachment circuit identifiers are configured as local and remote Ethernet tags. When an AD per-EVI route is imported and the Ethernet tag matches the configured remote Ethernet tag, an EVPN-MPLS destination is created for the Epipe.

In the following configuration example, Epipe 2 is an EVPN-VPWS service between PE2 and PE4 (as shown in the figure):

PE2>config>service>epipe(2)#
-----------------------
  bgp-evpn
    evi 2
    mpls
      auto-bind-tunnel resolution any
      ecmp 2
      no shutdown
    local-ac-name "AC-1"
      eth-tag 100  
    remote-ac-name "AC-2"
      eth-tag 200 
  sap 1/1/1:1 create


PE4>config>service>epipe(2)#
-----------------------
  bgp-evpn
    evi 2
    mpls
      auto-bind-tunnel resolution any
      no shutdown
    local-ac-name "AC-2"
      eth-tag 200  
    remote-ac-name "AC-1"
      eth-tag 100 
 spoke-sdp 1:1

The following considerations apply to the configuration:

• The evi value is used to auto-derive the route target or route distinguisher of the service. The evi values must be unique in the system regardless of the type of service they are assigned (Epipe or VPLS).

• Support for the following bgp-evpn commands in Epipe services is the same as in VPLS services:

  • mpls>auto-bind-tunnel

  • mpls>control-word

  • mpls>entropy-label

  • mpls>force-vlan-vc-forwarding

  • mpls>shutdown

• The following bgp-evpn commands identify the local and remote attachment circuits, with the configured eth-tag values encoded in the advertised and received AD Ethernet per-EVI routes:

  • local-ac-name ac-name

  • local-ac-name ac-name eth-tag tag-value, where tag-value is 1 to 16777215

  • remote-ac-name ac-name

  • remote-ac-name ac-name eth-tag tag-value, where tag-value is 1 to 16777215

  Changes to the remote eth-tag value are allowed without shutting down bgp-evpn>mpls or the Epipe service. The local eth-tag value cannot be changed without using the bgp-evpn>mpls>shutdown command.

  Both local and remote eth-tag values are mandatory to bring up the Epipe service.

EVPN-VPWS Epipes can also be configured with the following characteristics:

• Access attachment circuits can be SAPs or spoke SDPs. Only manually configured spoke SDPs are supported; BGP-VPWS and endpoints are not supported. The vc-switching configuration is not supported on bgp-evpn enabled Epipes.

• EVPN-VPWS Epipes support control-word and entropy-label.

  When the bgp-evpn>mpls>control-word command is configured, the PE sets the C-bit in its AD per-EVI advertisement and sends the control word in the data path. In this case, the PE also expects the control word to be received. If there is a mismatch between the received control word and the configured control word, the system will not set up the EVPN destination. As a result, the service will not come up.

• EVPN-VPWS Epipes can advertise the Layer 2 (service) MTU and check its consistency as follows:

  • The advertised MTU value is taken from the configured service-mtu in the Epipe service.

  • The received Layer 2 MTU is checked and compared with the local value. In case of a mismatch between the received MTU and the configured service-mtu, the system does not set up the EVPN destination. As a result, the service does not come up.

  • The system does not check the network port MTU value.

  • If the received Layer 2 MTU value is 0, the MTU is ignored.

The use of active/standby PWs (for access spoke SDPs) and MC-LAG (for access SAPs) provides an alternative redundant solution for EVPN-VPWS that does not use the EVPN multihoming procedures described in IETF draft-ietf-bess-evpn-vpws. The following figure shows the use of both mechanisms in a single Epipe.

In the figure, an active/standby (A/S) PW connects the CE to PE1 and PE2 (left side of the diagram), and an MC-LAG connects the CE to PE3 and PE4 (right side of the diagram). Because EVPN multihoming is not used, there are no AD per-ES routes or ES routes in this example. The redundancy is handled as follows:

• PE1 and PE2 are configured with Epipe 1, where a spoke SDP connects the service in each PE to the access CE. The local-ac-name eth-tag is 1 and the remote-ac-name eth-tag is 2.

• PE3 and PE4 are configured with Epipe 1, where each PE has a LAG SAP that belongs to a previously configured MC-LAG construct. The local-ac-name eth-tag is 2 and the remote-ac-name eth-tag is 1.

• An endpoint and A/S PW is configured on the CE on the left side of the diagram. PE1 and PE2 are able to advertise eth-tag 1 based on the operational status or the forwarding status of the spoke SDP.

  For example, if PE1 receives a standby PW status indication from the CE and the previous status was forward, PE1 withdraws the AD EVI route for eth-tag 1. If PE2 receives a forward PW status indication and the previous status was standby or down, PE2 advertises the AD EVI route for eth-tag 1.

• The user can configure MC-LAG for access SAPs using the configuration of PE3 and PE4 shown in the figure. In this case, the MC-LAG determines which of the two chassis is active or standby.

  If PE4 becomes the standby chassis, the entire LAG port is brought down. As a result, the SAP goes operationally down and PE4 withdraws any previous AD EVI route for eth-tag 2.

  If PE3 becomes the active chassis, the LAG port becomes operationally up. As a result, the SAP and PE3 advertise the AD per-EVI route for eth-tag 2.

EVPN multihoming is supported for EVPN-VPWS Epipe services with the following considerations:

• Single-active and all-active multihoming is supported for SAPs and spoke SDPs.

• Ethernet segments (ESs) can be shared between the Epipe and VPLS services for LAGs, ports, and SDPs.

• A split-horizon function is not required because there is no traffic between the DF and the non-DF for Epipe services. As a result, the ESI label is never used. For this reason, the ethernet-segment>multi-homing single-active no-esi-label command does not affect Epipe services.

• The local Ethernet tag values must match on all PEs that are part of the same ES, regardless of the multihoming mode. The PEs in the ES use the AD per-EVI routes from the peer PEs to validate the PEs as DF election candidates for a specific EVI.

The DF election for Epipes that is defined in an all-active multihoming ES is not relevant because all PEs in the ES function in the same way:

• All PEs send P=1 on the AD per-EVI routes.

• All PEs can send upstream and downstream traffic, regardless of whether traffic is unicast, multicast, or broadcast (all traffic is treated as unicast in the Epipe services).

Therefore, the following tools command output shows ‟N/A” when all-active multihoming is configured.

*A:PE-2# tools dump service system bgp-evpn ethernet-segment "ESI-12" evi 6000 df 
[03/18/2016 20:31:35] All Active VPWS - DF N/A

Aliasing is supported for traffic sent to an Ethernet segment destination. If ECMP is enabled on the ingress PE, per-service load balancing is performed to all PEs that advertise P=1. The PEs that advertise P=0 are not considered as next hops for an ES destination.

Although DF election is not relevant for Epipes in an all-active multihoming ES, it is essential for the following forwarding and backup functions in a single-active multihoming ES:

• The PE elected as DF is the primary PE for the Ethernet segment in the Epipe. The primary PE unblocks the SAP or spoke SDP for upstream and downstream traffic. The remaining PEs in the ES bring their ES SAPs or spoke SDPs operationally down.

• The DF candidate list is built from the PEs sending ES routes for the same ES and is pruned for a specific service, depending on the availability of the AD per-ES and per-EVI routes.

• When the SAP or spoke SDPs (part of the ES) come up, the AD per-EVI routes are sent with P=B=0. The remote PEs do not send traffic at this stage.

  The remote PEs do not start sending traffic until the DF election process is completed, the es-activation-timer has expired, and the PEs advertise AD per-EVI routes with P- and B-bits different from 0.

• The backup PE function is supported as defined in IETF draft-ietf-bess-evpn-vpws. The primary PE, backup, or none status is signaled by the PEs (part of the same single-active multihoming ES) in the P- or B-flags of the EVPN Layer 2 attributes extended community. The following figure shows the advertisement and use of the primary, backup, or none indication by the PEs in the ES.

  

As specified in RFC 7432, the remote PEs in VPLS services have knowledge of the primary PE in the remote single-active ES, based on the advertisement of the MAC/IP routes (because only the DF learns and advertises MAC/IP routes).

Because there are no MAC or IP routes in EVPN-VPWS, the remote PEs can forward the traffic based on the P- and B-bits. The process is described in the following list (using the figure as an example):

• The DF PE for an EVI (PE2) sends P=1 and B=0.

• For each ES or EVI, a second DF election is run among the PEs in the backup candidate list to elect the backup PE. The backup PE (PE3) sends P=0 and B=1.

• All remaining multihoming PEs (PE4 and PE5) send P=B=0.

• At the remote PEs (PE1), the P- and B-flags are used to identify the primary and backup PEs within the ES destination. The traffic is then sent to the primary PE, provided that it is active:

  • When a remote PE receives the withdrawal of an Ethernet AD per-ES (or EVI) route from the primary PE, the remote PE immediately switches the traffic to the backup PE for the affected EVIs.

  • The backup PE takes over immediately without waiting for the ES activation timer to expire and bring up its SAP or spoke SDP.

  • The bgp-evpn mpls ecmp setting also governs the forwarding in single-active multihoming, regardless of the single-active multihoming bit in the AD per-ES route received at the remote PE (PE1):

    • PE1 always sends the traffic to the primary remote PE (the owner of the P=1 bit). If there are multiple primary PEs and ECMP > 1, PE1 will load-balance the traffic to all the primary PEs, regardless of the multihoming mode.

    • If the last primary PE withdraws its AD per-EVI or ES route, PE1 sends the traffic to the backup PE or PEs. If there are multiple backup PEs and ECMP > 1, PE1 load-balances the traffic to the backup PEs.

EVPN and MPLS can be enabled on VPLS or r-VPLS services on the 7705 SAR. While the EVPN-VPLS for MPLS tunnels section focuses on the use of EVPN-MPLS Layer 2 services (that is, how EVPN-MPLS is configured in VPLS services), this section describes how EVPN-MPLS can be used to provide inter-subnet forwarding in r-VPLS and VPRN services. Although inter-subnet forwarding can be provided by regular r-VPLS and VPRN services, EVPN provides an efficient and unified way to populate forwarding databases (FDBs), address resolution protocol (ARP) tables, and routing tables using a single BGP address family. Inter-subnet forwarding in overlay networks would otherwise require data plane learning and the use of routing protocols on a per-VPRN basis.

The 7705 SAR solution for inter-subnet forwarding using EVPN is based on building blocks described in draft-sajassi-l2vpn-evpn-inter-subnet-forwarding and the use of the EVPN IP prefix routes (route type 5) as described in draft-rabadan-l2vpn-evpnprefix-advertisement.

The IRB interface refers to an r-VPLS service bound to a VPRN IP interface.

SAP-based and spoke SDP-based Ethernet segments are supported on r-VPLS services where bgp-evpn mpls is enabled.

The following figure shows an example of EVPN-MPLS multihoming in r-VPLS services, with the following assumptions:

• There are two subnets for a specific customer (for example, EVI1 and EVI2 in the figure), and a VPRN is instantiated in all the PEs for efficient inter-subnet forwarding.

• A backhaul r-VPLS with evpn-tunnel mode enabled is used in the core to interconnect all the VPRNs. EVPN IP prefix routes are used to exchange the prefixes corresponding to the two subnets.

• An all-active ES is configured for EVI1 on PE1 and PE2.

• A single-active ES is configured for EVI2 on PE3 and PE4.

In the figure, the hosts connected to CE1 and CE4 can use regular VRRP for default gateway redundancy; however, this may not be the most efficient way to provide upstream routing.

For example, if PE1 and PE2 are using regular VRRP, the upstream traffic from CE1 may be hashed to the backup IRB VRRP interface instead of being hashed to the master interface. The same thing may occur for single-active multihoming and regular VRRP for PE3 and PE4. The traffic from CE4 will be sent to PE3 although PE4 may be the VRRP master. In that case, PE3 will have to send the traffic to PE4 instead of routing it directly.

In both cases, unnecessary bandwidth between the PEs is used to get to the master IRB interface. In addition, VRRP scaling is limited if aggressive keepalive timers are used.

Because of these issues, passive VRRP is recommended as the best method when EVPN-MPLS multihoming is used in combination with r-VPLS redundant interfaces.

Passive VRRP is a VRRP setting in which the transmission and reception of keepalive messages is completely suppressed, and therefore the VPRN interface always functions as the master. Passive VRRP is enabled by adding the passive keyword to the VRRP instance at creation time (passive mode cannot be enabled or disabled while the protocol is running), as shown in the following examples:

config service vprn interface vrrp virtual-router-id passive

config service vprn interface ipv6 vrrp virtual-router-id passive

For example, if PE1, PE2, and PE5 in the figure use passive VRRP, then even if each individual r-VPLS interface has a different MAC/IP address, because they share the same VRRP instance 1 and the same backup IP, the three PEs will own the same virtual MAC and virtual IP address (for example, 00-00-5E-00-00-01 and 10.0.0.254). The virtual MAC is auto-derived from 00-00-5E-00-00-VRID, as per RFC 3768. The following is the expected behavior when passive VRRP is used in this example:

• All r-VPLS IRB interfaces for EVI1 have their own physical MAC/IP address; they also own the same default gateway virtual MAC and IP address.

• All EVI1 hosts have a unique configured default gateway; for example, 10.0.0.254.

• When CE1 or CE2 sends upstream traffic to a remote subnet, the packets are routed by the closest PE because the virtual MAC is always local to the PE.

  For example, the packets from CE1 hashed to PE1 are routed at PE1. The packets from CE1 hashed to PE2 are routed directly at PE2.

• Downstream packets (for example, packets from CE3 to CE1), are routed directly by the PE to CE1, regardless of the PE to which PE5 routed the packets.

  For example, the packets from CE3 sent to PE1 are routed to CE1 at PE1. The packets from CE3 sent to PE2 are routed to CE1 at PE2.

• In case of ES failure in one of the PEs, the traffic is forwarded by the available PE.

  For example, if the packets routed by PE5 arrive at PE1 and the link to CE1 is down, PE1 will send the packets to PE2. PE2 will forward the packets to CE1 even if the MAC source address of the packets matches the virtual MAC address of PE2. Virtual MAC addresses bypass the r-VPLS interface MAC protection.

The following list summarizes the advantages of using passive VRRP mode versus regular VRRP for EVPN-MPLS multihoming in r-VPLS services:

• Passive VRRP does not require multiple VRRP instances to achieve default gateway load balancing. Only one instance per r-VPLS—therefore only one default gateway—is needed for all the hosts.

• The convergence time for link or node failures is not impacted by the VRRP convergence because all the nodes in the VRRP instance are master routers.

• Passive VRRP scales better than VRRP because it does not use keepalive or BFD messages to detect failures and allow the backup to take over.

When enabling existing VPLS features in an EVPN-MPLS service, the following must be considered:

• EVPN-MPLS is only supported in regular VPLS. Other VPLS types, such as management VPLS (mVPLS), are not supported with EVPN-MPLS.

• In general, no router-generated control packets are sent to the EVPN destination bindings, except for ETH-CFM for EVPN-MPLS.

• STP and mVPLS services:

  • STP can be configured in BGP-EVPN services. BPDUs are not sent over the EVPN bindings.

  • The bgp-evpn command is blocked in mVPLS services; however, a separate mVPLS service can manage a SAP or spoke SDP in a BGP-EVPN service.

• The mac-move command can be used in BGP-EVPN VPLS services for SAPs and SDP bindings; however, the MAC addresses being learned through BGP-EVPN will not be considered.

  Note: The MAC duplication function already provides protection against MAC moves between EVPN and SAPs and SDP bindings.

• The disable-learning command and other FDB-related tools only work for data-plane learned MAC addresses.

• The mac-protect command cannot be used in conjunction with EVPN.

  Note: EVPN provides its own protection mechanism for static MAC addresses.

• MAC OAM tools are not supported for BGP-EVPN services, including the following commands: mac-ping, mac-trace, mac-populate, mac-purge, and cpe-ping.

• SAPs and SDP bindings that belong to a specified ES but are configured on non-BGP-EVPN MPLS-enabled VPLS or Epipe services are kept operationally down with the StandbyForMHProtocol flag.

• CPE ping is not supported for EVPN services. CPE ping packets are not sent over EVPN destinations.

• Other functions not supported in conjunction with the bgp-evpn command include:

  • endpoints and attributes

  • MLD snooping and attributes

  • BPDU translation

  • MAC pinning

BGP routing policies are supported for IP prefixes imported or exported through BGP-EVPN.

When applying routing policies to control the distribution of prefixes between EVPN and IP-VPN, the user must consider that both families are separate as far as BGP is concerned, and when prefixes are imported in the VPRN routing table, the BGP attributes are lost to the other family. The use of route tags allows the controlled distribution of prefixes across the two families.

The following figure shows an example of how VPN-IPv4 routes are imported into the routing table manager (RTM) and then passed to EVPN for processing.

Policy tags can be used to match EVPN IP prefixes that were learned not only from BGP VPN-IPv4 but also from other routing protocols. The tag range supported for each protocol is different:

<tag>  : accepts in decimal or hex
        [0x1..0xFFFFFFFF]H (for OSPF and IS-IS)
        [0x1..0xFFFF]H (for RIP)
        [0x1..0xFF]H (for BGP)

The following figure shows an example of the reverse workflow: routes imported from EVPN and exported from RTM to BGP VPN-IPv4.

The policy behavior for EVPN IP prefixes is summarized in the following statements:

• for EVPN prefix routes received and imported in RTM:

  • policy entries can match on communities and add tags. This works at the peer level or at the vsi-import level.

  • policy entries can match on family evpn

• for exporting RTM to EVPN prefix routes:

  • policy entries can match on tags and based on that, add communities, accept, or reject. This works at the peer level or the virtual switch instance (VSI) export level.

Policy entries can add tags for static routes, RIP, OSPF, IS-IS, and BGP that can then be matched on the BGP peer export policy or VSI export policy for EVPN prefix routes.

The first scenario describes r-VPLS support including IP route advertisement (BGP-EVPN route type 5) with EVPN tunnel interfaces without multihoming. VPLS 101 does not have a connected host, but the linked VPRN has SAP 1/2/1:10. The following figure shows an example of topology used for r-VPLS with an EVPN tunnel but without multihoming. IP prefixes are advertised.

The initial configuration includes the following:

• cards, MDAs, ports

• router interface between PE-2 and PE-3

• IS-IS (or OSPF)

• LDP enabled on the router interface between PE-2 and PE-3

BGP is configured for address family EVPN on PE-2 and PE-3. The BGP configuration on PE-2 is as follows. The BGP configuration on PE-3 is similar.

# on PE-2:
configure
    router
        autonomous-system 64500
        bgp
            family evpn
            vpn-apply-import
            vpn-apply-export
            enable-peer-tracking
            rapid-withdrawal
            rapid-update evpn
            group "internal"
                peer-as 64500
                neighbor 192.0.2.3
                exit
            exit
        exit

The CEs are connected to SAP 1/2/1:10 in VPRN 10. r-VPLS 101 is bound to VPRN 10 and VPRN 10 has a dedicated interface ‟int-evi-101” for the EVPN tunnel. In general, if only one route target (RT) is used for import and export in the EVPN-VPLS, it is best to add the EVI and have the route distinguisher (RD) and RT auto-derived from the EVI; this simplifies the configuration and reduces the chance of errors. The service configuration on PE-2 is as follows:

# on PE-2:
configure
    service
        vprn 10 name "VPRN 10" customer 1 create
            route-distinguisher 192.0.2.2:10
            vrf-target target:64500:10
            interface "int-PE-2-CE-20" create
                address 172.16.2.1/24
                sap 1/2/1:10 create
                exit
            exit
            interface "int-evi-101" create
                vpls "evi-101"
  evpn-tunnel
                exit
            exit
            no shutdown
        exit
        vpls 101 name "evi-101" customer 1 create
            allow-ip-int-bind
            exit
            bgp              // RD and RT are not manually configured in BGP context
            exit
            bgp-evpn
                ip-route-advertisement
                evi 101      // RD and RT will be auto-derived from the EVI
                mpls bgp 1
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            no shutdown
        exit

In the preceding configuration:

• the allow-ip-int-binding command is required so that r-VPLS 101 can be bound to VPRN 10

• the service name is required and the configured name ‟evi-101” must match the name in the VPRN 10 VPLS interface. The service name is configured at service creation time.

• the VPRN 10 VPLS interface is configured with the keyword evpn-tunnel. This configuration has the advantage of not having to allocate IP addresses to the r-VPLS interfaces; however, it cannot be used when the r-VPLS interface has local SAPs.

The configuration is similar on PE-3. The RD must be different on PE-2 and PE-3; this is automatically the case when the RD is auto-derived from the configured EVI, as in the example. The RD on PE-2 is 192.0.2.2:101; on PE-3, the RD is 192.0.2.3:101.

PE-3 receives the following BGP-EVPN IP prefix route for prefix 172.16.2.0/24 from PE-2:

34 2019/09/27 12:21:38.100 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: UPDATE
Peer 1: 192.0.2.2 - Received BGP UPDATE:
    Withdrawn Length = 0
    Total Path Attr Length = 97
    Flag: 0x90 Type: 14 Len: 45 Multiprotocol Reachable NLRI:
        Address Family EVPN
        NextHop len 4 NextHop 192.0.2.2
        Type: EVPN-IP-Prefix Len: 34 RD: 192.0.2.2:101, tag: 0, 
ip_prefix: 172.16.2.0/24 gw_ip 0.0.0.0 Label: 8388464 
    Flag: 0x40 Type: 1 Len: 1 Origin: 0
    Flag: 0x40 Type: 2 Len: 0 AS Path:
    Flag: 0x80 Type: 4 Len: 4 MED: 0
    Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
    Flag: 0xc0 Type: 16 Len: 24 Extended Community:
        target:64500:101
        mac-nh:04:0b:ff:ff:ff:a2
 bgp-tunnel-encap:MPLS
"

GW IP 0.0.0.0 is an indication that an EVPN tunnel is in use. With EVPN tunnels, no IRB IP address needs to be configured in the VPRN. EVPN tunnels make provisioning easier to automate and save IP addresses from the tenant IP space.

The BGP tunnel encapsulation is MPLS, but the MPLS label in the debug message is not the same as in the service, because the router strips the extra four lowest bits to get the 20-bit MPLS label. In the debug message, the label is 8388464. This is because the debug message is shown before the router can parse the label field and see if it corresponds to an MPLS label (20 bits). The MPLS label is calculated by dividing the label value by 24 (16), as follows: 8388464/16 = 524279.

The MAC next-hop extended community 04:0b:ff:ff:ff:a2 is the MAC address of the interface ‟int-evi-101” in VPRN 10 on PE-2, as follows:

*A:PE-2# show service id 10 interface "int-evi-101" detail | match MAC 
MACSec           : N/A
MAC Address      : 04:0b:ff:ff:ff:a2    Mac Accounting    : Disabled

The routing table for VPRN 10 on PE-3 contains the route for prefix 172.16.2.0/24 as the BGP-EVPN route with next-hop ‟int-evi-101” and interface name ‟ET-04:0b:ff:ff:ff:a2” (ET stands for EVPN Tunnel), as follows:

*A:PE-3# show router 10 route-table
 
===============================================================================
Route Table (Service: 10)
===============================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric   
-------------------------------------------------------------------------------
172.16.2.0/24                                 Remote  BGP EVPN  00h06m45s  169
 int-evi-101 (ET-04:0b:ff:ff:ff:a2)                           0
172.16.3.0/24                                 Local   Local     00h06m48s  0
       int-PE-3-CE-30                                               0
-------------------------------------------------------------------------------
No. of Routes: 2
Flags: n = Number of times nexthop is repeated
       B = BGP backup route available
       L = LFA nexthop available
       S = Sticky ECMP requested
===============================================================================

The forwarding database (FDB) for VPLS 101 on PE-3 shows an entry for MAC address 04:0b:ff:ff:ff:a2 that is learned via EVPN. The MAC address is static (S) and protected (P). The MPLS label is 524279.

*A:PE-3# show service id 101 fdb detail 

===============================================================================
Forwarding Database, Service 101
===============================================================================
ServId     MAC               Source-Identifier       Type     Last Change
            Transport:Tnl-Id                         Age      
-------------------------------------------------------------------------------
101        04:0b:ff:ff:ff:a2 eMpls:                  EvpnS:P  09/27/19 12:55:59
                             192.0.2.2:524279
           ldp:65538
101        04:0d:ff:ff:ff:a2 cpm                     Intf     09/27/19 12:55:57
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend:  L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================

When the CEs have IPv6 addresses, the VPRN configuration is similar on the PEs, but the ipv6 context must be enabled on the EVPN tunnel interface so that the router can advertise and process BGP-EVPN type 5 routes with IPv6 prefixes. The configuration of VPLS is identical for IPv4 and IPv6.

# on PE-2:
configure
    service
        vprn 16 name "VPRN 16" customer 1 create
            route-distinguisher 192.0.2.2:16
            vrf-target target:64500:16
            interface "int-PE-2-CE-26" create
                ipv6
                    address 2001:db8:16::2:1/120 
                exit
                sap 1/2/1:16 create
                exit
            exit
            interface "int-evi-106" create
                ipv6
                exit
                vpls "evi-106"
                    evpn-tunnel
                exit
            exit
            no shutdown
        exit
        vpls 106 name "evi-106" customer 1 create
            allow-ip-int-bind
            exit
            bgp
            exit
            bgp-evpn
                ip-route-advertisement
                evi 106
                mpls bgp 1
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            no shutdown
        exit

When advertising IPv6 prefixes, the GW IP field for route type 5 is always populated with the IPv6 address of the r-VPLS interface. In this example, because no specific IPv6 global address is configured, the GW IP will be populated with the auto-created link local address. The following BGP update is received by PE-3 for IPv6 prefix 2001:db8:16::2:0/120:

# on PE-3:
36 2019/09/27 12:21:38.123 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: UPDATE
Peer 1: 192.0.2.2 - Received BGP UPDATE:
    Withdrawn Length = 0
    Total Path Attr Length = 113
    Flag: 0x90 Type: 14 Len: 69 Multiprotocol Reachable NLRI:
        Address Family EVPN
        NextHop len 4 NextHop 192.0.2.2
        Type: EVPN-IP-Prefix Len: 58 RD: 192.0.2.2:106, tag: 0,
ip_prefix: 2001:db8:16::2:0/120 gw_ip fe80::60b:1ff:fe02:1 Label: 8388448 
    Flag: 0x40 Type: 1 Len: 1 Origin: 0
    Flag: 0x40 Type: 2 Len: 0 AS Path:
    Flag: 0x80 Type: 4 Len: 4 MED: 0
    Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
    Flag: 0xc0 Type: 16 Len: 16 Extended Community:
        target:64500:106
        bgp-tunnel-encap:MPLS
"

The IPv6 route table on PE-3 is as follows:

*A:PE-3# show router 16 route-table ipv6 

===============================================================================
IPv6 Route Table (Service: 16)
===============================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric   
-------------------------------------------------------------------------------
2001:db8:16::2:0/120                          Remote  BGP EVPN  00h17m24s  169
       fe80::60b:1ff:fe02:1-"int-evi-106"                          0
2001:db8:16::3:0/120                          Local   Local     00h17m26s  0
       int-PE-3-CE-36                                               0
-------------------------------------------------------------------------------
No. of Routes: 2

The following figure shows an example of the topology with all-active multihoming Ethernet segment (ES) ‟ESI-23”.

BGP is configured between PE-2, PE-3, and PE-4 for address family EVPN. The configuration on PE-2 is as follows:

# on PE-2:
configure
    router
        autonomous-system 64500
        bgp
            family evpn
            vpn-apply-import
            vpn-apply-export
            enable-peer-tracking
            rapid-withdrawal
            rapid-update evpn
            group "internal"
                peer-as 64500
                neighbor 192.0.2.3
                exit
                neighbor 192.0.2.4
                exit
            exit
        exit

All-active multihoming Ethernet segment ‟ESI-23” is configured on PE-2 and PE-3 as follows:

configure
    service
        system
            bgp-evpn
                ethernet-segment "ESI-23" create
                    esi 01:00:00:00:00:23:00:00:00:01
                    es-activation-timer 3
                    service-carving
                        mode auto
                    exit
                    multi-homing all-active
 lag 1
                    no shutdown
                exit

The following services are configured on the PEs:

• VPRN 20 has interfaces bound to VPLS 200 and VPLS 202. On PE-4, VPRN 20 also has an interface bound to VPLS 203.

• VPLS 200 is configured as an EVPN tunnel that connects the PEs.

• VPLS 202 and VPLS 203 have attachment circuits to CEs.

The services are configured on PE-2 as follows. The configuration on PE-3 and PE-4 is similar.

# on PE-2:
configure
    service
        vprn 20 name "VPRN 20" customer 1 create
            route-distinguisher 192.0.2.2:20
            vrf-target target:64500:20
            interface "int-evi-202" create
                address 172.16.20.2/24
                mac 00:ca:fe:00:02:02
                vrrp 1 passive
 backup 172.16.20.254
                    ping-reply
                    traceroute-reply
                exit
                ipv6
                    address 2001:db8:16::20:2/120 
 link-local-address fe80::16:20:2
 vrrp 1 passive
   backup fe80::16:20:fe
                        ping-reply
                        traceroute-reply
                    exit
                exit
                vpls "evi-202"
                exit
            exit
            interface "int-evi-200" create
                ipv6
                exit
                vpls "evi-200"
                    evpn-tunnel
                exit
            exit
            router-advertisement
 interface "int-evi-202"
  use-virtual-mac
  no shutdown
                exit
            exit
            no shutdown
        exit
        vpls 200 name "evi-200" customer 1 create
            allow-ip-int-bind
            exit
            bgp
            exit
            bgp-evpn
                ip-route-advertisement
                evi 200
                mpls bgp 1
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            no shutdown
        exit
        vpls 202 name "evi-202" customer 1 create
            allow-ip-int-bind
            exit
            bgp
            exit
            bgp-evpn
                evi 202
                mpls bgp 1
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            sap lag-1:20 create
            exit
            no shutdown
        exit

The IPv6 VRRP backup address is in the same subnet as the link local address of the interface ‟int-evi-202”. The IPv6 address can be set as preferred. Also for IPv6, router advertisement must be enabled and configured to use the virtual MAC address.

The following figure shows an example of topology with single-active multihoming ES ‟ESI-23”. The difference between this figure and EVPN-MPLS r-VPLS with all-active multihoming ES is that in this figure, the ES is single-active and SDPs are used instead of a LAG.

The configuration is modified as follows:

• LAG 1 is removed from MTU-1, PE-2, and PE-3

• network interfaces are configured between MTU-1 and PE-2/PE-3 with IS-IS and LDP enabled

• SDPs are configured

• ES ‟ESI-23” is redefined as single-active multihoming. The SDP is associated with this ES.

• VPLS 202 on PE-2 and PE-3 no longer has a SAP, but has a spoke SDP instead

• no changes are required on VPRN 20 or VPLS 200

The service configuration on PE-2 is as follows. The configuration on PE-3 is similar. No changes are required on PE-4.

*A:PE-2# configure service 
*A:PE-2>config>service# info 
----------------------------------------------
        system
            bgp-evpn
                ethernet-segment "ESI-23"  create
                    esi 01:00:00:00:00:23:00:00:00:01
                    es-activation-timer 3
                    service-carving
                        mode auto
                    exit
                    multi-homing single-active
sdp 21
                    no shutdown
                exit
            exit
        exit
---snip---
        sdp 21 mpls create
 far-end 192.0.2.1
ldp
            keep-alive
                shutdown
            exit
            no shutdown
        exit
---snip---
        vprn 20 name "VPRN 20" customer 1 create
            route-distinguisher 192.0.2.2:20
            vrf-target target:64500:20
            interface "int-evi-202" create
                address 172.16.20.2/24
                mac 00:ca:fe:00:02:02
                vrrp 1 passive
                    backup 172.16.20.254
                    ping-reply
                    traceroute-reply 
                exit
                ipv6
                    address 2001:db8:16::20:2/120 
                    link-local-address fe80::16:20:2 dad-disable
                    vrrp 1 passive
                        backup fe80::16:20:fe
                        ping-reply
                        traceroute-reply
                    exit
                exit
                vpls "evi-202"
                exit
            exit
            interface "int-evi-200" create
                ipv6
                exit
                vpls "evi-200"
                    evpn-tunnel
                exit
            exit
            router-advertisement
                interface "int-evi-202"
                    use-virtual-mac
                    no shutdown
                exit
            exit
            no shutdown
        exit
        vpls 200 name "evi-200" customer 1 create
            allow-ip-int-bind
            exit
            bgp
            exit
            bgp-evpn
                ip-route-advertisement
                evi 200
                mpls bgp 1
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            stp
                shutdown
            exit
            no shutdown
        exit
        vpls 202 name "evi-202" customer 1 create
            allow-ip-int-bind
            exit
            bgp
            exit
            bgp-evpn
                evi 202
                mpls bgp 1
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            stp
                shutdown
            exit
            spoke-sdp 21:20 create
                no shutdown
            exit
            no shutdown
        exit

PE-2 is the designated forwarder (DF) in the single-active ES, as shown in the following output:

*A:PE-2# show service id 202 ethernet-segment 
No sap entries
===============================================================================
SDP Ethernet-Segment Information
===============================================================================
SDP                   Eth-Seg                          Status
-------------------------------------------------------------------------------
21:20                 ESI-23                           DF
===============================================================================

*A:PE-3# show service id 202 ethernet-segment 
No sap entries
===============================================================================
SDP Ethernet-Segment Information
===============================================================================
SDP                   Eth-Seg                          Status
-------------------------------------------------------------------------------
31:20                 ESI-23                           NDF
===============================================================================

When traffic is sent between CE-11 and CE-41, the FDB on PE-2 is as follows, where MAC address 00:00:01:00:00:11 corresponds to CE-11 and is learned on spoke SDP 21:20, and MAC address 00:00:04:00:00:41 corresponds to CE-41 and his advertised by PE-4 in an EVPN-MAC route.

*A:PE-2# show service id 202 fdb detail 

===============================================================================
Forwarding Database, Service 202
===============================================================================
ServId     MAC               Source-Identifier       Type     Last Change
            Transport:Tnl-Id                         Age      
-------------------------------------------------------------------------------
202        00:00:01:00:00:11 sdp:21:20               L/30     09/27/19 12:24:05
202        00:00:01:00:00:16 sdp:21:20               L/30     09/27/19 12:24:10
202        00:00:04:00:00:41 eMpls:                  Evpn     09/27/19 12:20:38
                             192.0.2.4:524275
           ldp:65539
202        00:00:5e:00:01:01 cpm                     Intf     09/27/19 12:20:19
202        00:00:5e:00:02:01 cpm                     Intf     09/27/19 12:20:19
202        00:ca:fe:00:02:02 cpm                     Intf     09/27/19 12:20:18
202        00:ca:fe:00:02:03 eMpls:                  EvpnS:P  09/27/19 12:20:26
                             192.0.2.3:524274
           ldp:65537
202        00:ca:fe:00:02:04 eMpls:                  EvpnS:P  09/27/19 12:20:37
                             192.0.2.4:524275
           ldp:65539
-------------------------------------------------------------------------------
No. of MAC Entries: 8
-------------------------------------------------------------------------------
Legend:  L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf
===============================================================================

When the SDP between MTU-1 and DF PE-2 goes down, traffic from CE-41 to CE-11 is forwarded by PE-4 to DF PE-2. PE-2 cannot forward the packets to CE-11 directly and will forward the packets to its ES peer PE-3. PE-3 will forward to CE-11 even if the MAC SA matches its own vMAC. Virtual MACs bypass the r-VPLS interface protection, so traffic can be forwarded between the PEs without being dropped.