EVPN Command Reference

This command configures an Epipe service instance. This command is used to configure a point-to-point epipe service. An Epipe connects two endpoints defined as Service Access Points (SAPs). Both SAPs may be defined in one or they may be defined in 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 a Service Distribution Point (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.

No MAC learning or filtering is provided on an Epipe.

When a service is created, the customer keyword and customer-id must be specified and associates the service with a customer. The customer-id must already exist having been created using the customer command in the service context. Once a service has been created with a customer association, it is not possible to edit the customer association. The service must be deleted and recreated with a new customer association.

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

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.

This command creates or edits a Virtual Private LAN Services (VPLS) instance. The vpls command is used to create or maintain a VPLS service. 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 service connects multiple customer sites together acting like a zero-hop, Layer 2 switched domain. A VPLS is always a logical full mesh.

When a service is created, the create keyword must be specified if the create command is enabled in the environment context. When a service is created, the customer keyword and customer-id must be specified and associates the service with a customer. The customer-id must already exist having been created using the customer command in the service context. Once a service has been created with a customer association, it is not possible to edit the customer association. The service must be deleted and recreated with a new customer association.

To create a management VPLS on a 7450 ESS, the m-vpls keyword must be specified. See section Hierarchical VPLS Redundancy for an introduction to the concept of management VPLS.

Once 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 service 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.

This command enables the context to configure the BGP related parameters for BGP AD, BGP VPLS and EVPN.

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, 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 ext-comm 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.

This command specifies the name of the VSI export policies to be used for BGP auto-discovery, BGP VPLS and BGP Multi-Homing if these features are 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.

This command specifies the name of the VSI import policies to be used for BGP auto-discovery, BGP VPLS and BGP Multi-Homing if these features are 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.

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

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

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

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.

This command specifies the name of the VSI import policies to be used for BGP auto-discovery, BGP VPLS and BGP Multi-Homing if these features are 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.

This command defines the type-1 route-distinguisher ipv4 address and community value range within which the system will select a route-distinguisher for the bgp-enabled services using auto-rd.

Interactions:

This command is used along with the route-distinguisher auto-rd command supported in VPLS, VPRN and Epipe services. The system forces the user to create a bgp-auto-range before the auto-rd option can be used in the services.

Note that the system will keep allocating values for services configured with route-distinguisher auto-rd as long as there are available community values within the configured range. Once the command is added, the following changes are allowed:

This command enables the context to configure the BGP EVPN parameters in the base instance.

This command controls how Ethernet AD per-ES routes are generated.

The system can either send a separate Ethernet AD per-ES route per service, or an Ethernet AD per-ES routes aggregating the route-targets for multiple services. While both alternatives will inter-operate, RFC 7432 states that the EVPN Auto-Discovery per-ES route must be sent with a set of route-targets corresponding to all the EVIs defined on the ethernet-segment. The command supports both options.

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

When enabled, the evi-rt-set option allows the aggregation of routes: A single AD per-ES route with the associated RD (ip-address:1) and a set of EVI route-targets will be advertised (to a maximum of 128). When a significant number of EVIs are defined in the ethernet-segment (hence the number of route-targets), the system will send more than one route. For example:

This command configures the Route Distinguisher (RD) component that will be signaled in the MP-BGP NLRI for EVPN corresponding to the base EVPN instance (Ethernet Segment routes). If the route-distinguisher component is not configured, the system will use system:ip-address as the default route-distinguisher

This command configures an ethernet-segment instance its corresponding name.

This command configures the ethernet-segment activation timer for a given ethernet-segment. The es-activation-timer delays the activation of a given ethernet-segment on a given PE that has been elected as DF (Designated Forwarder). Only when the es-activation-timer has expired, the SAP/SDP-binding 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).

If no es-activation-timer is configured, the system will use the value configured at config>redundancy>bgp-evpn-multi-homing>es-activation-timer if configured. Otherwise the system will use a default value of 3 seconds.

This command configures the 10-byte ethernet-segment identifier associated to 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.

This command configures a lag-id associated to the ethernet-segment. When the ethernet-segment is configured as all-active. only a lag can be associated to the ethernet-segment. When the ethernet-segment is configured as single-active, then a lag, port or sdp can be associated to the ethernet-segment. In either case, only one of the three objects can be configured in the ethernet-segment. A given lag can be part of only one ethernet-segment.

This command configures the multi-homing mode for the 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 a label for the esi 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.

This command configures a port-id associated with the ethernet-segment. If the ethernet-segment is configured as all-active only a lag can be associated to the ethernet-segment. If the ethernet-segment is configured as single-active, then a lag, port or sdp can be associated to the ethernet-segment. In any case, only one of the three objects can be configured in the ethernet-segment. A given port can be part of only one ethernet-segment. Only ethernet ports can be added to an ethernet-segment.

This command configures an sdp-id associated to the ethernet-segment. If the ethernet-segment is configured as all-active only a lag can be associated to the ethernet-segment. If the ethernet-segment is configured as single-active, then a lag, port or sdp can be associated to the ethernet-segment. In any case, only one of the three objects can be configured in the ethernet-segment. A given sdp can be part of only one ethernet-segment. Only user-configured sdps can be added to an ethernet-segment.

The service-carving algorithm determines the PE that is the Designated Forwarder (DF) in a given ethernet-segment and for a given service. This command enables the context to configure service-carving in the ethernet-segment.

This command configures the service-carving mode. This determines how the DF is elected for a given ethernet-segment and service.

This command enables the context to configure service-carving in a manual way, that is, configuring the evis or isids for which the PE is DF.

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

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

This command configures the isid ranges for which the PE is DF. Note that multiple individual isid values and multiple isid ranges are allowed. The PE will be non-DF for isid values not defined as primary.

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

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

This command configures the least significant two bytes of the BMAC used as source BMAC for packets generated from the ethernet-segment in PBB-EVPN.

When the multi-homing mode is all-active, this value and the first high order four bytes must match on all the PEs that are part of the same ethernet-segment.

The es-bmac-table-size parameter modifies the default value (8) for the maximum number of virtual bmacs that can be associated to the ethernet-segment, that is, the es-bmacs. When the source-bmac-lsb is configured, the associated es-bmac-table-size is reserved out of the total FDB. Note that the es-bmac will consume a separate BMAC per B-VPLS that is linked to an ethernet-segment

This command enables the context to configure the global redundancy parameters.

This command enables the context to configure the bgp-evpn global timers

When the PE boots up, the boot-timer will allow 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:

This command configures the global ethernet-segment activation timer. The es-activation-timer delays the activation of a given ethernet-segment on a given PE that has been elected as DF (Designated Forwarder). Only when the es-activation-timer has expired, the SAP/SDP-binding 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 es-activation-timer configured at the ethernet-segment level supersedes this global es-activation-timer.

This command enables the advertisement and withdrawal, as appropriate, of the IEEE MAC address associated with the MP (MEP & MIP) created on a SAP, Spoke or Mesh, in an EVPN service.

The up-date occurs each time an MP is added or deleted, or an IEEE MAC address is changed for an MP on a SAP, Spoke or Mesh within the service. The size of the update depends on the number of MPs in the service affected by the modification.

Note that you should only enable this functionality, as required, for services that require a resident MAC address to properly forward unicast traffic and that do not perform layer two MAC learning as part of the dataplane.

Local MP IEEE MAC addresses are not stored in the local FDB and, as such, cannot be advertised through a control plane to a peer without this command.

The no version of the command disables the functionality and withdraws all previously advertised MP IEEE MAC addresses.

This command allows you to specify a 2-byte EVPN instance unique in the system. It is used for the service-carving algorithm for multi-homing and auto-deriving route-target and route-distinguishers.

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

Note that if vsi-import and export policies are configured, the route-target must be configured in the policies and those values take preference over the auto-derived route-targets. The operational route-target for a service will be shown in the show service id bgp command.

The no version of the command will set the evi value back to zero.

This command enables and disables the advertisement of the Inclusive Multicast Ethernet Tag route (IMET route) with tunnel-type Ingress-Replication in the PMSI Tunnel Attribute, or with the tunnel-type Composite Point-to-Multipoint and Ingress-Replication (P2MP+IR) in the root-and-leaf nodes. The following considerations must be taken into account:

This command enables and disables the advertisement of IP prefixes in EVPN.If enabled, any active route in the R-VPLS VPRN route table will be advertised in EVPN using the VPLS BGP configuration. Note that the interface host addresses are not advertised in EVPN unless the ip-route-advertisement incl-host command is enabled.

This command enables and disables the context in which the local ethernet tag value is configured.

This command enables and disables the context in which the remote ethernet tag value is configured.

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

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

This command enables the context to configure the BGP EVPN MAC duplication parameters.

The mac-duplication featured is always enabled by default. This command modifies the default behavior. mac-duplication monitors the number of moves of a MAC address for a period of time (window).

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 no retry is configured, this implies that, once mac-duplication is detected, MAC updates for that MAC will be held down till the user intervenes or a network event (that flushes the MAC) occurs.

This command enables the context to configure the BGP EVPN MPLS parameters.

This command enables the context to configure automatic binding of a BGP-EVPN service using tunnels to MP-BGP peers.

The auto-bind-tunnel node is simply a context to configure the binding of EVPN routes to tunnels. The user must configure the resolution option to enable auto-bind resolution to tunnels in TTM. The following configurations are available:

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

The ldp value instructs BGP to search for an LDP LSP with a FEC prefix corresponding to the address of the BGP next-hop.

The rsvp value instructs BGP to 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.

When the sr-isis (sr-ospf) value is enabled, a SR tunnel to the BGP next-hop is selected in the TTM from the lowest numbered ISIS (OSPF) instance.

The sr-te value instructs the code to search for the best metric SR-TE LSP to the address of the BGP next-hop. The LSP metric is provided by MPLS in the tunnel table. In the case of multiple SR-TE LSPs with the same lowest metric, BGP selects the LSP with the lowest tunnel-id.

The bgp value instructs 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, inter-area or inter-as prefixes will not be resolved.

The user must set resolution to filter to activate the list of tunnel-types configured under resolution-filter.

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

This command enables the context that allows the configuration of 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), and BGP.

Selects the BGP tunnel type.

Selects the LDP tunnel type.

Selects the RSVP-TE tunnel type.

Selects the Segment Routing (SR) tunnel type programed by an ISIS instance in TTM.

Selects the Segment Routing (SR) tunnel type programed by an OSPF instance in TTM.

Selects the Segment Routing (SR) Traffic Engineered (SR-TE) LSP programmed in TTM.

This command enables the transmission and reception of the control-word. As defined in RFC7432, the use of the control-word helps avoid frame disordering.

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

This command controls the number of paths to reach a given MAC address when that MAC in the FDB is associated to a remote all-active multi-homed ethernet-segment.

The configuration of 2 or more ecmp paths to a given MAC enables the “aliasing” function described in RFC7432.

If entropy-label is configured, the Entropy label and Entropy Label Indicator are inserted in packets for which at least one LSP in the stack for the far-end of the tunnel used by the service has advertised entropy label capability. If the tunnel is RSVP type, entropy-label can also be controlled under the config>router>mpls or config>router>mpls>lsp context.

The entropy label is mutually exclusive with the hash label feature. The entropy label cannot be configured on a spoke-sdp or service where the hash label feature has already been configured unless no hash label is set, and vice-versa.

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.

Note that this command may be used in conjunction with the sap ingress vlan-translation command. If so used, the configured translated vlan-id will be 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 will be zero.

This command allows the user to configure the system so that a separate label is sent for BUM (Broadcast, Unknown unicast and Multicast) traffic in a given service. By default (no ingress-replication-bum-label), the same label is used for unicast and flooded BUM packets when for-warding traffic to remote PEs.

When saving labels, this might cause transient traffic duplication for all-active multi-homing. By enabling ingress-replication-bum-label, 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, so that the egress PE can determine if the 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 certain macs.

This command controls the administrative state of EVPN-MPLS in the service.

This command allows the user to configure an explicit split-horizon-group for all BGP-EVPN MPLS destinations that can be shared by other SAPs and/or 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 split-horizon-group command for bgp-evpn>mpls> 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 to saps, spoke-sdps, pw-templates, pw-template-bindings and EVPN-MPLS destinations. The configuration of bgp-evpn>mpls> split-horizon-group will only be allowed if bgp-evpn>mpls is shutdown; no changes are allowed when bgp-evpn>mpls is no shutdown.

When the SAPs and/or spoke-SDPs (manual or BGP-AD-discovered) are configured within the same split-horizon-group as the EVPN-MPLS endpoints, MAC addresses will still be learned on them but they will not be advertised in BGP-EVPN. If provider-tunnel is enabled in the bgp-evpn 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.

This command enables the advertisement of the unknown-mac-route in BGP. This will be coded in an EVPN MAC route where the MAC address is zero and the MAC address length 48. By using this unknown-mac-route advertisement, the user may decide to optionally turn off the advertisement of MAC addresses learned from saps and sdp-bindings, hence reducing the control plane overhead and the size of the FDB tables in the data center. All the receiving NVEs supporting this concept will send any unknown-unicast packet to the owner of the unknown-mac-route, as opposed to flooding the unknown-unicast traffic to all other nodes part of the same VPLS. Note that, although the 7750 SR, 7450 ESS, or 7950 XRS can be configured to generate and advertise the unknown-mac-route, the router will never honor the unknown-mac-route and will flood to the vpls flood list when an unknown-unicast packet arrives to an ingress sap/sdp-binding.

Use of the unknown-mac-route is only supported for BGP-EVPN VXLAN.

This command enables the use of vxlan in the VPLS service.

This command enables the context to configure the VXLAN parameters when BGP EVPN is used as the control plane.

This command enables and disables the automatic creation of VXLAN auto-bindings by BGP-EVPN.

This command enables the context where the PBB parameters are configured.

This command is only supported in B-VPLS instances where BGP-EVPN is enabled and controls the source BMAC used by the system for packets coming from the SAP or spoke-SDPs when they belong to an EVPN ethernet-segment.

If enabled, the system will use a source BMAC derived from the source-bmac (high order four bytes) and the least significant two bytes configured in config>service>system>bgp-evpn>ethernet-segment>source-bmac-lsb for all the packets coming from the local ethernet-segment.

If no use-es-bmac is configured, the system will use the regular source-bmac (provided by the config>service>vpls>pbb>source-bmac command, or the chassis bmac if the source-bmac is not configured).

This command enables the context to configure the use of a P2MP LSP to forward Broadcast, Unknown unicast, and Multicast (BUM) packets of a VPLS or B-VPLS instance. The P2MP LSP is referred to as the Provider Multicast Service Interface (PMSI).

This command enables the context to configure the use of a P2MP LSP as the default tree for forwarding Broadcast, Unknown unicast, and Multicast (BUM) packets of a VPLS or B-VPLS instance. The P2MP LSP is referred to, in this case, as the Inclusive Provider Multicast Service Interface (I-PMSI).

When enabled, this feature relies on BGP Auto-Discovery (BGP-AD), BGP-VPLS or BGP-EVPN to discover the PE nodes participating in a given VPLS/B-VPLS instance. In the case of BGP-AD or BGP-VPLS, the BGP route contains the information required to signal both point-to-point (P2P) PWs used to forward unicast known Ethernet frames, and the RSVP or mLDP P2MP LSP used to forward the BUM frames. In the case of BGP-EVPN, the EVPN IMET route contains the information to set up the mLDP P2MP LSP and may also contain the information that enables the remote leaf-only nodes to setup an EVPN destination to the sending PE.

Note: The provider-tunnel for a given service must be configured with an owner protocol (BGP-AD, BGP-VPLS or BGP-EVPN); only one owner must be configured. Use the owner {bgp-ad|bgp-vpls|bgp-evpn-mpls} command to configure an owner.

With an mLDP I-PMSI, each leaf node will initiate the signaling of the mLDP P2MP LSP upstream using the P2MP FEC information in the I-PMSI tunnel information discovered through the BGP.

Use the mldp command to enable the use of an LDP P2MP LSP as the I-PMSI for forwarding Ethernet BUM and IP multicast packets in a VPLS instance:

config>service>vpls [b-vpls]>provider-tunnel>inclusive>mldp

When a no shutdown is performed under the context of the inclusive node and the expiration of a delay timer, BUM packets will be forwarded over an automatically signaled mLDP P2MP LSP.

Use the root-and-leaf command to configure the node to operate as both root and leaf in the VPLS instance:

config>service>vpls [b-vpls]>provider-tunnel>inclusive>root-and-leaf

The node behaves as a leaf-only node by default. For the I-PMSI of type mLDP, the leaf-only node will join I-PMSI rooted at other nodes it discovered but will not include a PMSI Tunnel Attribute in BGP route update messages. This way a leaf-only node will forward packets to other nodes in the VPLS/B-VPLS using the point-to-point spoke-sdps in the case of BGP-AD or BGP-VPLS, or using EVPN destinations in the case of BGP-EVPN.

Note: Either BGP-AD/VPLS or BGP-EVPN must be enabled in the VPLS/B-VPLS instance otherwise the execution of the no shutdown command under the context of the inclusive node will fail and the I-PMSI will not come up.

If the P2MP LSP instance goes down, the VPLS/B-VPLS immediately reverts the forwarding of BUM packets to the P2P PWs or EVPN destinations (in the case of BGP-EVPN). Performing a shutdown under the context of the inclusive node will allow the user to restore BUM packet forwarding over the P2P PWs or EVPN destinations.

This feature is supported with VPLS and B-VPLS; it is not supported with I-VPLS. Although Routed VPLS is supported, routed traffic cannot be sent over the I-PMSI tree.

This command enables the context to configure the I-PMSI data delay timer.

For an mLDP P2MP LSP, the delay timer is started as soon as the P2MP FEC corresponding to the I- PMSI is resolved and installed at the root node. When configuring a value at the root node, the user must factor the configured IGP-LDP sync timer (config>router>interface>ldp-sync-timer) on the network interfaces. This is required because the mLDP P2MP LSP may move to a different interface at the expiry of the sync timer as the routing upstream of the LDP Label Mapping message may change when the sync timer expires and the interface metric is restored.

When the data delay timer expires, the VPLS/B-VPLS begins forwarding BUM packets over the P2MP LSP instance even if all the paths are not up.

The no version of this command reinstates the default value for the delay timer.

This command enables the context to configure the parameters of an LDP P2MP LSP used for forwarding Broadcast, Unicast unknown and Multicast (BUM) packets of a VPLS or B-VPLS instance.

This command enables the node to operate as both root and leaf of the I-PMSI in a given VPLS/B-VPLS instance.

By default, a node will behave as a leaf-only node. For the I-PMSI of type mLDP, the leaf-only node will join I-PMSI rooted at other nodes it discovered but will not include a PMSI Tunnel attribute in BGP route update messages. This way a leaf-only node will forward packets to other nodes in the VPLS/B-VPLS using the point-to-point spoke-sdp's or the EVPN destinations.

The no version of the command reinstates the default value.

This command selects the owner protocol of the inclusive PMSI tunnel in the service. Only one of the protocols will support the provider tunnel.

The bgp-vpls and bgp-evpn-mpls parameters cannot be configured together in the same service. Although bgp-ad and bgp-evpn can coexist in the same service, bgp-ad cannot be configured as the owner of the provider-tunnel. In addition, the following applies to this configuration:

This command administratively enables and disables the service.

This command enables the context to configure the proxy-ARP parameters in a VPLS service.

This command enables the context to configure the proxy-ND parameters in a VPLS service.

This command specifies the aging timer per proxy-ARP/proxy-ND entry for dynamic entries. When the aging expires, the entry is flushed. The age is reset when a new ARP/GARP/NA for the same MAC-IP is received. If the corresponding FDB MAC entry is flushed, the proxy-ARP/proxy-ND entry goes inactive and subsequent ARP/NS lookups are treated as "missed". EVPN will withdraw the IP->MAC if the entry goes inactive. The age-time should be set at send-refresh * 3 to ensure that no active entries are unnecessarily removed.

This command enables a 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/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 is configured, the proxy-ARP/ND offending entry's MAC is replaced with this <mac-address> and advertised in an unsolicited GARP/NA for local SAP/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.

The anti-spoof-mac can also be combined with the static-black-hole option. To use a black-hole MAC entry for the anti-spoof-mac function in a proxy-ARP/ND service, the following must be configured:

When both anti-spoof-mac and static-black-hole commands are configured, the MAC is advertised in EVPN as Static. Locally, the MAC will be shown in the FDB as 'CStatic' and associated with a black-hole.

The combination of the anti-spoof-mac and the static-black-hole options ensures that any frame arriving in the system with MAC DA = anti-spoof-mac will be discarded, irrespective of the ingress endpoint type (SAP/SDP-binding or EVPN) and without the need for a filter.

If the user wants to redirect the traffic with MAC DA = anti-spoof-mac instead of discarding it, redirect filters should be configured on saps/sdp-bindings instead of the static-black-hole option

If the static-black-hole option is not configured for the anti-spoof-mac, the behavior is as follows:

Any changes to the configuration of anti-spoof-mac require proxy-arp or proxy-nd to first be shut down. See ARP/ND Snooping and Proxy Support for more information.

This command enables the addition of dynamic entries to the proxy-ARP table (disabled by default). When executed, the system will populate proxy-ARP entries from snooped GARP/ARP messages on SAPs/SDP-bindings. These entries will be shown as dynamic.

When disabled, dynamic-arp entries will be flushed from the proxy-ARP table. Enabling dynamic-arp-populate is only recommended in networks with a consistent configuration of this command in all the PEs.

This command controls whether the system floods GARP-requests / GARP-replies to the EVPN. The GARPs impacted by this command are identified by the sender's IP being equal to the target's IP and the MAC DA being broadcast.

The no form of the command only floods to local saps/binds but not to EVPN destinations.

Disabling this command 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.

If enabled, this command will make the system send a refresh at the configured time. A refresh message is an ARP-request message that uses 0s as sender's IP for the case of a proxy-ARP entry. For proxy-ND entries, a refresh is a regular NS message using the chassis-mac as MAC source-address.

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

This command adds a table-size limit per service. By default, the table-size 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/trap is triggered. When the system/service limit is reached, entries for a given IP can be replaced (a different MAC can be learned and added) but no new IP entries will be 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 will fail.

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 the command will only flood to local SAPs/SDP-bindings and not to EVPN destinations.

This command enables the addition of dynamic entries to the proxy-ND table. The command is disabled by default. When executed, the system will populate proxy-ND entries from snooped Neighbor Advertisement (NA) messages on SAPs/SDP-bindings, in addition to the entries coming from EVPN (if the EVPN is enabled). These entries will be shown as dynamic, as opposed to EVPN entries or static entries.

When disabled, dynamic-ND entries will be flushed from the proxy-ND table. Enabling dynamic-nd-populate is only recommended in networks with a consistent configuration of this command in all the PEs.

This command enables two different functions: on the one hand it enables the advertisement of static or dynamic entries that are learned as host or routers (only one option is possible for a given service). On the other hand, it determines the R flag (host or router) when sending Neighbor Advertisement (NA) messages for existing EVPN entries in the proxy-ND table.

This command cannot be modified without proxy-nd shutdown.

This command controls whether the system floods host unsolicited Neighbor Advertisements to the EVPN. The NA messages impacted by this command are NA messages with the following flags: S=0 and R=0.

The no form of the command will only flood to local saps/binds but not to the EVPN destinations. This 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.

This command controls whether the system floods router unsolicited Neighbor Advertisements to EVPN. The NA messages impacted by this command are NA messages with the following flags: S=0 and R=1.

The no form of the command will only flood to local saps/binds 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 BGP does not miss the advertisement of these entries.

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

This command controls whether unknown Neighbor Solicitation messages are 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 the command will only flood to local SAPs/SDP-bindings but not to EVPN destinations.

This command enables and disables the proxy-ARP and proxy-nd functionality. ARP/GARP/ND messages will be 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->MAC pairs received from different sources (EVPN, static, dynamic). When the shutdown command is issued, it flushes the dynamic/EVPN dup proxy-ARP/proxy-ND table entries and instructs the system to stop snooping ARP/ND frames. All the static entries are kept in the table as inactive, regardless of their previous Status.

A set of conditional static MAC addresses can be created within a VPLS supporting bgp-evpn. Conditional Static Macs are also supported in B-VPLS with SPBs. Unless they are configured as black-hole, conditional Static Macs are dependent on the SAP/SDP state.

This command allows the assignment of a set of conditional Static MAC addresses to a SAP/ spoke-SDP or black-hole. In the FDB, the static MAC is then associated with the active SAP or spoke SDP.

When configured in conjunction with SPBM services, Static MACs are used for PBB Epipe and I-VPLS services that may terminate external to SPBM. If this is configured under a Control B-VPLS the interface referenced will not use IS-IS for this neighbor. This may also be configured under a User B-VPLS where the corresponding interface is not supported under the Control B-VPLS.

Static MACs configured in a bgp-evpn service are advertised as protected (EVPN will signal the MAC as protected).

This command assigns a conditional static MAC address entry to an SPBM B-VPLS SAP/spoke-SDP or black-hole, allowing external MACs for single and multi-homed operation.

This command also assigns a conditional static MAC address entry to an EVPN VPLS SAP/spoke-SDP or a black-hole on the 7450 ESS or 7750 SR.

When configured in conjunction with SPBM services, Static MACs are used for PBB Epipe and I-VPLS services that may terminate external to SPBM. If this is configured under a Control B-VPLS the interface referenced will not use IS-IS for this neighbor. This may also be configured under a User B-VPLS where the corresponding interface is not supported under the Control B-VPLS.

This command enables and disables the evpn-tunnel mode for the attached R-VPLS. When enabled, no IP address will be required under the same interface.

This command associates a previously configured vsd-domain to an existing VPRN or VPLS service. The vsd-domain is a tag used between the VSD and the 7750 SR, 7450 ESS, or 7950 XRS to correlate configuration parameters to a service.

This command provides the context for the vsd configuration.

This command configures a vsd-domain that can be associated to a VPLS or VPRN service.

This command provides a description for a vsd-domain. This description must be added before the domain can be no shutdown.

This command configures the range of service identifiers that the system allows for dynamic services configured by python, when the Nuage VSD sends the service configuration parameters for the VSD fully-dynamic integration model

This command enables or disables a domain. A description must be provided before no shutdown is executed.

This command configures the DC GW system-id that is used for the configuration from VSD. VSD will identify the DC GW based on this identifier, hence it must be unique per VSD.

This command provides the context for the xmpp configuration.

This command configures the XMPP server as well as the Jabber ID that the 7750 SR, 7450 ESS, or 7950 XRS will use for the XMPP communication with the server. Note that the system uses DNS to resolve the configured domain-name.

no server name will remove all the dynamic configurations in all the services.

This command enables or disables the communication with a given XMPP server. When the xmpp server is properly configured, no shutdown instructs the system to establish a TCP session with the XMPP server through the management interface first. If it fails to establish communication, the 7750 SR, 7450 ESS, or 7950 XRS uses an in-band communication and its system IP as source IP address. Shutdown does not remove the dynamic configurations.

This command enables the context for the configuration of the security parameters in the system.

This command enables the context for the configuration of the security parameters in the system.

This command enables the context for the configuration of the authorization parameters for the cli-scripts in the system.

This command enables the context for the configuration of the authorization parameters related to VSD in the system.

This command configures the cli-user for the configuration coming from VSD (fully dynamic VSD integration model). The user-profile determines what CLI set of commands can be executed by the VSD. This set of commands is a sub-set of the white-list of commands allowed by the system for the or VSD. You can use the tools dump service vsd-services command-list to check the white-list of commands.

This command enables the context for the configuration of the passwords in the system.

This command configures the password required to access the enable-vsd-config mode. The enable-vsd-config mode allows editing of services provisioned by the VSD in fully dynamic mode (or by the tools perform service vsd evaluate-script command

This command enables the context for the configuration of the base router in the system.

This command enables the context for the configuration of the base router bgp parameters in the system.

This command enables the context for the configuration of a bgp group in the base router.

This command enables the context for the configuration of a bgp group neighbor in the base router.

This command defines how the BGP will treat a received EVPN route without RC5512 BGP encapsulation extended community. If no encapsulation is received, BGP will validate the route as MPLS or VXLAN depending on how this command is configured.

This command enables the context for the configuration of the python parameters in the system.

This command enables the context for the configuration of the python policy parameters in the system.

This command defines the python script for the python-policy sent by the VSD.

This command allows editing of vsd services just like normal services. As this is an action that should only be executed by authorized personnel, the activation of this command is protected by the use of a password, defined under configure system security password vsd-password.

When the vsd modifier is used, this command displays the VSD domain tags used and the associated service identifier. If the modifier origin vsd is used, the command displays the services created by the VSD fully-dynamic integration model. (Python will actually create the service after receiving the relevant parameters from VSD).

This command enables the context to display the system parameters.

This command shows all the information related to the base EVPN instance, including the base RD used for ES routes, the ethernet-segments or individual ethernet-segment information.

This command enables the context to display the ethernet-segment parameters.

This command enables the context for the vsd parameters.

This command shows all the parameters related to a VSD domain created by the user or by VSD.

This command displays the root objects created by vsd.

This command enables the context to show dynamic services script information.

This command displays the dynamic services snippets information. The CLI output generated by a single vsd service python function call is a snippet instance

This command displays vsd service script statistics. Only non-zero values are shown. The script statistics can be cleared with the "clear service statistics vsd" command.

This command displays the global configuration summary for vsd services.

This command displays the bgp-evpn configured parameters for a given service, including the admin status of vxlan, 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. This command also shows whether the ip-route-advertisement command (and the incl-host parameter) has been enabled. If the service is bgp-evpn mpls, the command will show the parameters corresponding to evpn-mpls.

This command displays the existing EVPN-MPLS destinations for a given service and all related information. The command allows filtering based on esi (for EVPN multi-homing) and es-bmac (for PBB-EVPN multi-homing) to display the EVPN-MPLS destinations associated to an esi.

This command shows the remote ethernet-segment identifiers as well as the BGP-EVPN MPLS destinations associated to them.

This command shows the remote ethernet-segment BMACs as well as the BGP-EVPN MPLS destinations associated to them.

When a filter with an action forward esi is successfully added to a VPLS service and the PE receives an EVPN Auto-Discovery route for the configured ESI, this command displays the PBR VXLAN bindings auto-created, including the ESI, the VXLAN VTEP:VNI and the status of the binding.

This command displays the proxy-ARP entries existing for a particular service. This table is populated by the EVPN MAC routes containing a MAC and an IP address , as well as static entries or dynamic entries from snooped ARP messages on access SAP/SDP-bindings. A 7750 SR, 7450 ESS, or 7950 XRS receiving an ARP request from a SAP or SDP-binding will perform a lookup in the proxy-arp table for the service. If the router finds a match, it will reply to the ARP and will not let the ARP be flooded in the VPLS service. If the router does not find a match, the ARP will be flooded within the service if the configuration allows it. The command allows for an specific IP addresses to be shown.

This command displays the VXLAN bindings auto-created in a given service. A VXLAN binding is composed of the remote VTEP (VXLAN Termination Endpoint) and the corresponding egress VNI (VXLAN Network Identifier) to identify the service at the egress node. The command shows the number of MACs associated to each binding as well as the operational status and if the binding is part of the multicast list. The binding will be operationally down when the VTEP address is not found in the base routing table (the VTEP address cannot be reached). A binding will be part of the multicast list if a valid BGP EVPN inclusive multicast route exists for it.

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

This command shows the connectivity to the XMPP server, including the configured parameters and statistics. When the user provides the name of the server, a detailed view is shown.

This command shows the connectivity to the VSD server, including the configured parameters and statistics. When the user provides the entry number of the VSD server as shown in the show system xmpp vsd command, a detailed view for that specific server is shown, including statistics.

This command shows the different VSD domains configured in the system. If association is added, the VSD domain to service association is shown. If a specific domain-name is used, configuration event statistics are shown.

This command enables the context for the display of global redundancy parameters.

This command shows the information related to the EVPN global timers.

This command clears the statistics shown in the show service vsd domain name command.

This command clears the statistics shown in the show service vsd script statistics command.

This command clears the statistics shown in the show system xmpp server name command.

This command clears the statistics shown in the show system xmpp server name command.

This command enables the debug for XMPP messages sent or received by the 7750 SR, 7450 ESS, or 7950 XRS.

This command enables the context for the debug vsd commands.

This command enables the debug of the VSD fully dynamic integration scripts.

This command enables/disables the generation of all script debugging event output: cli, errors, execute-cmd, warnings, state-change.

This command enables/disables the generation of script debugging for a specific instance

This command enables/disables the generation of a specific script debugging event output: cli.

This command enables/disables the generation of a specific script debugging event output: errors.

This command enables/disables the generation of a specific script debugging event output: execute-cmd.

This command enables/disables the generation of a specific script debugging event output: state-change.

This command enables/disables the generation of a specific script debugging event output: warnings.

Use this command to configure tools to display service dump information.

Use this command to configure parameters to display service ID information.

This command displays the number of times a service could not add a VXLAN binding or <VTEP, Egress VNI> due to the following limits:

The command adds a clear option to clear the above statistics.

This command dumps the <VTEP, VNI> bindings that have been detected as duplicate attempts, i.e. an attempt to add the same binding to more than one service. The commands provides a clear option.

This command shows the maximum number of EVPN-tunnel interface IP next-hops per R-VPLS as well as the current usage for a given R-VPLS service.

This command enables the context for the domain-to-vsd mappings.

This command shows mapping of a given VSD to a vsd-domain.

This command enables the xmpp context.

This command instructs the system to refresh immediately the list of VSDs and not to wait for the next VSD list audit that the system does periodically.

This command instructs the system to audit the VSD to get the "DIFF" list of even the "FULL" list of all the do-mains in the VSD.

The command enables the user to test their setup, and modify and teardown python scripts in a lab environment without the need to be connected to a VSD. The successful execution of the command for action setup will create a vsd domain and the corresponding configuration, just as the system would do when the parameters are received from VSD.

This command instructs the system to refresh the configuration of a given domain immediately instead of waiting for the next audit interval.

This command enables the context for the bgp-evpn base instance.

This command shows the computed DF PE for a given evi or isid.

This command enables the context for the global evpn parameters.

This command displays the consumed VXLAN EVPN resources in the system.

This command enables the context for vsd-services commands.

This command displays the list of CLI nodes allowed in the VSD fully dynamic provisioning model. Python will have access to the shown nodes.

When access is granted to a node, all commands in that node are allowed; however, CLI nodes are only allowed if explicitly listed. Nodes in CLI are shown with a "+" in the CLI.

While you can navigate special "Pass through nodes" via these nodes, the commands in that node are not implicitly allowed. When configured in a service through VSD, these commands will not be shown in the 'info' output of the config command.

Note: A 'node' implies leaf-nodes and leaf-table nodes in reality. A 'Leaf-table' is a sub-table that looks like a leaf (i.e. it is entered/displayed as a one-liner). An example of leaf-table node is /configure router policy-options prefix-list x prefix 0.0.0.0/0 - since you can have multiple instances of prefixes.