3.17. Global Service Command Reference

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

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

The shutdown command administratively disables an entity. The operational state of the entity is disabled as well as the operational state of any entities contained within. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many objects must be shut down before they may be deleted. Many entities must be explicitly enabled using the no shutdown command.

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

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

This command controls the behavior of qinq SAP y.0 (for example, 1/1/1:3000.0). If this command is enabled, the y.0 SAP maps all ingress frames tagged with outer tag VLAN ID of y (qinq Ethertype) and no inner tag, or with an inner tag VLAN ID of zero (0). This behavior applies to all existing and future y.0 SAPs.

The no form of this command disables qinq untagged SAP, and the y.0 SAP will work like a 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).

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 and the create keyword must follow each new customer customer-id entry.

To edit a customer’s parameters, enter the existing customer customer-id without the create keyword.

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.

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.

The no form of this command removes the contact information from the customer ID.

This command adds telephone number information for a customer ID.

The no form of this command removes the phone number value from the customer ID.

This command creates or edits an SDP. SDPs must be explicitly configured.

An SDP is a (logical) service entity that is created on the local router. An SDP identifies the endpoint of a logical, unidirectional service tunnel. Traffic enters the tunnel at the SDP on the local router and exits the tunnel at the remote router. Thus, it is not necessary to specifically define far-end SAPs.

The 7705 SAR supports generic routing encapsulation (GRE) tunnels, multiprotocol label switching (MPLS) tunnels, and IP tunnels.

For MPLS, the 7705 SAR 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 LSPs are established in LDP-DU (downstream unsolicited) mode. Segment routing (SR) is another MPLS tunnel type and is used to allow service binding to an SR tunnel programmed in the tunnel table manager (TTM) by OSPF or IS-IS. An SDP of type sr-isis or sr-ospf can be used with the far-end option.

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. SDPs are created in the admin down state (shutdown). Once all relevant parameters are defined, the no shutdown command must be executed before the SDP can be used.

If sdp-id exists, the current CLI context is changed to that SDP for editing and modification. If editing an existing SDP, the gre, mpls, or ip keyword is not specified. If a keyword is specified for an existing sdp-id, an error is generated and the context of the CLI is not 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 fails, generating an error message specifying the first bound service found during the deletion process. If the specified sdp-id does not exist, an error is generated.

This command overrides the advertised VC-type MTU. When enabled, the 7705 SAR signals a VC MTU equal to the service MTU that includes the Layer 2 header. Under normal operations it will advertise the service MTU minus the Layer 2 header. In the receive direction, it will accept either one.

The no form of this command disables the VC-type MTU override.

This command enables GRE-encapsulated packets transmitted from the SDP to be fragmented if their size exceeds the configured network port MTU.

When allow-fragmentation is enabled, GRE-encapsulated packets that are larger than the network port MTU are fragmented and the DF bit is set to 0 by the router. Packets that are smaller than the port MTU are left unfragmented, the DF bit is set to 1 by the router, and the identification number of the packet is set to 0.

Fragmentation is supported on an SDP that has NGE (encryption-keygroup) enabled. To determine if an encrypted packet needs to be fragmented, the system compares the total packet size after NGE encryption to the network port MTU. If the encrypted packet size is larger than the MTU, the packet is fragmented. NGE decryption is performed after the packet is fully reassembled.

The no form of the command disables fragmentation of oversize GRE-encapsulated packets transmitted from the SDP.

This command allows the use of BGP route tunnels available in the tunnel table to reach SDP far-end nodes. BGP route tunnels are only available with MPLS SDPs. Only one transport method is allowed per SDP: LDP, RSVP-LSP, BGP-tunnel, SR-ISIS, SR-OSPF, or SR-TE-LSP. This restriction is relaxed for some combinations of the transport methods when the mixed-LSP mode option is enabled on the SDP.

The no form of the command disables the use of BGP route tunnels for the SDP far end.

This command is used to bind a key group to an SDP for inbound or outbound packet processing. When configured in the outbound direction, packets egressing the node use the active-outbound-sa associated with the key group configured. When configured in the inbound direction, received packets must be encrypted using one of the valid security associations configured for the key group. Services using the SDP will be encrypted.

Encryption is enabled once the outbound direction is configured.

The no form of the command removes the key group from the SDP in the specified direction (inbound or outbound).

This command configures the system IP address of the far-end destination 7705 SAR, 7750 SR, or other router ID platform for the SDP that is the termination point for a service.

The far-end IP address must be explicitly configured. The destination IP address must be a 7705 SAR, 7750 SR, or other router ID platform system IP address.

If the SDP uses GRE or IP for the destination encapsulation, the local 7705 SAR might not know that the ip-address is actually a system IP interface address on the far-end service router.

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 message will be generated.

An SDP cannot be administratively enabled until a far-end ip-address is defined. The SDP is operational when it is administratively enabled (no shutdown).

The no form of this command removes the currently configured destination IP address for the SDP. The ip-address and ipv6-address parameters are not specified and will generate an error message 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.

This command enables LDP-signaled LSPs on MPLS-encapsulated SDPs.

In MPLS SDP configurations, up to eight RSVP-TE LSPs can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive unless mixed-LSP SDP is enabled with the mixed-lsp-mode command.

If mixed-LSP SDP is not enabled and an LSP is specified on an MPLS SDP, 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.

This command creates an association between an LSP and an MPLS SDP. This command is implemented only on MPLS-encapsulated SDPs. Up to eight RSVP-TE LSPs can be associated with a single SDP. The LSPs must have already been created in the config>router>mpls context with a valid far-end IP address. Refer to the 7705 SAR MPLS Guide for CLI syntax and command usage.

In MPLS SDP configurations, LSPs can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive unless mixed-LSP SDP is enabled with the mixed-lsp-mode command.

If mixed-LSP SDP is not enabled and LDP is already enabled on an MPLS SDP, an LSP cannot be specified on the SDP. To specify an LSP on the SDP, LDP must be disabled.

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 can be shut down, causing the association with the SDP to be operationally down (the LSP will not be used by the SDP).

LSP SDPs also require that the T-LDP signaling be specified and that the SDP keepalive parameter be enabled and not timed out.

The no form of this command deletes an LSP association 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.

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 tiebreaker by tunnel table manager users to select the route with the lower value.

This command enables the mixed-LSP mode of operation on an SDP, which allows a primary LSP type and a backup LSP type in the same SDP configuration. For example, RSVP-TE LSPs and LDP LSPs can be configured on an SDP with the lsp and ldp commands. If mixed-LSP mode is not enabled, these commands are mutually exclusive.

Two combinations of mixed LSPs are possible:

Note: Mixed-LSP SDPs do not support static LSPs on either the primary or backup.

The no form of this command disables mixed-LSP; however you must remove one of the LSP types from the SDP configuration first or the command will fail.

This command configures the length of time that the service manager must wait before it resets the SDP configuration 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 that the service manager resets the SDP configuration immediately to a higher-priority LSP type when one becomes available.

This command configures the Maximum Transmission Unit (MTU) in bytes that the SDP can transmit to the far-end router without packet dropping or IP fragmentation overriding the default SDP-type path MTU.

The default SDP-type path-mtu can be overridden on a per-SDP basis.

Dynamic maintenance protocols on the SDP may override this setting.

If the physical mtu on an egress interface indicates that 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.

This command specifies the signaling protocol used to obtain the ingress and egress 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 signaling value can only be changed while the administrative status of the SDP is down.

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.

This command configures an MPLS SDP of LSP type IS-IS 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) or T-LDP (tldp).

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) or T-LDP (tldp).

This command configures an MPLS SDP of LSP type SR-TE. Up to eight SR-TE LSPs can be configured under an SDP.

The mixed-lsp-mode option does not support the sr-te tunnel type.

The signaling protocol for the service labels for an SDP using an SR-TE LSP can be configured to static (off) or T-LDP (tldp).

This command configures the VLAN VC Ethertype. The no form of this command returns the value to the default. The etype value populates the Ethertype field in the Ethernet frame. It is used to indicate which protocol is being transported in the Ethernet frame. The default value indicates that the payload is an IEEE 802.1q-tagged frame.

This command enables weighted ECMP for IES or VPRN Layer 3 spoke SDP interfaces. This command is applicable when the SDP has RSVP-TE LSPs configured using the config>service>sdp>lsp command or SR-TE LSPs configured using the config>service>sdp>sr-te-lsp command.

When weighted ECMP is enabled on an SDP, a path is selected based on the configured hash. Paths are then load-balanced across the LSPs used by the SDP according to the normalized LSP load-balancing weight configured using the load-balancing-weight command described in the 7705 SAR MPLS Guide, “MPLS Commands”. This means that consecutive packets of a particular service use the same LSP, but the overall load handled by LSPs to the SDP far end is balanced according to the load-balancing weight if all services using the SDP send the same bandwidth and there are more services using the SDP than there are LSPs for the SDP.

If an LSP in the ECMP set has no load-balancing weight configured, then ECMP is applied to packets based on the output of the hash for the service ID.

The no form of the command disables weighted ECMP for the SDP.

This command is the 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 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.

Table 13 describes keepalive interpretation of SDP Echo Reply response conditions and the effect on the SDP ID operational status.

This command configures the time period between SDP keepalive messages on the SDP-ID for the SDP connectivity monitoring messages.

The no form of this command resets the hello-time seconds value to the default setting.

This command 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 resets the hold-down-time seconds value to the default setting.

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 resets the max-drop-count count value to the default settings.

This command configures the size of SDP monitoring keepalive request messages transmitted on the SDP.

The no form of this command resets the message-length octets value to the default setting.

This command configures the time interval that the SDP waits before tearing down the session.

This command configures a G.8032 Ethernet ring. Ethernet rings may be configured as major rings with two paths (A and B), 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 specified Ethernet ring.

This command configures Ethernet ring dampening timers.

The no form of the command sets the up and down timers to the default values.

This command configures Ethernet ring compatibility version for the G.8032 state machine and messages. The default is version 2 and all router switches use version 2. The version can be changed if there is a need to interwork with third party devices that only support version 1.

The no form of this command sets the compatibility version to 2.

This command configures the guard time for an Ethernet ring.

The no form of this command restores the default guard time.

This optional command configures the MAC address of the RPL link. The default is to use the chassis MAC address for the ring control. This command allows the chassis MAC address to be overridden with another MAC address.

The no form of the command removes the RPL link.

This command assigns the Ethernet ring (major or sub-ring) path to a port and defines the Ethernet ring APS tag. Rings typically have two paths, A or B.

The no form of this command removes the configured path.

This command enables the context to configure Ethernet CFM parameters.

This command provisions an 802.1ag maintenance endpoint (MEP).

The no form of the command deletes the MEP.

This command enables the generation of CCM messages.

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

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

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

This command enables Ethernet ring control on the MEP. Configuration of this command is mandatory for a ring. MEP detection of failure using CCM can be enabled or disabled independently of the control MEP.

The no form of this command disables Ethernet ring control.

This command enables Ethernet test functionality on the MEP. For the test to work, operators need to configure Ethernet test parameters on both the sender and receiver nodes. The Ethernet test can be performed using the oam>eth-cfm>eth-test command.

A check is done for both the provisioning and the test to ensure the MEP is a Y.1731 MEP, provisioned with domain format none and associated with format icc-based. If they are not, the command fails and an error message is generated in the CLI and SNMP indicating the problem.

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

This command configures the test pattern for Ethernet test frames.

The no form of the command removes the test pattern from the Ethernet test configuration.

This command specifies the lowest priority defect that will generate a fault alarm.

This command configures a one-way delay threshold time limit.

This command configures the G.8032 path as a ring protection link (RPL) end. The ring must be declared as either an RPL owner or an RPL neighbor in order for this command to be valid. Only a path configured as A or B can be configured as an RPL end.

The no form of this command reverts to the default.

This command configures the revert time for an Ethernet ring. It ranges from 60 s to 720 s.

The no form of this command means that the Ethernet ring is in non-revertive mode and the revert time is essentially 0. The revert timers are not set.

This command configures the G.8032 ring protection link type as either owner or neighbor. The no form of the command means this node is not connected to an RPL link. When an 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. The link can be left with no RPL type configured, but if this command is used the nbr parameter is mandatory.

On a sub-ring without a virtual channel, it is mandatory to configure a sub-ring non-virtual-link on all nodes on the sub-ring to propagate the RAPS messages around the sub-ring.

The no form of this command removes the RPL link.

This command defines an Ethernet ring as a sub-ring as defined in G.8032. A sub-ring can have only one valid path connecting it to a major ring or to a VPLS instance. The virtual-link parameter indicates 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-link channel parameter indicates that a sub-ring may be connected to a another ring or to a VPLS instance but that control messages from the sub-ring can not 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.

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, as 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 only 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.

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 a sub-ring and the interconnection node. A virtual link or non-virtual link must be specified for this command to be valid. The command is blocked on major rings (when both path A and B are specified on a ring).

The no form of this command disables topology propagation.