10.2.1.1. EVPN Route Type 2 – MAC/IP Advertisement Route

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:

Route type 2 uses the fields and values shown in Figure 152 and described in Table 197. 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.

10.2.1.2. EVPN Route Type 3 – Inclusive Multicast Ethernet Tag Route

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.

Figure 152 shows and Table 198 describes the route values used for EVPN-MPLS services. 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.

10.2.1.3. EVPN Route Type 1 – Ethernet Auto-Discovery Route (AD Route)

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

The Ethernet AD per-ESI route uses the fields and values shown in Figure 153 and described in Table 199. 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:

The Ethernet AD per-EVI route uses the fields and values shown in Figure 153 and described in Table 200.

Note: The AD per-EVI route does not send the ESI label extended community field as is done for Ethernet AD per-ESI (see Table 199).

10.2.1.4. EVPN Route Type 4 – Ethernet Segment Route (ES Route)

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

The Ethernet segment route uses the fields and values shown in Figure 153 and described in Table 201. 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.

10.2.1.5. EVPN Route Type 5 – IP Prefix Route

EVPN route type 5 (IP prefix route) is supported for MPLS tunnels. The route fields for route type 5 are shown in Figure 154 and described in Table 202. 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:

Figure 154:  EVPN Route Type 5 

10.2.1.6. RFC 5512 – BGP Tunnel Encapsulation Extended Community

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:

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.

10.2.2.1. Overview

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.

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:

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

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

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:

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.

10.2.2.2. EVPN and VPLS Integration

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.

Figure 155 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.

Figure 155:  EVPN-VPLS Integration 

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

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 MAC advertisements are as follows.

BMU operation on PE1 is as follows.

10.2.2.3. Auto-derived Route Distinguisher (RD) in Services

In a VPLS service, a single RD is used per service.

The following rules apply.

10.2.2.4. EVPN Multihoming in VPLS Services

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.

Note: The esi value is advertised in the control plane to all the PEs in an EVPN network. Therefore, it is very important to ensure that the 10-byte esi value is unique throughout the entire network. Single-homed CEs are assumed to be connected to an Ethernet segment with esi = 0 (that is, single-homed Ethernet segments do not need to be explicitly configured).

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

10.2.2.4.1. EVPN All-Active Multihoming

This section contains information on the following topics:

1. all-active multihoming service mode
2. ES discovery and DF election procedures (all-active multihoming)
3. aliasing
4. network failures and convergence for all-active multihoming

As described in RFC 7432, all-active multihoming is only supported on access LAG SAPs. The CE must be configured with a LAG to avoid duplicated packets to the network. The use of LACP is optional.

Three different procedures are implemented in the 7705 SAR to provide all-active multihoming for a specified Ethernet segment:

1. designated forwarder (DF) election (see Figure 156)
2. split horizon (see Figure 157)
3. aliasing (see Figure 158)

Figure 156 shows the need for DF election in all-active multihoming.

Figure 156:  DF Election 

The DF election in an EVPN all-active multihoming scenario avoids duplicate packets on the multihomed CE. The DF election procedure is responsible for electing one DF PE per ESI per service; the other PEs are non-DF for the ESI and service. Only the DF forwards BMU traffic from the EVPN network toward the ES SAPs (the multihomed CE). The non-DF PEs do not forward BMU traffic to the local Ethernet segment SAPs (see ES Discovery and DF Election Procedures (all-active multihoming) for more information).

Note: BMU traffic from the CE to the network and known unicast traffic in any direction is allowed on both the DF and non-DF PEs.

Figure 157 shows the EVPN split-horizon concept for all-active multihoming.

Figure 157:  Split Horizon 

The EVPN split-horizon procedure ensures that the BMU traffic originated by the multihomed PE and sent from the non-DF to the DF is not replicated back to the CE (echoed packets on the CE). To avoid these echoed packets, the non-DF (PE1) sends all the BMU packets to the DF (PE2) with an indication of the source Ethernet segment. That indication is the ESI label (ESI2 in the example), previously signaled by PE2 in the AD per-ESI route for the Ethernet segment. When PE2 receives an EVPN packet (after the EVPN label lookup), PE2 finds the ESI label that identifies its local Ethernet segment (ESI2). The BMU packet is replicated to other local CEs but not to the ESI2 SAP.

Figure 158 shows the EVPN aliasing concept for all-active multihoming.

Figure 158:  Aliasing 

Because CE2 is multihomed to PE1 and PE2 using an all-active Ethernet segment, aliasing is the procedure by which PE3 can load-balance the known unicast traffic between PE1 and PE2, even if the destination MAC address was only advertised by PE1, as shown in the example. When PE3 installs MAC1 in the FDB, it associates MAC1 not only with the advertising PE (PE1) but also with all the PEs advertising the same esi esi (ESI2) for the service. In this example, PE1 and PE2 advertise an AD per-EVI route for ESI2. Therefore, PE3 installs the two next hops associated with MAC1.

Aliasing is enabled by configuring ECMP to be greater than 1 in the bgp-evpn>mpls context (see Aliasing for more information).

10.2.2.4.1.1. All-Active Multihoming Service Model

The following shows an example where the PE1 configuration provides all-active multihoming to the CE2 shown in Figure 158.

*A:PE1>config>lag(1)# info 

----------------------------------------------

  mode access

  encap-type dot1q

  port 1/1/2

  lacp active administrative-key 1 system-id 00:00:00:00:00:22

  no shutdown

 

*A:PE1>config>service>system>bgp-evpn# info 

----------------------------------------------

  route-distinguisher 1.1.1.1:0

  ethernet-segment "ESI2" create

    esi 01:12:12:12:12:12:12:12:12:12

    multi-homing all-active

    service-carving

    lag 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 all-active multihoming"

  bgp

  bgp-evpn

    evi 10

    mpls

      no shutdown

      auto-bind-tunnel resolution any

  sap lag-1:1 create 

  exit

 

In the same way, PE2 is configured as follows:

*A:PE2>config>lag(1)# info 

----------------------------------------------

  mode access

  encap-type dot1q

  port 1/1/1

  lacp active administrative-key 1 system-id 00:00:00:00:00:22

  no shutdown

 

*A:PE2>config>service>system>bgp-evpn# info 

----------------------------------------------

  route-distinguisher 1.1.1.1:0

  ethernet-segment "ESI12" create

    esi 01:12:12:12:12:12:12:12:12:12

    multi-homing all-active

    service-carving

    lag 1 

    no shutdown

 

*A:PE2>config>redundancy>evpn-multi-homing# info 

----------------------------------------------

    boot-timer 120

    es-activation-timer 10

 

*A:PE2>config>service>vpls# info 

----------------------------------------------

  description "evpn-mpls-service with all-active multihoming"

  bgp

    route-distinguisher 65001:60

    route-target target:65000:60

  bgp-evpn

    evi 10

    mpls

      no shutdown

      auto-bind-tunnel resolution any

  sap lag-1:1 create 

  exit

The preceding configuration enables the all-active multihoming procedures. The following must be considered.

1. The Ethernet segment must be configured with a name and a 10-byte esi esi value:
   1. config>service>system>bgp-evpn>ethernet-segment name create
   2. config>service>system>bgp-evpn>ethernet-segment>esi esi
2. When configuring the esi value, the system enforces the rule that the six high-order octets after the type field are not 0 (so that the auto-derived route target for the ES route is different from 0). Otherwise, the entire esi value must be unique in the system.
3. Only a LAG can be associated with the Ethernet segment. The LAG is used exclusively for EVPN multihoming. Other LAG ports in the system can still be used for MC-LAG and other services.
4. When the LAG is configured on PE1 and PE2, the same admin-key, system-priority, and system-id must be configured on both PEs so that CE2 responds as though it is connected to the same system.
5. Only one SAP per service can be part of the same Ethernet segment.

10.2.2.4.1.2. ES Discovery and DF Election Procedures (all-active multihoming)

The Ethernet segment (ES) discovery and DF election is implemented in three steps (described below and illustrated in Figure 159).

1. Step 1 – ES Advertisement and Discovery
2. Step 2 – DF Election
3. Step 3 – DF and Non-DF Service Behavior

Figure 159:  ES Discovery and DF Election 

10.2.2.4.1.2.1. Step 1 – ES Advertisement and Discovery

Ethernet segment ESI-1 is configured as described in the previous section (All-Active Multihoming Service Model), with all the required parameters. When ethernet-segment>no shutdown is executed, PE1 and PE2 advertise an ES route for ESI-1. Both PEs include the route target auto-derived from the MAC address portion of the configured ESI. If the route target address family is configured in the network, it allows the RR to keep the dissemination of the ES routes under control.

In addition to the ES route, PE1 and PE2 advertise AD per-ESI routes and AD per-EVI routes.

1. AD per-ESI routes announce the Ethernet segment capabilities, including the mode (single-active or all-active) and the ESI label for split horizon.
2. AD per-EVI routes are advertised so that PE3 knows which services (EVIs) are associated with the ESI. These routes are used by PE3 for its aliasing and backup procedures.

10.2.2.4.1.2.2. Step 2 – DF Election

When the exchange of ES routes between PE1 and PE2 is complete, both PEs run the DF election for all the services in the Ethernet segment.

PE1 and PE2 elect a DF for an ESI-service pair (that is, per ESI, per service). The default DF election mechanism in the 7705 SAR is service carving mode auto, as per RFC 7432. The following items apply when the default service carving mode is used on a specified PE. The DF election does not occur until the Ethernet segment is configured as no shutdown.

1. An ordered list of PE IP addresses where ESI-1 resides is built. The IP addresses are obtained from the “Origin IP” fields of all the ES routes received for ESI-1 and also include the local system address. The lowest IP address is considered ordinal “0” in the list.
2. The local IP address can only be considered a candidate after a successful ethernet-segment>no shutdown command for a specified service.

   Note: The remote PE IP addresses must be present in the local PE RTM so that they can participate in the DF election.

3. A PE only considers a specified remote IP address as candidate for the DF election algorithm for a specified service if, in addition to the ES route, the corresponding AD per-ESI and per-EVI routes for that PE have been received and properly activated.
4. All remote PEs receiving the AD per-ES routes (for example, PE3) interpret ESI-1 as all-active if all the PEs send their AD per-ES routes with the single-active bit = 0. Otherwise, if at least one PE sends an AD per-ESI route with the single-active flag set or if the local ESI configuration is single-active, the ESI behavior is single-active.
5. An es-activation-timer can be configured at the redundancy>bgp-evpn-multi-homing>es-activation-timer level or at the service>system>bgp-evpn>ethernet-segment>es-activation-timer level. This timer, which is 3 seconds by default, delays the transition from non-DF to DF for a specified service after the DF election has run.
   1. This use of the es-activation-timer with a value different from 0 minimizes the risk of loops and packet duplication due to multiple DFs in transient states.
   2. The same es-activation-timer value should be configured for all the PEs that are part of the same ESI. The user can configure a long timer to minimize the risk of loops or duplication or a short timer (even es-activation-timer = 0) to speed up the convergence for non-DF to DF transitions. When the user configures a specific value, the value configured at the Ethernet segment level supersedes the configured global value.
6. The DF election is triggered by the following events.
   1. The config>service>system>bgp-evpn>eth-seg>no shutdown command triggers the DF election for all the services in the ESI.
   2. Reception of a new update or withdrawal of an ES route (containing an ESI configured locally) triggers the DF election for all the services in the ESI.
   3. Reception of a new update or withdrawal of an AD per-ES route (containing an ESI configured locally) triggers the DF election for all the services associated with the list of route targets received along with the route.
   4. Reception of a new update of an AD per-ES route with a change in the ESI-label extended community (single-active bit or MPLS label) triggers the DF election for all the services associated with the list of route targets received along with the route.
   5. Reception of a new update or withdrawal of an AD per-EVI route (containing an ESI configured locally) triggers the DF election for that service.

1. When the PE boots up, the boot timer allows the necessary time for the control plane protocols to come up before bringing up the Ethernet segment and running the DF algorithm. The boot timer is configured at the system level (config>redundancy>bgp-evpn-multi-homing>boot-timer) and should have a value long enough to allow the IOMs and BGP sessions to come up before exchanging ES routes and running the DF election for each EVI.
   1. The system does not advertise ES routes until the boot timer expires. This guarantees that the peer ES PEs do not run the DF election until the PE is ready to become the DF, if necessary.
   2. The following show command displays the configured boot timer value as well as the remaining timer value if the system is still in boot stage.
    

            A:PE1# show redundancy bgp-evpn-multi-homing 

            ========================================================================

            Redundancy BGP EVPN Multi-homing Information

            ========================================================================

            Boot-Timer              : 10 secs                 

            Boot-Timer Remaining    : 0 secs                  

            ES Activation Timer     : 3 secs                  

            ========================================================================

1. When the service-carving mode auto command is configured (auto is the default mode), the DF election algorithm runs the following function to identify the DF for a specified service and ESI:
         V mod N = i (ordinal)
   where V is the EVI and N is the number of peers, for example:
   1. as shown in Figure 159, PE1 and PE2 are configured with ESI-1. If V = 10 and N = 2, then V mod N = 0, and PE1 would be elected DF—its IP address is lower than PE2's IP address and it is the first PE in the candidate list.

      Note: The algorithm uses the configured evi value in the service rather than the service-id. The evi value for a service must match for all the PEs that are part of the ESI. This guarantees that the election algorithm is consistent across all the PEs of the ESI. The evi value must always be configured in a service with SAPs or SDP bindings that are created in an ES.

2. The service-carving mode manual command allows the user to manually configure the evi identifiers for which the PE is primary, using the commands:
   service-carving>mode manual and
   service-carving>manual evi start [to to] primary
   1. The system will be the primary PE, forwarding or multicasting traffic for the evi identifiers included in the configuration. The PE will be secondary (non-DF) for the non-specified EVIs.
   2. If a range is configured but the service-carving mode is not manual, the range has no effect.
   3. Only two PEs are supported when service-carving mode manual is configured. If a third PE is configured with service-carving mode manual for an ESI, the two non-primary PEs remain non-DF regardless of the primary status.
   4. For example, as shown in Figure 159, if PE1 is configured with service-carving manual evi 1 to 100 and PE2 with service-carving manual evi 101 to 200, then PE1 will be the primary PE and PE2 will be the secondary PE.
3. When service-carving is disabled, the lowest originator IP address will win the election for a specified service and ESI. The following command disables service carving:
   config>service>system>bgp-evpn>ethernet-segment>service-carving mode off

The following show command displays the Ethernet segment configuration and DF status for all EVIs configured in the Ethernet segment.

*A:PE1# show service system bgp-evpn ethernet-segment name "ESI-1" all 

===============================================================================

Service Ethernet Segment

===============================================================================

Name                    : ESI-1

Admin State             : Up                 Oper State         : Up

ESI                     : 01:00:00:00:00:71:00:00:00:01

Multi-homing            : allActive          Oper Multi-homing  : allActive

Source BMAC LSB         : 71-71              

ES BMac Tbl Size        : 8                  ES BMac Entries    : 1

Lag Id                  : 1                  

ES Activation Timer     : 0 secs             

Exp/Imp Route-Target    : target:00:00:00:00:71:00

 

Svc Carving             : auto               

ES SHG Label            : 262142             

===============================================================================

===============================================================================

EVI Information 

===============================================================================

EVI                 SvcId               Actv Timer Rem      DF

-------------------------------------------------------------------------------

1                   1                   0                   no

-------------------------------------------------------------------------------

Number of entries: 1

===============================================================================

-------------------------------------------------------------------------------

DF Candidate list

-------------------------------------------------------------------------------

EVI                                     DF Address

-------------------------------------------------------------------------------

1                                       192.0.2.69

1                                       192.0.2.72

-------------------------------------------------------------------------------

Number of entries: 2

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

===============================================================================

ISID Information 

===============================================================================

ISID                SvcId               Actv Timer Rem      DF

-------------------------------------------------------------------------------

20001               20001               0                   no

-------------------------------------------------------------------------------

Number of entries: 1

===============================================================================

  

-------------------------------------------------------------------------------

DF Candidate list

-------------------------------------------------------------------------------

ISID                                    DF Address

-------------------------------------------------------------------------------

20001                                   192.0.2.69

20001                                   192.0.2.72

-------------------------------------------------------------------------------

Number of entries: 2

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

===============================================================================

BMAC Information 

===============================================================================

SvcId                                   BMacAddress

-------------------------------------------------------------------------------

20000                                   00:00:00:00:71:71

-------------------------------------------------------------------------------

Number of entries: 1

===============================================================================

10.2.2.4.1.2.3. Step 3 – DF and Non-DF Service Behavior

Based on the result of the DF election or the manual service carving, the control plane on the non-DF (PE1) instructs the data path to remove the LAG SAP associated with the ESI from the default flooding list for broadcast and multicast (BM) traffic. Unknown unicast traffic may still be sent if the EVI label is a unicast label and the source MAC address is not associated with the ESI.

On PE1 and PE2, both LAG SAPs learn the same MAC address (coming from the CE). For example, in the following show commands, 00:ca:ca:ba:ce:03 is learned on both the PE1 and PE2 access LAG (on ESI-1). However, PE1 learns the MAC address as “Learned” whereas PE2 learns it as “Evpn”. This is due to CE2 switching the traffic for that source MAC address to PE1. PE2 learns the MAC address through EVPN but it associates the MAC address with the ESI SAP because the MAC address belongs to the ESI.

*A:PE1# show service id 1 fdb detail 

===============================================================================

Forwarding Database, Service 1

===============================================================================

ServId    MAC               Source-Identifier        Type     Last Change

                                                     Age      

-------------------------------------------------------------------------------

1         00:ca:ca:ba:ce:03 sap:lag-1:1              L/0      06/11/15 00:14:47

1         00:ca:fe:ca:fe:70 eMpls:                   EvpnS    06/11/15 00:09:06

                            192.0.2.70:262140

1         00:ca:fe:ca:fe:72 eMpls:                   EvpnS    06/11/15 00:09:39

                            192.0.2.72:262141

-------------------------------------------------------------------------------

No. of MAC Entries: 3

-------------------------------------------------------------------------------

Legend:  L=Learned O=Oam P=Protected-MAC C=Conditional S=Static

===============================================================================

 

*A:PE2# show service id 1 fdb detail 

===============================================================================

Forwarding Database, Service 1

===============================================================================

ServId    MAC               Source-Identifier        Type     Last Change

                                                     Age      

-------------------------------------------------------------------------------

1         00:ca:ca:ba:ce:03 sap:lag-1:1              Evpn     06/11/15 00:14:47

1         00:ca:fe:ca:fe:69 eMpls:                   EvpnS    06/11/15 00:09:40

                            192.0.2.69:262141

1         00:ca:fe:ca:fe:70 eMpls:                   EvpnS    06/11/15 00:09:40

                            192.0.2.70:262140

-------------------------------------------------------------------------------

No. of MAC Entries: 3

-------------------------------------------------------------------------------

Legend:  L=Learned O=Oam P=Protected-MAC C=Conditional S=Static

===============================================================================

When PE1 (non-DF) and PE2 (DF) exchange BMU packets for evi 1, all the packets are sent with the ESI label included at the bottom of the stack (in both directions). The ESI label advertised by PE1 and PE2 for ESI-1 can be displayed using the following commands:

*A:PE1# show service system bgp-evpn ethernet-segment name "ESI-1" 

===============================================================================

Service Ethernet Segment

===============================================================================

Name                    : ESI-1

Admin State             : Up                 Oper State         : Up

ESI                     : 01:00:00:00:00:71:00:00:00:01

Multi-homing            : allActive          Oper Multi-homing  : allActive

Source BMAC LSB         : 71-71              

ES BMac Tbl Size        : 8                  ES BMac Entries    : 1

Lag Id                  : 1                  

ES Activation Timer     : 0 secs             

Exp/Imp Route-Target    : target:00:00:00:00:71:00

 

Svc Carving             : auto               

ES SHG Label            : 262142             

===============================================================================

 

*A:PE2# show service system bgp-evpn ethernet-segment name "ESI-1" 

 

===============================================================================

Service Ethernet Segment

===============================================================================

Name                    : ESI-1

Admin State             : Up                 Oper State         : Up

ESI                     : 01:00:00:00:00:71:00:00:00:01

Multi-homing            : allActive          Oper Multi-homing  : allActive

Source BMAC LSB         : 71-71              

ES BMac Tbl Size        : 8                  ES BMac Entries    : 0

Lag Id                  : 1                  

ES Activation Timer     : 20 secs            

Exp/Imp Route-Target    : target:00:00:00:00:71:00

 

Svc Carving             : auto               

ES SHG Label            : 262142             

===============================================================================

10.2.2.4.1.3. Aliasing

Following the example in Figure 159, if the service configuration on PE3 has ECMP > 1, then PE3 adds PE1 and PE2 to the list of next hops for ESI-1. As soon as PE3 receives a MAC address for ESI-1, it starts load balancing the flows, per service, between PE1 and PE2 to the remote ESI CE. The following command shows the FDB in PE3.

Note: MAC address 00:ca:ca:ba:ce:03 is associated with the Ethernet segment eES:01:00:00:00:00:71:00:00:00:01 (esi esi configured on PE1 and PE2 for ESI-1).

*A:PE3# show service id 1 fdb detail 

===============================================================================

Forwarding Database, Service 1

===============================================================================

ServId    MAC               Source-Identifier        Type     Last Change

                                                     Age      

-------------------------------------------------------------------------------

1         00:ca:ca:ba:ce:03 eES:                     Evpn     06/11/15 00:14:47

                            01:00:00:00:00:71:00:00:00:01

1         00:ca:fe:ca:fe:69 eMpls:                   EvpnS    06/11/15 00:09:18

                            192.0.2.69:262141

1         00:ca:fe:ca:fe:70 eMpls:                   EvpnS    06/11/15 00:09:18

                            192.0.2.70:262140

1         00:ca:fe:ca:fe:72 eMpls:                   EvpnS    06/11/15 00:09:39

                            192.0.2.72:262141

-------------------------------------------------------------------------------

No. of MAC Entries: 4

-------------------------------------------------------------------------------

Legend:  L=Learned O=Oam P=Protected-MAC C=Conditional S=Static

===============================================================================

The following command shows all the EVPN-MPLS destination bindings on PE3, including the ES destination bindings.

The Ethernet segment eES:01:00:00:00:00:71:00:00:00:01 is resolved to PE1 and PE2 addresses:

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

===============================================================================

BGP EVPN-MPLS Dest

===============================================================================

TEP Address     Egr Label     Num. MACs   Mcast           Last Change

                 Transport                                

-------------------------------------------------------------------------------

192.0.2.69      262140        0           Yes             06/10/2015 14:33:30

                ldp                                        

192.0.2.69      262141        1           No              06/10/2015 14:33:30

                ldp                                        

192.0.2.70      262139        0           Yes             06/10/2015 14:33:30

                ldp                                        

192.0.2.70      262140        1           No              06/10/2015 14:33:30

                ldp                                        

192.0.2.72      262140        0           Yes             06/10/2015 14:33:30

                ldp                                        

192.0.2.72      262141        1           No              06/10/2015 14:33:30

                ldp                                        

192.0.2.73      262139        0           Yes             06/10/2015 14:33:30

                ldp                                        

192.0.2.254     262142        0           Yes             06/10/2015 14:33:30

                bgp                                        

-------------------------------------------------------------------------------

Number of entries : 8

-------------------------------------------------------------------------------

===============================================================================

===============================================================================

BGP EVPN-MPLS Ethernet Segment Dest

===============================================================================

Eth SegId                     TEP Address     Egr Label   Last Change

                                               Transport  

-------------------------------------------------------------------------------

01:00:00:00:00:71:00:00:00:01 192.0.2.69      262141      06/10/2015 14:33:30

                                              ldp          

01:00:00:00:00:71:00:00:00:01 192.0.2.72      262141      06/10/2015 14:33:30

                                              ldp          

01:74:13:00:74:13:00:00:74:13 192.0.2.73      262140      06/10/2015 14:33:30

                                              ldp          

-------------------------------------------------------------------------------

Number of entries : 3

-------------------------------------------------------------------------------

===============================================================================

PE3 performs aliasing for all the MAC addresses associated with that ESI. This is possible because PE1 is configured with ECMP > 1:

*A:PE3>config>service>vpls# info 

----------------------------------------------

            bgp

            exit

            bgp-evpn

                evi 1

                exit

                mpls

                    ecmp 4

                    auto-bind-tunnel

                        resolution any

                    exit

                    no shutdown

                exit

            exit

            proxy-arp

                shutdown

            exit

            stp

                shutdown

            exit

            sap 1/1/1:2 create

            exit

            no shutdown

10.2.2.4.1.4. Network Failures and Convergence for All-Active Multihoming

Figure 160 shows the behavior on the remote PE (PE3) when there is an Ethernet segment failure.

Figure 160:  All-Active Multihoming ES Failure 

The unicast traffic behavior on PE3 is as follows.

1. PE3 can only forward MAC DA = CE2 to both PE1 and PE2 when the MAC advertisement route from PE1 or PE2 and the set of Ethernet AD per-ES routes and Ethernet AD per-EVI routes from PE1 and PE2 are active at PE3.
2. If there is a failure between CE2 and PE2, PE2 withdraws its set of Ethernet AD and ES routes, then PE3 forwards traffic destined for CE2 to PE1 only. PE3 does not need to wait for the withdrawal of the individual MAC address.
3. The same behavior would be followed if the failure had been at PE1.
4. If after (2), PE2 withdraws its MAC advertisement route, PE3 treats traffic to MAC DA = CE2 as unknown unicast, unless the MAC address had been previously advertised by PE1.

For BMU traffic, the following events trigger a DF election on a PE and only the DF forwards BMU traffic after the esi-activation-timer expiration (if there was a transition from non-DF to DF):

1. reception of ES route update (local ES shutdown/no shutdown or remote route)
2. new AD-ES route update or withdrawal
3. new AD-EVI route update or withdrawal
4. local ES port or SAP or service shutdown
5. service-carving range change (affecting the evi)
6. multihoming mode change (single-active to all-active or all-active to single-active)

10.2.2.4.1.4.1. Logical Failures on Ethernet Segments and Black Holes

Figure 161 shows a black hole caused by a SAP or service shutdown.

Figure 161:  Black Hole Caused by SAP or Service Shutdown 

If an individual VPLS service is shutdown in PE1 (the example is also valid for PE2), the corresponding LAG SAP goes operationally down. This event triggers the withdrawal of the AD per-EVI route for that particular SAP. PE3 removes PE1 from its list of aliased next hops and PE2 takes over as DF (if it was not the DF already). However, this does not prevent the network from blackholing the traffic that CE2 switches to the link to PE1. Traffic sent from CE2 to PE2 or traffic from the rest of the CEs to CE2 is unaffected, so this situation is not easily detected on the CE.

The same result occurs if the ES SAP is administratively shutdown instead of the service.

Note: When bgp-evpn>mpls shutdown is executed, the SAP associated with the ES is brought operationally down (StandbyForMHProtocol) and so is the entire service if there are no other SAPs or SDP bindings in the service. However, if there are other SAPs or SDP bindings, the service remains operationally up.

10.2.2.4.1.4.2. Transient Issues Due to MAC Route Delays

Some situations may cause transient issues to occur, such as a transient packet duplication and a transient black hole. These are shown in Figure 162 and explained below.

Figure 162:  Transient Issues Caused by Slow MAC Learning 

1. Transient packet duplication caused by delay in PE3 to learn MAC1:
   This scenario is illustrated by the diagram at the top in Figure 162.
   In an all-active multihoming scenario, if a specified MAC address (for example, MAC1), is not learned yet in a remote PE (for example, PE3) but it is known in the two PEs of the ES (for example, PE1 and PE2), the latter PEs might send duplicated packets to the CE.
   This issue is solved by the use of the ingress-replication-bum-label command in PE1 and PE2. If the command is configured, PE1 and PE2 will know that the received packet is an unknown unicast packet; therefore, the non-DF (PE1) will not send the packets to the CE and there will not be duplication.
   Even if the ingress-replication-bum-label command is not used, this is only a transient situation that is solved as soon as MAC1 is learned in PE3.
2. Transient black hole caused by delay in PE1 to learn MAC1:
   This scenario is illustrated by the diagram at the bottom in Figure 162.
   In an all-active multihoming scenario, MAC1 is known in PE3 and aliasing is applied to MAC1. However, MAC1 is not known yet in PE1, the non-DF for the ES. If PE3 hashing picks up PE1 as the destination for the aliased MAC1, the packets will be blackholed. This case is solved on the non-DF by not blocking unknown unicast traffic that arrives with a unicast label, which is possible if PE1 and PE2 are configured using ingress-replication-bum-label.
   As soon as PE1 learns MAC1, the black hole is resolved even if ingress-replication-bum-label is not used.

10.2.2.4.2. EVPN Single-Active Multihoming

This section provides information on the following topics:

1. single-active multihoming service model
2. ES and DF Election Procedures (single-active multihoming)
3. backup PE function
4. network failures and convergence for single-active multihoming

The 7705 SAR supports single-active multihoming on access SAPs, LAG SAPs, and spoke SDPs for a specified VPLS service. For LAG SAPs, the CE is configured with a different LAG to each PE in the Ethernet segment (as opposed to a single LAG in all-active multihoming).

The following procedures support EVPN single-active multihoming for a specified Ethernet segment:

1. DF election
   As in all-active multihoming, DF election in single-active multihoming determines the forwarding for BMU traffic from the EVPN network to the Ethernet segment CE. Also, in single-active multihoming, DF election determines the forwarding of any traffic (unicast and BMU) in any direction (to or from the CE).
2. backup PE
   In single-active multihoming, the remote PEs do not perform aliasing to the PEs in the Ethernet segment. The remote PEs identify the DF based on the MAC routes and send the unicast flows for the Ethernet segment to the PE in the DF and program a backup PE as an alternative next hop for the remote ESI in case of failure, as shown in Figure 163 for PE3.

   Figure 163:  Backup PE 

   

10.2.2.4.2.1. Single-Active Multihoming Service Model

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

*A:PE1>config>service>system>bgp-evpn# info 

----------------------------------------------

  route-distinguisher 1.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>bgp-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

      no shutdown

      auto-bind-tunnel resolution any

  spoke-sdp 1:1 create 

  exit

 

The PE2 configuration for this scenario is as follows:

*A:PE2>config>service>system>bgp-evpn# info 

----------------------------------------------

  route-distinguisher 1.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:PE2>config>redundancy>bgp-evpn-multi-homing# info 

----------------------------------------------

    boot-timer 120

    es-activation-timer 10

 

*A:PE2>config>service>vpls# info 

----------------------------------------------

  description "evpn-mpls-service with single-active multihoming"

  bgp

  bgp-evpn

    evi 10

    mpls

      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 BMU traffic in both directions (upstream and downstream) on the object associated with the ESI. Single-active multihoming is similar to all-active multihoming with the following differences.

1. The Ethernet segment is configured for single-active: service>system>bgp-evpn>ethernet-segment>multi-homing single-active.
2. The advertisement of the ESI label in an AD per-ESI route is optional for single-active Ethernet segments. By default, the ESI label is used for single-active Ethernet segments. The user can control the no advertisement of the ESI label by using the following command: service>system>bgp-evpn>ethernet-segment>multi-homing single-active no-esi-label.
3. For single-active multihoming, the Ethernet segment can be associated with a port, SDP, or LAG ID, as shown in Figure 163, where:
   1. a port is used for single-active SAP redundancy without the need for a LAG
   2. an SDP is used for single-active spoke SDP redundancy
   3. a LAG ID is used for single-active LAG redundancy

      Note: In the last case (LAG ID for single-active LAG redundancy), the admin-key, system-id, and system-priority values must be different on the PEs that are part of the Ethernet segment.

4. For single-active multihoming, when the PE is non-DF for the service, the SAPs and spoke SDPs on the Ethernet segment are operationally down and show StandbyForMHProtocol as the reason.
5. From a service perspective, single-active multihoming can provide redundancy to CEs (multihomed devices (MHD)) or networks (multihomed networks (MHN)) with the following setup:
   1. LAG with or without LACP
      In this case, the multihomed ports on the CE are part of different LAGs (one LAG per multihomed PE is used in the CE).
   2. regular Ethernet 802.1q/ad ports
      In this case, the multihomed ports on the CE or network are not part of any LAG.
   3. active-standby PWs
      In this case, the multihomed CE or 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 uses the LDP PW status bits to signal that the spoke SDP is operationally down on the PE side.

10.2.2.4.2.2. ES and DF Election Procedures (single-active multihoming)

In all-active multihoming, the non-DF keeps the SAP operationally up, although it removes the SAP from the default flooding list. See the ES Discovery and DF Election Procedures (all-active multihoming) for more information. In the single-active multihoming implementation, the non-DF brings the SAP or SDP binding operationally down.

The following show commands display the status of the single-active Ethernet segment (ESI-7413) in the non-DF. The associated spoke SDP is operationally down and it signals PW status standby to the multihomed CE.

*A:PE1# show service system bgp-evpn ethernet-segment name "ESI-7413"       

 

===============================================================================

Service Ethernet Segment

===============================================================================

Name                    : ESI-7413

Admin State             : Up                 Oper State         : Up

ESI                     : 01:74:13:00:74:13:00:00:74:13

Multi-homing            : singleActive       Oper Multi-homing  : singleActive

Source BMAC LSB         : <none>             

Sdp Id                  : 4                  

ES Activation Timer     : 0 secs             

Exp/Imp Route-Target    : target:74:13:00:74:13:00

 

Svc Carving             : auto               

ES SHG Label            : 262141             

===============================================================================

 

 

*A:PE1# show service system bgp-evpn ethernet-segment name "ESI-7413" evi 1 

===============================================================================

EVI DF and Candidate List

===============================================================================

EVI           SvcId         Actv Timer Rem      DF  DF Last Change

-------------------------------------------------------------------------------

1             1             0                   no  06/11/2015 20:05:32

===============================================================================

===============================================================================

DF Candidates                           Time Added

-------------------------------------------------------------------------------

192.0.2.70                              06/11/2015 20:05:20

192.0.2.73                              06/11/2015 20:05:32

-------------------------------------------------------------------------------

Number of entries: 2

===============================================================================

 

 

*A:PE1# show service id 1 base 

===============================================================================

Service Basic Information

===============================================================================

Service Id        : 1                   Vpn Id            : 0

Service Type      : VPLS                

Name              : (Not Specified)

Description       : (Not Specified)

 

...<snip>...

 

-------------------------------------------------------------------------------

Service Access & Destination Points

-------------------------------------------------------------------------------

Identifier                               Type         AdmMTU  OprMTU  Adm  Opr

-------------------------------------------------------------------------------

sap:1/1/1:1                              q-tag        9000    9000    Up   Up

sdp:4:13 S(192.0.2.74)                   Spok         0       8978    Up   Down

===============================================================================

* indicates that the corresponding row element may have been truncated.

 

 

*A:PE1# show service id 1 all | match Pw 

Local Pw Bits      : pwFwdingStandby

Peer Pw Bits       : None

 

*A:PE1# show service id 1 all | match Flag 

Flags              : StandbyForMHProtocol

Flags              : None

 

10.2.2.4.2.3. Backup PE Function

A remote PE (PE3 in Figure 163) imports the AD routes per ESI, where the single-active flag is set. PE3 interprets the Ethernet segment as single-active if at least one PE sends an AD per-ESI route with the single-active flag set. MAC addresses for a specified service and ESI are learned from a single PE, that is, the DF for that ESI-EVI pair (per ESI, per EVI).

The remote PE installs both a single EVPN-MPLS destination (TEP, label) for a received MAC address and a backup next hop to the PE for which the AD per-ESI and per-EVI routes are received. For example, in the following show command output, 00:ca:ca:ba:ca:06 is associated with the remote Ethernet segment eES 01:74:13:00:74:13:00:00:74:13. That eES resolves to PE 192.0.2.73, which is the DF on the Ethernet segment.

*A:PE3# show service id 1 fdb detail 

===============================================================================

Forwarding Database, Service 1

===============================================================================

ServId    MAC               Source-Identifier        Type     Last Change

                                                     Age      

-------------------------------------------------------------------------------

1         00:ca:ca:ba:ca:02 sap:1/1/1:2              L/0      06/12/15 00:33:39

1         00:ca:ca:ba:ca:06 eES:                     Evpn     06/12/15 00:33:39

                            01:74:13:00:74:13:00:00:74:13

1         00:ca:fe:ca:fe:69 eMpls:                   EvpnS    06/11/15 21:53:47

                            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: 5

-------------------------------------------------------------------------------

Legend:  L=Learned O=Oam P=Protected-MAC C=Conditional S=Static

===============================================================================

 

*A:PE3# 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

-------------------------------------------------------------------------------

===============================================================================

===============================================================================

BGP EVPN-MPLS Ethernet Segment Dest

===============================================================================

Eth SegId                     TEP Address     Egr Label   Last Change

                                               Transport  

-------------------------------------------------------------------------------

01:74:13:00:74:13:00:00:74:13 192.0.2.73      262140      06/11/2015 19:59:03

                                              ldp          

-------------------------------------------------------------------------------

Number of entries : 1

-------------------------------------------------------------------------------

===============================================================================

If PE3 sees only two single-active PEs in the same ESI, the second PE is the backup PE. Upon receiving an AD per-ES or per-EVI route withdrawal for the ESI from the primary PE, PE3 starts sending the unicast traffic to the backup PE immediately.

If PE3 receives AD routes for the same ESI and EVI from more than two PEs, the PE does not install any backup route in the data path. Upon receiving an AD per-ES or per-EVI route withdrawal for the ESI, the PE flushes the MAC addresses associated with the ESI.

10.2.2.4.2.4. Network Failures and Convergence for Single-Active Multihoming

Figure 164 shows the remote PE (PE3) behavior when there is an Ethernet segment failure.

Figure 164:  Single-Active Multihoming ES Failure 

The PE3 behavior for unicast traffic is as follows.

1. PE3 forwards MAC DA = CE2 to PE2 when the MAC advertisement route came from PE2 and the set of Ethernet AD per-ES routes and Ethernet AD per-EVI routes from PE1 and PE2 are active at PE3.
2. If there is a failure between CE2 and PE2, PE2 withdraws its set of Ethernet AD and ES routes, then PE3 immediately forwards the traffic destined for CE2 to PE1 only (the backup PE). PE3 does not need to wait for the withdrawal of the individual MAC address.
3. After PE2 withdraws its MAC advertisement route, PE3 treats traffic to MAC DA = CE2 as unknown unicast, unless the MAC has been previously advertised by PE1.

Also, a DF election on PE1 is triggered. In general, a DF election is triggered by the same events as for all-active multihoming. In this case, the DF forwards traffic to CE2 when the esi-activation-timer expiration occurs (the timer activates when there is a transition from non-DF to DF).

10.2.3.1. BGP-EVPN Control Plane for EVPN-VPWS

EVPN-VPWS uses route type 1 and route type 4; it does not use route types 2 or 3. Figure 165 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.

Figure 165:  EVPN-VPWS BGP Extensions 

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.

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.

Also, ES and AD per-ES routes are 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.

10.2.3.2. EVPN for MPLS Tunnels in Epipe Services

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

Figure 166:  EVPN-MPLS in Epipe Services 

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.

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

The following considerations apply to the configuration.

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

10.2.3.3. Using A/S PW and MC-LAG with EVPN-VPWS Epipes

The use of active/standby (A/S) PW (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. Figure 167 shows the use of both mechanisms in a single Epipe.

Figure 167:  A/S PW and MC-LAG Support on EVPN-VPWS 

In Figure 167, an A/S PW connects the CE to PE1 and PE2 (left-hand side of the diagram), and an MC-LAG connects the CE to PE3 and PE4 (right-hand 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.

10.2.3.4. EVPN Multihoming for EVPN-VPWS Services

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

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.

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

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.

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 (see the example in Figure 168).

10.2.4.1. Overview

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 explained in draft-rabadan-l2vpn-evpnprefix-advertisement.

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

10.2.4.2. EVPN-MPLS Multihoming and Passive VRRP

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

Figure 169 shows an example of EVPN-MPLS multi-homing in r-VPLS services, with the following assumptions.

Figure 169:  EVPN-MPLS Multi-Homing in r-VPLS Services 

In Figure 169, the hosts connected to CE1 and CE4 could 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 multi-homing 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 multi-homing 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 Figure 169 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.

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

10.3.7.1. Interaction of EVPN-MPLS with Existing VPLS Features

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

10.3.7.2. Routing Policies for BGP-EVPN IP Prefixes

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.

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

Note: VPN-IPv4 routes can be tagged at ingress, and that tag is preserved throughout the RTM and EVPN processing so that the tag can be matched at the egress BGP routing policy.

Figure 170:  IP-VPN Import and EVPN Export BGP Workflow 

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:

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

Figure 171:  EVPN Import and IP-VPN Export BGP Workflow  

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

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.