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.
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.
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The following steps describe the unicast traffic behavior on PE3:
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.
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.
The same handling is used if the failure was at PE1.
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.
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.
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.
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.
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.
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.
The following steps list the behavior of the remote PE3 for unicast traffic:
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.
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.
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.
-
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.
-
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:1The 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.
-
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.
-
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.
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.
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:
-
PE2 withdraws the EVPN route.
-
The EVPN destination is removed in PE1 and operational group ‟llf-1” also goes down.
-
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.
-
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.
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 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:
-
Conditional static MACs (local protected MACs)
-
EVPN static MACs (remote protected MACs)
-
Data plane learned MACs (regular learning on SAPs/SDP bindings)
-
EVPN MACs with higher SEQ number
-
Lowest IP (next-hop IP of the EVPN NLRI)
-
Lowest Ethernet tag (that is zero for MPLS and may be different from zero for VXLAN)
-
Lowest RD
-
-
BGP route selection for MAC routes with the same route key
The following priority order is applied:
-
EVPN static MACs (remote protected MACs)
-
EVPN MACs with higher sequence number
-
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.
General EVPN topics
This section provides information about general topics related to EVPN.
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.
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:
-
ISP-A sends ARP-request for 10.10.10.3.
-
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.
-
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.
-
-
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.
-
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.
-
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.
-
-
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
A static entry is active in the FDB even when the service is down.
|
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:
provide the appropriate R flag information in proxy-ND NA replies.
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
-
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).
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:
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).
The retry in-minutes timer expires, which flushes the MAC and restarts the process.
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.
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:
conditional static MACs (local protected MACs)
EVPN static MACs (remote protected MACs)
data plane learned MACs (regular learning on SAPs/SDP-bindings)
EVPN MACs with higher SEQ number
lowest IP (next-hop IP of the EVPN NLRI)
lowest Ethernet tag (that is zero for MPLS)
lowest RD
BGP route selection for MAC routes with the same route-key
The priority order is as follows:
EVPN static MACs (remote protected MACs)
EVPN MACs with higher sequence number
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
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.
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 show commands
show
- service
- evpn-mpls
- id service-id
- bgp-evpn
- evpn-mpls [esi esi]
- proxy-arp [ip-address] [detail]
- proxy-nd [ip-address] [detail]
- system
- bgp-evpn
show
- redundancy
- bgp-evpn-multi-homing
EVPN clear commands
EVPN tools commands
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.
- 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.
- vpn vpn-id
-
Specifies the VPN ID number which allows you to identify VPNs by a VPN identification number.
- 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.
- 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.
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 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.
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.
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
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.
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.
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.
- 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.
- vpn vpn-id
Specifies the VPN ID number which allows you to identify VPNs by a VPN identification number.
- 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.
- as-number:ext-comm-val
Specifies the AS number.
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.
- minutes
Specifies the length of the window, in minutes.
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.
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.
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.
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.
- count
Specifies the number of moves required so that an entry is declared duplicate.
- hold-down minutes
Specifies the hold-down time, in minutes, for a duplicate entry.
- 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.
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.
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.
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.
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.
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.
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.
- 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.
- 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
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.
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.
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
------------------------------------------------------------
============================================================
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)
===============================================================================
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
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.
- 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 outputshow 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
===============================================================================
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.
- 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 outputA: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
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
===============================================================================
|
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
===============================================================================
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