|
|
This chapter describes how to configure the PPP and Multilink PPP (MLP) features that can be configured on any interface. It includes the following main sections:
This chapter also describes address pooling for point-to-point links, which is available on all asynchronous serial, synchronous serial, and ISDN interfaces. See the chapter "Configuring Asynchronous SLIP and PPP" in this publication for information about PPP features and requirements that apply only to asynchronous lines and interfaces.
For a complete description of the PPP commands in this chapter, see the Cisco IOS Dial Services Command Reference publication. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
By enabling PPP encapsulation on physical interfaces, PPP can also be in effect on calls placed by the dialer interfaces that use the physical interfaces.
The current implementation of PPP supports option 3, authentication using Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP), option 4, Link Quality Monitoring (LQM), and option 5, Magic Number configuration options. The software always sends option 5 and negotiates for options 3 and 4 if so configured. All other options are rejected.
Magic Number support is available on all serial interfaces. PPP always attempts to negotiate for Magic Numbers, which are used to detect looped-back lines. Depending on how the down-when-looped command is configured, the router might shut down a link if it detects a loop.
To configure PPP on a serial interface (including ISDN), perform the following required task in interface configuration mode: Enabling PPP Encapsulation (required for PPP encapsulation).
You can also complete the tasks in the following sections; these tasks are optional but offer a variety of uses and enhancements for PPP on your systems and networks:
See the section "Monitoring and Maintaining PPP and MLP Interfaces" later in this chapter for tips on maintaining PPP. See the "PPP and MLP Configuration Examples" at the end of this chapter for ideas on how to implement PPP and MLP in your network.
To enable PPP on serial lines to encapsulate IP and other network protocol datagrams, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
encapsulation ppp | Enables PPP encapsulation. |
PPP echo requests are used as keepalives to minimize disruptions to the end users of your network. The no keepalive command can be used to disable echo requests.
Access control using CHAP or PAP is available on all serial interfaces that use PPP encapsulation. The authentication feature reduces the risk of security violations on your router or access server. You can configure either CHAP or PAP for the interface.
 |
Note To use CHAP or PAP, you must be running PPP encapsulation. |
When CHAP is enabled on an interface and a remote device attempts to connect to it, the local router or access server sends a CHAP packet to the remote device. The CHAP packet requests or "challenges" the remote device to respond. The challenge packet consists of an ID, a random number, and the host name of the local router.
The required response has two parts:
When the local router or access server receives the response, it verifies the secret password by performing the same encryption operation as indicated in the response and looking up the required host name or username. The secret passwords must be identical on the remote device and the local router.
Because this response is sent, the password is never sent in clear text, preventing other devices from stealing it and gaining illegal access to the system. Without the proper response, the remote device cannot connect to the local router.
CHAP transactions occur only when a link is established. The local router or access server does not request a password during the rest of the call. (The local device can, however, respond to such requests from other devices during a call.)
When PAP is enabled, the remote router attempting to connect to the local router or access server is required to send an authentication request. If the username and password specified in the authentication request are accepted, the Cisco IOS software sends an authentication acknowledgment.
After you have enabled CHAP or PAP, the local router or access server requires authentication from remote devices. If the remote device does not support the enabled protocol, no traffic will be passed to that device.
To use CHAP or PAP, you must perform the following tasks:
To enable PPP encapsulation, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
encapsulation ppp | Enables PPP encapsulation on an interface. |
To enable CHAP or PAP authentication on an interface configured for PPP encapsulation, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
ppp authentication {chap | chap pap | pap chap | pap} [if-needed] [list-name | default] [callin] | Defines the authentication methods supported and the order in which they are used. |
The ppp authentication chap optional keyword if-needed can be used only with Terminal Access Controller Access Control System (TACACS) or extended TACACS.
With authentication, authorization, and accounting (AAA) configured on the router and list names defined for AAA, the list-name optional keyword can be used with AAA/TACACS+.
 |
Caution If you use a list-name that has not been configured with the aaa authentication ppp command, you disable PPP on the line. |
Add a username entry for each remote system from which the local router or access server requires authentication.
To specify the password to be used in CHAP or PAP caller identification, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
username name [user-maxlinks link-number] password secret | Configures identification. Optionally, you can specify the maximum number of connections a user can establish. To use the user-maxlinks keyword, you must also use the aaa authorization network default local command, and PPP encapsulation and name authentication on all the interfaces the user will be accessing. |
Make sure this password does not include spaces or underscores.
To configure TACACS on a specific interface as an alternative to global host authentication, use one of the following command in interface configuration mode:
| Command | Purpose |
|---|---|
ppp use-tacacs [single-line] or aaa authentication ppp | Configures TACACS. |
Use the ppp use-tacacs command with TACACS and Extended TACACS. Use the aaa authentication ppp command with AAA/TACACS+.
For an example of CHAP, see the section "CHAP with an Encrypted Password" at the end of this chapter. CHAP is specified in RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP).
Link Quality Monitoring (LQM) is available on all serial interfaces running PPP. LQM will monitor the link quality, and if the quality drops below a configured percentage, the router will shut down the link. The percentages are calculated for both the incoming and outgoing directions. The outgoing quality is calculated by comparing the total number of packets and bytes sent with the total number of packets and bytes received by the destination node. The incoming quality is calculated by comparing the total number of packets and bytes received with the total number of packets and bytes sent by the destination peer.
When LQM is enabled, Link Quality Reports (LQRs) are sent, in place of keepalives, every keepalive period. All incoming keepalives are responded to properly. If LQM is not configured, keepalives are sent every keepalive period and all incoming LQRs are responded to with an LQR.
To enable LQM on the interface, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
ppp quality percentage | Enables LQM on the interface. |
The percentage argument specifies the link quality threshold. That percentage must be maintained, or the link is deemed to be of poor quality and taken down.
You can configure point-to-point software compression on serial interfaces that use PPP encapsulation. Compression reduces the size of a PPP frame via lossless data compression. PPP encapsulations support both predictor and Stacker compression algorithms.
If most of your traffic is already compressed files, do not use compression.
Most routers support software compression only, but in the Cisco 7000 series routers hardware compression and distributed compression are also available, depending on the interface processor and compression service adapter hardware installed in the router.
To configure compression, complete the tasks in one of the following sections:
Software compression is available in all router platforms. Software compression is performed by the main processor in the router.
Compression is performed in software and might significantly affect system performance. We recommend that you disable compression if the router CPU load exceeds 65 percent. To display the CPU load, use the show process cpu EXEC command.
To configure compression over PPP, use the following commands in interface configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | encapsulation ppp | Enables encapsulation of a single protocol on the serial line. |
Step 2 | compress [predictor | stac | mppc [ignore-pfc]] | Enables compression. |
When you configure Stacker compression on Cisco 7000 series routers with a 7000 Series Route Switch Processor (RSP7000), on Cisco 7200 series routers, and on Cisco 7500 series routers, there are three methods of compression: hardware compression, distributed compression, and software compression.
To configure hardware or distributed compression over PPP, use the following commands in interface configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | encapsulation ppp | Enables encapsulation of a single protocol on the serial line. |
Step 2 | compress stac [distributed | software] (Cisco 7000 series with RSP7000 and Cisco7500 series) or compress stac [csa slot | software] (Cisco7200 series) | Enables compression. |
Specifying the compress stac command with no options causes the router to use the fastest available compression method:
Using hardware compression in the CSA frees the main processor of the router for other tasks. You can also configure the router to use the VIP2 to perform compression by using the distributed option, or to use the main processor of the router by using the software option. If the VIP2 is not available, compression is performed in the main processor of the router.
When compression is performed in software installed in the main processor of the router, it might substantially affect system performance. We recommend that you disable compression in the main processor of the router if the router CPU load exceeds 40 percent. To display the CPU load, use the show process cpu EXEC command.
Specifying the compress stac command with no options causes the router to use the fastest available compression method.
Microsoft Point-to-Point Compression (MPPC) is a scheme used to compress PPP packets between Cisco and Microsoft client devices. The MPPC algorithm is designed to optimize bandwidth utilization in order to support multiple simultaneous connections. The MPPC algorithm uses a Lempel-Ziv (LZ)-based algorithm with a continuous history buffer called a dictionary.
The Compression Control Protocol (CCP) configuration option for MPPC is 18.
Exactly one MPPC datagram is encapsulated in the PPP information field. The PPP protocol field indicates the hexadecimal type of 00FD for all compressed datagrams. The maximum length of the MPPC datagram sent over PPP is the same as the MTU of the PPP interface; however, this length cannot be greater than 8192 bytes because the history buffer is limited to 8192 bytes. If compressing the data results in data expansion, the original data is sent as an uncompressed MPPC packet.
The history buffers between compressor and decompressor are synchronized by maintaining a 12-bit coherency count. If the decompressor detects that the coherency count is out of sequence, then the error recovery process described next is performed:
1. Reset Request (RR) packet is sent from the decompressor.
2. The compressor then flushes the history buffer and sets the flushed bit in the next packet it sends.
3. Upon receiving the flushed bit set packet, the decompressor flushes the history buffer.
Synchronization is achieved without CCP using the Reset Acknowledge (RA) packet, which can consume additional time.
Compression negotiation between a router and a Windows 95 client occurs through the following process:
1. Windows 95 sends a request for both STAC (option 17) and MPPC (option 18) compression.
2. The router sends a negative acknowledgment (NAK) requesting only MPPC.
3. Windows 95 resends the request for MPPC.
4. The router sends an acknowledgment (ACK) confirming MPPC compression negotiation.
The following restrictions apply to the MPPC feature:
PPP encapsulation must be enabled before you can configure MPPC. For information on how to configure PPP encapsulation see the section "Enabling PPP Encapsulation" earlier in this chapter.
There is only one command required to configure MPPC. The existing compress command supports the mppc keyword, which prepares the interface to initiate CCP and negotiates MPPC with the Microsoft client. To set MPPC once PPP encapsulation is configured on the router, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
compress [mppc [ignore-pfc]] | Enables MPPC on the interface. |
The ignore-pfc keyword instructs the router to ignore the protocol field compression flag negotiated by LCP. For example, the uncompressed standard protocol field value for IP is 0x0021 and 0x21 when compression is enabled. When the ignore-pfc option is enabled, the router will continue to use the uncompressed value (0x0021). Using the ignore-pfc option is helpful for some asynchronous driver devices that use an uncompressed protocol field (0x0021), even though the protocol field compression is negotiated between peers. Figure 49 displays protocol rejections when the debug ppp negotiation command is enabled. These errors can be remedied by setting the ignore-pfc option.
PPP Async2: protocol reject received for protocol = 0x2145 PPP Async2: protocol reject received for protocol = 0x2145 PPP Async2: protocol reject received for protocol = 0x2145
A point-to-point interface must be able to provide a remote node with its IP address through the IP Control Protocol (IPCP) address negotiation process. The IP address can be obtained from a variety of sources. The address can be configured through the command line, entered with an EXEC-level command, provided by TACACS+ or the Dynamic Host Configuration Protocol (DHCP), or from a locally administered pool.
IP address pooling uses a pool of IP addresses from which an incoming interface can provide an IP address to a remote node through IPCP address negotiation process. IP address pooling also enhances configuration flexibility by allowing multiple types of pooling to be active simultaneously.
See the chapter "Configuring Asynchronous SLIP and PPP" in this publication for additional information about address pooling on asynchronous interfaces and about the Serial Line Internet Protocol (SLIP).
A peer IP address can be allocated to an interface through several methods:
The following precedence rules of peer IP address support determine which address is used. Precedence is listed from most likely to least likely:
1. AAA/TACACS+ provided address or addresses from the pool named by AAA/TACACS+
2. An address from a local IP address pool or DHCP (typically not allocated unless no other address exists)
3. Dialer map lookup address (not done unless no other address exists)
4. Address from an EXEC-level PPP or SLIP command, or from a chat script
5. Configured address from the peer default ip address command or address from the protocol translate command
6. Peer provided address from IPCP negotiation (not accepted unless no other address exists)
Address pooling is available on all asynchronous serial, synchronous serial, ISDN BRI, and ISDN PRI interfaces running PPP.
The IP address pooling feature now allows configuration of a global default address pooling mechanism, per-interface configuration of the address pooling mechanism, and per-interface configuration of a specific address or pool name.
You can define the type of IP address pooling mechanism used on router interfaces in one or both of the ways described in the following sections:
The global default mechanism applies to all point-to-point interfaces that support PPP encapsulation and that have not otherwise been configured for IP address pooling. You can define the global default mechanism to be either DHCP or local address pooling.
To configure the global default mechanism for IP address pooling, perform the tasks in one of following sections:
After you have defined a global default mechanism, you can disable it on a specific interface by configuring the interface for some other pooling mechanism. You can define a local pool other than the default pool for the interface or you can configure the interface with a specific IP address to be used for dial-in peers.
DHCP specifies the following components:
To enable DHCP as the global default mechanism, use the following commands in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | ip address-pool dhcp-proxy-client | Specifies DHCP client-proxy as the global default mechanism. |
Step 2 | ip dhcp-server [ip-address | name] | (Optional) Specifies the IP address of a DHCP server for the proxy client to use. |
In Step 2, you can provide as few as one or as many as ten DHCP servers for the proxy-client (the Cisco router or access server) to use. DHCP servers provide temporary IP addresses.
To specify that the global default mechanism to use is local pooling, use the following commands in global configuration mode:
If no other pool is defined, the local pool called default is used.
After you have defined a global default mechanism for assigning IP addresses to dial-in peers, you can then configure the few interfaces for which it is important to have a nondefault configuration. You can do any of the following;
To define a nondefault address pool for use on an interface, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | ip local pool poolname {low-ip-address
[high-ip-address]}
| Creates one or more local IP address pools. |
Step 2 | interface type number | Specifies the interface and enters interface configuration mode. |
Step 3 | peer default ip address pool pool-name | Specifies the pool for the interface to use. |
To define DHCP as the IP address mechanism for an interface, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | interface type number | Specifies the interface and enters interface configuration mode. |
Step 2 | peer default ip address pool dhcp | Specifies DHCP as the IP address mechanism on this interface. |
To define a specific IP address to be assigned to all dial-in peers on an interface, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | interface type number | Specifies the interface and enters interface configuration mode. |
Step 2 | peer default ip address ip-address | Specifies the IP address to assign. |
Although LAPB protocol overhead consumes some bandwidth, you can offset that consumption by the use of PPP compression over the reliable link. PPP compression is separately configurable and is not required for use of a reliable link.
|
Note PPP reliable link is available only on synchronous serial interfaces, including ISDN BRI and ISDN PRI interfaces. PPP reliable link cannot be used over V.120, and does not work with Multilink PPP. |
To configure PPP reliable link on a specified interface, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
ppp reliable-link | Enables PPP reliable link. |
Having reliable links enabled does not guarantee that all connections through the specified interface will in fact use reliable link. It only guarantees that the router will attempt to negotiate reliable link on this interface.
You can troubleshoot PPP reliable link by using the debug lapb command and the debug ppp negotiations, debug ppp errors, and debug ppp packets commands. You can determine whether LAPB has been established on a connection by using the show interface command.
The Cisco IOS software automatically creates neighbor routes by default; that is, it automatically sets up a route to the peer address on a point-to-point interface when the PPP IPCP negotiation is completed.
To disable this default behavior, or to reenable it once it has been disabled, use the following commands in interface configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | no peer neighbor-route | Disables creation of neighbor routes. |
Step 2 | peer neighbor-route | Reenables creation of neighbor routes. |
|
Note If entered on a dialer or asynchronous group interface, this command affects all member interfaces. |
For situations in which a routed network needs connectivity to a remote bridged Ethernet network, a serial or ISDN interface can be configured to function as a PPP half-bridge. The line to the remote bridge functions as a virtual Ethernet interface, and the serial or ISDN interface on the router functions as a node on the same Ethernet subnetwork as the remote network.
The bridge sends bridge packets to the PPP half-bridge, which converts them to routed packets and forwards them to other router processes. Likewise, the PPP half-bridge converts routed packets to Ethernet bridge packets and sends them to the bridge on the same Ethernet subnetwork.
|
Note An interface cannot function as both a half-bridge and a bridge. |
Figure 50 shows a router with a serial interface configured as a PPP half-bridge. The interface functions as a node on the Ethernet subnetwork with the bridge. Note that the serial interface has an IP address on the same Ethernet subnetwork as the bridge.
|
Note The Cisco IOS software supports no more than one PPP half-bridge per Ethernet subnetwork. |
To configure a serial interface to function as a half-bridge, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | interface serial number | Specifies the interface (and enter interface configuration mode). |
Step 2 | ppp bridge appletalk ppp bridge ip ppp bridge ipx [novell-ether | arpa | sap | snap] | Enables PPP half-bridging for one or more routed protocols: AppleTalk, IP, or Internet Protocol Exchange (IPX). |
Step 3 | ip address n.n.n.n appletalk address network.node | Provides a protocol address on the same subnetwork as the remote network. |
|
Note You must enter the ppp bridge command either when the interface is shut down or before you provide a protocol address for the interface. |
For more information about AppleTalk addressing, see the "Configuring AppleTalk" chapter; for more information about IPX addresses and encapsulations, see the "Configuring Novell IPX" chapter. Both chapters are in the Cisco IOS AppleTalk and Novell IPX Configuration Guide.
MLP allows packets to be fragmented and the fragments to be sent at the same time over multiple point-to-point links to the same remote address. The multiple links come up in response to a defined dialer load threshold. The load can be calculated on inbound traffic, outbound traffic, or on either, as needed for the traffic between the specific sites. MLP provides bandwidth on demand and reduces transmission latency across WAN links.
MLP is designed to work over the following types of single or multiple interfaces that have been configured to support both dial-on-demand rotary groups and PPP encapsulation:
To configure an asynchronous interface to support DDR and PPP encapsulation, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | interface async number | Specifies an asynchronous interface. |
Step 2 | no ip address | Specifies no IP address for the interface. |
Step 3 | encapsulation ppp | Enables PPP encapsulation. |
Step 4 | dialer in-band | Enables DDR on the interface. |
Step 5 | dialer rotary-group number | Includes the interface in a specific dialer rotary group. |
Repeat these steps for additional asynchronous interfaces, as needed.
At some point, adding more asynchronous interfaces does not improve performance, With the default maximum transmission unit (MTU) size, MLP should support three asynchronous interfaces using V.34 modems. However, packets might be dropped occasionally if the maximum transmission unit (MTU) size is small or large bursts of short frames occur.
To configure a dialer interface to support PPP encapsulation and Multilink PPP, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | interface dialer number | Defines a dialer rotary group. |
Step 2 | no ip address | Specifies no IP address for the interface. |
Step 3 | encapsulation ppp | Enables PPP encapsulation. |
Step 4 | dialer in-band | Enables DDR on the interface. |
Step 5 | dialer load-threshold load [inbound | outbound | either] | Configures bandwidth on demand by specifying the maximum load before the dialer places another call to a destination. |
Step 6 | ppp multilink | Enables Multilink PPP. |
To enable MLP on a single ISDN BRI interface, you are not required to define a dialer rotary group separately because ISDN interfaces are dialer rotary groups by default.
To enable PPP on an ISDN BRI interface, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | interface bri number | Specifies an interface. |
Step 2 | ip address ip-address mask [secondary] | Provides an appropriate protocol address for the interface. |
Step 3 | encapsulation ppp | Enables PPP encapsulation. |
Step 4 | dialer idle-timeout seconds | (Optional) Specifies a dialer idle timeout. |
Step 5 | dialer load-threshold load | Specifies the dialer load threshold for bringing up additional WAN links. |
Step 6 | dialer map protocol next-hop-address [name hostname] [spc] [speed 56 | 64] [broadcast] [dial-string[:isdn-subaddress]] | Configures the ISDN interface to call the remote site. |
Step 7 | dialer-group group-number | Controls access to this interface by adding it to a dialer access group. |
Step 8 | ppp authentication pap | (Optional) Enables PPP authentication. |
Step 9 | ppp multilink | Enables MLP on the dialer rotary group. |
The load threshold number is required. For an example of configuring MLP on a single ISDN BRI interface, see the section "MLP on One ISDN BRI Interface" at the end of this chapter.
When MLP is configured and you want a multilink bundle to be connected indefinitely, use the dialer idle-timeout command to set a very high idle timer. (The dialer-load threshold 1 command no longer keeps a multilink bundle of n links connected indefinitely, and the dialer-load threshold 2 command no longer keeps a multilink bundle of two links connected indefinitely.)
To enable MLP on multiple ISDN BRI interfaces, set up a dialer rotary interface and configure it for Multilink PPP, then configure the BRI interfaces separately and add them to the same rotary group.
| Command | Purpose | |
|---|---|---|
Step 1 | interface dialer number | Specifies the dialer rotary interface. |
Step 2 | ip address address mask | Specifies the protocol address for the dialer rotary interface. |
Step 3 | encapsulation ppp | Enables PPP encapsulation. |
Step 4 | dialer in-band | Specifies in-band dialing. |
Step 5 | dialer idle-timeout seconds | (Optional) Specifies the dialer idle timeout period, using the same timeout period as the individual BRI interfaces. |
Step 6 | dialer map protocol next-hop-address [name hostname] [spc] [speed 56 | 64] [broadcast] [dial-string[:isdn-subaddress]] | Maps the next hop protocol address and name to the dial string needed to reach it. |
Step 7 | dialer load-threshold load | Specifies the dialer load threshold, using the same threshold as the individual BRI interfaces. |
Step 8 | dialer-group number | Controls access to this interface by adding it to a dialer access group. |
Step 9 | ppp authentication chap | (Optional) Enables PPP CHAP authentication. |
Step 10 | ppp multilink | Enables Multilink PPP. |
If you do not use PPP authentication procedures (Step 10), your telephone service must pass caller ID information.
| Command | Purpose | |
|---|---|---|
Step 1 | interface bri number | Specifies one of the BRI interfaces. |
Step 2 | no ip address | Specifies that it does not have an individual protocol address. |
Step 3 | encapsulation ppp | Enables PPP encapsulation. |
Step 4 | dialer idle-timeout seconds | Sets the dialer idle timeout period, using the same timeout for each of the BRI interfaces you configure. |
Step 5 | dialer rotary-group number | Adds the interface to the rotary group. |
Step 6 | dialer load-threshold load | Specifies the dialer load threshold for bringing up additional WAN links. |
Repeat Steps 1 through 6 for each BRI you want to belong to the same dialer rotary group.
When MLP is configured and you want a multilink bundle to be connected indefinitely, use the dialer idle-timeout command to set a very high idle timer. (The dialer load-threshold 1 command no longer keeps a multilink bundle of n links connected indefinitely and the dialer load-threshold 2 command no longer keeps a multilink bundle of two links connected indefinitely.)
|
Note Previously, when MLP was used in a dialer profile, a virtual access interface was always created as the bundle. It was bound to both the B channel and the dialer profile interfaces after creation and cloning. The dialer profile interface could act as the bundle without help from a virtual access interface. But with the Dynamic Multiple Encapsulations feature available in in Cisco IOS Release 12.1, it is no longer the virtual access interface that is added into the connected group of the dialer profile, but the dialer profile itself. The dialer profile becomes a connected member of its own connected group. See the "Dynamic Multiple Encapsulations over ISDN" example in the chapter "Configuring Peer-to-Peer DDR with Dialer Profiles" in this publication, for more information about dynamic multiple encapsulations and its relation to Multilink PPP. |
For an example of configuring MLP on multiple ISDN BRI interfaces, see the "MLP on Multiple ISDN IBRI Interfaces" example at the end of this chapter.
Weighted fair queueing is now supported on all interfaces that support Multilink PPP, including MLP virtual access interfaces and virtual interface templates. Weighted fair-queueing is enabled by default.
Fair queueing on MLP overcomes a prior restriction. Previously, fair queueing was not allowed on virtual access interfaces and virtual interface templates. Interleaving provides the delay bounds for delay-sensitive voice packets on a slow link that is used for other best-effort traffic.
Interleaving applies only to interfaces that can configure a multilink bundle interface. These restrictions include virtual templates, dialer interfaces, and ISDN BRI or PRI interfaces.
Multilink and fair queueing are not supported when a multilink bundle is off-loaded to a different system using Multichassis Multilink PPP (MMP). Thus, interleaving is not supported in MMP networking designs.
MLP support for interleaving can be configured on virtual-templates, dialer interfaces, and ISDN BRI or PRI interfaces. To configure interleaving, complete the following tasks:
|
Note Fair queueing, which is enabled by default, must remain enabled on the interface. |
To configure MLP and interleaving on a configured and operational interface or virtual interface template, use the following commands in interface configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | ppp multilink | Enables Multilink PPP. |
Step 2 | ppp multilink interleave | Enables real-time packet interleaving. |
Step 3 | ppp multilink fragment-delay milliseconds | Optionally, configures a maximum fragment delay. |
Step 4 | ip rtp reserve lowest-udp-port range-of-ports [maximum-bandwidth] | Reserves a special queue for real-time packet flows to specified destination UDP ports, allowing real-time traffic to have higher priority than other flows. |
Step 5 | multilink virtual-template 1 | For virtual templates only, applies the virtual template to the multilink bundle.1 |
| 1This step is not used for ISDN or dialer interfaces. |
Interleaving statistics can be displayed by using the show interfaces command, specifying the particular interface on which interleaving is enabled. Interleaving data is displayed only if there are interleaves. For example, the following line shows interleaves:
Output queue: 315/64/164974/31191 (size/threshold/drops/interleaves)
Non-distributed MLP can only perform limited links, with CPU usage quickly reaching 90% with only a few T1/E1 lines running MLP. With distributed MLP, you can increase the router's total capacity.
The MLP Inverse Multiplexer feature was designed for Internet service providers (ISPs) that want to have the bandwidth of multiple T1 lines with performance comparable to that of an inverse multiplexer without the need of buying standalone inverse-multiplexing equipment. A Cisco router supporting VIPs can bundle multiple T1 lines in a CT3 or CE3 interface. Bundling is more economical than purchasing an inverse multiplexer, and eliminates the need to configure another piece of equipment.
This feature supports the CT3 CE3 data rates without taxing the RSP and CPU by moving the data path to the VIP. This feature also allows remote sites to purchase multiple T1 lines instead of a T3 line, which is especially useful when the remote site does not need the bandwidth of an entire T3 line.
This feature allows multilink fragmentation to be disabled, so multilink packets are sent using Cisco Express Forwarding (CEF) on all platforms, if fragmentation is disabled. CEF is now supported with fragmentation enabled or disabled.
Figure 51 shows a typical network using a VIP MLP link. The Cisco 7500 series router is connected to the network with a CT3 line that has been configured with VIP MLP to carry two bundles of four T1 lines each. One of these bundles goes out to a Cisco 2500 series router and the other goes out to a Cisco 3800 series router.
To configure a multilink bundle, perform the tasks in the following sections:
Before beginning the MLP Inverse Multiplexer configuration tasks, make note of the following prerequisites and restrictions.
Enabling fragmentation reduces the delay latency among bundle links, but adds some load to the CPU. Disabling fragmentation may result in better throughput.
If your data traffic is consistently of a similar size, we recommend disabling fragmentation. In this case, the benefits of fragmentation may be outweighed by the added load on the CPU.
To enable distributed MLP, first enable distributed CEF switching (dCEF) by using the following command in global configuration mode:
| Command | Purpose |
|---|---|
ip cef distributed | Enables distributed CEF switching. |
To create a multilink bundle, use the following commands beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | interface multilink group-number | Enters multilink interface configuration mode. |
Step 2 | ip address address mask | Assigns an IP address to the multilink interface. |
Step 3 | encapsulation ppp | Enables PPP encapsulation. |
Step 4 | ppp multilink | Enables Multilink PPP. |
To assign an interface to a multilink bundle, use the following commands in interface configuration mode:
| Command | Purpose | |
|---|---|---|
Step 1 | no ip address | Removes any specified IP address. |
Step 2 | keepalive | Sets the frequency of keepalive packets. |
Step 3 | encapsulation ppp | Enables PPP encapsulation. |
Step 4 | multilink-group group-number | Assigns the interface to a multilink bundle. |
Step 5 | ppp multilink | Enables Multilink PPP. |
Step 6 | ppp authentication chap | (Optional) Enables CHAP authentication. |
Step 7 | pulse-time seconds | (Optional) Configures DTR signal pulsing. |
By default, PPP multilink fragmentation is enabled. To disable PPP multilink fragmentation, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
no ppp multilink fragmentation | (Optional) Disables PPP multilink fragmentation. |
To display information about the newly created multilink bundle, use the show ppp multilink command in EXEC mode:
Router# show ppp multilink Multilink1, bundle name is group1 Bundle is Distributed 0 lost fragments, 0 reordered, 0 unassigned, sequence 0x0/0x0 rcvd/sent 0 discarded, 0 lost received, 1/255 load Member links:4 active, 0 inactive (max not set, min not set) Serial1/0/0:1 Serial1/0/0/:2 Serial1/0/0/:3 Serial1/0/0/:4
To monitor and maintain virtual interfaces, use the following command in EXEC mode:
| Command | Purpose |
|---|---|
show ppp multilink | Displays MLP and MMP bundle information. |
Examples in the following sections section show various PPP configurations:
The following examples show how to enable CHAP on serial interface 0 of three devices:
Configuration of Router yyy
hostname yyy interface serial 0 encapsulation ppp ppp authentication chap username xxx password secretxy username zzz password secretzy
Configuration of Router xxx
hostname xxx interface serial 0 encapsulation ppp ppp authentication chap
username yyy password secretxy username zzz password secretxz
Configuration of Router zzz
hostname zzz interface serial 0 encapsulation ppp ppp authentication chap username xxx password secretxz username yyy password secretzy
When you look at the configuration file, the passwords will be encrypted and the display will look similar to the following:
hostname xxx interface serial 0 encapsulation ppp ppp authentication chap username yyy password 7 121F0A18 username zzz password 7 1329A055
The following example shows how to configure the username sTephen and establish a maximum of five connections. sTephen can connect through serial interface 1/0, which has a dialer map configured for it, or through PRI interface 0/0:23, which has dialer profile interface 0 dedicated to it.
The aaa authorization network default local command must be configured. PPP encapsulation and authentication must be enabled on all the interfaces sTephen can connect to.
aaa new-model aaa authorization network default local enable secret saintstephen enable password witharose ! username sTephen user-maxlinks 5 password gardenhegoes ! interface Serial0/0:23 no ip address encapsulation ppp dialer pool-member 1 ppp authentication chap ppp multilink ! interface Serial1/0 ip address 2.2.2.4 255.255.255.0 encapsulation ppp dialer in-band dialer map ip 2.2.2.13 name sTephen 12345 dialer-group 1 ppp authentication chap ! interface Dialer0 ip address 1.1.1.4 255.255.255.0 encapsulation ppp dialer remote-name sTephen dialer string 23456 dialer pool 1 dialer-group 1 ppp authentication chap ppp multilink ! dialer-list 1 protocol ip permit
The following example configures asynchronous interface 1 to implement MPPC and ignore the protocol field compression flag negotiated by LCP:
interface async1 ip unnumbered ethernet0 encapsulation ppp async default routing async dynamic routing async mode interactive peer default ip address 172.21.71.74 compress mppc ignore-pfc
The following example creates a virtual access interface (virtual-template interface 1) and serial interface 0, which is configured for X.25 encapsulation. MPPC values are configured on the virtual-template interface and will ignore the negotiated protocol field compression flag.
interface ethernet0 ip address 172.20.30.102 255.255.255.0 ! interface virtual-template1 ip unnumbered ethernet0 peer default ip address pool vtemp1 compress mppc ignore-pfc ! interface serial0 no ipaddress no ip mroute-cache encapsulation x25 x25 win 7 x25 winout 7 x25 ips 512 x25 ops 512 clock rate 50000 ! ip local pool vtemp1 172.20.30.103 172.20.30.104 ip route 0.0.0.0 0.0.0.0 172.20.30.1 ! translate x25 31320000000000 virtual-template 1
The following example enables PPP reliable link and STAC compression on BRI 0:
interface BRI0 description Enables stac compression on BRI 0 ip address 172.1.1.1 255.255.255.0 encapsulation ppp dialer map ip 172.1.1.2 name baseball 14195386368 compress stac ppp authentication chap dialer-group 1 ppp reliable-link
The following example shows output of the show interfaces command when PPP reliable link is enabled. The LAPB output lines indicate that PPP reliable link is provided over LAPB.
Router# show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Description: connects to enkidu s 0
Internet address is 172.21.10.10/8
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation PPP, loopback not set
LCP Open
Open: IPCP, CDP
LAPB DTE, state CONNECT, modulo 8, k 7, N1 12048, N2 20
T1 3000, T2 0, interface outage (partial T3) 0, T4 0, PPP over LAPB
VS 1, VR 1, tx NR 1, Remote VR 1, Retransmissions 0
Queues: U/S frames 0, I frames 0, unack. 0, reTx 0
IFRAMEs 1017/1017 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0
Last input 00:00:18, output 00:00:08, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/64/0 (size/threshold/drops)
Conversations 0/1 (active/max active)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 3000 bits/sec, 4 packets/sec
5 minute output rate 3000 bits/sec, 7 packets/sec
1365 packets input, 107665 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
2064 packets output, 109207 bytes, 0 underruns
0 output errors, 0 collisions, 4 interface resets
0 output buffer failures, 0 output buffers swapped out
4 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
The following examples configure Multilink PPP. The first example configures it on one ISDN BRI interface, and the second configures multiple BRI interfaces to belong to the same dialer rotary group, which is then configured for Multilink PPP.
The following example enables MLP on the BRI interface 0. Because an ISDN interface is a rotary group by default, when one BRI is configured, no dialer rotary group configuration is required.
interface bri 0 description connected to ntt 81012345678902 ip address 171.1.1.7 255.255.255.0 encapsulation ppp dialer idle-timeout 30 dialer load-threshold 40 either dialer map ip 171.1.1.8 name atlanta 81012345678901 dialer-group 1 ppp authentication pap ppp multilink
The following example configures multiple ISDN BRI interfaces to belong to the same dialer rotary group for Multilink PPP. The dialer rotary-group command is used to assign each of the ISDN BRI interfaces to that dialer rotary group.
interface BRI0 no ip address encapsulation ppp dialer idle-timeout 500 dialer rotary-group 0 dialer load-threshold 30 either ! interface BRI1 no ip address encapsulation ppp dialer idle-timeout 500 dialer rotary-group 0 dialer load-threshold 30 either ! interface BRI2 no ip address encapsulation ppp dialer idle-timeout 500 dialer rotary-group 0 dialer load-threshold 30 either ! interface Dialer0 ip address 99.0.0.2 255.0.0.0 encapsulation ppp dialer in-band dialer idle-timeout 500 dialer map ip 99.0.0.1 name atlanta broadcast 81012345678901 dialer load-threshold 30 either dialer-group 1 ppp authentication chap ppp multilink
interface virtual-template 1 ip unnumbered ethernet 0 ppp multilink ppp multilink interleave ppp multilink fragment-delay 20 ip rtp interleave 32768 20 1000 multilink virtual-template 1
interface BRI 0 description connected into a rotary group encapsulation ppp dialer rotary-group 1 ! interface BRI 1 no ip address encapsulation ppp dialer rotary-group 1 ! interface BRI 2 encapsulation ppp dialer rotary-group 1 ! interface BRI 3 no ip address encapsulation ppp dialer rotary-group 1 ! interface BRI 4 encapsulation ppp dialer rotary-group 1 ! interface Dialer 0 description Dialer group controlling the BRIs ip address 8.1.1.1 255.255.255.0 encapsulation ppp dialer map ip 8.1.1.2 name angus 14802616900 dialer-group 1 ppp authentication chap ! Enables Multilink PPP interleaving on the dialer interface and reserves ! a special queue. ppp multilink ppp multilink interleave ip rtp reserve 32768 20 1000 ! Keeps fragments of large packets small enough to ensure delay of 20 ms or less. ppp multilink fragment-delay 20 dialer-list 1 protocol ip permit
In the following example, the T3 controller is configured and four channelized interfaces are created:
controller T3 1/0/0 framing m23 cablelength 10 t1 1 timeslots 1-24 t1 2 timeslots 1-24 t1 3 timeslots 1-24 t1 4 timeslots 1-24
In the following example, four multilink interfaces are created with distributed CEF switching and MLP enabled. Each of the newly created interfaces are added to a multilink bundle:
interface multilink1 ip address 10.0.0.0 10.255.255.255 ppp chap hosstname group 1 pp multilink multilink-group 1
interface serial 1/0/0/:1 no ip address encapsulation ppp ip route-cache distributed no keepalive ppp multilink multilink-group 1 interface serial 1/0/0/:2 no ip address encapsulation ppp ip route-cache distributed no keepalive ppp chap hostname group 1 ppp multilink multilink-group 1 interface serial 1/0/0/:3 no ip address encapsulation ppp ip route-cache distributed no keepalive ppp chap hostname group 1 ppp multilink multilink-group 1 interface serial 1/0/0/:4 no ip address encapsulation ppp ip route-cache distributed no keepalive ppp chap hostname group 1 ppp multilink multilink-group 1
Posted: Wed Aug 30 22:30:11 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.