5.22. VPLS 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 can 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 are described below in Special Cases.

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 creates or edits 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 together acting like a zero-hop, Layer 2 switched domain. A VPLS is always a logical full mesh.

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

To create a management VPLS, include the m-vpls keyword when creating the VPLS. Associate a range of VLANs with the mVPLS by using the managed-vlan-list command.

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

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

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

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

This command enables blocking (brings the entity to an operationally down state) after all configured SDPs or endpoints are in operationally down state. This event is signaled to a corresponding T-LDP peer 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 disables MAC address aging across a VPLS service or on a VPLS service SAP or spoke SDP.

As is the case for 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 will be ignored.

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

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

When disable-learning is enabled, new source MAC addresses will not be entered in the VPLS service forwarding database. This is true for both local and remote MAC addresses.

When disable-learning is disabled, new source MAC addresses will be 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 an unknown destination MAC address will be dropped instead of being flooded (even when configured FDB size limits for VPLS or SAPs 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.

When this command is enabled, the node will ignores the standby bit received from T-LDP peers for the given spoke SDP and performs internal tasks without taking the standby bit into account—traffic can egress out to the spoke SDP.

This command is present at the endpoint level as well as 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 that is a part of the given explicit endpoint will inherit this setting from the endpoint configuration.

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

For a regular endpoint, the revert-time setting affects only the pseudowire defined as “primary” (precedence 0). If the primary pseudowire fails and is then restored, the revert timer is started. After the revert timer expires, the primary pseudowire takes the active role in the endpoint. This behavior does not apply if both pseudowires are defined as “secondary”. For example, if the active secondary pseudowire fails and is restored, it will stay 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 address is then associated with the active spoke SDP.

When this command is enabled, the pseudowire standby bit (value 0x00000020) will not be sent to the T-LDP peer when the given spoke SDP is selected as a standby. This allows faster switchover because 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 enables PIM snooping for the VPLS service. When enabled, it is enabled for all SAPs except default SAPs. A default SAP is a SAP that has a wildcard VLAN ID, such as sap 1/1/1:*.

The no form of the command disables PIM snooping and removes the PIM snooping configuration.

This command identifies one or more route policies for multicast groups applied to this VPLS entity. The sources of the multicast traffic must be members of the VPLS.

Routing policies are configured in the config>router>policy-options context. The router policy must be defined before it can be imported. The grp-policy-name variable is the same as the name variable in the policy-options>policy-statement name command.

For details on route policies, refer to the “Route Policies” section in the 7705 SAR Router Configuration Guide.

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

This command configures the length of time during which the PIM snooping switch snoops all the PIM states in the VPLS. During the hold-time, multicast traffic is flooded in the VPLS. At the end of the hold-time, multicast traffic is forwarded using the snooped states. The snooped state consists of the forwarding state for the (S,G) and (*,G) groups, the incoming interface, and the outgoing interfaces.

When PIM snooping is enabled in VPLS, there is a period of time when the PIM snooping switch may not have built the complete snooping state. The switch cannot build states until the routers connected to the VPLS refresh their PIM messages.

This parameter is applicable only when PIM snooping is enabled.

This command disables PIM snooping for IPv4 multicast traffic within a VPLS service. By default, IPv4 multicast traffic is enabled.

The no form of the command enables PIM snooping for IPv4 multicast traffic within a VPLS service. To fully remove PIM snooping from a VPLS service, the no pim-snooping command must be used.

This command disables PIM snooping for IPv6 multicast traffic within a VPLS service. By default, IPv6 multicast traffic is disabled.

The no form of the command enables PIM snooping for IPv6 multicast traffic within a VPLS service. To fully remove PIM snooping from a VPLS service, the no pim-snooping command must be used.

This command sets the PIM snooping mode to proxy or plain snooping.

When enabled, this command appends Agent-Circuit-Id information to PADI and PADR packets received from an ATM SAP (the subscriber) that is bound to a VPLS instance. The Agent-Circuit-Id information is compliant with RFC 4679 section-3.3.1; Agent-Circuit-Id. The ATM SAP must be configured for bridged llc-snap encapsulation.

The pppoe-circuit-id command can be enabled or disabled for a VPLS instance or an individual ATM SAP. When applied to a VPLS instance, pppoe-circuit-id appends the Agent-Circuit-Id to all ATM SAPs bound to that VPLS instance. Furthermore, pppoe-circuit-id can be applied to individual SAPs bound to that VPLS instance in order to override the VPLS setting. If there is a mix of enabled and disabled SAPs bound to the VPLS instance, applying the command to the VPLS will override the mix, enabling (or disabling) pppoe-circuit-id on all the SAPs.

In addition, any newly created SAPs bound to the VPLS will default to match the VPLS setting.

As per the DSL Forum TR-101 April'06 specification, section 3.9.2, any PPPoE vendor-specific tag that may already be present in the received frame is replaced by the 7705 SAR client-id tag.

The no version of this command disables appending the Agent-Circuit-Id information.

This command enables the propagation of mac-flush messages received from the given T-LDP on all spoke and mesh SDPs within the context of the VPLS service. The propagation conforms to split-horizon principles and any datapath blocking in order to avoid looping of these messages.

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 returns the maximum FDB table size to the default.

This command accesses the context to configure load balancing.

This command enables or disables Layer 4 load balancing for the VPLS instance. When enabled, Layer 4 source and destination port fields of incoming TCP/UDP packets are included in the hashing calculation to randomly determine the distribution of packets.

Adding the Layer 4 source and destination port fields to the hashing algorithm generates a higher degree of randomness and a more even distribution of packets across the available LAG ports.

You can add additional fields to generate more randomness and more equal distribution of packets with the teid-load-balancing command.

Hashing based on the l4-load-balancing and teid-load-balancing commands and hashing based on the per-service-hashing command are mutually exclusive.

The no form of the command disables Layer 4 load balancing.

This command enables or disables hashing based on the service ID. The result of the hashing calculation is used to determine the distribution of packets.

Hashing based on the per-service-hashing command and hashing based on the l4-load-balancing and teid-load-balancing commands are mutually exclusive.

Note: Starting with Release 8.0.R4, unless per-service-hashing is enabled, a 4-byte hash value will be appended to internal overhead for VPLS multicast traffic at ingress. The egress internal hash value is discarded at egress before scheduling. Therefore, shaping rates at access and network ingress and for fabric policies may need to be adjusted accordingly. In addition, the 4-byte internal hash value may be included in any affected statistics counters.

The no form of the command disables per-service hashing.

This command enables use of the SPI in hashing for ESP/AH encrypted IPv4 or IPv6 traffic at the interface level.

The no form of this command disables SPI hashing.

This command enables or disables TEID load balancing for the VPLS instance. The TEID attribute is included in the header of GTP (general packet radio system tunneling protocol) packets. When TEID load balancing is enabled, the TEID field of incoming TCP/UDP packets is included in the hashing calculation to randomly determine the distribution of packets.

You can add additional fields to generate more randomness and more equal distribution of packets with the l4-load-balancing command.

Hashing based on the teid-load-balancing and l4-load-balancing commands and hashing based on the per-service-hashing command are mutually exclusive.

The no form of the command disables TEID load balancing.

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 SAP or SDP. MACs associated with a SAP are classified as local MACs, and MACs associated with an SDP are remote MACs.

As is the case for 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 locally learned MAC and remotely learned MAC entries in the FDB. The local-age timer specifies the aging time for locally learned MAC addresses.

The no form of this command returns the local aging timer 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, the spanning tree protocol (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 the 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 increases linearly with the number of times the given SAP was disabled. A SAP can be configures as non-blockable with the limit-mac-move command. This means that when the relearn rate has exceeded the limit, another (blockable) SAP will be disabled instead. By default, all SAPs and spoke SDPs are configured as blockable when MAC-move is enabled.

When MAC-move is enabled and the relearn rate exceeds the maximum limit, the 7705 SAR sends a “Mac move rate for MAC ... exceeded” alarm. This alarm is raised for both blockable and non-blockable SAPs and spoke SDPs. The alarm frequency for non-blockable SAPs and spoke SDPs decreases if the MAC-move condition persists.

The mac-move command enables the feature at the service level for SAPs and spoke SDPs, as only those objects can be blocked by this feature. Mesh SDPs are never blocked, but their relearn rates (SAP-to-mesh/spoke-to-mesh or vice versa) are still measured.

The operation of this feature is the same on the SAP and spoke SDP. For example, if a MAC address moves from SAP to SAP, from SAP to spoke SDP, or between spoke SDPs, one will be blocked to prevent thrashing. If the MAC address moves between a SAP and mesh SDP or spoke SDP and mesh SDP combinations, the respective SAP or spoke SDP will be blocked.

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

The no form of this command disables MAC move.

This command specifies the number of bits to be considered when performing MAC learning (MAC source) and MAC switching (MAC destination). Specifically, this value identifies how many bits are used, starting from the beginning of the MAC address. For example, if the mask value of 28 is used, MAC learning will only do a lookup for the first 28 bits of the source MAC address when comparing it with existing FDB entries. Then, it will install the first 28 bits in the FDB while zeroing out the last 20 bits of the MAC address. When performing switching in the reverse direction, only the first 28 bits of the destination MAC address will be used to perform an FDB lookup to determine the next hop.

The no form of this command switches back to full MAC lookup.

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 in order to protect the system against undetected loops or duplicate MACs.

The no form of the command reverts to the default value

This command configures the number of times that retries are performed for re-enabling the SAP or SDP bindings.

This command enables the context to define primary VPLS ports. VPLS ports that were declared as secondary prior to the execution of this command will be moved from secondary port level to primary port level. Changing a port to the tertiary level (default) can only be done by first removing it from the secondary port level.

This command configures a factor for the primary or secondary ports that defines how many MAC relearn periods should be used to measure the MAC relearn rate. The rate must be exceeded during consecutive periods before the corresponding ports (SAP and/or spoke SDP) are blocked by the mac-move feature.

This command configures the specified SAP to be a primary or secondary VPLS port.

This command configures the specified spoke SDP to be a primary or secondary VPLS port.

This command enables the context to define secondary VPLS ports. VPLS ports that were declared as primary prior to the execution of this command will be moved from the primary port level to the secondary port level. Changing a port to the tertiary level (default) can only be done by first removing it from the primary port level.

This command indicates 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 timeout value be equal to or larger than 5 s × cumulative factor of the highest-priority port so that the sequential order of port blocking will not be disturbed by reinitializing lower-priority ports.

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

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

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 classified as local MACs, and MACs associated with an SDP are remote MACs.

As is the case for 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 locally learned MAC and remotely learned MAC entries in the FDB. The remote-age timer specifies the aging time for remotely learned MAC addresses. To reduce the amount of signaling required between switches, configure this timer to be larger than the local-age timer.

The no form of this command returns the remote aging timer 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 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 Rapid Spanning Tree Protocol (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 will be sent out only when all spoke SDPs associated with the endpoint go down.

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 bindings’ operational state within the service.

The service MTU and a SAP’s service delineation encapsulation overhead (that is, 4 bytes for a dot1q tag or 8 bytes for a qinq tag) are 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 will be placed in an inoperative state. If the required MTU is equal to or less than the port or channel MTU, the SAP will be able to transition to the operative state.

When binding an SDP to a service, the service MTU is compared to the path MTU associated with the SDP. The path MTU can be administratively defined in the context of the SDP. The default or administrative path MTU can be dynamically reduced due to the MTU capabilities discovered by the tunneling mechanism of the SDP or the egress interface MTU capabilities based on the next hop in the tunnel path. If the service MTU is larger than the path MTU, the SDP binding for the service will be placed in an inoperative state. If the service MTU is equal to or less than the path MTU, then the SDP binding will be placed in an operational state.

If 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 re-evaluated.

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

This command configures a service name that can be used in other configuration commands and show commands that reference the service.

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

A split horizon group must be created before SAPs and spoke SDPs can be assigned to the group. The split horizon group is defined within the context of a single VPLS. The same group-name can be reused in different VPLS instances.

An ATM SAP must be in a residential SHGs. If an Ethernet SAP is in a SHG, then that SHG cannot be a residential SHG.

Up to 30 split horizon groups can be defined per VPLS instance.

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

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters that identify the service access point on the interface and within the 7705 SAR. Each SAP must be unique. All SAPs must be explicitly created. If no SAPs are created within a service or on an IP interface, a SAP will 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. Channelized TDM ports are always access ports.

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 split-horizon group can be associated with an Ethernet ring in order to prevent loops in cases where an Ethernet virtual ring is misconfigured on the main ring. Each A and B path in the major ring is configured in the group and associated with the sub-ring control instance in the VPLS service.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP will also be deleted. For Internet Enhanced Service (IES), the IP interface must be shut down before the SAP on that interface may be removed.

This command enables Cflowd to collect traffic flow samples through a SAP for analysis. When Cflowd is enabled on a VPLS service SAP, the Ethernet traffic can be sampled and processed by the system’s Cflowd engine and exported to Cflowd version 10 collectors with the l2-ip template enabled.

When Cflowd is enabled at the SAP level, all packets forwarded by the interface are subject to analysis according to the Cflowd configuration.

For Layer 2 services, only ingress sampling is supported.

This command specifies that packets received on a SAP or a spoke SDP with an unknown source MAC address will be 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 addresses to be forwarded by destination MAC addresses in VPLS.

This command indicates whether the MAC move agent, when enabled using mac-move, will limit the MAC relearn (move) rate on this SAP.

This command disables relearning of MAC addresses on other SAPs or SDPs within the VPLS. The MAC address will remain attached to a given SAP or SDP for the duration of its age timer.

The age of the MAC address entry in the FDB is set by the age timer. If mac-aging is disabled on a given VPLS service, any MAC address learned on a SAP or SDP with mac-pinning enabled will remain in the FDB on this SAP or SDP forever. Every event that would otherwise result in relearning will be logged (MAC address; original SAP; new SAP).

MAC addresses learned during DHCP address assignment (DHCP snooping enabled) are not impacted by this command. MAC pinning for such addresses is implicit.

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 will be discarded.

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

This command creates 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 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 FDB 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 FDB 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 access to the context to configure ATM-related attributes. This command can only be used when a given context (for example, a channel or SAP) supports ATM functionality such as:

If ATM functionality is not supported for a given context, the command returns an error.

This command enables the context to configure egress ATM attributes for the SAP.

This command assigns an ATM traffic descriptor profile to a given context (for example, a SAP).

When configured under the egress context, the specified traffic descriptor profile defines the traffic contract in the backwards direction.

The no form of the command reverts to the default traffic descriptor profile.

This command specifies the data encapsulation for an ATM PVCC-delimited SAP. The definition references RFC 2684, Multiprotocol Encapsulation over ATM AAL5, and the ATM Forum LAN Emulation specification.

Ingress traffic that does not match the configured encapsulation will be dropped.

This command enables the context to configure OAM functionality for a PVCC delimiting a SAP. The ATM-capable adapter cards support the following F5 end-to-end OAM functionality (AIS, RDI, loopback):

This command configures AIS/RDI fault management on a PVCC. Fault management allows PVCC termination to monitor and report the status of its connection by propagating fault information through the network and by driving a PVCC operational status.

When alarm-cells functionality is enabled, a PVCC operational status is affected when a PVCC goes into an AIS or RDI state because of AIS/RDI processing. This assumes that nothing else affects the PVCC operational status; for example, the PVCC goes down, or enters a fault state and comes back up, or exits that fault state. RDI cells are generated when a PVCC is operationally down. No OAM-specific SNMP trap is raised whenever an endpoint enters or exits an AIS or RDI state; however, if an OAM state change results in a change to the operational status of the PVCC, then a trap is expected from an entity that the PVCC is associated with (for example, a SAP).

The no form of the command disables alarm-cells functionality for a PVCC. When alarm-cells functionality is disabled, the PVCC operational status is no longer affected by the PVCC OAM state changes due to AIS/RDI processing. When alarm-cells is disabled, a PVCC will change operational status to up from down due to alarm-cell processing. RDI cells are not generated as result of PVCC going into an AIS or RDI state; however, the PVCC OAM status will record OAM faults as described above.

This command enables the push operation of a configured VLAN at ingress and a pop operation at egress on a per-ATM SAP basis. After AAL5 termination at ATM access ingress as per the configured encapsulation type, the configured VLAN tag is pushed to the received subscriber frame. The type of Ethernet frame is set to 0x8100 in order to designate the existence of the VLAN header, and the original Ethertype is shifted by 4 bytes (dot1q) or 8 bytes (qinq), enlarging the resulting subscriber frame by 4 or 8 bytes.

Using the subscriber-vlan command necessitates the use of the tagged (dot1q or qinq) uplink. In the uplink ingress direction (from the network to the 7705 SAR), the 7705 SAR is programmed to pop the VLAN tags. The first pop operation is mandatory, but if the frame is a single-tagged frame and there are no other VLAN tags, then the resulting untagged frame is forwarded to the subscriber interface without any errors.

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

This command enables the Multicast Listener Discovery (MLD) snooping context.

This command enables or disables router alert checking for IGMP or MLD messages received on this interface. The router alert field in the IP header is used to inform the router to extract the packet. By default, router alert checks are enabled for IGMP and MLD packets (that is, no disable).

The no form of the command enables the router alert check.

This command enables fast leave. When IGMP or MLD fast-leave processing is enabled, the 7705 SAR immediately removes a SAP or SDP from the multicast group when it detects an IGMP or MLD leave message on that SAP or SDP. Fast-leave processing allows the 7705 SAR to remove from the forwarding table a SAP or SDP that has sent a leave message without first sending group-specific queries to the SAP or SDP. This speeds up the process of changing channels (called 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 specifies the import routing policy used to filter IGMP or MLD packets 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 the command removes the policy association from the SAP or SDP.

This command configures the maximum response time used in group-specific queries that are sent by the router acting as the querier in response to leave messages, and is also the amount of time between two 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, MLD, or PIM join message that would exceed the configured number of groups, the request is ignored. The max-num-groups command does not apply to mesh SDPs.

The no form of this command disables the check.

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

The no form of this command disables the check.

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

The no form of this command disables the check.

This command specifies whether a multicast router is attached behind this SAP or SDP.

Configuring a SAP as an mrouter-port has two effects. First, all multicast traffic received on another SAP or SDP is copied to this SAP or SDP. Second, IGMP or MLD reports generated by the system as a result of a host joining or leaving a multicast group are sent to this SAP or SDP.

If two multicast routers exist in the network, one of them becomes the active querier and the other one (the non-querier) stops sending IGMP queries. The non-querier router continues to receive reports in order to keep its multicast trees up to date. To support this, enable mrouter-port on all SAPs or SDPs connected to a multicast router.

The version used for the reports (IGMPv1, v2, or v3, or MLDv1 or v2) can only be determined after an initial query has been received. Until the version is determined, no reports are sent on the SAP or spoke SDP, even if mrouter-port is enabled.

If the send-queries command is enabled on this SAP or spoke SDP, the mrouter-port command cannot be enabled. The mrouter-port and send-queries commands are mutually exclusive.

This command configures the IGMP or MLD query interval. If the send-queries command is enabled, this command specifies the interval between two consecutive general queries sent by the router acting as the querier on this SAP or SDP. The configured query-interval must be greater than the configured query-response-interval.

If send-queries is not enabled on this SAP or SDP, the configured query-interval value is ignored.

This command configures the IGMP or MLD query response interval. If the send-queries command is enabled, this command specifies how long the router acting as the querier waits to receive a response from the host. The configured query-response-interval must be smaller than the configured query-interval. If send-queries is not enabled on this SAP or SDP, the configured query-response-interval value is ignored.

This command configures the IP source address used in IGMP or MLD queries.

This command specifies the source IP address used when generating IGMP or MLD reports. According to the IGMPv3 standard, a zero source address is allowed when sending IGMP reports. However, for interoperability with some multicast routers, the source IP address of IGMP group reports can be configured using this command.

This command allows tuning for the expected packet loss on a SAP or an SDP, and is comparable to a retry count. For a SAP or SDP, this command is functional when the send-queries command is enabled. If the send-queries command is not enabled, robust-count is ignored. If the SAP or SDP is expected to experience packet loss, the robust-count parameter may be increased. IGMP or MLD snooping on this SAP or SDP is robust up to the robust-count minus 1 packet.

This command specifies whether to send IGMP or MLD general query messages on the SAP or SDP.

When send-queries is configured, all query reports generated locally are of the type belonging to the configured version. If a report from a version higher than the configured version is received, the report is dropped and a “wrong version” counter is incremented. If send-queries is not configured, the version command has no effect and the version used is the version of the querier. This implies that, for example, when there is a version 2 querier, a specific version 3 group or group-source query is never sent when a host wants to leave a group.

This command enables access to the context to configure static group addresses. Static group addresses can be configured on a SAP or SDP. When present as either a (*,G) or a (S,G) entry, multicast packets matching the configuration are forwarded even if no join message was registered for the specific group.

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

The group is not created until the source or starg is specified.

This command adds a static (S,G) entry, to allow multicast traffic for a multicast group from a specified source. For a multicast group, more than one source address can be specified. Static (S,G) entries cannot be added if a starg has been created previously.

The no form of the command removes the source from the configuration.

This command adds a static (*,G) entry to allow multicast traffic for the corresponding multicast group from any source. This command can only be enabled if there are no existing source addresses for this group.

The no form of the command removes the starg entry from the configuration.

This command specifies the version of IGMP or MLD that is running on this SAP or SDP. This command can be used to configure a router capable of running IGMP version 1, 2, or 3, or MLD version 1 or 2. For IGMP or MLD to function correctly, all routers on a LAN must be configured to run the same version of IGMP or MLD on that LAN.

When the send-queries command is configured, all query reports generated locally are of the type belonging to the configured version. If a report from a version higher than the configured version is received, the report gets dropped and a “wrong version” counter is incremented.

If the send-queries command is not configured, the version command has no effect. The version used on that SAP or SDP is the version of the querier. This implies that, for example, when there is an IGMP version 2 querier, a specific version 3 group or group-source query is never sent when a host wants to leave a group.

The no form of the command returns the version to the default value.

This command enables the context to configure the Spanning Tree Protocol (STP) parameters. The 7705 SAR runs the RSTP version of STP. The Nokia implementation of STP is simply 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. Since the core network operating between Nokia service routers should not be blocked, the root path is calculated from the core perspective.

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

The hello-time command 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.

Since VPLS on the 7705 SAR runs in RSTP mode, the hello time is always taken from the locally configured parameter, unless RSTP fails and the SAP falls back to legacy STP operation, in which case the hello time for the spanning tree is determined by the root bridge.

The no form of this command returns the hello time to the default value.

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

The no form of this command returns the hold count to the default value.

This command specifies the version of Spanning Tree Protocol the bridge is currently running. VPLS on the 7705 SAR runs only in RSTP mode.

The no form of this command returns the STP variant to the default mode.

The 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 will be truncated to multiples of 4096, conforming with IEEE 802.1t and 802.1D-2004.

The no form of this command returns the bridge priority to the default value.

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 will be 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 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 or qinq.

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

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

If auto-edge is enabled and STP concludes there is no bridge behind the SAP or spoke SDP, the OPER_EDGE variable will dynamically be set to true. If auto-edge is enabled and a BPDU is received, the OPER_EDGE variable will dynamically be set to false (see edge-port).

The no form of this command removes automatic edge detection.

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

The function of the edge-port command is to tell STP that it is on the edge of the network (for example, there are no other bridges connected to that port), and, as a consequence, it can immediately transition to a forwarding state if the port becomes available.

STP, 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 will change if:

The no form of this command returns the edge port setting to the default value.

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

The no form of this command returns the link type 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 or spoke SDP. When BPDUs are sent out other egress SAP or spoke SDP, 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 and spoke SDPs are controlled by complex queuing dynamics, in the 7705 SAR the STP path cost is a purely static configuration.

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

This command configures the virtual port number that uniquely identifies a SAP or spoke SDP within configuration BPDUs. The internal representation of a SAP or spoke SDP is unique to a system and has a reference space much larger than the 12 bits definable in a configuration BPDU. STP takes the internal representation value of a SAP or spoke SDP and identifies it with its own virtual port number, which is unique to any other SAP or spoke SDP defined on the VPLS. The virtual port number is assigned at the time that the SAP or spoke SDP is added to the VPLS. Since the order in which SAPs or spoke SDPs are added to the VPLS is not preserved between reboots of the system, the virtual port number may change between restarts of the STP instance.

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

When configuration BPDUs are received, the STP priority is used in some circumstances as a tiebreaking mechanism to determine whether the SAP or spoke SDP 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) 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 or spoke SDP within the STP instance.

STP computes the actual priority by taking the input value and masking out the lower 4 bits.The result is the value that is stored in the SAP or spoke SDP 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 returns the STP priority to the default value.

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 enables the context to configure egress SAP QoS policies and filter policies.

If no sap-egress QoS policy is defined, the system default sap-egress QoS policy is used for egress processing. 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 sets the aggregate rate limits (PIR and CIR) for the SAP. The agg-rate sets the PIR value. The cir-rate sets the CIR value. When aggregate rate limits are configured on a second-generation (Gen-2) Ethernet adapter card, the scheduler mode must be set to 16-priority. On a third-generation (Gen-3) Ethernet adapter card, the scheduler mode is always 4-priority. For information on adapter card generations, refer to the “Evolution of Ethernet Adapter Cards, Modules, and Platforms” section in the 7705 SAR Interface Configuration Guide.

Configuring the cir-rate is optional. If a cir-rate is not entered, then the cir-rate is set to its default value (0 kb/s). If a cir-rate has been set and the agg-rate is changed without re-entering the cir-rate, the cir-rate automatically resets to 0 kb/s. For example, to change the agg-rate from 2000 to 1500 while maintaining a cir-rate of 500, use the command agg-rate-limit 1500 cir 500.

If the specified SAP is a LAG SAP, then agg-rate and cir-rate can be configured regardless of the scheduler mode setting on Gen-2 or Gen-3 hardware—it is not configurable if one of the ports configured in the LAG SAP is on Gen-1 hardware. If the active port is on a Gen-3 card or platform, then agg-rate and cir-rate are applicable. If the active port is on a Gen-2 card or platform, then agg-rate and cir-rate apply when the scheduler mode is set to 16-priority. If the active port is on a Gen-1 card, then agg-rate and cir-rate are not applicable. For details on the behavior of a mix-and-match LAG SAP, refer to the “LAG Support on Third-Generation Ethernet Adapter Cards, Ports, and Platforms” and “Network LAG Traffic Management” sections in the 7705 SAR Interface Configuration Guide.

The no form of the command sets the agg-rate to the maximum and the cir-rate to 0 kb/s.

This command associates a filter policy with a SAP or SDP (mesh or spoke). Filters can be applied to VPLS and routed VPLS SAPs and SDPs.

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 at a time. The filter ID must be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message will be returned.

Only one filter ID can be assigned to an interface unless the interface is dual-stack (supports both IPv4 and IPv6). A dual-stack interface can have one IPv4 and one IPv6 filter ID assigned to it.

In general, filters applied to SAPs or SDPs apply to all packets on the SAP or SDP. 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.

If an IP interface is attached to a VPLS service context (routed VPLS), the VPLS SAP or SDP configured IP or MAC filter for ingress routed packets can be optionally overridden in order to provide special ingress filtering for routed packets. This allows different filtering for routed packets and non-routed packets. The filter override is defined on the IP interface bound to the VPLS service name. A separate override filter can be specified for IPv4 and IPv6 packet types, using the v4-routed-override-filter or v6-routed-override-filter command in the IES or VPRN service contexts.

If filter override is configured, the IP or MAC filter configured on the SAP or SDP applies to non-routed packets. If filter override is not configured, the IP or MAC filter configured on the SAP or SDP applies to both routed and non-routed packets.

The no form of this command removes any configured filter ID association with the SAP or SDP. The filter ID itself is not removed from the system unless the scope of the created filter is set to exclusive. To avoid deletion of the filter ID and only break the association with the service object, use the scope command within the filter definition to set the scope to template. The default scope of a filter is exclusive.

This command specifies which dot1q tag position (top or bottom) in a qinq-encapsulated packet should be used when QoS evaluates dot1p classification.

The no form of the command restores the default dot1p evaluation behavior for the SAP, which means that the inner (bottom) tag (second tag) dot1p bits are used for classification.

By default, the dot1p bits from the inner tag service-delineating dot1q tag are used.

Table 66 shows which set of dot1p bits are used for QoS purposes when match-qinq-dot1p is configured. To use the table, find the row that represents the settings for Port/SAP Type and Match-QinQ-Dot1q Setting. Use the Existing Packet Tags column to identify which dot1q tags are available in the packet. Then use the P-bits Used for Match column to identify which dot1q tag contains the dot1p bits that are used for QoS dot1p classification.

When enabled, the qinq-mark-top-only command specifies which P-bits to mark during packet egress. When disabled, both sets of P-bits are marked. When enabled, only the P-bits in the top Q-tag are marked. The no form of the command is the default state (disabled).

Table 67 shows the dot1p remarking behavior for different egress port type/SAP type combinations and qinq-mark-top-only state, where “False” represents the default (disabled) state.

If a new tag is pushed, the dot1p bits of the new tag will be zero (unless the new tag is re-marked by the egress policy. The dot1p bits are configured using the dot1p parameter under the config>qos context.

This command associates a QoS policy with an ingress or egress SAP.

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

The qos command is used to associate both ingress and egress QoS policies. The qos command only allows ingress policies to be associated with ingress SAP, and egress policies with egress SAP. 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.

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

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

This command sets the scheduler mode for the SAP and is part of the hierarchical QoS (H-QoS) feature on the 7705 SAR.

If the mode is 4-priority, then the SAP is considered an unshaped 4-priority SAP and the agg-rate-limit cannot be changed from its default values.

If the mode is 16-priority and the agg-rate limit parameters are configured to be non-default values, then the SAP is considered a shaped SAP. If the agg-rate limit parameters are left in their default settings, the SAP is considered an unshaped, 16-priority SAP.

This command is blocked on third-generation (Gen-3) Ethernet adapter cards and platforms, such as the 6-port Ethernet 10Gbps Adapter card and the 7705 SAR-X, which only support 4-priority scheduling mode.

If the specified SAP is a LAG SAP, scheduler-mode can be configured but is not applied to Gen-3 adapter cards and platforms. If one of the ports in the LAG is on a Gen-1 adapter card, then scheduler-mode cannot be configured.

This command applies a shaper group to a SAP. The shaper group must already be created and must be within the shaper policy assigned to the Ethernet MDA (for ingress) or port (for egress). A shaper group is a dual-rate aggregate shaper used to shape aggregate access ingress or egress SAPs at a shaper group rate. Multiple aggregate shaper groups ensure fair sharing of available bandwidth among different aggregate shapers.

The default shaper group cannot be deleted.

The no form of this command removes the configured shaper-group.

This command preserves the VLAN tag at the ingress SAP. The default (disabled) behavior is to strip off the VLAN tag at the ingress SAP and push a new VLAN tag at the egress SAP.

The force-c-vlan-forwarding command is only available on VPLS dot1q and qinq SAPs.

When the ingress and egress port encap-type are both dot1q, force-c-vlan-forwarding has the following behavior:

When the ingress and egress port encap-type are both qinq, force-c-vlan-forwarding has the following behavior:

The no version of this command sets the default behavior.

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 acct-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 a SAP, a network port, or an 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 CSM. However, the CPU will 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 enables the context to configure DHCP parameters.

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

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

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

The no form of this command returns the system to the default value.

This command causes the router to send an ASCII-encoded “tuple” in the circuit-id suboption of the DHCP packet. This ASCII-tuple consists of the access-node-identifier, service-id, and SAP-ID, separated by “|”. If no keyword is configured, then the circuit-id suboption will not be part of the information option (Option 82).

If disabled, the circuit-id suboption of the DHCP packet will be left empty.

This command specifies what information goes into the remote-id suboption in the DHCP Relay packet.

If disabled, the remote-id suboption of the DHCP packet will be left empty.

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

This command configures the vendor-specific suboption within the Option 82 field 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 the 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 the 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 the 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 the command returns the default value.

This command specifies whether the system ID is encoded in the vendor specific suboption of Option 82.

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

Use the no form of the command to disable DHCP snooping on the specified VPLS SAP binding.

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.

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 in order 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 7705 SAR 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. Once removed, no packets are forwarded to the far-end router.

This command binds a service to an existing 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 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 will be down.

The SDP must already be defined in the config>service>sdp context in order to associate an SDP with a VPLS 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. Once 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 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 the command resets the mesh SDP or spoke SDP to the default behavior of not using the control word.

This command configures the egress SDP context.

This command configures the ingress SDP context.

This command configures the egress VC label.

This command configures the ingress VC label.

This command enables or disables the use of entropy labels for mesh or spoke SDPs.

If entropy-label is enabled, the entropy label and entropy label indicator (ELI) are inserted in packets for which at least one LSP in the stack for the far end of the tunnel used by the service has advertised entropy label capability.

If the tunnel is an RSVP-TE type, entropy-label can also be controlled by disabling entropy-label-capability under the config>router>rsvp context at the far-end LER.

When the entropy-label and entropy-label-capability commands are both enabled, the entropy label value inserted at the iLER is always based on the service ID.

This command configures the precedence of this SDP binding when there are multiple SDP bindings attached to one service endpoint. When an SDP binding goes down, the next highest precedence SDP binding begins forwarding traffic.

This command enables pseudowire status signaling for spoke SDPs. The no form of this command disables pseudowire status signaling. When pseudowire status signaling is disabled, a 7705 SAR does not include the PW status TLV in the initial label mapping message of the pseudowire that is used for a spoke SDP. This forces both 7705 SAR PEs to use the pseudowire label withdrawal method for signaling pseudowire status. If the remote endpoint has standby-signaling-master enabled and it determines that a particular PW should be standby, based on the precedence of the PWs, it will withdraw the PW label. If the label is withdrawn for all PWs on a VPLS, the VPLS will go operationally down.

If pseudowire status signaling is enabled, the 7705 SAR includes the pseudowire status TLV in the initial label mapping message for the pseudowire.

This command creates a remote static MAC entry in the VPLS FDB associated with the SDP.

In a VPLS service, MAC addresses are associated with a SAP or an SDP. MACs associated with a SAP are classified as local MACs, and MACs associated with an SDP are remote MACs.

Remote static MAC entries create a permanent MAC address to SDP association in the FDB 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 FDB for the VPLS.

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

The no form of this command deletes the static MAC entry with the specified MAC address associated with the SDP from the VPLS FDB.

This command specifies an explicit dot1q value that is 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 0 is stored as the administrative dot1q value. Setting the value to 0 is equivalent to not specifying the value.

The no form of this command disables the command.