For feedback and comments:
documentation.feedback@alcatel-lucent.com

Table of Contents Previous Next PDF


Global Service Configuration Commands
Generic Commands
shutdown
Syntax
[no] shutdown
Context
config>eth-cf>mep
config>service>sdp
config>service>sdp>class-forwarding
config>service>sdp>keep-alive
config>service>sdp>forwarding-class
config>service>pw-routing>hop
config>service>pw-template>stp
config>service>sdp>binding>pw-port
config>eth-tunnel>path
config>eth-tunnel>path>eth-cfm>mep
config>eth-tunnel
Description
This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.
The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.
Services are created in the administratively down (shutdown) state. When a no shutdown command is entered, the service becomes administratively up and then tries to enter the operationally up state. Default administrative states for services and service entities is described below in Special Cases.
The no form of this command places the entity into an administratively enabled state.
Special Cases
Service Admin State
Bindings to an SDP within the service will be put into the out-of-service state when the service is shutdown. While the service is shutdown, all customer packets are dropped and counted as discards for billing and debugging purposes.
SDP (global)
When an SDP is shutdown at the global service level, all bindings to that SDP are put into the out-of-service state and the SDP itself is put into the administratively and operationally down states. Packets that would normally be transmitted using this SDP binding will be discarded and counted as dropped packets.
SDP (service level)
Shutting down an SDP within a service only affects traffic on that service from entering or being received from the SDP. The SDP itself may still be operationally up for other services.
SDP Keepalives
Enables SDP connectivity monitoring keepalive messages for the SDP ID. Default state is disabled (shutdown) in which case the operational state of the SDP-ID is not affected by the keepalive message state.
description
Syntax
description description-string
no description
Context
config>service>customer
config>service>customer>multi-service-site
config>service>pw-template
config>service>pw-template>split-horizon-group
config>service>sdp
config>eth-tunnel
config>eth-tunnel>path
config>eth-tunnel>path>eth-cfm>mep
Description
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.
Default
No description associated with the configuration context.
Parameters
string
The description character string. Allowed values are any string up to 80 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, etc.), the entire string must be enclosed within double quotes.
new-qinq-untagged-sap
Syntax
[no] new-qinq-untagged-sap
Context
config>system>ethernet
Description
This command controls the behavior of QinQ SAP y.0 (for example, 1/1/1:3000.0). If the flag is not enabled (no new-qinq-untagged-sap), the y.0 SAP works the same as the y.* SAP (for example, 1/1/1:3000.*); all frames tagged with outer VLAN y and no inner VLANs or inner VLAN x where inner VLAN x is not specified in a SAP y.x configured on the same port (for example, 1/1/1:3000.10).
If the flag is enabled, then the following new behavior immediately applies to all existing and future y.0 SAPs: the y.0 SAP maps all the ingress frames tagged with outer tag VLAN-id of y (qinq-etype) and no inner tag or with inner tag of VLAN-id of zero (0).
Default
no new-qinq-untagged-sap. This setting ensures that there will be no disruption for existing usage of this SAP type.
 
Customer Management Commands
customer
Syntax
customer customer-id [create]
no customer customer-id
Context
config>service
Description
This command creates a customer ID and customer context used to associate information with a particular customer. Services can later be associated with this customer at the service level.
Each customer-id must be unique. The create keyword must follow each new customer customer-id entry.
Enter an existing customer customer-id (without the create keyword) to edit the customer’s parameters.
Default customer 1 always exists on the system and cannot be deleted.
The no form of this command removes a customer-id and all associated information. Before removing a customer-id, all references to that customer in all services must be deleted or changed to a different customer ID.
Parameters
customer-id
Specifies the ID number to be associated with the customer, expressed as an integer.
Values
create
This keyword is required when first creating the configuration context. Once the context is created, it is possible to navigate into the context without the create keyword.
contact
Syntax
contact contact-information
no contact contact-information
Context
config>service>customer
Description
This command allows you to configure contact information for a customer.
Include any customer-related contact information such as a technician’s name or account contract name.
Default
No contact information is associated with the customer-id.
The no form of this command removes the contact information from the customer ID.
Parameters
contact-information
The customer contact information entered as an ASCII character string up to 80 characters in length. If the string contains special characters (#, $, spaces, etc.), the entire string must be enclosed within double quotes. Any printable, seven bit ASCII characters may be used within the string.
 
multi-service-site
Syntax
multi-service-site customer-site-name [create]
no multi-service-site customer-site-name
Context
config>service>customer
Description
This command creates a new customer site or edits an existing customer site with the customer-site-name parameter. A customer site is an anchor point to create an ingress and egress virtual scheduler hierarchy. When a site is created, it must be assigned to a chassis slot or port with the exception of the in which the slot is set to 1.When scheduler policies are defined for ingress and egress, the scheduler names contained in each policy are created according to the parameters defined in the policy. Multi-service customer sites exist for the sole purpose of creating a virtual scheduler hierarchy and making it available to queues on multiple Service Access Points (SAPs).
The scheduler policy association with the customer site normally prevents the scheduler policy from being deleted until after the scheduler policy is removed from the customer site. The multi-service-site object will generate a log message indicating that the association was deleted due to scheduler policy removal.
When the multi-service customer site is created, an ingress and egress scheduler policy association does not exist. This does not prevent the site from being assigned to a chassis slot or prevent service SAP assignment. After the site has been created, the ingress and egress scheduler policy associations can be assigned or removed at any time.
Default
None — Each customer site must be explicitly created.
Parameters
customer-site-name
Each customer site must have a unique name within the context of the customer. If customer-site-name already exists for the customer ID, the CLI context changes to that site name for the purpose of editing the site scheduler policies or assignment. Any modifications made to an existing site will affect all SAPs associated with the site. Changing a scheduler policy association may cause new schedulers to be created and existing queues on the SAPs to no longer be orphaned. Existing schedulers on the site may cease to exist, causing queues relying on that scheduler to be orphaned.
If the customer-site-name does not exist, it is assumed that an attempt is being made to create a site of that name in the customer ID context. The success of the command execution depends on the following:
The customer-site-name is valid.
The create keyword is included in the command line syntax (if the system requires it).
When the maximum number of customer sites has been exceeded a configuration error occurs; the command will not execute and the CLI context will not change.
If the customer-site-name is invalid, a syntax error occurs; the command will not execute and the CLI context will not change.
Values
 
phone
Syntax
[no] phone string
Context
config>service>customer customer-id
Description
This command adds telephone number information for a customer ID.
Default
none
The no form of this command removes the phone number value from the customer ID.
Parameters
string
The customer phone number entered as an ASCII string string up to 80 characters. If the string contains special characters (#, $, spaces, etc.), the entire string must be enclosed within double quotes. Any printable, seven bit ASCII characters may be used within the string.
assignment
Syntax
assignment {port port-id | card slot-number}
no assignment
Context
config>service>customer>multi-service-site
Description
This command assigns a multi-service customer site to a specific chassis slot, port, or channel. This allows the system to allocate the resources necessary to create the virtual schedulers defined in the ingress and egress scheduler policies as they are specified. This also verifies that each SAP assigned to the site exists within the context of the proper customer ID and that the SAP was configured on the proper slot, port, or channel . The assignment must be given prior to any SAP associations with the site.
The no form of the command removes the port, channel, or slot assignment. If the customer site has not yet been assigned, the command has no effect and returns without any warnings or messages.
Default
None
Parameters
port port-id
The port keyword is used to assign the multi-service customer site to the port-id or port-id.channel-id given. When the multi-service customer site has been assigned to a specific port or channel, all SAPs associated with this customer site must be on a service owned by the customer and created on the defined port or channel. The defined port or channel must already have been pre-provisioned on the system but need not be installed when the customer site assignment is made.
Syntax: port-id[:encap-val]
Values
port-id slot/mda/port[.channel]
aps-id aps-group-id[.channel]
aps keyword
group-id 1 — 64
group-id 1 — 16
bundle-type-slot/mda.bundle-num
bundle keyword
type ima, ppp
bundle-num 1 — 256
bpgrp-id: bpgrp-type-bpgrp-num
bpgrp keyword
type ima
bpgrp-num 1 — 1280
ccag-id - ccag-<id>.<path-id>[cc-type]
ccag keyword
id 1 — 8
path-id a, b
cc-type [.sap-net | .net-sap]
lag-id lag-id
lag keyword
id 1 — 800
lag-id lag-id
lag keyword
id 1 — 64
card slot-number
The card keyword is used to assign the multi-service customer site to the slot-number given. When the multi-service customer site has been assigned to a specific slot in the chassis, all SAPs associated with this customer site must be on a service owned by the customer and created on the defined chassis slot. The defined slot must already have been pre-provisioned on the system but need not be installed when the customer site assignment is made.
Values
ingress
Syntax
ingress
Context
config>service>customer>multi-service-site
Description
This command enables the context to configure the ingress node associate an existing scheduler policy name with the customer site. The ingress node is an entity to associate commands that complement the association.
egress
Syntax
egress
Context
config>service>customer>multi-service-site
Description
This command enables the context to configure the egress node associate an existing scheduler policy name with the customer site. The egress node is an entity to associate commands that complement the association.
agg-rate
Syntax
[no] agg-rate
Context
config>service>customer>multi-service-site>egress
Description
This command is used to control an HQoS aggregate rate limit. It is used in conjunction with the following parameter commands: rate, limit-unused-bandwidth, and queue-frame-based-accounting.
rate
Syntax
rate {max | rate}
no rate
Context
config>service>customer>multi-service-site>egress>agg-rate
Description
This command defines the enforced aggregate rate for all queues associated with the agg-rate context. A rate must be specified for the agg-rate context to be considered to be active on the context’s object (SAP, subscriber, VPORT etc.).
limit-unused-bandwidth
Syntax
[no] limit-unused-bandwidth
Context
config>service>customer>multi-service-site>egress>agg-rate
Description
This command is used to enable (or disable) aggregate rate overrun protection on the agg-rate context.
queue-frame-based-accounting
Syntax
[no] queue-frame-based-accounting
Context
config>service>customer>multi-service-site>egress>agg-rate
Description
This command is used to enabled (or disable) frame based accounting on all queues associated with the agg-rate context. Only supported on Ethernet ports. Not supported on HSMDA Ethernet ports.
scheduler-override
Syntax
[no] scheduler-override
Context
config>service>customer>multi-service-site>ingress
config>service>customer>multi-service-site>egress
Description
This command specifies the set of attributes whose values have been overridden by management on this virtual scheduler. Clearing a given flag will return the corresponding overridden attribute to the value defined on the SAP's ingress and egress scheduler policy.
scheduler
Syntax
[no] scheduler scheduler-name
Context
config>service>customer>multi-service-site>ingress>sched-override
config>service>customer>multi-service-site>egress>sched-override
Description
This command can be used to override specific attributes of the specified scheduler name.
A scheduler defines bandwidth controls that limit each child (other schedulers and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have queues or other schedulers defined as child associations. The scheduler can be a child (take bandwidth from a scheduler in a higher tier, except for schedulers created in tier 1). A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers.
Each scheduler must have a unique name within the context of the scheduler policy; however the same name can be reused in multiple scheduler policies. If scheduler-name already exists within the policy tier level (regardless of the inclusion of the keyword create), the context changes to that scheduler name for the purpose of editing the scheduler parameters. Modifications made to an existing scheduler are executed on all instantiated schedulers created through association with the policy of the edited scheduler. This can cause queues or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce service level agreements (SLAs).
If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of the keyword create), an error occurs and the current CLI context will not change.
If the scheduler-name does not exist in this or another tier within the scheduler policy, it is assumed that an attempt is being made to create a scheduler of that name. The success of the command execution is dependent on the following:
1.
2.
The provided scheduler-name is valid.
3.
The create keyword is entered with the command if the system is configured to require it (enabled in the environment create command).
When the maximum number of schedulers has been exceeded on the policy, a configuration error occurs and the command will not execute, nor will the CLI context change.
If the provided scheduler-name is invalid according to the criteria below, a name syntax error will occur, the command will not execute, and the CLI context will not change.
Parameters
scheduler-name
The name of the scheduler.
Values
Default
None. Each scheduler must be explicitly created.
create
This optional keyword explicitly specifies that it is acceptable to create a scheduler with the given scheduler-name. If the create keyword is omitted, scheduler-name is not created when the system environment variable create is set to true. This safeguard is meant to avoid accidental creation of system objects (such as schedulers) while attempting to edit an object with a mistyped name or ID. The keyword has no effect when the object already exists.
parent
Syntax
parent [weight weight] [cir-weight cir-weight]
no parent
Context
config>service>customer>multi-service-site>ingress>sched-override>scheduler
config>service>customer>multi-service-site>egress>sched-override>scheduler
Description
This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy – this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non default weightings for fostered schedulers.
The no form of the command returns the scheduler’s parent weight and cir-weight to the value configured in the applied scheduler policy.
Default
no parent
Parameters
weight weight
Weight defines the relative weight of this scheduler in comparison to other child schedulers and queues at the same strict level defined by the level parameter in the applied scheduler olicy. Within the level, all weight values from active children at that level are summed and the ratio of each active child’s weight to the total is used to distribute the available bandwidth at that level. A weight is considered to be active when the queue or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit.
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
Values
Default
cir-weight cir-weight
The cir-weight keyword defines the relative weight of this scheduler in comparison to other child schedulers and queues at the same cir-level defined by the cir-level parameter in the applied scheduler policy. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child’s cir-weight to the total is used to distribute the available bandwidth at that level. A cir-weight is considered to be active when the queue or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
Values
Default
rate
Syntax
rate pir-rate [cir cir-rate]
no rate
Context
config>service>customer>multi-service-site>ingress>sched-override>scheduler
config>service>customer>multi-service-site>egress>sched-override>scheduler
Description
This command can be used to override specific attributes of the specified scheduler rate.
The rate command defines the maximum bandwidth that the scheduler can offer its child queues or schedulers. The maximum rate is limited to the amount of bandwidth the scheduler can receive from its parent scheduler. If the scheduler has no parent, the maximum rate is assumed to be the amount available to the scheduler. When a parent is associated with the scheduler, the CIR parameter provides the scheduler’s amount of bandwidth to be considered during the parent schedulers ‘within CIR’ distribution phase.
The actual operating rate of the scheduler is limited by bandwidth constraints other than its maximum rate. The scheduler’s parent scheduler may not have the available bandwidth to meet the scheduler’s needs or the bandwidth available to the parent scheduler could be allocated to other child schedulers or child queues on the parent based on higher priority. The children of the scheduler may not need the maximum rate available to the scheduler due to insufficient offered load or limits to their own maximum rates.
When a scheduler is defined without specifying a rate, the default rate is max. If the scheduler is a root scheduler (no parent defined), the default maximum rate must be changed to an explicit value. Without this explicit value, the scheduler will assume that an infinite amount of bandwidth is available and allow all child queues and schedulers to operate at their maximum rates.
The no form of this command returns all queues created with this queue-id by association with the QoS policy to the default PIR and CIR parameters.
Parameters
pir-rate
The pir parameter accepts a step multiplier value that specifies the multiplier used to determine the PIR rate at which the queue will operate. A value of 0 to 100000000 or the keyword max or sum is accepted. Any other value will result in an error without modifying the current PIR rate.
To calculate the actual PIR rate, the rate described by the queue’s rate is multiplied by the pir-rate.
The SAP ingress context for PIR is independent of the defined forwarding class (fc) for the queue. The default pir and definable range is identical for each class. The PIR in effect for a queue defines the maximum rate at which the queue will be allowed to forward packets in a given second, thus shaping the queue’s output.
The PIR parameter for SAP ingress queues do not have a negate (no) function. To return the queues PIR rate to the default value, that value must be specified as the PIR value.
Values
Default
cir cir-rate
The cir parameter accepts a step-multiplier value that specifies the multiplier used to determine the CIR rate at which the queue will operate. A value of 0 to 100000000 or the keyword max or sum are accepted. Any other value will result in an error without modifying the current CIR rate.
To calculate the actual CIR rate, the rate described by the rate pir pir-rate is multiplied by the cir cir-rate. If the cir is set to max, then the CIR rate is set to infinity.
The SAP ingress context for CIR is dependent on the defined forwarding class (fc) for the queue. The default CIR and definable range is different for each class. The CIR in effect for a queue defines both its profile (in or out) marking level as well as the relative importance compared to other queues for scheduling purposes during congestion periods.
Values
Default
scheduler-policy
Syntax
scheduler-policy scheduler-policy-name
no scheduler-policy
Context
config>service>customer>multi-service-site>ingress
config>service>customer>multi-service-site>egress
Description
This command applies an existing scheduler policy to an ingress or egress scheduler used by SAP queues associated with this multi-service customer site. The schedulers defined in the scheduler policy can only be created once the customer site has been appropriately assigned to a chassis port, channel or slot. Scheduler policies are defined in the config>qos>scheduler-policy scheduler-policy-name context.
The no form of this command removes the configured ingress or egress scheduler policy from the multi-service customer site. When the policy is removed, the schedulers created due to the policy are removed also making them unavailable for the ingress SAP queues associated with the customer site. Queues that lose their parent scheduler association are deemed to be orphaned and are no longer subject to a virtual scheduler.
The SAPs that have ingress queues reliant on the removed schedulers enter into an operational state depicting the orphaned status of one or more queues. When the no scheduler-policy command is executed, the customer site ingress or egress node will not contain an applied scheduler policy.
scheduler-policy-name:
The scheduler-policy-name parameter applies an existing scheduler policy that was created in the config>qos>scheduler-policy scheduler-policy-name context to create the hierarchy of ingress or egress virtual schedulers. The scheduler names defined within the policy are created and made available to any ingress or egress queues created on associated SAPs.
Values
tod-suite
Syntax
tod-suite tod-suite-name
no tod-suite
Context
config>service>cust>multi-service-site
Description
This command applies a time-based policy (filter or QoS policy) to the multiservice site. The suite name must already exist in the config>system>cron context.
Default
no tod-suite
Parameters
tod-suite-name
Specifies collection of policies (ACLs, QoS) including time-ranges. Only the scheduler-policy part of the tod-suite is taken into account. The suite can be applied to more than one multi-service-site.
policer-control-policy
Syntax
policer-control-policy policy-name [create]
no policer-control-policy
Context
config>service>customer>multi-service-site>egress
config>service>customer>multi-service-site>ingress
Description
This command, within the QoS CLI node, is used to create, delete or modify policer control policies. A policer control policy is very similar to the scheduler-policy which is used to manage a set of queues by defining a hierarchy of virtual schedulers and specifying how the virtual schedulers interact to provide an aggregate SLA. In a similar fashion, the policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs.
Policer Control Policy Instances
On the SAP side, an instance of a policy is created each time a policy is applied. When applied to a sub-profile, an instance of the policy is created each time a subscriber successfully maps one or more hosts to the profile per ingress SAP.
Each instance of the policer-control-policy manages the policers associated with the object that owns the policy instance (SAP or subscriber). If a policer on the object is parented to an appropriate arbiter name that exists within the policy, the policer will be managed by the instance. If a policer is not parented or is parented to a non-existent arbiter, the policer will be orphaned and will not be subject to bandwidth control by the policy instance.
Maximum Rate and Root Arbiter
The policer-control-policy supports an overall maximum rate (max-rate) that defines the total amount of bandwidth that may be distributed to all associated child policers. By default, that rate is set to max which provides an unlimited amount of bandwidth to the policers. Once the policy is created, an actual rate should be configured in order for the policy instances to be effective. At the SAP level, the maximum rate may be overridden on a per instance basis. For subscribers, the maximum rate may only be overridden on the subscriber profile which will then be applied to all instances associated with the profile.
The maximum rate is defined within the context of the root arbiter which is always present in a policer-control-policy. The system creates a parent policer which polices the output of all child policers attached to the policy instance to the configured rate. Child policers may be parented directly to the root arbiter (parent root) or parented to one of the tiered arbiters (parent arbiter-name). Since each tiered arbiter must be parented to either another tiered arbiter or the root arbiter (default), every parented child policer is associated with the root arbiter and thus the root arbiter’s parent policer.
Parent Policer PIR Leaky Bucket Operation
The parent policer is a single leaky bucket that monitors the aggregate throughput rate of the associated child policers. Forwarded packets increment the bucket by the size of each packet. The rate of the parent policer is implemented as a bucket decrement function which attempts to drain the bucket. If the rate of the packets flowing through the bucket is less than the decrement rate, the bucket does not accumulate depth. Each packet that flows through the bucket is accompanied by a derived discard threshold. If the current depth of the bucket is less than the discard threshold, the packet is allowed to pass through, retaining the colors derived from the packet’s child policer. If the current depth is equal to or greater than the threshold value, the packet is colored red and the bucket depth is not incremented by the packet size. Also, any increased bucket depths in the child policer are canceled making any discard event an atomic function between the child and the parent.
Due to the fact that multiple thresholds are supported by the parent policer, the policer control policy is able to protect the throughput of higher priority child policers from the throughput of the lower priority child policers within the aggregate rate.
Tier 1 and Tier 2 Arbiters
As stated above, each child is attached either to the always available root arbiter or to an explicitly created tier 1 or tier 2 arbiter. Unlike the hardware parent policer based root arbiter, the arbiters at tier 1 and tier 2 are only represented in software and are meant to provide an arbitrary hierarchical bandwidth distribution capability. An arbiter created on tier 2 must parent to either to an arbiter on tier 1 or to the root arbiter. Arbiters created on tier 1 always parent to the root arbiter. In this manner, every arbiter ultimately is parented or grand-parented by the root arbiter.
Each tiered arbiter supports an optional rate parameter that defines a rate limit for all child arbiters or child policers associated with the arbiter. Child arbiters and policers attached to the arbiter have a level attribute that defines the strict level at which the child is given bandwidth by the arbiter. Level 8 is the highest and 1 is the lowest. Also a weight attribute defines each child’s weight at that strict level in order to determine how bandwidth is distributed to multiple children at that level when insufficient bandwidth is available to meet each child’s required bandwidth.
Fair and Unfair Bandwidth Control
Each child policer supports three leaky buckets. The PIR bucket manages the policer’s peak rate and maximum burst size, the CIR leaky bucket manages the policer’s committed rate (in-profile / out-of-profile) and committed burst size. The third leaky bucket is used by the policer control policy instance to manage the child policer’s fair rate (FIR). When multiple child policers are attached to the root arbiter at the same priority level, the policy instance uses each child’s FIR bucket rate to control how much of the traffic forwarded by the policer is fair and how much is unfair.
In the simplest case where all the child policers in the same priority level are directly attached to the root arbiter, each child’s FIR rate is set according to the child’s weight divided by the sum of the active children’s weights multiplied by the available bandwidth at the priority level. The result is that the FIR bucket will mark the appropriate amount of traffic for each child as fair based on the weighted fair output of the policy instance.
The fair/unfair forwarding control in the root parent policer is accomplished by implementing two different discard thresholds for the priority. The first threshold is discard-unfair and the second is discard-all for packet associated with the priority level. As the parent policer PIR bucket fills (due the aggregate forwarded rate being greater than the parent policers PIR decrement rate) and the bucket depth reaches the first threshold, all unfair packets within the priority are discarded. This leaves room in the bucket for the fair packets to be forwarded.
In the more complex case where one or more tiered arbiters are attached at the priority level, the policer control policy instance must consider more than just the child policer weights associated with the attached arbiter. If the arbiter is configured with an aggregate rate limit that its children cannot exceed, the policer control policy instance will switch to calculating the rate each child serviced by the arbiter should receive and enforces that rate using each child policers PIR leaky bucket.
When the child policer PIR leaky bucket is used to limit the bandwidth for the child policer and the child’s PIR bucket discard threshold is reached, packets associated with the child policer are discarded. The child policer’s discarded packets do not consume depth in the child policer’s CIR or FIR buckets. The child policers discarded packets are also prevented from impacting the parent policer and will not consume the aggregate bandwidth managed by the parent policer.
Parent Policer Priority Level Thresholds
As stated above, each child policer is attached either to the root arbiter or explicitly to one of the tier 1 or tier 2 arbiters. When attached directly to the root arbiter, its priority relative to all other child policers is indicated by the parenting level parameter. When attached through one of the tiered arbiters, the parenting hierarchy of the arbiters must be traced through to the ultimate attachment to the root arbiter. The parenting level parameter of the arbiter parented to the root arbiter defines the child policer’s priority level within the parent policer.
The priority level is important since it defines the parent policer discard thresholds that will be applied at the parent policer. The parent policer has 8 levels of strict priority and each priority level has its own discard-unfairand discard-all thresholds. Each priority’s thresholds are larger than the thresholds of the lower priority levels. This ensures that when the parent policer is discarding, it will be priority sensitive.
To visualize the behavior of the parent policer, picture that when the aggregate forwarding rate of all child policers is currently above the decrement rate of the parent PIR leaky bucket, the bucket depth will increase over time. As the bucket depth increases, it will eventually cross the lowest priority’s discard-unfair threshold. If this amount of discard sufficiently lowers the remaining aggregate child policer rate, the parent PIR bucket will hover around this bucket depth. If however, the remaining aggregate child rate is still greater than the decrement rate, the bucket will continue to rise and eventually reach the lowest priority’s discard-all threshold which will cause all packets associated with the priority level to be discarded (fair and unfair). Again, if the remaining aggregate child rate is less than or equal to the bucket decrement rate, the parent PIR bucket will hover around this higher bucket depth. If the remaining aggregate child rate is still higher than the decrement rate, the bucket will continue to rise through the remaining priority level discards until equilibrium is achieved.
As noted above, each child’s rate feeding into the parent policer is governed by the child policer’s PIR bucket decrement rate. The amount of bandwidth the child policer offers to the parent policer will not exceed the child policer’s configured maximum rate.
Root Arbiter’s Parent Policer’s Priority Aggregate Thresholds
Each policer-control-policy root arbiter supports configurable aggregate priority thresholds which are used to control burst tolerance within each priority level. Two values are maintained per priority level; the shared-portion and the fair-portion. The shared-portion represents the amount of parent PIR bucket depth that is allowed to be consumed by both fair and unfair child packets at the priority level. The fair-portion represents the amount of parent PIR bucket depth that only the fair child policer packets may consume within the priority level. It should be noted that the fair and unfair child packets associated with a higher parent policer priority level may also consume the bucket depth set aside for this priority.
While the policy maintains a parent policer default or explicit configurable values for shared-portion and fair-portion within each priority level, it is possible that some priority levels will not be used within the parent policer. Most parent policer use cases require fewer than eight strict priority levels.
In order to derive the actual priority level discard-unfair and discard-all thresholds while only accounting for the actual in-use priority levels, the system maintains a child policer to parent policer association counter per priority level for each policer control policy instance. As a child policer is parented to either the root or a tiered arbiter, the system determines the parent policer priority level for the child policer and increments the association counter for that priority level on the parent policer instance.
The shared-portion for each priority level is affected by the parent policer global min-thresh-separation parameter that defines the minimum separation between any in-use discard thresholds. When more than one child policer is associated with a parent policer priority level, the shared-portion for that priority level will be the current value of min-thresh-separation. When only a single child policer is associated, the priority level’s shared-portion is zero since all packets from the child will be marked fair and the discard-unfair threshold is meaningless. When the association counter is zero, both the shared-portion and the fair-portion for that priority level are zero since neither discard thresholds will be used. Whenever the association counter is greater than 0, the fair-portion for that priority level will be derived from the current value of the priority’s mbs-contribution parameter and the global min-thresh-separation parameter.
Each priority level’s discard-unfair and discard-alld thresholds are calculated based on an accumulation of lower priorities shared-portions and fair-portions and the priority level’s own shared-portion and fair-portion. The base threshold value for each priority level is equal to the sum of all lower priority level’s shared-portions and fair-portions. The discard-unfair threshold is the priority level’s base threshold plus the priority level’s shared-portion. The discard-all threshold for the priority level is the priority level’s base threshold plus both the shared-portion and fair-portion values of the priority. As can be seen, an in-use priority level’s thresholds are always greater than the thresholds of lower priority levels.
Policer Control Policy Application
A policer-control-policy may be applied on any Ethernet ingress or egress SAP that is associated with a port (or ports in the case of LAG).
The no form of the command removes a non-associated policer control policy from the system. The command will not execute when policer-name is currently associated with any SAP context.
Default
none
Parameters
policy-name
Each policer-control-policy must be created with a unique policy name. The name must given as policy-name must adhere to the system policy ASCII naming requirements. If the defined policy-name already exists, the system will enter that policy’s context for editing purposes. If policy-name does not exist, the system will attempt to create a policy with the specified name. Creating a policy may require use of the create parameter when the system is configured for explicit object creation mode.
create
This keyword is required when a new policy is being created and the system is configured for explicit object creation mode.
 
Service System Commands
bgp-auto-rd-range
Syntax
bgp-auto-rd-range ip-address comm-val comm-val to comm-val
no bgp-auto-rd-range
Context
config>service>system
Description
This command defines the type-1 route-distinguisher ipv4 address and community value range within which the system will select a route-distinguisher for the bgp-enabled services using auto-rd.
Default
no bgp-auto-rd-range
Parameters
ip-address
Specifies the IPv4 address used in the first 4 octets of all the type-1 auto route-distinguishers selected by the system.
comm-val
Specifies the community value of the type-1 auto route-distinguisher.
Values
Interactions: This command is used along with the route-distinguisher auto-rd command supported in VPLS, VPRN and Epipe services. The system forces the user to create a bgp-auto-range before the auto-rd option can be used in the services.
Note that the system will keep allocating values for services configured with route-distinguisher auto-rd as long as there are available community values within the configured range. Once the command is added, the following changes are allowed:
The ip-address can be changed without changing the comm-val range, even if there are services using auto-rd. The affected routes will be withdrawn and re-advertised with the new route-distinguishers.
The comm-val range can be modified as long as there are not existing conflicting values in the new range. For instance, the user may expand the range as long as the new range does not overlap with existing manual route-distinguishers. The user may also reduce the range as long as the new range can accommodate the already allocated auto-RDs.
 
MRP Commands
mrp
Syntax
mrp
Context
config>service
Description
This command configures a Multi-service Route Processor (MRP).
mrp-policy
Syntax
[no] mrp-policy policy-name
Context
config>service>mrp
Description
This command enables the context for a MRP policy. The mrp-policy specifies either a forward or a drop action for the Group BMAC attributes associated with the ISIDs specified in the match criteria. The mrp-policy can be applied to multiple BVPLS services as long as the scope of the policy is template.
Any changes made to the existing policy, using any of the sub-commands, will be applied immediately to all services where this policy is applied. For this reason, when many changes are required on a mrp-policy, it is recommended that the policy be copied to a work area. That work-in-progress policy can be modified until complete and then written over the original mrp-policy. Use the config mrp-policy copy command to maintain policies in this manner.
The no form of the command deletes the mrp-policy. An MRP policy cannot be deleted until it is removed from all the SAPs or SDPs where it is applied.
Default
no mrp-policy is defined
Parameters
policy-name
Specifies the redirect policy name. Allowed values are any string up to 32 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, etc.), the entire string must be enclosed within double quotes.
create
This keyword is required when first creating the configuration context. Once the context is created, it is possible to navigate into the context without the create keyword.
scope
Syntax
scope {exclusive | template}
no scope
Context
config>service>mrp>mrp-policy
Description
This command configures the filter policy scope as exclusive or template. If the scope of the policy is template and is applied to one or more services, the scope cannot be changed.
The no form of the command sets the scope of the policy to the default of template.
Default
template
Parameters
exclusive
When the scope of a policy is defined as exclusive, the policy can only be applied to a single entity (SAP or SDP). Attempting to assign the policy to a second entity will result in an error message. If the policy is removed from the entity, it will become available for assignment to another entity.
template
When the scope of a policy is defined as template, the policy can be applied to multiple SAPs or network ports.
default-action
Syntax
default-action {block | allow}
Context
config>service>mrp>mrp-policy
Description
This command specifies the action to be applied to the MMRP attributes (Group BMACs) whose ISIDs do not match the specified criteria in all of the entries of the mrp-policy.
When multiple default-action commands are entered, the last command will overwrite the previous command.
Default
default-action-allow
Parameters
block
Specifies that all MMRP attributes will not be declared or registered unless there is a specific mrp-policy entry which causes them to be allowed on this SAP/SDP.
allow
Specifies that all MMRP attributes will be declared and registered unless there is a specific mrp-policy entry which causes them to be blocked on this SAP/SDP.
entry
Syntax
[no] entry entry-id
Context
config>service>mrp>mrp-policy
Description
This command creates or edits an mrp-policy entry. Multiple entries can be created using unique entry-id numbers within the policy. The implementation exits the policy on the first match found and executes the actions in accordance with the accompanying action command. For this reason, entries must be sequenced correctly from most to least explicit. An entry may not have any match criteria defined (in which case, everything matches) but must have at least the keyword action for it to be considered complete. Entries without the action keyword will be considered incomplete and hence will be rendered inactive.
The no form of the command removes the specified entry from the mrp-policy. Entries removed from the mrp-policy are immediately removed from all services where the policy is applied.
The no form of the command removes the specified entry-id.
Default
none
Parameters
entry-id
An entry-id uniquely identifies a match criteria and the corresponding action. It is recommended that multiple entries be given entry-ids in staggered increments. This allows users to insert a new entry in an existing policy without requiring renumbering of all the existing entries.
Values
create
Keyword; required when first creating the configuration context. Once the context is created, one can navigate into the context without the create keyword.
match
Syntax
[no] match
Context
config>service>mrp>mrp-policy>entry
Description
This command creates the context for entering/editing match criteria for the mrp-policy entry. When the match criteria have been satisfied the action associated with the match criteria is executed. In the current implementation just one match criteria (ISID based) is possible in the entry associated with the mrp-policy. Only one match statement can be entered per entry.
The no form of the command removes the match criteria for the entry-id.
isid
Syntax
[no] isid value | from value to higher-value
Context
config>service>mrp>mrp-policy>entry>match
Description
This command configures an ISID value or a range of ISID values to be matched by the mrp-policy parent when looking at the related MMRP attributes (Group BMACs). The pbb-etype value for the related SAP (inherited from the ethernet port configuration) or for the related SDP binding (inherited from SDP configuration) will be used to identify the ISID tag.
Multiple isid statements are allowed under a match node. The following rules govern the usage of multiple isid statements:
The no form of the command can be used in two ways:
no isid - removes all the previous statements under one match node
no isid value | from value to higher-value - removes a specific ISID value or range. Must match a previously used positive statement: for example if the command “isid 16 to 100” was used using “no isid 16 to 50” will not work but “no isid 16 to 100 will be successful.
Default
no isid
Parameters
value or higher-value
Specifies the ISID value in 24 bits. When just one present identifies a particular ISID to be used for matching.
Values
from value to higher-value
Identifies a range of ISIDs to be used as matching criteria.
action
Syntax
action {block | allow | end-station}
no action
Context
config>service>mrp>mrp-policy>entry
Description
This command specifies the action to be applied to the MMRP attributes (Group BMACs) whose ISIDs match the specified ISID criteria in the related entry.
The action keyword must be entered for the entry to be active. Any filter entry without the action keyword will be considered incomplete and will be inactive. If neither keyword is specified (no action is used), this is considered a No-Op policy entry used to explicitly set an entry inactive without modifying match criteria or removing the entry itself. Multiple action statements entered will overwrite previous actions parameters when defined. To remove a parameter, use the no form of the action command with the specified parameter.
The no form of the command removes the specified action statement. The entry is considered incomplete and hence rendered inactive without the action keyword.
Default
no action
Parameters
block
Specifies that the matching MMRP attributes will not be declared or registered on this SAP/SDP.
allow
Specifies that the matching MMRP attributes will be declared and registered on this SAP/SDP.
end-station
Specifies that an end-station emulation is present on this SAP/SDP for the MMRP attributes related with matching ISIDs. Equivalent action with the block keyword on that SAP/SDP– the attributes associated with the matching ISIDs do not get declared or registered on the SAP/SDP. The matching attributes on the other hand are mapped as static MMRP entries on the SAP/SDP which implicitly instantiates in the data plane as a MFIB entry associated with that SAP/SDP for the related Group BMAC. For the other SAPs/SDPs in the BVPLS with MRP enabled (no shutdown) this means permanent declaration of the matching attributes, same as in the case when the IVPLS instances associated with these ISIDs were locally configured.
If an mrp-policy has end-station action in one entry, the only default action allowed in the policy is block. Also no other actions are allowed to be configured in other entry configured under the policy.
This policy will apply even if the MRP is shutdown on the local SAP/SDP or for the whole BVPLS to allow for manual creation of MMRP entries in the data plane. Specifically the following rules apply:
copy
Syntax
copy mrp-policy source-name to dest-name
Context
config>service>mrp
Description
This command copies existing mrp-policy list entries for a specific policy name to another policy name. The copy command is a configuration level maintenance tool used to create new mrp-policy using existing mrp-policy.
An error will occur if the destination policy name exists.
Parameters
mrp-policy
Indicates that source-name and dest-name are MRP policy names.
source-name
Identifies the source mrp-policy from which the copy command will attempt to copy. The mrp-policy with this name must exist for the command to be successful.
dest-name
Identifies the destination mrp-policy to which the copy command will attempt to copy. If the mrp-policy with dest-name exist within the system an error message is generated.
renum
Syntax
renum old-entry-id to new-entry-id
Context
config>service>mrp>mrp-policy
Description
This command renumbers existing MRP policy entries to properly sequence policy entries. This may be required in some cases since the implementation exits when the first match is found and executes the actions according to the accompanying action command. This requires that entries be sequenced correctly from most to least explicit.
Parameters
old-entry-id
Specifies the entry number of an existing entry.
Values
new-entry-id
Specifies the new entry number to be assigned to the old entry. If the new entry exists, an error message is generated.
 
Oper Group Commands
oper-group
Syntax
oper-group group-name [create]
no oper-group group-name
Context
config>service
Description
This command creates a system-wide group name which can be used to associate a number of service objects (for example, SAPs or pseudowires). The status of the group is derived from the status of its members. The status of the group can then be used to influence the status of non-member objects. FOr example, when a group status i marked as down, the object(s) that monitor the group change their status accordingly.
The no form of the command removes thegroup. All the object associations need to be removed before the no command can be executed.
no oper-group
Parameters
group-name
specifies the operational group identifier up to 32 characters in length.
create
This keyword is required when first creating the configuration context. Once the context is created, it is possible to navigate into the context without the create keyword.
bfd-enable
Syntax
bfd-enable interface interface-name dst-ip ip-address [service service-id]
no bfd-enable
Context
config>service>oper-group
Description
This command associates a BFD sessions with the named oper-group so that if the BFD session fails then the oper-group is changed to operationally down and all monitoring interfaces should also be brought operationally down.
Default
None
Parameters
interface
Specifies the source interface for the BFD sessions to be monitored for the associated oper-group.
dst-ip
Specifies the destination IP address for the BFD sessions to be monitored for the associated oper-group.
service
Specifies the service context in which the BFD session exists if it is not in the base routing context.
hold-time
Syntax
hold-time
Context
config>service>oper-group
Description
This command enables the context to configure hold time information.
group up
Syntax
group up time | no group up
Context
config>service>oper-group>hold-time
Description
This command configures the number of seconds to wait before notifying clients monitoring this group when its operational status transitions from down to up. A value of zero indicates that transitions are reported immediately to monitoring clients. The up time option is a must to achieve fast convergence: when the group comes up, the monitoring MH site which tracks the group status may wait without impacting the overall convergence; there is usually a pair MH site that is already handling the traffic.
The no form sets the values back to the defaults.
Default
4
Parameters
time
Specifies the group up time value.
Values
group down
Syntax
group down time | no group down
Context
config>service>oper-group>hold-time
Description
This command configures the number of seconds to wait before notifying clients monitoring this group when its operational status transitions from up to down.
The no form sets the values back to the default.
 
Pseudowire Commands
pw-routing
Syntax
pw-routing
Context
config>service
Description
This command enables the context to configure dynamic multi-segment pseudowire (MS-PW) routing. Pseudowire routing must be configured on each node that will be a T-PE or an S-PE.
Default
disabled
block-on-peer-fault
Syntax
[no] block-on-peer-fault
Context
config>service>pw-template
Description
When enabled, this command blocks the transmit direction of a pseudowire when any of the following pseudowire status codes is received from the far end PE:
0x00000001 Pseudowire Not Forwarding
0x00000002 Local Attachment Circuit (ingress) Receive Fault
0x00000004 Local Attachment Circuit (egress) Transmit Fault
0x00000008 Local PSN-facing PW (ingress) Receive Fault
0x00000010 Local PSN-facing PW (egress) Transmit Fault
The transmit direction is unblocked when the following pseudowire status code is received:
0x00000000 Pseudowire forwarding (clear all failures)
This command is mutually exclusive with no pw-status-signaling, and standby-signaling-slave. It is not applicable to spoke SDPs forming part of an MC-LAG or spoke SDPs in an endpoint.
Default
no block-on-peer-fault
boot-timer
Syntax
boot-timer secs
no boot-timer
Context
config>service>pw-routing
Description
This command configures a hold-off timer for MS-PW routing advertisements and signaling and is used at boot time.
The no form of this command removes a previously configured timer and restores it to its default.
Default
10
Parameters
timer-value
The value of the boot timer in seconds.
Values
local-prefix
Syntax
local-prefix local-prefix [create]
no local-prefixlocal-prefix
Context
config>service>pw-routing
Description
This command configures one or more node prefix values to be used for MS-PW routing. At least one prefix must be configured on each node that is an S-PE or a T-PE.
The no form of this command removes a previously configured prefix, and will cause the corresponding route to be withdrawn if it has been advertised in BGP.
Default
no local-prefix.
Parameters
local-prefix
Specifies a 32 bit prefix for the AII. One or more prefix values, up to a maximum of 16 may be assigned to the 7x50 node. The global ID can contain the 2-octet or 4-octet value of the provider's Autonomous System Number (ASN). The presence of a global ID based on the provider's ASN ensures that the AII for spoke-SDPs configured on the node will be globally unique.
Values
advertise-bgp
Syntax
advertise-bgp route-distinguisher rd [community community]
no advertise-bgp route-distinguisher rd
Context
config>service>pw-routing
Description
This command enables a given prefix to be advertised in MP-BGP for dynamic MS-PW routing.
The no form of this command will explicitly woithdraw a route if it has been previously advertised.
Default
no advertise-bgp.
Parameters
rd
Specifies an 8-octet route distinguisher associated with the prefix. Up to 4 unique route distinguishers can be configured and advertised for a given prefix though multiple instances of the advertise-bgp command. This parameter is mandatory.
Values
community community
An optional BGP communities attribute associated with the advertisement. To delete a previously advertised community, advertise-bgp route-distinguisher must be run again with the same value for the RD but excluding the community attribute.
Values
community {2-byte-as-number:comm-va1}
2-byte-asnumber 0— 65535
comm.-val 0 — 65535
path
Syntax
path name [create]
no path name
Context
config>service>pw-routing
Description
This command configures an explicit path between this 7x50 T-PE and a remote 7x50 T-PE. For each path, one or more intermediate S-PE hops must be configured. A path can be used by multiple multi-segment pseudowires. Paths are used by a 7x50 T-PE to populate the list of Explicit Route TLVs included in the signaling of a dynamic MS-PW.
A path may specify all or only some of the hops along the route to reach a T-PE.
The no form of the command removes a specified explicit path from the configuration.
Default
no path
Parameters
path-name
Specifies a locally-unique case-sensitive alphanumeric name label for the MS-PW path of up to 32 characters in length.
hop
Syntax
hop hop-index ip-address
no hop hop-index
Context
config>service>pw-routing>hop
Description
This command configures each hop on an explicit path that can be used by one or more dynamic MS-PWs. It specifies the IP addresses of the hops that the MS-PE should traverse. These IP addresses can correspond to the system IP address of each S-PE, or the IP address on which the T-LDP session to a given S-PE terminates.
The no form of this command deletes hop list entries for the path. All the MS-PWs currently using this path are unaffected. Additionally, all services actively using these MS-PWs are unaffected. The path must be shutdown first in order to delete the hop from the hop list. The ‘no hop hop-index’ command will not result in any action, except for a warning message on the console indicating that the path is administratively up.
Default
no hop
Parameters
hop-index
Specifies a locally significant numeric identifier for the hop. The hop index is used to order the hops specified. The LSP always traverses from the lowest hop index to the highest. The hop index does not need to be sequential.
Values
ip-address
Specifies the system IP address or terminating IP address for the T-LDP session to the S-PE corresponding to this hop. For a given IP address on a hop, the system will choose the appropriate SDP to use.
retry-count
Syntax
retry-count [10..10000]
no retry-count
Context
config>service>pw-routing
Description
This optional command specifies the number of attempts software should make to re-establish the spoke-SDP after it has failed. After each successful attempt, the counter is reset to zero.
When the specified number is reached, no more attempts are made and the spoke-sdp is put into the shutdown state.
Use the no shutdown command to bring up the path after the retry limit is exceeded.
The no form of this command reverts the parameter to the default value.
Default
30
Parameters
retry-count
Specifies the maximum number of retries before putting the spoke-sdp into the shutdown state.
Values
retry-timer
Syntax
retry-timer secs
no retry-timer
Context
config>service>pw-routing
Description
This command specifies a retry-timer for the spoke-SDP. This is a configurable exponential back-off timer that determines the interval between retries to re-establish a spoke-SDP if it fails and a label withdraw message is received with the status code “AII unreachable”.
The no form of this command reverts the timer to its default value.
Default
30
Parameters
retry-count
The initial retry-timer value in seconds.
Values
spe-address
Syntax
spe-address global-id:prefix
no spe-address
Context
config>service>pw-routing
Description
This command configures a single S-PE Address for the node to be used for dynamic MS-PWs. This value is used for the pseudowire switching point TLV used in LDP signaling, and is the value used by pseudowire status signaling to indicate the PE that originates a pseudowire status message. . Configuration of this parameter is mandatory to enable dynamic MS-PW support on a node.
If the S-PE Address is not configured, spoke-sdps that use dynamic MS-PWs and pw-routing local-prefixes cannot be configured on a T-PE. Furthermore, and 7x50 node will send a label release for any label mappings received for FEC129 AII type 2.
The S-PE Address cannot be changed unless the dynamic ms-pw configuration is removed. Furthermore, changing the S-PE Address will also result in all dynamic MS-PWs for which this node is an S-PE being released. It is recommended that the S-PE Address should be configured for the life of an MS-PW configuration after reboot of the 7x50.
The no form of this command removes the configured S-PE Address.
Default
no spe-address
Parameters
global-id
Specifies a 4-octet value that is unique to the service provider. For example, the global ID can contain the 2-octet or 4-octet value of the provider's Autonomous System Number (ASN).
Syntax: <global-id:prefix>: <global-id>:{<prefix>|<ipaddress>}
global-id 1 — 4294967295
prefix 1 — 4294967295
ipaddress a.b.c.d
static-route
Syntax
[no] static-route route-name
Context
config>service>pw-routing
Description
This command configures a static route to a next hop S-PE or T-PE. Static routes may be configured on either S-PEs or T-PEs.
A default static route is entered as follows:
static-route 0:0:next_hop_ip_addresss
or
static-route 0:0.0.0.0:next_hop_ip_address
The no form of this command removes a previously configured static route.
Default
no static-route
Parameters
route-name
Specifies the static pseudowire route.
Values
pw-template
Syntax
[no] pw-template sdp-template-id [use-provisioned-sdp] [create]
Context
config>service
Description
This command configures an SDP template.
Parameters
sdp-template-id
Specifies a number used to uniquely identify a template for the creation of a Service Distribution Point (SDP. The value 0 is used as the null ID.
Values
use-provisioned-sdp
Specifies whether to use an already provisioned SDP. When specified, the tunnel manager will be consulted for an existing active SDP. Otherwise, the default SDP template will be used to use for instantiation of the SDP.
create
This keyword is required when first creating the configuration context. Once the context is created, it is possible to navigate into the context without the create keyword.
 
 
SDP Commands
sdp
Syntax
sdp sdp-id [gre | mpls | l2tpv3] [create]
no sdp sdp-id
Context
config>service
Description
This command creates or edits a Service Distribution Point (SDP). SDPs must be explicitly configured.
An SDP is a logical mechanism that ties a far-end router to a particular service without having to specifically define far end SAPs. Each SDP represents a method to reach another router.
One method is IP Generic Router Encapsulation (GRE) which has no state in the core of the network. GRE does not specify a specific path to the far-end router. A GRE-based SDP uses the underlying IGP routing table to find the best next hop to the far-end router.
The second method is Multi-Protocol Label Switching (MPLS) encapsulation. A router supports both signaled and non-signaled Label Switched Paths (LSPs) through the network. Non-signaled paths are defined at each hop through the network. Signaled paths are communicated by protocol from end to end using Resource ReserVation Protocol (RSVP). Paths may be manually defined or a constraint-based routing protocol (such as OSPF-TE or CSPF) can be used to determine the best path with specific constraints. An LDP LSP can also be used for an SDP when the encapsulation is MPLS. The use of an LDP LSP type or an RSVP/Static LSP type are mutually exclusive except when the mixed-lsp option is enabled on the SDP.
Segment Routing (SR) is another MPLS tunnel type and is used to allow service binding to a SR tunnel programmed in TTM by OSPF or IS-IS. The SDP of type sr-isis or sr-ospf can be used with the far-end option. The tunnel-farend option is not supported. In addition, the mixed-lsp-mode option does not support the sr-isis and sr-isis tunnel types.
L2TPv3-over-IPv6 transport is also an option for Ethernet Pipe (EPIPE) services. Like GRE, L2TPv3 is stateless in the core of the network, as well as on the service nodes as the L2TPv3 control plane functionality is disabled for this SDP type. A unique source and destination IPv6 address combined with TX and RX Cookie values are used to ensure that the SDP is bound to the correct service.
SDPs are created and then bound to services. Many services may be bound to a single SDP. The operational and administrative state of the SDP controls the state of the SDP binding to the service.
If sdp-id does not exist, a new SDP is created. When creating an SDP, either the gre, mpls, or l2tpv3 keyword must be specified. SDPs are created in the admin down state (shutdown) and the no shutdown command must be executed once all relevant parameters are defined and before the SDP can be used.
If sdp-id exists, the current CLI context is changed to that SDP for editing and modification. For editing an existing SDP, neither the gre, mpls, or l2tpv3 keyword is specified. If a keyword is specified for an existing sdp-id, an error is generated and the context of the CLI will not be changed to the specified sdp-id.
The no form of this command deletes the specified SDP. Before an SDP can be deleted, it must be administratively down (shutdown) and not bound to any services. If the specified SDP is bound to a service, the no sdp command will fail generating an error message specifying the first bound service found during the deletion process. If the specified sdp-id does not exist an error will be generated.
Default
none
Parameters
sdp-id
The SDP identifier.
Values
gre
Specifies the SDP will use GRE to reach the far-end router. Only one GRE SDP can be created to a given destination device. Multiple GRE SDPs to a single destination serve no purpose as the path taken to reach the far end is determined by the IGP which will be the same for all SDPs to a given destination and there is no bandwidth reservation in GRE tunnels.
mpls
Specifies the SDP will use MPLS encapsulation and one or more LSP tunnels to reach the far-end device. Multiple MPLS SDPs may be created to a given destination device . Multiple MPLS SDPs to a single destination device are helpful when they use divergent paths.
l2tpv3
Specifies the SDP will use L2TPv3-over-IPv6 encapsulation. One SDP is created per service, regardless of whether the far-end node is common or not. Unique local and far-end addresses are configured for every L2TPv3 SDP type. The local address must exist on the local node.
auto-learn-mac-protect
Syntax
[no] auto-learn-mac-protect
Context
config>service>pw-template
config>service>pw-template>split-horizon-group
Description
This command specifies whether to enable automatic population of the MAC protect list with source MAC addresses learned on the associated with this SHG. For more information about auto-learn MAC protect, refer to the Layer 2 Services Guide.
The no form of the command disables the automatic population of the MAC protect list.
Default
auto-learn-mac-protect
accounting-policy
Syntax
accounting-policy acct-policy-id
no accounting-policy
Context
config>service>pw-template
config>service>sdp
Description
This command creates the accounting policy context that can be applied to an SDP. An accounting policy must be defined before it can be associated with a SDP. If the policy-id does not exist, an error message is generated.
A maximum of one accounting policy can be associated with a SDP 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 SDP, and the acccounting policy reverts to the default.
Default
Default accounting policy.
Parameters
acct-policy-id
Enter the accounting policy-id as configured in the config>log>accounting-policy context.
Values
allow-fragmentation
Syntax
[no] allow-fragmentation
Context
config>service>sdp
Description
This command disables the setting of the do-not-fragment bit in the IP header of GRE encapsulated service traffic. This feature is only applicable to GRE SDPs and will be applied to all service traffic using the associated GRE SDP.
The no form of this command removes the command from the active configuration and returns the associated SDP to its default which is to set the do-not-fragment bit in all GRE encapsulated service traffic.
Default
no allow-fragmentation
bgp-tunnel
Syntax
[no] bgp-tunnel
Context
config>service>sdp
Description
This command allows the use of BGP route tunnels available in the tunnel table to reach SDP far-end nodes. Use of BGP route tunnels are only available with MPLS-SDP. Only one of the transport methods is allowed per SDP - LDP, RSVP-LSP BGP, SR-ISIS, or SR-OSPF. This restriction is relaxed for some combinations of the transport methods when the mixed-lsp-mode option is enabled within the SDP.
The no form of the command disables resolving BGP route tunnel LSP for SDP far-end.
Default
no bgp-tunnel (BGP tunnel route to SDP far-end is disabled)
booking-factor
Syntax
booking-factor percentage
no booking-factor
Context
config>service>sdp
Description
This command specifies the booking factor applied against the maximum SDP available bandwidth by the VLL CAC feature.
The service manager keeps track of the available bandwidth for each SDP. The maximum value is the sum of the bandwidths of all constituent LSPs in the SDP. The SDP available bandwidth is adjusted by the user configured booking factor. A value of 0 means no VLL can be admitted into the SDP.
The no form of the command reverts to the default value.
Parameters
percentage
Specifies the percentage of the SDP maximum available bandwidth for VLL call admission. When the value of this parameter is set to zero (0), no new VLL spoke SDP bindings with non-zero bandwidth are permitted with this SDP. Overbooking, >100% is allowed.
Values
Default
100%
collect-stats
Syntax
[no] collect-stats
Context
config>service>pw-template
config>service>sdp
Description
This command enables accounting and statistical data collection for either the SDP. 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 IOM cards. 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.
Default
no collect-stats
controlword
Syntax
[no] controlword
Description
config>service>pw-template
Description
This command enables the use of the control word on pseudowire packets in VPLS and VPWS 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/VPWS 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 the command reverts the mesh SDP or spoke-sdp to the default behavior of not using the control word.
Default
no control word
disable-aging
Syntax
[no] disable-aging
Context
config>service>pw-template
Description
This command disables MAC address aging across a service.
The no form of this command enables aging.
Default
no disable-aging
disable-learning
Syntax
[no] disable-learning
Context
config>service>pw-template
Description
This command enables learning of new MAC addresses.
This parameter is mainly used in conjunction with the discard-unknown command.
The no form of this command enables learning of MAC addresses.
Default
no disable-learning (Normal MAC learning is enabled)
discard-unknown-source
Syntax
[no] discard-unknown-source
Context
config>service>pw-template
Description
When this command is enabled, packets received with an unknown source MAC address will be dropped only if the maximum number of MAC addresses have been reached.
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.
Default
no discard-unknown
egress
Syntax
egress
Context
config>service>pw-template
Description
This command enables the context to configure spoke SDP binding egress filter parameters.
ingress
Syntax
ingress
Context
config>service>pw-template
Description
This command enables the context to configure spoke SDP binding ingress filter parameters.
filter
Syntax
filter ip ip-filter-id
filter ipv6 ipv6-filter-id
filter mac mac-filter-id
no filter [ip ip-filter-id] [mac mac-filter-id] [ipv6 ipv6-filter-id]
Context
config>service>pw-template>egress
config>service>pw-template>ingress
Description
This command associates an IP filter policy or MAC filter policy on egress or ingress. Filter policies control the forwarding and dropping of packets based on IP or MAC matching criteria. There are two types of filter policies: IP and MAC. Only one type may be applied to a SAP at a time.
The filter command is used to associate a filter policy with a specified filter ID with an ingress or egress SAP. The filter ID must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message returned.
The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.
Parameters
ip ip-filter-id
Specifies IP filter policy. The filter ID must already exist within the created IP filters.
Values
ipv6 ipv6-filter-id
Specifies the IPv6 filter policy. The filter ID must already exist within the created IPv6 filters.
Values
mac mac-filter-id
Specifies the MAC filter policy. The specified filter ID must already exist within the created MAC filters. The filter policy must already exist within the created MAC filters.
Values
qos
Syntax
qos network-policy-id port-redirect-group queue-group-name [instance instance-id]
no qos [network-policy-id]
Context
configure>service>apipe>spoke-sdp>egress
configure>service>cpipe>spoke-sdp>egress
configure>service>epipe>spoke-sdp>egress
configure>service>fpipe>spoke-sdp>egress
configure>service>ipipe>spoke-sdp>egress
config>service>vpls>spoke-sdp>egress
config>service>vpls>mesh-sdp>egress
config>service>pw-template>egress
config>service>vprn>interface>spoke-sdp>egress
config>service>ies>interface>spoke-sdp>egress
Description
This command is used to redirect pseudowire packets to an egress port queue-group for the purpose of shaping.
The egress pseudowire shaping provisioning model allows the mapping of one ore more pseudowires to the same instance of queues, or policers and queues, which are defined in the queue-group template.
Operationally, the provisioning model consists of the following steps:
1.
2.
3.
4.
One or more spoke-SPDs can have their FCs redirected to use queues only or queues and policers in the same queue-group instance.
The following are the constraints and rules of this provisioning model:
1.
2.
3.
a
b When a pseudowire packet for that FC is forwarded and an instance of the referenced queue-group name does not exist on that egress port, the pseudowire packet will be fed directly to the corresponding egress shared queue for that FC defined in the network-queue policy applied to the egress of this port.
4.
When the queue-group name the pseudowire is redirected to exists and the redirection succeeds, the marking of the packet DEI/dot1.p/DSCP and the tunnel DEI/dot1.p/DSCP/EXP is performed; according to the relevant mappings of the (FC, profile) in the egress context of the network QoS policy applied to the pseudowire. This is true regardless, wether an instance of the queue-group exists or not on the egress port to which the pseudowire packet is forwarded. If the packet profile value changed due to egress child policer CIR profiling, the new profile value is used to mark the packet DEI/dot1.p and the tunnel DEI/dot1.p/EXP, but the DSCP is not modified by the policer operation.
When the queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the marking of the packet DEI/dot1.p/DSCP and the tunnel DEI/dot1.p/DSCP/EXP fields is performed according to the relevant commands in the egress context of the network QoS policy applied to the network IP interface to which the pseudowire packet is forwarded.
The no version of this command removes the redirection of the pseudowire to the queue-group.
Parameters
network-policy-id
Specifies the network policy identification. The value uniquely identifies the policy on the system.
Values
queue-redirect-group queue-group-name
This optional parameter specifies that the queue-group-name will be used for all egress forwarding class redirections within the network QoS policy ID. The specified queue-group-name must exist as a port egress queue group on the port associated with the IP interface.
egress-instance instance-id
Specifies the identification of a specific instance of the queue-group.
Values
hash-label
Syntax
hash-label [signal-capability]
no hash-label
Context
config>service>pw-template
Description
This command enables the use of the hash label on a VLL, VPRN or VPLS service bound to LDP or RSVP SDP as well as to a VPRN service using the autobind mode with the ldp, rsvp-te, or mpls options. This feature is not supported on a service bound to a GRE SDP or for a VPRN service using the autobind mode with the gre option. This feature 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. It is, however, supported when forwarding multicast packets using an IES/VPRN spoke-interface.
When this feature is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use as the value of the label field of the hash label. The egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).
In order 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 will always be in the range [524,288 - 1,048,575] and will 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.
The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG spraying of packets locally on the ingress LER. Note, however, that for VLL services, the result of the hash is overwritten and the ECMP and LAG spraying will be based on service-id when ingress SAP shared queuing is not enabled. However, the hash label will still reflect the result of the hash such that an LSR can use it to perform fine grained load balancing of VLL pseudowire packets.
Packets generated in CPM and that are forwarded labeled within the context of a service (for example, OAM packets) must also include a Hash Label at the BoS and set the S-bit accordingly.
The TTL of the hash label is set to a value of 0.
The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS spoke-sdp or mesh-sdp, or an IES/VPRN spoke 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 are the procedures:
If remote PE does not include this sub-TLV (for example, it does not support it, or it is supported but the user did not enable the hash-label option or the signal-capability option), then the local PE establishes the pseudowire but must not insert the hash label in the user and control packets over that spoke-sdp or mesh-sdp. If the remote PE does not support the signal-capability option, then there are a couple of possible outcomes:
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. The only way to solve this is to disable 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 no form of this command disables the use of the hash label.
Default
no hash-label
Parameters
signal-capability
Enables the signaling and negotiation of the use of the hash label between the local and remote PE nodes. The signal-capability option is not supported on a VPRN spoke-sdp.
force-qinq-vc-forwarding
Syntax
[no] force-qinq-vc-forwarding
Context
config>service>epipe>spoke-sdp
config>service>vpls>mesh-sdp
config>service>vpls>spoke-sdp
config>service>pw-template
Description
This command forces two VLAN tags to be inserted and removed for spoke and mesh SDPs that have either vc-type ether or vc-type vlan. The use of this command is mutually exclusive with the force-vlanvc- forwarding command.
The VLAN identifiers and dot 1p/DE bits inserted in the two VLAN tags are taken from the inner tag received on a qinq SAP or qinq mesh/spoke SDP, or from the VLAN tag received on a dot1q SAP or mesh/spoke SDP (with vc-type vlan or force-vlan-vc-forwarding), or taken from the outer tag received on a qtag.* SAP or 0 if there is no service delimiting VLAN tag at the ingress SAP or mesh/spoke SDP. The VLAN identifiers in both VLAN tags can be set to the value configured in the vlan-vc-tag parameter in the pw-template or under the mesh/spoke SDP configuration. In the received direction, the VLAN identifiers are ignored and the dot1p/DE bits are not used for ingress classification. However, the inner dot1p/DE bits are propagated to the egress QoS processing.
The Ether type inserted and used to determine the presence of a received VLAN tag for both VLAN tags is 0x8100. A different Ether type can be used for the outer VLAN tag by configuring the PW template with use-provisioned-sdps and setting the Ether type using the SDP vlan-vc-etype parameter (this Ether type value is then used for all mesh/spoke SDPs using that SDP).
The no version of this command sets default behavior.
force-vlan-vc-forwarding
Syntax
[no] force-vlan-vc-forwarding
Context
config>service>pw-template
Description
This command forces vc-vlan-type forwarding in the data path for spoke and mesh SDPs which have ether vc-type. This command is not allowed on vlan-vc-type SDPs.
The system expects a symmetrical configuration with its peer, specifically it expects to remove the same number of VLAN tags from received traffic as it adds to transmitted traffic. As some of the related configuration parameters are local and not communicated in the signaling plane, an asymmetrical behavior cannot always be detected and so cannot be blocked. Consequently, protocol extractions will not necessarily function for asymmetrical configurations as they would with a symmetrical configurations resulting in an unexpected operation.
The no version of this command sets default behavior.
Default
disabled
qos
Syntax
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
no qos
Context
config>service>apipe>spoke-sdp>ingress
config>service>cpipe>spoke-sdp>ingress
config>service>epipe>spoke-sdp>ingress
config>service>fpipe>spoke-sdp>ingress
config>service>ipipe>spoke-sdp>ingress
config>service>vpls>spoke-sdp>ingress
config>service>vpls>mesh-sdp>ingress
config>service>pw-template>ingress
config>service>vprn>interface>spoke-sdp>ingress
config>service>ies>interface>spoke-sdp>ingress
Description
This command is used to redirect pseudowire packets to an ingress forwarding plane queue-group for the purpose of rate-limiting.
The ingress pseudowire rate-limiting feature uses a policer in queue-group provisioning model. This model allows the mapping of one or more pseudowires to the same instance of policers which are defined in a queue-group template.
Operationally, the provisioning model in the case of the ingress pseudowire shaping feature consists of the following steps:
1.
2.
3.
4.
One or more spoke-sdps can have their FCs redirected to use policers in the same policer queue-group instance.
The following are the constraints and rules of this provisioning model when used in the ingress pseudowire rate-limiting feature:
1.
2.
3.
4.
5.
When a pseudowire is redirected to use a policer queue-group, the classification of the packet for the purpose of FC and profile determination is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the pseudowire. This is true regardless if an instance of the named policer queue-group exists on the ingress FP the pseudowire packet is received on. The user can apply a QoS filter matching the dot1.p in the VLAN tag corresponding to the Ethernet port encapsulation, the EXP in the outer label when the tunnel is an LSP, the DSCP in the IP header if the tunnel encapsulation is GRE, and the DSCP in the payload’s IP header if the user enabled the ler-use-dscp option and the pseudowire terminates in IES or VPRN service (spoke-interface).
When the policer queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the packet classification is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the network IP interface the pseudowire packet is received on.
The no version of this command removes the redirection of the pseudowire to the queue-group.
Parameters
network-policy-id
Specifies the network policy identification. The value uniquely identifies the policy on the system.
Values
fp-redirect-group queue-group-name
Specifies the network policy identification. The value uniquely identifies the policy on the system.
Values
vc-label
Syntax
[no] vc-label vc-label
Context
config>service>pw-template>ingress
Description
This command configures the ingress VC label.
Parameters
vc-label
A VC ingress value that indicates a specific connection.
Values
l2pt-termination
Syntax
l2pt-termination [cdp] [dtp] [pagp] [stp] [udld] [vtp]
no l2pt-termination
Context
config>service>pw-template
Description
This command enables Layer 2 Protocol Tunneling (L2PT) termination on a given SAP or spoke SDP. L2PT termination will be supported only for STP BPDUs. PDUs of other protocols will be discarded.
This feature can be enabled only if STP is disabled in the context of the given VPLS service.
Default
no l2pt-termination
Parameters
cdp
Specifies the Cisco discovery protocol.
dtp
Specifies the dynamic trunking protocol.
pagp
Specifies the port aggregation protocol.
stp
Specifies all spanning tree protocols: stp, rstp, mstp, pvst (default).
udld
Specifies unidirectional link detection.
vtp
Specifies the virtual trunk protocol.
limit-mac-move
Syntax
limit-mac-move [blockable | non-blockable]
no limit-mac-move
Context
config>service>pw-template
Description
This command indicates whether or not the mac-move agent will limit the MAC re-learn (move) rate.
Default
blockable
Parameters
blockable
The agent will monitor the MAC re-learn rate, and it will block it when the re-learn rate is exceeded.
non-blockable
When specified, a SAP will not be blocked, and another blockable SAP will be blocked instead.
mac-pinning
Syntax
[no] mac-pinning
Context
config>service>pw-template
Description
Enabling this command will disable re-learning of MAC addresses on other SAPs within the service. The MAC address will remain attached to a given SAP 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 given VPLS service, any MAC address learned on a SAP/SDP with mac-pinning enabled will remain in the FIB on this SAP/SDP forever. Every event that would otherwise result in re-learning will be logged (MAC address; original-SAP; new-SAP).
Note that MAC addresses learned during DHCP address assignment (DHCP snooping enabled) are not impacted by this command. MAC-pinning for such addresses is implicit.
Default
When a SAP or spoke SDP is part of a Residential Split Horizon Group (RSHG), MAC pinning is activated at creation of the SAP. Otherwise MAC pinning is not enabled by default.
max-nbr-mac-addr
Syntax
max-nbr-mac-addr table-size
no max-nbr-mac-addr
Context
config>service>pw-template
Description
This command specifies the maximum number of FDB entries for both learned and static MAC addresses for this SAP or spoke SDP.
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.
Default
no max-nbr-mac-addr
Parameters
table-size
Specifies the maximum number of learned and static entries allowed in the FDB of this service.
Values
restrict-protected-src
Syntax
restrict-protected-src alarm-only
restrict-protected-src [discard-frame]
no restrict-protected-src
Context
config>service>pw-template
config>service>pw-template>split-horizon-group
Description
This command indicates the action to take whenever a relearn request for a protected MAC is received on a restricted SAP belonging to this SHG
When enabled, the agent will protect the MAC from being learned or re-learned on a SAP that has restricted learning enabled.
Default
restrict-protected-src
Parameters
alarm-only
Specifies that the SAP will be left up and only a notification, sapReceivedProtSrcMac, will be generated. This parmeter is not supported on the 7750 SR-a.
discard-frame
Specifies that the SAP will start discarding the frame in addition to generating sapReceivedProtSrcMac notification.
mfib-allowed-mda-destinations
Syntax
mfib-allowed-mda-destinations
Context
config>service>pw-template>egress
Description
This command enables the context to configure MFIB-allowed MDA destinations.
The allowed-mda-destinations node and the corresponding mda command are used on spoke and mesh SDP bindings to provide a list of MDA destinations in the chassis that are allowed as destinations for multicast streams represented by [*,g] and [s,g] multicast flooding records on the VPLS service. The MDA list only applies to IP multicast forwarding when IGMP snooping is enabled on the VPLS service. The MDA list has no effect on normal VPLS flooding such as broadcast, Layer 2 multicast, unknown destinations or non-snooped IP multicast.
At the IGMP snooping level, a spoke or mesh SDP binding is included in the flooding domain for an IP multicast stream when it has either been defined as a multicast router port, received a IGMP query through the binding or has been associated with the multicast stream through an IGMP request by a host over the binding. Due to the dynamic nature of the way that a spoke or mesh SDP binding is associated with one or more egress network IP interfaces, the system treats the binding as appearing on all network ports. This causes all possible network destinations in the switch fabric to be included in the multicast streams flooding domain. The MDA destination list provides a simple mechanism that narrows the IP multicast switch fabric destinations for the spoke or mesh SDP binding.
If no MDAs are defined within the allowed-mda-destinations node, the system operates normally and will forward IP multicast flooded packets associated with the spoke or mesh SDP binding to all switch fabric taps containing network IP interfaces.
The MDA inclusion list should include all MDAs that the SDP binding may attempt to forward through. A simple way to ensure that an MDA that is not included in the list is not being used by the binding is to define the SDP the binding is associated with as MPLS and use an RSVP-TE LSP with a strict egress hop. The MDA associated with the IP interface defined as the strict egress hop should be present in the inclusion list.
If the inclusion list does not currently contain the MDA that the binding is forwarding through, the multicast packets will not reach the destination represented by the binding. By default, the MDA inclusion list is empty.
If an MDA is removed from the list, the MDA is automatically removed from the flooding domain of any snooped IP multicast streams associated with a destination on the MDA unless the MDA was the last MDA on the inclusion list. Once the inclusion list is empty, all MDAs are eligible for snooped IP multicast flooding for streams associated with the SDP binding.
mda
Syntax
[no] mda mda-id
Context
config>service>pw-template>egress>mfib-mda
Description
This command specifies an MFIB-allowed MDA destination for an SDP binding configured in the system.
Parameters
mda-id
Specifies an MFIB-allowed MDA destination.
Values
igmp-snooping
Syntax
igmp-snooping
Context
config>service>pw-template
Description
This command enables the Internet Group Management Protocol (IGMP) snooping context.
Default
none
fast-leave
Syntax
[no] fast-leave
Context
config>service>pw-template>igmp-snooping
Description
This command enables fast leave.
When IGMP fast leave processing is enabled, the 7750 SR will immediately remove a SAP or SDP from the IP multicast group when it detects an IGMP 'leave' on that SAP or SDP. Fast leave processing allows the switch to remove a SAP or SDP that sends a 'leave' from the forwarding table without first sending out group-specific queries to the SAP or SDP, and thus speeds up the process of changing channels ('zapping').
Fast leave should only be enabled when there is a single receiver present on the SAP or SDP.
When fast leave is enabled, the configured last-member-query-interval value is ignored.
Default
no fast-leave
import
Syntax
import policy-name
no import
Context
config>service>pw-template>igmp-snooping
Description
This command specifies the import routing policy to be used for IGMP packets. Only a single policy can be imported at a time.
The no form of the command removes the policy association.
Default
no import — No import policy is specified.
Parameters
policy-name
The import policy name. Allowed values are any string up to 32 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, etc.), the entire string must be enclosed within double quotes. Routing policies are configured in the config>router>policy-options context The router policy must be defined before it can be imported.
last-member-query-interval
Syntax
last-member-query-interval tenths-of-seconds
no last-member-query-interval
Context
config>service>pw-template>igmp-snooping
Description
This command configures the maximum response time used in group-specific queries sent in response to ‘leave’messages, and is also the amount of time between 2 consecutive group-specific queries. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group.
The configured last-member-query-interval is ignored when fast-leave is enabled on the SAP or SDP.
Default
10
Parameters
tenths-of-seconds
Specifies the frequency, in tenths of seconds, at which query messages are sent.
Values
max-num-groups
Syntax
max-num-groups count
no max-num-groups
Context
config>service>pw-template>igmp-snooping
Description
This command defines the maximum number of multicast groups that can be joined. If the 7750 SR receives an IGMP join message that would exceed the configured number of groups, the request is ignored.
Default
no max-num-groups
Parameters
count
Specifies the maximum number of groups that can be joined.
Values
query-interval
Syntax
query-interval seconds
no query-interval
Context
config>service>pw-template>igmp-snooping
Description
This command configures the IGMP query interval. If the send-queries command is enabled, this parameter specifies the interval between two consecutive general queries sent by the system 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.
Default
125
Parameters
seconds
The time interval, in seconds, that the router transmits general host-query messages.
Values
query-response-interval
Syntax
query-response-interval seconds
Context
config>service>pw-template>igmp-snooping
Description
This command configures the IGMP query response interval. If the send-queries command is enabled, this parameter specifies the maximum response time advertised in IGMPv2/v3 queries.
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.
Default
10
Parameters
seconds
Specifies the length of time to wait to receive a response to the host-query message from the host.
Values
robust-count
Syntax
robust-count robust-count
no robust-count
Context
config>service>pw-template>igmp-snooping
Description
If the send-queries command is enabled, this parameter allows tuning for the expected packet loss. The robust-count variable allows tuning for the expected packet loss on a subnet and is comparable to a retry count.
If send-queries is not enabled, this parameter will be ignored.
Default
2
Parameters
robust-count
Specifies the robust count for the SAP or SDP.
Values
send-queries
Syntax
[no] send-queries
Context
config>service>pw-template>igmp-snooping
Description
This command specifies whether to send IGMP general query messages.
When send-queries is configured, all type of queries generate ourselves are of the configured version. If a report of a version higher than the configured version is received, the report will get dropped and a new wrong version counter will get incremented.
If send-queries is not configured, the version command has no effect. The version used on that SAP/SDP will be the version of the querier. This implies that, for example, when we have a v2 querier, we will never send out a v3 group or group-source specific query when a host wants to leave a certain group.
Default
no send-queries
version
Syntax
version version
no version
Context
config>service>pw-template>igmp-snooping
Description
This command specifies the version of IGMP. This object can be used to configure a router capable of running either value. For IGMP to function correctly, all routers on a LAN must be configured to run the same version of IGMP on that LAN.
When the send-query command is configured, all type of queries generate ourselves are of the configured version. If a report of a version higher than the configured version is received, the report gets dropped and a new “wrong version” counter is incremented.
If the send-query command is not configured, the version command has no effect. The version used on that SAP or SDP will be the version of the querier. This implies that, for example, when there is a v2 querier, a v3 group or group-source specific query when a host wants to leave a certain group will never be sent.
Parameters
version
Specify the IGMP version.
Values
sdp-include
Syntax
[no] sdp-include group-name
Context
config>service>pw-template
Description
This command configures SDP admin group constraints for a pseudowire template.
The admin group name must have been configured or the command is failed. The user can execute the command multiple times to include or exclude more than one admin group. The sdp-include and sdp-exclude commands can only be used with the use-provisioned-sdp option. If the same group name is included and excluded within the same pseudowire template, only the exclude option will be enforced.
Any changes made to the admin group sdp-include and sdp-exclude constraints will only be reflected in existing spoke-sdps after the following command has been executed:
tools>perform>service>eval-pw-template>allow-service-impact
When the service is bound to the pseudowire template, the SDP selection rules will enforce the admin group constraints specified in the sdp-include and sdp-exclude commands.
In the SDP selection process, all provisioned SDPs with the correct far-end IP address, the correct tunnel-far-end IP address, and the correct service label signaling are considered. The SDP with the lowest admin metric is selected. If more then one SDP with the same lowest metric are found then the SDP with the highest sdp-id is selected. The type of SDP, GRE or MPLS (BGP/RSVP/LDP) is not a criterion in this selection.
The selection rule with SDP admin groups is modified such that the following admin-group constraints are applied upfront to prune SDPs that do not comply:
if one or more sdp-include statement is part of the pw-template, then an SDP that is a member of one or more of the included groups will be considered. With the sdp-include statement, there is no preference for an SDP that belongs to all included groups versus one that belongs to one or fewer of the included groups. All SDPs satisfying the admin-group constraint will be considered and the selection above based on the lowest metric and highest sdp-id is applied.
if one or more sdp-exclude statement is part of the pw-template, then an sdp that is a member of any of the excluded groups will not be considered.
SDP admin group constraints can be configured on all 7x50 services that makes use of the pseudowire template (BGP-AD VPLS service, BGP-VPLS service, and FEC129 VLL service). In the latter case, only support at a T-PE node is provided.
The no form of this command removes the SDP admin group constraints from the pseudowire template.
Default
none
Parameters
group-name
Specifies the name of the SDP admin group. A maximum of 32 characters can be entered.
sdp-exclude
Syntax
[no] sdp-exclude group-name
Context
config>service>pw-template
Description
This command configures SDP admin group constraints for a pseudowire template.
The admin group name must have been configured or the command is failed. The user can execute the command multiple times to include or exclude more than one admin group. The sdp-include and sdp-exclude commands can only be used with the use-provisioned-sdp option. If the same group name is included and excluded within the same pseudowire template, only the exclude option will be enforced.
Any changes made to the admin group sdp-include and sdp-exclude constraints will only be reflected in existing spoke-sdps after the following command has been executed:
tools>perform>service>eval-pw-template>allow-service-impact
When the service is bound to the pseudowire template, the SDP selection rules will enforce the admin group constraints specified in the sdp-include and sdp-exclude commands.
In the SDP selection process, all provisioned SDPs with the correct far-end IP address, the correct tunnel-far-end IP address, and the correct service label signaling are considered. The SDP with the lowest admin metric is selected. If more then one SDP with the same lowest metric are found then the SDP with the highest sdp-id is selected. The type of SDP, GRE or MPLS (BGP/RSVP/LDP) is not a criterion in this selection.
The selection rule with SDP admin groups is modified such that the following admin-group constraints are applied upfront to prune SDPs that do not comply:
if one or more sdp-include statement is part of the pw-template, then an SDP that is a member of one or more of the included groups will be considered. With the sdp-include statement, there is no preference for an SDP that belongs to all included groups versus one that belongs to one or fewer of the included groups. All SDPs satisfying the admin-group constraint will be considered and the selection above based on the lowest metric and highest sdp-id is applied.
if one or more sdp-exclude statement is part of the pw-template, then an sdp that is a member of any of the excluded groups will not be considered.
SDP admin group constraints can be configured on all 7x50 services that makes use of the pseudowire template (BGP-AD VPLS service, BGP-VPLS service, and FEC129 VLL service). In the latter case, only support at a T-PE node is provided.
The no form of this command removes the SDP admin group constraints from the pseudowire template.
Default
none
Parameters
group-name
Specifies the name of the SDP admin group. A maximum of 32 characters can be entered.
split-horizon-group
Syntax
[no] split-horizon-group [group-name] [residential-group]
Context
config>service>pw-template
Description
This command creates a new split horizon group (SGH).
Comparing a “residential” SGH and a “regular” SHG is that a residential SHG:
When the feature was initially introduced, residential SHGs were also using ingress shared queing by default to increase SAP scaling.
A residential SAP (SAP that belongs to a RSHG) is used to scale the number of SAPs in a single VPLS instance. The limit depends on the hardware used and is higher for residential SAPs (where there is no need for egress multicast replication on residential SAPs) than for regular SAPs. Therefore, residential SAPs are usefull in residential aggregation environments (for example, triple play networks) with a VLAN/subscriber model.
The no form of the command removes the group name from the configuration.
Parameters
group-name
Specifies the name of the split horizon group to which the SDP belongs.
residential-group
Defines a split horizon group as a residential split horizon group (RSHG). Doing so entails that:
Default
A split horizon group is by default not created as a residential-group.
auto-learn-mac-protect
Syntax
[no] auto-learn-mac-protect
Context
config>service>vpls>sap
config>service>vpls>spoke-sdp
config>service>vpls >mesh-sdp
config>service>vpls>split-horizon-group
config>service>vpls>endpoint
config>service>pw-template
config>service>pw-template>split-horizon-group
Description
This command enables the automatic protection of source MAC addresses learned on the associated object. MAC protection is used in conjunction with restrict-protected-src, restrict-unprotected-dst and mac-protect. When this command is applied or removed, the MAC addresses are cleared from the related object.
When the auto-learn-mac-protect is enabled on an SHG the action only applies to the associated SAPs (no action is taken by default for spoke SDPs in the SHG). In order to enable this function for spoke SDPs within a SHG, the auto-learn-mac-protect must be enabled explicitly under the spoke-SDP. If required, auto-learn-mac-protect can also be enabled explicitly under specific SAPs within the SHG. For more information about auto-learn MAC protect, refer to the Layer 2 Services Guide.
Default
no auto-learn-mac-protect
restrict-protected-src
Syntax
restrict-protected-src [alarm-only | discard-frame]
no restrict-protected-src
Context
config>service>vpls>sap
config>service>vpls>spoke-sdp
config>service>vpls>mesh-sdp
config>service>vpls>split-horizon-group
config>service>vpls>endpoint
config>service>pw-template>
config>service>pw-template>split-horizon-group
Description
This command indicates how the agent will handle relearn requests for protected MAC addresses, either manually added using the mac-protect command or automatically added using the auto-learn-mac-protect command. While enabled all packets entering the configured SAP, spoke-SDP, mesh-SDP , or any SAP that is part of the configured split horizon group (SHG) will be verified not to contain a protected source MAC address. If the packet is found to contain such an address, the action taken depends on the parameter specified on the restrict-protected-src command, namely:
The packet will be discarded, an alarm will be generated and the SAP, spoke-SDP or mesh-SDP will be set operationally down. The SAP, spoke-SDP or mesh-SDP must be shutdown and enabled (no shutdown) for this state to be cleared.
The packet will be forwarded, an alarm will be generated but the source MAC is not learned on the SAP/spoke-SDP/mesh-SDP.
The packet will be discarded and an alarm generated. The frequency of alarm generation is fixed to be at most one alarm per MAC address per FP2 per 10 minutes in a given VPLS service. This parameter is only applicable to automatically protected MAC addresses.
When the restrict-protected-src is enabled on an SHG the action only applies to the associated SAPs (no action is taken by default for spoke SDPs in the SHG). In order to enable this function for spoke SDPs within a SHG, the restrict-protected-src must be enabled explicitly under the spoke-SDP. If required, restrict-protected-src can also be enabled explicitly under specific SAPs within the SHG.
When this command is applied or removed, with either the alarm-only or discard-frame parameters, the MAC addresses are cleared from the related object.
The use of “restrict-protected-src discard-frame” is mutually exclusive with both the “restrict-protected-src [alarm-only]” command and with the configuration of manually protected MAC addresses within a given VPLS. Note that the alarm-only parameter is not supported on the 7750 SR-a or .
“restrict-protected-src discard-frame” can only be enabled on SAPs on FP2 or later hardware or on SDPs where all network interfaces are on FP2 or later hardware.
Parameters
alarm-only
Specifies that the packet will be forwarded, an alarm will be generated but the source MAC is not learned on the SAP/spoke-SDP/mesh-SDP. This parameter is not supported on the .
Default
discard-frame
Specifies that the packet will be discarded and an alarm generated. The frequency of alarm generation is fixed to be at most one alarm per FP2 per MAC address per 10 minutes within a given VPLS service.
Default
Default
no restrict-protected-src
restrict-unprotected-dst
Syntax
restrict-unprotected-dst
no restrict-unprotected-dst
Context
config>service>pw-template>split-horizon-group
config>service>vpls>split-horizon-group
config>service>vpls>sap
Description
This command indicates how the system will forward packets destined to an unprotected MAC address, either manually added using the mac-protect command or automatically added using the auto-learn-mac-protect command. While enabled all packets entering the configured SAP or SAPs within a split-horizon-group (but not spoke or mesh-SDPs) will be verified to contain a protected destination MAC address. If the packet is found to contain a non-protected destination MAC, it will be discarded. Detecting a non-protected destination MAC on the SAP will not cause the SAP to be placed in the operationally down state. No alarms are generated.
If the destination MAC address is unknown, even if the packet is entering a restricted SAP, with restrict-unprotected-dst enabled, it will be flooded.
Default
no restrict-unprotected-dst
stp
Syntax
stp
Context
config>service>pw-template
Description
This command enables the context to configure the Spanning Tree Protocol (STP) parameters. Alcatel-Lucent’s 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 Alcatel-Lucent’s service routers should not be blocked, the root path is calculated from the core perspective.
auto-edge
Syntax
auto-edge
no auto-edge
Context
config>service>pw-template>stp
Description
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 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 true (see edge-port ).
The no form of this command returns the auto-detection setting to the default value.
Default
auto-edge
edge-port
Syntax
[no] edge-port
Context
config>service>pw-template>stp
Description
This command configures the SAP or SDP as an edge or non-edge port. If auto-edge is enabled for the SAP, this value will be used only as the initial value.
NOTE: The function of the edge-port command is similar to the rapid-start command. It tells RSTP 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.
RSTP, however, can detect that the actual situation is different from what edge-port may indicate.
Initially, the value of the SAP or spoke SDP parameter is set to edge-port. This value will change if:
The no form of this command returns the edge port setting to the default value.
Default
no edge-port
link-type
Syntax
link-type {pt-pt | shared}
no link-type
Context
config>service>pw-template>stp
Description
This command instructs STP on the maximum number of bridges behind this SAP or spoke SDP. If there is only a single bridge, transitioning to forwarding state will be based on handshaking (fast transitions). If more than two bridges are connected via a shared media, their SAP or spoke SDPs should all be configured as shared, and timer-based transitions are used.
The no form of this command returns the link type to the default value.
Default
pt-pt
path-cost
Syntax
path-cost sap-path-cost
no path-cost
Context
config>service>pw-template>stp
Description
This command configures the Spanning Tree Protocol (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 SAPs or spoke SDPs, the newly calculated root path cost is used. These are the values used for CIST when running MSTP.
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, the STP path cost is a purely static configuration.
The no form of this command returns the path cost to the default value.
path-cost
The path cost for the SAP or spoke SDP.
Values
Default
priority
Syntax
priority bridge-priority
no priority
Context
config>service>pw-template>stp
Description
The bridge-priority command is used to populate the priority portion of the bridge ID field within outbound BPDUs (the most significant 4 bits of the bridge ID). It is also used as part of the decision process when determining the best BPDU between messages received and sent. All values 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.
Default
By default, the bridge priority is configured to 4096 which is the highest priority.
Parameters
bridge-priority
The bridge priority for the STP instance.
Values
root-guard
Syntax
[no] root-guard
Context
config>service>pw-template>stp
Description
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.
Default
no root-guard
vc-type
Syntax
vc-type {ether | vlan}
Context
config>service>pw-template
Description
This command overrides the default VC type signaled for the binding to the far end SDP. The VC type is a 15 bit-quantity containing a value which represents the type of VC. The actual signaling of the VC type depends on the signaling parameter defined for the SDP. If signaling is disabled, the vc-type command can still be used to define the dot1q value expected by the far-end provider equipment. A change of the bindings VC type causes the binding to signal the new VC type to the far end when signaling is enabled.
VC types are derived according to IETF draft-martini-l2circuit-trans-mpls.
Parameters
ether
Defines the VC type as Ethernet. The ethernet and vlan keywords are mutually exclusive. When the VC type is not defined then the default is Ethernet for spoke SDP bindings. Defining Ethernet is the same as executing no vc-type and restores the default VC type for the spoke SDP binding. (hex 5)
vlan
Defines the VC type as VLAN. The top VLAN tag, if a VLAN tag is present, is stripped from traffic received on the pseudowire, and a vlan-tag is inserted when forwarding into the pseudowire.The ethernet and vlan keywords are mutually exclusive. When the VC type is not defined then the default is Ethernet for spoke SDP bindings.
Note: The system expects a symmetrical configuration with its peer, specifically it expects to remove the same number of VLAN tags from received traffic as it adds to transmitted traffic. As some of the related configuration parameters are local and not communicated in the signaling plane, an asymmetrical behavior cannot always be detected and so cannot be blocked. Consequently, protocol extractions will not necessarily function for asymmetrical configurations as they would with a symmetrical configurations resulting in an unexpected operation.
vlan-vc-tag
Syntax
vlan-vc-tag 0..4094
no vlan-vc-tag [0..4094]
Context
config>service>pw-template
Description
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
Default
no vlan-vc-tag
Parameters
0..4094
Specifies a valid VLAN identifier to bind an 802.1Q VLAN tag ID.
adv-mtu-override
Syntax
[no] adv-mtu-override
Context
config>service>sdp
Description
This command overrides the advertised VC-type MTU of all spoke-sdp's of L2 services using this SDP-ID. When enabled, the router signals a VC MTU equal to the service MTU, which includes the Layer 2 header. It also allows this router to accept an MTU advertized by the far-end PE which value matches either its advertised MTU or its advertised MTU minus the L2 headers.
By default, the router advertizes a VC-MTU equal to the L2 service MTU minus the Layer 2 header and always matches its advertized MTU to that signaled by the far-end PE router, otherwise the spoke-sdp goes operationally down.
When this command is enabled on the SDP, it has no effect on a spoke-sdp of an IES/VPRN spoke interface using this SDP-ID. The router continues to signal a VC MTU equal to the net IP interface MTU, which is min{ip-mtu, sdp operational path mtu - L2 headers}. The router also continues to make sure that the advertized MTU values of both PE routers match or the spoke-sdp goes operationally down.
The no form of the command disables the VC-type MTU override and returns to the default behavior.
Default
no adv-mtu-override
binding
Syntax
binding
Context
config>service>sdp
Description
The command enables the context to configure SDP bindings.
port
Syntax
port [port-id | lag-id]
no port
Context
config>service>sdp>binding
Description
This command specifies the port or lag identifier, to which the pseudowire ports associated with the underlying SDP are bound. If the underlying SDP is re-routed to a port or lag other than the specified one, the pseudowire ports on the SDP are operationally brought down.
The no form of the command removes the value from the configuration.
Default
none
Parameters
port-id
The identifier of the port in the slot/mda/port format.
lag-id
Specifies the LAG identifier.
pw-port
Syntax
pw-port pw-port-id [vc-id vc-id] [create]
no pw-port pw-port-id
Context
config>service>sdp>binding
Description
This command creates a pseudowire port.
The no form of the command removes the pseudowire port ID from the configuration.
Default
none
Parameters
pw-port-id
Specifies a unique identifier of the pseudowire port.
Values
vc-id vc-id
Specifies a virtual circuit identifier signaled to the peer.
Values
create
This keyword is required when a new pseudowire is being created.
 
description
Syntax
description description-string
no description
Context
config>service>sdp>binding>pw-port
Description
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 the command removes the string from the configuration.
Default
no description
Parameters
description-string
Specifies the description character string of the configuration context.
Values
encap-type
Syntax
encap-type {dot1q | qinq}
no encap-type
Context
config>service>sdp>binding>pw-port
Description
This command sets the encapsulation type for the pseudowire port as dot1q or qinq.
Default
dot1q
Parameters
dot1q
Specifies dot1q encapsulation type.
qinq
Specifies qinq encapsulation type.
monitor-oper-group
Syntax
monitor-oper-group group name
no monitor-oper-group
Context
config>service>sdp>binding>pw-port
Description
This command specifies the operational group to be monitored by the object under which it is configured. The oper-group name must be already configured under the config>service context before its name is referenced in this command.
The no form of the command removes the association from the configuration.
Default
no monitor-oper-group
Parameters
name
Specifies a character string of maximum 32 ASCII characters identifying the group instance.
vc-type
Syntax
vc-type {ether | vlan}
no vc-type
Context
config>service>sdp>binding>pw-port
Description
This command sets the forwarding mode for the pseudowire port. The vc-type is signaled to the peer, and must be configured consistently on both ends of the pseudowire. vc-type VLAN is only configurable with dot1q encapsulation on the pseudowire port. The tag with vc-type vlan only has significance for transport, and is not used for service delineation or ESM. The top (provider tag) is stripped while forwarding out of the pseudowire, and a configured vlan-tag (for vc-type vlan) is inserted when forwarding into the pseudowire. With vc-type ether, the tags if present (max 2), are transparently preserved when forwarding in our out of the pseudowire.
The no form of the command reverts to the default value.
Default
ether
Parameters
ether
Specifies ether as the virtual circuit (VC) associated with the SDP binding.
vlan
Specifies vlan as the virtual circuit (VC) associated with the SDP binding.
vlan-vc-tag
Syntax
vlan-vc-tag vlan-id
no vlan-vc-tag
Context
config>service>sdp>binding>pw-port
Description
This command sets tag relevant for vc-type vlan mode. This tag is inserted in traffic forwarded into the pseudowire.
The no form of the command reverts to the default value.
Default
0
Parameters
vlan-id
Specifies the VLAN ID value.
Values
egress
Syntax
egress
Context
config>service>sdp>binding>pw-port
Description
This command enters egress configuration context for the vport.
Default
none
shaper
Syntax
[no] shaper
Context
config>service>sdp>binding>pw-port>egress
Description
This command configures an egress shaping option for use by a pseudowire port.
Default
no shaper
int-dest-id
Syntax
int-dest-id int-dest-id
no int-dest-id
Context
config>service>sdp>binding>pw-port>egress>shaper
Description
This command configures an intermediate destination identifier applicable to esm pw-saps.
pw-sap-secondary-shaper
Syntax
pw-sap-secondary-shaper pw-sap-sec-shaper-name
no pw-sap-secondary-shaper
Context
config>service>sdp>binding>pw-port>egress>shaper
Description
This command configures a default secondary shaper applicable to pw-saps under normal interfaces.
vport
Syntax
vport vport-name
no vport
Context
config>service>sdp>binding>pw-port>egress>shaper
Description
This command configures a virtual port applicable to all pw-saps.
class-forwarding
Syntax
class-forwarding [default-lsp lsp-name]
no class-forwarding
Context
config>service>sdp
Description
This command enables the forwarding of a service packet over the SDP based on the class of service of the packet. Specifically, the packet is forwarded on the RSVP LSP or static LSP whose forwarding class matches that of the packet. The user maps the system forwarding classes to LSPs using the config>service>sdp>class-forwarding>fc command. If there is no LSP that matches the packet’s forwarding class, the default LSP is used. If the packet is a VPLS multicast/broadcast packet and the user did not explicitly specify the LSP to use under the config>service>sdp>class-forwarding>multicast-lsp context, then the default LSP is used.
VLL service packets are forwarded based on their forwarding class only if shared queuing is enabled on the ingress SAP. Shared queuing must be enabled on the VLL ingress SAP if class-forwarding is enabled on the SDP the service is bound to. Otherwise, the VLL packets will be forwarded to the LSP which is the result of hashing the VLL service ID. Since there are eight entries in the ECMP table for an SDP, one LSP ID for each forwarding class, the resulting load balancing of VLL service ID is weighted by the number of times an LSP appears on that table. For instance, if there are eight LSPs, the result of the hashing will be similar to when class based forwarding is disabled on the SDP. If there are fewer LSPs, then the LSPs which were mapped to more than one forwarding class, including the default LSP, will have proportionally more VLL services forwarding to them.
Class-based forwarding is not supported on a spoke SDP used for termination on an IES or VPRN service. All packets are forwarded over the default LSP.
The no form of the command deletes the configuration and the SDP reverts back to forwarding service packets based on the hash algorithm used for LAG and ECMP.
Default
no class-forwarding — Packets of a service bound to this SDP will be forwarded based on the hash algorithm used for LAG and ECMP.
Parameters
default-lsp lsp-name
Specifies the default LSP for the SDP. This LSP name must exist and must have been associated with this SDP using the lsp-name configured in the config>service>sdp>lsp context. The default LSP is used to forward packets when there is no available LSP which matches the packet’s forwarding class. This could be because the LSP associated with the packet’s forwarding class is down, or that the user did not configure a mapping of the packet’s forwarding class to an LSP using the config>service>sdp>class-forwarding>fc command. The default LSP is also used to forward VPLS service multicast/broadcast packets in the absence of a user configuration indicating an explicit association to one of the SDP LSPs.
Note that when the default LSP is down, the SDP is also brought down. The user will not be able to enter the class-forwarding node if the default LSP was not previously specified. In other words the class-forwarding for this SDP will remain shutdown.
enforce-diffserv-lsp-fc
Syntax
[no] enforce-diffserv-lsp-fc
Context
config>service>sdp>class-forwarding
Description
This command enables checking by RSVP that a Forwarding Class (FC) mapping to an LSP under the SDP configuration is compatible with the Diff-Serv Class Type (CT) configuration for this LSP.
When the user enables this option, the service manager enquires with RSVP if the FC is supported by the LSP. RSVP checks if the FC maps to the CT of the LSP, for example, the default class-type value or the class-type value entered at the LSP configuration level.
If RSVP did not validate the FC, then the service manager will return an error and the check has failed. In this case, packets matching this FC will be forwarded over the default LSP. Any addition of an LSP to an SDP that will not satisfy the FC check will also be rejected.
The service manager does no validate the default-lsp FC-to-CT mapping. Whether or not the FC is validated, the default-lsp will always end up being used in this case.
RSVP will not allow the user to change the CT of the LSP until no SDP with class-based forwarding enabled and the enforce-diffserv-lsp-fc option enabled is using this LSP. All other SDPs using this LSP are not concerned by this rule.
The SDP will continue to enforce the mapping of a single LSP per FC. However, when enforce-diffserv-lsp-fc enabled, RSVP will also enforce the use of a single CT per FC as per the user configured mapping in RSVP.
If class-forwarding is enabled but enforce-diffserv-lsp-fc is disabled, forwarding of the service packets will continue to be based on the user entered mapping of FC to LSP name without further validation as per the existing implementation. The CT of the LSP does not matter in this case.
If class-forwarding is not enabled on the SDP, forwarding of the service packets will continue to be based on the ECMP/LAG hash routine. The CT of the LSP does not matter in this case.
The no form of this command reverts to the default value which is to use the user entered mapping of FC to LSP name.
Default
no enforce-diffserv-lsp-fc
far-end
Syntax
far-end ip-address | ipv6-address | {node-id node-id [global-id global-id]}
no far-end
Context
config>service>sdp
Description
This command configures the system IP address of the far-end destination router for the Service Distribution Point (SDP) that is the termination point for a service.
The far-end IP address must be explicitly configured. The destination IP address must be that of an SR OS node and for a GRE SDP it must match the system IP address of the far end router.
If the SDP uses GRE for the destination encapsulation, the ip-address is checked against other GRE SDPs to verify uniqueness. If the ip-address is not unique within the configured GRE SDPs, an error is generated and the ip-address is not associated with the SDP. The local device may not know whether the ip-address is actually a system IP interface address on the far-end device.
If the SDP uses MPLS encapsulation, the far-end ip-address is used to check LSP names when added to the SDP. If the “to IP address” defined within the LSP configuration does not exactly match the SDP far-end ip-address, the LSP will not be added to the SDP and an error will be generated. Alternatively, an SDP that uses MPLS can have an MPLS-TP node with an MPLS-TP node-id and (optionally) a global-id. In this case, the SDP must use an MPLS-TP LSP and the SDP signaling parameter must be set to off.
An SDP cannot be administratively enabled until a far-end ip-address or MPLS-TP node-id is defined. The SDP is operational when it is administratively enabled (no shutdown) and the far-end ip-address is contained in the IGP routing table as a host route. OSPF ABRs should not summarize host routes between areas. This can cause SDPs to become operationally down. Static host routes (direct and indirect) can be defined in the local device to alleviate this issue.
The no form of this command removes the currently configured destination IP address for the SDP. The ip-address parameter is not specified and will generate an error if used in the no far-end command. The SDP must be administratively disabled using the config service sdp shutdown command before the no far-end command can be executed. Removing the far end IP address will cause all lsp-name associations with the SDP to be removed.
Default
none
Parameters
ip-address|ipv6-address
The IPv4 or IPv6 address of the far-end SR OS node for the SDP in dotted decimal notation.
node-id node-id
The MPLS-TP Node ID of the far-end system for the SDP, either in dotted decimal notation (a.b.c.d) or an unsigned 32-bit integer (1 – 4294967295). This parameter is mandatory for an SDP using an MPLS-TP LSP.
global-id global-id
The MPLS-TP Global ID of the far-end system for the SDP, in an unsigned 32-bit integer (0 – 4294967295). This parameter is optional for an SDP using an MPLS-TP LSP. If not entered, a default value for the Global ID of ‘0’ is used. A global ID of ‘0’ indicates that the far-end node is in the same domain as the local node. The user must explicitly configure a Global ID if its value is non-zero.
fc
Syntax
fc {be | l2 | af | l1 | h2 | ef | h1 | nc} lsp lsp-name
no fc {be | l2 | af | l1 | h2 | ef | h1 | nc}
Context
config>service>sdp>forwarding-class
Description
This command makes an explicit association between a forwarding class and an LSP. The LSP name must exist and must have been associated with this SDP using the command config>service>sdp>lsp. Multiple forwarding classes can be associated with the same LSP. However, a forwarding class can only be associated with a single LSP in a given SDP. All subclasses will be assigned to the same LSP as the parent forwarding class.
Default
none
Parameters
lsp lsp-name
Specifies the RSVP or static LSP to use to forward service packets which are classified into the specified forwarding class.
multicast-lsp
Syntax
multicast-lsp lsp-name
no multicast-lsp
Context
config>service>sdp>forwarding-class
Description
This command specifies the RSVP or static LSP in this SDP to use to forward VPLS multicast and broadcast packets. The LSP name must exist and must have been associated with this SDP using the command config>service>sdp>lsp. In the absence of an explicit configuration by the user, the default LSP is used.
Default
default-lsp-name
ldp
Syntax
[no] ldp
Context
config>service>sdp
Description
This command enables LDP-signaled LSP's on MPLS-encapsulated SDPs.
In MPLS SDP configurations either one or more LSP names can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive except if the mixed-lsp-mode option is also enabled. If an LSP is specified on an MPLS SDP, then LDP cannot be enabled on the SDP. To enable LDP on the SDP when an LSP is already specified, the LSP must be removed from the configuration using the no lsp lsp-name command or the mixed-lsp-mode option is also enabled.
Alternatively, if LDP is already enabled on an MPLS SDP, then an LSP cannot be specified on the SDP. To specify an LSP on the SDP, the LDP must be disabled. The LSP must have already been created in the config>router>mpls context with a valid far-end IP address. The above rules are relaxed when the mixed-lsp option is enabled on the SDP.
Default
no ldp (disabled)
local-end
Syntax
local-end ip-address|ipv6-address
no local-end
Context
config>service>sdp
Description
This command configures the local-end of the L2TP v3 tunnel.
lsp
Syntax
[no] lsp lsp-name
Context
config>service>sdp
Description
This command creates associations between one or more label switched paths (LSPs) and an Multi-Protocol Label Switching (MPLS) Service Distribution Point (SDP). This command is implemented only on MPLS-type encapsulated SDPs.
In MPLS SDP configurations either one or more LSP names can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive except if the mixed-lsp-mode option is also enabled. If an LSP is specified on an MPLS SDP, then LDP cannot be enabled on the SDP. To enable LDP on the SDP when an LSP is already specified, the LSP must be removed from the configuration using the no lsp lsp-name command.
Alternatively, if LDP is already enabled on an MPLS SDP, then an LSP cannot be specified on the SDP. To specify an LSP on the SDP, the LDP must be disabled or the mixed-lsp-mode option is also enabled. The LSP must have already been created in the config>router>mpls context. with a valid far-end IP address. RSVP must be enabled.
If no LSP is associated with an MPLS SDP, the SDP cannot enter the operationally up state. The SDP can be administratively enabled (no shutdown) with no LSP associations. The lsp-name may be shutdown, causing the association with the SDP to be operationally down (the LSP will not be used by the SDP).
Up to 16 LSP names can be entered on a single command line.
The no form of this command deletes one or more LSP associations from an SDP. If the lsp-name does not exist as an association or as a configured LSP, no error is returned. An lsp-name must be removed from all SDP associations before the lsp-name can be deleted from the system. The SDP must be administratively disabled (shutdown) before the last lsp-name association with the SDP is deleted.
Default
none
Parameters
lsp-name
The name of the LSP to associate with the SDP. An LSP name is case sensitive and is limited to 32 ASCII 7-bit printable characters with no spaces. If an exact match of lsp-name does not already exist as a defined LSP, an error message is generated. If the lsp-name does exist and the LSP to IP address matches the SDP far-end IP address, the association is created.
metric
Syntax
metric metric
no metric
Context
config>service>sdp
Description
This command specifies the metric to be used within the tunnel table manager for decision making purposes. When multiple SDPs going to the same destination exist, this value is used as a tie-breaker by tunnel table manager users such as MP-BGP to select the route with the lower value.
Parameters
metric
Specifies the SDP metric.
Values
mixed-lsp-mode
Syntax
[no] mixed-lsp-mode
Context
config>service>sdp
Description
This command enables the use by an SDP of the mixed-LSP mode of operation. This command indicates to the service manager that it must allow a primary LSP type and a backup LSP type in the same SDP configuration. For example, the lsp and ldp commands are allowed concurrently in the SDP configuration. The user can configure one or two types of LSPs under the same SDP. Without this command, these commands are mutually exclusive.
The user can configure an RSVP LSP as a primary LSP type with an LDP LSP as a backup type. The user can also configure a BGP RFC 3107 BGP LSP as a backup LSP type.
If the user configures an LDP LSP as a primary LSP type, then the backup LSP type must be an RFC 3107 BGP labeled route.
At any given time, the service manager programs only one type of LSP in the linecard that will
activate it to forward service packets according to the following priority order:
6.
7.
LDP LSP type. One LDP FEC programmed by service manager but ingress IOM can use up to 16 LDP ECMP paths for the FEC to load balance service packets when ECMP is enabled on the node.
8.
In the case of the RSVP/LDP SDP, the service manager will program the NHLFE(s) for the active LSP type preferring the RSVP LSP type over the LDP LSP type. If no RSVP LSP is configured or all configured RSVP LSPs go down, the service manager will re-program the IOM with the LDP LSP if available. If not, the SDP goes operationally down.
When a higher priority type LSP becomes available, the service manager reverts back to this LSP at the expiry of the sdp-revert-time timer or the failure of the currently active LSP, whichever comes first. The service manager then re-programs the IOM accordingly. If the infinite value is configured, then the SDP reverts to the highest priority type LSP only if the currently active LSP failed.
Note however, that LDP uses a tunnel down damp timer which is set to three seconds by default. When the LDP LSP fails, the SDP will revert to the RSVP LSP type after the expiry of this timer. For an immediate switchover this timer must be set to zero. Use the configure>router>ldp>tunnel-down-damp-time command.
If the user changes the value of the sdp-revert-time timer, it will take effect only at the next use of the timer. Any timer which is outstanding at the time of the change will be restarted with the new value.
If class based forwarding is enabled for this SDP, the forwarding of the packets over the RSVP LSPs will be based on the FC of the packet as in current implementation. When the SDP activates the LDP LSP type, then packets are forwarded over the LDP ECMP paths using the regular hash routine.
In the case of the LDP/BGP SDP, the service manager will prefer the LDP LSP type over the BGP LSP type. The service manager will re-program the IOM with the BGP LSP if available otherwise it brings down the SDP operationally.
Also Note the following difference in behavior of the LDP/BGP SDP compared to that of an RSVP/LDP SDP. For a given /32 prefix, only a single route will exist in the routing table: the IGP route or the BGP route. Thus, either the LDP FEC or the BGP label route is active at any given time. The impact of this is that the tunnel table needs to be re-programmed each time a route is deactivated and the other is activated. Furthermore, the SDP revert-time cannot be used since there is no situation where both LSP types are active for the same /32 prefix.
The no form of this command disables the mixed-LSP mode of operation. The user first has to remove one of the LSP types from the SDP configuration or the command will fail.
Default
no mixed-lsp-mode
revert-time
Syntax
revert-time seconds | infinite
no revert-time
Context
config>service>sdp>mixed-lsp-mode
Description
This command configures the delay period the SDP must wait before it reverts to a higher priority LSP type when one becomes available.
The no form of the command resets the timer to the default value of 0. This means the SDP reverts immediately to a higher priority LSP type when one becomes available.
Default
0
Parameters
seconds
Specifies the delay period, in seconds, that the SDP must wait before it reverts to a higher priority LSP type when one becomes available. A value of zero means the SDP reverts immediately to a higher priority LSP type when one becomes available.
Values
infinite
This keyword forces the SDP to never revert to another higher priority LSP type unless the currently active LSP type is down.
sdp-group
Syntax
[no] sdp-group group-name
Context
config>service>sdp
Description
This command configures the SDP membership in admin groups.
The user can enter a maximum of one (1) admin group name at once. The user can execute the command multiple times to add membership to more than one admin group. The admin group name must have been configured or the command is failed. Admin groups are supported on an SDP of type GRE and of type MPLS (BGP/RSVP/LDP). They are also supported on an SDP with the mixed-lsp-mode option enabled.
The no form of this command removes this SDP membership to the specified admin group.
Default
none
Parameters
group-name group-name
Specifies the name of the SDP admin group. A maximum of 32 charactrs can be entered.
group-name
Syntax
group-name group-name value group-value
no group-name group-name
Context
config>service>sdp-group
Description
This command defines SDP administrative groups, referred to as SDP admin groups.
SDP admin groups provide a way for services using a pseudowire template to automatically include or exclude specific provisioned SDPs. SDPs sharing a specific characteristic or attribute can be made members of the same admin group. When users configure a pseudowire template, they can include and/or exclude one or more admin groups. When the service is bound to the pseudowire template, the SDP selection rules will enforce the admin group constraints specified in the sdp-include and sdp-exclude commands.
A maximum of 32 admin groups can be created. The group value ranges from zero (0) to 31. It is uniquely associated with the group name at creation time. If the user attempts to configure another group name for a group value that is already assigned to an existing group name, the SDP admin group creation is failed. The same happens if the user attempts to configure an SDP admin group with a new name but associates it to a group value already assigned to an existing group name.
The no option of this command deletes the SDP admin group but is only allowed if the group-name is not referenced in a pw-template or SDP.
Default
none
Parameters
group-name group-name
Specifies the name of the SDP admin group. A maximum of 32 characters can be entered.
value group-value
Specifies the group value associated with this SDP admin group. This value is unique within the system.
Values
signaling
Syntax
signaling {off | tldp | bgp}
Context
config>service>sdp
Description
This command specifies the signaling protocol used to obtain the ingress and egress pseudowire labels in frames transmitted and received on the SDP. When signaling is off then labels are manually configured when the SDP is bound to a service. The signalling value can only be changed while the administrative status of the SDP is down. Additionally, the signaling can only be changed on an SDP if that SDP is not in use by BGP-AD or BGP-VPLS. BGP signaling can only be enabled if that SDP does not already have pseudowires signaled over it. Also, BGP signaling is not supported with mixed mode LSP SDPs.
The no form of this command is not applicable. To modify the signaling configuration, the SDP must be administratively shut down and then the signaling parameter can be modified and re-enabled.
Default
tldp
Parameters
off
Ingress and egress signal auto-labeling is not enabled. If this parameter is selected, then each service using the specified SDP must manually configure VPN labels. This configuration is independent of the SDP’s transport type, GRE, MPLS (RSVP or LDP).
tldp
Ingress and egress pseudowire signaling using T-LDP is enabled. Default value used when BGP AD automatically instantiates the SDP.
bgp
Ingress and egress pseudowire signaling using BGP is enabled. Default value used when BGP VPLS automatically instantiates the SDP.
tunnel-far-end
Syntax
tunnel-far-end ip-address
no tunnel-far-end [ip-address]
Context
config>service>sdp
Description
This command enables the user to specify an SDP tunnel destination address that is different from the configuration in the SDP far-end option.
The SDP must be shutdown first to add or change the configuration of the
tunnel-far-end option.
When this option is enabled, service packets are encapsulated using an LDP LSP with a FEC prefix matching the value entered in ip-address. By default, service packets are encapsulated using an LDP LSP with a FEC prefix matching the address entered in the SDP far-end option.
The T-LDP session to the remote PE is still targeted to the address configured under the far-end option. This means that targeted “hello” messages are sent to the far-end address, which is also the LSR-ID of the remote node. TCP based LDP messages, such as initialization and label mapping messages, are sent to the address specified in the transport-address field of the “hello” message received from the remote PE. This address can be the same as the remote PE LSR-ID, or a different address. This feature works, however, if the signaling option in the SDP is set to off instead of tldp, in which case, the service labels are statically configured.
This feature operates on an SDP of type LDP only. It can be used with VLL, VPLS, and VPRN services when an explicit binding to an SDP with the tunnel-far-end is specified. It also operates with a spoke interface on an IES or VPRN service. Finally, this feature operates with a BGP AD based VPLS service when the use-provisioned-sdp option is enabled in the pseudowire template.
This feature is not supported in an SDP of type MPLS when an RSVP LSP name is configured under the SDP. It also does not work with a mixed-lsp SDP.
The no form of this command disables the use of the tunnel-far-end option and returns to using the address specified in the far-end.
Default
no tunnel-far-end
Parameters
ip-address
The system address of the far-end router for the SDP in dotted decimal notation.
path-mtu
Syntax
path-mtu [bytes]
no path-mtu bytes
Context
config>service>sdp
Description
This command configures the Maximum Transmission Unit (MTU) in bytes that the Service Distribution Point (SDP) can transmit to the far-end device router without packet dropping or IP fragmentation overriding the SDP-type default path-mtu.
The default SDP-type path-mtu can be overridden on a per SDP basis. Dynamic maintenance protocols on the SDP like RSVP may override this setting.
If the physical mtu on an egress interface or PoS channel indicates the next hop on an SDP path cannot support the current path-mtu, the operational path-mtu on that SDP will be modified to a value that can be transmitted without fragmentation.
The no form of this command removes any path-mtu defined on the SDP and the SDP will use the system default for the SDP type.
Default
The default path-mtu defined on the system for the type of SDP is used.
network-domain
Syntax
network-domain network-domain-name
no network-domain
Context
config>service>sdp
Description
This command assigns a given SDP to a given network-domain. The network-domain is then taken into account during sap-ingress queue allocation for VPLS SAP.
The network-domain association can only be done in a base-routing context. Associating a network domain with an loop-back or system interface will be rejected. Associating a network-domain with an interface that has no physical port specified will be accepted, but will have no effect as long as a corresponding port, or LAG, is undefined.
A single SDP can only be associated with a single network-domain.
Default
per default “default” network domain is assigned
pbb-etype
Syntax
pbb-etype [0x0600..0xffff]
no pbb-etype
Context
configure>service>sdp
Default
0x88E7
Description
This command configures the Ethertype used for PBB.
0x0600..0xffff
Specifies the Ethertype.
Values
source-bmac-lsb
Syntax
source-bmac-lsb MAC-lsb control-pw-vc-id vc-id
no source-bmac-lsb
Context
config>service>sdp
Description
This command defines the 16 least significant bits (lsb) which, when combined with the 32 most significant bits of the PBB source-bmac, are used as the virtual backbone MAC associated with this SDP. The virtual backbone MAC is used as the source backbone MAC for traffic received on a PBB EPIPE spoke-SDP with use-sdp-bmac configured (that is, a redundant pseudowire) and forwarded into the B-VPLS domain.
The control-pw-vc-id defines VC identifier of the spoke-SDP relating to the control pseudowire whose status is to be used to determine whether SPBM advertises this virtual backbone MAC. This is a mandatory parameter when the source-bmac-lsb is added or changed. The spoke SDP must have the parameter use-sdp-bmac for the control pseudowire to be active.
Default
no source-bmac-lsb
MAC-lsb
Specificies the 16 least significant bits of the virtual backbone MAC associated with this SDP.
Values
control-pw-vc-id vc-id
Specifies the VC identifier of the control pseudowire.
Values
sr-isis
Syntax
[no] sr-isis
Context
config>service>sdp
Description
This command configures an MPLS SDP of LSP type ISIS Segment Routing. The SDP of LSP type sr-isis can be used with the far-end option. The signaling protocol for the service labels for an SDP using an SR tunnel can be configured to static (off), T-LDP (tldp), or BGP (bgp).
sr-ospf
Syntax
[no] sr-ospf
Context
config>service>sdp
Description
This command configures an MPLS SDP of LSP type OSPF Segment Routing. The SDP of LSP type sr‑ospf can be used with the far-end option. The signaling protocol for the service labels for an SDP using an SR tunnel can be configured to static (off), T-LDP (tldp), or BGP (bgp).
vlan-vc-etype
Syntax
vlan-vc-etype 0x0600..0xffff
no vlan-vc-etype [0x0600..0xffff]
Context
config>service>sdp
Description
This command configures the VLAN VC EtherType.
The no form of this command returns the value to the default.
Default
no vlan-vc-etype
Parameters
0x0600..0xffff
Specifies a valid VLAN etype identifier.
 
SDP Keepalive Commands
keep-alive
Syntax
keepalive
Context
config>service>sdp
Description
Context for configuring SDP connectivity monitoring keepalive messages for the SDP ID.
SDP-ID keepalive messages use SDP Echo Request and Reply messages to monitor SDP connectivity. The operating state of the SDP is affected by the keepalive state on the SDP-ID. SDP Echo Request messages are only sent when the SDP-ID is completely configured and administratively up. If the SDP-ID is administratively down, keepalives for that SDP-ID are disabled. SDP Echo Requests (when sent for keepalive messages) are always sent with the originator-sdp-id. All SDP-ID keepalive SDP Echo Replies are sent using generic IP/GRE OAM encapsulation.
When a keepalive response is received that indicates an error condition, the SDP ID will immediately be brought operationally down. Once a response is received that indicates the error has cleared and the hold-down-time interval has expired, the SDP ID will be eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP ID will enter the operational state.
A set of event counters track the number of keepalive requests sent, the size of the message sent, non-error replies received and error replies received. A keepalive state value is kept indicating the last response event. A keepalive state timestamp value is kept indicating the time of the last event. With each keepalive event change, a log message is generated indicating the event type and the timestamp value.
The table below describes keepalive interpretation of SDP echo reply response conditions and the effect on the SDP ID operational status.

1
This condition should not occur.

hello-time
Syntax
hello-time seconds
no hello-time
Context
config>service>sdp>keep-alive
Description
Configures the time period between SDP keepalive messages on the SDP-ID for the SDP connectivity monitoring messages.
The no form of this command reverts the hello-time seconds value to the default setting.
Default
hello-time 10 — 10 seconds between keepalive messages
Parameters
seconds
The time period in seconds between SDP keepalive messages, expressed as a decimal integer.
Values
hold-down-time
Syntax
hold-down-time seconds
no hold-down-time
Context
config>service>sdp>keep-alive
Description
Configures the minimum time period the SDP will remain in the operationally down state in response to SDP keepalive monitoring.
This parameter can be used to prevent the SDP operational state from “flapping” by rapidly transitioning between the operationally up and operationally down states based on keepalive messages.
When an SDP keepalive response is received that indicates an error condition or the max-drop-count keepalive messages receive no reply, the sdp-id will immediately be brought operationally down. If a keepalive response is received that indicates the error has cleared, the sdp-id will be eligible to be put into the operationally up state only after the hold-down-time interval has expired.
The no form of this command reverts the hold-down-time seconds value to the default setting.
Default
hold-down-time 10 — The SDP is operationally down for 10 seconds after an SDP keepalive error.
Parameters
seconds
The time in seconds, expressed as a decimal integer, the sdp-id will remain in the operationally down state before it is eligible to enter the operationally up state. A value of 0 indicates that no hold-down-time will be enforced for sdp-id.
Values
max-drop-count
Syntax
max-drop-count count
no max-drop-count
Context
config>service>sdp>keep-alive
Description
This command configures the number of consecutive SDP keepalive failed request attempts or remote replies that can be missed after which the SDP is operationally downed. If the max-drop-count consecutive keepalive request messages cannot be sent or no replies are received, the SDP-ID will be brought operationally down by the keepalive SDP monitoring.
The no form of this command reverts the max-drop-count count value to the default settings.
Default
max-drop-count 3
Parameters
count
The number of consecutive SDP keepalive requests that are failed to be sent or replies missed, expressed as a decimal integer.
Values
message-length
Syntax
message-length octets
no message-length
Context
config>service>sdp>keep-alive
Description
This command configures the SDP monitoring keepalive request message length transmitted.
The
no form of this command reverts the message-length octets value to the default setting.
Default
0 — The message length should be equal to the SDP’s operating path MTU as configured in the path-mtu command. If the default size is overridden, the actual size used will be the smaller of the operational SDP-ID Path MTU and the size specified.
Parameters
octets
The size of the keepalive request messages in octets, expressed as a decimal integer. The size keyword overrides the default keepalive message size.
Values
timeout
Syntax
timeout timeout
no timeout
Context
config>service>sdp>keep-alive
Description
This command configures the time interval that the SDP waits before tearing down the session.
Default
5
Parameters
timeout
The timeout time, in seconds.
Values
Ethernet Ring Commands
eth-ring
Syntax
eth-ring ring-id
no eth-ring
Context
config
Description
This command configures a G.8032 protected Ethernet ring. G.8032 Rings may be configured as major rings with two paths (a&b) or as Sub-Rings with two paths or in the case of an interconnection node a single path.
The no form of this command deletes the Ethernet ring specified by the ring-id.
Default
no eth-ring
Parameters
ring-id
Specifies the ring ID.
Values
description
Syntax
description long-description-string
no description
Context
config>eth-ring
config>eth-ring>path
Description
This command adds a text description for the ring or ring-path. The no form of this command removes the text description.
Default
“Eth ring”
Parameters
long-description-string
Specifies the text description up to 160 characters in length.
guard-time
Syntax
guard-time time
no guard-time
Context
config>eth-ring
Description
This command configures the guard time for an Eth-Ring. The guard timer is standard and is configurable from “x”ms to 2 seconds.
The no form of this command restores the default guard-time.
Default
5 deciseconds
Parameters
value
Specifies the guard-time, in deciseconds.
Values
revert-time
Syntax
revert-time time
no revert-time
Context
config>eth-ring
Description
This command configures the revert time for an Eth-Ring. It ranges from 60 seconds to 720 second by 1 second intervals.
The no form of this command means non-revertive mode and revert time is essentially 0, and the revert timers are not set.
Default
300 seconds
Parameters
value
Specifies the guard-time, in seconds.
Values
ccm-hold-time
Syntax
ccm-hold-time {[down down-timeout] [up up-timeout]}
no ccm-hold-time
Context
config>eth-ring
Description
This command configures eth-ring dampening timers. See the down and up commands for more information.
The no form of the command sets the up and down timers to the default values.
down
Syntax
down down-timeout
Context
config>eth-ring>ccm-hold-time
Description
This command specifies the timer, which controls the delay between detecting that ring path is down and reporting it to the G.8032 protection module. If a non-zero value is configured, the CPM will wait for the time specified in the value parameter before reporting it to the G.8032 protection module.
Note: This parameter applies only to ring path CCM. It does not apply to the ring port link state. To damp ring port link state transitions, use hold-time parameter from the physical member port.
Default
0 — The fault is immediately reported to the protection module.
Parameters
down-timeout
Specifies the down timeout, in centiseconds.
Values
up
Syntax
up up-timeout
Context
config>eth-ring>ccm-hold-time
Description
This command specifies the timer, which controls the delay between detecting that ring path is up and reporting it to the G.8032 protection module. If a non-zero value is configured, the CPM will wait for the time specified in the value parameter before reporting it to the G.8032 protection module.
Note: This parameter applies only to ring path CCM. It does not apply to the member port link state. To damp member port link state transitions, use hold-time parameter from the physical member port.
Default
20 deciseconds
Parameters
up-timeout
Specifies the hold-time for reporting the recovery, in deciseconds.
Values
rpl-node
Syntax
[no] rpl-node [owner | nbr]
Context
config>eth-ring
Description
This command configures the G.8032 ring protection link type as owner or neighbor. When RPL owner or neighbor is specified either the a or b path must be configured with the RPL end command. An owner is responsible for operation of the rpl link. Configuring the RPL as neighbor is optional (can be left as no rpl-node) but if the command is used the nbr is mandatory. On a Sub-ring without virtual channel it is recommended not to configure the rpl-node nbr since this will block additional RAPS messages on the RPL link. By not configuring this mode RPL messages on sub-rings are processed on RPL links.
The no form of this command removes the RPL link, or indicates that the node is not connected to an RPL link.
Default
no rpl-node
node-id
Syntax
node-id mac
no node-id
Context
config>eth-ring
Description
This optional command configures the MAC address of the RPL control. The default is to use the chassis MAC for the ring control. This command allows the chassis MAC to be overridden with another MAC address.
The no form of the command removes the RPL link.
Default
no node-id
Parameters
mac
xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx
sub-ring
Syntax
[no] sub-ring {virtual-link | non-virtual-link}
Context
config>eth-ring
Description
This command additionally specifies this ring-id to be sub-ring as defined in G.80312. By declaring this ring as a sub-ring object, this ring will only have one valid path and the sub-ring will be connected to a major ring or a VPLS instance. The virtual-link parameter declares that a sub-ring is connected to another ring and that control messages can be sent over the attached ring to the other side of the sub-ring. The non-virtual channel parameter declares that a sub-ring may be connected to a another ring or to a VPLS instance but that no control messages from the sub-ring use the attached ring or VPLS instance. The non-virtual channel behavior is standard G.8032 capability.
The no form of this command deletes the sub-ring and its virtual channel associations.
Default
no sub-ring
Parameters
virtual-link
Specifies that the interconnection is to a ring and a virtual link will be used.
non-virtual-link
Specifies that the interconnection is to a ring or a VPLS instance and a virtual link will not be used.
compatible-version
Syntax
compatible-version value
no compatible-version
Context
config>eth-ring
Description
This command configures eth-ring compatibility version for the G.8032 state machine and messages. The default is version 2 and all 7x50 switches use version 2. If there is a need to interwork with third party devices that only support version 1 this can be set to version 1.
The no form of this command set the compatibility version to 2.
Default
2
Parameters
value
The version of the G.8032 state machine.
interconnect
Syntax
[no] interconnect {ring-id ring-id | vpls}
Context
config>eth-ring>sub-ring
Description
This command links the G.8032 sub-ring to a ring instance or to a VPLS instance. The ring instance must be a complete ring with two paths but may itself be a sub-ring or a major ring (declared by its configuration on another node). When the interconnection is to another node, the sub-ring may have a virtual link or a non-virtual-link. When the sub-ring has been configured with a non-virtual link, the sub ring may be alternatively be connected to a VPLS service. This command is on ly valid on the interconnection node where a single sub-ring port connects to a major ring or terminates on a VPLS service.
The no form of this command removes the interconnect node.
Default
no interconnect
Parameters
ring-id
Specifies the identifier for the ring instance of the connection ring for this sub-ring on this node.
Values
vpls
Specifies that the sub-ring is connected to the VPLS instance that contains the sub-ring SAP.
propagate-topology-change
Syntax
[no] propagate-topology-change
Context
config>eth-ring
Description
This command configures the G.8032 sub-ring to propagate topology changes. From the sub-ring to the major ring as specified in the G.8032 interconnection flush logic. This command is only valid on the sub-ring and on the interconnection node. Since this command is only valid on a Sub-ring, a virtual link or non-virtual link must be specified for this command to be configured. The command is blocked on major rings (when both path a and b are specified on a ring).
The no form of this command sets propagate to the default.
Default
no propagate-topology-change
path
Syntax
path {a | b} [{port-id | lag-id} raps-tag qtag1[.qtag2]]
no path {a | b}
Context
config>eth-ring
Description
This command assigns the ring (major or sub-ring) path to a port and defines the Ring APS tag. Rings typically have two paths a and b.
The no form of this command removes the path a or b.
Default
no path
Parameters
port-id
Specifies the port ID.
Values
slot/mda/port
lag-id
Specifies the LAG ID.
Values
lag- — Keyword.
id — Specifies the LAG ID number.
qtag1
Specifies the top/outer VLAN ID.
Values
qtag2
Specifies the bottom/inner VLAN ID.
Values
rpl-end
Syntax
[no] rpl-end
Context
config>eth-ring
Description
This command configures the G.8032 path as a ring protection link end. The ring should be declared as either a RPL owner or RPL neighbor for this command to be allowed. Only path a or path b can be declared an RPL-end.
The no form of this command sets the rpl-end to default no rpl-end.
Default
no rpl-end
eth-cfm
Syntax
eth-cfm
Context
config>eth-ring>path
Description
This command enables the context to configure ETH-CFM parameters.
mep
Syntax
[no] mep mep-id domain md-index association ma-index
Context
config>eth-ring>path>eth-cfm
Description
This command provisions an 802.1ag maintenance endpoint (MEP).
The no form of the command deletes the MEP.
Parameters
mep-id
Specifies the maintenance association end point identifier.
Values
md-index
Specifies the maintenance domain (MD) index value.
Values
ma-index
Specifies the MA index value.
Values
ccm-enable
Syntax
[no] ccm-enable
Context
config>eth-ring>path>eth-cfm>mep
Description
This command enables the generation of CCM messages.
The no form of the command disables the generation of CCM messages.
ccm-ltm-priority
Syntax
ccm-ltm-priority priority
no ccm-ltm-priority
Context
config>eth-ring>path>eth-cfm>mep
Description
This command specifies the priority value for CCMs and LTMs transmitted by the MEP.
The no form of the command removes the priority value from the configuration.
Default
The highest priority on the bridge-port.
Parameters
priority
Specifies the priority of CCM and LTM messages.
Values
eth-test-enable
Syntax
[no] eth-test-enable
Context
config>eth-ring>path>eth-cfm>mep
Description
This command enables eth-test functionality on MEP. For this test to work, operators need to configure ETH-test parameters on both sender and receiver nodes. The ETH-test then can be done using the following OAM commands:
oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
A check is done for both the provisioning and test to ensure the MEP is an Y.1731 MEP (MEP provisioned with domain format none, association format icc-based). If not, the operation fails. An error message in the CLI and SNMP will indicate the problem.
test-pattern
Syntax
test-pattern {all-zeros | all-ones} [crc-enable]
no test-pattern
Context
config>eth-ring>path>eth-cfm>mep>eth-test-enable
Description
This command configures the test pattern for eth-test frames.
The no form of the command removes the values from the configuration.
Default
all-zeros
Parameters
all-zeros
Specifies to use all zeros in the test pattern.
all-ones
Specifies to use all ones in the test pattern.
crc-enable
Generates a CRC checksum.
bit-error-threshold
Syntax
bit-error-threshold bit-errors
Context
config>eth-ring>path>eth-cfm>mep
Description
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
Default
1
Parameters
bit-errors
Specifies the lowest priority defect.
Values
mac-address
Syntax
mac-address mac-address
no mac-address
Context
config>eth-ring>path>eth-cfm>mep
Description
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 SDP).
Parameters
mac-address
Specifies the MAC address of the MEP.
Values
one-way-delay-threshold
Syntax
one-way-delay-threshold time
Context
config>eth-ring>path>eth-cfm>mep
Description
This command configures a one way delay threshold time limit.
Default
3 seconds
Parameters
time
Specifies the value for the threshold.
Values
shutdown
Syntax
[no] shutdown
Context
config>eth-ring>path>eth-cfm>mep
config>eth-ring>path
config>eth-ring
Description
This command administratively disables the entity.
The no form of the command enables the entity.
Default
shutdown
 
ETH-CFM Configuration Commands
eth-cfm
Syntax
eth-cfm
Context
config
Description
This command enables the context to configure 802.1ag CFM parameters.
mep
Syntax
mep mep-id domain md-index association ma-index [vlan vlan-id]
no mep mep-id domain md-index association ma-index [vlan vlan-id]
Context
config>port>ethernet>eth-cfm
config>lag>eth-cfm
config>router>if>eth-cfm
Description
This command provisions the maintenance endpoint (MEP).
The no form of the command reverts to the default values.
Parameters
mep-id mep-id
Specifies the maintenance association end point identifier.
Values
md-index
Specifies the maintenance domain (MD) index value.
Values
ma-index
Specifies the MA index value.
Values
vlan-id
Specific to tunnel facility MEPs which means this option is only applicable to the lag>eth-cfm> context. Used to specify the outer vlan id of the tunnel.
Values
ais-enable
Syntax
[no] ais-enable
Context
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>mep
Description
This command enables the reception of AIS messages.
The no form of the command reverts to the default values.
client-meg-level
Syntax
client-meg-level [[level [level ...]]
no client-meg-level
Context
config>port>ethernet>eth-cfm>mep>ais-enable
config>lag>eth-cfm> mep>ais-enable
Description
This command configures the client maintenance entity group (MEG) level(s) 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. Only the lowest client MEG level will be used for facility MEPs.
The no form of the command reverts to the default values.
Parameters
level
Specifies the client MEG level.
Values
Default
interval
Syntax
interval {1 | 60}
no interval
Context
config>port>ethernet>eth-cfm>mep>ais-enable
config>lag>eth-cfm> mep>ais-enable
Description
This command specifies the transmission interval of AIS messages in seconds.
The no form of the command reverts to the default values.
Parameters
1 | 60
The transmission interval of AIS messages in seconds.
Default
priority
Syntax
priority priority-value
no priority
Context
config>port>ethernet>eth-cfm>mep>ais-enable
config>lag>eth-cfm> mep>ais-enable
Description
This command specifies the priority of the AIS messages generated by the node.
The no form of the command reverts to the default values.
Parameters
priority-value
Specify the priority value of the AIS messages originated by the node.
Values
Default
ccm-enable
Syntax
[no] ccm-enable
Context
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>mep
 
Description
This command enables the generation of CCM messages.
The no form of the command disables the generation of CCM messages.
ccm-ltm-priority
Syntax
ccm-ltm-priority priority
no ccm-ltm-priority
Context
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>mep
config>router>if>eth-cfm>mep
 
Description
This command specifies the priority of the CCM and LTM messages transmitted by the MEP. Since CCM does not apply to the Router Facility MEP only the LTM priority is of value under that context.
The no form of the command reverts to the default values.
Default
priority
Specifies the priority value
Values
Default
ccm-tlv-ignore
Syntax
ccm-tlv-ignore [interface-status][port-status]
no ccm-tlv-ignore
Context
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>mep
config>router>interface>eth-cfm>mep
Description
This command allows the receiving MEP to ignore the specified TLVs in CCM PDU. Ignored TLVs will be reported as absent and will have no impact on the MEP state machine.
The no form of the command means the receiving MEP will process all recognized TLVs in the CCM PDU.
Default
no ccm-tlv-ignore
Parameters
interface-status
ignores the interface status TLV on reception.
port-status
ignores the port status TVL on reception.
eth-test-enable
Syntax
[no] eth-test-enable
Context
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>mep
config>router>if>eth-cfm>mep
Description
For this test to work, operators need to configure ETH-test parameters on both sender and receiver nodes. The ETH-test then can be done using the following OAM commands:
oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
The no form of the command disables eth-test capabilities.
test-pattern
Syntax
test-pattern {all-zeros | all-ones} [crc-enable]
no test-pattern
Context
config>port>ethernet>eth-cfm>mep>eth-test
config>lag>eth-cfm>mep>eth-test
config>router>if>eth-cfm>mep>eth-test
Description
This command specifies the test pattern of the ETH-TEST frames. This does not have to be configured the same on the sender and the receiver.
The no form of the command reverts to the default values.
Parameters
all-zeros
Specifies to use all zeros in the test pattern.
all-ones
Specifies to use all ones in the test pattern.
crc-enable
Generates a CRC checksum.
Default
low-priority-defect
Syntax
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
Context
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>mep
Description
This command specifies the lowest priority defect that is allowed to generate a fault alarm. This setting is also used to determine the fault state of the MEP which, well enabled to do so, causes a network reaction.
Default
macRemErrXcon
Values
mac-address
Syntax
mac-address mac-address
no mac-address
Context
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>mep
config>router>if>eth-cfm>mep
Description
This command specifies the MAC address of the MEP.
The no form of the command reverts to the MAC address of the MEP back to the default, that of the port, since this is SAP based.
Default
no mac-address
Parameters
mac-address mac-address
Specifies the MAC address of the MEP.
Values
facility-fault
Syntax
[no] facility-fault
Context
config>lag>eth-cfm>mep
config>port>ethernet>eth-cfm>mep
Description
Allows the facility MEP to move from alarming only to network actionable function. This means a facility MEP will not merely report the defect conditions but will be able to action based on the transition of the MEP state. Without this command the facility MEP will only monitor and report and conditions of the MEP do not affect related services.
Default
no facility-fault
tunnel-fault
Syntax
tunnel-fault {accept | ignore}
Context
config>service>vpls>eth-cfm
config>service>vpls>sap>eth-cfm
config>service>epipe>eth-cfm
config>service>epipe>sap>eth-cfm
config>service>ipipe>eth-cfm
config>service>ipipe>sap>eth-cfm
config>service>ies>eth-cfm
config>service>ies>if>sap>eth-cfm
config>service>ies>sub-if>grp-if>sap>eth-cfm
config>service>vprn>eth-cfm
config>service>vprn>if>sap>eth-cfm
config>service>vprn>sub-if>grp-if>sap>eth-cfm
Description
Allows the individual service SAPs to react to changes in the tunnel MEP state. When tunnel-fault accept is configured at the service level, the SAP will react according to the service type, Epipe will set the operational flag and VPLS, IES and VPRN SAP operational state will become down on failure or up on clear. This command triggers the OAM mapping functions to mate SAPs and bindings in an Epipe service as well as setting the operational flag. If AIS generation is the requirement for the Epipe services this command is not required. See the ais-enable command under the config>service>epipe>sap>eth-cfm>ais-enable context for more details. This works in conjunction with the tunnel-fault accept on the individual SAPs. Both must be set to accept to react to the tunnel MEP state. By default the service level command is “ignore” and the SAP level command is “accept”. This means simply changing the service level command to “accept” will enable the feature for all SAPs. This is not required for Epipe services that only wish to generate AIS on failure.
Parameters
accept
Shares fate with the facility tunnel MEP.
ignore
Do not share fate with the facility tunnel MEP
Default
ignore (Service Level)
accept (SAP Level for Epipe and VPLS)
domain
Syntax
domain md-index [format {dns | mac | none | string}] name md-name level level
domain md-index
no domain md-index
Context
config>eth-cfm
Description
This command configures Connectivity Fault Management domain parameters.
The no form of the command removes the MD index parameters from the configuration.
Parameters
md-index
Specifies the Maintenance Domain (MD) index value.
Values
format {dns | mac | none | string}
Specifies a value that represents the type (format).
Values
dns: Specifies the DNS name format.
mac: X:X:X:X:X:X-u
X: [0..FF]h
u: [0..65535]d
none: Specifies a Y.1731 domain format and the only format allowed to execute Y.1731 specific functions.
string Specifies an ASCII string.
Default
name md-name
Specifies a generic Maintenance Domain (MD) name.
Values
level level
Specifies the integer identifying the maintenance domain level (MD Level). Higher numbers correspond to higher maintenance domains, those with the greatest physical reach, with the highest values for customers' CFM packets. Lower numbers correspond to lower maintenance domains, those with more limited physical reach, with the lowest values for single bridges or physical links.
Values
association
Syntax
association ma-index [format {icc-based | integer | string | vid | vpn-id}] name ma-name
association ma-index
no association ma-index
Context
config>eth-cfg>domain
Description
This command configures the Maintenance Association (MA) for the domain.
ma-index
Specifies the MA index value.
Values
format {icc-based | integer | string | vid | vpn-id}
Specifies a value that represents the type (format).
Values
icc-based: Only applicable to a Y.1731 context where the domain format is
configured as none. Allows for exactly a 13 character name.
integer : 0 — 65535 (integer value 0 means the MA is not attached to a VID.)
string: raw ascii
vid: 0 — 4095
vpn-id: RFC-2685, Virtual Private Networks Identifier
xxx:xxxx, where x is a value between 00 and FF.
for example 00164D:AABBCCDD
Default
name ma-name
Specifies the part of the maintenance association identifier which is unique within the maintenance domain name.
Values
auto-mep-discovery
Syntax
auto-mep-discovery
[no] auto-mep-discovery
Context
config>eth-cfm>domain>association
Description
Enable/disable the ability to auto-discover remote MEPs from a peer MEP sending ETH-CC.
Default
no auto-mep- discovery
bridge-identifier
Syntax
[no] bridge-identifier bridge-id
Context
config>eth-cfm>domain>association
Description
This command configures the service ID for the domain association. The value must be configured to match the service-id of the service where MEPs for this association will be created. Note that there is no verification that the service with a matching service-id exists. This is not used for facility MEPs as they are not tied to services.
Parameters
bridge-id
Specifies the bridge ID for the domain association.
Values
id-permission
Syntax
id-permission {chassis}
no id-permission
Context
config>eth-cfm>domain>association>bridge-identifier
Description
This command configures the id-permission for the association.
mhf-creation
Syntax
mhf-creation {default | none | explicit | static}
no mhf-creation
Context
config>eth-cfm>domain>association>bridge-identifier
Description
This command determines whether to allow MIP creation for the MA. Use of the none, default and explicit parameters are only allowed for MHFs (MIPs) that are not associated with a configured Primary VLAN. The static parameter is only applicable to MHFs (MIPs) that are associated with a Primary VLAN.
Default
none
Parameters
default
Specifies MHFs (MIPs) can be created for this SAP or Spoke-Sdp without the requirement for a MEP at some lower MA level.
none
Specifies that no MHFs (MIPs) can be created for this SAP or Spoke-SDP.
explicit
Specifies that MHFs (MIPs) can be created for this SAP or Spoke-Sdp only if a MEP is created at some lower MD Level. There must be at least one lower MD Level MEP provisioned on the same SAP or Spoke-SDP.
static
Specifies the exact level of the MHF (MIP) that will be created for this SAP. Multiple MHFs (MIPs) are allowed as long as the MD Level hierarchy is properly configured for the particular Primary VLAN. Ingress MHFs (MIPs) with primary VLAN are not supported on SDP Bindings.
mip-ltr-priority
Syntax
mip-ltr-priority priority
no mip-ltr-priority
Context
config>eth-cfm>domain>association>bridge-identifier
Description
This command allows the operator to set the priority of the Linktrace Response Message (ETH-LTR) from a MIP for this association. If this command is not specified a LTR priority of 7 will be used.
Default
no mip-ltr-priority
Parameters
priority
Specifies the priority of the Linktrace Response Message (ETH-LTR) from a MIP for this association.
Values
vlan
Syntax
vlan vlan-id
no vlan
Context
config>eth-cfm>domain>association>bridge-identifier
Description
This command configures the bridge-identifier primary VLAN ID. Note that it is informational only, and no verification is done to ensure MEPs on this association are on the configured VLAN.
Parameters
vlan-id
Specifies a VLAN ID monitored by MA.
Values
ccm-interval
Syntax
ccm-interval interval
no ccm-interval
Context
config>eth-cfm>domain>association
Description
This command configures the CCM transmission interval for all MEPs in the association.
The no form of the command reverts the value to the default.
Default
10 seconds
Parameters
interval
Specifies the interval between CCM transmissions to be used by all MEPs in the MA.
Values
remote-mepid
Syntax
remote-mepid mep-id remote-mac {unicast-da | default}
no remote-mepid mep-id
Context
config>eth-cfm>domain>association
Description
This command identifies remote maintenance association endpoint (MEP) the systems is expecting to receive packets form. Optionally, the operator may configure a unciast MAC address associated with the remote-mep. This unicast value will replace the default layer two class 1 multicast address that is typically associated with ETH-CC packets.
Note: This command is not supported with sub second CCM intervals. unicast-da may only be configured when a single remote MEP exists in the association.
Default
multicast class 1 address
Parameters
remote-mep mep-id
Specifies the remote MEP identifier.
Values
mep-id 1 — 8191
remote-mac {unicast-da | default}
Specifies the remote MAC type.
Values
default — Removes the unicast address and reverts back to class 1 multicast.
ccm-hold-time
Syntax
ccm-hold-time down delay-down
no ccm-hold-time
Context
config>eth-cfm>domain>association
Description
This command allows a sub second CCM enabled MEP to delay a transition to a failed state if a configured remote CCM peer has timed out. The MEP will remain in the UP state for 3.5 times CCM interval + down-delay.
The no form of this command removes the additional delay
Default
0 second
Parameters
down
Specifies the amount of time to delay in 100ths of a second
Values
slm
Syntax
slm
Context
config>eth-cfm
Description
This is the container that provides the global configuration parameters for ITU-T Synthetic Loss Measurement (ETH-SL).
inactivity-timer
Syntax
inactivity-timer timeout
no inactivity-timer
Context
config>eth-cfm>slm
Description
The time the responder keeps a test active. Should the time between packets exceed this values within a test the responder will mark the previous test as complete. It will treat any new packets from a peer with the same test-id, source-mac and MEP-ID as a new test responding with the sequence number one.
Default
100 seconds
Parameters
timeout
Specifies the amount of time in seconds
Values
ccm-hold-time
Syntax
ccm-hold-time down delay-down
no ccm-hold-time
Context
config>eth-cfm>domain>association
Description
This command allows a sub second CCM enabled MEP to delay a transition to a failed state if a configured remote CCM peer has timed out. The MEP will remain in the UP state for 3.5 times CCM interval + down-delay.
The no form of this command removes the additional delay
Default
0 second
Parameters
down
Specifies the amount of time to delay in 100ths of a second
Values
system
Syntax
system
Context
config>eth-cfm
Description
This command enables the context to configure Connectivity Fault Management General System parameters.
grace-tx-enable
Syntax
[no] grace-tx-enable
Context
config>eth-cfm>system
Description
This command enables and disables the transmission of ETH-VSM messages to delay CCM timeout and AIS churn during ISSU and soft reset functions.
Default
grace-tx-enable
redundancy
Syntax
redundancy
Context
config>eth-cfm
Description
This command provides the context under which the ETH-CFM redundancy parameters are to be configured
Default
none
mc-lag
Syntax
mc-lag
Context
config>eth-cfm>redundancy
Description
This command provides the context under which the MC-LAG specific ETH-CFM redundancy parameters are to be configured
Default
none
propagate-hold-time
Syntax
propagate-hold-time second
no propagate-hold-time
Context
config>eth-cfm>redundancy>mc-lag
Description
This command configures the delay, in seconds, that fault propagation is delayed because of port or MC-LAG state changes. This provides the amount of time for system stabilization during a port state changes that may be protected by MC-LAG. This command requires the standby-mep-shutdown command in order to take effect.
Default
1 second
Parameters
seconds
The amount of time in seconds, zero means no delay.
Values
standby-mep-shutdown
Syntax
standby-mep-shutdown
no standby-mep-shutdown
Context
config>eth-cfm>redundancy>mc-lag
Description
System wide command that enables MEPs to track the state of MC-LAG. This allows MEPs on the standby MC-LAG to act administratively down.
Default
no standby-mep-shutdown
 
ETH-Tunnel Commands
eth-tunnel
Syntax
eth-tunnel tunnel-index
no eth-tunnel tunnel-index
Context
config
Description
This command configures a unique Ethernet Tunnel Identifier for an Ethernet Tunnel Group.
The no form of the command removes the index ID from the configuration.
Default
none
Parameters
tunnel-index
Specifies a tunnel index identifier.
Values
ccm-hold-time
Syntax
ccm-hold-time { down down-timeout | up up-timeout }
no ccm-hold-time
Context
config>eth-tunnel
Description
This command allows a sub second CCM enabled MEP to delay a transition to a failed state if a configured remote CCM peer has timed out. The MEP will remain in the UP state for 3.5 times CCM interval + down-delay.
The no form of this command removes the additional delay
Default
down down-timeout
Specifies the time, in centiseconds, used for the hold-timer for associated Continuity Check (CC) Session down event dampening. This guards against reporting excessive member operational state transitions.
This is implemented by not advertising subsequent transitions of the CC state to the Ethernet Tunnel Group until the configured timer has expired.
Values
Default
up up-timeout
Specifies the time, in deciseconds, used for the hold-timer for associated Continuity Check (CC) Session up event dampening. This guards against reporting excessive member operational state transitions.
This is implemented by not advertising subsequent transitions of the CC state to the Ethernet Tunnel Group until the configured timer has expired.
Values
Default
ethernet
Syntax
ethernet
Context
config>eth-tunnel
Description
This command enables the context to configure Ethernet parameters for the Ethernet tunnel.
encap-type
Syntax
encap-type {dot1q|qinq}
no encap-type
Context
config>eth-tunnel>ethernet
Description
This command configures the encapsulation method used to distinguish customer traffic on a LAG. The encapsulation type is configurable on a LAG port. The LAG port and the port member encapsulation types must match when adding a port member.
If the encapsulation type of the LAG port is changed, the encapsulation type on all the port members will also change. The encapsulation type can be changed on the LAG port only if there is no interface associated with it. If the MTU is set to a non default value, it will be reset to the default value when the encap type is changed.
The no form of this command reverts to the default.
Default
dot1q
Parameters
dot1q
Specifies that frames carry 802.1Q tags where each tag signifies a different service.
qinq
Specifies the qinq encapsulation method.
mac
Syntax
mac ieee-address
no mac
Context
config>eth-tunnel>ethernet
Description
This command assigns a specific MAC address to an Ethernet port, Link Aggregation Group (LAG), Ethernet tunnel, or BCP-enabled port or sub-port.
Only one MAC address can be assigned to a port. When multiple mac commands are entered, the last command overwrites the previous command. When the command is issued while the port is operational, IP will issue an ARP, if appropriate, and BPDU’s are sent with the new MAC address.
The no form of this command returns the MAC address to the default value.
Default
A default MAC address is assigned by the system from the chassis MAC address pool.
Parameters
ieee-address
Specifies the 48-bit MAC address in the form aa:bb:cc:dd:ee:ff or aa-bb-cc-dd-ee-ff where aa, bb, cc, dd, ee and ff are hexadecimal numbers. Allowed values are any non-broadcast, non-multicast MAC and non-IEEE reserved MAC addresses6-byte unicast mac-address (xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx) of the MEP. Using the all zeros address is equivalent to the no form of this command.
lag-emulation
Syntax
lag-emulation
Context
config>eth-tunnel
Description
This command enables the context to configure eth-tunnel loadsharing parameters/
access
Syntax
access
Context
config>eth-tunnel>lag-emulation
Description
This command enables the context to configure eth-tunnel loadsharing access parameters
adapt-qos
Syntax
adapt-qos {distribute|link|port-fair}
no adapt-qos
Context
config>eth-tunnel>lag-emulation>access
Description
This command specifies how the emulated LAG queue and virtual scheduler buffering and rate parameters are adapted over multiple active MDAs.
The no form of the command reverts to the default.
Parameters
distribute
Creates an additional internal virtual scheduler per line card as parent of the configured SAP queues and virtual schedulers per member path on that line card. This internal virtual scheduler limits the total amount of egress bandwidth for all member paths on the line card to that line card’s share of the bandwidth specified in the egress qos policy. This mode is not supported together with an egress port scheduler or the use of egress queue groups.
link
Specifies that the emulated LAG will create the SAP queues and virtual schedulers with the bandwidth specified in the egress QoS policy on each member path.
port-fair
Specifies that the emulated LAG will create the SAP queues and virtual schedulers on each member path based on the bandwidth specified in the egress QoS policy divided by the number of active paths.
 
per-fp-ing-queuing
Syntax
[no] per-fp-ing-queuing
Context
config>eth-tunnel>lag-emulation>access
Description
This command specifies whether a more efficient method of queue allocation for the LAG should be utilized.
The no form of the command disables the method of queue allocation.
path-threshold
Syntax
path-threshold num-paths
no path-threshold
Context
config>eth-tunnel>lag-emulation
Description
This command configures whether a more efficient method of queue allocation for Ethernet Tunnel Group SAPs should be utilized.
The no form of the command reverts the default.
Default
no per-fp-ing-queuing
Parameters
num-paths
Specifies the behavior for the eth-tunnel if the number of operational members is equal to or below a threshold level.
Values
path
Syntax
path
Context
config>eth-tunnel
Description
This command configures one of the two paths supported under the Ethernet tunnel.
The no form of this command removes the path from under the Ethernet tunnel. If this is the last path, the associated SAP need to be un-configured before the path can be deleted.
Default
no path
Parameters
path-index
Specifies the identifier for the path.
Values
control-tag
Syntax
control-tag qtag[.qtag]
no control-tag
Context
config>eth-tunnel>path
Description
This command specifies the VLAN-ID to be used for Ethernet CFM and G.8031 control plane exchanges. If the operator wants to replace an existing control-tag, the parent path needs to be in shutdown state, then deleted and recreated before a new control-tag can be specified.
The no form of this command is used just to indicate that a control-tag is not configured. The procedure described above, based on ‘no path’ command must be used to un-configure/change the control-tag assigned to the path.
Default
no control tag specified
Parameters
vlan-id
specifies the value of the VLAN ID to be used for the control tag.
Values
eth-cfm
Syntax
eth-cfm
Context
config>eth-tunnel>path
Description
This command enables the context to configure ETH-CFM parameters.
mep
Syntax
[no] mep mep-id domain md-index association ma-index
Context
config>eth-tunnel>path>eth-cfm
Description
This command provisions an 802.1ag maintenance endpoint (MEP).
The no form of the command reverts to the default values.
Parameters
mep-id
Specifies the maintenance association end point identifier.
Values
md-index
Specifies the maintenance domain (MD) index value.
Values
ma-index
Specifies the MA index value.
Values
ccm-enable
Syntax
[no] ccm-enable
Context
config>eth-tunnel>path>eth-cfm>mep
Description
This command enables the generation of CCM messages.
The no form of the command disables the generation of CCM messages.
ccm-ltm-priority
Syntax
ccm-ltm-priority priority
no ccm-ltm-priority
Context
config>eth-tunnel>path>eth-cfm>mep
Description
This command specifies the priority value for CCMs and LTMs transmitted by the MEP.
The no form of the command removes the priority value from the configuration.
Default
The highest priority on the bridge-port.
Parameters
priority
Specifies the priority of CCM and LTM messages.
Values
ccm-padding-size
Syntax
ccm-padding-size ccm-padding
no ccm-padding-size
Context
config>eth-tunnel>path>eth-cfm>mep
Description
This command inserts additional padding in the CCM packets.
The no form of the command reverts to the default.
Parameters
ccm-padding
Specifies the additional padding in the CCM packets.
Values
control-mep
Syntax
[no] control-mep
Context
config>eth-tunnel>path>eth-cfm>mep
Description
This command enables the Ethernet ring control on the MEP. The use of control-mep command is mandatory for a ring. MEP detection of failure using CCM may be enabled or disabled independently of the control mep.
The no form of this command disables Ethernet ring control.
Default
no control-mep
eth-test-enable
Syntax
[no] eth-test-enable
Context
config>eth-tunnel>path>eth-cfm>mep
Description
This command enables eth-test functionality on MEP. For this test to work, operators need to configure ETH-test parameters on both sender and receiver nodes. The ETH-test then can be done using the following OAM commands:
oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
A check is done for both the provisioning and test to ensure the MEP is an Y.1731 MEP (MEP provisioned with domain format none, association format icc-based). If not, the operation fails. An error message in the CLI and SNMP will indicate the problem.
rpl-node
Syntax
rpl-node [owner | nbr]
no rpl-node
Context
config>eth-ring
 
The no form of this command removes the RPL link.
Default
no rpl-node
bit-error-threshold
Syntax
bit-error-threshold bit-errors
Context
config>eth-ring>path>eth-cfm>mep
Description
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
Default
1
Parameters
bit-errors
Specifies the lowest priority defect.
Values
test-pattern
Syntax
test-pattern {all-zeros|all-ones} [crc-enable]
no test-pattern
Context
config>eth-ring>path>eth-cfm>mep>eth-test-enable
Description
This command configures the test pattern for eth-test frames.
The no form of the command removes the values from the configuration.
Parameters
all-zeros
Specifies to use all zeros in the test pattern.
all-ones
Specifies to use all ones in the test pattern.
crc-enable
Generates a CRC checksum.
Default
all-zeros
low-priority-defect
Syntax
low-priority-defect {allDef|macRemErrXcon|remErrXcon|errXcon|xcon|noXcon}
Context
config>eth-tunnel>path>eth-cfm>mep
Description
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
Default
remErrXcon
Values
mac-address
Syntax
mac-address mac-address
no mac-address
Context
config>eth-tunnel>path>eth-cfm>mep
Description
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 SDP).
Parameters
mac-address mac-address
Specifies the MAC address of the MEP.
Values
one-way-delay-threshold
Syntax
one-way-delay-threshold seconds
Context
config>eth-tunnel>path>eth-cfm>mep
Description
This command enables one way delay threshold time limit.
Default
3 seconds
Parameters
priority
Specifies the value for the threshold.
Values
member
Syntax
member port-id
no member
Context
config>eth-tunnel>path
Description
This command configures the path member.
The no form of the command removes the port-id from the configuration.
Default
none
Parameters
port-id
Specifies the path member
Values
precedence
Syntax
precedence {primary|secondary}
Context
config>eth-tunnel>path
Description
This command specifies the precedence to be used for the path. Only two precedence options are supported: primary and secondary.
The no form of this command sets the precedence to the default value.
Default
secondary
Parameters
primary | secondary
specifies the path precedence as either primary or secondary.
protection-type
Syntax
protection-type {g8031-1to1|loadsharing}
Context
config>eth-tunnel
Description
This command configures the model used for determining which members are actively receiving and transmitting data.
When the value is set to 'g8031-1to1 (1)', as per G.8031 spec, only two members are allowed, and only one of them can be active at one point in time.
When the value is set to 'loadsharing (2)', multiple members can be active at one point in time.
Default
g8031-1to1
revert-time
Syntax
revert-time time
no revert-time
Context
config>eth-tunnel
Description
This command configures the revert time for an Eth tunnel. It ranges from 60 seconds to 720 second by 1 second intervals.
The no form of this command this command means non-revertive mode and revert time essentially is 0 meaning the revert timers are not set.
Default
300 seconds
Parameters
value
Specifies the guard-time.
Values
 
Tools Perform Commands
tools
Syntax
tools
Context
root
Description
This command enables the context to enable useful tools for debugging purposes.
Default
none
Parameters
dump
Enables dump tools for the various protocols.
perform
Enables tools to perform specific tasks.
perform
Syntax
perform
Context
tools
Description
This command enables the context to enable tools to perform specific tasks.
Default
none
service
Syntax
services
Context
tools>perform
Description
This command enables the context to configure tools for services.
id
Syntax
id service-id
Context
tools>perform>service
Description
This command enables the context to configure tools for a specific service.
Parameters
service-id
Specify an existing service ID.
Values
admin-lock
Syntax
admin-lock
Context
tools>perform>service>id
Description
This command enters the context for applying an administrative lock for a spoke-sdp that is bound to a VLL SAP, another spoke-sdp or a VPLS interface for an MPLS-TP PW. Once the PW is locked it may be put into loopback mode.The command must be executed at both ends of the PW or MS-PW represented by the spoke-SDP. Test traffic can then be injected using a test SAP.
loopback
Syntax
loopback
Context
tools>perform>service>id
Description
Tools for placing and removing SAPs and SDP bindings in data loopback. Overwrite will occur for any SAP or SDP Binding when issuing a subsequent loopback command on the same SAP or SDP Binding.
Interactions: Loopback functions are only applicable to epipe, PBB ePipe, VPLS, I-VPLS and PBB core service contexts.
eth
Syntax
eth
Context
tools>perform>service>id>loopback
Description
This command enables the context to configure a loopback on Ethernet SAPs or MPLS SDP bindings.
pw
Syntax
pw
Context
tools>perform>service>id>admin-lock
tools>perform>service>id>loopback
Description
In the admin-lock context, this command administratively locks the specified spoke-sdp by locking the host service.The command must be executed at both ends of the PW or MS-PW represented by the spoke-SDP. Test traffic can then be injected using a test SAP.
In the loopback context, this command enters the MPLS-TP PW context for starting or stopping a loopback on a specified spoke-SDP. An administrative lock should first be applied to both ends of the PW or MS-PW represented by the spoke-SDP prior to configuring the loopback.
Interactions: Loopback functions for MPLS-TP pseudowire can be specified for either a T-PE or S-PE.
sap
Syntax
sap sap-id start mode [mac-swap [mac ieee-address [all]]]
sap sap-id stop
Context
tools>perform>service>loopback>eth
Description
This command places and removes the specific SAP in loopback mode for reflecting Ethernet traffic back in the direction of the received stream. This is only applicable to Ethernet-based SAPs.
Parameters
sap-id
Specifies the SAP ID.
Values
null port-id | lag-id
dot1q port-id | lag-id :qtag1
qinq port-id | lag-id :qtag1.qtag2
port-id slot/mda/port
lag-id lag-id
lag keyword
id [1..800]
qtag1 [0..4094]
qtag2 [*|0..4094]
start
keyword that places the sap in loopback mode.
mode
Keywords that specify the location on the loopback in relation to the SAP.
Values
ingress — Traffic arriving at the sap-ingress will be reflected back out the same SAP.
egress — Traffic arriving at the sap-egress will be reflected back into the service in the direction of the original source.
stop
removes the SAP from loopback mode.
mac-swap
enable source address and destination address swapping for the reflected packets when the arriving packet is unicast. Any broadcast and multicast packets arriving on a looped point will be dropped.
mac ieee-address
Optionally configures the source MAC address used in the reflected packet when the arriving packet is a broadcast or multicast. This does not apply to arriving unicast packets.
6-byte unicast mac-address in the form xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx.
all
Configured ieee-address is used as the source address for all reflected packets regardless of the arriving destination.
sdp
Syntax
sdp sdp-id:vc-id start mode [mac-swap [mac ieee-address [all]]]
sdp sdp-id:vc-id stop
Context
tools>perform>service>loopback>eth
Description
This command places the specific MPLS SDP binding in loopback mode for reflecting Ethernet traffic back in the direction of the received stream. This is only applicable to MPLS SDP Bindings.
Parameters
sdp-id:vc-id
Specifies the SDP ID and VC-ID.
Values
start mode
Specifies the loopback in relation to the MPLS SDP Binding..
Values
ingress — Traffic arriving at the sap-ingress will be reflected back out the same sap.
egress — Traffic arriving at the sap-egress will be reflected back into the service in the
direction of the original source.
stop
rkeyword that removes the MPLS SD- binding from loopback mode.
mac-swap
enable source address and destination address swapping for the reflected packets when the arriving packet is unicast. Any broadcast and multicast packets arriving on a looped point will be dropped.
mac ieee-address
Optionally configure the source MAC address used in the reflected
packet when the arriving packet is a broadcast or multicast. This does not apply to
arriving unicast packets.
Values
all
Configured ieee-address is used as the source address for all reflected packets regardless of the arriving destination.
mac-swap
no swapping of MAC addresses are performed without specifying this option and any non-unicast destined packets will not be reflected back to the source.
sdp
Syntax
sdp sdp-id:vc-id {start | stop}
Context
tools>perform>service>loopback>pw
Description
This command places or removes the specified MPLS-TP SDP binding in loopback mode for the purpose of an MPLS-TP pseudowire test service. Note that the loopback is created at the PW level so everything under the PW label is looped back. It is recommended to configure an administrative lock for the MPLS-TP pseudowire for the specified test service prior to configuring the loopback.
Parameters
sdp-id:vc-id
Specifies the SDP-ID and VC-ID.
Values
start
keyword that places the specified MPLS-TP PW in loopback mode for the purpose of an MPLS_TP PW test service.
stop
rkeyword that removes the SDP binding from the loopback mode for the MPLS-TP pseudowire test service.
sdp
Syntax
sdp sdp-id:vc-id admin-lock [test-svc-id id]
Context
tools>perform>service>admin-lock>pw
Description
This command specifies the spoke-sdp binding to which an administrative lock will be applied for the MPLS-TP pseudowire. The administrative lock can be placed on a spoke SDP that is bound to a VLL SAP, another spoke-sdp or a VPLS interface. Once the pseudowire is locked it may be put into loopback mode.The command must be executed at both ends of the pseudowire or MS-PW represented by the spoke-SDP. Test traffic can then be injected using a configured test SAP on an Epipe, Apipe or Cpipe.
Parameters
sdp-id:vc-id
Specifies the SDP-ID and VC-ID.
Values
admin-lock
keyword that specifies an administrative lock is placed for the specified test service ID.
stop
rkeyword that specifies the ID of a test service (SAP) to which the SDP is bound.