3.16. 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 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, a 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.

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.

Note: The allow-fragmentation command cannot be enabled for an SDP that has NGE (encryption-keygroup) enabled. Attempting to enable both commands will result in an error message.

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 or BGP-Tunnel.

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, 7710 SR, 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, 7710 SR, 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 parameter is 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, 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.

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, LDP must be disabled. The LSP must have already been created in the config>router>mpls context with a valid far-end IP address.

This command creates an association between an LSP and an MPLS SDP. This command is implemented only on MPLS-type encapsulated SDPs.

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.

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, LDP must be disabled. The LSP 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.

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

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