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.
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.
[no
] new-qinq-untagged-sap
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.
The no form of this command removes the contact information from the customer ID.
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 7750 SR-1 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).
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).
|
If the customer-site-name is invalid, a syntax error occurs; the command will not execute and the CLI context will not change.
The no form of this command removes the phone number value from the customer ID.
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.
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 channelmust already have been pre-provisioned on the system but need not be installed when the customer site assignment is made.
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 — 200 lag-id lag- id lag keyword id 1 — 64
|
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.
agg-rate-limit {max
| kilobits-per-second
} [queue-frame-based-accounting
]
config>service>customer>multi-service-site>egress
This command defines a maximum total rate for all egress queues on a service SAP or multi-service site. The agg-rate-limit command is mutually exclusive with the egress scheduler policy. When an egress scheduler policy is defined, the
agg-rate-limit command will fail. If the
agg-rate-limit command is specified, at attempt to bind a
scheduler-policy to the SAP or multi-service site will fail.
A multi-service site must have a port scope defined that ensures all queues associated with the site are on the same port or channel. If the scope is not set to a port, the agg-rate-limit command will fail. Once an agg-rate-limit has been assigned to a multi-service site, the scope cannot be changed to card level.
A port scheduler policy must be applied on the egress port or channel the SAP or multi-service site are bound to in order for the defined agg-rate-limit to take effect. The egress port scheduler enforces the aggregate queue rate as it distributes its bandwidth at the various port priority levels. The port scheduler stops offering bandwidth to member queues once it has detected that the aggregate rate limit has been reached.
The no form of the command removes the aggregate rate limit from the SAP or multi-service site.
[no
] scheduler
scheduler-name
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:
3.
|
The create keyword is entered with the command if the system is configured to require it (enabled in the environment create command).
|
Default
|
None. Each scheduler must be explicitly created.
|
rate pir-rate [cir
cir-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.
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.
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.
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.
scheduler-policy scheduler-policy-name
config>service>customer>multi-service-site>ingress
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 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.
[no
] mrp-policy
policy-name
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.
scope {exclusive | template
}
The no form of the command sets the scope of the policy to the default of template.
The no form of the command removes the match criteria for the entry-id.
[no
] isid
value | from
value to
higher-value
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.
from value
to higher-value
action {block | allow | end-station
}
The no form of the command removes the specified action statement. The entry is considered incomplete and hence rendered inactive without the action keyword.
renum old-entry-id to
new-entry-id
The no form of the command removes thegroup. All the object associations need to be removed before the no command can be executed.
The no form sets the values back to the defaults.
The no form sets the values back to the default.
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.
The no form of this command removes a previously configured timer and restores it to its default.
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.
Values
|
community {2-byte-as-number:comm-va1} 2-byte-asnumber 0— 65535 comm.-val 0 — 65535
|
The no form of the command removes a specified explicit path from the configuration.
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.
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.
The no form of this command reverts the timer to its default value.
The no form of this command removes the configured S-PE Address.
Syntax: <global-id:prefix>: <global-id>:{<prefix>|<ipaddress>}
global-id 1 — 4294967295
prefix 1 — 4294967295
ipaddress a.b.c.d
[no
] static-route
route-name
The no form of this command removes a previously configured static route.
[no
] pw-template
sdp-template-id [use-provisioned-sdp
] [create
]
sdp sdp-id [gre
| mpls
] [create]
An SDP is a logical mechanism that ties a far-end 7750 SR to a particular service without having to specifically define far end SAPs. Each SDP represents a method to reach a 7750 SR router.
If sdp-id does not exist, a new SDP is created. When creating an SDP, either the
gre or the
mpls 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 nor the
mpls 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.
[no
] auto-learn-mac-protect
This command specifies whether to enable autoAuto-Learn MAC Protectatic 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
Auto-Learn MAC Protect.
The no form of the command disables the automatic population of the MAC protect list.
The no form of this command removes the accounting policy association from the SDP, and the acccounting policy reverts to the default.
The no form of the command disables resolving BGP route tunnel LSP for SDP far-end.
The no form of the command reverts to the default value.
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.
The no form of the command reverts the mesh SDP or spoke-sdp to the default behavior of not using the control word.
The no form of this command enables aging.
The no form of this command enables learning of MAC addresses.
[no
] discard-unknown-source
The no form of this command causes packets with an unknown source MAC addresses to be forwarded by destination MAC addresses.
no filter [ip
ip-filter-id] [mac
mac-filter-id] [ipv6
ipv6-filter-id]
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.
qos network-policy-id port-redirect-group
queue-group-name [instance
instance-id]
The no version of this command removes the redirection of the pseudowire to the queue-group.
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.
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.
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 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.
[no
] force-vlan-vc-forwarding
The no version of this command sets default behavior.
qos network-policy-id fp-redirect-group
queue-group-name instance
instance-id
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).
The no form of the command restores the global MAC learning limitations for the SAP or spoke SDP.
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.
The no form of the command removes the policy association.
no import — No import policy is specified.
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.
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.
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.
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.
[no
] sdp-include
group-name
•
|
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.
|
The no form of this command removes the SDP admin group constraints from the PW template.
[no
] sdp-exclude
group-name
•
|
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.
|
The no form of this command removes the SDP admin group constraints from the PW template.
[no
] split-horizon-group
[group-name] [residential-group]
The no form of the command removes the group name from the configuration.
[no
] auto-learn-mac-protect
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.
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. “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.
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.
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)
Defines the VC type as VLAN. The ethernet and
vlan keywords are mutually exclusive. When the VC type is not defined then the default is Ethernet for spoke SDP bindings.
The no form of this command disables the command
The no form of the command disables the VC-type MTU override and returns to the default behavior.
The no form of the command removes the value from the configuration.
pw-port pw-port-id [vc-id
vc-id] [create
]
The no form of the command removes the pseudowire port ID from the configuration.
The no form of the command reverts to the default value.
Specifies ether as the virtual circuit (VC) associated with the SDP binding.
Specifies vlan as the virtual circuit (VC) associated with the SDP binding.
The no form of the command reverts to the default value.
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.
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.
no class-forwarding — Packets of a service bound to this SDP will be forwarded based on the hash algorithm used for LAG and ECMP.
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.
[no
] enforce-diffserv-lsp-fc
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.
The no form of this command reverts to the default value which is to use the user entered mapping of FC to LSP name.
far-end ip-address | {node-id node-id [global-id global-id]}
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, and SDP that uses MPLS can have an MPLS-TP node with an MPLS-TP node-id and (optioanlly) 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 dev ice 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.
fc {be
| l2
| af
| l1
| h2
| ef
| h1
| nc
} lsp
lsp-name
no fc {be
| l2
| af
| l1
| h2
| ef
| h1
| nc
}
In MPLS SDP configurations either one LSP can be specified
or LDP can be enabled. The SDP
ldp and
lsp commands are mutually exclusive. 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.
In MPLS SDP configurations either one LSP can be specified
or LDP can be enabled. The SDP
ldp and
lsp commands are mutually exclusive. 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.
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).
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.
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.
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.
[no
] sdp-group
group-name
The no form of this command removes this SDP membership to the specified admin group.
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.
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.
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.
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.
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.
The default path-mtu defined on the system for the type of SDP is used.
Values
|
0x0600.. 0xffff: 1536 — 65535 (accepted in decimal or hex)
|
The no form of this command returns the value to the default.
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.
The table below describes keepalive interpretation of SDP echo reply response conditions and the effect on the SDP ID operational status.
The no form of this command reverts the
hello-time seconds value to the default setting.
hello-time 10 — 10 seconds between 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.
hold-down-time 10 — The SDP is operationally down for 10 seconds after an SDP keepalive error.
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.
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.
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]
The no form of the command reverts to the default values.
The no form of the command reverts to the default values.
The no form of the command reverts to the default values.
The no form of the command reverts to the default values.
The no form of the command reverts to the default values.
The no form of the command disables the generation of CCM messages.
The no form of the command reverts to the default values.
The no form of the command means the receiving MEP will process all recognized TLVs in the CCM PDU.
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.
The no form of the command reverts to the default values.
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.
accept (SAP Level for Epipe and VPLS)
domain md-index [format
{dns
| mac | none
| string
}] name
md-name level
level
The no form of the command removes the MD index parameters from the configuration.
format {dns
| mac
| none
| string
}
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.
|
association ma-index [format
{icc-based
| integer
| string
| vid
| vpn-id
}] name
ma-name
format {icc-based
| integer
| string
| vid
| vpn-id
}
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
|
[no
] bridge-identifier
bridge-id
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.
The no form of the command reverts the value to the default.
[no
] remote-mepid
mep-id remote-mac
{unicast-da | default}
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.
remote-mac {
unicast-da | default}
The no form of this command removes the additional delay
The no form of this command reverts to the default.
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.
The no form of the command reverts to the default.
The no form of the command disables the method of queue allocation.
The no form of the command reverts the default.
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.
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.
[no
] mep
mep-id domain
md-index association
ma-index
The no form of the command reverts to the default values.
The no form of the command disables the generation of CCM messages.
The no form of the command removes the priority value from the configuration.
The no form of the command reverts to the default.
The no form of this command disables Ethernet ring control.
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 removes the values from the configuration.
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).
The no form of the command removes the port-id from the configuration.
The no form of this command sets the precedence to the default value.
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.
Interactions: Loopback functions are only applicable to epipe, PBB ePipe, VPLS, I-VPLS and PBB core service contexts.
sap sap-id start
mode [mac-swap
[mac
ieee-address [all
]]]
null port-id |
lag-id
dot1q
port-id | l
ag-id :qtag1
qinq
port-id | l
ag-id :qtag1.qtag2
port-id
slot/
mda/
port
lag-id lag-
id
lag
keyword
id [1..200]
qtag1 [0..4094]
qtag2 [*|0..4094]
keyword that places the sap in loopback mode.
mode ingress |
egress : keywords that specifies the location on the loopback in relation
to the SAP.
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.
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.
Value: 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.
Default
|
[no] 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 sdp-id:vc-id start
mode [mac-swap
[mac
ieee-address [all
]]]
keyword that places the sap in loopback mode.
mode ingress |
egress : keywords that specifies the location on the loopback in relation
to the MPLS SDP Binding.
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.
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.
Value: 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.
Default
|
[no] 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.
|