5.8. VPLS Services Command Reference

This command creates a text description stored in the configuration file for a configuration context.

The description command associates a text string with a configuration context to help identify the content in the configuration file.

The no form of this command removes the string from the configuration.

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

The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

Services are created in the administratively down (shutdown) state. When a no shutdown command is entered, the service becomes administratively up and then tries to enter the operationally up state. Default administrative states for services and service entities is described as follows in Special Cases.

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

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, 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 parameter must be specified to associate the service with a customer. The customer-id value must already exist, having been created using the customer command in the service context. When 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.

When a service is created, the use of the customer customer-id command is optional for navigating into the service configuration context. Editing a service with the incorrect customer-id value specified results 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 shut down and deleted, and the service has been shut down.

This command creates or maintains a virtual private LAN services (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 service connects multiple customer sites, 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 parameter must be specified to associate the service with a customer. The customer-id value must already exist, having been created using the customer command in the service context. When 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.

When a service is created, the use of the customer customer-id command is optional for navigating into the service configuration context. Editing a service with the incorrect customer-id value specified results 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 shut down and deleted, and the service has been shut down.

This command enables the context to configure the parameters related to BGP.

This command enables the context to configure the parameters related to BGP AD.

This command enables blocking (brings the entity to an operationally down state) after all configured mesh-SDPs are in the operationally down state. This event is signaled to corresponding T-LDP peer by withdrawing service label (status-bit-signaling non-capable peer) or by setting “PW not forwarding” status bit in T-LDP message (status-bit-signaling capable peer).

This command enables the translation of BPDUs to a specific format, meaning that all BPDUs transmitted on a specific SAP or spoke-SDP have a specified format.

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

Note: The config>service>vpls>spoke-sdp context is not supported on 7210 SAS platforms configured in the access-uplink operating mode.

This command enables Layer 2 Protocol Tunneling (L2PT) termination on a specific SAP or spoke-SDP. L2PT termination is supported for CDP, DTP, PAGP, STP, UDLD, VTP, and LLDP PDUs.

This feature can be enabled only if STP is disabled in the context of the specific VPLS service.

Note: The config>service>vpls>spoke-sdp and config>service>pw-template contexts are not supported on platforms configured in the access-uplink operating mode.

This command disables MAC address aging across a VPLS service or on a VPLS service SAP.

Like in a Layer 2 switch, learned MACs can be aged out if no packets are sourced from the MAC address for a period of time (the aging time). In each VPLS service instance, there are independent aging timers for local learned MAC and remote learned MAC entries in the VPLS forwarding database (FDB). The disable-aging command turns off aging for local and remote learned MAC addresses.

When no disable-aging is specified for a VPLS, it is possible to disable aging for specific SAPs and/or spoke-SDPs by entering the disable-aging command at the appropriate level.

When the disable-aging command is entered at the VPLS level, the disable-aging state of individual SAPs or SDPs is ignored.

The no form of this command enables aging on the VPLS service.

Note: The config>service>pw-template context is not supported on platforms configured in the access-uplink operating mode.

This command disables learning of new MAC addresses in the VPLS forwarding database (FDB) for the service instance.

When disable-learning is enabled, new source MAC addresses is not entered in the VPLS service forwarding database.

When disable-learning is disabled, new source MAC addresses is learned and entered into the VPLS forwarding database.

This parameter is mainly used in conjunction with the discard-unknown command.

The no form of this command enables learning of MAC addresses.

By default, packets with unknown destination MAC addresses are flooded. If discard-unknown is enabled at the VPLS level, packets with unknown destination MAC address is dropped instead (even when configured FIB size limits for VPLS or SAP are not yet reached).

The no form of this command allows flooding of packets with unknown destination MAC addresses in the VPLS.

This command configures a service endpoint.

This command creates a text description stored in the configuration file for a configuration context.

The description command associates a text string with a configuration context to help identify the content in the configuration file.

The no form of this command removes the string from the configuration.

This command causes the node to ignore the standby-bit received from TLDP peers for the specific spoke-SDP and performs internal tasks without taking it into account.

This command is present at endpoint level as well as spoke-SDP level. If the spoke-SDP is part of the explicit-endpoint, it is not possible to change this setting at the spoke-SDP level. The existing spoke-SDP becomes part of the explicit-endpoint only if the setting is not conflicting. The newly created spoke-SDP which is a part of the specific explicit-endpoint inherits this setting from the endpoint configuration.

This command configures the time to wait before reverting to primary spoke-SDP.

In a regular endpoint the revert-time setting affects just the pseudowire defined as primary (precedence 0). For a failure of the primary pseudowire followed by restoration the revert-timer is started. After it expires the primary pseudowire takes the active role in the endpoint. This behavior does not apply for the case when both pseudowires are defined as secondary. For example, if the active secondary pseudowire fails and is restored it stays in standby until a configuration change or a force command occurs.

This command assigns a static MAC address to the endpoint. In the FDB, the static MAC is then associated with the active spoke-SDP.

When this command is enabled, the pseudowire standby bit (with value 0x00000020) is not sent to T-LDP peer when the specific spoke is selected as a standby. This allows faster switchover as the traffic is sent over this SDP and discarded at the blocking side of the connection. This is particularly applicable to multicast traffic.

This command specifies whether MAC flush messages received from the specific LDP are propagated to all spoke and mesh SDPs within the context of this VPLS service. The propagation follows the split-horizon principle and any data-path blocking to avoid the looping of these messages.

This command specifies the value to send logs and traps when the threshold is reached.

This command specifies the value to send logs and traps when the threshold is reached.

This command specifies the maximum number of MAC entries in the Forwarding Database (FDB) for the VPLS instance on this node.

The fdb-table-size specifies the maximum number of forwarding database entries for both learned and static MAC addresses for the VPLS instance.

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

This command specifies the name of the VSI export policies to be used for BGP auto-discovery, if this feature is configured in the 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, if this feature is configured in the 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 target (RT) component that is signaled in the related MPBGP attribute to be used for BGP auto-discovery, if this feature is configured in the 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.

The following rules apply:

This command binds the advertisements received with the route target (RT) that matches the configured list (either the generic or the specified import) to a specific pw-template. If the RT list is not present the pw-template is used for all of them.

The pw-template-binding applies to BGP-AD, if this feature is configured in the VPLS service.

The tools perform commands can be used to control the application of changes in pw-template for BGP-AD.

The no form of this command removes the values from the configuration.

This command configures the Route Distinguisher (RD) component that is signaled in the MPBGP NLRI for L2VPN AFI. This value is used for BGP-AD, if this feature is configured in the VPLS service.

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

This command configures the aging time for locally learned MAC addresses in the forwarding database (FDB) for the Virtual Private LAN Service (VPLS) instance. In a VPLS service, MAC addresses are associated with a Service Access Point (SAP). MACs associated with a SAP are classified as local MACs, and MACs associated with are remote MACsQinQ / access-uplink SAPs.

Like in a Layer 2 switch, learned MACs can be aged out if no packets are sourced from the MAC address for a period of time (the aging time). The local-age timer specifies the aging time for local learned MAC addresses.

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

This command enables the context to configure MAC move attributes. A sustained high relearn rate can be a sign of a loop somewhere in the VPLS topology. Typically, STP detects loops in the topology, but for those networks that do not run STP, the mac-move feature is an alternative way to protect your network against loops.

When enabled in a VPLS, mac-move monitors the relearn rate of each MAC. If the rate exceeds the configured maximum allowed limit, it disables the SAP where the source MAC was last seen. The SAP can be disabled permanently (until a shutdown/no shutdown command is executed) or for a length of time that grows linearly with the number of times the specific SAP was disabled. You have the option of marking a SAP as non-blockable in the config>service>vpls>sap>limit-mac-move context. This means that when the relearn rate has exceeded the limit, another (blockable) SAP is disabled instead.

The mac-move command enables the feature at the service level for SAPs, as only those objects can be blocked by this feature.

The operation of this feature is the same on the SAP. For example, if a MAC address moves from SAP to SAP, one is blocked to prevent thrashing.

The mac-move command disables a VPLS port when the number of relearns detected has reached the number of relearns needed to reach the move-frequency in the 5-second interval. For example, when the move-frequency is configured to 1 (relearn per second) mac-move disables one of the VPLS ports when 5 relearns were detected during the 5-second interval because then the average move-frequency of 1 relearn per second has been reached. This can already occur in the first second if the real relearn rate is 5 relearns per second or higher.

The no form of this command disables MAC move.

This command specifies the maximum rate at which MACs can be relearned in the VPLS service, before the SAP where the moving MAC was last seen is automatically disabled to protect the system against undetected loops or duplicate MACs.

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

This command specifies the time in seconds to wait before a SAP that has been disabled after exceeding the maximum relearn rate is re-enabled.

It is recommended that the retry-timeout value is larger or equal to 5s * cumulative factor of the highest priority port so that the sequential order of port blocking is not disturbed by reinitializing lower priority ports.

A zero value indicates that the SAP is not automatically re-enabled after being disabled. If, after the SAP is re-enabled it is disabled again, the effective retry timeout is doubled to avoid thrashing.

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

This command specifies the multicast FIB high watermark. When the percentage filling level of the multicast FIB exceeds the configured value, a trap is generated and/or a log entry is added.

This command specifies the multicast FIB low watermark. When the percentage filling level of the Multicast FIB drops below the configured value, the corresponding trap is cleared and/or a log entry is added.

This command specifies the maximum number of (s,g) entries in the multicast forwarding database (MFIB) for this VPLS instance.

The mfib-table-size parameter specifies the maximum number of multicast database entries for both learned and static multicast addresses for the VPLS instance. When a table-size limit is set on the mfib of a service which is lower than the current number of dynamic entries present in the mfib then the number of entries remains above the limit.

The no form of this command removes the configured maximum MFIB table size.

This command specifies the aging time for remotely learned MAC addresses in the forwarding database (FDB) for the Virtual Private LAN Service (VPLS) instance. In a VPLS service, MAC addresses are associated with a Service Access Point (SAP) or with a Service Distribution Point (SDP). MACs associated with a SAP are classified as local MACs, and MACs associated with an SDP are remote MACs.

Like in a Layer 2 switch, learned MACs can be aged out if no packets are sourced from the MAC address for a period of time (the aging time). In each VPLS service instance, there are independent aging timers for local learned MAC and remote learned MAC entries in the FDB. The remote-age timer specifies the aging time for remote learned MAC addresses. To reduce the amount of signaling required between switches configure this timer larger than the local-age timer.

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

This command enables sending out “flush-all-from-ME” messages to all LDP peers included in affected VPLS, in the event of physical port failures or “oper-down” events of individual SAPs. This feature provides an LDP-based mechanism for recovering a physical link failure in a dual-homed connection to a VPLS service. This method provides an alternative to RSTP solutions where dual homing redundancy and recovery, in the case of link failure, is resolved by RSTP running between a PE router and CE devices. If the endpoint is configured within the VPLS and send-flush-on-failure is enabled, flush-all-from-me messages is sent out only when all spoke-SDPs associated with the endpoint go down.

This feature cannot be enabled on management VPLS.

This command configures the service payload (Maximum Transmission Unit – MTU), in bytes, for the service. This MTU value overrides the service-type default MTU. The service-mtu defines the payload capabilities of the service. It is used by the system to validate the SAP and SDP binding operational state within the service.

The service MTU and a SAP service delineation encapsulation overhead (i.e., 4 bytes for a dot1q tag) is used to derive the required MTU of the physical port or channel on which the SAP was created. If the required payload is larger than the port or channel MTU, then the SAP is placed in an inoperative state. If the required MTU is equal to or less than the port or channel MTU, the SAP is able to transition to the operative state.

In the event that a service MTU, port or channel MTU, or path MTU is dynamically or administratively modified, then all associated SAP and SDP binding operational states are automatically reevaluated.

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

Note: To disable service MTU check execute the command no service-mtu-check. Disabling service MTU check allows the packets to pass to the egress if the packet length is lesser than or equal to the MTU configured on the port.

Disabling service MTU check allows the packets to pass to the egress if the packet length is lesser than or equal to the MTU configured on the port. The length of the packet sent from a SAP is limited only by the access port MTU. In case of a pseudowire the length of a packet is limited by the network port MTU (including the MPLS encapsulation).

Note: If TLDP is used for signaling, the configured value for service-mtu is used during pseudowire setup.

The no form of this command disables the service MTU check.

This command configures an optional service name, up to 64 characters, which adds a name identifier to a specific service to then use that service name in configuration references as well as display and use service names in show commands throughout the system. This helps the service provider/administrator to identify and manage services within the 7210 SAS platforms.

All services are required to assign a service ID to initially create a service. However, either the service ID or the service name can be used o identify and reference a specific service when it is initially created.

This command creates a new split-horizon group (SHG) for the VPLS instance. Traffic arriving on a SAP or spoke-SDP within this SHG is not copied to other SAPs or spoke-SDPs in the same SHG.

The SHG must be created before SAPs and spoke-SDPs can be assigned to the group.

The SHG is defined within the context of a single VPLS. The same group name can be reused in different VPLS instances.

Note: The split-horizon-group command is only supported on 7210 SAS platforms operating in the network mode. Service-based SHGs are only supported on the 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE operating in the network mode. On these platforms, service-based SHGs and mesh-SDPs are mutually exclusive in a VPLS service. On the 7210 SAS-Mxp, an SHG can be used with spoke-SDPs or mesh SDPs configured in the service. Service-based SHGs are not supported in an R-VPLS service.

The no form of this command removes the group name from the configuration.

This command specifies whether this port is allowed to become an STP root port. It corresponds to the restrictedRole parameter in 802.1Q. If set, it can cause lack of spanning tree connectivity.

This command applies a time-based policy (filter or QoS policy) to the service SAP. The suite name must already exist in the config>cron context.

This command configures the VPLS ID component that is signaled in one of the extended community attributes (ext-comm).

Values and format (6 bytes, other 2 bytes of type-subtype are automatically generated).

This command enables the context to configure the Virtual Switch Instance Identifier (VSI-ID).

This command specifies the low-order 4 bytes used to compose the Virtual Switch Instance Identifier

(VSI-ID) to use for NLRI in BGP auto-discovery in this VPLS service.

If no value is set, the system IP address is used.

This command configures an optional service name, up to 64 characters, which adds a name identifier to a specific service to then use that service name in configuration references as well as display and use service names in show commands throughout the system. This helps the service provider/administrator to identify and manage services within the 7210 SAS platforms.

All services are required to assign a service ID to initially create a service. However, either the service ID or the service name can be used o identify and reference a specific service when it is initially created.

This command creates a logical IP routing interface for a VPLS service. When created, attributes such as IP address and service access points (SAP) can be associated with the IP interface.

The interface command, under the context of services, is used to create and maintain IP routing interfaces within the VPLS service IDs. The IP interface created is associated with the VPLS management routing instance.This instance does not support routing.

Interface names are case-sensitive and must be unique within the group of defined IP interfaces defined for the network core router instance. Interface names in the dotted decimal notation of an IP address are not allowed. For example, the name “1.1.1.1” is not allowed, but “int-1.1.1.1” is allowed. Show commands for router interfaces use either interface names or the IP addresses. Use unique IP address values and IP address names to maintain clarity. Duplicate interface names can exist in different router instances.

Enter a new name to create a logical router interface. When an existing interface name is entered, the user enters the router interface context for editing and configuration.

By default, no default IP interface names are defined within the system. All VPLS IP interfaces must be explicitly defined in an enabled state.

The no form of this command removes the IP interface and the entire associated configuration. The interface must be administratively shutdown before issuing the no interface command.

For VPLS services, the IP interface must be shutdown before the SAP on that interface is removed.

For VPLS service, ping and traceroute are the only applications supported.

This command assigns an IP address and an IP subnet, to a VPLS IP router interface. Only one IP address can be associated with an IP interface. An IP address must be assigned to each VPLS IP interface. An IP address and a mask are used together to create a local IP prefix. The defined IP prefix must be unique within the context of the routing instance. It cannot overlap with other existing IP prefixes defined as local subnets on other IP interfaces in the same routing context within the 7210 SAS.

The IP address for the interface can be entered in either Classless Inter-Domain Routing (CIDR) or traditional dotted decimal notation. The show commands display CIDR notation and is stored in configuration files.

By default, no IP address or subnet association exists on an IP interface until it is explicitly created. Use the no form of this command to remove the IP address assignment from the IP interface. When the no address command is entered, the interface becomes operationally down.

The operational state is a read-only variable and the only controlling variables are the address and admin states. The address and admin states are independent and can be set independently. If an interface is in an adminstratively up state and an address is assigned, it becomes operationally up.

This command configures the minimum time in seconds an ARP entry learned on the IP interface is stored in the ARP table. ARP entries are automatically refreshed when an ARP request or gratuitous ARP is seen from an IP host, otherwise, the ARP entry is aged from the ARP table. If arp-timeout is set to a value of zero seconds, ARP aging is disabled.

The default value for arp-timeout is 14400 seconds (4 hours).

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

This command assigns a specific MAC address to a VPLS IP interface.

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

This command configures a static address resolution protocol (ARP) entry associating a subscriber IP address with a MAC address for the core router instance. A static ARP can only be configured if it exists on the network attached to the IP interface.

If an entry for a particular IP address already exists and a new MAC address is configured for the IP address, the existing MAC address is replaced with the new MAC address.

The no form of this command removes a static ARP entry.

This command enables the context to configure the Spanning Tree Protocol (STP) parameters.

The Nokia STP has a few modifications to better suit the operational characteristics of VPLS services. The most evident change is to the root bridge election. Since the core network operating between the Nokia service routers should not be blocked, the root path is calculated from the core perspective.

This command configures automatic detection of the edge port characteristics of the SAP or spoke-SDP.

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

Note: The config>service>vpls>spoke-sdp>stp context is not supported on platforms configured in the access-uplink operating mode.

This command configures the SAP or SDP as an edge or non-edge port. If auto-edge is enabled for the SAP, this value is used only as the initial value.

RSTP, however, can detect that the actual situation is different from what edge-port may indicate.

Initially, the value of the SAP or spoke-SDP parameter is set to edge-port. This value changes if:

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

Note: The config>service>vpls>spoke-sdp>stp context is not supported on platforms configured in the access-uplink operating mode.

RSTP, as defined in the IEEE 802.1D-2004 standards, transition to the forwarding state via a handshaking mechanism (rapid transition), without any waiting times. If handshaking fails (e.g. on shared links), the system falls back to the timer-based mechanism defined in the original STP (802.1D-1998) standard.

A shared link is a link with more than two nodes (for example, a shared 10/100BaseT segment). The port-type command is used to configure a link as point-to-point or shared.

For timer-based transitions, the 802.1D-2004 standard defines an internal variable forward-delay, which is used in calculating the default number of seconds that a SAP spends in the discarding and learning states when transitioning to the forwarding state.

The value of the forward-delay variable depends on the STP operating mode of the VPLS instance:

Note: The config>service>vpls>spoke-sdp>stp context is not supported on platforms configured in the access-uplink operating mode.

This command configures the STP hello time for the Virtual Private LAN Service (VPLS) STP instance.

The hello time parameter defines the default timer value that controls the sending interval between BPDU configuration messages by this bridge, on ports where this bridge assumes the designated role.

The active hello time for the spanning tree is determined by the root bridge (except when the STP is running in RSTP mode, then the hello time is always taken from the locally configured parameter).

The configured hello-time can also be used to calculate the forward delay. See auto-edge.

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

This command configures the peak number of BPDUs that can be transmitted in a period of one second.

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

This command instructs STP on the maximum number of bridges behind this SAP. If there is only a single bridge, transitioning to forwarding state is based on handshaking (fast transitions). If more than two bridges are connected via a shared media, their SAP should all be configured as shared, and timer-based transitions are used.

The no form of this command reverts the default value.

This command enables the context to configure MSTI related parameters at SAP level. This context can be open only for existing mst-instances defined at the service level.

This commands specifies path-cost within a specific instance. If a loop occurs, this parameter indicates the probability of a specific port being assigned a forwarding state. (The highest value expresses lowest priority).

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

This commands specifies the port priority within a specific instance. If a loop occurs, this parameter indicates the probability of a specific port being assigned a forwarding state.

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

This command indicates how many hops a BPDU can traverse the network starting from the root bridge. The message age field in a BPDU transmitted by the root bridge is initialized to 0. Each other bridge takes the message_age value from BPDUs received on their root port and increment this value by 1. The message_age therefore reflects the distance from the root bridge. BPDUs with a message age exceeding max-age are ignored.

STP uses the max-age value configured in the root bridge. This value is propagated to the other bridges via the BPDUs.

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

This command specifies the version of STP the bridge is currently running.

See Spanning Tree Operating Modes for more information about these modes.

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

This command enables the context to configure Multiple Spanning Tree Instance (MSTI) related parameters. MSTP supports 16 instances. The instance 0 is mandatory (by protocol) and cannot be created by the CLI. The software automatically maintains this instance.

This command specifies the bridge priority for this specific Multiple Spanning Tree Instance for this service. The bridge-priority value reflects likelihood that the switch is chosen as the regional root switch (65535 represents the least likely). It is used as the highest 4 bits of the Bridge ID included in the MSTP BPDU's generated by this bridge.

The values of the priority are only multiples of 4096 (4k). If a value is specified that is not a multiple of 4K, the value is replaced by the closest multiple of 4K (lower than the value entered).

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

This command specifies a range of VLANs associated with a certain MST-instance. This range applies to all SAPs of the mVPLS.

Every VLAN range that is not assigned within any of the created mst-instance is automatically assigned to mst-instance 0. This instance is automatically maintained by the software and cannot be modified. Changing the VLAN range value can be performed only when the specific mst-instance is shutdown.

The no form of this command removes the vlan-range from a specific mst-instance.

This command specifies the number of hops in the region before BPDU is discarded and the information held for the port is aged out. The root bridge of the instance sends a BPDU (or M-record) with remaining-hop-count set to configured max-hops. When a bridge receives the BPDU (or M-record), it decrements the received remaining-hop-count by 1 and propagates it in BPDU (or M-record) it generates.

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

This command defines an MST region name. Two bridges are considered part of the same MST region when their configuration of the MST region name, the MST-revision and VLAN-to-instance assignment, is identical.

The no form of this command removes region-name from the configuration.

This command defines the MST configuration revision number. Two bridges are considered as a part of the same MST region if their configured MST-region name, MST-revision, and VLAN-to-instance are identical.

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

This command configures the STP path cost for the SAP or spoke-SDP.

The path cost is used by STP to calculate the path cost to the root bridge. The path cost in BPDUs received on the root port is incremented with the configured path cost for that SAP. When BPDUs are sent out other egress SAPs or spoke-SDPs, the newly calculated root path cost is used.

STP suggests that the path cost is defined as a function of the link bandwidth. Since SAPs are controlled by complex queuing dynamics, in the 7210 SAS the STP path cost is a purely static configuration.

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

This command configures the virtual port number which uniquely identifies a SAP within configuration bridge protocol data units (BPDUs). The internal representation of a SAP is unique to a system and has a reference space much bigger than the 12 bits definable in a configuration BPDU. STP takes the internal representation value of a SAP and identifies it with it’s own virtual port number that is unique to every other SAP defined on the TLS. The virtual port number is assigned at the time that the SAP is added to the TLS. Since the order that the SAP was added to the TLS is not preserved between reboots of the system, the virtual port number may change between restarts of the STP instance.

The virtual port number cannot be administratively modified.

The bridge-priority command is used to populate the priority portion of the bridge ID field within outbound BPDUs (the most significant 4 bits of the bridge ID). It is also used as part of the decision process when determining the best BPDU between messages received and sent. All values are truncated to multiples of 4096, conforming with IEEE 802.1t and 802.1D-2004.

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

This command configures the Nokia STP priority for the SAP or spoke-SDP.

STP priority is a configurable parameter associated with a SAP or spoke-SDP. When configuration BPDUs are received, the priority is used in some circumstances as a tie breaking mechanism to determine whether the SAP or spoke-SDP is designated or blocked.

In traditional STP implementations (802.1D-1998), this field is called the port priority and has a value of 0 to 255. This field is coupled with the port number (0 to 255 also) to create a 16 bit value. In the latest STP standard (802.1D-2004) only the upper 4 bits of the port priority field are used to encode the SAP or spoke-SDP priority. The remaining 4 bits are used to extend the port ID field into a 12 bit virtual port number field. The virtual port number uniquely references a SAP within the STP instance.

STP computes the actual priority by taking the input value and masking out the lower four bits.The result is the value that is stored in the priority parameter. For instance, if a value of 0 is entered, masking out the lower 4 bits results in a parameter value of 0. If a value of 255 is entered, the result is 240.

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

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters which identifies the service access point on the interface and within the 7210 SAS. Each SAP must be unique.

A physical port can have only one SAP to be part of one service. Multiple SAPS can be defined over a physical port but each of these SAPs should belong to a different service.

All SAPs must be explicitly created. If no SAPs are created within a service or on an IP interface, a SAP does not exist on that object.

Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned by the service in which it was created.

A SAP can only be associated with a single service. A SAP can only be defined on a port that has been configured as an access port using the config interface port-type port-id mode access command.

If a port is shutdown, all SAPs on that port become operationally down. When a service is shutdown, SAPs for the service are not displayed as operationally down although all traffic traversing the service is discarded. The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP is also deleted.

This command is also used to create a Ring APS Control SAP or a Data SAP whose traffic is protected by a Ring APS Instance.

When this command is enabled, packets received on a SAP or a spoke-SDP with an unknown source MAC address is dropped only if the maximum number of MAC addresses for that SAP or spoke-SDP (see max-nbr-mac-addr) has been reached. If max-nbr-mac-addr has not been set for the SAP or spoke-SDP, enabling discard-unknown-source has no effect.

When disabled, the packets are forwarded based on the destination MAC addresses.

The no form of this command causes packets with an unknown source MAC address to be forwarded by destination MAC addresses in VPLS.

This command enables the context to configure DHCP snooping parameters.

This command configures the Relay Agent Information Option (Option 82) processing.

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

When enabled, the router sends an ASCII-encoded tuple in the circuit-id sub-option of the DHCP packet. This ASCII-tuple consists of the access-node-identifier, service-id, and SAPID, separated by “|”. If no keyword is configured, then the circuit-id sub-option is not part of the information option (Option 82).

When the command is configured without any parameters, it equals to circuit-id ascii-tuple.

If disabled, the circuit-id sub-option of the DHCP packet is left empty.

Note: By default, circuit-id is enabled if any of the other options, such as remote-id or vso, are configured.

This command enables DHCP Option 82 (Relay Agent Information Option) parameters processing and enters the context for configuring Option 82 sub-options.

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

When enabled, the router sends the MAC address of the remote end (typically the DHCP client) in the remote-id sub-option of the DHCP packet. This command identifies the host at the other end of the circuit.

If disabled, the remote-id sub-option of the DHCP packet is left empty.

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

This command configures the vendor specific sub-option of the DHCP relay packet.

This command enables sending the MAC address in the vendor specific sub-option of the DHCP relay packet.

The no form of this command disables the sending of the MAC address in the vendor specific sub-option of the DHCP relay packet.

This command enables sending the SAP ID in the vendor specific suboption of the DHCP relay packet.

The no form of this command disables the sending of the SAP ID in the vendor specific suboption of the DHCP relay packet.

This command enables sending the service ID in the vendor specific suboption of the DHCP relay packet.

The no form of this command disables the sending of the service ID in the vendor specific suboption of the DHCP relay packet.

This command specifies the string in the vendor specific suboption of the DHCP relay packet.

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

This command specifies whether the system-id is encoded in the vendor specific sub-option of Option 82.

This command enables the relaying of plain BOOTP packets.

The no form of this command disables the relaying of plain BOOTP packets.

This command specifies a list of servers where requests are forwarded. The list of servers can be entered as either IP addresses or fully qualified domain names. There must be at least one server specified for DHCP relay to work. If there are multiple servers then the request is forwarded to all of the servers in the list.

There can be a maximum of eight DHCP servers configured.

This command enables relaying of untrusted packets.

The no form of this command disables the relay.

This command enables DHCP snooping of DHCP messages on the SAP. Enabling DHCP snooping on VPLS interfaces (SAPs) is required where DHCP messages where Option 82 information is to be inserted. This includes interfaces that are in the path to receive messages from either DHCP servers or from subscribers.

The no form of this command disables DHCP snooping on the specified VPLS SAP.

This command enables the context to configure ETH-CFM parameters.

This command configures the ETH-CFM maintenance endpoint (MEP).

This command enables the generation and reception of AIS messages.

This command configures the client maintenance entity group (MEG) levels to use for AIS message generation. Up to 7 levels can be provisioned with the restriction that the client MEG level must be higher than the local MEG level.

This command specifies the transmission interval of AIS messages in seconds.

This command specifies the priority of AIS messages originated by the node.

This command enables the generation of CCM messages.

The no form of this command disables the generation of CCM messages.

This command specifies the priority value for CCMs and LTMs transmitted by the MEP.

The no form of this command removes the priority value from the configuration.

For ETH-test to work, operators need to configure ETH-test parameters on both sender and receiver nodes. The ETH-test then can be done using the following OAM commands:

oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]

A check is done for both the provisioning and test to ensure that the MEP is an Y.1731 MEP (MEP provisioned with domain format none, association format icc-based). If not, the operation fails. An error message in the CLI and SNMP indicates the problem.

This command configures the test pattern for eth-test frames.

The no form of this command removes the values from the configuration.

This command specifies the lowest priority defect that is allowed to generate a fault alarm.

This command specifies the MAC address of the MEP.

The no form of this command reverts the MAC address of the MEP back to that of the port (if the MEP is on a SAP) or the bridge (if the MEP is on a spoke).

This command enables/disables eth-test functionality on MEP.

This command indicates whether the mac-move agent, when enabled using the config service vpls mac-move or config service epipe mac-move command, limits the MAC relearn (move) rate on this SAP.

This command disables relearning of MAC addresses on other mesh SDPs within the VPLS.

The MAC address remains attached to a specific Mesh for duration of its age-timer.

The age of the MAC address entry in the FIB is set by the age timer. If mac-aging is disabled on a specific VPLS service, any MAC address learned on a mesh with mac-pinning enabled remains in the FIB on this mesh forever. Every event that otherwise results in relearning is logged (MAC address; original - mesh SDP; new - mesh SDP).

This command specifies the maximum number of FDB entries for both learned and static MAC addresses for this SAP, spoke-SDP or endpoint.

When the configured limit has been reached, and discard-unknown-source has been enabled for this SAP or spoke-SDP (see discard-unknown-source), packets with unknown source MAC addresses are discarded.

The no form of this command restores the global MAC learning limitations for the SAP or spoke-SDP.

This command creates a local static MAC entry in the Virtual Private LAN Service (VPLS) forwarding database (FDB) associated with the Service Access Point (SAP).

In a VPLS service, MAC addresses are associated with a Service Access Point (SAP) or with a Service Distribution Point (SDP). MACs associated with a SAP are classified as local MACs, and MACs associated with an SDP are remote MACs.

Local static MAC entries create a permanent MAC address to SAP association in the forwarding database for the VPLS instance so that MAC addresses are not learned on the edge device.

Note that static MAC definitions on one edge device are not propagated to other edge devices participating in the VPLS instance, that is, each edge device has an independent forwarding database for the VPLS.

Only one static MAC entry (local or remote) can be defined per MAC address per VPLS instance.

By default, no static MAC address entries are defined for the SAP.

The no form of this command deletes the static MAC entry with the specified MAC address associated with the SAP from the VPLS forwarding database.

This command enables the context to configure VLAN ranges to be managed by a management VPLS. The list indicates, for each SAP, the ranges of associated VLANs that are affected when the SAP changes state.

This command is only valid when the VPLS in which it is entered was created as a management VPLS.

This command adds a default SAP to the managed VLAN list.

The no form of this command removes the default SAP to the managed VLAN list.

This command configures a range of VLANs on an access port that are to be managed by an existing management VPLS.

This command is only valid when the VPLS in which it is entered was created as a management VPLS, and when the SAP in which it was entered was created on an Ethernet port with encapsulation type of dot1q.

To modify the range of VLANs, first the new range should be entered and afterwards the old range removed. See Modifying VPLS Service Parameters.

This command enables the context to configure the counters associated with SAP ingress and egress.

This command enables the context to configure the ingress SAP statistics counters.

This command allows the user to set the counter mode for the counters associated with SAP ingress meters (also known as policers). A pair of counters is available with each meter. These counters count different events based on the counter mode value.

Note: The counter mode can be changed if an accounting policy is associated with a SAP. If the counter mode is changed, the counters associated with the meter are reset and the counts are cleared. If an accounting policy is in use when the counter-mode is changed, a new record is written into the current accounting file.

Perform the following steps on the specified SAP to ensure that the correct statistics are collected when the counter-mode is changed.

This command associates a counter which enables the counting of extra VLAN-tag dropped packets for the SAP, spoke-SDP, or mesh SDP. A limited amount of such counters are available for use.

The no form of this command removes the associated counter.

This command enables the context to configure egress filter policies.

If no egress filter is defined, no filtering is performed.

This command enables the context to configure ingress SAP QoS policies and filter policies.

If no SAP-ingress QoS policy is defined, the system default SAP-ingress QoS policy is used for ingress processing. If no ingress filter is defined, no filtering is performed.

This command defines a maximum total rate for all egress queues on a service SAP.

The port scheduler mode should be set to “sap-based” scheduling mode before using this command. The egress port scheduler enforces the aggregate queue rate for the SAP as it distributes its bandwidth to all the SAPs configured on the port. The port scheduler stops distributing bandwidth to member queues when it has detected that the aggregate rate limit has been reached.

A SAP aggregate scheduler is created for each instance of the SAP queues created on each of the member ports of the LAG. For a LAG, the port scheduler-mode configured for the primary port is used for all the member ports of the LAG.

The scheduler mode is specified by the scheduler-mode command. To implement the aggregate rate limit, the scheduler mode must be specified as “sap-based”. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide for more information about the scheduler-mode command.

The no form of this command removes the aggregate rate limit from the SAP or multi-service site.

This command associates an IP filter policy or MAC filter policy with an ingress or egress SAP or IP interface.

Filter policies control the forwarding and dropping of packets based on IP or MAC matching criteria. There are two types of filter policies: IP and MAC. Only one type may be applied to a SAP at a time.

The filter command is used to associate a filter policy with a specified filter ID with an ingress or egress SAP. The filter ID must already be defined before the filter command is executed. If the filter policy does not exist, the operation fails and an error message returned.

In general, filters applied to SAPs (ingress or egress) apply to all packets on the SAP. One exception is non-IP packets are not applied to IP match criteria, so the default action in the filter policy applies to these packets.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID is not removed from the system.

This command associates a Quality of Service (QoS) policy with an ingress or egress Service Access Point (SAP).

QoS ingress policies are important for the enforcement of SLA agreements. The policy ID must be defined before associating the policy with a SAP. If the policy-id does not exist, an error is returned.

The qos command is used to associate both ingress and egress QoS policies. The qos command only allows ingress policies to be associated on SAP or IP interface ingress, and only allows egress policies on SAP or IP interface egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress and one egress QoS policy can be associated with a SAP at one time. Attempts to associate a second policy of same or different type replaces the earlier one with the new policy.

Note: SAP egress QoS policies are only supported on the 7210 SAS-Mxp.

On the 7210 SAS-Mxp (ingress), using the enable-table-classification keyword enables the use of IP DSCP tables to assign FC and profile on a per-SAP ingress basis. The match-criteria configured in the service ingress policy, which require CAM resources, are ignored. Only meters from the service ingress policy are used (and the meters still require CAM resources). The IP DSCP classification policy configured in the SAP ingress policy is used to assign FC and profile. The default FC is assigned from the SAP ingress policy.

By default, if no specific QoS policy is associated with the SAP for ingress or egress, the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

This command creates the accounting policy context that can be applied to a SAP.

An accounting policy must be defined before it can be associated with a SAP. If the policy-id does not exist, an error message is generated.

A maximum of one accounting policy can be associated with a SAP at one time. Accounting policies are configured in the config>log context.

The no form of this command removes the accounting policy association from the SAP, and the accounting policy reverts to the default.

This command enables accounting and statistical data collection for either the SAP, network port, or IP interface. When applying accounting policies the data, by default, is collected in the appropriate records and written to the designated billing file.

When the no collect-stats command is issued the statistics are still accumulated by the cards. However, the CPU does not obtain the results and write them to the billing file. If a subsequent collect-stats command is issued then the counters written to the billing file include all the traffic while the no collect-stats command was in effect.

This command binds a VPLS service to an existing Service Distribution Point (SDP). Mesh SDPs bound to a service are logically treated like a single bridge “port” for flooded traffic where flooded traffic received on any mesh SDP on the service is replicated to other “ports” (spoke-SDPs and SAPs) and not transmitted on any mesh SDPs.

Note that this command creates a binding between a service and an SDP. The SDP has an operational state which determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service is down.

The SDP must already be defined in the config>service>sdp context to associate the SDP with a valid service. If the sdp sdp-id is not already configured, an error message is generated. If the sdp-id does exist, a binding between that sdp-id and the service is created.

SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a service, no far-end devices can participate in the service.

The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. When removed, no packets are forwarded to the far-end router.

This command binds a service to an existing Service Distribution Point (SDP). A spoke-SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke-SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port on which it was received.

The SDP has an operational state that determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service is down.

The SDP must already exist in the config>service>sdp context before it can be associated with a VPLS service. If the sdp-id is not already configured, an error message is generated. If the sdp-id exists, a binding between the specific sdp-id and service is created.

SDPs must be explicitly associated and bound to a service to allow far-end devices to participate in the service.

The no form of this command removes the SDP binding from the service; the SDP configuration is not affected. When the SDP binding is removed, no packets are forwarded to the far-end router.

This command enables the context to configure egress SDP.

This command enables the context to configure ingress SDP.

This command forces vc-vlan-type forwarding in the data path for spoke/mesh SDPs which have either vc-type. This command is not allowed on vlan-vc-type SDPs.

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

This command enables the use of hash label on a VLL or VPLS service bound to LDP or RSVP SDP, using the autobind mode with the ldp, rsvp-te, or mpls options. When the hash-label command is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use, as the value of the label field of the hash label. Only the hash-2 parameters are used to compute hash-label, even if sdp is over a lag (with load-balancing set as hash-1 or hash-2) or a port. The egress data path adds the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).

Note: On 7210 SAS, the hash label is not used on the local node for purpose of ECMP hashing and LAG hashing. It is available for use by LSR nodes, through which the traffic flows and are capable of using the labels for hashing.

Packets generated in CPM and that are forwarded labeled within the context of a service (for example, OAM packets) must also include a Hash Label at the BoS and set the S-bit accordingly.

The TTL of the hash label is set to a value of 0.

The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS spoke-sdp or mesh-sdp interface by adding the signal-capability option. In this case, the decision whether to insert the hash label on the user and control plane packets by the local PE is solely determined by the outcome of the signaling process and can override the local PE configuration. The following procedures apply when the hash-label option and the signal-capability option are enabled on the local PE:

The user can enable or disable the signal-capability option in CLI as needed. When doing so, the router must withdraw the label it sent to its peer and send a new label mapping message with the new value of the F bit in the flow label interface parameters sub-TLV of the PW ID FEC element.

Note: This feature is supported only for VLL and VPLS services. It not supported for VPRN services. It is also not supported on multicast packets forwarded using RSVP P2MP LPS or mLDP LSP in both the base router instance and in the multicast VPN (mVPN) instance. In 7x50 and possibly other vendor implementations, to allow applications where the egress LER infers the presence of the hash label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the Hash Label. This means that the value of the hash label is always in the range [524,288 - 1,048,575] and does not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label does not match a value in the reserved label range. This is not supported on 7210 for service traffic (for MPLS OAM traffic the MSB bit is set). That is, 7210 SAS devices do not set the MSB bit in the hash label value for service traffic. Therefore, user must ensure that both the ends are correctly configured to either process hash labels or disable it.

The no form of this command disables the use of the hash label.

This command configures the egress VC label.

This command configures the ingress VC label.

This command specifies an explicit Dot1q value used when encapsulating to the SDP far end. When signaling is enabled between the near and far end, the configured Dot1q tag can be overridden by a received TLV specifying the Dot1q value expected by the far end. This signaled value must be stored as the remote signaled Dot1q value for the binding.

The provisioned local Dot1q tag must be stored as the administrative Dot1q value for the binding.

When the Dot1q tag is not defined, the default value of zero is stored as the administrative dot1q value. Setting the value to zero is equivalent to not specifying the value.

The no form of this command disables the command.

This command enables the context to configure Internet Group Management Protocol (IGMP) snooping.

This command enables the IGMP router alert check option.

Note: The disable-router-alert-check command is not supported in a VPLS on 7210 SAS platforms operating in network mode.

The no form of this command disables the router alert check.

This command creates a text description stored in the configuration file for a configuration context. The description command associates a text string with a configuration context to help identify the content in the configuration file.

The no form of this command removes the string from the configuration.

This command enables fast leave. When IGMP fast leave processing is enabled, the 7210 SAS immediately removes a SAP or SDP from the multicast group when it detects an IGMP “leave” on that SAP or SDP. Fast leave processing allows the switch to remove a SAP or SDP that sends a 'leave' from the forwarding table without first sending out group-specific queries to the SAP or SDP, and therefore speeds up the process of changing channels ('zapping').

Fast leave should only be enabled when there is a single receiver present on the SAP or SDP. When fast leave is enabled, the configured last-member-query-interval value is ignored.

This command configures the VPLS and R-VPLS service from which multicast traffic is copied upon receipt of an IGMP join request. IGMP snooping must be enabled on the MVR VPLS and MVR R-VPLS service.

This command adds a static multicast group as a (*, g). When a static IGMP group is added, multicast data for that (*,g) is forwarded to the specific SAP or SDP without receiving any membership report from a host.

Note: Only SAPs are supported in an R-VPLS. SDPs are not supported in an R-VPLS.

This command identifies a filter policy of multicast groups to be applied to this VPLS entity. The sources of the multicast traffic must be a member of the VPLS.

The no form of this command removes the policy association from the VPLS configuration.

This command specifies the import routing policy to be used for IGMP packets to be used on this SAP or SDP. Only a single policy can be imported on a single SAP or SDP at any time.

The no form of this command removes the policy association from the SAP or SDP.

This command configures the maximum response time used in group-specific queries sent in response to ‘leave’ messages, and is also the amount of time between 2 consecutive group-specific queries. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group. The configured last-member-query-interval is ignored when fast-leave is enabled on the SAP or SDP.

This command defines the maximum number of multicast groups that can be joined on this SAP or SDP. If the node receives an IGMP join message that would exceed the configured number of groups, the request is ignored.

This command defines the maximum number of multicast sources allowed per group that can be joined on this SAP. If the node receives an IGMP join message that would exceed the configured number of sources, the request is ignored.

Note: The max-num-sources command is applicable only in the context of R-VPLS service. It cannot be used in the context of VPLS service.