4.7. VPLS Services Command Reference

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.

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

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 the context to configure DHCP parameters.

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

The no form of this command reverts the system 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, the circuit-id sub-option is not part of the information option (Option 82).

When this command is configured without parameters, it is the equivalent of circuit-id ascii-tuple.

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

By default, if any of the other options are configured (for example, remote-id or vso), circuit-id is enabled.

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

The no form of this command reverts the system 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 the sending of the MAC address in the vendor-specific suboption of the DHCP relay packet.

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

This command enables the sending of 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 the sending of 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 suboption 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 will be 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, the request is forwarded to all the servers in the list.

A maximum of 8 DHCP servers can be configured.

This command enables relaying of untrusted packets.

The no form of this command disables the relay.

This command configures DHCP snooping of DHCP messages on the SAP. Enabling DHCP snooping on VPLS interfaces (SAPs) is required where vendor-specific information (as per RFC 4243) is to be inserted into the Option 82 field of the DHCP messages. 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.

Note: DHCP snooping for SDP is not supported on the platforms as described in this document.

This command creates or edits a 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 as 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 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 BGP-related parameters to BGP AD.

This command enables blocking (brings the entity to an operationally down state) after all configured mesh-SDPs are in operationally down state. This event is signaled to corresponding T-LDP peers by withdrawing the service label (status-bit-signaling non-capable peer) or by setting the “PW not forwarding” status bit in the 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 will have a specified format.

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

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

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

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 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 is ignored.

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

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

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

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

This command 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 this command is enabled at the VPLS level, packets with unknown destination MAC address are dropped instead (even when the 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 enables the context to link the MEP with the primary VLAN configured under the bridge-identifier for the MA. MEPs can not be changed from or to primary VLAN functions. This must be configured as part of the creation step and can be changed only by deleting the MEP and recreating it.

This command is used to enable both the ingress and egress MIP functionality for a VPLS SAP.

Before enabling both Ingress and egress MIP functionality, the user must allocate sufficient resources in the egress-internal-tcam resource pool using the configure system resource-profile egress-internal-tcam eth-cfm bidir-mip-egress command. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information.

The following describes the behavior for this command:

This command configures a service endpoint.

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

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

When this command is enabled, the node ignores 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 the endpoint level and at the 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 will become part of the explicit-endpoint only if the setting is not conflicting. The newly created spoke-SDP, which is 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 only 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 case where 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 creates a new split horizon group (SHG) for the VPLS instance. Traffic arriving on a SAP or spoke-SDP within this SHG will not be copied to other SAPs or spoke SDPs in the same SHG.

An 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 instance. The same group name can be reused in different VPLS instances.

Note: On the 7210 SAS-R6 with IMM (v1 cards) and IMM-c cards, service-based SHGs and mesh-SDPs are mutually exclusive in a VPLS service. On the 7210 SAS-R6 and 7210 SAS-R12 with IMM-b cards, 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 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) will not be sent to T-LDP peer when the specific spoke is selected as a standby. This allows faster switchover as the traffic will be sent over this SDP and discarded at the blocking side of the connection. This is particularly applicable to multicast traffic.

This command specifies the upper threshold value for FDB entries. The high-water-mark is configured as a percentage of the FDB. When the number of FDB entries exceeds the high-water-mark, the system raises a log event.

This command specifies the lower threshold value for FDB entries. The low-water-mark is configured as a percentage of the FDB. When the number of FDB entries drops below the low-water-mark, the system raises a log event.

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

The fdb-table-size specifies the maximum number of FDB 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 will be 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 extended community can have the same formats as the VPLS ID: a two-octet AS-specific extended community, or an IPv4-specific extended community.

The following rules apply.

This command binds the advertisements received with the RT that match 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 will be 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:

The values and format consist of 6 bytes, where the other 2 bytes of type is automatically generated.

This command specifies the aging time for locally learned MAC addresses in the FDB for the 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 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). 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 command is an alternative way to protect your network against loops.

When enabled in a VPLS, the mac-move command 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. A SAP can be marked as non-blockable using the config>service>vpls>sap>limit-mac-move context. This means that when the relearn rate has exceeded the limit, another (blockable) SAP will be disabled instead.

The mac-move command enables the feature at the service level for SAPs; 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 will be 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) the mac-move command disables one of the VPLS ports when 5 relearns were detected during the 5-second interval, because the average move-frequency of 1 relearn per second has been reached. This can occur in the first second if the real relearn rate is 5 relearns per second or higher.

The no form of this command disables the mac-move command.

This command indicates 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 configures the time in seconds to wait before a SAP that has been disabled after exceeding the maximum relearn rate is re-enabled.

Nokia recommends that the retry-timeout value be 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 will not be 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 (MFIB) high watermark. When the percentage filling level of the MFIB exceeds the configured value, a trap is generated and a log entry is added.

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

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

The 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 that is lower than the current number of dynamic entries present in the MFIB, 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 FDB for the VPLS instance. In a VPLS service, MAC addresses are associated with a SAP or an SDP. MACs associated with a SAP are called local MACs, and MACs associated with an SDP are called 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 with a value 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 the affected VPLS, in the event of physical port failures or “oper-down” events of individual SAPs.

This command 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 the send-flush-on-failure command is enabled, flush-all-from-me messages are 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 command defines the payload capabilities of the service and 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 (that is, 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, 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, all associated SAP and SDP binding operational states are automatically reevaluated.

The no form of this command reverts the service-mtu value for the indicated service type to the default.

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

This command, when disabled, allows the packets to pass to the egress if the packet length is less 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).

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

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

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 enables the context to configure the Virtual Switch Instance Identifier (VSI-ID).

This command specifies the low-order 4 bytes used to compose the VSI-ID to use for NLRI in BGP auto-discovery in the specified VPLS service.

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

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

The Nokia STP is the Spanning Tree Protocol (STP) with a few modifications to better suit the operational characteristics of VPLS services. The most evident change is to the root bridge election. Because the core network operating between the 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.

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

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

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

Initially, the value of the SAP parameter is set to edge-port. This value changes in the following circumstances:

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

RSTP, as defined in the IEEE 802.1D-2004 standards, transitions to the forwarding state via a handshaking mechanism (rapid transition), without wait times. If handshaking fails (for example, on shared links (see the following)), 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 parameter depends on the STP operating mode of the VPLS instance, as outlined in the following:

This command configures the STP hello time for the 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; in this case, 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 the auto-edge command for more information.

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 configures the maximum number of bridges for STP 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 SAPs should all be configured as shared, and timer-based transitions are used.

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

This command enables the context to configure Multiple Spanning Tree Instance (MSTI) related parameters at the SAP level. This context can be open only for existing MSTIs 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 the lowest priority.

By default, the path-cost is proportional to the link speed.

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

This command 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 configures 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 will take 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 the max-age value 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 that the bridge is currently running.

See Spanning Tree Operating Modes for information about these modes.

The no form of this command reverts to the default.

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 will be 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 BPDUs 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).

All instances that are created by the vlan-range command do not have an explicit definition of bridge-priority and inherit the default value.

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

This command specifies a range of VLANs associated with a particular MSTI. 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 shut down.

The no form of this command removes the vlan-range from the 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 the BPDU (or M-record) it generates.

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

This command defines an MST region name. Two bridges are considered as a part of the same MST region as soon as 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.

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, the newly calculated root path cost is used.

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

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

This command configures the virtual port number, which uniquely identifies a SAP within configuration 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 using a virtual port number that is unique from every other SAP defined on the TLS. The virtual port number is assigned at the time that the SAP is added to the TLS. Because 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.

This 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 the bridge priority to the default value.

This command configures the STP priority for the 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 will be 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 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 example, 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 the STP priority to the default value.

This command creates a SAP within a service. A SAP is a combination of port and encapsulation parameters that identifies the SAP 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 shut down, all SAPs on that port become operationally down. When a service is shut down, SAPs for the service are not displayed as operationally down, although all traffic traversing the service will be 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 are also deleted.

This command configures 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 value.

When this command is enabled, packets received on a SAP or with an unknown source MAC address will be dropped only if the maximum number of MAC addresses for that SAP (see the max-nbr-mac-addr command) has been reached. If the max-nbr-mac-addr command has not been configured for the SAP, enabling the discard-unknown-source command 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 addresses to be forwarded by destination MAC addresses in VPLS.

This command assigns a valid existing Distributed CPU Protection (DCP) policy to a SAP. By default, no DCP policy is associated with the SAP.

The no form of this command disables the use of DCP policies for the SAP.

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 configures 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 command 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 will be written into the current accounting file.

Execute the following sequence of commands on the specified SAP to ensure the correct statistics are collected when the counter-mode is changed:

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

The no form of this command removes the associated counter.

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

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

The primary-vlan-enable parameter provides a method for linking the MEP with the primary VLAN configured under the bridge-identifier for the MA. MEPs can not be changed from or to primary vlan functions. This must be configured as part of the creation step and can only be changed by deleting the MEP and recreating it. Primary VLANs are only supported under Ethernet SAPs.

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, configure ETH-test parameters on both sender and receiver nodes. The ETH-test can be performed using the following OAM command:

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 performed for both the provisioning and test to ensure the MEP is a 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 configures the fault propagation for the MEP.

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 or disables eth-test functionality on MEP.

This command allows Maintenance Intermediate Points (MIPs) to be created if mhf-creation for the MA is configured using the default option.

The primary-vlan-enable parameter provides a method for linking the MEP with the primary VLAN configured under the bridge-identifier for the MA. MEPs can not be changed from or to primary vlan functions. This must be configured as part of the creation step and can only be changed by deleting the MEP and recreating it. Primary VLANs are only supported under Ethernet SAPs.

This command specifies 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, a 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.

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

The no form of this command restores the global MAC learning limitations for the SAP.

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

This command configures 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.

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 will be written into the current accounting file.

Execute the following sequence of commands to ensure a new accounting file is generated when the counter-mode is changed:

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

This command configures a local static MAC entry in the VPLS FDB associated with the SAP.

In a VPLS service, MAC addresses are associated with a SAP or with an 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 the MAC address will not be learned on the edge device.

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

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

This command is valid only 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 from 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 valid only 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 then the old range removed. See Modifying VPLS Service Parameters for more information.

This command enables the context to configure egress filter policies.

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

This command configures 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 using 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 a set of two counters to count total forwarded packets and octets and total dropped packets and octets. When the counter is enabled, the amount of resources required increases by twice the amount of resources taken up when counter is not used. If the enable-stats keyword is specified during the creation of the meter, the counter is allocated by the software, if available. To free up the counter and relinquish its use, use the no aggregate-meter-rate command, and then recreate the meter using the aggregate-meter rate command.

If egress frame-based accounting is used, the SAP egress aggregate meter rate accounts for the Ethernet frame overhead. The system accounts for 12 bytes of IFG and 8 bytes of start delimiter. Frame-based counting does not affect the count of octets maintained by the counter, if in use.

Note: Before enabling this command for a SAP, resources must be allocated to this feature from the egress internal TCAM resource pool using the configure system resource-profile egress-internal-tcam egress-sap-aggregate-meter command. For more information, refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide. The egress aggregate meter is not FC aware. The forward and drop decisions are made based on the order the packets are sent out of the SAP by the egress port scheduler.

The no form of this command removes the egress aggregate policer from use.

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 types of filter policies are 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 is returned.

In general, filters applied to SAPs (ingress or egress) apply to all packets on the SAP. One exception is that 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 QoS policy with an ingress SAP or IP interface.

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.

On the 7210 SAS-R6 and 7210 SAS-R12 (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 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.

Note: The sum of CIR of the individual FCs configured under the SAP cannot exceed the PIR rate configured for the SAP. The 7210 SAS software does not block this configuration, however it is not recommended.

The meter modes “srtcm” and “trtcm1” are used in the absence of an aggregate meter.

The SAP ingress meter counters increment the packet or octet counts based on the final disposition of the packet.

If ingress frame-based accounting is used, the SAP aggregate meter rate accounts for the Ethernet frame overhead. The system accounts for 12 bytes of IFG and 8 bytes of start delimiter.

The no form of this command removes the aggregate policer from use.

This command enables the context for specific overrides to one or more meters created on the SAP through the SAP ingress QoS policies.

The no form of this command removes existing meter overrides.

This command enables the context for specific overrides to a specific meter created on the SAP through a sap-ingress QoS policies.

The no form of this command is used to remove any existing overrides for the specified meter-id.

This command enables the context to override specific attributes of the specified meter adaptation rule parameters. The adaptation rule controls the method used by the system to derive the operational CIR and PIR settings when the meter is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

The no form of this command removes explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

This command enables the context to override the default CBS for the meter. The committed burst size parameter specifies the maximum burst size that can be transmitted by the source while still complying with the CIR. If the transmitted burst is lower than the CBS value then the packets are marked as in-profile by the meter to indicate that the traffic is complying meter configured parameters.

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

This command enables the context to override the default MBS for the meter. The maximum burst size parameter specifies the maximum burst size that can be transmitted by the source while still complying with the CIR. If the transmitted burst is lower than the MBS value, the packets are marked as in-profile by the meter to indicate that the traffic is complying with meter configured parameters.

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

This command overrides the SAP ingress QoS policy configured mode parameters for the specified meter-id.

The no form of this command restores the policy defined metering and profiling mode to a meter.

This command overrides the SAP ingress QoS policy configured rate parameters for the specified meter-id.

The max default specifies the amount of bandwidth in kilobits per second (thousand bits per second). The max value is mutually exclusive to the pir-rate value.

The no form of this command restores the policy defined metering and profiling rate to a meter.

This command enables accounting and statistical data collection for either the SAP, network port, or IP interface. When applying accounting policies, by default the data 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 will not obtain the results and write them to the billing file. If a subsequent collect-stats command is issued, 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 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.

This command creates a binding between a service and an SDP. 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 will be 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 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 use of the control word on pseudowire packets in VPLS, and enables the use of the control word individually on each mesh SDP or spoke-SDP. By default, the control word is disabled. When the control word is enabled, all VPLS packets, including the BPDU frames, are encapsulated with the control word when sent over the pseudowire. The T-LDP control plane behavior is the same as in the implementation of control word for VLL services. The configuration for the two directions of the Ethernet pseudowire should match.

The no form of this command reverts the mesh SDP or spoke-SDP to the default value.

This command enables the egress SDP context.

This command enables the ingress SDP context.

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 configures 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 system immediately removes a SAP from the multicast group if it detects an IGMP “leave” on that SAP. Fast leave processing allows the switch to remove a SAP that sends a “leave” message from the forwarding table without first sending out group-specific queries to the SAP, and therefore speeds up the process of changing channels (known as “zapping”).

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

This command configures the VPLS and RVPLS 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 RVPLS 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 a membership report from a host.

Note: Only SAPs are supported in an RVPLS service. SDPs are not supported in an RVPLS service.

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

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

This command enables the use of the 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 this feature is enabled, the ingress data path is modified so 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. The egress data path appends 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 that 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.

Enable 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 apply when the hash-label option and the signal-capability option are enabled on the local PE.

If the hash-label option was enabled on the local configuration of the spoke-sdp or mesh-sdp at the remote PE, the pseudowire packets received by the local PE will have the hash label included. These packets must be dropped. Solve this by disabling the signaling capability option on the local node, which will result in the insertion of the hash label by both PE nodes.

If the hash-label option is not supported or was not enabled on the local configuration of the spoke-sdp or mesh-sdp at the remote PE, the pseudowire received by the local PE will not have the hash label included.

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 always in the range [524,288 to 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 will not match a value in the reserved label range. This is not supported on 7210 SAS 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, users must ensure that both ends are correctly configured to process hash labels or disable the feature.

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