COMMAND DESCRIPTION     14/190 82-CRA 119 1170/1-V1 Uen A

Commands: pp through q

Copyright

© Copyright Ericsson AB 2009. All rights reserved.

Disclaimer

No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

Contents

1   Command Descriptions

Commands starting with “pp” through commands starting “q” are included.

1.1   ppp delay lcp-confreq

1.1.1   Purpose

Sets the delay between sending a Point-to-Point Protocol over Ethernet (PPPoE) Active Discovery Session (PADS) packet and a Link Control Protocol (LCP) Configuration Request packet if the Point-to-Point Protocol (PPP) peer has not started the LCP.

1.1.2   Command Mode

global configuration

1.1.3   Syntax Description

1.1.4   Default

The default value for the LCP negotiation request time delay is 3 seconds.

1.1.5   Usage Guidelines

Use the ppp delay lcp-confreq command to delay sending the PPP LCP Configuration Request to the peer after sending the PPPoE PADS packet. If the SmartEdge OS receives the LCP Configuration Request of the PPP peer before this delay is satisfied, the SmartEdge OS sends its own LCP Configuration Request immediately.

Note:  

This command is valid only with PPPoE sessions.

The default form of this command sets the delay to 3 seconds when the SmartEdge router sends the LCP Configuration Request.

1.1.6   Examples

The following example shows how to set the delay to 5 seconds:

[local]Redback(config)#ppp delay lcp-confreq 5

1.2   ppp ipcp disconnect invalid-ip-address

1.2.1   Purpose

Sends a Point-to-Point Protocol (PPP) termination request to subscribers when they do not negotiate a valid IP address during the PPP Internet Protocol Control Protocol (IPCP) negotiation process.

1.2.2   Command Mode

• global configuration

1.2.3   Syntax Description

This command has no keywords or arguments.

1.2.4   Default

None.

1.2.5   Usage Guidelines

Use the ppp ipcp disconnect invalid-ip-address command to send a PPP termination request to subscribers when they do not negotiate a valid IP address during the IPCP negotiation process.

1.2.6   Examples

The following example shows how to enable the PPP termination request feature:

[local]Redback(config)#ppp ipcp disconnect invalid-ip-address

1.3   ppp ipcp peer-address

1.3.1   Purpose

Configures a static IP address that the SmartEdge system can provide to the static point-to-point protocol (PPP) peer devices during the establishment of PPP links.

1.3.2   Command Mode

Interface configuration

1.3.3   Syntax Description

1.3.4   Default

No IP address is provided to the PPP peer device.

1.3.5   Usage Guidelines

Use the ppp ipcp peer-address command to configure a static IP address that the SmartEdge system can provide to the PPP peer devices during the establishment of PPP links.

Note:  

The peer ip-address assignment is only for PPP links (not for PPP subscriber sessions) and is applicable to only T1 cards; such as the Channelized-DS3 card.

1.3.6   Examples

The following example illustrates how the IP address offered in the IPCP phase of PPP negotiations is configured for an interface:

[local]Redback(config)#context blue

[local]Redback(config-ctx)#interface yellow

[local]Redback(config-if)#ip address 10.0.0.1/24

[local]Redback(config-if)#ppp ipcp peer-address 10.0.0.2

1.4   ppp keepalive

1.4.1   Purpose

Enables Point-to-Point Protocol (PPP) keepalive checks and specifies PPP timing attributes.

1.4.2   Command Mode

• context configuration

1.4.3   Syntax Description

1.4.4   Default

Keepalive checks are not enabled, except in the case of circuits using PPP over Ethernet (PPPoE), for which the period between keepalive checks is 5 minutes (300 seconds).

1.4.5   Usage Guidelines

Use the ppp keepalive command to enable PPP keepalive checks and specify PPP timing attributes. The command keywords work together to configure when and how keepalives are sent, and what action is taken as a result of the response, or lack of response.

Keepalive checks are LCP echo request messages sent over PPP sessions in the context to detect abnormal session disconnects that the system would not otherwise know about. The check-interval keyword must be entered before the other command keywords are available.

The check-interval keyword sets the time between LCP echo requests, in either minutes or seconds. When this time expires, an LCP echo request is sent to the PPP peer and a response timer is started. The length of the response timer is determined by the value of the response-timeout seconds construct. If a valid LCP echo is received before the response timer expires, the response timer is canceled, and the check interval timer is reset.

If the response timer expires without a valid LCP echo being received, an optional check, specified by the data-check keyword, is performed to see if any data has been received on the circuit since the LCP echo request was sent. Only valid PPP packets are considered data. If data has been received since the LCP echo request was sent, the check interval timer is reset. If no data has been received, the retry counter is incremented and another LCP echo request message is sent. When the configured number of retries has been reached, set by the value of the retries retry-num construct, without a valid echo or data being received, the session is considered to be no longer alive and is torn down.

The data-check keyword specifies that after the check interval timer expires and before an LCP echo request message is sent, a check is performed to determine if data has been received on the circuit since the last check interval timer expiration. If data has been received, the check interval timer is simply reset, skipping the LCP echo request message altogether. This option is recommended when it is preferred to limit the overhead for PPP keepalive processing. The tradeoff is that using the data-check keyword to determine that a session is no longer active can take longer than using the PPP keepalive feature without the data-check keyword. For an example illustrating this tradeoff, see PPP Keepalive Checks in PPP Keepalive Checks.

Although the default period between keepalive checks for PPPoE circuits is 5 minutes (300 seconds) if keepalive checks are not enabled, PPPoE circuits take on the configured period between checks when keepalive checks are enabled.

Use the no form of this command without options to disable all command options.

Note:  

The no ppp keepalive data-check form is available only if you have previously specified the check interval.

Note:  

Entering the no ppp keepalive check-interval command does not disable the keepalive feature on active sessions. Because it is a context configuration mode command, applying to all PPP sessions in the context, the command takes effect when the last active session is torn down.

Use the default form of this command to specify the default value for the response timer or the number of retries.

1.4.6   Examples

The following example shows how to enable the PPP keepalive feature, sets the length of the response timer and the number of retries, and specifies the data check option to minimize LCP echo traffic:

[local]Redback(config-ctx)#ppp keepalive check-interval seconds 500

[local]Redback(config-ctx)#ppp keepalive data-check response-timeout 30 retries 3

1.5   ppp mtu

1.5.1   Purpose

Sets the maximum transmission unit (MTU) used by Point-to-Point Protocol (PPP) for a subscriber’s circuit.

1.5.2   Command Mode

• subscriber configuration

1.5.3   Syntax Description

1.5.4   Default

None

1.5.5   Usage Guidelines

Use the ppp mtu command to set the MTU used by PPP for a subscriber circuit. The effect of this command is strictly local to the SmartEdge router, and therefore, does not force the router to negotiate a particular PPP MRU.

Use the ppp mtu command to lower the size of data packets being sent over that subscriber link from the MRU value that has been negotiated between the SmartEdge router and the PPP client. You cannot make the size any larger than the negotiated MRU. If an MRU value lower than the value of the mtu argument in the ppp mtu command has been negotiated, the MRU value takes precedence and the ppp mtu command setting is ignored.

On a normal Ethernet interface, the standard MTU is 1500. For Point-to-Point Protocol over Ethernet (PPPoE) implementation, the negotiated MTU uses the physical interface, minus eight bytes as the default.

1.5.6   Examples

The following example shows how to set the PPP MTU to 768 bytes:

[local]Redback(config-sub)#ppp mtu 768

1.6   ppp multilink

1.6.1   Purpose

Enables multilink Point-to-Point Protocol (PPP) for subscriber sessions on PPP-encapsulated Asynchronous Transfer Mode (ATM) permanent virtual circuits (PVCs), PPPoE over Ethernet (PPPoE)-encapsulated 802.1Q PVCs, 802.1Q tunnels, untagged Ethernet traffic, and Layer 2 Tunneling Protocol (L2TP) tunnels.

1.6.2   Command Mode

• global configuration

1.6.3   Syntax Description

This command has no keywords or arguments.

1.6.4   Default

Multilink PPP (MP) is disabled for subscriber sessions on PPP-encapsulated ATM PVCs, PPPoE-encapsulated 802.1Q PVCs and tunnels, untagged Ethernet traffic, and L2TP tunnels.

1.6.5   Usage Guidelines

Use the ppp multilink command to enable MP for subscriber sessions on ATM PVCs, PPPoE-encapsulated 802.1Q PVCs and tunnels, untagged Ethernet traffic, and L2TP tunnels.

Use the no form of this command to specify the default condition.

1.6.6   Examples

The following example shows how to enable MP:

[local]Redback(config)#ppp multilink

1.7   ppp multilink lfi

1.7.1   Purpose

Enables Point-to-Point Protocol (PPP) Link Fragmentation and Interleaving (LFI) within the specified priority or fragmentation threshold value for subscriber sessions on PPP-encapsulated Asynchronous Transfer Mode (ATM) permanent virtual circuits (PVCs), PPP over Ethernet (PPPoE)-encapsulated 802.1Q PVCs and tunnels, untagged Ethernet traffic, and Layer 2 Tunneling Protocol (L2TP) tunnels.

1.7.2   Command Mode

• global configuration

1.7.3   Syntax Description

1.7.4   Default

The default does not enable LFI priority and fragmentation thresholds for subscriber sessions on PPP-encapsulated ATM PVCs, PPPoE-encapsulated 802.1Q PVCs and tunnels, untagged Ethernet traffic, and L2TP tunnels.

1.7.5   Usage Guidelines

Use the ppp multilink lfi command to enable PPP LFI with the specified priority or fragmentation threshold values for subscriber sessions on PPP-encapsulated ATM PVCs, PPPoE-encapsulated 802.1Q PVCs and tunnels, untagged Ethernet traffic, and L2TP tunnels.

Use the fragment-threshold value construct to set the fragmentation threshold on outgoing traffic. The range of values is 258 to 16,320. The threshold size is not to exceed the value specified by the user, but does not necessarily need to be the same as the fragment threshold. The default value is 0, with no packets becoming fragmented.

Use the optional priority-threshold value construct to define the multiprotocol encapsulation priority level. The packet is encapsulated only if it is of lower or equal priority than the configured threshold. If the packet is not multiprotocol encapsulated, it is not fragmented, regardless of the size. All packets are multiprotocol encapsulated if their priority is lower than or equal to the threshold. The default value of 0 results in all packets being multiprotocol encapsulated.

Use the no form of this command to disable LFI priority and fragmentation thresholds.

1.7.6   Examples

The following example shows how to enable PPP LFI with a specified fragmentation threshold value of 258:

[local]Redback(config)#ppp multilink lfi fragment-threshold 258

The following example shows how to enable PPP LFI with a specified priority threshold value of 7:

[local]Redback(config)#ppp multilink lfi priority-threshold 7

1.8   pppoe always-send-padt

1.8.1   Purpose

Configures a Point-to-Point Protocol (PPP)-encapsulated (PPPoE) option that terminates the PPPoE session by sending a PPPoE Active Discovery Terminate (PADT) packet after the PPP session is terminated.

1.8.2   Command Mode

global configuration

1.8.3   Syntax Description

This command has no keywords or arguments.

1.8.4   Default

The PPPoE option does not terminate the PPPoE session when the PPP session is terminated.

1.8.5   Usage Guidelines

Use the pppoe always-send-padt command to configure a PPPoE option that terminates the PPPoE session after a PPP session is terminated.

Use this command if the PPPoE client requires explicit termination of the PPPoE session.

The PPPoE option is a global and will be applied to all PPPoE sessions that are currently established and for all future sessions.

Use the no or default form of this command to disable the PPPoE option that terminates the PPPoE session once the PPP session has terminated.

1.8.6   Examples

The following example shows how to configure the PPPoE option to terminate the PPPoE session after the PPP session has terminated:

[local]Redback(config)#pppoe always-send-padt

[local]Redback(config)#end

1.9   pppoe circuit padi per-mac

1.9.1   Purpose

Limits the number of Point-to-Point Protocol over Ethernet Active Discovery Initialization (PADI) messages that the system accepts in a specified interval for each medium access control (MAC) address.

1.9.2   Command Mode

• global configuration

1.9.3   Syntax Description

1.9.4   Default

The SmartEdge router does not limit the outstanding PADI message that the router accepts in a specified interval for each MAC address.

1.9.5   Usage Guidelines

Use the pppoe circuit padi per-mac command to limit the number of PPPoE PADI messages that the system accepts in an interval for each MAC address.

Note:  

The SmartEdge router can accept many PADI messages simultaneously from the same MAC address, but it processes only one at any given time.

This command applies only to PPPoE-encapsulated circuits on the following traffic cards:

• All Ethernet and Gigabit Ethernet cards
• All ATM cards

Use the no or default form of this command to specify the default condition.

1.9.6   Examples

The following example shows how to accept 150 PADI messages per MAC address in every 2-second interval. If more than 150 PADI messages are received during the interval, all PADI messages are dropped for 3 seconds following the interval. Following that, 150 PADI messages are allowed per MAC address for the next 2-second interval:

[local]Redback(config)#pppoe circuit padi per-mac count 150 allow-time 2 drop-time 3

1.10   pppoe circuit padr per-mac

1.10.1   Purpose

Limits the number of Point-to-Point Protocol over Ethernet Active Discovery Request (PADR) messages that the system accepts in a specified interval for each medium access control (MAC) address.

1.10.2   Command Mode

• global configuration

1.10.3   Syntax Description

1.10.4   Default

The PPPoE session limits the outstanding PADR message count to 1 for each MAC address until it receives a PPPoE Active Discovery Session (PADS) reply for that session.

1.10.5   Usage Guidelines

Use the pppoe circuit padr per-mac command to limit the number of PPPoE PADR messages that the system accepts in an interval for each MAC address.

Note:  

The SmartEdge router can accept many PADR messages simultaneously from the same MAC address, but it processes only one at any given time.

This command applies only to PPPoE-encapsulated circuits on the following traffic cards:

• All Ethernet and Gigabit Ethernet cards
• All ATM cards

Use the no or default form of this command to specify the default condition.

1.10.6   Examples

The following example shows how to accept 200 PADR messages per MAC address in every 2-second interval. If more than 200 PADR messages are received during the interval, all PADR messages are dropped for 3 seconds following the interval. Following that, 200 PADR messages are allowed per MAC address for the next 2-second interval:

[local]Redback(config)#pppoe circuit padr per-mac count 200 allow-time 2 drop-time 3

1.11   pppoe client route

1.11.1   Purpose

Configures routes to be installed on the subscriber’s PC when multiple Point-to-Point Protocol over Ethernet (PPPoE) sessions exist.

1.11.2   Command Mode

• subscriber configuration

1.11.3   Syntax Description

1.11.4   Default

Routes are not sent to the subscriber’s PPPoE client.

1.11.5   Usage Guidelines

Use the pppoe client route command to configure the SmartEdge router to provide different routes for different PPPoE sessions. For each PPPoE session, a route is sent in a PPPoE Active Discovery Network (PADN) message, and installed on the subscriber’s PC. In this way, subscribers are enabled with seamless client route provisioning on a per-PPPoE session basis. The subscriber’s PC client must support PADN. If the PPPoE client ignores the routes, they have no effect.

As an example of this feature, one PPPoE session could provide Internet connectivity, while another session connects corporate headquarters to a remote office site. Routes to the business site might be of a very different nature than the routes that provide access to the Internet.

Use the no form of this command to remove the specified route from the configuration.

1.11.6   Examples

The following example shows how to specify that a route at 200.1.1.0 255.255.255.0 is to be used for concurrent multiple PPPoE sessions. This route has a metric, or hop count, of 1:

[local]Redback(config-sub)#pppoe client route 200.1.1.0 255.255.255.0 1

1.12   pppoe motm

1.12.1   Purpose

Creates and enables the sending of a message of the minute (MOTM) to a subscriber when logging on.

1.12.2   Command Mode

subscriber configuration

1.12.3   Syntax Description

1.12.4   Default

None

1.12.5   Usage Guidelines

Use the pppoe motm command to create and enable the sending of a message to the subscriber when logging on. You can use this command to send any information of general use to subscribers; for example, information about system downtime.

Note:  

A newly created MOTM overwrites an existing MOTM.

Use the no form of this command to delete the MOTM so that the message is no longer sent to the subscriber after logging on.

1.12.6   Examples

The following example establishes an MOTM:

[local]Redback(config-sub)#pppoe motm Network will be down for maintenance from 0100-0400 Saturday.

The following example deletes the active MOTM:

[local]Redback(config-sub)#no pppoe motm 

1.13   pppoe pado delay

1.13.1   Purpose

Sets the Point-to-Point Protocol over Ethernet Active Discovery Offer (PADO) delay timer to the specified number of seconds.

1.13.2   Command Mode

• dot1q profile configuration

1.13.3   Syntax Description

1.13.4   Default

No PPPoE PADO delay value is set.

1.13.5   Usage Guidelines

Use the pppoe pado delay command to set the PPPoE PADO delay timer to the specified value, in number of seconds.

Note:  

All PVCs with the PPPoE encapsulation type that are bound to the 802.1Q profile inherit the PPPoE PADO delay value. After you delete an 802.1Q profile, all PPPoE PVCs that refer to this profile no longer have PPPoE PADO delay timer values specified.

Use the no form of this command to delete the PPPoE PADO delay timer value.

1.13.6   Examples

The following example shows how to set the 802.1Q blue profile to have a PADO delay time of 3 seconds:

[local]Redback(config)#dot1q profile blue

[local]Redback(config-dot1q-profile)#pppoe pado delay 3

1.14   pppoe service-name accept-all

1.14.1   Purpose

Enables the SmartEdge router to accept any service name tag that is included in a Point-to-Point Protocol over Ethernet (PPPoE) Active Discovery Initiation (PADI) or PPPoE Active Discovery Request (PADR) message and include it among the advertised services in a PPP Active Discovery Offer (PADO) or PPPoE Active Discovery Session (PADS) message, respectively.

1.14.2   Command Mode

• global configuration

1.14.3   Syntax Description

This command has no keywords or arguments.

1.14.4   Default

The SmartEdge router accepts and advertises only those services (domains) that have been configured through the SmartEdge router.

1.14.5   Usage Guidelines

Use the pppoe service-name accept-all command to enable the SmartEdge router to accept any service name tag that is included in a PPPoE PADI message, and include it among the advertised services in PPP PADO messages. It also accepts any service name tag that is included in a PPPoE PADR message and includes it in a PPPoE PADS message.

Use the no form of this command to disable the acceptance and advertisement of service name tags that are not configured through the SmartEdge router.

1.14.6   Examples

The following example shows how to enable the acceptance of all service names that might be included in PADI or PADR messages:

[local]Redback(config)#pppoe service-name accept-all

1.15   pppoe services

1.15.1   Purpose

Specifies which domains (services) are advertised to Point-to-Point Protocol over Ethernet (PPPoE) clients.

1.15.2   Command Mode

global configuration

1.15.3   Syntax Description

1.15.4   Default

No domains are advertised to PPPoE clients.

1.15.5   Usage Guidelines

Use the pppoe services command to specify which domains (services) are advertised to PPPoE clients and make public the services that the SmartEdge router provides.

Note:  

Domain names, not context names, are advertised during the PPPoE discovery protocol.

Use the no or default form of this command to disable domain advertisement.

1.15.6   Examples

The following example shows how to enable the advertisement of marked domains to PPPoE clients:

[local]Redback(config)#pppoe services marked-domains

1.16   pppoe tag

1.16.1   Purpose

Replaces the default access concentrator (AC)-Name PPPoE tag value with the specified string or enables AC-Cookie tag support.

1.16.2   Command Mode

global configuration

1.16.3   Syntax Description

1.16.4   Default

The SmartEdge router uses an automatically generated (and guaranteed to be unique) value for the AC-Name PPPoE tag and AC-cookie tag support is disabled.

1.16.5   Usage Guidelines

RFC 2516, Transmitting PPP Over Ethernet, specifies that the AC-Name PPPoE tag sent in PPPoE Active Discovery Offer (PADO) messages must have a unique value. The SmartEdge router ensures that this value is unique by creating it from a combination of the backplane serial number and the hostname of the AC device sending the PADO message. When it is preferred to override this default, use this command to establish an alternate value for the AC-Name tag. After you change the default, the SmartEdge router can no longer guarantee that the value is unique.

SmartEdge router also supports the AC-Cookie tag described in RFC 2516 to allow the AC to uniquely regenerate the tag value based on the PADR source address. Using this feature, the AC can ensure that the PADI source address is indeed reachable and can then limit concurrent sessions for that address.

Use the no or default form of this command to return the AC-Name value to the automatically generated default name or to disable AC-Cookie tag support.

1.16.6   Examples

The following example replaces the AC-Name PPPoE tag with fortune-1:

[local]Redback(config)#pppoe tag ac-name fortune-1

1.17   pppoe url

1.17.1   Purpose

Sets the subscriber’s Point-to-Point Protocol over Ethernet (PPPoE) client to automatically point the web browser to a specified URL as soon as the session is established.

1.17.2   Command Mode

subscriber configuration

1.17.3   Syntax Description

1.17.4   Default

None

1.17.5   Usage Guidelines

Use the pppoe url command to set the subscriber’s PPPoE client to point the subscriber’s browser to a specific location after the subscriber’s PPP session is established.

This command can be configured in each subscriber record, in a named subscriber profile, or in the subscriber default profile.

The url argument is a standard URL that can contain the special-character sequences listed in Table 1.

The SmartEdge router expands these sequences prior to inclusion in a PPP Active Discovery Message (PADM) and can be used to personalize the URL to the subscriber.

Use the no form of this command to remove the URL association from the subscriber record.

1.17.6   Examples

For a subscriber, joe, in the context, local, the following example allows a PADM containing the URL http://www.loe.com/members/joe@local to be sent to the PPPoE client when the PPP session is established:

[local]Redback(config-ctx)#subscriber name joe

[local]Redback(config-sub)#pppoe url http://www.loe.com/members/%U

For every subscriber to which the subscriber default value is applied, the following example sends a PADM containing http://www.loe.com/members/name to the PPPoE client when the PPP session is established:

[local]Redback(config-ctx)#subscriber default

[local]Redback(config-sub)#pppoe url http://www.loe.com/members/%u

1.18   ppp our-options mru

1.18.1   Purpose

Specifies the range for the maximum receive unit (MRU) with which the SmartEdge router negotiates Link Control Protocol (LCP) option values for the SmartEdge router end of the Point-to-Point Protocol (PPP) session.

1.18.2   Command Mode

• global configuration

1.18.3   Syntax Description

1.18.4   Default

If you do not use this command, the SmartEdge router uses the default values described in the Syntax Description section of this command.

1.18.5   Usage Guidelines

Use the ppp our-options mru command to specify the range for the MRU with which the SmartEdge router negotiates LCP option values for the SmartEdge router end of PPP sessions.

Currently, the options available are the initial and maximum MRU values. When these values are specified, the SmartEdge router begins negotiation for its MRU at the value of the initial-mru argument, and does not exceed the value of the max-mru argument. The resulting size guidelines are reflected in all packets sent to the SmartEdge router by the remote peer.

If, after 10 attempts, an agreement with the peer can not be reached as to a local MRU between the configured initial and maximum values, the SmartEdge router establishes the PPP session without negotiating the local MRU. In that case, the SmartEdge router uses an MRU of 1,500 for PPP circuits and 1,492 for PPPoE circuits.

Note:  

This command affects only subscriber sessions.

Use the default form of this command to return the LCP options for MRU to their default values.

1.18.6   Examples

The following example shows how to set the local initial and maximum MRU values:

[local]Redback(config)#ppp our-options mru initial 1800 maximum 11000

1.19   ppp our-options multilink

1.19.1   Purpose

Specifies the address for the SmartEdge router end of multilink Point-to-Point Protocol (MP) bundles.

1.19.2   Command Mode

• global configuration

1.19.3   Syntax Description

1.19.4   Default

If you do not use this command, the SmartEdge router uses the hostname and IP address of the SmartEdge router.

1.19.5   Usage Guidelines

Use the ppp our-options multilink command to specify the address for the SmartEdge router end of MP bundles. This command is not available until you have enabled MP using the ppp multilink command (in global configuration mode).

Note:  

This command only applies to MP bundles on Point-to-Point Protocol (PPP)-encapsulated Asynchronous Transfer Mode (ATM) permanent virtual circuits (PVCs), PPP over Ethernet (PPPoE)-encapsulated 802.1Q PVCs and tunnels, untagged Ethernet traffic, and Layer 2 Tunneling Protocol (L2TP) tunnels.

Table 2 lists the address types and their constructs for the addr argument.

Use the no or default form of this command to specify the local MAC address of the SmartEdge router.

1.19.6   Examples

The following example shows how to specify the IP address of the Ethernet management port on the controller card as the endpoint discriminator:

[local]Redback(config)#ppp our-options multilink endpoint-discriminator local-ip-address

1.20   ppp peer-options mru

1.20.1   Purpose

Specifies the range for the maximum receive unit (MRU) with which the SmartEdge router negotiates Link Control Protocol (LCP) option values for the remote end of the Point-to-Point Protocol (PPP) session.

1.20.2   Command Mode

• global configuration

1.20.3   Syntax Description

1.20.4   Default

The SmartEdge router negotiates LCP options with the default values.

1.20.5   Usage Guidelines

Use the ppp peer-options mru command to specify the range for the MRU with which the SmartEdge router negotiates LCP option values for the remote end of PPP sessions.

Note:  

The use of this command can alter the values negotiated during LCP, but it does not force any options to be negotiated or prevent any options from being negotiated. For MRU (the only option supported at the moment), it controls the SmartEdge end of the MRU negotiation if the remote peer is willing to negotiate MRU.

Currently, the options available are the minimum and maximum MRU values. When these values are specified, the SmartEdge router negotiates the remote peer’s MRU value to be at least the value specified by the min-mru argument, and not greater than the value specified by the max-mru argument. The resulting size guidelines are reflected in all packets that the SmartEdge router sends to the remote peer.

If, after 10 attempts, the SmartEdge router has not reached an agreement with the peer regarding the value of the peer’s MRU between the specified minimum and maximum values, the SmartEdge router establishes the PPP session without negotiating the peer’s MRU. In that case, the SmartEdge router uses the standard MRU of 1,500 for PPP circuits, and 1,492 for PPP over Ethernet (PPPoE) circuits.

Note:  

This command affects only subscriber sessions.

Use the default form of this command to return the options to their default values.

1.20.6   Examples

The following example shows how to set the peer’s minimum and maximum MRU values:

[local]Redback(config)#ppp peer-options mru minimum 200 maximum 2000

1.21   ppp pppoe-large-mru

1.21.1   Purpose

Enables the negotiation of the maximum receive unit (MRU) larger than 1492 bytes for Point-to-Point Protocol over Ethernet (PPPoE) circuits as described in RFC 4638.

1.21.2   Command Mode

• global configuration

1.21.3   Syntax Description

This command has no keywords or arguments.

1.21.4   Default

MRU negotiation is disabled.

1.21.5   Usage Guidelines

Use the ppp pppoe-large-mru command to enable the negotiation of a MRU larger than 1492 bytes for PPPoE circuits as described in RFC 4638. If the SmartEdge router is configured with this command, an MRU larger than 1492 bytes is allowed only when the PPPoE PPP-Max-Payload tag is received from the client and the client initiates MRU negotiation.

The MRU negotiation is decided in described in RFC 4638. These negotiations are based on the PPPoE PPP-Max-Payload tag value received, and the subscribers and ports MTU value.

Use the no form of this command to disable MRU negotiation. When MRU negotiation is disabled, the MRU is set to 1,492 bytes.

1.21.6   Examples

The following example shows how to enable MRU negotiation:

[local]Redback(config)#ppp pppoe-large-mru

1.22   preempt

1.22.1   Purpose

Enables a higher priority Virtual Router Redundancy Protocol (VRRP) backup router to preempt a lower priority VRRP master.

1.22.2   Command Mode

VRRP configuration

1.22.3   Syntax Description

1.22.4   Default

Preemption is enabled.

1.22.5   Usage Guidelines

Use the preempt command to enable a VRRP backup router that has a higher priority to preempt a lower priority VRRP master. Use the optional hold-time interval construct to specify a hold time, in seconds, for which a higher-priority VRRP backup router must wait before preempting a lower-priority VRRP master. Configure the preemption hold time when you want the higher-priority server to wait before trying to preempt the current master while the system completely converges.

When preemption is disabled, a higher priority VRRP backup router does not preempt a lower priority VRRP master.

Note:  

Preemption can only be disabled for VRRP backup routers; VRRP owner routers always have preemption enabled.

The master VRRP router can never be preempted by another router, and it always advertises a VRRP priority of 255. The priority of 255 is reserved for the master VRRP router. If a failure occurs in the master VRRP router, a backup router takes over until the master VRRP router comes back up. In such cases, the master VRRP router immediately preempts the backup router; a preempt hold time is ignored if it is configured on the master VRRP router.

Use the no or default form of this command to disable preemption.

1.22.6   Examples

The following example disables preemption on the VRRP backup router with virtual ID 23:

[local]Redback(config-if)#vrrp 23 backup

[local]Redback(config-vrrp)#no preempt

[local]Redback(config-vrrp)#

1.23   preferred-lifetime

1.23.1   Purpose

Specifies the value for the Preferred Lifetime field.

1.23.2   Command Mode

• ND router configuration
• ND router interface configuration

1.23.3   Syntax Description

1.23.4   Default

The preferred lifetime is seven days.

1.23.5   Usage Guidelines

Use the preferred-lifetime command to specify the value for the Preferred Lifetime field. In ND router configuration mode, this command specifies the global value for all interfaces; in ND router interface mode, it specifies the value for this Neighbor Discovery (ND) router interface. If specified, the setting for the interface overrides the global setting.

Use the no or default form of this command to specify the default value.

1.23.6   Examples

The following example specifies a preferred lifetime of 43200 seconds (12 hours) for all interfaces for this ND router:

[local]Redback(config)#context local

[local]Redback(config-ctx)#router nd

[local]Redback(config-nd-if)#preferred-lifetime 43200

The following example specifies a preferred lifetime of 2880 seconds (48 minutes) for the int1 ND router interface, which overrides the global setting:

[local]Redback(config)#context local

[local]Redback(config-ctx)#router nd

[local]Redback(config-nd)#interface int1

[local]Redback(config-nd-if)#preferred-lifetime 2880

1.24   prefix

1.24.1   Purpose

Configures a prefix to be advertised for this Neighbor Discovery (ND) router interface.

1.24.2   Command Mode

• ND router interface configuration

1.24.3   Syntax Description

1.24.4   Default

No prefix is configured for any ND router interface.

1.24.5   Usage Guidelines

Use the prefix command to configure a prefix to be advertised for this ND router interface. Enter this command multiple times to configure more than one prefix.

Use the optional keywords and constructs to define the fields in the Prefix Information option for this prefix:

• no-autoconfig—Sets the autonomous address configuration flag in the Prefix Information option to FALSE.
• no-onlink—Sets the on-link flag to FALSE.
• preferred-lifetime—Specifies the value for the Preferred Lifetime field.
• valid-lifetime—Specifies the value for the Valid Lifetime field.

The values for the preferred-lifetime preferred-lifetime and valid-lifetime valid-lifetime constructs override the values for the interface that you specified with the preferred-lifetime and valid-lifetime commands (in ND router interface configuration mode).

Use the no or default form of this command to delete the specified prefix from this interface configuration.

1.24.6   Examples

The following example configures the 5555:bbbb::22/64 prefix for the int1 ND router interface:

[local]Redback(config)#context local

[local]Redback(config-ctx)#router nd

[local]Redback(config-nd)#interface int1

[local]Redback(config-nd-if)#prefix 5555:bbbb::22/64 no-autoconfig no-onlink preferred-lifetime 360 valid-lifetime 360

1.25   prefix-list

1.25.1   Purpose

Filters Border Gateway Protocol (BGP) routes from or to the neighbor address family or peer group address family.

1.25.2   Command Mode

• BGP neighbor address family configuration
• BGP peer group address family configuration

1.25.3   Syntax Description

1.25.4   Default

There are no preconfigured prefix lists.

1.25.5   Usage Guidelines

Use the prefix-list command to filter BGP routes from or to the neighbor address family or peer group address family. Use this command in conjunction with the ip prefix-list command in context configuration mode, which creates the conditions of the filter.

Use the in keyword to filter incoming BGP routes from the specified neighbor or peer. Use the out keyword to filter outgoing BGP routes to the specified neighbor.

Note:  

You cannot enable the out keyword on a BGP neighbor that is part of a peer group, because this feature cannot be customized for individual members inside of a peer group.

Currently, prefix list changes automatically take effect, and issuing the clear bgp neighbor ip-addr soft [in | out] command in exec mode to update a prefix list can cause updates to be unnecessarily sent; therefore, it is not recommended.

To aggregate multiple policy changes, such as the prefix list, the operating system performs the automatic update 15 seconds after any routing policy has changed.

Note:  

If the remote peer does not support the BGP route refresh capability, an inbound policy change for the peer will result in an automatic hard reset of the session.

Use the no form of this command to remove the application of a prefix list.

1.25.6   Examples

The following example denies incoming unicast BGP routes 10.0.0.0/8 (and more-specific routes) from the unicast neighbor at IP address 102.210.210.1. Outgoing multicast BGP routes 204.16.16.0/24 can be sent to the multicast neighbor at IP address 68.68.68.68:

[local]Redback(config-ctx)#ip prefix-list prefix-101

[local]Redback(config-prefix-list)#deny 10.0.0.0/8 le 32

[local]Redback(config-prefix-list)#permit 0.0.0.0/0 le 32

[local]Redback(config-prefix-list)#exit

[local]Redback(config-ctx)#ip prefix-list prefix-202

[local]Redback(config-prefix-list)#permit 204.16.16.0/24

.

.

.

[local]Redback(config-ctx)#router bgp 100

[local]Redback(config-bgp)#neighbor 102.210.210.1 external

[local]Redback(config-bgp-neighbor)#remote-as 200

[local]Redback(config-bgp-neighbor)#address-family ipv4 unicast

[local]Redback(config-bgp-peer-af)#prefix-list prefix-101 in

[local]Redback(config-bgp-peer-af)#exit

[local]Redback(config-bgp-neighbor)#exit

[local]Redback(config-bgp)#neighbor 68.68.68.68 external

[local]Redback(config-bgp-neighbor)#remote-as 300

[local]Redback(config-bgp-neighbor)#address-family ipv4 multicast

[local]Redback(config-bgp-peer-af)#prefix-list prefix-202 out

1.26   priority (IGMP)

1.26.1   Purpose

Configures the priority of the interface when the maximum bandwidth in the service profile has been exhausted.

1.26.2   Command Mode

IGMP service profile configuration

1.26.3   Syntax Description

1.26.4   Default

The interface has no priority setting.

1.26.5   Usage Guidelines

Use the priority command to configure the priority of the interface when the maximum bandwidth in the service profile has been exhausted.

When the addition of a new group would cause the maximum bandwidth, as specified by the igmp maximum-bandwidth command, to be exceeded on the port, the router searches for subscribers joined on the same port with a lower priority. The router drops the lower priority subscribers and reclaims their bandwidth until it gets enough bandwidth to service the higher priority subscriber. If it cannot reclaim enough bandwidth the new group join will be dropped.

Use the no form of this command to delete the priority setting for the interface.

1.26.6   Examples

The following example configures a priority of 8 for the interface:

[local]Redback(config-ctx)#igmp service-profile bar

[local]Redback(config-igmp-service-profile)#priority 8

1.27   priority (IS-IS)

1.27.1   Purpose

Configures the Intermediate System-to-Intermediate System (IS-IS) designated router priority setting for the specified LAN interface.

1.27.2   Command Mode

IS-IS interface configuration

1.27.3   Syntax Description

1.27.4   Default

The priority setting is 64.

1.27.5   Usage Guidelines

Use the priority command to configure the IS-IS designated router priority setting for the specified LAN interface.

A priority value determines which router on a network is the first router chosen for sending and receiving traffic. The priority value is advertised in Hello packets. The router with the highest priority becomes the Designated Intermediate System (DIS).

In IS-IS, there is no backup designated router. If a router is set to priority 0, it has a smaller chance of becoming the DIS, but it may not be prevented from becoming the DIS. When a router with a higher priority becomes available on the network, it takes over as the current DIS. In the case of equal priorities, the highest medium access control (MAC) address breaks the tie.

Use the no form of this command to restore the default priority.

1.27.6   Examples

The following example sets the priority for the fa4/1 interface to 80, making it more likely to become the DIS for IS-IS level-1 routing:

[local]Redback(config-ctx)#router isis ip-backbone

[local]Redback(config-isis)#interface fa4/1

[local]Redback(config-isis-if)#priority 80 level-1

1.28   priority (loop-detection)

1.28.1   Purpose

Sets the priority of loop-prevention blocking on the assigned circuit.

1.28.2   Command Mode

• loop-detection profile configuration

1.28.3   Syntax Description

1.28.4   Default

0 (never blocked)

1.28.5   Usage Guidelines

Use the priority command to set the priority of loop-prevention blocking on the assigned circuit. The default is 0 (unblockable). Except for circuits with priority 0, circuits with higher priority are blocked before circuits with lower priority. Circuits with priority 0 are never blocked.

Use the no form of this command to return the priority of loop-detection of the assigned circuit to its default.

1.28.6   Examples

The following example creates the bridge profile, plow, and sets the loop-detection priority for circuits associated with that bridge profile to the value 2:

[local]jeudi.lab(config)#bridge profile plow

[local]jeudi.lab(config-bridge-profile)#loop-detection

[local]jeudi.lab(config-bridge-profile-ld)#priority 2

1.29   priority (RSVP)

1.29.1   Purpose

For Constrained Shortest Path First (CSPF), specifies the preemptive characteristics of the label-switched path (LSP).

1.29.2   Command Mode

• RSVP constraint configuration

1.29.3   Syntax Description

1.29.4   Default

Setup priority is 7. Hold priority is 0.

1.29.5   Usage Guidelines

For CSPF, specifies the preemptive characteristics of the LSP. The setup priority specifies whether a new LSP can preempt an existing LSP. The hold priority determines whether the LSP can preserve its session reservation after being established. If the setup priority of the new LSP has a higher priority (a lower number) than the hold priority of an existing LSP, and resource contention exists between two LSPs, they preempt each other forever because neither LSP can preserve its session reservation. The system prevents you from configuring the hold priority to a higher priority (lower number) than the setup priority.

Note:  

You typically configure the setup priority and hold priority to the same value.

The following scenario illustrates what happens when two LSPs are configured with the same setup priority but with a lower hold priority, and resource contention exists between both LSPs. In this case, both LSP1 and LSP2 have a setup priority of 6 and a hold priority of 7:

1. LSP1 establishes a tunnel.
2. LSP2 attempts to establish a tunnel, and contention exists for resources with LSP1.
3. LSP2 preempts (disassembles) LSP1 because its setup priority is higher than the hold priority.
4. LSP1 attempts to re-establishes its tunnel and succeeds by disassembling the LSP2 tunnel, because its setup priority is higher than the hold priority.
5. This process continues forever if the hold priorities continues to remain lower than the setup priorities and sufficient bandwidth is available for both LSPs.

Use the no form of this command to remove the tunnel priority.

1.29.6   Examples

The following example shows how to configure an LSP with a setup priority of 2 and a hold priority of 2:

[local]Redback#configure

[local]Redback(config)#context sj1

[local]Redback(config-ctx)#router rsvp

[local]Redback(config-rsvp)#constraint constraint1

[local]Redback(config-rsvp-constr)#priority 2 2

1.30   priority (spanning-tree)

1.30.1   Purpose

Sets the priority of the bridge.

1.30.2   Command Mode

• spanning-tree configuration

1.30.3   Syntax Description

1.30.4   Default

The default priority level is 32768.

1.30.5   Usage Guidelines

Use the priority command to set the priority of the bridge (0 to 61,440). The lower the priority of the bridge, the more likely it is to be elected as the root bridge.

In the Spanning Tree Protocol, the bridge identifier consists of the bridge MAC address and the bridge priority. These attributes can optionally be set by the bridge-mac-address command (in bridge configuration mode) and the priority command, respectively.

1.30.6   Examples

An example of the bridge priority follows:

[local]Redback(config-bridge-stp)#priority 8192

1.31   priority (VRRP)

1.31.1   Purpose

Configures the Virtual Router Redundancy Protocol (VRRP) election priority for the backup virtual router.

1.31.2   Command Mode

VRRP configuration

1.31.3   Syntax Description

1.31.4   Default

The priority is set to 100.

1.31.5   Usage Guidelines

Use the priority command to configure the VRRP priority for the backup virtual router.

Use the no form of this command to return the priority setting to its default value.

1.31.6   Examples

The following example configures VRRP backup routers for two separate routers, Router_A and Router_B, on the same LAN. Both VRRP backup routers have the same virtual ID, 2. The VRRP backup router on Router_A, which has a priority of 100, is preferred over the VRRP backup router on Router_B, which has a priority of 200.

The configuration for Router_A is as follows:

[local]Router_A(config)#context local

[local]Router_A(config-ctx)#interface foo

[local]Router_A(config-if)#ip address 1.1.1.100/24 secondary

[local]Router_A(config-if)#vrrp 2 backup

[local]Router_A(config-vrrp)#virtual-address 1.1.1.111

[local]Router_A(config-vrrp)#priority 100

The configuration for Router_B is as follows:

[local]Router_B(config)#context local

[local]Router_B(config-ctx)#interface foo

[local]Router_B(config-if)#ip address 1.1.1.200/24 secondary

[local]Router_B(config-if)#vrrp 2 backup

[local]Router_B(config-vrrp)#virtual-address 1.1.1.111

[local]Router_B(config-vrrp)#priority 200

1.32   privilege

1.32.1   Purpose

Assigns a different privilege level to the specified command.

1.32.2   Command Mode

global configuration

1.32.3   Syntax Description

1.32.4   Default

For the default minimum privilege level, see the individual commands. In general, most exec mode commands require privilege level 3, and most configuration mode commands require privilege level 10.

1.32.5   Usage Guidelines

Use the privilege command to assign a different privilege level to a specific command or set of commands.

Use the inherit keyword to modify the privilege level of all commands that begin with one or more keywords within a particular mode. For example, to modify all commands that begin with the snmp keyword (snmp server, snmp target, and so on) in global configuration mode, specify configuration for the mode argument, the inherit keyword, and snmp for the command argument; the command appears as follows:

[local]Redback(config)#privilege config inherit snmp

If you are an administrator at privilege level 15, you can determine the privilege level of any given command by recursively applying the enable and show ? commands at level 15, level 14, level 13, and so on. Initially, all commands at privilege level 15 and lower are listed, then all commands at privilege level 14 and lower, and do on. Be aware that this method yields the current privilege levels, which could be different from the default privilege levels.

Use the no or default form of this command to return a command to the default privilege level.

1.32.6   Examples

The following example assigns the minimum privilege level to the abort and commit commands (in exec mode) to 15:

[local]Redback(config)#privilege exec abort level 15

[local]Redback(config)#privilege exec commit level 15

The following example assigns the minimum privilege level, 12, to all global configuration mode commands that start with the snmp keyword:

[local]Redback(config)#privilege configuration inherit level 12 snmp

1.33   privilege max

1.33.1   Purpose

Specifies the maximum privilege level for the administrator.

1.33.2   Command Mode

administrator configuration

1.33.3   Syntax Description

1.33.4   Default

The maximum privilege level is 15.

1.33.5   Usage Guidelines

Use the privilege max command to specify the maximum privilege level for the administrator.

Using the enable command (in exec mode), an administrator can change the privilege level of the current exec session up to the maximum privilege level specified by this command for the administrator.

Use the default form of this command to return the maximum privilege level to the default value.

1.33.6   Examples

The following command configures administrator fred to a maximum privilege level of 13:

[local]Redback(config-ctx)#administrator fred

[local]Redback(config-administrator)#privilege max 13

1.34   privilege start

1.34.1   Purpose

Specifies the initial privilege level for exec sessions initiated by an administrator.

1.34.2   Command Mode

administrator configuration

1.34.3   Syntax Description

1.34.4   Default

The initial privilege level is set to 6.

1.34.5   Usage Guidelines

Use the privilege start command to specify the initial privilege level for any exec session initiated by the administrator.

When an administrator logs on to the system, the exec session runs at the initial privilege level specified by this command for the administrator.

Use the default form of this command to return the initial privilege level for an administrator to the default value.

1.34.6   Examples

The following command configures administrator fred with an initial privilege level of 11:

[local]Redback(config-ctx)#administrator fred

[local]Redback(config-administrator)#privilege start 11

1.35   probablecause

1.35.1   Purpose

Identifies the probable cause of the event as defined by IANAItuProbableCause in IANA-ITU-ALARM-MIB.

1.35.2   Command Mode

• SNMP alarm model configuration

1.35.3   Syntax Description

1.35.4   Default

None

1.35.5   Usage Guidelines

Identifies the probable cause of the event as defined by IANAItuProbableCause in ASNA-ITU-ALARM-MIB. The value identifies the event type. The following are possible values for the probable-cause-value argument:

1—aIS

2—callSetUpFailure

3—degradedSignal

4—farEndReceiverFailure

5—framingError

6—lossOfFrame

7—lossOfPointer

8—lossOfSignal

9—payloadTypeMismatch

10—transmissionError

11—remoteAlarmInterface

12—excessiveBER

13—pathTraceMismatch

14—unavailable

15—signalLabelMismatch

16—lossOfMultiFrame

17—receiveFailure

18—transmitFailure

19—modulationFailure

20—demodulationFailure

21—broadcastChannelFailure

22—connectionEstablishmentError

23—invalidMessageReceived

24—localNodeTransmissionError

25—remoteNodeTransmissionError

26—routingFailure

51—backplaneFailure

52—dataSetProblem

53—equipmentIdentifierDuplication

54—externalIFDeviceProblem

55—lineCardProblem

56—multiplexerProblem

57—nEIdentifierDuplication

58—powerProblem

59—processorProblem

60—protectionPathFailure

61—receiverFailure

62—replaceableUnitMissing

63—replaceableUnitTypeMismatch

64—synchronizationSourceMismatch

65—terminalProblem

66—timingProblem

67—transmitterFailure

68—trunkCardProblem

69—replaceableUnitProblem

70—realTimeClockFailure

71—antennaFailure

72—batteryChargingFailure

73—diskFailure

74—frequencyHoppingFailure

75—iODeviceError

76—lossOfSynchronisation

77—lossOfRedundancy

78—powerSupplyFailure

79—signalQualityEvaluationFailure

80—tranceiverFailure

81—protectionMechanismFailure

82—protectingResourceFailure

101—airCompressorFailure

102—airConditioningFailure

103—airDryerFailure

104—batteryDischarging

105—batteryFailure

106—commercialPowerFailure

107—coolingFanFailure

108—engineFailure

109—fireDetectorFailure

110—fuseFailure

111—generatorFailure

112—lowBatteryThreshold

113—pumpFailure

114—rectifierFailure

115—rectifierHighVoltage

116—rectifierLowFVoltage

117—ventilationsSystemFailure

118—enclosureDoorOpen

119—explosiveGas120—fire

121—flood

122—highHumidity

123—highTemperature

124—highWind

125—iceBuildUp

126—intrusionDetection

127—lowFuel

128—lowHumidity

129—lowCablePressure

130—lowTemperatue

131—lowWater

132—smoke

133—toxicGas

134—coolingSystemFailure

135—externalEquipmentFailure

136—externalPointFailure

151—storageCapacityProblem

152—memoryMismatch

153—corruptData

154—outOfCPUCycles

155—sfwrEnvironmentProblem

156—sfwrDownloadFailure

157—lossOfRealTimel

158—applicationSubsystemFailure

159—configurationOrCustomisationError

160—databaseInconsistency

161—fileError

162—outOfMemory

163—softwareError

164—timeoutExpired

165—underlayingResourceUnavailable

166—versionMismatch

201—bandwidthReduced

202—congestion

203—excessiveErrorRate

204—excessiveResponseTime

205—excessiveRetransmissionRate

206—reducedLoggingCapability

207—systemResourcesOverload

500—adapterError

501—applicationSubsystemFailture

502—bandwidthReducedX733

503—callEstablishmentError

504—communicationsProtocolError

505—communicationsSubsystemFailure

506—configurationOrCustomizationError

507—congestionX733

508—coruptData

509—cpuCyclesLimitExceeded

510—dataSetOrModemError

511—degradedSignalX733

512—dteDceInterfaceError

513—enclosureDoorOpenX733

514—equipmentMalfunction

515—excessiveVibration

516—fileErrorX733

517—fireDetected

518—framingErrorX733

519—heatingVentCoolingSystemProblem

520—humidityUnacceptable

521—inputOutputDeviceError

522—inputDeviceError

523—lanError

524—leakDetected

525—localNodeTransmissionErrorX733

526—lossOfFrameX733

527—lossOfSignalX733

528—materialSupplyExhausted

529—multiplexerProblemX733

530—outOfMemoryX733

531—ouputDeviceError

532—performanceDegraded

533—powerProblems

534—pressureUnacceptable

535—processorProblems

536—pumpFailureX733

537—queueSizeExceeded

538—receiveFailureX733

539—receiverFailureX733

540—remoteNodeTransmissionErrorX733

541—resourceAtOrNearingCapacity

542—responseTimeExecessive

543—retransmissionRateExcessive

544—softwareErrorX733

545—softwareProgramAbnormallyTerminated

546—softwareProgramError

547—storageCapacityProblemX733

548—temperatureUnacceptable

549—thresholdCrossed

550—timingProblemX733

551—toxicLeakDetected

552—transmitFailureX733

553—transmiterFailure

554—underlyingResourceUnavailable

555—versionMismatchX733

600—authenticationFailure

601—breachOfConfidentiality

602—cableTamper

603—delayedInformation

604—denialOfService

605—duplicateInformation

606—informationMissing

607—informationModificationDetectede

608—informationOutOfSequence

609—keyExpired

610—nonRepudiationFailure

611—outOfHoursActivity

612—outOfServic

613—proceduralError

614—unauthorizedAccessAttempt

615—unexpectedInformation

1024—other

Use the no form of this command to remove the probable cause of the event.

1.35.6   Examples

The following example shows how to configure the probable cause for the alarm model event as thresholdCrossed (549).

[local]jazz#config
[local]jazz(config)#snmp alarm model 1 state clear
[local]jazz(config-snmp-alarmmodel)#probablecause 549
[local]jazz(config-snmp-alarmmodel)#exit

1.36   process coredump

1.36.1   Purpose

Interrupts the specified process and saves the core dump file.

1.36.2   Command Mode

• exec (10)

1.36.3   Syntax Description

1.36.4   Default

None

1.36.5   Usage Guidelines

Use the process coredump command to interrupt a specified process and save the core dump file. You can specify the process either by its process name or PID.

For an overview of core dumps, crash files, and a guide to their management, see Performing Core Dump and Crash File Management Tasks in Managing Files for additional information.

Note:  

We strongly recommend that you configure the system to upload crash files automatically to a remote File Transfer Protocol (FTP) server, using the service upload-coredump command (in global configuration mode). By configuring this service, you maximize the use of available disk space and improve system stability and performance. For more information about the service upload-coredump command (in global configuration mode), see the Command List.

Note:  

This command is used to provide troubleshooting information to the technical support group.

Table 3 lists the keywords for the processes supported by this command.

(1)  The SmartEdge 100 router does not support 802.1Q.

(2)  Not all controller cards support flow.

(3)  The SmartEdge 100 router does not support Frame Relay.

1.36.6   Examples

The following example initiates a core dump and creates a crash file for the BGP process:

[local]Redback#process coredump bgp 

1.37   process restart

1.37.1   Purpose

Restarts a process that has been stopped.

1.37.2   Command Mode

• exec (10)

1.37.3   Syntax Description

1.37.4   Default

The default for the optional delay is two seconds.

1.37.5   Usage Guidelines

Use the process restart command to restart a process that has been stopped.

Table 4 lists the keywords for the processes supported by this command.

(1)  The SmartEdge 100 router does not support 802.1Q.

(2)  Not all controller cards support flow.

(3)  The SmartEdge 100 router does not support Frame Relay.

1.37.6   Examples

The following example restarts the BGP process after a five-minute delay (300 seconds):

[local]Redback#process restart bgp 300

1.38   process set

1.38.1   Purpose

Sets process management parameters.

1.38.2   Command Mode

• exec (10)

1.38.3   Syntax Description

1.38.4   Default

The heartbeat is on; the maximum number of crashes allowed is five per process within a 24 hour period; the spawn time is two seconds.

1.38.5   Usage Guidelines

Use the process set command to set process management parameters including whether the heartbeat is turned on or off, the kill time, the maximum number of crashes allowed within a configurable period of time, and the amount of time between the crash of a process and the subsequent spawn by the PM (spawn time).

Table 5 lists the keywords for the processes supported by this command.

(1)  The SmartEdge 100 router does not support 802.1Q.

(2)  Not all controller cards support flow.

(3)  The SmartEdge 100 router does not support Frame Relay.

The heartbeat is a message that each process sends to the PM to identify itself as an active process. If the heartbeat ceases, the PM considers the process a candidate for automatic restart. It can be useful for debugging processes to turn the heartbeat off so that a hung process is not restarted automatically by the PM.

1.38.6   Examples

The following example sets process management parameters for the BGP process:

[local]Redback#process set bgp kill-time 100

[local]Redback#process set bgp max-crashes 3 within 43200

[local]Redback#process set bgp spawn-time 10

1.39   process start

1.39.1   Purpose

Instructs the Process Manager (PM) to start the specified process.

1.39.2   Command Mode

• exec (10)

1.39.3   Syntax Description

1.39.4   Default

None

1.39.5   Usage Guidelines

Use the process start command to instruct the PM to start the specified process.

Table 6 lists the keywords for the processes supported by this command.

(1)  The SmartEdge 100 router does not support 802.1Q.

(2)  Not all controller cards support flow.

(3)  The SmartEdge 100 router does not support Frame Relay.

1.39.6   Examples

The following example starts the BGP process:

[local]Redback#process start bgp

1.40   process stop

1.40.1   Purpose

Stops the specified process.

1.40.2   Command Mode

exec (10)

1.40.3   Syntax Description

1.40.4   Default

None

1.40.5   Usage Guidelines

Use the process stop command to the specified process.

Table 7 lists the keywords for the processes supported by this command.

(1)  The SmartEdge 100 router does not support 802.1Q.

(2)  Not all controller cards support flow.

(3)  The SmartEdge 100 router does not support Frame Relay.

1.40.6   Examples

The following example stops the BGP process:

[local]Redback#process stop bgp

1.41   profile

1.41.1   Purpose

Assigns an existing named profile to the subscriber.

1.41.2   Command Mode

• subscriber configuration

1.41.3   Syntax Description

1.41.4   Default

The default profile is assigned to the subscriber.

1.41.5   Usage Guidelines

Use the profile command to assign an existing named profile to the subscriber.

If this subscriber will be a user of clientless IP service selection (CLIPS), adhere to the following guidelines:

• For static CLIPS circuits, the profile that you assign must have one and only one IP address; to assign an IP address to a subscriber profile, use the ip address command (in subscriber configuration mode).
• For dynamic CLIPS circuits, the profile that you assign must not include an IP address; instead, set the maximum number of IP addresses to 1, using the dhcp max-addrs command (in subscriber configuration mode). For more information about the dhcp max-addr command, see the Command List.

Use the no form of this command to assign the default profile to the subscriber.

1.41.6   Examples

The following example assigns the existing profile, hi-perf, to subscriber joe in the isp1 context:

[local]Redback(config)#context ips1

[isp1]Redback(config-ctx)#subscriber name joe

[isp1]Redback(config-sub)#profile hi-perf

1.42   profile (VPLS)

1.42.1   Purpose

In VPLS configuration mode, applies an existing Virtual Private LAN Services (VPLS) profile to a VPLS instance.

In port pseudowire configuration mode, applies an existing port pseudowire profile to a pseudowire connection.

1.42.2   Command Mode

• VPLS configuration
• port pseudowire configuration

1.42.3   Syntax Description

1.42.4   Default

None

1.42.5   Usage Guidelines

Use the profile command to apply an existing VPLS profile to a VPLS instance or an existing port pseudowire profile to port pseudowire connection. When a VPLS profile is applied, a VPLS peer instance is created for each neighbor defined in the profile, and a pseudowire connection is established using the attributes defined for the neighbor.

A VPLS profile must be configured using the vpls profile command (in global configuration mode) before it can be applied.

A port pseudowire profile must be configured using the port pseudo-wire profile command (in global configuration mode) before it can be applied.

Use the pw-id pw-num construct or pw-name pw-name construct to optionally specify a pseudowire ID (number or name) to signal the ID for pseudowires to the neighbor defined in the profile. If a pseudowire ID is not configured for a VPLS profile, then the VPLS instance-level default pseudowire ID is used.

Multiple VPLS profiles can be applied to the same VPLS instance. If two or more profiles reference the same PE (same IP address), then the neighbor from the first profile is used. The same profile cannot be applied multiple times even if the pseudowire IDs are different.

Use the no form of this command to delete a VPLS or port pseudowire profile.

1.42.6   Examples

The following example applies the foo VPLS profile to the VPLS instance on the to-pe4 bridge:

[local]Redback#config

[local]Redback(config)#context local

[local]Redback(config-ctx)#bridge to-pe4

[local]Redback(config-bridge)#vpls

[local]Redback(config-vpls)#profile foo pw-id 20

[local]Redback(config-vpls)#

The following example applies the foo port pseudowire profile name and port pseudowire profile ID 20 to the current port pseudowire connection:

[local]Redback#config

[local]Redback(config)#port pseudowire connect1 ethernet

[local]Redback(config-port)#profile foo pw-id 20

[local]Redback(config-port)#

1.43   propagate qos from ethernet

1.43.1   Purpose

For incoming packets, propagates Ethernet 802.1p user priority bits to packet descriptor (PD) quality of service (QoS) bits.

1.43.2   Command Mode

dot1q profile configuration

1.43.3   Syntax Description

1.43.4   Default

Ethernet 802.1p user priority bits are not propagated to DSCP bits.

1.43.5   Usage Guidelines

Use the propagate qos from ethernet command to propagate Ethernet 802.1p user priority bits to PD QoS bits.

Note:  

This command applies to incoming packets transmitted over 802.1Q permanent virtual circuits (PVCs) that reference the dot1q profile.

You can use the qos class-map command to define an optional mapping schema. If you specify the class-map map-name construct for the propagate qos from ethernet command, only the PD QoS values are affected. If the class-map map-name construct is not specified, the Ethernet 802.1p bits are also copied to the priority bits of the DSCP field in the IP header.

Use the no form of this command to disable the propagation of Ethernet 802.1p bits to PD QoS bits.

1.43.6   Examples

The following example propagates Ethernet 802.1p user priority bits to DSCP bits for incoming packets for all 802.1Q PVCs that reference the 802.1Q profile, 8021p-on:

[local]Redback(config)#dot1q profile 8021p-on

[local]Redback(config-dot1q-profile)#propagate qos from ethernet

1.44   propagate qos from ip

1.44.1   Purpose

Specifies a custom value mapping for propagating the Differentiated Services Code Point (DSCP) bits in the IP packet header to the packet descriptor (PD) priority bits for incoming IP packets.

1.44.2   Command Mode

• subscriber configuration
• interface configuration

1.44.3   Syntax Description

1.44.4   Default

DSCP values are copied to the PD values using a default mapping.

1.44.5   Usage Guidelines

Use the propagate qos from ip command to specify a custom value mapping for propagating the DSCP bits in the IP packet header to the PD priority bits for incoming IP packets. The DSCP bits are modified in the received IP packet according to the specified classification map. In subscriber configuration mode, this command allows you to customize the mapping for traffic received on a specific subscriber session. In interface configuration mode, this command allows you to customize the mapping for all IP traffic received through the interface. The SmartEdge router propagates classification values and marks packets before it applies any metering policy.

Custom classification mappings configured for either a subscriber or an interface affect Layer 3 (IP-routed) circuits only.

Use the qos class-map command with the ip in keywords (in global configuration mode) to define a mapping schema to be referenced by the propagate qos from ip command.

You can use the propagate qos from subscriber command (in L2TP peer configuration mode) to copy DSCP bits to PD values for Layer 2 Tunneling Protocol (L2TP) access concentrator (LAC) sessions, then use the propagate qos from ip command to specify a custom value mapping.

Use the no form of this command to remove a customized DSCP-to-PD mapping.

1.44.6   Examples

The following example customizes the propagation of IP header DSCP values to PD values for incoming packets of all subscriber sessions in the local context:

[local]Redback(config-sub)#qos class-map ip-to-pd ip in
[local]Redback(config-class-map)#ip df to qos af43
[local]Redback(config-class-map)#exit
[local]Redback(config)#context local
[local]Redback(config-ctx)#subscriber default
[local]Redback(config-sub)#propagate qos from ip class-map ip-to-pd

1.45   propagate qos from l2tp

1.45.1   Purpose

If no classification map is specified, propagates the packet descriptor (PD) priority bits to the Differentiated Services Code Point (DSCP) bits of the inner (subscriber) IP header for incoming Layer 2 Tunneling Protocol (L2TP) packets when the SmartEdge router is configured as an L2TP network server (LNS).

1.45.2   Command Mode

L2TP peer configuration (default peer only)

1.45.3   Syntax Description

1.45.4   Default

The DSCP bits in the incoming L2TP IP packet headers are not propagated to the DSCP bits in subscriber IP packet headers.

1.45.5   Usage Guidelines

Use the propagate qos from l2tp command to propagate the PD priority bits to the DSCP bits of the inner (subscriber) IP header if no classification map is specified for incoming L2TP packets when the SmartEdge router is configured as an LNS. Propagation occurs after the outer IP DSCP bits have been propagated to the PD priority bits as part of IP forwarding. If you specify a classification map, this command customizes the default mapping from the outer IP header DSCP value to the PD QoS value and leaves the inner IP header DSCP value unmodified.

Note:  

This propagation occurs only in the upstream direction; this command applies only to a SmartEdge router that is configured as an LNS as it receives packets from an L2TP access concentrator (LAC).

You can use the qos class-map command to define an optional mapping schema. If you do not specify the class-map map-name construct with the propagate qos from l2tp command, the SmartEdge router overwrites the value in the inner IP header with the DSCP value from the received outer IP header. If you specify the class-map map-name construct, the SmartEdge router customizes the default mapping from the outer IP header DSCP value to the PD QoS value and leaves the inner IP header DSCP value unmodified.

L2TP tunnels are User Datagram Protocol (UDP)/IP-encapsulated circuits that carry subscriber-based IP traffic encapsulated in Point-to-Point (PPP) sessions between routers. The LNS is the IP termination point for subscriber traffic. DSCP bits from the L2TP IP packet header can be propagated into subscriber traffic.

Use the no form of this command to disable the propagation of DSCP bits to the inner (subscriber) IP header or to remove the customized propagation to the QoS PD value.

1.45.6   Examples

The following example propagates DSCP bits from outer L2TP IP packet headers to DSCP bits in inner IP packet headers:

[local]Redback(config-ctx)#l2tp-peer default
[local]Redback(config-l2tp)#propagate qos from l2tp

1.46   propagate qos from mpls

1.46.1   Purpose

Enables mapping Multiprotocol Label Switching (MPLS) experimental (EXP) bits to Differentiated Services Code Point (DSCP) bits in the IP header or enables customized mapping of EXP to packet descriptor (PD) quality of service (QoS) values for incoming packets when the SmartEdge router is configured as a MPLS egress router.

1.46.2   Command Mode

MPLS router configuration

1.46.3   Syntax Description

1.46.4   Default

MPLS EXP bits are not mapped to DSCP bits.

1.46.5   Usage Guidelines

Use the propagate qos from mpls command to enable mapping MPLS EXP bits to DSCP bits in the IP header or enable customized mapping of EXP to PD QoS values for incoming packets when the SmartEdge router is configured as a MPLS egress router. If the optional class-map map-name construct is not specified, the EXP bits are also copied to the priority bits of the DSCP field in the IP header.

If you specify the optional class-map map-name construct, the propagate qos from mpls command specifies a custom value mapping for MPLS EXP bits to PD values. The DSCP bits are unaffected. In this case, use the qos class-map command to define a mapping schema, then reference the schema using the class-map map-name construct. If you do not specify a Layer 2 virtual private network (L2VPN) classification map, the standard classification map applies to both Layer 2 and Layer 3 traffic.

If you specify the optional l2vpn class-map map-name construct with the class-map map-name construct, the L2VPN classification map applies to Layer 2 traffic and Layer 3 traffic uses the default 8P0D mapping schema. If you specify both the l2vpn class-map map-name construct and the class-map map-name construct, Layer 2 traffic uses the L2VPN classification map and Layer 3 traffic uses the standard classification map.

If you use the mpls use-ethernet command to perform a secondary lookup and the encapsulated packet contains no virtual LAN (VLAN) header, the PD value is determined by mapping the MPLS EXP value using the default 8P0D schema.

Use the no form of this command to disable the mapping of MPLS EXP bits to DSCP bits or remove a customized EXP-to-PD mapping.

1.46.6   Examples

The following example enables the mapping of MPLS EXP bits to DSCP bits for outgoing packets:

[local]Redback(config-ctx)#router mpls
[local]Redback(config-mpls)#propagate qos from mpls 

The following example specifies a customized mapping of MPLS EXP bits to PD values by referencing the existing MPLS ingress classification map exp-to-pd:

[local]Redback(config-ctx)#router mpls
[local]Redback(config-mpls)#propagate qos from mpls class-map exp-to-pd

1.47   propagate qos from subscriber

1.47.1   Purpose

For incoming packets when the SmartEdge router is configured as a Layer 2 Tunneling Protocol (L2TP) access concentrator (LAC), propagates the Differentiated Services Code Point (DSCP) bits in the subscriber’s IP packet header to the packet descriptor (PD) priority bits.

1.47.2   Command Mode

L2TP peer configuration (default peer only)

1.47.3   Syntax Description

1.47.4   Default

DSCP bits are not propagated from the incoming subscriber IP packet header to the PD for the subscriber IP packet.

1.47.5   Usage Guidelines

For incoming packets when the SmartEdge router is configured as a LAC, use the propagate qos from subscriber command to propagate the DSCP bits in the subscriber’s IP packet header to the PD priority bits.

Use the upstream keyword to propagate from inbound packets from the subscriber. Use the downstream keyword to propagate from inbound packets from the network. Use the both keyword to propagate in both directions.

The SmartEdge router performs a deep packet inspection of inner IP packet headers and copies the DSCP bits in the IP header. L2TP tunnels are User Datagram Protocol (UDP)/IP-encapsulated circuits that carry subscriber-based Point-to-Point Protocol (PPP) sessions between routers. On L2TP tunnels, subscriber IP packets are encapsulated in PPP packets, which themselves are encapsulated in L2TP packets. DSCP bits can be propagated from inner IP packet headers to outer L2TP IP packet headers, and vice versa. DSCP bits are propagated between layers of encapsulated packets so that any Layer 3 device located between an LNS and a LAC can recognize and apply DSCP settings.

Use the no form of this command to disable the propagation of DSCP bits in the specified direction or, if neither keyword is specified, in both directions.

1.47.6   Examples

The following example propagates the DSCP bits in a subscriber IP packet header to the PD for the subscriber IP packet header in the upstream direction only:

[local]Redback(config-ctx)#l2tp-peer default
[local]Redback(config-l2tp)#propagate qos from subscriber upstream

The following example propagates the DSCP bits from subscriber IP packet headers to DSCP bits in L2TP IP packet headers in both directions:

[local]Redback(config-ctx)#l2tp-peer default
[local]Redback(config-l2tp)#propagate qos from subscriber

1.48   propagate qos to ethernet

1.48.1   Purpose

Propagates packet descriptor (PD) priority values to Ethernet 802.1p user priority bits for outgoing packets.

1.48.2   Command Mode

dot1q profile configuration

1.48.3   Syntax Description

1.48.4   Default

Differentiated Services Code Point (DSCP) bits are not propagated to Ethernet 802.1p user priority bits.

1.48.5   Usage Guidelines

Use the propagate qos to ethernet command to propagate PD priority values to Ethernet 802.1p user priority bits for outgoing packets.