Cisco IOS Dial Technologies Command Reference

 

Syntax Description

 

Command Default

256 packets

 

Command History

 

Usage Guidelines

There are two types of IP header compression used over PPP: Van Jacobsen header compression, which is defined in RFC 1332, and a newer compression type described in RFC 2509. The ppp iphc set of commands controls parameters that pertain to the form of IPHC described in RFC 2509.

The IPHC specification allows low speed links to run more efficiently when IP headers are extremely large. IPHC supports compressed Real-Time Transport Protocol (cRTP), compressed User Datagram Protocol (cUDP), and compressed Transaction Control Protocol (cTCP).

An IPHC-enabled interface sends only changes to the header instead of sending the entire header with every packet. At the beginning of a transmission, the transmitting end (the compressor) sends a full header packet to the receiving end (the decompressor). After the initial packet is sent, the compressor sends all other packets with headers that contain only the differences between them and the original full header. The decompressor maintains a copy of the original full header and reconstructs all the other packet headers by adding the changes to them.

The header data that is different with each packet is referred to as the session state, and is identified by a session ID or connection ID.

When the decompressor receives a compressed packet, it reconstructs the packet header by adding the difference to the saved uncompressed header. Typically, IPHC enables the header to be compressed to two bytes (four bytes if UDP checksums are used).

The following fields in a packet header usually remain the same throughout a transmission:

• IP source and destination addresses
• UDP and TCP source and destination ports
• RTP synchronization source (SSRC) fields

The following fields in a packet header usually change during a transmission:

• IP packet ID
• Checksum
• Sequence number
• RTP time stamp
• RTP marker bit

The ppp iphc max-period command is specifically related to an IPHC frame format known as compressed_non_TCP. The recovery of lost compressed_non_TCP frames on lossy links is much improved by allowing more full headers to flow and by configuring less compression.

Examples

The following example shows how to increase the maximum number of compressed packets that can be sent before a full header from 256 to 512 packets when configuring IPHC control options over PPP:

 

Related Commands

 

Syntax Description

 

Command Default

5 seconds

 

Command History

 

Usage Guidelines

There are two forms of IP header compression used over PPP: Van Jacobsen header compression, which is defined in RFC 1332, and a newer form of compression described in RFC 2509. The ppp iphc set of commands controls parameters that pertain to the form of IPHC described in RFC 2509.

The IPHC specification allows low speed links to run more efficiently by reducing the size of IP headers as transmitted on the link. IPHC supports compressed Real-Time Transport Protocol (cRTP), compressed User Datagram Protocol (cUDP), and compressed Transaction Control Protocol (cTCP).

An IPHC-enabled interface sends only changes to the header instead of sending the entire header with every packet. At the beginning of a transmission, the transmitting end (the compressor) sends a full header packet to the receiving end (the decompressor). After the initial packet is sent, the compressor sends all other packets with headers that contain only the differences between them and the original full header. The decompressor maintains a copy of the original full header and reconstructs all the other packet headers by adding the changes to them.

The header data that is different with each packet is referred to as the session state, and is identified by a session ID or connection ID.

When the decompressor receives a compressed packet, it reconstructs the packet header by adding the difference to the saved uncompressed header. Typically, IPHC enables the header to be compressed to two bytes (four bytes if UDP checksums are used).

The following fields in a packet header usually remain the same throughout a transmission:

• IP source and destination addresses
• UDP and TCP source and destination ports
• RTP synchronization source (SSRC) fields

The following fields in a packet header usually change during a transmission:

• IP packet ID
• Checksum
• Sequence number
• RTP time stamp
• RTP marker bit

The ppp iphc max-time command is specifically related to an IPHC frame format known as compressed_non_TCP. The recovery of lost compressed_non_TCP frames on lossy links is much improved by allowing more full headers to flow and by configuring less compression.

Examples

The following example shows how to change the number of compressed packets that can be sent before a full header from the default 5 seconds to 10 seconds:

 

Related Commands

 

Syntax Description

 

Command Default

No LCP delay timer is configured.

 

Command History

 

Usage Guidelines

Configure an LCP delay timer to allow the peer device a short amount of time to send the first packet after the PPP link comes up. If the LCP delay timer expires before a CONFREQ is received from the peer, the router can initiate LCP negotiations.

The LCP delay timer is applied only to incoming connections. PPP does not delay for outbound connections or connections where PPP cannot determine a direction.

Use the random max-delay-seconds keyword and argument combination add a random amount of time to the LCP delay timer. Setting a random delay on the initiation of LCP negotiations prevents overload when many PPP links come up at the same time.

Use the discard keyword to specify that incoming CONFREQs should be discarded until the configured delay has expired. LCP negotiations will not be initiated until the LCP delay timer has expired.

Examples

The following example configures an LCP delay timer of 4 seconds. If a CONFREQ is not received before the LCP delay timer expires, LCP negotiations can be initiated by either peer.

The following example configures an LCP delay timer that will expire at a random time between 5 and 15 seconds after the link comes up. If a CONFREQ is not received before the LCP delay timer expires, LCP negotiations can be initiated by either peer.

The following example configures an LCP delay timer of 3.25 seconds and specifies that incoming CONFREQs will be discarded until the LCP delay timer has expired. After 3.25 seconds, LCP negotiations can be initiated by either peer.

The following example configures an LCP delay timer that will expire at a random time between 10 and 15 seconds after the link comes up, and specifies that incoming CONFREQs will be discarded until the LCP delay timer has expired. After the LCP delay timer expires, negotiations can be initiated by either peer.

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Command is enabled by default.

 

Command History

 

Usage Guidelines

Some systems, typically those with external modems, may have problems with slow or electrically noisy hardware. If the no ppp lcp fast-start command is specified, PPP starts a debounce timer and waits for it to expire before attempting to communicate with the peer system, thereby reducing the probability of a false start on the interface.

If the no ppp lcp fast-start command is not specified, PPP will not use a debounce timer and will respond immediately to incoming packets once a connection is made.

The default fast start enabled state should not be disabled unless there is a problem with slow or electronically noisy hardware. This setting prevents PPP from waiting for a debounce timer to expire before responding to inbound frames.

Examples

The following example disables fast start:

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

The PPP LCP is not set to a predictive state.

 

Command History

 

Usage Guidelines

The ppp lcp predictive command is useful in networks that accept connections from devices that require a reduction in the LCP negotiation cycle time. This command reduces the amount of time needed for PPP to negotiate with the peer so that connections can be made in an acceptable amount of time. The following changes to the LCP negotiation strategy make this time reduction possible:

• Send an LCP Configure-Ack packet, then send the next-level LCP Configure-Request packet before receiving acknowledgment for the PPP Configure-Request packet.
• Send an LCP Configure-Ack packet after sending LCP Configure-Reject and Configure-Nak packets for certain configuration options.

These changes can reduce connection delay by approximately 40 percent.

The ppp lcp predictive command is configured on group asynchronous and dialer interfaces running PPP or Multilink PPP.

Examples

The following example sets LCP and Internet Protocol Control Protocol (IPCP) to predictive states on a dialer interface:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Command is disabled.

 

Command History

 

Usage Guidelines

The ppp link reorders command indicates that a link can receive packets in a different order than the peer system sent them. This situation can be encountered with PPP tunneling mechanisms such as Layer 2 Forwarding (L2F) and the Layer 2 Transport Protocol (L2TP) that do not always enforce strictly serial delivery of frames from source to final destination. Such links can pose problems for PPP features that depend upon in-order delivery of packets, such as compression, encryption, network header compression, and Multilink PPP.

Setting this option allows some PPP systems to compensate to an extent for the nonserial delivery of packets, although this compensation can incur a performance penalty. It is not normally necessary to configure the ppp link reorders command. PPP automatically recognizes that the condition exists for Virtual Private Network (VPN) tunnels, and the misdelivery situation will not occur on normal serial interfaces.

Examples

The following example sets the ppp link reorders command advisory flag:

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Loopback detection is enabled.

 

Command History

 

Usage Guidelines

A circuit loopback normally indicates faulty external switching equipment or wiring errors. The PPP protocol includes a mechanism that detects when a circuit is looped back, that is, when the circuit is fed back upon itself such that the router is reading its own output on that link. A first phase of loopback detection occurs during Link Control Protocol (LCP) negotiation when the circuit is being established. A loopback condition that occurs after the connection is made (after LCP negotiation) can be detected if link keepalives are enabled. If keepalives are disabled on the link, the second phase of loopback detection is not available.

The normal operation (default) is for PPP to check for a loopback condition and terminate the connection when a loopback is detected. There are, however, some situations where it is necessary to disable loopback detection, such as during certain testing situations, or when software detects problematic peers that do not implement the PPP protocol correctly. The ppp loopback ignore command disables normal operation; the no ppp loopback ignore command restores normal operation.

Note Loopback detection depends upon successful negotiation of the LCP Magic Number option during link establishment. Some implementations may not support this option.

Examples

The following example shows PPP loopback detection being disabled:

 

Related Commands

 

Syntax Description

 

Command Default

The default is 0.

 

Command History

 

Usage Guidelines

This command applies to any serial interface (asynchronous serial, synchronous serial, or ISDN) on which PPP encapsulation is enabled.

Examples

The following example sets BRI interface 0 to allow two additional retries after an initial authentication failure (for a total of three failed authentication attempts):

 

Related Commands

 

Syntax Description

 

Command Default

10 attempts (packets) and a default retry timeout period of 2 seconds

 

Command History

 

Usage Guidelines

The ppp max-configure command sets the maximum number of Configure-Request packets that will be sent for any particular control protocol and that have gone unanswered before PPP will assume that the peer is unable to respond to the packets and will cease trying to negotiate that particular control protocol.

There is generally no reason to adjust the default maximum number of Configure-Request packets sent (attempts). The number might need to be increased slightly in the unlikely event that you are connecting to a peer that is slow to start negotiations of some protocol. Because the default is 10 packets (attempts), and the default retry timeout period is 2 seconds, a slow peer would be one that takes more than 20 seconds to start protocol negotiation.

For ordinary network control protocols (NCPs), the protocol will be put in a passive state whereby PPP will accept inbound negotiation packets, thereby giving the peer a chance to attempt negotiations later on.

If the Link Control Protocol (LCP) is used, then failure to negotiate LCP implies that the link will be reset. On a dialup connection, this reset will disconnect the call. For a leased-line connection, the reset will merely result in PPP attempting to restart after a short delay.

Note None of the supported PPP authentication protocols conform to RFC 1661-style control protocols, and the protocols are not affected by the ppp max-configure command. Rather, the authentication protocol commands have their own set of commands to fine-tune control.

Examples

The following example returns the maximum number of attempts to send a Configure-Request packet to the default of 10:

 

Related Commands

 

Syntax Description

 

Command Default

5 attempts

 

Command History

 

Usage Guidelines

Unless you have reason to believe that a control protocol that is slow to converge will actually converge if given more chances, there is no reason to increase the default value of this command.

The ppp max-failure command sets the maximum number of successive Configure-NAK packets (attempts) that will be sent for any control protocol before PPP will assume that the peer is unwilling or incapable of converging (adapting to its own negotiation parameters), and that the negotiation parameters will never succeed.

Once the maximum limit is reached, PPP will start sending Configure-Reject packets rather than Configure-NAK packets for the offending parameters. The peer’s response to this action should be to stop sending the offending parameters.

Note None of the supported PPP authentication protocols conform to RFC 1661-style control protocols, and the protocols are not affected by the ppp max-failure command. Rather, the authentication protocol commands have their own set of commands to fine-tune control.

Examples

The following example returns the maximum number of attempts to send a Configure-NAK packet to the default of 5:

 

Related Commands

 

Syntax Description

 

Command Default

2 attempts

 

Command History

 

Usage Guidelines

There is little reason to change the default value of the ppp max-terminate command. The action of PPP sending a Terminate-Request packet is mainly a courtesy to the peer system; the protocol itself will be terminated whether or not the peer acknowledges the request. Sending the Terminate-Request packet twice makes an allowance that a single instance could be lost in transit.

When PPP wants to terminate a control protocol, it sends a Terminate-Request packet and waits for a limited time for the peer to respond with a Terminate-Ack packet. This command sets the maximum number of attempts that will be made, that is, the maximum number of Terminate-Request packets that will be sent, before PPP gives up waiting for the Terminate-Ack packet and automatically stops the protocol.

Note None of the supported PPP authentication protocols conform to RFC 1661-style control protocols, and the protocols are not affected by the ppp max-terminate command. Rather, the authentication protocol commands have their own set of commands to fine-tune control.

Examples

The following example returns the maximum number of attempts to send a Terminate-Request packet to the default of 2:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Hardware PPP framing on an asynchronous interface is enabled.

 

Command History

 

Usage Guidelines

Do not use the no form of this command unless instructed to do so by Cisco Technical Assistance Center (TAC) or Cisco technical support.

Examples

The following example shows how to disable the ppp m icrocode command in interface configuration mode:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

This command is disabled by default.

 

Command History

 

Usage Guidelines

This command is configured only on virtual template interfaces.

By default, the LNS does not enforce matching of the MRU value advertised by the LAC with the MRU value that the LNS would advertise. Use the ppp mru match command to enforce strict matching of the MRU that is advertised by the Layer 2 Tunneling Protocol (L2TP) access concentrator (LAC) with the maximum transmission unit (MTU) of the relevant virtual template interface on the LNS. A mismatch can occur because the effective MRU size for a virtual access interface is not necessarily limited to the MTU size.

This command can be useful to inform the client PPP stack of the true MRU, when that PPP implementation is capable of adapting its MTU based on LCP MRU negotiation.

Examples

The following example shows LCP renegotiation being triggered on an MRU mismatch:

 

Related Commands

 

Syntax Description

 

Command Default

This command is disabled by default.

 

Command History

 

Usage Guidelines

This command specifies that MS-CHAP authentication is disabled for all calls, meaning that all attempts by the peer to force the user to authenticate using MS-CHAP will be refused. If the callin keyword is used, MS-CHAP authentication is disabled for incoming calls from the peer, but will still be performed on outgoing calls to the peer.

If outbound Password Authentication Protocol (PAP) has been enabled (using the ppp pap sent-username command), PAP will be suggested as the authentication method in the refusal packet.

Examples

The following example shows how to disable MS-CHAP authentication if a peer calls in requesting MS-CHAP authentication. The method of encapsulation on interface ISDN BRI number 0 is PPP.

 

Related Commands

 

Syntax Description

 

Command Default

This command is disabled by default.

 

Command History

 

Usage Guidelines

This command specifies that MS-CHAP version 2 authentication is disabled for all calls, meaning that all attempts by the peer to force the user to authenticate using MS-CHAP version 2 will be refused. If the callin keyword is used, MS-CHAP version 2 authentication is disabled for incoming calls from the peer, but will still be performed on outgoing calls to the peer.

If outbound Password Authentication Protocol (PAP) has been enabled (using the ppp pap sent-username command), PAP will be suggested as the authentication method in the refusal packet.

Examples

The following example shows how to disable MS-CHAP version 2 authentication if a peer calls in requesting MS-CHAP version 2 authentication. The method of encapsulation on interface ISDN BRI number 0 is PPP.

 

Related Commands

 

Syntax Description

 

Command Default

Automatic adaption of the MTU size for PPP is not enabled.

 

Command History

 

Usage Guidelines

By default, the Cisco IOS software will not adapt the interface MTU to the peer or proxy MRU.

Note By default, the LNS does not renegotiate Link Control Protocol (LCP). If the LNS has a different MTU defined, the call setup experiences a failure. Use the ppp mtu adaptive command to adjust the LNS MRU value to the CPE's negotiated value with the LAC.

Use this command on interfaces where a number of peers with different MRU settings may connect. In Cisco IOS Release 12.2(7) and later releases, this command is configured on virtual template interfaces and dialer interfaces. In Cisco IOS Release 12.3(14)T and later releases, the ppp mtu adaptive command without the proxy keyword can be configured on serial interfaces.

The proxy keyword is not typically required. It is used only as a workaround when the client PPP stack cannot correctly advertise its MRU requirements.

Examples

The following example defines autonegotiation of the MTU size on a virtual template:

 

Related Commands

 

Syntax Description

 

Defaults

This command is disabled. When BACP is enabled, the defaults are to accept calls and to set the timeout pending at 30 seconds.

 

Command History

 

Usage Guidelines

This command applies only to interfaces that use PPP encapsulation.

MLP and PPP reliable links do not work together.

When the ppp multilink command is used, the first channel will negotiate the appropriate Network Control Protocol (NCP) layers (such as the IP Control Protocol and IPX Control Protocol), but subsequent links will negotiate only the link control protocol and MLP. NCP layers do not get negotiated on these links, and it is normal to see these layers in a closed state.

This command with the bap keyword must be used before configuring any ppp bap commands and options. If the bap required option is configured and a reject of the options is received, the multilink bundle is torn down.

The no form of this command without the bap keyword disables both MLP and BACP on the interface.

The dialer load-threshold command enables a rotary group to bring up additional links and to add them to a multilink bundle.

Before Cisco IOS Release 11.1, the dialer-load threshold 1 command kept a multilink bundle of any number of links connected indefinitely, and the dialer-load threshold 2 command kept a multilink bundle of two links connected indefinitely. If you want a multilink bundle to be connected indefinitely, you must set a very high idle timer.

Note By default, after changing hostnames, an MLP member link does not undergo failure recovery automatically. You must use the ppp chap hostname command to define the MLP bundle name on an endpoint. If this command is not configured and the hostname is changed, then a link flap will not return the link back to the bundle.

Cisco 10000 Series Router

The ppp multilink command has no arguments or keywords.

Examples

The following partial example shows how to configure a dialer for MLP:

 

Related Commands

 

Syntax Description

 

Command Default

The default endpoint discriminator is the globally configured host name, or the Challenge Handshake Authentication Protocol (CHAP) host name or Password Authentication Protocol (PAP) sent-username configured on the interface. See the “Usage Guidelines” for additional information.

 

Command History

 

Usage Guidelines

By default, PPP uses the same string for the endpoint discriminator that it would provide for authentication to negotiate use of MLP with the peer. The string (username) is configured for the interface with the ppp chap hostname or ppp pap sent-username command, or defaults to the globally configured host name (or stack group name, if the interface is a Stack Group Bidding Protocol, or SGBP, group member). The keywords supplied with the ppp multilink endpoint command allow a different endpoint discriminator to be defined. You can reset the default condition by entering the no ppp multilink endpoint command.

The difference between the no ppp multilink endpoint command and the ppp multilink endpoint hostname command is that for the first command, MLP supplies the name used for authentication (which may or may not be the router host name), and the second command always uses the router host name, regardless of any local authentication configuration.

Both the hostname and string keywords use the local endpoint class, the differences between them being that the string keyword allows you to enter a value, while the hostname keyword uses the configured (default) host name.

Note Do not configure the ppp multilink endpoint command on MLP bundle interfaces. Configure this command on each interface that will be an MLP bundle member, not on the bundle interface itself.

Refer to RFC 1990 for more information about MLP and the endpoint discriminator option.

Examples

The following partial example changes the endpoint discriminator from the CHAP host named group 1 to IP address 10.1.1.4:

 

Related Commands

 

Syntax Description

 

Command Default

The default value is 30 milliseconds if interleaving is enabled or if the bundle contains links that have differing bandwidths. See the “Usage Guidelines” for more information.

 

Command History

 

Usage Guidelines

By default, MLP has no fragment size constraint. Packets are divided into a number of fragments based on the number of links in the bundle. The size of any fragment is unconstrained, but the maximum number of fragments is constrained by the number of links. If interleaving is enabled, if the bundle contains links that have differing bandwidths, or if a fragment delay is explicitly configured with the ppp multilink fragment delay command, then MLP uses a different fragmentation algorithm. In this mode, the number of fragments is unconstrained, but the size of each fragment is limited to the fragment delay value, or 30 milliseconds if the fragment delay has not been configured.

The ppp multilink fragment delay command is useful when packets are interleaved and traffic characteristics such as delay, jitter, and load balancing must be tightly controlled.

The ppp multilink fragment delay command applies only to multilink interfaces that can configure a bundle interface, including multilink interfaces, virtual templates, dialer interfaces, and ISDN BRI or PRI interfaces.

The value assigned to the milliseconds or microseconds argument is scaled by the speed at which a link can convert the time value into a byte value. If a bundle has multiple links with varying speeds, the absolute size of a fragment will differ for each link.

MLP chooses a fragment size on the basis of the maximum delay allowed. If real-time traffic requires a certain maximum bound on delay, using this command to set that maximum time can ensure that a real-time packet will get interleaved within the fragments of a large packet.

Examples

The following example configures a maximum fragment delay of 20 milliseconds:

The following example configures a maximum fragment delay of 500 microseconds (1/2 millisecond):

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Fragmentation is enabled.

 

Command History

 

Usage Guidelines

The ppp multilink fragment delay and ppp multilink interleave commands have precedence over the ppp multilink fragment disable command. Therefore, the ppp multilink fragment disable command has no effect if these commands are configured for a multilink interface and the following message displays:

To completely disable fragmentation, you must do the following:

Disable multilink fragmentation using the ppp multilink fragment disable command if fragmentation causes performance degradation. Performance degradation due to multilink fragmentation has been observed with asynchronous member links.

Examples

The following example disables packet fragmentation:

 

Related Commands

 

Syntax Description

 

Command Default

16 fragments

 

Command History

 

Usage Guidelines

Use the ppp multilink fragment maximum command to control the number of fragments into which a PPP frame may be fragmented. The ppp multilink fragment maximum command has been used to disable fragmentation entirely by setting the number of fragments to 1. This setting is better accomplished using the ppp multilink fragment disable command.

The limit set using the ppp multilink fragment maximum command applies only when Multilink PPP (MLP) is fragmenting packets in a mode where it is constraining the number of fragments rather than the size of the fragments. See the description about fragmentation modes in the section “Usage Guidelines” of the ppp multilink fragment delay command for more details.

Examples

The following example uses the ppp multilink fragment maximum command to fragment each frame into no more than four fragments:

 

Related Commands

 

Syntax Description

 

Command Default

No maximum fragment size is set.

 

Command History

 

Usage Guidelines

Use the ppp multilink fragment size command to specify a maximum fragment size that is smaller than the size automatically computed by the value set with the ppp multilink fragment delay command. The ppp multilink fragment size command may be configured on the bundle interface or on the member links. If the command is configured on the bundle interface, the same fragment size is used by all of the links in the bundle. If it is configured in both places, the configuration on the member link takes precedence.

Examples

The following example configures a maximum fragment size of 100 bytes, not including link layer or multilink header overhead:

 

Related Commands

 

Syntax Description

 

Command Defaults

If the ppp multilink command is configured on an interface, the interface can join any multilink group. If the ppp multilink command is not configured on an interface, the interface cannot join a multilink group.

 

Command History

 

Usage Guidelines

When the ppp multilink group command is configured on an interface, the interface is restricted from joining any interface but the designated multilink group interface. If a peer at the other end of the interface tries to join a different multilink group, the connection is severed. This restriction applies when Multilink PPP (MLP) is negotiated between the local end and the peer system. The interface can still come up as a regular PPP interface.

The ppp multilink group command cannot be configured on an interface if the multilink group interface is not configured.

To modify the multilink group configuration on a serial interface, the existing PPP multilink group configuration must be removed from the serial interface.

When the multilink group interface is removed, the PPP multilink group configuration is removed from all the member links that have joined the specified multilink group.

The ppp multilink group command is primarily used with the MLP inverse multiplexer as described in the “Configuring Media-Independent PPP and Multilink PPP” chapter in the Dial Technologies Configuration Guide.

Cisco 10000 Series Router

The group-number option of the ppp multilink group command identifies the multilink group. This number must be identical to the multilink-bundle-number that you assign to a multilink interface. Valid group numbers are:

• MLP over serial-based Link Fragmentation and Interleaving (LFI)

– 1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

– 1 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

• Single-VC MLP over ATM-based LFI

– 10,000 and higher

• Multi-VC MLP over ATM-based LFI

– 1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)

– 1 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)

• MLP over Frame Relay based LFI

– 10,000 and higher

Examples

The following example shows how to configure a multilink group interface and configure a serial link to join the multilink group interface:

The following sample error message is displayed when a PPP multilink group is configured on a serial link before the multilink group interface is configured:

The following sample error message is displayed when the multilink group configuration on a serial link is modified before the existing multilink group configuration is removed:

The following sample output displays the serial interface configuration before and after the removal of the multilink group interface:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

The idle link flag is not set.

 

Command History

 

Usage Guidelines

When the idle link flag is enabled, Multilink PPP (MLP) places the slowest link in a bundle into an idle receive-only mode whenever the bundle has more than one link.

This mode is used for the Always On/Dynamic ISDN (AO/DI) feature, where a bundle contains one permanent slow-speed member link, which is on an X.25 circuit contained on an ISDN D channel. As additional and faster links join the MLP bundle, the D channel circuit will be idled and traffic will be confined to the faster links.

The ppp multilink idle-link command was intended specifically to enable the AO/DI feature. The command will work on any bundle, but normally should not be used outside the AO/DI environment.

Examples

The following example configures the interface (dialer interface 1) to add links to the MLP bundle once the traffic load on the primary link is reached:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Interleaving is disabled.

 

Command History

 

Usage Guidelines

The ppp multilink interleave command applies only to interfaces that can configure a bundle interface, such as virtual templates, dialer interfaces, multilink interfaces, and ISDN BRI or PRI interfaces.

Interleaving works only when the queuing mode on the bundle has been set to fair queuing (all platforms except the VIP-enabled Cisco 7500 series routers) or to distributed low latency queuing (dLLQ) for the VIP-enabled Cisco 7500 series routers.

On the VIP-enabled Cisco 7500 series routers, distributed Cisco Express Forwarding (dCEF) must be enabled, and dLLQ must be configured using the priority command in policy map configuration mode, before ppp multilink interleave command is used.

For all platforms except the VIP-enabled Cisco 7500 series routers, the ppp multilink interleave command should not be set unless weighted fair queuing (WFQ) has been configured using the default fair-queue command.

If interleaving is enabled when fragment delay is not configured, the default delay is 30 milliseconds. The fragment size is derived from that delay, depending on the bandwidths of the links.

Examples

The following example defines a virtual interface template that enables MLP interleaving and a maximum real-time traffic delay of 20 milliseconds, and then applies that virtual template to the MLP bundle:

The following example shows the configuration of LFI using MLP running on top of a PPP link over Frame Relay using a virtual template interface:

The following example shows the configuration of LFI using MLP running on top of a PPPoATM link on an ATM interface. This configuration uses a virtual template interface.

The following example shows the configuration of LFI over a leased line:

The following example shows a simple leased-line interleaving configuration using a virtual access interface bundle and default WFQ:

The following example shows a simple leased-line interleaving configuration using a dedicated multilink interface:

 

Related Commands

 

Syntax Description

 

Command Default

255 links

 

Command History

 

Usage Guidelines

This command affects only dial-on-demand dynamic bandwidth environments.

The value configured in the ppp multilink links maximum command specifies the maximum number of links allowed in a bundle. When more links than the number assigned with the ppp multilink links maximum command try to enter the bundle, MLP hangs up its dialer channels to reduce the number of links.

Member links that are not dialer lines are not affected by settings in the ppp multilink links maximum command. If a bundle contains a mix of leased and dialer links, the leased lines count against the total, but the leased lines remain as permanent member links and will do so even if the value specified for the maximum number of links is exceeded.

Use this command to fine-tune the ppp multilink load-threshold command settings and to prevent runaway expansion of a bundle when a low threshold is set.

Examples

The following example sets the maximum number of links to 50:

 

Related Commands

 

Syntax Description

 

Command Default

0 links

 

Command History

 

Usage Guidelines

This command affects only dial-on-demand dynamic bandwidth environments.

The value configured for the links argument specifies the minimum number of links that MLP will try to keep in a bundle. If a bundle contains fewer links than the number specified by the links argument, and there is a means to establish additional channels (for example, available dialer channels), then MLP attempts to increase the number of links up to the specified limit. MLP attempts to dial up additional links to obtain the number specified by the links argument, even if the load does not exceed the load threshold.

If the mandatory keyword is configured, the minimum number of links specified by the links argument must be in the bundle. Whenever a link is added to or removed from the bundle, the number of links is checked against the specified minimum number. If the number of links in the bundle falls below the specified minimum, all NCPs will be disabled for the bundle. NCPs will be established if the number of links meets the specified minimum.

If the dialer max-call command is configured, MLP will not exceed its value even if the ppp multilink links maximum command is configured for a higher value. This restriction does not affect the number of links that you can configure; rather it affects what happens at run time.

Examples

The following example sets the minimum number of links to 12:

The following example sets the minimum number of links to 4 and specifies that the bundle must have at least four links to establish and maintain NCPs:

 

Related Commands

 

Syntax Description

 

Command Default

No active dynamic bandwidth mechanisms. If a load-threshold argument is configured without any of the optional keywords, the link defaults to examining outbound traffic load (outbound).

 

Command History

 

Usage Guidelines

The dialer load-threshold command is generally configured instead of the ppp multilink load-threshold command, and MLP inherits the values set by the dialer load-threshold command when a bundle configuration is taken from a dialer interface.

Use the ppp multilink load-threshold command for dynamic bandwidth (dial-on-demand) systems in which MLP will need to dial additional links as needed to increase the bandwidth of a connection. When the load on the bundle interface exceeds the set value, links are added. When the load on the bundle interface drops below the set value, links are dropped.

Examples

The following example sets the MLP inbound load threshold to 10:

 

Related Commands

 

Syntax Description

 

Command Default

The default values for the local MRRU are the value of the multilink group interface maximum transmission unit (MTU) for multilink group members, and 1524 bytes for all other interfaces.

 

Command History

 

Usage Guidelines

This command allows the MRRU value to be configured on MLP interfaces and member links. This command is useful for interfaces running an application such as IP Security (IPsec), where the addition of the IPsec header causes the packet to exceed the 1500-byte MTU of a typical IP packet.

When using a large-bundle interface MTU size, you must ensure that the individual frames-per-fragment size passed to the link interfaces is not greater than the link interface MTU setting or the peer MRRU setting. This size limit can be achieved in one of the following two ways:

• Configure the link interface MTU setting appropriately.
• Configure fragmentation such that the link MTU settings will never be violated.

When MLP is configured, several physical interfaces can constitute one logical connection to the peer. To represent the logical connection, software provides a logical interface, often called the bundle interface. This interface will have the IP address, for instance, and the MTU setting of the interface that IP uses when it is deciding whether to fragment an IP datagram that needs to be forwarded. The physical interfaces simply forward individual MLP fragments or frames that are given to them by the bundle interface.

The result of having to decide whether to fragment a packet is that, whereas with simple PPP the interface MTU must not exceed the peer’s MRRU, with MLP the MTU size of the bundle interface must not exceed the MRRU setting of the peer. The MRRU settings on both sides need not be equal, but the “must not exceed” rule just specified must be followed; otherwise a system might send several fragments that, when reconstructed as a frame, will be too large for the peer’s receive buffer.

Once you configure the MRRU on the bundle interface, you enable the router to receive large reconstructed MLP frames. You may want to configure the bundle MTU so that the router can send large MLP frames, although it is not strictly necessary. The maximum recommended value for the bundle MTU is the value of the peer’s MTU. The software will automatically reduce the bundle interface MTU if necessary to avoid violating the peer’s MRRU.

When the bundle interface MTU is tuned to a higher number, then depending upon the fragmentation configuration, the link interface may be given larger frames to send. There are two possible solutions to this problem, as follows:

• Ensure that fragmentation is performed such that fragments are sized less than the link interface MTU (refer to the command pages for the ppp multilink fragment disable and ppp multilink fragment delay commands for more information about packet fragments).
• Configure the MTUs of the link interfaces such that they can send the larger frames.

Note Be careful when configuring MLP MRRU negotiation in a virtual private dialup network (VPDN) environment when an L2TP network server (LNS) is not running Cisco IOS Release 12.3(7)T. The software performs strict matching on the MRRU values in earlier versions of Cisco IOS software.

Examples

The following example shows how to configure MRRU negotiation on a virtual template with synchronous serial interfaces. The example also applies to asynchronous serial interfaces.

mtu 1600

The following example shows how to configure MRRU negotiation on multilink groups:

The following example shows how to configure MRRU negotiation on dialer interfaces:

Note Dialer interfaces are not supported on the Cisco 7600 series router.

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Multiclass Multilink PPP is disabled.

 

Command History

 

Usage Guidelines

This command applies only to interfaces that use PPP encapsulation.

Multiclass Multilink PPP and PPP reliable links do not work together.

When the ppp multilink multiclass command is used, the first channel will negotiate the appropriate Network Control Protocol (NCP) layers (such as the IP Control Protocol and IPX Control Protocol), but subsequent links will negotiate only the link control protocol and Multiclass Multilink PPP. NCP layers do not get negotiated. The dialer load-threshold command enables a rotary group to bring up additional links and to add them to a multilink bundle.

The ppp multilink multiclass command must be configured on each link that will be joining the bundle (that is, on member links, not on the bundle interface itself). Failure to configure this command could result in the peer refusing to allow mismatched links to join the bundle. The first link to join the bundle will determine whether Multiclass Multilink PPP is in effect for the bundle. Each subsequent link must negotiate the same Multiclass Multilink PPP parameters in order to join the bundle. In the case of PPP over ATM (PPPoA) or PPP over Frame Relay (PPPoFR), the command is entered on the virtual template.

When this command is configured (and assuming that the peer also supports and is configured for multiclass interleaving), interleaved packets are assigned sequence numbers so that they are kept in order at the receiving end. Without this command, interleaved packets are sent without multilink headers and are subject to reordering when sent over parallel links.

Examples

The following partial example shows the configuration for a dialer for Multiclass Multilink PPP; it does not show the configuration of the physical interfaces:

The following example shows a configuration that enables multilink PPP interleaving and Multiclass Multilink PPP on a dialer interface that controls a rotary group of BRI interfaces. This configuration permits IP packets to trigger calls.

The following example shows the configuration for defining a virtual interface template that enables Multilink PPP interleaving and a maximum real-time traffic delay of 20 milliseconds. The bundle interface will be a virtual access interface cloned from the virtual template. Multiclass Multilink PPP is then configured on a member link, Serial0.

The following example shows the configuration for Multilink PPP interleaving and a maximum real-time traffic delay of 20 milliseconds on a multilink interface. Multiclass Multilink PPP is then configured on a member link, Serial1, and the member link is restricted to joining only the designated multilink group interface.

The following example shows the configuration for interleaving on the bundle interface while multiclass is configured on the member links (in this case, any virtual access interfaces that are cloned from the virtual template):

 

Related Commands

 

Syntax Description

 

Command Default

Initially omit the multilink header format option when negotiating with the peer, but request the option in a maximum of 16 subsequent requests when the peer includes it in a configure-nak message.

 

Command History

 

Usage Guidelines

This command applies only to interfaces that use PPP encapsulation.

Use this command paired with the ppp multilink multiclass remote command to configure the multiclass multilink PPP multilink header format option when negotiating with a peer. These commands extend the multiclass multilink PPP transmit logic to allow up to 16 transmit and receive classes, and up to 16 classes that can be negotiated with the peer. The ppp multilink multiclass local and ppp multilink multiclass remote commands use PPP link fragmentation and interleaving (LFI) to apply multilink headers to interleaved packets, which allows the packets to be kept in sequence when transmitted over multiple parallel links within a given multilink bundle.

MLP and PPP reliable links do not work together.

The dialer load-threshold command enables a rotary group to bring up additional links and to add them to a multilink bundle.

The ppp multilink multiclass command must be configured on each link that will be joining the bundle or on the multilink interface itself (members of the multilink group inherit any PPP configuration that is done on the multilink group master). Failure to configure this command could result in the peer refusing to allow mismatched links to join the bundle. The first link to join the bundle will determine whether multilink PPP is in effect for the bundle. Each subsequent link must negotiate the same multilink PPP parameters in order to join the bundle.

In the case of PPP over ATM (PPPoA) or PPP over Frame Relay (PPPoFR), the command is entered on the virtual template.

Effective with Cisco IOS Release 12.2(31)SB2, this command can be used only on the Cisco 10000 series platform.

Examples

The following example shows how to configure a multilink bundle for up to four receive classes and at least four transmit classes:

The following example shows how to configure a multilink bundle to not use multiple classes but allows the peer to request the option and transmit up to four classes when needed:

The following example shows how to configure a multilink bundle to not use multiple classes, but allows the peer to request the option and inform the peer that the option is supported, allowing for up to four receive classes:

The following example shows how to completely disable multiclass multilink PPP, rejecting the header and declining to allow the peer to transmit multiple classes:

 

Related Commands

 

Syntax Description

 

Command Default

Multilink PPP is disabled.

 

Command History

 

Usage Guidelines

This command applies only to interfaces that use PPP encapsulation.

Use this command paired with the ppp multilink multiclass local command to configure the multiclass multilink PPP multilink header format option when negotiating with a peer. These commands extend the multiclass multilink PPP transmit logic to allow up to 16 transmit and receive classes, and up to 16 classes that can be negotiated with the peer. The ppp multilink multiclass local and ppp multilink multiclass remote commands use PPP link fragmentation and interleaving (LFI) to apply multilink headers to interleaved packets, which allows the packets to be kept in sequence when transmitted over multiple parallel links within a given multilink bundle.

MLP and PPP reliable links do not work together.

The dialer load-threshold command enables a rotary group to bring up additional links and to add them to a multilink bundle.

The ppp multilink multiclass command must be configured on each link that will be joining the bundle or on the multilink interface itself (members of the multilink group inherit any PPP configuration that is done on the multilink group master). Failure to configure this command could result in the peer refusing to allow mismatched links to join the bundle. The first link to join the bundle will determine whether multilink PPP is in effect for the bundle. Each subsequent link must negotiate the same multilink PPP parameters in order to join the bundle.

In the case of PPP over ATM (PPPoA) or PPP over Frame Relay (PPPoFR), the command is entered on the virtual template.

Effective with Cisco IOS Release 12.2(31)SB2, this command can be used only on the Cisco 10000 series platform.

Examples

The following example shows how to configure a multilink bundle for up to four receive classes and at least four transmit classes:

The following example shows how to configure a multilink bundle to not use multiple classes but allows the peer to request the option and transmit up to four classes when needed:

The following example shows how to configure a multilink bundle to not use multiple classes, but allows the peer to request the option and inform the peer that the option is supported, allowing for up to four receive classes:

The following example shows how to configure a multilink bundle to not use multiple classes, but allows the peer to request the option and inform the peer that the option is supported, allowing for up to four receive classes:

The following example shows how to completely disable multiclass multilink PPP, rejecting the header and declining to allow the peer to transmit multiple classes:

 

Related Commands

 

Syntax Description

 

Command Default

NCP packets are sent on an if-needed basis.

 

Command History

 

Usage Guidelines

This command applies only to interfaces used for multilink bundles (multilink, virtual-templates, or dialer interfaces).

You must specify one keyword, unless you are using the no form of this command.

Some remote peers require the presence of multilink headers for NCP packet processing, while other remote peers require that NCP packets do not have multilink headers. Using the ppp multilink ncp sequenced command, you can control the presence of multilink headers in NCP packets.

Use this command with the if-needed keyword if your remote peers are RFC 1990 compliant. The if-needed specifies that remote peers are able to process NCP regardless of the existence of multilink headers. The always keyword specifies that multilink headers will always appear in all NCP packets. Use the always keyword for any remote peer that requires multilink headers in NCP packet for processing.

The never keyword specifies that multilink headers will never appear in any NCP packet. Use the never keyword for any remote peer that requires NCP packets without multilink headers for processing.

The no form of this command to disables the control of multilink headers appearing in NCP packets.

Examples

 

Related Commands

 

Syntax Description

 

Defaults

The mru value default is 8 bytes.

There is no default for msec value.

 

Command History

 

Usage Guidelines

The slippage constraints are interface-level configuration commands, which may be placed on any interface or configuration source ultimately providing the configuration for a multilink bundle interface like “interface Multilink” and “interface dialer.”

Limits are on a “per-link” basis. For example, issuing ppp multilink slippage mru 4 means that the total amount of data which is buffered by the bundle is 4 times the MRU times the number of links in the bundle.

The reassembly engine is also affected by the lost fragment timeout, which is configured using the ppp timeout multilink lost-fragment command.

The buffer limit derived from the slippage constraints implies a corresponding tolerated differential delay between the links. Since it does not make sense to be declaring a fragment lost due to a timeout when it is within the delay window defined by the slippage, the timeout will be dynamically increased as necessary so that it is never smaller than the delay value derived from the slippage parameters.

Examples

The following example shows the total amount of data buffered by the bundle is four times the MRU times the number of links in the bundle:

The following example shows configuring Multilink PPP over serial interface links on a multilink group interface. In this example, there are two serial interfaces that are members of “interface multilink8”. It is assumed that Serial2 interface has the bandwidth of 64kbps and Serial3 interface has the bandwidth of 128kbps. With these two serial links, interface Multilink8 will have a bandwidth equal to 64kbps plus 128kbps which equals 196 kbps or 24.5 kBps [b=bit, B=byte]. The interface Multilink8 is configured with ppp multilink slippage msec 2000 and therefore buffers at least 2000 milliseconds worth of data (2000 ms * 24.5 kBps = 49000 bytes).

 

Related Commands