Ethernet Virtual Private Networks

This chapter provides information about Ethernet Virtual Private Networks (EVPN) for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

EVPN applications

EVPN, as described in RFC 7432, BGP MPLS-Based Ethernet VPN, is an IETF technology that uses a new BGP address family and allows Virtual Private LAN Services (VPLS) to operate in a similar manner to IP-VPNs, in which the MAC addresses and information to set up flooding trees are distributed by BGP.

EVPN is designed to fill the gaps of traditional L2VPN technologies, such as VPLS. The main objective of EVPN is to build E-LAN services similar to IP-VPNs defined in RFC 4364, while supporting MAC learning in the control plane (distributed using multi-protocol BGP (MP-BGP)), efficient multi-destination traffic delivery, and single-active/all-active multi-homing.

EVPN can be used as the control plane for different data plane encapsulations. The Nokia implementation supports EVPN for MPLS tunnels (EVPN-MPLS), where PEs are connected by any type of MPLS tunnel. EVPN-MPLS is generally used as an evolution for VPLS services. The EVPN-MPLS functionality is standardized in RFC 7432.

EVPN for MPLS tunnels in E-LAN services

The following figure shows the use of EVPN for MPLS tunnels on the 7210 SAS. In this example, EVPN is used as the control plane for E-LAN services.

Figure 1. EVPN for MPLS in VPLS services

Service providers that offer E-LAN services request EVPN for its multi-homing capabilities and to leverage the optimization EVPN provides.

EVPN supports all-active multi-homing (per-flow load-balancing multi-homing) and single-active multi-homing (per-service load-balancing multi-homing). Although VPLS already supports single-active multi-homing, EVPN single-active multi-homing is deemed the superior technology because of its mass-withdrawal capabilities to speed up convergence in scaled environments.

EVPN technology provides significant benefits, including:

  • IP-VPN-like operation and control for E-LAN services

  • reduction and (in some cases) suppression of the broadcast, unknown unicast, and multicast (BUM) traffic in the network

  • simple provisioning and management

  • new set of tools to control the distribution of MAC addresses and ARP entries in the network

  • potential to use single unified control-plane for both L2 VPN services and L3 VPN services

  • superior multi-homing capabilities

The SR OS EVPN-MPLS implementation is compliant with RFC 7432.

EVPN for MPLS tunnels in E-Line services

The MPLS network used by EVPN for E-LAN services can also be shared by E-Line services using EVPN in the control plane. EVPN for E-Line services (EVPN-VPWS) is a simplification of the RFC 7432 procedures, and is supported on the 7210 SAS in compliance with draft-ietf-bess-evpn-vpws.

EVPN for MPLS tunnels

This section provides information about EVPN for MPLS tunnels (EVPN-MPLS).

BGP-EVPN control plane for MPLS tunnels

The following table lists the EVPN routes supported in 7210 SAS SR OS and their usage in EVPN-MPLS.

Table 1. EVPN routes and usage

EVPN route

Usage

EVPN-MPLS

Type 1 - Ethernet auto-discovery route (A-D)

Mass-withdraw, ESI labels, Aliasing

Yes

Type 2 - MAC/IP advertisement route

MAC/IP advertisement, IP advertisement for ARP resolution

Yes

Type 3 - Inclusive multicast Ethernet Tag route

Flooding tree setup (BUM flooding)

Yes

Type 4 - Ethernet segment (ES) route

ES discovery and DF election

Yes

RFC 7432 describes the BGP-EVPN control plane for MPLS tunnels. If EVPN multi-homing is not required, two route types are needed to set up a basic EVPN Instance (EVI): MAC/IP Advertisement and the Inclusive Multicast Ethernet Tag routes. If multi-homing is required, the ES and the Auto-Discovery routes are also needed.

When EVPN multi-homing is enabled in the system, two additional routes are required. The following figure shows the fields in routes type 1 and 4 and their associated extended communities.

Figure 2. EVPN routes type 1 and 4

EVPN route type 3 — inclusive multicast Ethernet tag route

Route type 3 is used for setting up the flooding tree (BUM flooding) for a specified VPLS service. The received inclusive multicast routes add entries to the VPLS flood list. When BGP-EVPN MPLS is enabled, the standard supports ingress replication, p2mp mLDP, and composite tunnels as tunnel types in route type 3. On the 7210 SAS, only ingress replication is supported.

EVPN route type 2 — MAC/IP advertisement route

The node generates this route type for advertising MAC addresses (and IP addresses if proxy-ARP/proxy-ND is enabled). The router generates MAC advertisement routes for the following entities:

  • learned MACs on SAPs, if the mac-advertisement command is enabled

  • conditional static MACs, if the mac-advertisement command is enabled

  • learned MACs on spoke-SDPs, if the mac-advertisement command is enabled

Note:

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

The route type 2 generated by a router uses the following fields and values:

  • route distinguisher (RD)

    This is taken from the RD of the VPLS service within the BGP context. The RD can be configured or derived from the bgp-evpn evi value.

  • ethernet segment identifier (ESI)

    This is zero (0) for MACs learned from single-homed CEs and different from zero for MACs learned from multi-homed CEs.

  • ethernet tag ID

    This is zero (0).

  • MAC address length

    This is always 48.

  • MAC address

    This is learned or statically configured.

  • IP address and IP address length

    • This is the IP address associated with the MAC being advertised with a length of 32 (or 128 for IPv6).

    • In general, any MAC route without IP has IPL (IP length) = 0 and the IP is omitted.

    • When received, any IPL value not equal to zero, 32, or 128 discards the route.

  • MPLS label 1

    This carries the MPLS label allocated by the system to the VPLS service. The label value is encoded in the high-order 20 bits of the field and is the same label used in type 3 routes for the same service, unless bgp-evpn mpls ingress-replication-bum-label is configured in the service.

  • MPLS label 2

    This is 0.

  • MAC mobility extended community

    This is used for signaling the sequence number in case of mac moves and the ‟sticky” bit in case of advertising conditional static MACs. If a MAC route is received with a MAC mobility of ext-community, the sequence number and the ‟sticky” bit are considered for the route selection.

EVPN route type 1 — Ethernet Auto-Discovery route

The 7210 SAS router generates this route type for advertising for multi-homing functions. The system can generate two types of Ethernet Auto-Discovery (AD) routes:

  • Ethernet AD route per-ESI

  • Ethernet AD route per-EVI

The Ethernet AD per-ESI route generated by a router uses the following fields and values:

  • route distinguisher

    This is taken from the service-level RD.

  • ethernet segment identifier (ESI)

    This contains a 10-byte identifier as configured in the system for a specified ethernet-segment.

  • ethernet tag ID

    This value, MAX-ET (0xFFFFFFFF), is reserved and used only for AD routes per ESI.

  • MPLS label

    This is zero (0).

  • ESI label extended community

    This includes the single-active bit (0 for all-active and 1 for single-active) and ESI label for all-active multi-homing split-horizon.

  • route-target extended community

    This is taken from the service level RT.

The system can send only a separate Ethernet AD per-ESI route per service.

The Ethernet AD per-EVI route generated by a router uses the following fields and values:

  • route distinguisher

    This is taken from the service level RD.

  • ethernet segment identifier (ESI)

    This contains a 10-byte identifier, as configured in the system for a specified ethernet-segment.

  • ethernet tag ID

    This is zero (0).

  • MPLS label

    This encodes the unicast label allocated for the service (high-order 20 bits).

  • route-target extended community

    This is taken from the service level RT.

Note:

The AD per-EVI route is not sent with the ESI label Extended Community.

EVPN route type 4 — ES route

The router generates this route type for multi-homing ES discovery and DF (Designated Forwarder) election.

  • Route Distinguisher

    This is taken from the system level RD.

  • Ethernet Segment Identifier (ESI)

    This contains a 10-byte identifier, as configured in the system for a specified ethernet-segment.

  • ES-import route-target community

    This value is automatically derived from the MAC address portion of the ESI.

    This extended community is treated as a route-target and is supported by RT-constraint (route-target BGP family).

BGP tunnel encapsulation extended community

The following routes are sent with the RFC 5512 BGP Encapsulation Extended Community:

  • MAC/IP

  • Inclusive Multicast Ethernet Tag

  • AD per-EVI routes

ES routes and AD per-ESI routes are not sent with this extended community.

The router processes MPLS encapsulation: 10, the BGP tunnel encapsulation tunnel value registered by IANA for RFC 5512. Any other tunnel value makes the route ‟treat-as-withdraw”.

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 (as defined in RFC 5512) is not present in a received route, BGP treats the route as an MPLS. On the 7210 SAS, only MPLS encapsulation is supported.

EVPN for MPLS tunnels in VPLS services

EVPN can be used in MPLS networks where provider edge (PE) routers are interconnected through any type of MPLS tunnel, including RSVP-TE, LDP, BGP, Segment Routing IS-IS, or Segment Routing OSPF. As with VPRN services, the tunnel selection for a VPLS service (with BGP-EVPN MPLS enabled) is based on the auto-bind-tunnel command.

The EVPN-MPLS VPLS service uses a regular VPLS service where EVPN-MPLS ‟bindings” can coexist with SAPs. The following is a sample configuration output that shows a VPLS service with EVPN-MPLS.

*A:PE-1>config>service>vpls# info
----------------------------------------------
description "evpn-mpls-service"
bgp

bgp-evpn
         evi 10
         mpls
                 auto-bind-tunnel resolution any
                 no shutdown

sap 1/1/1:1 create
exit
-------------------------------------------------

First configure a bgp-evpn context as mpls. In addition, the minimum set of commands that must be configured to set up the EVPN-MPLS instance are the evi and the auto-bind-tunnel resolution commands.

Note:

The EVI and the system IP must be configured before executing the configure>service/vpls>bgp-evpn>mpls>no shutdown command.

The evi value is the EVPN instance (EVI) identifier and is unique in the system. It is used for the service-carving algorithm for multi-homing (if configured) and for auto-deriving route-target and route-distinguishers in EVPN-MPLS services.

If the evi value is not specified, the value is zero and no route-distinguisher or route-targets are auto-derived from it. If it is specified, and no other route-distinguisher or route-target are configured in the service, the following applies:

  • the route-distinguisher is derived from: system_ip:evi

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

Note:

When vsi-import and vsi-export polices are configured, the route-target must be configured in the policies, and those values take precedence over the auto-derived route-targets. The operational route-target for a service is displayed by the show service id svc-id bgp command output. Nokia recommends that the user should not configure a VPLS ID using the bgp-ad>vpls-id command in the service.

When the evi command is configured, a config>service>vpls>bgp node (even empty) is required to output correct information using the show service id 1 bgp and show service system bgp-route-distinguisher commands.

The configuration of an EVI is enforced for EVPN services with SAPs in an Ethernet-segment. See EVPN multi-homing in VPLS services for more information about ESs.

The following options are specific to EVPN-MPLS and are configured in the config>service>vpls>bgp-evpn>mpls context:

  • control-word

    Enable or disable the control-word command to guarantee interoperability to other vendors. In accordance with RFC 7432, this command is required to avoid frame disordering.

  • auto-bind-tunnel

    This command is used to select the type of MPLS transport tunnel used for a specific instance. The command is used in the same way as in VPRN services. See auto-bind-tunnel for more information.

    For BGP-EVPN MPLS, bgp must be 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 pBits of the service-delimiting qtag in a new tag added in the customer frame before sending the frame to the EVPN core.

  • split-horizon-group

    This command associates a user-created split-horizon group to all the EVPN-MPLS destinations. See EVPN and VPLS integration for more information.

  • ecmp

    When this command is set to a value greater than 1, aliasing is activated to the remote PEs that are defined in the same all-active multi-homing ES. See EVPN all-active multi-homing for more information.

  • ingress-replication-bum-label

    When this command is enabled, it allows the PE to advertise a label for BUM traffic (inclusive multicast routes) 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 multi-homing.

In addition to the preceding options, 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” to the remote EVPN destinations are created on each PE. A specified ingress PE creates the following:

  • 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 with a BUM label (only possible if the egress PE is configured with ingress-replication-bum-label)

These bindings, as well as the MACs learned on them, can be checked using the show commands in the following output example, where 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. As a result, the device 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). The following is a sample configuration output.

*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
===============================================================================

EVPN and VPLS integration

In accordance with draft-ietf-bess-evpn-vpls-seamless-integ, the 7210 SAS EVPN implementation allows EVPN-MPLS and VPLS to be integrated to the same network within the same service. Because EVPN is not deployed in greenfield networks, this feature is useful for facilitating the integration between both technologies and for migrating VPLS services to EVPN-MPLS.

The following behavior enables the integration of EVPN and SDP-bindings in the same VPLS network:

  • 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 applies to spoke-SDPs (manual) and mesh-SDPs.

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

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

    • In the case of an SDP-binding and EVPN endpoint to different far-end IPs on the same remote PE, both links are up. This may occur if the SDP-binding is terminated in an IPv4 address that is different from the system address where the EVPN endpoint is terminated.

  • Users can add spoke-SDPs and all the EVPN-MPLS endpoints in the same split-horizon group (SHG):

    • The following CLI command is added under the bgp-evpn>mpls context so that the EVPN-MPLS endpoints can be added to a split-horizon group: bgp-evpn mpls [no] split-horizon-group group-name.

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

    • If the bgp-evpn mpls split-horizon-group command is not used, the default split-horizon group (that contains all the EVPN endpoints) is still used but cannot be referred to using SAPs/spoke-SDPs.

  • The system disables the advertisement of MACs learned on spoke-SDPs or SAPs that are part of an EVPN split-horizon group:

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

    • The preceding statement is also true if proxy-ARP/proxy-ND is enabled and an IP-to-MAC pair is learned on a SAP or SDP-binding that belongs to the EVPN split-horizon group.

    • The SAPs added to an EVPN split-horizon group should not be part of any EVPN multi-homed ES. If that occurs, the PE still advertises the AD per-EVI route for the SAP, attracting EVPN traffic that could not possibly be forwarded to that SAP.

The following figure shows an example of EVPN-VPLS integration.

Figure 3. EVPN-VPLS integration

The following is a sample configuration for PE1, PE5, and PE2 from the EVPN-VPLS integration example in the preceding figure.

*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
  spoke-sdp 12:1 create
  exit
  spoke-sdp 13:1 split-horizon-group "SHG-1" create
  exit
  spoke-sdp 14:1 split-horizon-group "SHG-1" create
  exit
  spoke-sdp 15:1 split-horizon-group "SHG-1" create
  exit
  sap 1/1/1:1 create
  exit

*A:PE5>config>service# info 
----------------------------------------------
split-horizon-group "SHG-1" create
vpls 1 customer 1 create
  bgp
    route-target target:65000:1
  spoke-sdp 52:1 create
  exit
  spoke-sdp 51:1 split-horizon-group "SHG-1" create
  exit
  spoke-sdp 53:1 split-horizon-group "SHG-1" create
  exit
  spoke-sdp 54:1 split-horizon-group "SHG-1" create
  exit

*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

The following applies to the configuration described in the preceding examples:

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

    • PE1, PE3, and PE4 have manual spoke SDPs, but they are kept operationally down as long as there are EVPN endpoints active among them

    • manual spoke SDPs on PE1, PE3, and PE4 and EVPN endpoints are instantiated within the same SHG, for example, the default SHG

    • manual spoke SDPs from PE1 and PE5 to PE2 are not part of the default SHG

  • EVPN MAC advertisements:

    • for spoke SDPs and EVPN in the same SHG, MACs learned locally on a spoke SDP are not advertised in EVPN

  • BUM traffic operation on PE1:

    • when CE1 sends BUM traffic, PE1 floods to all the active bindings

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

    • when CE5 sends BUM traffic, PE5 floods to the three EVPN PEs. PE1 floods to the active spoke SDP and SAPs, never to the EVPN PEs because they are part of the same SHG.

Auto-derived RD in services with multiple BGP families

A single RD is used per service and not per BGP family or protocol. On the 7210 SAS, BGP-AD is not supported with BGP-EVPN.

Note:

On the 7210 SAS, to prevent auto-derived RD in services from using BGP-AD information, Nokia recommends that the user should not configure the bgp-ad>vpls-id command.

The following rules apply:

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

    • manual RD always takes precedence when configured

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

    • if no manual-rd or bgp-evpn>evi configuration exists, there is no RD and the service fails

  • The selected RD (see the preceding selection criteria) is displayed by the Oper Route Dist field of the show service id bgp command.

  • The service supports dynamic RD changes; for example, the manual RD can be updated dynamically, even if it is currently in use as the service RD.

    Note:

    When the RD changes, the active routes for that VPLS are withdrawn and re-advertised with the new RD.

  • If one of the mechanisms to derive the RD for a specified service is removed from the configuration, the system selects a new RD based on the preceding rules. For example, if the manual RD is removed form the configuration, the routes are withdrawn, the new RD is selected from the EVI, and the routes re-advertised with the new RD. See Auto-derived RD in services with multiple BGP families for more information about rules governing the RD selection.

    Note:

    The reconfiguration fails if the new RD already exists in a different VPLS or Epipe service.

EVPN multi-homing in VPLS services

EVPN multi-homing implementation is based on the concept of the Ethernet Segment (ES). An ES is a logical structure that can be defined in one or more PEs and identifies the CE (or access network) multi-homed to the EVPN PEs. An ES is associated with port or LAG objects and shared by all the services defined on those objects. On the 7210 SAS, only the following service objects are allowed to be configured as an ES: port and LAG.

Each ES has a unique Ethernet Segment Identifier (ESI) that is 10 bytes long and is manually configured in the router.

Note:

Because the esi command is advertised in the control plane to all the PEs in the EVPN network, it is 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 ES with esi = 0 (single-homed ESs are not explicitly configured).

EVPN all-active multi-homing

In accordance with RFC 7432, all-active multi-homing is only supported on access LAG SAPs, and it is mandatory to configure the CE with a LAG to avoid duplicated packets to the network. LACP is optional.

When PE3 installs MAC1 in the Forwarding Database (FDB), it associates MAC1 not only with the advertising PE (PE1), but also with all the PEs advertising the same 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.

To enable aliasing, configure ECMP greater than 1 in the bgp-evpn>mpls context.

All-active multi-homing procedures

This sections describes procedures implemented in SR OS to provide all-active multi-homing for a specified ES.

Note:

The 7210 SAS only supports two PEs per ES for all-active multi-homing.

Designated Forwarder election

Using Designated Forwarder (DF) election in EVPN all-active multi-homing prevents duplicate packets on the multi-homed CE. The DF election procedure elects one DF PE per ESI per service; the rest of the PEs are non-DF for the ESI and service. Only the DF forwards BUM traffic from the EVPN network toward the ES SAPs (the multi-homed CE). The non-DF PEs do not forward BUM traffic to the local ES SAPs.

The following figure shows the need for DF election in all-active multi-homing.

Figure 4. DF election
Note:

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

Split-horizon

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

The following figure shows the EVPN split-horizon concept for all-active multi-homing.

Figure 5. Split-horizon
Aliasing

The following figure shows the EVPN aliasing procedure for all-active multi-homing. Because CE2 is multi-homed to PE1 and PE2 using an all-active ES, ‟aliasing” is the procedure by which PE3 can load-balance the known unicast traffic between PE1 and PE2, even if the destination MAC address is only advertised by PE1.

Figure 6. Aliasing

All-active multi-homing service model

The following is a sample output of the PE1 configuration that provides all-active multi-homing to the CE2 shown in Aliasing .

*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 10.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 
      mode auto 
    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 
      ingress-replication-bum-label 
  sap lag-1:1 create  
  exit 

In the same way, PE2 is configured as follows:

*A:PE1>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:PE1>config>service>system>bgp-evpn# info  
---------------------------------------------- 
  route-distinguisher 10.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 
      mode auto 
    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 
    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 following considerations apply when the all-active multi-homing procedure is enabled:

  • The ethernet-segment command must be configured with a name and a 10-byte esi using the config service system bgp-evpn ethernet-segment es_name create and config service system bgp-evpn ethernet-segment esi value commands.

  • When configuring the esi, the system enforces that the 6 high-order octets after the type are not zero, which ensures that the auto-derived route-target for the ES route is not zero). In addition, the entire ESI value must be unique in the system.

  • Only a LAG can be associated with the all-active ES. LAG is used exclusively for EVPN multi-homing. Other LAG ports in the system can continue to be used for MC-LAG and other services.

  • 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 can respond as though it is connected to the same system.

  • Only one SAP per service can be part of the same ethernet-segment.

ES discovery and DF election procedures

The ES discovery and DF election are implemented in three logical steps, as shown in the following figure.

Figure 7. ES discovery and DF election
Step 1 — ES advertisement and discovery

ES ESI-1 is configured with all the required parameters, as described in All-active multi-homing service model. When ethernet-segment no shutdown is executed, PE1 and PE2 advertise an ES route for ESI-1. They both include the route-target auto-derived from the MAC portion of the configured ESI. If the route-target address family is configured in the network, this 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 as follows:

  • AD per-ESI routes announces the ES capabilities, including the mode (single-active or all-active) and the ESI label for split horizon.

  • AD per-EVI routes are advertised so that PE3 knows what services (EVIs) are associated with the ESI. These routes are used by PE3 for its aliasing and backup procedures.

Step 2 — DF election

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

PE1 and PE2 elect a Designated Forwarder (DF) per ESI service. The default DF election mechanism in the SR OS is service-carving (as per RFC 7432). The following applies when the mechanism is enabled on a specified PE:

  • An ordered list of PE IPs where ESI-1 resides is built. The IPs are derived from the origin IP fields of all the ES routes received for ESI-1, as well as the local system address. The lowest IP is considered ordinal ‟0” in the list.

  • The local IP can only be considered a ‟candidate” after successful ethernet-segment no shutdown for a specified service.

    Note:

    The remote PE IPs must be present in the local PE RTM so that they can participate in the DF election.

  • A PE only considers a specified remote IP address as candidate for the DF election algorithm for a specified service if, as well as the ES route, the corresponding AD routes per-ESI and per-EVI for that PE have been received and properly activated.

  • All remote PEs that receive 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 route per-ESI with the single-active flag set or the local ESI configuration is single-active, the ESI behaves as single-active.

  • 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>eth-seg>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:

    • This use of the es-activation-timer is different from zero and minimizes the risks of loops and packet duplication due to ‟transient” multiple DFs.

    • The same es-activation-timer should be configured in all PEs that are part of the same ESI. It is up to the user to configure either a long timer to minimize the risks of loops/duplication or 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 ES level supersedes the configured global value.

  • The DF election is triggered by the following events:

    • The config service system bgp-evpn eth-seg no shutdown command triggers the DF election for all the services in the ESI.

    • 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.

    • 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.

    • 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.

    • Reception of a new update or withdrawal of an AD route per-EVI (containing an ESI configured locally) triggers the DF election for that service.

  • When the PE boots up, the boot-timer allows the necessary time for the control plane protocols to come up before bringing up the ES and running the DF algorithm. The boot-timer is configured at the system level, using the config redundancy bgp-evpn-multi-homing boot-timer command, and should use a value that is long enough to allow the node (with any cards, if available) to boot up and BGP sessions to come up before exchanging ES routes and running the DF election for each EVI/ISID:

    • 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 it needs to.

    • The following show command displays the configured boot-timer and the remaining timer, 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                  
===============================================================================
  • When service-carving mode auto is configured (default mode), the DF election algorithm runs the function [V(evi) mod N(peers) = i(ordinal)] to identify the DF for a specified service and ESI, as described in the following example:

    • As shown in ES discovery and DF election, PE1 and PE2 are configured with ESI-1. Given that V(10) mod N(2) = 0, PE1 are elected DF for VPLS-10 (because its IP address is lower than PE2's and it is the first PE in the candidate list).

      Note:

      The algorithm uses the configured evi in the service and not the service-id. The evi for a service must match in all PEs that are part of the ESI. This guarantees that the election algorithm is consistent across all PEs of the ESI. The evi must be always configured in a service with SAPs that are created in an ES.

  • A service-carving command is supported to manually configure the EVI identifiers for which the PE is primary: service-carving mode manual/manual evi start-evi to end-evi. The following considerations apply:

    • The system is the PE forwarding/multicasting traffic for the evi identifiers included in the configuration. The PE is secondary (non-DF) for the non-specified evi identifiers.

    • If a range is configured but service-carving is not mode manual, the range has no effect.

    • Only two PEs are supported when service-carving mode manual is configured. If manual mode is configured for a third PE for an ESI, the two non-primary PEs remain non-DF regardless of the primary status.

    • For example, as shown in ES discovery and DF election: if PE1 is configured with service-carving manual evi 1 to 100 and PE2 with service-carving manual evi 101 to 200, PE1 is the primary PE for service VPLS 10 and PE2 the secondary PE.

  • If service-carving is disabled, the lowest originator IP wins the election for a specified service and ESI. Use the config service system bgp-evpn eth-seg service-carving mode off command to disable service-carving.

The following sample configuration output shows the ethernet-segment configuration and DF status for all EVIs configured in the ethernet-segment.

*A:Dut-B# /show service system bgp-evpn ethernet-segment name "eslag1" all 
===============================================================================
Service Ethernet Segment
===============================================================================
Name                    : eslag1
Admin State             : Enabled            Oper State         : Up
ESI                     : 00:bc:01:00:00:00:00:00:00:01
Multi-homing            : allActive          Oper Multi-homing  : allActive
Lag Id                  : 1                  
ES Activation Timer     : 3 secs (default)   
Exp/Imp Route-Target    : target:bc:01:00:00:00:00
Svc Carving             : auto               
ES SHG Label            : 131070             
===============================================================================
===============================================================================
EVI Information 
===============================================================================
EVI                 SvcId               Actv Timer Rem      DF
-------------------------------------------------------------------------------
1                   1                   0                   no
-------------------------------------------------------------------------------
Number of entries: 1
===============================================================================
-------------------------------------------------------------------------------
DF Candidate list
-------------------------------------------------------------------------------
EVI                                     DF Address
-------------------------------------------------------------------------------
1                                       10.20.1.2
1                                       10.20.1.3
-------------------------------------------------------------------------------
Number of entries: 2
-------------------------------------------------------------------------------
------------------------------------------------------------------------------- 
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 datapath to remove the LAG SAP (associated with the ESI) from the default flooding list for 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 sample configuration output, 00:ca:ca:ba:ce:03 is learned on both PE1 and PE2 access LAG (on ESI-1). However, PE1 learns the MAC as ‟Learned” whereas PE2 learns it as ‟Evpn”. This is because CE2 hashes the traffic for that source MAC to PE1. And PE2 learns the MAC through EVPN but associates the MAC to the ESI SAP, because the MAC 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 BUM packets for evi 1, the packets are sent including the ESI label at the bottom of the stack (in both directions). The ESI label advertised by each PE for ESI-1 can be displayed using the following command.

*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
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
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             
===============================================================================

Aliasing

As shown in the example in ES discovery and DF election, if the service configuration on PE3 has ECMP > 1, PE3 adds PE1 and PE2 to the list of next-hops for ESI-1. As soon as PE3 receives a MAC for ESI-1, it starts load-balancing between PE1 and PE2 the flows to the remote ESI CE.

Configuration output for the FDB in PE3

The following is a sample configuration output that shows the FDB in PE3.

Note:

MAC 00:ca:ca:ba:ce:03 is associated with the ethernet-segment eES:01:00:00:00:00:71:00:00:00:01 (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
===============================================================================
Configuration output for all EVPN-MPLS destination bindings on PE3

The following is a sample configuration output that shows all the EVPN-MPLS destination bindings on PE3, including the ES destination bindings.

Note:

The ethernet-segment eES:01:00:00:00:00:71:00:00:00:01 is resolved to PE1 and PE2 addresses.

*A:Dut-B# /show service id 1 evpn-mpls 
===============================================================================
BGP EVPN-MPLS Dest
===============================================================================
TEP Address     Egr Label     Num. MACs   Mcast           Last Change
                 Transport                                
-------------------------------------------------------------------------------
10.20.1.3       131069        0           Yes             02/02/2014 15:29:40
                rsvp                                       
10.20.1.4       131069        0           Yes             02/02/2014 15:29:33
                rsvp                                       
10.20.1.5       131059        0           Yes             02/02/2014 15:29:42
                rsvp                                       
-------------------------------------------------------------------------------
Number of entries : 3
-------------------------------------------------------------------------------
===============================================================================
===============================================================================
BGP EVPN-MPLS Ethernet Segment Dest
===============================================================================
Eth SegId                       Num. Macs               Last Change
-------------------------------------------------------------------------------
00:de:01:00:00:00:00:00:00:01   1                       02/02/2014 15:47:04
-------------------------------------------------------------------------------
Number of entries: 1
------------------------------------------------------------------------------- 
PE3 configuration

PE3 performs aliasing for all the MACs associated with that ESI. This is possible because PE1 is configured with ECMP parameter >1. The following is a sample configuration output.

*A:PE3>config>service>vpls# info 
----------------------------------------------
            bgp
            exit
            bgp-evpn
                evi 1
                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

Network failures and convergence for all-active multi-homing

The following figure shows the behavior on the remote PEs (PE3) when there is an ethernet-segment failure.

Figure 8. All-active multi-homing ES failure

The following steps describe the unicast traffic behavior on PE3:

  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. In case of a failure between CE2 and PE2, PE2 withdraws its set of Ethernet AD and ES routes, and PE3 forwards traffic destined for CE2 to PE1 only. PE3 does not need to wait for the withdrawal of the individual MAC.

  3. The same handling is used if the failure was at PE1.

  4. If after step2, PE2 withdraws its MAC advertisement route, PE3 treats traffic to MAC DA = CE2 as unknown unicast, unless PE1 has previously advertised the MAC.

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

  • reception of ES route update (local ES shutdown/no shutdown or remote route)

  • new AD-ES route update/withdraw

  • new AD-EVI route update/withdraw

  • local ES port/SAP/service shutdown

  • service carving range change (affecting the EVI)

  • multi-homing mode change (single/all active to all/single-active)

Logical failures on ESs and black holes

Specific ‟failure scenarios” in the network can trigger effects. The following figure shows some of these scenarios.

Figure 9. Black hole caused by SAP/SVC 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 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 black-holing the traffic that CE2 ‟hashes” to the link to PE1. Because traffic sent from CE2 to PE2 or traffic from the rest of the CEs to CE2 is unaffected, the 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 the bgp-evpn mpls shutdown command is executed, the SAP associated with the ES goes operationally down (StandbyforMHprotocol). If no other SAPs or SDP-bindings are configured in the service, the service also goes operationally down. However, if other SAPs or SDP-bindings are present, the service remains operationally up.

Transient issues due to MAC route delays

The following figure shows scenarios that may cause potential transient issues in the network.

Figure 10. Transient issues caused by ‟slow” MAC learning

In the preceding figure, the scenario on the left shows an example of transient packet duplication caused by delay in PE3 to learn MAC1.

In an all-active multi-homing scenario, if a specified MAC address (for example, MAC1), is not yet learned 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.

Configuring ingress-replication-bum-label in PE1 and PE2 resolves the issue. PE1 and PE2 know that the received packet is an unknown unicast packet; consequently, the NDF (PE1) does not send the packets to the CE, which prevents transient and duplication.

In Transient issues caused by ‟slow” MAC learning, the scenario on the right shows an example of transient black hole caused by delay in PE1 to learn MAC1.

In an all-active multi-homing scenario, MAC1 is known in PE3 and aliasing is applied to MAC1. However, MAC1 is not yet known in PE1, which is the NDF for the ES. If PE3 hashing picks up PE1 as the destination of the aliased MAC1, the packets are blackholed. To resolve this issue, unknown unicast traffic that arrives with a unicast label should not be blocked on the NDF. If PE1 and PE2 are configured using ingress-replication-bum-label, PE3 sends unknown unicast packets with a BUM label and known unicast with a unicast label. In the latter case, PE1 considers it safe to forward the frame to the CE, even if it is unknown unicast.

Note:

This is a transient issue that is resolved as soon as MAC1 is learned in PE1 and the frames are forwarded as known unicast.

EVPN single-active multi-homing

The 7210 SAS SR OS supports single-active multi-homing on access LAG SAPs and regular SAPs for a specified VPLS service. For LAG SAPs, the CE is configured with a different LAG to each PE in the ES (in contrast to a single LAG in an all-active multi-homing).

The following SR OS procedures support EVPN single-active multi-homing for a specified ES:

  • DF election

    The DF election in single-active multi-homing determines the forwarding for BUM traffic from the EVPN network to the ES CE. DF election also determines the forwarding of any traffic (unicast or BUM) in any direction (to or from the CE).

  • backup PE

    In single-active multi-homing, the remote PEs do not perform aliasing to the PEs in the ES. The remote PEs identify the DF based on the MAC routes and send the unicast flows for the ES to the PE in the DF. The remote PEs also program a backup PE as an alternative next-hop for the remote ESI in case of failure. This is in accordance with the Backup PE procedure, defined in RFC 7432.

    The following figure shows an example backup PE for PE3.

    Figure 11. Backup PE

Single-active multi-homing service model

The following example shows a PE1 configuration that provides single-active multi-homing to CE2, as shown in Backup PE.

*A:PE1>config>service>system>bgp-evpn# info 
----------------------------------------------
  route-distinguisher 10.1.1.1:0
  ethernet-segment "ESI2" create
    esi 01:12:12:12:12:12:12:12:12:12
    multi-homing single-active
    service-carving
      mode auto 
    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 single-active multihoming"
  bgp
  bgp-evpn
    evi 10
    mpls
      no shutdown
      auto-bind-tunnel resolution any
  lag 1:1 create 
  exit

The PE2 example configuration for this scenario is as follows.

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

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

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

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

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

  • The advertisement of the ESI-label in an AD per-ESI is optional for single-active ESs. Use the service system bgp-evpn eth-seg multi-homing single-active no-esi-label command to control the ESI label advertisement. By default, the ESI label is also used for single-active ESs.

  • For single-active multi-homing, the ES can be associated with a port or lag-id, as shown in Backup PE, where:

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

    • lag is used for single-active LAG redundancy

      Note:

      For a LAG configured with single-active homing, the LAG parameters key, system-id, and system-priority must be different on the PEs that are part of the ES.

  • For single-active multi-homing, when the PE is non-DF for the service, the SAPs on the ethernet-segment are down and show StandByForMHProtocol as the reason.

  • From a service perspective, single-active multi-homing can provide redundancy to CEs (MHD, Multi-Homed Devices) with the following setup:

    • LAG with or without LACP

      In this case, the multi-homed ports on the CE are part of the different LAGs (a LAG per multi-homed PE is used in the CE).

    • regular Ethernet 802.1q/ad ports

      In this case, the multi-homed ports on the CE/network are not part of any LAG.

ES and DF election procedures

In all-active multi-homing, the non-DF keeps the SAP up, although it removes it from the default flooding list. In the single-active multi-homing implementation, the non-DF brings the SAP operationally down. For more information, see ES discovery and DF election procedures.

The following show command output is an example status of the single-active ESI-7413 in the non-DF.

*A:Dut-D# /show service system bgp-evpn ethernet-segment name "eslag1"     
===============================================================================
Service Ethernet Segment
===============================================================================
Name                    : eslag1
Admin State             : Enabled            Oper State         : Up
ESI                     : 00:de:01:00:00:00:00:00:00:01
Multi-homing            : singleActive       Oper Multi-homing  : singleActive
Lag Id                  : 6                  
ES Activation Timer     : 3 secs (default)   
Exp/Imp Route-Target    : target:de:01:00:00:00:00
Svc Carving             : auto               
ES SHG Label            : 130988             
===============================================================================
*A:Dut-D# /show service system bgp-evpn ethernet-segment name "eslag1" evi 1 
===============================================================================
EVI DF and Candidate List
===============================================================================
EVI           SvcId         Actv Timer Rem      DF  DF Last Change
-------------------------------------------------------------------------------
1             1             0                   no  03/13/2000 11:43:16
===============================================================================
===============================================================================
DF Candidates                           Time Added
-------------------------------------------------------------------------------
10.20.1.4                               03/13/2000 12:00:30
10.20.1.5                               03/13/2000 11:43:16
-------------------------------------------------------------------------------
Number of entries: 2
===============================================================================
*A:Dut-D#        

Backup PE function

In the example in Backup PE, the remote PE3 imports 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 route per-ESI with the single-active flag set. MACs for a specified service and ESI are learned from a single PE, that is, the DF for that <ESI, EVI>.

The remote PE installs a single EVPN-MPLS destination (TEP, label) for a received MAC address and a backup next-hop to the PE for which the AD routes per-ESI and per-EVI are received. For example, in the following show command sample 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. This ES is resolved to PE(192.0.2.73), which is the DF on the ES.

*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:Dut-D# /show service id 1 evpn-mpls 
===============================================================================
BGP EVPN-MPLS Dest
===============================================================================
TEP Address     Egr Label     Num. MACs   Mcast           Last Change
                 Transport                                
-------------------------------------------------------------------------------
10.20.1.2       131061        0           Yes             03/13/2000 11:26:29
                rsvp                                       
10.20.1.2       131062        1           No              03/13/2000 12:10:04
                rsvp                                       
10.20.1.5       131061        0           Yes             03/13/2000 11:18:23
                rsvp                                       
-------------------------------------------------------------------------------
Number of entries : 3
-------------------------------------------------------------------------------
===============================================================================
===============================================================================
BGP EVPN-MPLS Ethernet Segment Dest
===============================================================================
Eth SegId                       Num. Macs               Last Change
-------------------------------------------------------------------------------
00:de:01:00:00:00:00:00:00:01   453                     03/13/2000 12:10:14
-------------------------------------------------------------------------------
Number of entries: 1
-------------------------------------------------------------------------------
===============================================================================
*A:Dut-D# /show service id 1 evpn-mpls esi 00:de:01:00:00:00:00:00:00:01 
===============================================================================
BGP EVPN-MPLS Ethernet Segment Dest
===============================================================================
Eth SegId                       Num. Macs               Last Change
-------------------------------------------------------------------------------
00:de:01:00:00:00:00:00:00:01   453                     03/13/2000 12:10:14
===============================================================================
===============================================================================
BGP EVPN-MPLS Dest TEP Info
===============================================================================
TEP Address              Egr Label                Last Change
                         Transport                
-------------------------------------------------------------------------------

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/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 datapath. Upon receiving an AD per-ES/per-EVI route withdrawal for the ESI, it flushes the MACs associated with the ESI.

Note:

On the 7210 SAS, an ES can be multi-homed to up to two PEs.

Network failures and convergence for single-active multi-homing

The following figure shows an example of remote PE (PE3) behavior when there is an ethernet-segment failure.

Figure 12. Single-active multi-homing ES failure

The following steps list the behavior of the remote PE3 for unicast traffic:

  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. PE3 does not need to wait for the withdrawal of the individual MAC, and immediately forwards the traffic destined for CE2 to PE1 (the backup PE) only.

  3. After the (2) 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.

A DF election on PE1 is also triggered. A DF election is triggered by the same events as all-active multi-homing. In this case, the DF forwards traffic to CE2 when the esi-activation-timer expires; the timer is triggered when a transition from non-DF to DF occurs.

EVPN-VPWS for MPLS tunnels

This section describes the EVPN-VPWS for MPLS tunnels.

BGP-EVPN control plane for EVPN-VPWS

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

Figure 13. EVPN-VPWS BGP extensions
Assuming that the advertising PE has an access SAP 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:
  • The Ethernet tag ID field is encoded with the value configured by the user in the config>service>bgp-evpn>local-ac-name>eth-tag value command.

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

  • The ESI is 0.

  • The route is sent along with an EVPN L2 attributes extended community, as specified in 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

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

EVPN for MPLS tunnels in Epipe services (EVPN-VPWS)

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

Figure 14. EVPN-MPLS VPWS
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, MAC/IP routes, or IP prefix routes.

  • AD Ethernet 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 destination is created for the Epipe.

Epipe 2 as a EVPN-VPWS service between PE2 and PE4

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

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

The following considerations apply to the example configuration:

  • The evi 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 to which 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 force-vlan-vc-forwarding
    • mpls shutdown
  • The following bgp-evpn commands identify the local and remote attachment circuits, with the configured eth-tags encoded in the advertised and received AD Ethernet per-EVI routes:

    • local-ac-name name
    • local-ac-name name eth-tag tag-value; where tag-value [1..16777215]

    • remote-ac-name name
    • remote-ac-name name eth-tag tag-value; where tag-value [1..16777215]

    • Changes on remote Ethernet tags are allowed without shutting down bgp-evpn mpls or the Epipe service. The local-ac eth-tag value cannot be changed without bgp-evpn mpls shutdown.

    • Both local and remote Ethernet tags 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, endpoints are not supported. The vc-switching configuration is not supported on bgp-evpn enabled pipes.

  • EVPN-VPWS Epipes support control-word.

    When bgp-evpn>mpls>control-word 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 does not setup the EVPN destination. As a result, the service does 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 L2 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 setup 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 L2 MTU value is 0, the MTU is ignored.

Note: The 7210 SAS supports the no service-mtu-check command to disable the MTU checks in the dataplane to allow for interop with other PE routers. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide for more information about the packet length used for service MTU enforcement on the 7210 SAS.

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

The use of A/S PW (for access spoke SDPs) and MC-LAG (for access SAPs) provides an alternative redundant solution for EVPN-VPWS that do not use the EVPN multihoming procedures described in draft-ietf-bess-evpn-vpws. The following figure shows the use the mechanism in a single Epipe.

Figure 15. A/S PW and MC-LAG support on EVPN-VPWS

In the preceding figure, an 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). As 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 (in PE1 and PE2).

  • 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, it 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, it advertises the AD EVI route for eth-tag 1.

  • Users can configure MC-LAG for access SAPs using the example configuration of PE3 and PE4 shown in Figure 165. 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 the PE3 advertises the AD per-EVI route for eth-tag 2.

LAG-based LLF for EVPN-VPWS services

The 7210 SAS supports CE-to-CE fault propagation in EVPN-VPWS services by using LAG standby signaling, which can be LACP-based or power-off when the remote CE is using LAG. That is, when detecting a CE failure, an EVPN-VPWS PE withdraws the corresponding autodiscovery per-EVI route, which then triggers the remote PE to signal the fault to the connected CE using LAG standby signaling (either LACP-based or power-off).

The following figure shows an example of link loss forwarding for EVPN-VPWS.

Figure 16. Link loss forwarding for EVPN-VPWS
PE1 configuration
*A:Dut>config> system> oper-group “llf-1” create
*A:Dut>config> system> oper-group> info detail
----------------------------------------------
       hold-time
            group-down nn
            group-up  mm 
       exit
----------------------------------------------

A:PE1>config>lag(1)# info
----------------------------------------------
      mode access
      encap-type null
      port 1/1/1
      port 1/1/2
      standby-signaling power-off 
      monitor-oper-group "llf-1"
      no shutdown
----------------------------------------------

*A:PE1>config>service>epipe# info
----------------------------------------------
       bgp
       exit
       bgp-evpn
             evi 1
                   local-ac-name ac-1
                          eth-tag 1
                   exit
                   remote-ac-name ac-2
                          eth-tag 2
                   exit
             mpls
                   oper-group "llf-1"
                   auto-bind-tunnel
                   resolution any
                   exit
                   no shutdown
             exit
             sap lag-1 create
                   no shutdown
             exit
       no shutdown
----------------------------------------------

The following applies to the PE1 configuration:

  • The EVPN Epipe service is configured on PE1 with a null LAG SAP and the operational group ‟llf-1” under bgp-evpn>mpls. This is the only member of operational group ‟llf-1”.

  • The operational group monitors the status of the BGP-EVPN instance in the Epipe service. The status of the BGP-EVPN instance is determined by the existence of an EVPN destination at the Epipe.

  • In access mode and encap-type null, the LAG is configured with the monitor-oper-group ‟llf-1” command.

As shown in Link loss forwarding for EVPN-VPWS, upon failure on CE2, the following events occur:

  1. PE2 withdraws the EVPN route.

  2. The EVPN destination is removed in PE1 and operational group ‟llf-1” also goes down.

  3. Because lag-1 is monitoring ‟llf-1”, the operational group that is becoming inactive triggers standby signaling on the LAG; that is, power-off or LACP out-of-sync signaling to the CE1.

    When the SAP or port is down because of the LAG monitoring of the operational group, PE1 does not trigger an AD per-EVI route withdrawal, even if the SAP is brought operationally down.

  4. After CE2 recovers and PE2 re-advertises the AD per-EVI route, PE1 creates the EVPN destination and operational group ‟llf-1” comes up. As a result, the monitoring LAG stops signaling standby and the LAG is brought up.

LAG or port standby signaling to the CE on non-DF EVPN PEs (single-active)

As described in EVPN for MPLS tunnels, the EVPN single-active multihoming PEs elected as non-DF must notify their attached CEs, so the CE does not send traffic to the non-DF PE. This scenario is shown in the following figure.

Figure 17. LACP standby signaling from the non-DF

As shown in the preceding figure, the multihomed PEs are configured with multiple EVPN services that use ES-1. ES-1 and its associated LAG is configured as follows:

ES-1 and associated LAG configuration
*A:Dut>config> system> oper-group “SA-1” create
*A:Dut>config> system> oper-group> info detail
----------------------------------------------
       hold-time
              group-down nn 
              group-up  mm
       exit
----------------------------------------------

*A:Dut>config>lag# info
----------------------------------------------
       mode access
       encap-type dot1q
       port 1/1/3
       lacp active administrative-key 32772 system-id 00:00:00:00:00:01 system-priority 1
       monitor-oper-group SA-1
       no shutdown
----------------------------------------------

*A:Dut>config>service>system>bgp-evpn# info
----------------------------------------------
       ethernet-segment "toI" create
              esi 14:13:12:08:00:00:00:00:00:08
              service-carving 
                    mode off
              exit
              multi-homing single-active
              oper-group SA-1
              lag 2
              no shutdown
       exit
----------------------------------------------

When the operational group is configured on the ES and monitored on the associated LAG:

  • The operational group status is driven by the ES DF status (defined by the number of DF SAPs or oper-up SAPs owned by the ES).

  • The operational group goes down if all the SAPs in the ES go down (this happens in PE2 in LACP standby signaling from the non-DF). The ES operational group goes up when at least one SAP in the ES goes up.

    As a result, if PE2 becomes non-DF on all SAPs in the ES, they all go operationally down, including the ES-1 operational group.

  • Because LAG-1 is monitoring the operational group, when its status goes down, LAG-1 signals LAG standby state to the CE. The standby signaling can be configured as LACP or power-off.

  • The ES and AD routes for the ES are not withdrawn because the router recognizes that the LAG becomes standby for the ES operational group.

    Note:
    • The config>lag>monitor-oper-group name command is supported for ports configured in either access or hybrid mode. Any encap-type can be used.

    • With an Epipe configured on the CE to use a single LAG (with active/standby member links) per service to provide uplink redundancy, the 7210 SAS PEs must be configured with a LAG in access port mode, and the system ID and system priority of the LAG should be configured to the same value across all those PEs.

    • With an Epipe or a VPLS configured on the CE to use multiple LAGs per service (with active/standby LAGs) to provide uplink redundancy, the 7210 SAS PEs must be configured with a LAG in either access port mode or hybrid port mode, and the system ID and system priority of the LAG should be configured to a different value across all those PEs.

Operational groups cannot be assigned to ESs that are configured as all-active or service-carving mode auto.

BGP and EVPN route selection for EVPN routes

When two or more EVPN routes are received at a PE, BGP route selection typically takes place when the route key or the routes are equal. When the route key is different, but the PE has to make a selection (for instance, the same MAC is advertised in two routes with different RDs), BGP hands over the routes to EVPN and the EVPN application performs the selection.

EVPN and BGP selection criteria are described below.
  • EVPN route selection for MAC routes

    When two or more routes with the same MAC length/MAC but different route keys are received, BGP hands the routes over to EVPN. EVPN selects the route based on the following tie-break order:

    1. Conditional static MACs (local protected MACs)

    2. EVPN static MACs (remote protected MACs)

    3. Data plane learned MACs (regular learning on SAPs/SDP bindings)

    4. EVPN MACs with higher SEQ number

    5. Lowest IP (next-hop IP of the EVPN NLRI)

    6. Lowest Ethernet tag (that is zero for MPLS and may be different from zero for VXLAN)

    7. Lowest RD

  • BGP route selection for MAC routes with the same route key

    The following priority order is applied:

    1. EVPN static MACs (remote protected MACs)

    2. EVPN MACs with higher sequence number

    3. Regular BGP selection (local preference, AIGP metric, shortest AS-path, lowest IP)

  • BGP route selection for remaining EVPN routes

    The regular BGP selection is followed.

Note: If BGP has to run an actual selection and a specific (otherwise valid) EVPN route "loses" to another EVPN route, the non-selected route is displayed by the show router bgp routes evpn x detail command with a "tie-breaker" reason.

General EVPN topics

This section provides information about general topics related to EVPN.

Note:

Hash labels (that is, the Flow Aware Transport label (RFC 6391)) are not supported with 7210 SAS EVPN VPLS services.

ARP and ND snooping and proxy support

VPLS services support proxy-Address Resolution Protocol (proxy-ARP) and proxy-Neighbor Discovery (proxy-ND) functions that can be enabled or disabled independently per service. When enabled (proxy-ARP or proxy-ND no shutdown), the system populates the corresponding proxy-ARP or proxy-ND table with IP-to-MAC entries learned from the following sources:

  • EVPN-received IP-to-MAC entries

  • user-configured static IP-to-MAC entries

  • snooped dynamic IP-to-MAC entries (learned from ARP, GARP, or NA messages received on local SAPs or SDP-bindings)

In addition, any ingress ARP or ND frame on a SAP or SDP-binding are intercepted and processed. The system answers ARP requests and Neighbor Solicitation messages if the requested IP address is present in the proxy table.

The following figure shows an example proxy-ARP usage in an EVPN network. Proxy-ND functions in a similar way. The MAC address notation in the diagram is shortened for readability.

Figure 18. Proxy-ARP example usage in an EVPN network

In the preceding figure, PE1 is configured as follows:

*A:Dut-B>config>service>vpls# info 
----------------------------------------------
            description "Vpls 1 "
            service-mtu 1400
            split-horizon-group "vpls1" create
                description "Default description for SHG vpls1"
            exit
            bgp
                route-distinguisher auto-rd
                route-target export target:100:1 import target:100:1
                pw-template-binding 100
                exit
            exit
            bgp-evpn
                evi 1
                mpls
                    split-horizon-group "vpls1"
                    ingress-replication-bum-label
                    auto-bind-tunnel
                        resolution-filter
                            ldp
                        exit
                        resolution filter
                    exit
                    no shutdown
                exit
            exit
            stp
                shutdown
            exit
            sap lag-1:1 create
                description "Default sap description for service id 1"
                no shutdown
            exit
            proxy-arp
                age-time 600
                send-refresh 200      
                dup-detect window 3 num-moves 3 hold-down max anti-spoof-
mac 00:aa:aa:aa:aa:aa
                dynamic-arp-populate
                no shutdown
            exit
            no shutdown
----------------------------------------------
*A:Dut-B>config>service>vpls#

Proxy-ARP example usage in an EVPN network shows the following steps, assuming proxy-ARP is no shutdown on PE1 and PE2, and the tables are empty:

  1. ISP-A sends ARP-request for 10.10.10.3.

  2. PE1 learns the MAC 00:01 in the FDB as usual and advertises it in EVPN without any IP. Optionally if the MAC is configured as a Cstatic MAC, it is advertised as a protected MAC to other PEs with the sticky bit set.

  3. The ARP-request is sent to the CPM, where it is handled as follows.

    • An ARP entry (IP 10.1'MAC 00:01) is populated into the proxy-ARP table.

    • EVPN advertises MAC 00:01 and IP 10.1 in EVPN with the same SEQ number and protected bit as the previous route-type 2 for MAC 00:01.

    • A GARP is also issued to other SAPs/SDP-bindings (assuming they are not in the same split-horizon group as the source). If the garp-flood-evpn command is enabled, the GARP message is also sent to the EVPN network.

    • The original ARP-request can still be flooded to the EVPN or not based on the unknown-arp-request-flood-evpn command.

  4. Assuming PE1 was configured with unknown-arp-request-flood-evpn, the ARP-request is flooded to PE2 and delivered to ISP-B. ISP-B replies with its MAC in the ARP-reply. The ARP-reply is finally delivered to ISP-A.

  5. PE2 learns MAC 00:01 in the FDB and the entry 10.1'00:01 in the proxy-ARP table, based on the EVPN advertisements.

  6. When ISP-B replies with its MAC in the ARP-reply, the MAC is handled as follows.

    • MAC 00:03 is learned in FDB at PE2 and advertised in EVPN.

    • MAC 00:03 and IP 10.3 are learned in the proxy-ARP table and advertised in EVPN with the same SEQ number as the previous MAC route.

    • ARP-reply is unicasted to MAC 00:01.

  7. EVPN advertisements are used to populate PE1's FDB (MAC 00:03) and proxy-ARP (IP 10.3 to MAC 00:03) tables as mentioned in5.

From this point onward, the PEs reply to any ARP-request for 00:01 or 00:03 without the need for flooding the message in the EVPN network. By replying to known ARP-requests and Neighbor Solicitations, the PEs help to significantly reduce the flooding in the network.

Use the following commands to customize proxy-ARP/proxy-ND behavior:

  • dynamic-arp-populate and dynamic-nd-populate

    These commands enable the addition of dynamic entries to the proxy-ARP or proxy-ND table (disabled by default). When executed, the system populates proxy-ARP/proxy-ND entries from snooped GARP/ARP/NA messages on SAPs/SDP-bindings, in addition to the entries coming from EVPN (if EVPN is enabled). These entries are shown as dynamic.

  • static ipv4-address mac-address, static ipv4-address mac-address, and static ipv6-address mac-address {host | router}

    These commands configure static entries to be added to the table.

    Note:

    A static IP-to-MAC entry requires the addition of the MAC address to the FDB as either learned or CStatic (conditional static mac) to become active (Status active).

  • age-time seconds

    This command specifies the aging timer per proxy-ARP/proxy-ND entry. When the aging expires, the entry is flushed. The age is reset when a new ARP/GARP/NA for the same IP-to-MAC is received.

  • send-refresh seconds

    If this command is enabled, the system sends ARP-request or Neighbor Solicitation (NS) messages at the configured time, which enables the owner of the IP to reply and, therefore, refresh its IP-to-MAC (proxy-ARP entry) and MAC (FDB entry).

  • table-size table-size

    This command enables the user to limit the number of entries learned on a specified service. By default, the table-size limit is 250.

    Flooding unknown ARP-requests, NS messages, or unsolicited GARPs and NA messages in an EVPN network can be configured using the following commands:

    • proxy-arp [no] unknown-arp-request-flood-evpn

    • proxy-arp [no] garp-flood-evpn

    • proxy-nd [no] unknown-ns-flood-evpn

    • proxy-nd [no] host-unsolicited-na-flood-evpn

    • proxy-nd [no] router-unsolicited-na-flood-evpn

  • dup-detect [anti-spoof-mac mac-address] window minutes num-moves count hold-down minutes | max

    This command enables a mechanism that detects duplicate IPs and ARP/ND spoofing attacks. The following is a summary of the dup-detect command mechanism:

    • Attempts (relevant to dynamic and EVPN entry types) to add the same IP (different MAC) are monitored for window minutes value and when the count value is reached within the configured window, the proxy-ARP/proxy-ND entry for the IP is suspected and marked as duplicate. An alarm is also triggered.

    • The condition is cleared when hold-down time expires (max does not expire) or a clear command is issued.

    • If the anti-spoof-mac command is configured, the proxy-ARP or proxy-ND offending entry's MAC is replaced by the configured mac-address and advertised in an unsolicited GARP/NA for local SAP or SDP-bindings and in EVPN to remote PEs.

    • This mechanism assumes that the same anti-spoof-mac is configured in all PEs for the service, and that traffic with destination anti-spoof-mac received on SAPs/SDP-bindings is dropped. An ingress MAC filter must be configured to drop traffic to the anti-spoof-mac.

The following table shows the combinations that produce a Status = Active proxy-ARP entry in the table. The system only replies to proxy-ARP requests for active entries. Any other combination result in a Status = inActv entry. If the service is not active, the proxy-ARP entries are not active, regardless of the FDB entries

Note:

A static entry is active in the FDB even when the service is down.

Table 2. Proxy-ARP entry combinations

Proxy-ARP entry type

FDB entry type (for the same MAC)

Dynamic

learned

Static

CStatic

EVPN

EVPN, EVPNS with matching ESI

Duplicate

When proxy-ARP or proxy-ND is enabled on services with all-active multi-homed ESs, a proxy-ARP entry type ‟EVPN” may be associated with a ‟learned” FDB entry because the CE can send traffic for the same MAC to all the multi-homed PEs in the ES. In such cases, the entry is inactive, in accordance with Proxy-ARP entry combinations.

Proxy-ARP/ND periodic refresh, unsolicited refresh, and confirm-messages

When proxy-ARP or proxy-ND is enabled, the system starts populating the proxy table and responding to ARP-requests or NS messages. To keep the active IP-to-MAC entries alive and ensure that all the host/routers in the service update their ARP/ND caches, the system may generate the following three types of ARP/ND messages for a specified IP-to-MAC entry:

  • periodic refresh messages (ARP-requests or NS for a specified IP)

    These messages are activated by the send-refresh command and their objective is to keep the existing FDB and proxy-ARP/ND entries alive, in order to minimize EVPN withdrawals and re-advertisements.

  • unsolicited refresh messages (unsolicited GARP or NA messages)

    These messages are sent by the system when a new entry is learned or updated. Their objective is to update the attached host/router caches.

  • confirm messages (unicast ARP-requests or unicast NS messages)

    These messages are sent by the system when a new MAC is learned for an existing IP. The objective of the confirm messages is to verify that a specified IP has moved to a different part of the network and is associated with the new MAC. If the IP has not moved, it forces the owners of the duplicate IP to reply and triggers dup-detect.

Proxy-ND and the Router flag in neighbor advertisement messages

RFC 4861 describes the use of the (R) or ‟Router” flag in NA messages as follows:

  • a node capable of routing IPv6 packets must reply to NS messages with NA messages where the R flag is set (R=1)

  • hosts must reply with NA messages where R=0

The use of the R flag in NA messages impacts how the hosts select their default gateways when sending packets ‟off-link”. Therefore, it is important that the proxy-ND function on the 7210 SAS meet one of the following criteria:

  1. provide the appropriate R flag information in proxy-ND NA replies.

  2. flood the received NA messages if it cannot provide the appropriate R flag when replying

Because of the use of the R flag, the procedure for learning proxy-ND entries and replying to NS messages differs from the procedures for proxy-ARP in IPv4: the router or host flag is added to each entry, and that determines the flag to use when responding to a NS.

Procedure to add the R flag to a specified entry

The procedure to add the R flag to a specified entry is as follows:
  • Dynamic entries are learned based on received NA messages. The R flag is also learned and added to the proxy-ND entry so that the appropriate R flag is used in response to NS requests for a specified IP.

  • Static entries are configured as host or router as per the [no] static ip-address ieee-address {host | router} command.

  • EVPN entries are learned from BGP and the evpn-nd-advertise {host | router} the R flag added to them.

  • In addition, the evpn-nd-advertise {host | router} command indicates what static and dynamic IP-to-MAC entries the system advertises in EVPN. If evpn-nd-advertise router is configured, the system should flood the received unsolicited NA messages for hosts. This is controlled by the [no] host-unsolicited-na-flood-evpn command. The opposite is also recommended, so that the evpn-nd-advertise host is configured using the router-unsolicited-na-flood-evpn command.

BGP-EVPN MAC mobility

EVPN defines a mechanism to allow the smooth mobility of MAC addresses from one CE/NVE to another. The 7210 SAS supports this procedure and the MAC mobility extended community in MAC advertisement routes:

  • The router honors and generates the Sequence (SEQ) number in the MAC mobility extended community for MAC moves.

  • When a MAC is EVPN-learned and it is attempted to be learned locally, a BGP update is sent with SEQ number changed to ‟previous SEQ”+1 (exception: mac-duplication detect num-moves value is reached).

  • A SEQ number = zero or no MAC mobility ext-community are interpreted as sequence zero.

  • In case of mobility, the following MAC selection procedure is followed:

    • If a PE has two or more active remote EVPN routes for the same MAC, the highest SEQ number is selected. The tie-breaker is the lowest IP (BGP NH IP).

    • If a PE has two or more active EVPN routes and it is the originator of one of them, the highest SEQ number is selected. The tie-breaker is the lowest IP (BGP NH IP of the remote route is compared to the local system address).

Note:

When EVPN multi-homing is used in EVPN-MPLS, the ESI is compared to determine whether a MAC received from two different PEs should be processed within the context of MAC mobility or multi-homing. Two MAC routes that are associated with the same remote or local ESI but different PEs are considered reachable through all those PEs. Mobility procedures are not triggered if the MAC route still belongs to the same ESI.

BGP-EVPN MAC duplication

EVPN defines a mechanism to protect the EVPN service from control plane churn as a result of loops or accidental duplicated MAC addresses. The 7210 SAS supports an enhanced version of this procedure, which is described in this section.

In a scenario where two or more hosts are misconfigured using the same (duplicate) MAC address, the duplicate MAC address is learned by the PEs in the VPLS. As a result, the traffic originating from the hosts triggers continuous MAC moves among the PEs attached to the hosts. It is important to recognize such situations and avoid incrementing the sequence number (in the MAC Mobility attribute) to infinity.

To remedy accidentally duplicated MAC addresses, a router that detects a MAC mobility event through local learning starts a window in-minutes timer (the default value is 3). If the configured num-moves num value is detected before the timer expires (the default value is 5), the router concludes that a duplicate MAC situation has occurred and sends a trap message to alert the operator. Use the show service id svc-id bgp-evpn command to display the MAC addresses. The following is a sample configuration output.

10 2014/01/14 01:00:22.91 UTC MINOR: SVCMGR #2331 Base 
"VPLS Service 1 has MAC(s) detected as duplicates by EVPN mac-
duplication detection."
# show service id 1 bgp-evpn 
===============================================================================
BGP EVPN Table
===============================================================================
MAC Advertisement  : Enabled            Unknown MAC Route  : Disabled
MPLS Admin Status : Enabled            Creation Origin    : manual
MAC Dup Detn Moves : 5                  MAC Dup Detn Window: 3
MAC Dup Detn Retry : 9                  Number of Dup MACs : 1
-------------------------------------------------------------------------------
Detected Duplicate MAC Addresses             Time Detected
-------------------------------------------------------------------------------
00:00:00:00:00:12                            01/14/2014 01:00:23
-------------------------------------------------------------------------------
===============================================================================

After a duplicate MAC address is detected, the router stops sending and processing BGP MAC advertisement routes for that MAC address until one of the following occurs:

  1. The MAC is flushed because of a local event (SAP or SDP-binding associated with the MAC fails) or the reception of a remote update with better SEQ number (because of a MAC flush at the remote router).

  2. The retry in-minutes timer expires, which flushes the MAC and restarts the process.

Note:

The other routers in the VPLS instance forward the traffic for the duplicate MAC address to the router advertising the best route for the MAC.

The values of num-moves and window can be configured for different environments. In scenarios where BGP rapid-update EVPN is configured, the operator should configure a shorter window timer than scenarios where BGP updates are sent per the configured min-route-advertisement interval, which is the default.

The preceding MAC duplication parameters can be configured per VPLS service under the bgp-evpn mac-duplication context. The following is a sample configuration output.

MAC duplication parameter configuration

A:Dut-B>config>service>vpls>bgp-evpn# info 
----------------------------------------------
                evi 1
                mac-duplication
                    detect num-moves 5 window 2
                    retry 10
                exit
                mpls
                    split-horizon-group "vpls1"
                    ingress-replication-bum-label
                    auto-bind-tunnel
                        resolution-filter
                            ldp
                        exit
                        resolution filter
                    exit
                    no shutdown
                exit
----------------------------------------------

Conditional static MAC and protection

In RFC 7432, the MAC Mobility Extended Community section defines the use of the sticky bit to signal static MAC addresses. These addresses must be protected to prevent attempts to dynamically learn them in a different place in the EVPN-MPLS VPLS service.

Note:

On the 7210 SAS, the conditional static MACs are not protected using MAC-protect functionality. A Cstatic MAC is advertised to other PEs with the sticky bit set so that it is prevented from being learned dynamically at a different place in the EVPN-MPLS VPLS service. MAC frames whose source MAC address matches the statically configured MAC address are forwarded based on destination MAC address lookup and are not dropped.

In the 7210 SAS, any conditional static MAC address that is defined in an EVPN-MPLS VPLS service is advertised by BGP-EVPN as a static address (that is, with the sticky bit set). The following is a sample output that shows the configuration of a conditional static MAC.

Conditional static MAC configuration

*A:Dut-B>config>service>vpls# info 
----------------------------------------------
            description "evpn mpls service "
……….
            sap lag-1:1 create
                description "Default sap description for service id 1"
                no shutdown
            exit
            static-mac
                mac 00:ca:ca:ca:ca:00 create sap lag-1:1 monitor fwd-status
            exit
A:Dut-C# show router bgp routes evpn mac hunt mac-address 00:ca:ca:ca:ca:00 
……..
===============================================================================
BGP EVPN MAC Routes
===============================================================================
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Network        : n/a
Nexthop        : 10.20.1.2
From           : 10.20.1.2
Res. Nexthop   : 10.10.3.2
Local Pref.    : 100                    Interface Name : ip-10.10.3.3
Aggregator AS  : None                   Aggregator     : None
Atomic Aggr.   : Not Atomic             MED            : 0
AIGP Metric    : None                   IGP Cost       : 400
Connector      : None
Community      : target:100:1 bgp-tunnel-encap:MPLS
                 mac-mobility:Seq:0/Static
Cluster        : No Cluster Members
Originator Id  : None                   Peer Router Id : 10.20.1.2
Flags          : Used  Valid  Best  IGP  
Route Source   : Internal
AS-Path        : No As-Path
EVPN type      : MAC                    
ESI            : 00:bc:01:00:00:00:00:00:00:01
Tag            : 0                      
IP Address     : n/a
Route Dist.    : 2.2.2.2:1              
Mac Address    : 00:ca:ca:ca:ca:00      
MPLS Label1    : LABEL 131056           MPLS Label2    : n/a
Route Tag      : 0                      
Neighbor-AS    : n/a
Orig Validation: N/A                    
Add Paths Send : Default                
Last Modified  : 00h02m02s              
 
-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Routes : 1
===============================================================================

BGP and EVPN route selection for EVPN routes

When two or more EVPN routes are received at a PE, BGP route selection typically takes place when the route key or the routes are equal. When the route key is different, but the PE has to make a selection (for example, the same MAC is advertised in two routes with different RDs), BGP hands over the routes to EVPN and the EVPN application performs the selection.

EVPN and BGP selection criteria are as follows:

  • EVPN route selection for MAC routes

    When two or more routes with the same mac-length/mac but different route key are received, BGP transfers the routes to EVPN. EVPN selects the route based on the following tie-breaking order:

    1. conditional static MACs (local protected MACs)

    2. EVPN static MACs (remote protected MACs)

    3. data plane learned MACs (regular learning on SAPs/SDP-bindings)

    4. EVPN MACs with higher SEQ number

    5. lowest IP (next-hop IP of the EVPN NLRI)

    6. lowest Ethernet tag (that is zero for MPLS)

    7. lowest RD

  • BGP route selection for MAC routes with the same route-key

    The priority order is as follows:

    1. EVPN static MACs (remote protected MACs)

    2. EVPN MACs with higher sequence number

    3. regular BGP selection (local-pref, aigp metric, shortest as-path, …, lowest IP)

  • BGP route selection for the rest of the EVPN routes follows regular BGP selection

Note:

If BGP runs through the selection criteria and a specified and valid EVPN route is not selected in favor of another EVPN route, the non-selected route is displayed by the show router bgp routes evpn evpn-type detail command with a tie-breaker reason.

EVPN interaction with other features

This section describes the interaction of EVPN with other features.

EVPN-MPLS with existing VPLS features

When enabling existing VPLS features in an EVPN-MPLS-enabled service, the following considerations apply:

  • EVPN-MPLS is only supported in regular VPLS. Other VPLS types, such as m-vpls, are not supported.

  • In general, no router-generated control packets are sent to the EVPN destination bindings, except for proxy-ARP/proxy-ND confirm messages for EVPN-MPLS.

  • For xSTP and M-VPLS services, the following applies.

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

    • BGP-EVPN is blocked in M-VPLS services; however, a different M-VPLS service can manage a SAP or spoke-SDP in a BGP-EVPN-enabled service.

  • For BGP-EVPN-enabled VPLS services, mac-move can be used in SAPs/SDP-bindings; however, MACs learned through BGP-EVPN are not considered.

    Note:

    MAC duplication provides protection against MAC moves between EVPN and SAPs/SDP-bindings.

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

  • MAC OAM tools (mac-ping, mac-trace, mac-populate, mac-purge, and cpe-ping) are not supported for BGP-EVPN services.

  • SAPs that belong to a specified ES but are configured on non-BGP-EVPN-MPLS-enabled VPLS or Epipe services are kept down using the StandByForMHProtocol flag.

  • CPE ping is not supported on EVPN services.

  • Other features not supported in conjunction with BGP-EVPN are:

    • endpoints and attributes

    • BPDU translation

    • L2PT termination

    • MAC-pinning

    • IGMP snooping in VPLS services when BGP-EVPN MPLS is enabled (in the service)

    • DHCP snooping

    • ETH-CFM (MEPs, vMEPs, MIPs)

    • allow-ip-int-bind (R-VPLS)

EVPN with G.8032 in an access ring

It is possible to use the G.8032 operation in an access ring with EVPN. The only supported configuration is a G.8032 sub-ring with a non-virtual link and without MAC flush propagation from the EVPN network to the G.8032 sub-ring. This section provides a sample configuration and guidelines about the configuration.

The following figure shows the network topology of an access ring with EVPN. It shows a G.8032 sub-ring formed by nodes G, B, C on the left side of the figure and nodes A, D, E on the right side of the figure, connected to the EVPN network formed by nodes B, C, D, E.

Figure 19. Network topology of an access ring

Nodes B, C, D, E connect to both the EVPN network using network ports and to the G.8032 ring using access ports. For example, on node B, network ports 1/1/7, 1/1/1, and 1/1/6 connect PE-B to remote EVPN nodes D, E, C, respectively. Additionally, on node B, access port 1/1/22 is part of the G.8032 access ring that connects PE-B to the G.8032 ring formed with access CE node G.

EVPN bindings are protected by using fast reroute (FRR) paths; however, in the event a failure occurs in the EVPN network, MAC flush is not propagated from the EVPN network to the G.8032 ring.

G.8032 data SAPs and control SAPs on the EVPN PE nodes (B, C, D, E) can be configured only on non-ES ports. Non-ES LAGs cannot be used with G.8032 on 7210 SAS.

The following is a sample configuration of the access CE node, node A in Network topology of an access ring, which is part of the G.8032 access ring.

#--------------------------------------------------
echo "System Configuration"
#--------------------------------------------------
    system
        name "Dut-A"
#--------------------------------------------------
echo "Ethernet Rings Configuration"
#--------------------------------------------------
    eth-ring 124
    exit
    eth-ring 124
        description "Ethernet Ring 124"
        guard-time 20
        revert-time 60
        rpl-node owner
        path a 1/1/1 raps-tag 124
            description "Ethernet Ring : 124 Path : pathA"
            rpl-end
            eth-cfm
                mep 6 domain 1 association 1241
                    ccm-enable
                    control-mep
                    control-sap-tag 724
                    no shutdown
                exit
            exit
            no shutdown
        exit
        path b 1/1/2 raps-tag 124
            description "Ethernet Ring : 124 Path : pathB"
            eth-cfm
                mep 7 domain 1 association 1242
                    ccm-enable
                    control-mep
                    control-sap-tag 724
                    no shutdown
                exit
            exit
            no shutdown
        exit
        no shutdown
    exit
#--------------------------------------------------
------snipped------------
#--------------------------------------------------
echo "Service Configuration"
#--------------------------------------------------
    service
        customer 1 create
            description "Default customer"
        exit
        vpls 1 customer 1 svc-sap-type any create
            description "Default tls description for service id 1"
            disable-learning
            
            stp
                shutdown
            exit
            sap 1/1/5:1 create
                description "Default sap description for service id 1"
                egress
                exit
            exit
            sap 1/1/1:1 eth-ring 124 create
                stp
                    shutdown
                exit
                egress
                exit
            exit
            sap 1/1/2:1 eth-ring 124 create
                stp
                    shutdown
                exit
                egress
                exit
            exit
            no shutdown
        exit
        vpls 124 customer 1 vpn 124 svc-sap-type any create
            description "Default tls description for service id 124"
            stp
                shutdown
            exit
            sap 1/1/1:124 eth-ring 124 create
                description "SAP 1/1/1:124 on Ethernet Ring 124 "
                stp
                    shutdown
                exit
                egress
                exit
            exit
            sap 1/1/2:124 eth-ring 124 create
                description "SAP 1/1/2:124 on Ethernet Ring 124 "
                stp
                    shutdown
                exit
                egress
                exit
            exit
            no shutdown
        exit
    exit
#--------------------------------------------------

The following is a sample configuration of an EVPN PE node, node D in Network topology of an access ring.

#--------------------------------------------------
echo "System Configuration"
#--------------------------------------------------
    system
        name "Dut-D"
---------snipped-------------
#--------------------------------------------------
echo "Ethernet Rings Configuration"
#--------------------------------------------------
    eth-ring 124
    exit
    eth-ring 124
        description "Ethernet Ring 124"
        guard-time 20
        path a 1/1/21 raps-tag 124
            description "Ethernet Ring : 124 Path : pathA"
            eth-cfm
                mep 5 domain 1 association 1243
                    ccm-enable
                    control-mep
                    control-sap-tag 724
                    no shutdown
                exit
            exit
            no shutdown
        exit
        no shutdown
    exit
#--------------------------------------------------
--------snipped-----------------
#--------------------------------------------------
echo "Service Configuration"
#--------------------------------------------------
    service
        sdp 42 mpls create
            far-end 10.20.1.2
            ldp
            path-mtu 1600
            keep-alive
                shutdown
            exit
            no shutdown
        exit
        sdp 43 mpls create
            far-end 10.20.1.3
            ldp
            path-mtu 1600
            keep-alive
                shutdown
            exit
            no shutdown
        exit
        sdp 45 mpls create
            far-end 10.20.1.5
            ldp
            path-mtu 1600
            keep-alive
                shutdown
            exit
            no shutdown
        exit
        customer 1 create
            description "Default customer"
        exit
        system
            bgp-evpn
                ethernet-segment "esPort1" create
                    esi 00:de:03:00:00:00:00:00:00:03
                    service-carving
                        mode auto
                    exit
                    multi-homing single-active no-esi-label
                    shutdown
                exit
            exit
        exit
        vpls 1 customer 1 svc-sap-type any create
            description "Default tls description for service id 1"
            split-horizon-group "vpls1" create
                description "Default description for SHG vpls1"
            exit
            bgp-evpn
                evi 1
                mpls
                    control-word
                    force-vlan-vc-forwarding
                    split-horizon-group "vpls1"
                    ingress-replication-bum-label
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            stp
                shutdown
            exit
            sap 1/1/21:1 eth-ring 124 create
                stp
                    shutdown
                exit
                egress
                exit
            exit
            no shutdown
        exit
        vpls 124 customer 1 vpn 124 svc-sap-type any create
            description "Default tls description for service id 124"
            stp
                shutdown
            exit
            sap 1/1/21:124 eth-ring 124 create
                description "SAP 1/1/21:124 on Ethernet Ring 124 "
                stp
                    shutdown
                exit
                egress
                exit
            exit
            no shutdown
        exit
    exit
#--------------------------------------------------
echo "Router (Service Side) Configuration"
#--------------------------------------------------
    router Base
#--------------------------------------------------
echo "BGP Configuration"
#--------------------------------------------------
        bgp
            connect-retry 1
            min-route-advertisement 1
            rapid-withdrawal
            bfd-enable
            group "bgpEvpn"
                peer-as 100
                bfd-enable
                neighbor 10.20.1.2
                    family evpn
                    peer-as 100
                    bfd-enable
                exit
                neighbor 10.20.1.3
                    family evpn
                    peer-as 100
                    bfd-enable
                exit
                neighbor 10.20.1.5
                    family evpn
                    peer-as 100
                    bfd-enable
                exit
            exit
            no shutdown
        exit 
#--------------------------------------------------

Routing policies for BGP EVPN routes

Routing policies match on specific fields when importing or exporting EVPN routes. These matching fields are the following:

  • communities (comm-val), extended communities (ext-comm), and large communities (large-comm)

  • well-known communities (well-known-comm); no-export | no-export-subconfed | no-advertise

  • family EVPN

  • protocol BGP-VPN (this term also matches VPN-IPv4/6 routes)

  • BGP attributes that are applicable to EVPN routes (such as AS-path, local-preference, next-hop)

Configuring an EVPN service with CLI

This section provides information to configure EVPN services using the CLI for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

EVPN-MPLS configuration examples

This section provides EVPN-MPLS configuration examples.

EVPN all-active multi-homing example

This section shows a configuration example, specified by the following assumptions:

  • PE-1 and PE-2 are multi-homed to CE-12 that uses a LAG to get connected to the network. CE-12 is connected to LAG SAPs configured in an all-active multi-homing ES.

  • PE-3 is a remote PE that performs aliasing for traffic destined for the CE-12

The following configuration example applies to a VPLS-1 on PE-1 and PE-2, as well as the corresponding ethernet-segment and lag commands.

*A:Dut-C>config>lag# info 
----------------------------------------------
        mode access
        encap-type dot1q
        port 1/4/6
        lacp active administrative-key 1 system-id 00:00:00:00:69:72
        no shutdown
----------------------------------------------
*A:Dut-C>config>lag# /configure service system bgp-evpn 
*A:Dut-D>config>service>system>bgp-evpn>eth-seg# info 
----------------------------------------------
                esi 00:de:01:00:00:00:00:00:00:01
                service-carving
                    mode auto
                exit
                multi-homing all-active
                lag 6
                no shutdown
----------------------------------------------
 description "Default tls description
            split-horizon-group "vpls1" create
                description "Default description for SHG vpls1"
            exit
            bgp-evpn
                evi 1
                mpls
                    control-word
                    split-horizon-group "vpls1"
                    ingress-replication-bum-label
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            stp
                shutdown
            exit
            sap lag-6:1 create
                description "Default sap description for service id 1"
                egress
                exit
            exit
            static-mac
                mac 00:81:00:00:00:02 create sap lag-6:1 monitor fwd-status
            exit
            no shutdown
*A:Dut-C>config>service>vpls#         
A:Dut-B>config>lag# info 
*A:Dut-E>config>service>system>bgp-evpn>eth-seg# info 
----------------------------------------------
                esi 00:de:01:00:00:00:00:00:00:01
                service-carving
                    mode auto
                exit
                multi-homing all-active
                lag 6
                no shutdown
----------------------------------------------
*A:Dut-B>config>service>system>bgp-evpn# /configure service vpls 1 
*A:Dut-E>config>service>vpls# info 
----------------------------------------------
            description "Default tls description for service id 1"
            split-horizon-group "vpls1" create
                description "Default description for SHG vpls1"
            exit
            bgp-evpn
                evi 1
                mpls
                    control-word
                    split-horizon-group "vpls1"
                    ingress-replication-bum-label
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            stp
                shutdown
            exit
            sap lag-6:1 create
                description "Default sap description for service id 1"
                egress
                exit
            exit
            no shutdown

The configuration on the remote PE (for example, PE-3), which supports aliasing to PE-1 and PE-2, is shown below. PE-3 does not have any ES configured and to perform aliasing requires only the VPLS-1 configuration and ecmp>1.

*A:PE3>config>service>vpls# info 
----------------------------------------------
            bgp
            exit
            bgp-evpn
                evi 1
                mpls
                    ingress-replication-bum-label
                    ecmp 4
                    auto-bind-tunnel
                        resolution any
                    exit
                    no shutdown
                exit
            exit
            stp
                shutdown
            exit
            sap 1/1/1:1 create
            exit
            spoke-sdp 4:13 create
                no shutdown
            exit
            no shutdown
----------------------------------------------

EVPN single-active multi-homing example

To use single-active multi-homing on PE-1 and PE-2 instead of all-active multi-homing perform the following:

  • change the LAG configuration to multi-homing single-active

    The CE-12 is now configured with two different LAGs; therefore, the key, system ID, and system priority values must be different on PE-1 and PE-2

  • change the Ethernet segment configuration to multi-homing single-active

No changes are needed at the service level on any of the three PEs.

Single-active and all-active multi-homing

The following configuration example shows the differences between single-active multi-homing and all-active multi-homing.

A:PE1# configure lag 1 
A:PE1>config>lag# info 
----------------------------------------------
        mode access
        encap-type dot1q
        port 1/1/2 
        lacp active administrative-key 1 system-id 00:00:00:00:69:69 
        no shutdown
----------------------------------------------
A:PE1>config>lag# /configure service system bgp-evpn 
A:PE1>config>service>system>bgp-evpn# info 
 esi 00:de:01:00:00:00:00:00:00:01
                service-carving
                    mode auto
                exit
                multi-homing single-active
                lag 6
                no shutdown
----------------------------------------------
A:PE2# configure lag 1 
A:PE2>config>lag# info 
----------------------------------------------
        mode access
        encap-type dot1q
        port 1/1/3 
        lacp active administrative-key 1 system-id 00:00:00:00:72:72 
        no shutdown
----------------------------------------------
A:PE2>config>lag# /configure service system bgp-evpn 
A:PE2>config>service>system>bgp-evpn# info 
 esi 00:de:01:00:00:00:00:00:00:01
                service-carving
                    mode auto
                exit
                multi-homing single-active
                lag 6
                no shutdown

EVPN command reference

This section describes the EVPN commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

Command hierarchies

EVPN configuration commands

config
    - service
        -  epipeservice-id [customer customer-id] [create] [vpn vpn-id][vc-switching]
        - epipe service-id [customer customer-id] [create] [vpn vpn-id][svc-sap-type {null-star | dot1q | dot1q-preserve | any | dot1q-range | qinq-inner-tag-preserve}] [customer-vid vlan-id]
        - no epipe service-id
            - bgp
            - no bgp
                - route-distinguisher rd
                - no route-distinguisher
                - route-target {ext-community | export ext-community | import ext-community}
                - no route-target
            - bgp-evpn 
            - no bgp-evpn 
                - evi value
                -  no evi 
                - local-ac-name ac-name
                - no local-ac-name
                    - [no] eth-tag tag-value
                - remote-ac-name ac-name
                - no remote-ac-name
                    - [no] eth-tag tag-value
                -  mpls
                    -  auto-bind-tunnel
                        -  resolution {disabled | any | filter}
                        -  resolution-filter
                            - [no] bgp
                            - [no] ldp
                            - [no] rsvp
                            - [no] sr-isis
                            - [no] sr-ospf
                    - [no] control-word
                    - [no] force-vlan-vc-forwarding
                    - oper-group name
                    - no oper-group
                    - [no] shutdown
        -  vpls service-id [customer customer-id] [create] [vpn vpn-id] [m-vpls] 
        - no vpls service-id 
            - [no] bgp [bgp-instance]
                - route-distinguisher [ip-addr:comm-val | as-number:ext-comm-val ]
                - no route-distinguisher
                - route-target ext-community
                - route-target export ext-community [import ext-community]
                - route-target import ext-community
                - no route-target
                - vsi-export policy-name [policy-name...(up to 5 max)]
                - no vsi-export
                - vsi-import policy-name [policy-name...(up to 5 max)]
                - no vsi-import
            - bgp-evpn 
            - no bgp-evpn 
                - evi value
                -  no evi 
                -  [no] mac-advertisement
                -  mac-duplication
                    - detect num-moves num-moves window minutes
                    - retry minutes
                    - no retry
                -  mpls
                    -  auto-bind-tunnel
                        -  resolution {disabled | any | filter}
                        -  resolution-filter
                            - [no] bgp
                            - [no] ldp
                            - [no] rsvp
                            - [no] sr-isis
                            - [no] sr-ospf
                    - [no] control-word
                    - ecmp max-ecmp-routes
                    - [no] force-vlan-vc-forwarding
                    - [no] ingress-replication-bum-label
                    -  [no] shutdown
                    -  split-horizon-group name
                    -  no split-horizon-group
            - [no] proxy-arp
                - age-time seconds
                - no age-time
                - dup-detect [anti-spoof-mac mac-address] window minutes num-moves count hold-down minutes | max
                - [no] dynamic-arp-populate
                - [no] garp-flood-evpn
                - [no] send-refresh seconds
                - static ip-address ieee-address
                - no static ip-address
                - table-size table-size
                - [no] unknown-arp-request-flood-evpn
                - [no] shutdown
            - [no] proxy-nd
                - age-time seconds
                - no age-time
                - dup-detect [anti-spoof-mac mac-address] window minutes num-moves count hold-down minutes | max
                - [no] dynamic-nd-populate
                - evpn-nd-advertise {host | router}
                - [no] host-unsolicited-na-flood-evpn
                - [no] router-unsolicited-na-flood-evpn
                - [no] send-refresh seconds
                - [no] static ip-address ieee-address {host | router}
                - table-size table-size
                - [no] unknown-ns-flood-evpn
                - [no] shutdown
config
    - service
        - system
            - bgp-evpn
                - ethernet-segment name [create] [virtual]
                    - es-activation-timer seconds
                    - no es-activation-timer 
                    - esi esi
                    - no esi
                    - lag lag-id
                    - no lag
                    - multi-homing single-active [no-esi-label]
                    - multi-homing all-active
                    - no multi-homing
                    - oper-group name
                    - no oper-group
                    - port port-id 
                    - no port
                    - service-carving
                        - manual
                            - evi start [to to]
                            - no evi start 
                        - mode {auto | manual | off}
                    - [no] shutdown
                - route-distinguisher rd
                - no route-distinguisher
config
    - redundancy
        - bgp-evpn-multi-homing
                - boot-timer seconds
                - es-activation-timer seconds

EVPN clear commands

clear
    - service
        - id service-id
            - proxy-arp [duplicate] [dynamic] 
            - proxy-nd [duplicate] [dynamic]

Command descriptions

EVPN configuration commands

epipe
Syntax

epipe service-id [customer customer-id] [create] [vpn vpn-id] [vc-switching]

epipe service-id [customer customer-id] [create] [vpn vpn-id] [svc-sap-type {null-star | dot1q | dot1q-preserve | any | dot1q-range | qinq-inner-tag-preserve}] [customer-vid vlan-id]

no epipe service-id

Context

config>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures a point-to-point Epipe service instance. An Epipe connects two endpoints defined as SAPs. Both SAPs may be defined in one or separate devices connected over the service provider network. When the endpoint SAPs are separated by the service provider network, the far-end SAP is generalized into an SDP. This SDP describes a destination and the encapsulation method used to reach it. In addition to the SDPs, endpoint SAPs can also be connected by EVPN destinations. A VPLS connects multiple customer sites together acting like a zero-hop, Layer 2 switched domain. A VPLS is always a logical full mesh.

No MAC learning or filtering is provided on an Epipe.

When a service is created, the customer keyword and customer-id must be specified, which associates the service with a customer. The customer-id must already exist (created using the customer command in the service context). The customer association cannot be edited; the service must be deleted and recreated with a new customer association. More than one VPLS may be created for a single customer ID. By default, no VPLS instances exist until they are explicitly created.

After a service is created, the use of the customer customer-id is optional for navigating into the service configuration context. Attempting to edit a service with the incorrect customer-id specified results in an error.

By default, no Epipe services exist until they are explicitly created with this command.

The no form of this command deletes the Epipe service instance with the specified service-id. The service cannot be deleted until the service has been shutdown.

Parameters
service-id

Specifies the unique service identification number or string identifying the service in the service domain. This ID must be unique to this service and may not be used for any other service of any type. The service-id must be the same number used for every router on which this service is defined.

Values

service-id — 1 to 2147483647

svc-name — a string up to 64 characters

customer customer-id

Specifies the customer ID number to be associated with the service. This parameter is required on service creation and optional for service editing or deleting.

Values

1 to 2147483647

vpn vpn-id

Specifies the VPN ID number which allows you to identify VPNs by a VPN identification number.

Values

1 to 2147483647

Default

null (0)

vc-switching

Specifies whether pseudowire switching signaling is used for the spoke-SDPs configured in the service. This is not supported for EVPN-VPWS.

svc-sap-type

Keyword that specifies the type of access SAPs and access-uplink SAPs allowed in the service.

Values

null-star — Specifies that the allowed SAP in the service can be null SAPs, dot1q default, Q.* SAP, 0.* SAP, or default QinQ SAP (also known as *.* SAP).

dot1q — Specifies that the allowed SAPs in the service are dot1q SAPs and dot1q explicit null SAPs.

dot1q-preserve — Specifies that the allowed SAPs in the service are dot1q. The dot1q ID is not stripped after packets match the SAP.

dot1q-range — Specifies that the access SAP in the service can use VLAN ranges as the SAP tags. The VLAN ranges are configured using the config>connection-profile command. On ingress of the access dot1q SAP using VLAN ranges, the outermost tag is not removed before forwarding.

any — Specifies that any SAP type is allowed.

qinq-inner-tag-preserve — Specifies that an Epipe service processes and forwards packets received with three or more tags on a QinQ SAP.

Default

any

customer-vid vlan-id

Specifies the dot1q VLAN ID used while creating the local dot1q SAP for svc-sap-type dot1q-preserve. Applicable only for access-uplink mode.

Values

1 to 4094

bgp
Syntax

bgp

no bgp

Context

config>service>epipe

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures BGP related parameters for BGP EVPN.

The no form of this command disables EVPN-VPWS.

Default

no bgp

route-distinguisher
Syntax

route-distinguisher rd

no route-distinguisher

Context

config>service>vpls>bgp

config>service>epipe>bgp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the Route Distinguisher (RD) component signaled in the MP-BGP NLRI for L2VPN and EVPN families. This value is used for BGP-AD, BGP VPLS, and BGP multi-homing NLRI if these features are configured.

If this command is not configured, the RD is automatically built using the BGP-AD VPLS ID. The following rules apply:
  • if BGP AD VPLS-ID is configured and no RD is configured under the BGP node - RD=VPLS-ID
  • if BGP AD VPLS-id is not configured, an RD value must be configured under the BGP node (this is the case when only BGP VPLS is configured)

  • if BGP AD VPLS-id is configured and an RD value is also configured under BGP node, the configured RD value prevails

Alternatively, the auto-rd option allows the system to automatically generate an RD based on the bgp-auto-rd-range command configured at the service level. For bgp-evpn enabled VPLS and Epipe services, the route-distinguisher value can also be auto-derived from the evi value (config>service>vpls>bgp-evpn>evi or config>service>epipe>bgp-evpn>evi) if this command is not configured. See the evi command description for more information.

Default

no route-distinguisher

Parameters
rd

Specifies all routes in the specified BGP community.

Values

ip-addr:comm-val | 2byte-asnumber:ext-comm-val> | 4byte-asnumber:comm-val

ip-addr

a.b.c.d

comm-val

0 to 65535

2byte-asnumber

1 to 65535

ext-comm-val

0 to 4294967295

4byte-asnumber

0 to 4294967295

route-target
Syntax

route-target {ext-community |export ext-community | import ext-community}

no route-target

Context

config>service>vpls>bgp

config>service>epipe>bgp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the Route Target (RT) component that is signaled in the related MP-BGP attribute used for BGP auto-discovery, BGP VPLS, BGP multi-homing, and EVPN if these features are configured in this VPLS service.

If this command is not used, the RT is built automatically using the VPLS ID. The extended community can have the same two formats as the VPLS ID, a two-octet AS-specific extended community, IPv4 specific extended community. For BGP EVPN enabled VPLS and Epipe services, the route target can also be auto-derived from the evi value (config>service>vpls>bgp-evpn>evi or config>service>epipe>bgp-evpn>evi) if this command is not configured. See the evi command description for more information.

Default

no route-target

Parameters
export ext-community

Specifies communities allowed to be sent to remote PE neighbors, up to 72 characters.

import ext-community

Specifies communities allowed to be accepted from remote PE neighbors, up to 72 characters.

bgp-evpn
Syntax

bgp-evpn

no bgp-evpn

Context

config>service>vpls

config>service>epipe

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables BGP-EVPN in the base instance.

The no form of this command disables BGP-EVPN.

Note:

CFM Is not supported with 7210 SAS EVPN VPLS services.

evi
Syntax

evi value

no evi

Context

config>service>vpls>bgp-evpn

config>service>epipe>bgp-evpn

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies a 2-byte EVPN instance that is unique in the system. It is used by the service-carving algorithm for multihoming and auto-deriving route target and route distinguishers.

If not specified, the value is zero 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 target is configured in the service, the following rules apply:

  • the route distinguisher is derived from <system_ip>:evi

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

Note:

If VSI import and export policies are configured, the route target must be configured in the policies, and those values take precedence over the auto-derived route targets. The operational route target for a service is shown in the show service id bgp command.

The no form of this command reverts the evi value to zero.

Default

no evi

Parameters
value

Specifies the EVPN instance.

Values

1 to 65535

local-ac-name
Syntax

local-ac-name ac-name

no local-ac-name

Context

config>service>epipe>bgp-evpn

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the local Ethernet tag value.

The no form of this command disables the local Ethernet tag value.

Default

no local-ac-name

Parameters
ac-name

Specifies the name of the local attachment circuit, up to 32 characters.

eth-tag
Syntax

[no] eth-tag tag-value

Context

config>service>epipe>bgp-evpn>local-ac-name

config>service>epipe>bgp-evpn>remote-ac-name

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the Ethernet tag value. When configured in the local-ac-name context, the system uses the value in the advertised AD per-EVI route sent for the attachment circuit. When configured in the remote-ac-name context, the system compares that value with the Ethernet tag value of the imported AD per-EVI routes for the service. If there is a match, the system creates an EVPN destination for the Epipe.

The no form of this command disables the local Ethernet tag value.

Default

no eth-tag

Parameters
tag-value

Specifies the Ethernet tag value of the attachment circuit.

Values

1 to 16777215

remote-ac-name
Syntax

remote-ac-name ac-name

no remote-ac-name

Context

config>service>epipe>bgp-evpn

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the remote Ethernet tag value.

The no form of this command disables the remote Ethernet tag value.

Default

no remote-ac-name

Parameters
ac-name

Specifies the name of the remote attachment circuit, up to 32 characters.

mpls
Syntax

mpls

Context

config>service>vpls>bgp-evpn

config>service>epipe>bgp-evpn

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the BGP EVPN MPLS parameters.

auto-bind-tunnel
Syntax

auto-bind-tunnel

Context

config>service>vpls>bgp-evpn>mpls

config>service>epipe>bgp-evpn>mpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure automatic binding of a BGP-EVPN service using tunnels to MP-BGP peers.

The resolution mode must be configured to enable auto-bind resolution to tunnels in TTM. The following configurations are available.

  • If resolution is explicitly set to disabled, the auto-binding to the tunnel is removed.

  • If resolution is set to any, any supported tunnel type in the EVPN context is selected, following TTM preference.

  • The resolution-filter option is used to specify one or more explicit tunnel types; only the specified tunnel types are selected again following the TTM preference.

The following tunnel types are supported in a BGP-EVPN MPLS context, in order of preference: RSVP, LDP, SR-ISIS, SR-OSPF, and BGP.

The rsvp value specifies that BGP searches for the best metric RSVP LSP to the address of the BGP next hop. This address can correspond to the system interface or to another loopback used by the BGP instance on the remote node. The LSP metric is provided by MPLS in the tunnel table. In the case of multiple RSVP LSPs with the same lowest metric, BGP selects the LSP with the lowest tunnel ID.

The ldp value specifies that BGP searches for an LDP LSP with a FEC prefix corresponding to the address of the BGP next hop.

The sr-isis (sr-ospf) value specifies that an SR tunnel to the BGP next hop is selected in the TTM from the lowest numbered ISIS (OSPF) instance.

The bgp value specifies BGP EVPN to search for a BGP LSP to the address of the BGP next hop. If the user does not enable the BGP tunnel type, the inter-area or inter-as prefixes is not resolved.

To activate the list of tunnel-types configured under resolution-filter, the resolution must be set to filter.

resolution
Syntax

resolution {disabled | any | filter}

Context

config>service>vpls>bgp-evpn>mpls>auto-bind-tunnel

config>service>epipe>bgp-evpn>mpls>auto-bind-tunnel

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the resolution mode in the automatic binding of a BGP-EVPN MPLS service to tunnels to MP-BGP peers.

Default

resolution disabled

Parameters
disabled

Specifies to disable the automatic binding of a BGP-EVPN MPLS service to tunnels to MP-BGP peers.

any

Specifies to enable the binding to any supported tunnel type in a BGP-EVPN MPLS context following TTM preference.

filter

Specifies to enable the binding to the subset of tunnel types configured under resolution-filter.

resolution-filter
Syntax

resolution-filter

Context

config>service>vpls>bgp-evpn>mpls>auto-bind-tunnel

config>service>epipe>bgp-evpn>mpls>auto-bind-tunnel

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the subset of tunnel types that can be used in the resolution of BGP-EVPN routes within the automatic binding of BGP-EVPN MPLS service to tunnels to MP-BGP peers.

The following tunnel types are supported in a BGP-EVPN MPLS context, in order of preference: RSVP, LDP, Segment Routing (SR), BGP, and UDP.

bgp
Syntax

[no] bgp

Context

config>service>vpls>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

config>service>epipe>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the BGP tunnel type.

BGP EVPN will search for a BGP LSP to the address of the BGP next hop. If the user does not enable the BGP tunnel type, the inter-area or inter-as prefixes will not be resolved.

The no form of this command disables BGP as a tunnel type to consider.

Default

no bgp

ldp
Syntax

[no] ldp

Context

config>service>vpls>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

config>service>epipe>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the LDP tunnel type.

BGP will search for an LDP LSP with a FEC prefix corresponding to the address of the BGP next-hop.

The no form of this command disables LDP as a tunnel type to consider.

Default

no ldp

rsvp
Syntax

[no] rsvp

Context

config>service>vpls>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

config>service>epipe>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the RSVP-TE tunnel type.

BGP will search for the best metric RSVP LSP to the address of the BGP next hop. This address can correspond to the system interface or to another loopback used by the BGP instance on the remote node. The LSP metric is provided by MPLS in the tunnel table. In the case of multiple RSVP LSPs with the same lowest metric, BGP selects the LSP with the lowest tunnel-id.

The no form of this command disables RSVP as a tunnel type to consider.

Default

no rsvp

sr-isis
Syntax

[no] sr-isis

Context

config>service>vpls>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

config>service>epipe>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the Segment Routing (SR) tunnel type programmed by an IS-IS instance in TTM.

The no form of this command disables SR-ISIS as a tunnel type to consider.

Default

no sr-isis

sr-ospf
Syntax

[no] sr-ospf

Context

config>service>vpls>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

config>service>epipe>bgp-evpn>mpls>auto-bind-tunnel>resolution-filter

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the SR tunnel type programmed by an OSPF instance in TTM.

The SR tunnel to the BGP next hop is selected in the TTM from the lowest numbered IS-IS (OSPF) instance.

The no form of this command disables SR-OSPF as a tunnel type to consider.

Default

no sr-ospf

shutdown
Syntax

shutdown

no shutdown

Context

config>service>vpls>bgp-evpn>mpls

config>service>epipe>bgp-evpn>mpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.

The no form of this command places the entity into an administratively enabled state.

Default

shutdown

vpls
Syntax

vpls service-id [customer customer-id] [vpn vpn-id] [m-vpls] [name name] [create]

no vpls service-id

Context

config>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command creates or edits a Virtual Private LAN Service (VPLS) instance. If the service-id does not exist, a context for the service is created. If the service-id exists, the context for editing the service is entered.

A VPLS connects multiple customer sites together acting like a zero-hop, Layer 2 switched domain. A VPLS is always a logical full mesh.

If the create command is enabled in the environment context, the create keyword must be specified when the service is created. Specify the customer keyword and customer-id to associate the service with a customer. The customer-id must already exist (created using the customer command in the service context). After a service has been created with a customer association, it is not possible to edit the customer association. To edit the customer association, the service must be deleted and recreated with a new customer association.

After a service is created, the use of the customer customer-id is optional for navigating into the service configuration context. Attempting to edit a service with the incorrect customer-id specified will result in an error.

More than one VPLS may be created for a single customer ID.

By default, no VPLS instances exist until they are explicitly created.

The no form of this command deletes the VPLS service instance with the specified service-id. The service cannot be deleted until all SAPs and SDPs defined within the service ID have been shutdown and deleted, and the service has been shutdown.

Parameters
service-id

Specifies the unique service identification number or string identifying the service in the service domain. This ID must be unique to this service and may not be used for any other service of any type. The service-id must be the same number used for every router on which this service is defined.

Values

service-id — 1 to 2147483648

svc-name — a string up to 64 characters

customer customer-id

Specifies the customer ID number to be associated with the service. This parameter is required on service creation and optional for service editing or deleting.

Values

1 to 2147483647

vpn vpn-id

Specifies the VPN ID number which allows you to identify VPNs by a VPN identification number.

Values

1 to 2147483647

Default

null (0)

m-vpls

Specifies a management VPLS.

bgp
Syntax

bgp bgp-instance

Context

config>service>vpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the BGP related parameters for BGP EVPN.

route-distinguisher
Syntax

route-distinguisher [ip-addr:comm-val | as-number:ext-comm-val ]

no route-distinguisher

Context

config>service>vpls>bgp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the Route Distinguisher (RD) component that will be signaled in the MP-BGP NLRI for L2VPN and EVPN families. This value is used for BGP-AD and BGP multi-homing NLRI, if these features are configured.

If this command is not configured, the RD is automatically built using the BGP-AD VPLS ID. The following rules apply:

  • if BGP AD VPLS-id is configured and no RD is configured under BGP node - RD=VPLS-ID

  • if BGP AD VPLS-id is configured and an RD value is also configured under BGP node, the configured RD value prevails

Values and format (6 bytes, other 2 bytes of type) will be automatically generated.

The no form of this command removes the RD component.

Parameters
ip-addr:comm-val

Specifies the IP address.

Values

ip-addr: a.b.c.d

comm-val: 0 to 65535

as-number:ext-comm-val

Specifies the AS number.

Values

as-number: 1 to 65535

ext-comm-val: 0 to 4294967295

route-target
Syntax

route-target ext-community

route-target export ext-community

route-target import ext-community

no route-target

Context

config>service>vpls>bgp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the route target (RT) component that will be signaled in the related MP-BGP attribute to be used for BGP auto-discovery and EVPN, if these features are configured in this VPLS service.

If this command is not used, the RT is built automatically using the VPLS ID. The ext-comm value can have the same two formats as the VPLS ID, a two-octet AS-specific extended community, IPv4 specific extended community. For BGP EVPN enabled VPLS services, the route target can also be auto-derived from the evi value (config service vpls bgp-evpn evi), if this command is not configured. See the command description for more information.

The no form of this command removes the RT component.

Parameters
export ext-community

Specifies communities allowed to be sent to remote PE neighbors.

import ext-community

Specifies communities allowed to be accepted from remote PE neighbors.

vsi-export
Syntax

vsi-export policy-name [policy-name ... (up to 5 max)]

no vsi-export

Context

config>service>vpls>bgp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the name of the VSI export policies to be used for BGP auto-discovery, if it is configured in this VPLS service. If multiple policy names are configured, the policies are evaluated in the order they are specified. The first policy that matches is applied.

The policy name list is handled by the SNMP agent as a single entity.

The no form of this command removes the VSI export policy.

Parameters
policy-name

Specifies a VSI export policy, 32 characters maximum.

vsi-import
Syntax

vsi-import policy-name [policy-name ... (up to 5 max)]

no vsi-import

Context

config>service>vpls>bgp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the name of the VSI import policies to be used for BGP auto-discovery, if it is configured in this VPLS service. If multiple policy names are configured, the policies are evaluated in the order they are specified. The first policy that matches is applied.

The policy name list is handled by the SNMP agent as a single entity.

The no form of this command removes the VSI import policy.

Parameters
policy-name

Specifies a VSI import policy, 32 characters maximum.

mac-advertisement
Syntax

[no] mac-advertisement

Context

config>service>vpls>bgp-evpn

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables the advertisement in BGP of the learned MACs on SAPs and SDP bindings. When the mac-advertisement command is disabled, the local MACs will be withdrawn in BGP.

The no form of this command disables mac-advertisement.

Default

mac-advertisement

mac-duplication
Syntax

mac-duplication

Context

config>service>vpls>bgp-evpn

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the BGP EVPN MAC duplication parameters.

detect
Syntax

detect num-moves num-moves window minutes

Context

config>service>vpls>bgp-evpn>mac-duplication

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command modifies the default behavior of the mac-duplication feature, which is always enabled by default. The command specifies the number of moves (num-moves) to monitor within a period of time (window).

Default

detect num-moves 5 window 3

Parameters
num-moves

Specifies the number of MAC moves in a VPLS. The counter is incremented when a specified MAC is locally relearned in the FDB or flushed from the FDB because of the reception of a better remote EVPN route for that MAC.

Values

3 to 10

Default

5

minutes

Specifies the length of the window, in minutes.

Values

1 to 15

Default

3

retry
Syntax

retry minutes

no retry

Context

config>service>vpls>bgp-evpn>mac-duplication

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the timer after which the MAC in hold-down state is automatically flushed and the MAC duplication process starts again. This value is expected to be equal to two times or more than that of window.

If the no form of this command is configured and MAC duplication is detected, MAC updates for that MAC will be held down until the user intervenes or a network event (that flushes the MAC) occurs.

Default

retry 9

Parameters
minutes

Specifies the BGP EVPN MAC duplication retry, in minutes.

Values

2 to 60

control-word
Syntax

[no] control-word

Context

config>service>vpls>bgp-evpn>mpls

config>service>epipe>bgp-evpn>mpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables the transmission and reception of the control word, as defined in RFC 7432, which helps avoid frame disordering.

This command is enabled or disabled for all EVPN-MPLS destinations at the same time.

The no form of this command reverts to the default value.

Default

no control-word

ecmp
Syntax

ecmp max-ecmp-routes

no ecmp

Context

config>service>vpls>bgp-evpn>mpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

When configured in a VPLS service, this command controls the number of paths to reach a specified MAC address when that MAC in the FDB is associated with a remote all-active multi-homed ES.

The configuration of two or more ECMP paths to a specified MAC enables the aliasing function described in RFC 7432.

The no form of this command reverts to the default value.

Default

no ecmp

Parameters
max-ecmp-routes

Specifies the maximum number of tunnels that may be used as ECMP next hops for the service.

Values

0 to 4

Default

0

force-vlan-vc-forwarding
Syntax

[no] force-vlan-vc-forwarding

Context

config>service>vpls>bgp-evpn>mpls

config>service>epipe>bgp-evpn>mpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command allows the system to preserve the VLAN ID and 802.1p bits of the service-delimiting qtag in a new tag added in the customer frame before sending it to the EVPN-MPLS destinations.

This command may be used in conjunction with the sap ingress vlan-translation command. In this case, the configured translated VLAN ID is the VLAN ID sent to the EVPN-MPLS destinations as opposed to the service-delimiting tag VLAN ID. If the ingress SAP/SDP binding is null-encapsulated, the output VLAN ID and pbits are zero.

The no form of this command reverts to the default value.

Default

no force-vlan-vc-forwarding

oper-group
Syntax

oper-group name

no oper-group

Context

config>service>epipe>bgp-evpn>mpls

config>service>system>bgp-evpn>ethernet-segment

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command adds the bgp-evpn mpls instance as a member of the operational group. The operational group is up when either this command is not yet configured or an EVPN destination is created under the EVPN instance added as member. When configured, no other objects (for example, SAP, SDP-bind, BGP-EVPN instance) can be configured as part of the operational group within the same or different service.

The no form of this command disables the operational group.

Default

no oper-group

Parameters
name

Specifies the name of the operational group, up to 32 characters.

ingress-replication-bum-label
Syntax

[no] ingress-replication-bum-label

Context

config>service>vpls>bgp-evpn>mpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the system to send a separate label for Broadcast, Unknown unicast and Multicast (BUM) traffic in a specified service. By default (no ingress-replication-bum-label), the same label is used for unicast and flooded BUM packets when forwarding traffic to remote PEs.

Saving labels may cause transient traffic duplication for all-active multihoming. If ingress-replication-bum-label is enabled, the system will advertise two labels per EVPN VPLS instance, one for unicast and one for BUM traffic. The ingress PE will use the BUM label for flooded traffic to the advertising egress PE, which allows the egress PE to determine whether unicast traffic has been flooded by the ingress PE. Depending on the scale required in the network, the user may choose between saving label space or avoiding transient packet duplication sent to an all-active multi-homed CE for specific MACs.

The no form of this command uses the same label for unicast and flooded BUM packets.

Default

no ingress-replication-bum-label

split-horizon-group
Syntax

split-horizon-group name

no split-horizon-group

Context

config>service>vpls>bgp-evpn>mpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures an explicit split-horizon group for all BGP-EVPN MPLS destinations that can be shared by other SAPs and spoke-SDPs. The use of explicit split-horizon groups for EVPN-MPLS and spoke-SDPs allows the integration of VPLS and EVPN-MPLS networks.

If the bgp-evpn mpls split-horizon-group command is not used, the default split-horizon group (that contains all the EVPN destinations) is still used, but it is not possible to refer to it on SAPs/spoke-SDPs.

User-configured split-horizon groups can be configured within the service context. The same group name can be associated with SAPs, spoke-SDPs, pw-templates, pw-template-bindings, and EVPN-MPLS destinations.

The configuration of the bgp-evpn mpls split-horizon-group command is only allowed if bgp-evpn>mpls is shut down; no changes are allowed when bgp-evpn>mpls is no shutdown.

If the SAPs or spoke-SDPs (manual) are configured within the same split-horizon group as the EVPN-MPLS endpoints, MAC addresses will still be learned but not advertised in BGP-EVPN. If an EVPN-MPLS provider tunnel is enabled in the service, the SAPs and SDP-bindings that share the same split-horizon group of the EVPN-MPLS provider-tunnel will be brought operationally down if the point-to-multipoint tunnel is operationally up.

The no form of this command configures the EVPN-MPLS destinations to use the default split-horizon group.

Default

no split-horizon-group

Parameters
name

Specifies the split-horizon group name.

proxy-arp
Syntax

[no] proxy-arp

Context

config>service>vpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the proxy-ARP in a VPLS service.

The no form of this command removes the proxy-ARP context.

Default

no proxy-arp

proxy-nd
Syntax

[no] proxy-nd

Context

config>service>vpls

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the proxy-ND in a VPLS service.

The no form of this command removes the proxy-ND context.

Default

no proxy-nd

age-time
Syntax

age-time seconds

no age-time

Context

config>service>vpls>proxy-arp

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the aging timer per proxy-ARP and proxy-ND entry for dynamic entries. When the aging expires, the entry is flushed. The age is reset when a new ARP, GARP, or NA for the same MAC-IP is received.

If the corresponding FDB MAC entry is flushed, the proxy-ARP or proxy-ND entry becomes inactive and subsequent ARP or NS lookups are treated as "missed". EVPN withdraws the IP-to-MAC if the entry becomes inactive. The age-time should be set at the send-refresh seconds value * 3 to ensure that no active entries are unnecessarily removed.

The no form of this command disables the aging timer.

Default

no age-time

Parameters
seconds

Specifies the aging time, in seconds.

Values

60 to 86400

dup-detect
Syntax

dup-detect [anti-spoof-mac mac-address] window minutes num-moves count hold-down [minutes | max]

Context

config>service>vpls>proxy-arp

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables the mechanism that detects duplicate IPs and ARP/ND spoofing attacks. Attempts (relevant to dynamic and EVPN entry types) to add the same IP (different MAC) are monitored for window minutes. When count is reached within that window, the proxy-ARP or proxy-ND entry for the suspected IP is marked as duplicate. An alarm is also triggered. This condition is cleared when hold-down time expires (max does not expire) or a clear command is issued.

If the anti-spoof-mac keyword is configured, the proxy-ARP or proxy-ND MAC address of the offending entry is replaced with the configured anti-spoof mac-address and advertised in an unsolicited GARP/NA for local SAPs/SDP-bindings, and in EVPN to remote PEs. This mechanism assumes that the same anti-spoof-mac is configured in all the PEs for the same service, and that traffic with destination anti-spoof-mac received on SAPs/SDP-bindings will be dropped. An ingress mac-filter may be configured to drop traffic to the anti-spoof-mac.

Default

dup-detect window 3 num-moves 5 hold-down 9

Parameters
window minutes

Specifies the window size, in minutes.

Values

1 to 15

Default

3

count

Specifies the number of moves required so that an entry is declared duplicate.

Values

3 to 10

Default

5

hold-down minutes

Specifies the hold-down time, in minutes, for a duplicate entry.

Values

2 to 60 | max

Default

9

mac-address

Specifies the MAC address to use as the optional anti-spoof-mac.

dynamic-arp-populate
Syntax

[no] dynamic-arp-populate

Context

config>service>vpls>proxy-arp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables the addition of dynamic entries to the proxy-ARP table.

When enabled, the system populates proxy-ARP entries from snooped GARP or ARP messages on SAPs/SDP-bindings. These entries are shown as dynamic.

When disabled, dynamic ARP entries are flushed from the proxy-ARP table. Enabling dynamic-arp-populate is only recommended in networks where this command is consistently configured in all PEs.

The no form of this command disables the addition of dynamic entries to the proxy-ARP table.

Default

no dynamic-arp-populate

dynamic-nd-populate
Syntax

[no] dynamic-nd-populate

Context

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables the addition of dynamic entries to the proxy-ND table.

When enabled, the system populates proxy-ND entries from snooped Neighbor Advertisement (NA) messages on SAPs or SDP-bindings, in addition to the entries coming from EVPN (if the EVPN is enabled). These entries are shown as dynamic, and not as EVPN or static entries.

When disabled, dynamic ND entries are flushed from the proxy-ND table. Enabling dynamic-nd-populate is only recommended in networks where this command is consistently configured in all PEs.

The no form of this command disables the addition of dynamic entries to the proxy-ND table.

Default

no dynamic-nd-populate

evpn-nd-advertise
Syntax

evpn-nd-advertise {host | router}

Context

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables the advertisement of static or dynamic entries that are learned as a host or router. Only one option (host or router) is possible in a specified service. This command also determines the R flag (host or router) when sending NA messages for existing EVPN entries in the proxy-ND table.

This command can only be modified if proxy-nd is shut down.

Default

evpn-nd-advertise router

Parameters
host

Keyword to enable the advertisement of static or dynamic entries that are learned as host.

router

Keyword to enable the advertisement of static or dynamic entries that are learned as routers.

garp-flood-evpn
Syntax

[no] garp-flood-evpn

Context

config>service>vpls>proxy-arp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command controls whether the system floods GARP-requests and GARP-replies to the EVPN. The GARPs impacted by this command are messages in which the sender IP is equal to the target IP and the MAC DA is broadcast.

The no form of this command only floods to local SAPs/SDP-bindings but not to EVPN destinations. The use of the no form is only recommended in networks where CEs are routers that are directly connected to the PEs. Networks using aggregation switches between the host/routers and the PEs should flood GARP messages in the EVPN to ensure that the remote caches are updated and the BGP does not miss the advertisement of these entries.

Default

garp-flood-evpn

host-unsolicited-na-flood-evpn
Syntax

[no] host-unsolicited-na-flood-evpn

Context

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command controls whether the system floods host unsolicited Neighbor Advertisement (NA) messages to the EVPN. The NA messages with the following flags are impacted by this command:

  • S=0

  • R=0

The no form of this command only floods to local SAPs/SDP-bindings but not to the EVPN destinations. The use of the no form is only recommended in networks where CEs are routers that are directly connected to the PEs. Networks using aggregation switches between the host/routers and the PEs should flood unsolicited NA messages in the EVPN to ensure that the remote caches are updated and the BGP does not miss the advertisement of these entries.

Default

host-unsolicited-na-flood-evpn

router-unsolicited-na-flood-evpn
Syntax

[no] router-unsolicited-na-flood-evpn

Context

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command controls whether the system floods router unsolicited NAs to EVPN. The NA messages impacted by this command are NA messages with the following flags:

  • S=0

  • R=1

The no form of this command only floods to local SAPs/SDP-bindings but not to EVPN destinations. This is only recommended in networks where CEs are routers directly connected to the PEs. Networks using aggregation switches between the host/routers and the PEs should flood unsolicited NA messages in EVPN to ensure that the remote caches are updated and the BGP does not miss the advertisement of these entries.

Default

router-unsolicited-na-flood-evpn

send-refresh
Syntax

send-refresh seconds

no send-refresh

Context

config>service>vpls>proxy-arp

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables the system to send a refresh message at the configured time. A refresh message is an ARP-request message that uses 0s as the sender IP for the case of a proxy-ARP entry. For proxy-ND entries, a refresh is a regular NS message that uses the chassis MAC address as the MAC source address.

The no form of this command suppresses the refresh messages.

Default

no send-refresh

Parameters
seconds

Specifies the time to send a refresh message, in seconds.

Values

120 to 86400

static
Syntax

static ip-address ieee-address

no static ip-address

Context

config>service>vpls>proxy-arp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures static entries to be added to the table. A static MAC-IP entry requires the addition of the MAC address to the FDB as either learned or CStatic (conditional static MAC) to become active.

The no form of this command removes the specified static entry.

Parameters
ip-address

Specifies the IPv4 address for the static entry.

ieee-address

Specifies a 48-bit MAC address in the form xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx, where xx represents a hexadecimal number.

static
Syntax

static ipv6-address ieee-address {host | router}

no static ipv6-address

Context

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures static entries to be added to the table. A static MAC-IP entry requires the addition of the MAC address to the FDB as either dynamic or CStatic (Conditional Static MAC) to become active. Along with the IPv6 and MAC address, the entry must also be configured as either host or router. This determines whether the received NS for the entry is replied with the R flag set to 1 (router) or 0 (host).

The no form of this command removes the specified static entry.

Parameters
ipv6-address

Specifies the IPv6 address for the static entry.

ieee-address

Specifies a 48-bit MAC address in the form xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx, where xx represents a hexadecimal number.

host

Specifies that the entry is type ‟host”.

router

Specifies that the entry is type ‟router”.

table-size
Syntax

table-size table-size

Context

config>service>vpls>proxy-arp

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command adds a table-size limit per service. By default, the limit is 250; it can be set up to 16k entries per service. A non-configurable implicit high watermark of 95% and low watermark of 90% exists, per service and per system.

When those watermarks are reached, a syslog or trap is triggered. When the system or service limit is reached, entries for a specified IP can be replaced (a different MAC can be learned and added) but no new IP entries are added, regardless of the type (Static, evpn, dynamic). If the user attempts to change the table-size value to a value that cannot accommodate the number of existing entries, the attempt fails.

Default

250

Parameters
table-size

Specifies the table-size as the number of entries for the service.

Values

1 to 16384

unknown-arp-request-flood-evpn
Syntax

[no] unknown-arp-request-flood-evpn

Context

config>service>vpls>proxy-arp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command controls whether unknown ARP requests are flooded into the EVPN network. By default, the system floods ARP requests, including EVPN (with source squelching), if there is no active proxy-ARP entry for the requested IP.

The no form of this command only floods to local SAPs/SDP-bindings and not to EVPN destinations.

Default

unknown-arp-request-flood-evpn

unknown-ns-flood-evpn
Syntax

[no] unknown-ns-flood-evpn

Context

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables unknown Neighbor Solicitation (NS) messages to be flooded into the EVPN network. By default, the system floods NS (with source squelching) to SAPs/SDP-bindings including EVPN, if there is no active proxy-ND entry for the requested IPv6.

The no form of this command only floods to local SAPs/SDP-bindings but not to EVPN destinations.

Default

unknown-ns-flood-evpn

shutdown
Syntax

[no] shutdown

Context

config>service>vpls>proxy-arp

config>service>vpls>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables and disables the proxy-ARP and proxy-ND functionalities. ARP, GARP, and ND messages are snooped and redirected to the CPM for lookup in the proxy-ARP/proxy-ND table. The proxy-ARP/proxy-ND table is populated with IP-to-MAC pairs received from different sources (EVPN, static, dynamic). When the shutdown command is issued, the system stops snooping ARP/ND frames and the dynamic/EVPN dup proxy-ARP/proxy-ND table entries are flushed. All the static entries are kept in the table as "inactive", regardless of their previous "Status".

The no form of this command enables the proxy-ARP and proxy-ND functionalities.

Default

shutdown

ethernet-segment
Syntax

ethernet-segment name [create]

no ethernet-segment name

Context

config>service>system>bgp-evpn

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures an ES instance and its corresponding name.

The no form of this command deletes the specified ES.

Parameters
name

Specifies the ES name, up to 28 characters.

create

Keyword to create an ES.

es-activation-timer
Syntax

es-activation-timer seconds

no es-activation-timer

Context

config>service>system>bgp-evpn>ethernet-segment

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the ES activation timer for the specified ethernet-segment. The es-activation-timer delays the activation of a specified ethernet-segment on a specified PE that has been elected as DF (Designated Forwarder). Only when the es-activation-timer has expired, the SAP associated to an ethernet-segment can be activated (in case of single-active multi-homing) or added to the default-multicast-list (in case of all-active multi-homing).

The no form of this command specifies that the system uses the value in the config>redundancy>bgp-evpn-multi-homing>es-activation-timer context, if configured. Otherwise the system uses the default value of 3 seconds.

Default

no es-activation-timer

Parameters
seconds

Specifies the number of seconds for the es-activation-timer.

Values

0 to 100

Default

3

esi
Syntax

esi value

no esi

Context

config>service>system>bgp-evpn>ethernet-segment

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the 10-byte Ethernet segment identifier (ESI) associated with the ethernet-segment that will be signaled in the BGP-EVPN routes. The ESI value cannot be changed unless the ethernet-segment is shutdown. Reserved ESI values, 0 and MAX-ESI, are not allowed.

The no form of this command deletes the ESI from the Ethernet segment.

Default

no esi

Parameters
value

Specifies the 10-byte ESI in the form 00-11-22-33-44-55-66-77-88-99, using ‟-”, ‟:”, or ‟ ” as separators.

lag
Syntax

lag lag-id

no lag

Context

config>service>system>bgp-evpn>ethernet-segment

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures a lag ID associated to the ES When the ethernet-segment is configured as all-active, only a LAG can be associated to the ES. When the ethernet-segment is configured as single-active, a LAG or port can be associated to the ES. In either case, only one of the two objects can be configured in the ES. A specified LAG can be part of only one ES.

The no form of this command removes the association of the Ethernet segment to LAG ports.

Default

no lag

Parameters
lag-id

Specifies the lag ID associated with the ES.

Values

1 to 800

multi-homing
Syntax

multi-homing single-active [no-esi-label]

multi-homing all-active

no multi-homing

Context

config>service>system>bgp-evpn>ethernet-segment

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the multi-homing mode for the specified ethernet-segment as single-active or all-active multi-homing, as defined in RFC7432.

By default, the use of esi-label is enabled for all-active and single-active as defined in RFC7432 (for single-active multi-homing, the ESI label is used to avoid transient loops).

When single-active no-esi-label is specified, the system will not allocate an ESI label and hence advertise ESI label 0 to peers. Even if the ESI is configured to not send the ESI label, upon reception of an ESI label from a peer, the PE will always send traffic to that peer using the received ESI label.

The multi-homing command must be configured for the Ethernet segment to be enabled.

The no form of this command disables multi-homing on the Ethernet segment.

Default

no multi-homing

Parameters
single-active

Specifies single-active mode for the ES.

all-active

Specifies all-active mode for the ES.

no-esi-label

Specifies that the system does not send an ESI label for single-active mode.

port
Syntax

port port-id

no port

Context

config>service>system>bgp-evpn>ethernet-segment

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures a port ID associated with the ES. If the ethernet-segment is configured as all-active, only a LAG can be associated to the ES. If the ethernet-segment is configured as single-active, a LAG or port can be associated to the ES. In any case, only one of the two objects can be configured in the ethernet-segment. A specified port can be part of only one ethernet-segment. Only Ethernet ports can be added to an ethernet-segment.

The no form of this command removes the Ethernet segment association to all ports.

Default

no port

Parameters
port-id

Specifies the port ID associated to the ES.

Values

port-id

slot/mda/port [.channel]

service-carving
Syntax

service-carving

Context

config>service>system>bgp-evpn>ethernet-segment

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure service-carving in the Ethernet segment. The service-carving algorithm determines the PE that is the Designated Forwarder (DF) in a specified ES and for a specific service.

manual
Syntax

manual

Context

config>service>system>bgp-evpn>eth-seg>service-carving

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context manually configure the service-carving algorithm; that is, configure the EVIs for which the PE is DF.

evi
Syntax

evi start [to to] primary

no evi start

Context

config>service>system>bgp-evpn>eth-seg>service-carving>manual

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the EVI ranges for which the PE is DF.

Note:

Multiple individual EVI values and ranges are allowed. The PE will be non-DF for the evi values not defined as primary.

The no form of this command removes the specified EVI range.

Parameters
start

Specifies the initial EVI value of the range for which the PE is DF.

Values

1 to 65535

to

Specifies the end EVI value of the range for which the PD is DF. If not configured, only the individual start value is considered.

Values

1 to 65535

primary

Specifies that the PE is DF for the configured EVI range.

mode
Syntax

mode {manual | auto | off}

Context

config>service>system>bgp-evpn>eth-seg>service-carving

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the service-carving mode. This determines how the DF is elected for a specified ES and service.

Default

mode auto

Parameters
auto

Specifies the service-carving algorithm defined in RFC 7432. The DF for the service is calculated based on the modulo function of the service (identified by either the EVI or the ISID) and the number of PEs.

manual

Specifies that the DF is elected based on the manual configuration added in the service-carving>manual context.

off

Specifies that all the services elect the same DF PE (assuming the same PEs are active for all the configured services). The PE with the lowest IP is elected as DF for the ES.

shutdown
Syntax

[no] shutdown

Context

config>service>system>bgp-evpn>ethernet-segment

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command changes the administrative status of the ethernet-segment.

The user can only configure no shutdown when esi, multi-homing, and lag/port are configured. If the ES or the corresponding lag/port are shutdown, the ES route and the AD per-ES routes will be withdrawn. No changes are allowed when the ethernet-segment is no shutdown.

Default

shutdown

route-distinguisher
Syntax

route-distinguisher rd

no route-distinguisher

Context

config>service>system>bgp-evpn

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the route distinguisher (RD) that will be signaled in EVPN Type 4 routes (Ethernet segment routes).

The no form of this command reverts to the default value.

Default

no route-distinguisher

Parameters
rd

Specifies the route distinguisher in the following format.

  • ip-addr:comm-val

Values

ip-addr — a.b.c.d

comm-val — 0 to 65535

Default

system-ip: 0

redundancy
Syntax

redundancy

Context

config

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the global redundancy parameters.

bgp-evpn-multi-homing
Syntax

bgp-evpn-multi-homing

Context

config>redundancy

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the BGP-EVPN global timers.

boot-timer
Syntax

boot-timer seconds

Context

config>redundancy>bgp-evpn-multi-homing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

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 segments and running the DF algorithm.

The following considerations apply to the functionality:

  • The boot-timer is configured at the system level. The configured value must provide enough time to allow the node and the cards (if available) to come up and BGP sessions to come up before exchanging ES routes and running the DF election for each EVI.

  • The boot-timer is synchronized across CPMs and is relative to the System UP-time; therefore the boot-timer is not subject to change or reset upon CPM switchover.

  • The boot-timer is never interrupted (however, the es-activation-timer can be interrupted if there is a new event triggering the DF election).

  • The boot-timer runs per EVI on the ES's in the system. While system-up-time>boot-timer is true, the system does not run the DF election for any EVI. When the boot-timer expires, the DF election for the EVI is run and if the system is elected DF for the EVI, the es-activation-timer kicks in.

  • The system does not advertise ES routes until the boot timer has expired. This guarantees that the peer ES PEs do not run the DF election until the PE is ready to become the DF, if required.

Default

boot-timer 10

Parameters
seconds

Specifies the number of seconds for the boot-timer.

Values

0 to 600

es-activation-timer
Syntax

es-activation-timer seconds

Context

config>redundancy>bgp-evpn-multi-homing

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the global Ethernet segment activation timer. The es-activation-timer delays the activation of a specified Ethernet segment on a specified PE that has been elected as the DF (Designated Forwarder). Only when the es-activation-timer has expired, can the SAP/SDP-binding associated to an Ethernet segment be activated (in case of single-active multi-homing) or added to the default-multicast-list (in case of all-active multi-homing).

The es-activation-timer configured at the Ethernet-segment level supersedes this global es-activation-timer.

Default

es-activation-timer 3

Parameters
seconds

Specifies the number of seconds for the es-activation-timer.

Values

0 to 100

EVPN show commands

evpn-mpls
Syntax

evpn-mpls

Context

show>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command displays the remote EVPN-MPLS tunnel endpoints in the system.

Output

The following output is an example of EVPN MPLS tunnel endpoint information, and Output fields: EVPN MPLS tunnel endpoints describes the output fields.

Sample output
*A:Dut-B# show service evpn-mpls 
============================================================
EVPN MPLS Tunnel Endpoints
============================================================
EvpnMplsTEP Address EVPN-MPLS Dest      ES Dest
------------------------------------------------------------
10.20.1.3           1                   0
10.20.1.4           1                   0
10.20.1.5           1                   0
------------------------------------------------------------
Number of EvpnMpls Tunnel Endpoints: 3
------------------------------------------------------------
============================================================ 
Table 3. Output fields: EVPN MPLS tunnel endpoints

Label

Description

EvpnMplsTEP

Displays the tunnel endpoint addresses

EVPN-MPLS Dest

Displays the number of EVPN-MPLS destinations

ES Dest

Displays the Ethernet segment destination

bgp-evpn
Syntax

bgp-evpn

Context

show>service>id

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command displays the bgp-evpn configured parameters for a specified service, including the administrative status of MPLS, the configuration for mac-advertisement and unknown-mac-route, as well as the mac-duplication parameters. The command shows the duplicate MAC addresses that mac-duplication has detected.

If the service is BGP-EVPN MPLS, the command also shows the parameters corresponding to EVPN-MPLS.

Output

The following output is an example of BGP EVPN information for a specified service, and Output fields: service ID BGP-EVPN describes the output fields.

Sample output
*A:Dut-B# /show service id 1 bgp-evpn 
===============================================================================
BGP EVPN Table
===============================================================================
MAC Advertisement  : Enabled            
CFM MAC Advertise  : Disabled           
MAC Dup Detn Moves : 5                  MAC Dup Detn Window: 3
MAC Dup Detn Retry : 9                  Number of Dup MACs : 0
EVI                : 1                  
-------------------------------------------------------------------------------
Detected Duplicate MAC Addresses             Time Detected
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
===============================================================================
===============================================================================
BGP EVPN MPLS Information
===============================================================================
Admin Status       : Enabled            
Force Vlan Fwding  : Disabled           Control Word       : Disabled
Split Horizon Group: (Not Specified)
Ingress Rep BUM Lbl: Disabled           Max Ecmp Routes    : 0
Ingress Ucast Lbl  : 131069             Ingress Mcast Lbl  : 131069
===============================================================================
===============================================================================
BGP EVPN MPLS Auto Bind Tunnel Information
===============================================================================
Resolution         : any                
Filter Tunnel Types: (Not Specified)
===============================================================================
Table 4. Output fields: service ID BGP-EVPN

Label

Description

BGP EVPN Table

MAC Advertisement

Displays whether MAC advertisement is enabled or disabled

CFM MAC Advertise

Displays whether CFM MAC advertise is enabled or disabled

MAC Dup Detn Moves

Displays the number of moves that trigger MAC duplication detection

MAC Dup Detn Window

Displays the configured window size used for duplicate MAC detection

MAC Dup Detn Retry

Displays the retry timer value used for MAC duplication detection.

Number of Dup MACs

Displays the number of duplicate MAC addresses

EVI

Displays the EVPN instance ID

BGP EVPN MPLS Information

Admin Status

Displays the administrative status of the EVPN MPLS

Force Vlan Fwding

Displays the status of force-vlan-forwarding

Control Word

Displays the status of control

Split Horizon Group

Displays the split-horizon group membership information

Ingress Rep BUM Lbl

Displays the label used for Ingress BUM replication

Max Ecmp Routes

Displays the maximum number of ECMP routes

Ingress Ucast Lbl

Displays the ingress unicast label

Ingress Mcast Lbl

Displays the ingress multicast label

BGP EVPN MPLS Auto Bind Tunnel Information

Resolution

Displays the transport tunnel resolution filter used

Filter Tunnel Types

Displays auto-bind-tunnel resolution filter values, if applicable

evpn-mpls
Syntax

evpn-mpls

evpn-mpls esi esi

Context

show>service>id

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command displays the existing EVPN-MPLS destinations for a specified service and all related information. The command allows filtering based on esi (for EVPN multi-homing) to display the EVPN-MPLS destinations associated to an Ethernet Segment Identifier (ESI).

Parameters
esi

Specifies a 10-byte ESI by which to filter the displayed information. For example, ESI-0 | ESI-MAX or 00-11-22-33-44-55-66-77-88-99 with any of these separators ('-',':',' ')

Output

The following output is an example of EVPN MPLS information, and Output fields: EVPN MPLS describes the output fields.

Sample output
*A:Dut-B# /show service id 1 evpn-mpls 
===============================================================================
BGP EVPN-MPLS Dest
===============================================================================
TEP Address     Egr Label     Num. MACs   Mcast           Last Change
                 Transport                                
-------------------------------------------------------------------------------
10.20.1.3       131069        0           Yes             02/02/2014 15:29:40
                rsvp                                       
10.20.1.4       131069        0           Yes             02/02/2014 15:29:33
                rsvp                                       
10.20.1.5       131059        0           Yes             02/02/2014 15:29:42
                rsvp                                       
-------------------------------------------------------------------------------
Number of entries : 3
-------------------------------------------------------------------------------
===============================================================================
===============================================================================
BGP EVPN-MPLS Ethernet Segment Dest
===============================================================================
Eth SegId                       Num. Macs               Last Change
-------------------------------------------------------------------------------
00:de:01:00:00:00:00:00:00:01   1                       02/02/2014 15:47:04
-------------------------------------------------------------------------------
Number of entries: 1
-------------------------------------------------------------------------------
*A:PE-1# show service id 2 evpn-mpls esi 00:10:00:00:00:00:00:00:00:00  
Table 5. Output fields: EVPN MPLS

Label

Description

TEP Address

Displays the TEP address

Egr Label

Displays the egress label

Transport

Displays the transport type

Number of entries

Indicates the number of entries

Eth SegId

Displays the Ethernet segment ID

Transport:Tnl-Id

Displays the tunnel type and tunnel ID of the EVPN-MPLS entry

Transport:Tnl

Displays the transport tunnel

Num. MAC

Displays the number of MACs

Mcast

Displays the multicast information

Sup BCast Domain

Displays the Sup BCast Domain

proxy-arp
Syntax

proxy-arp [ip-address] [detail]

Context

show>service>id

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command displays, in a table, the existing proxy-ARP entries for a specified service. The table is populated by EVPN MAC routes that contain a MAC and an IP address, as well as static entries or dynamic entries from snooped ARP messages on access SAPs.

A 7210 SAS that receives an ARP request from a SAP performs a lookup in the proxy-ARP table for the service. If a match is found, the router replies to the ARP and does not allow ARP flooding in the VPLS service. If a match is not found, the ARP is flooded within the service if the configuration allows it.

The command allows for specific IP addresses to be displayed. Dynamic IP entries associated to a MAC list are displayed with the corresponding MAC list and resolve timers information.

Parameters
ip-address

Specifies an IP address.

Values

a.b.c.d

detail

Displays detailed information.

Output

The following output is an example of proxy-ARP information for a specified service, and Output fields: proxy-ARP describes the output fields.

Sample output
show service id 1 proxy-arp detail 
-------------------------------------------------------------------------------
Proxy Arp
-------------------------------------------------------------------------------
Admin State       : enabled             
Dyn Populate      : enabled             
Age Time          : disabled            Send Refresh      : disabled
Table Size        : 16383               Total             : 2
Static Count      : 0                   EVPN Count        : 1
Dynamic Count     : 1                   Duplicate Count   : 0
Dup Detect
-------------------------------------------------------------------------------
Detect Window     : 3 mins              Num Moves         : 5
Hold down         : 9 mins              
Anti Spoof MAC    : None
EVPN
-------------------------------------------------------------------------------
Garp Flood        : disabled            Req Flood         : enabled
-------------------------------------------------------------------------------
===============================================================================
VPLS Proxy Arp Entries
===============================================================================
IP Address          Mac Address         Type      Status    Last Update
-------------------------------------------------------------------------------
10.1.1.1            00:00:00:00:00:01   dyn       active    03/13/2020 10:25:39
10.1.1.10           00:00:00:00:00:11   evpn      active    03/13/2020 10:25:40
-------------------------------------------------------------------------------
Number of entries : 2
===============================================================================
Table 6. Output fields: proxy-ARP

Label

Description

Admin State

Displays the admin state: enabled or disabled

Dyn Populate

Displays the status of the ARP dynamic population

Age Time

Displays the configured ARP age timer

Send Refresh

Displays the configured ARP refresh timer

Table Size

Displays the configured ARP table size

Total

Displays the total table used count

Static Count

Displays the static ARP entries count

EVPN Count

Displays the count of ARP entries learned through the EVPN tunnel

Dynamic Count

Displays the count of ARP entries dynamically learned

Duplicate Count

Displays the count of ARP duplicate entries

Detect Window

Displays the configured window value for ARP duplicate detection

Num Moves

Displays the configured count for number of moves used for ARP duplicate detection

Hold Down

Displays the hold-down timer used by ARP duplicate detection

Anti Spoof MAC

Displays the MAC address configured for anti-spoof detection

Garp Flood

Displays the status for GARP flooding

Req Flood

Displays the status of ARP request flooding

IP Address

Displays the IP address of the proxy-ARP entry

Mac Address

Displays the MAC address of the proxy-ARP entry

Type

Displays the type of ARP entry

Status

Displays the status

Last Update

Displays the date and time of the last update

proxy-nd
Syntax

proxy-nd [ipv6-address] [detail]

Context

show>service>id

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command displays, in a table, the existing proxy-ND entries for a specified service. The table is populated by the EVPN MAC routes containing a MAC and an IPv6 address, as well as static entries or dynamic entries from snooped NA messages on access SAPs.

A 7210 SAS that receives a Neighbor Solicitation (NS) from a SAP performs a lookup in the proxy-ND table for the service. If a match is found, the router replies to the NS and does not allow NS flooding in the VPLS service. If a match is not found, the NS is flooded in the service, if the configuration allows it.

This command allows specific IPv6 addresses to be displayed. Dynamic IPv6 entries associated to a MAC list are shown with the corresponding MAC list and resolve timer information.

Parameters
ipv6-address

Specifies an IPv6 address.

Values

ipv6-address:

x:x:x:x:x:x:x:x (eight 16-bit pieces)

x:x:x:x:x:x:d.d.d.d

where:

x - [0 to FFFF]H

d - [0 to 255]D

detail

Displays detailed information.

Output

The following output is an example of proxy-ND information for a specified service, and Output fields: proxy-ND displays the output fields.

Sample output
A:Dut-C# show service id 1 proxy-nd detail 
-------------------------------------------------------------------------------
Proxy ND
-------------------------------------------------------------------------------
Admin State       : enabled             
Dyn Populate      : enabled             
Age Time          : disabled            Send Refresh      : disabled
Table Size        : 250                 Total             : 1
Static Count      : 0                   EVPN Count        : 0
Dynamic Count     : 1                   Duplicate Count   : 0
Dup Detect
-------------------------------------------------------------------------------
Detect Window     : 3 mins              Num Moves         : 5
Hold down         : 9 mins              
Anti Spoof MAC    : None
EVPN
-------------------------------------------------------------------------------
Unknown NS Flood  : enabled             ND Advertise      : Router
Rtr Unsol NA Flood: disabled            Host Unsol NA Fld : disabled
-------------------------------------------------------------------------------
===============================================================================
VPLS Proxy ND Entries
===============================================================================
IP Address               Mac Address       Type Status Rtr/ Last Update
                                                       Host 
-------------------------------------------------------------------------------
2000::4                  00:00:00:00:00:04 dyn  active Rtr  01/14/2020 09:47:43
-------------------------------------------------------------------------------
Number of entries : 1*A:PE-2#  show service id 5 proxy-nd        
Table 7. Output fields: proxy-ND

Label

Description

Admin State

Displays the admin state for proxy-ND: enabled or disabled

Dyn Populate

Displays the status for dynamic populate

Age Time

Displays the aging timer for ND entries

Send Refresh

Displays the refresh timer for ND entries

Table Size

Displays the proxy-ND table size

Total

Displays the count of learned ND entries

Static Count

Displays the count of static ND entries

EVPN Count

Displays the count of ND entries learned from the EVPN binding

Dynamic Count

Displays the count of dynamically learned ND entries

Duplicate Count

Displays the count of duplicate ND entries

Detect Window

Displays the configured value for window size used for duplicate detection

Num Moves

Displays the configured value for number of moves used in duplicate ND detection

Hold Down

Displays the value of the hold-down timer

Anti Spoof MAC

Displays the configured anti-spoof MAC address

Unknown NS Flood

Displays the state of unknown Neighbor Solicitation messages that are flooded to the EVPN network

ND Advertise

Displays the advertisement of static or dynamic entries that are learned as hosts or routers

Rtr Unsol NA Flood

Displays the state of system floods router unsolicited Neighbor Advertisements to EVPN

Host Unsol NA Fld

Displays the state of system floods host unsolicited Neighbor Advertisements to EVPN

IP Address

Displays the IP address of the proxy-ND entry

Mac Address

Displays the MAC address of the proxy-ND entry

Type

Displays the type of ND entry

Status

Displays the status of the ND entry

Last Update

Displays the date and time of the last update

system
Syntax

system

Context

show>service

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the system BGP EVPN show command.

bgp-evpn
Syntax

bgp-evpn

Context

show>service>system

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command shows system BGP EVPN information.

Output

The following output is an example of system BGP EVPN information, and Output fields: system BGP-EVPN describes the output fields.

Sample output
*A:Dut-B# /show service system bgp-evpn                  
===============================================================================
System BGP EVPN Information
===============================================================================
Evpn Route Dist.                       : <none>
Oper Route Dist.                       : 10.20.1.2:0
Oper Route Dist Type                   : default
===============================================================================
Table 8. Output fields: system BGP-EVPN

Label

Description

Evpn Route Dist.

Displays the EVPN route distinguisher

Oper Route Dist.

Displays address of the operational route distinguisher

Oper Route Dist Type

Displays the operational route distinguisher type

redundancy
Syntax

redundancy

Context

show

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context display the global redundancy parameters.

bgp-evpn-multi-homing
Syntax

bgp-evpn-multi-homing

Context

show>redundancy

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command displays information related to the EVPN global timers.

Output

The following output is an example of BGP EVPN multi-homing information, and Output fields: BGP-EVPN multi-homing displays the output fields.

Sample output
*A:Dut-B# 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                  
=============================================================================== 
Table 9. Output fields: BGP-EVPN multi-homing

Label

Description

Boot-Timer

Displays the value configured for the boot timer

Boot-Timer Remaining

Displays the amount of time remaining on the boot timer

ES Activation Timer

Displays the value configured for the ES activation timer

EVPN clear commands

proxy-arp
Syntax

proxy-arp [duplicate] [dynamic]

Context

clear>service>id

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command clears all entries in the proxy-ARP table if none of the optional parameters is specified. If the duplicate parameter is specified it clears all the duplicate entries in the proxy-ARP table. If the dynamic parameter is specified it clears all the dynamic entries in the proxy-ARP table.

Parameters
duplicate

Clears the proxy ARP duplicate entries.

dynamic

Clears the proxy ARP dynamic entries.

proxy-nd
Syntax

proxy-nd [duplicate] [dynamic]

Context

clear>service>id

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command clears all entries in the proxy-ND table if none of the optional parameters is specified. If the duplicate parameter is specified it clears all the duplicate entries in the hold-down state from the proxy-ND table. If the dynamic parameter is specified it clears all the dynamic entries in the hold-down state from the proxy-ND table.

Parameters
duplicate

Clears the proxy ND duplicate entries.

dynamic

Clears the proxy ND dynamic entries.

Tools commands

service
Syntax

service

Context

tools>dump

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures tools to display service dump information.

usage
Syntax

usage

Context

tools>dump>service>proxy-arp

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command provides information about the usage and limit of the system-wide proxy-ARP table for all the services. The command also shows if the limit has been exceeded and a trap raised.

Output

The following output is an example of tools dump service proxy-arp usage information.

Sample output
*A:Dut# tools dump service proxy-arp usage 
Proxy arp Usage
            Current Usage       :         10
            System Limit        :     16384
      High Usage Trap Raised:       No
            High Usage Threshold:         95 percent
            High Usage Clear Threshold:   90 percent
usage
Syntax

usage

Context

tools>dump>service>proxy-nd

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command provides information about the usage and limit of the system-wide proxy-ND table for all the services. The command also shows if the limit has been exceeded and a trap raised.

Output

The following output is an example of tools dump service proxy-nd usage information.

Sample output
*A:Dut# tools dump service proxy-nd usage 
Proxy nd Usage
            Current Usage       :        211
            System Limit        :     16384
      High Usage Trap Raised:       No
            High Usage Threshold:         95 percent
            High Usage Clear Threshold:   90 percent