Cisco IOS Dial Technologies Command Reference

 

Syntax Description

 

Command Default

The default is pool.

 

Command History

 

Usage Guidelines

This command applies to point-to-point interfaces that support the PPP or Serial Line Internet Protocol (SLIP) encapsulation. This command sets the address used on the remote (PC) side.

Note This command replaces the async default ip address command.

This command allows an administrator to configure all possible address pooling mechanisms on an interface-by-interface basis.

The peer default ip address command can override the global default mechanism defined by the ip address-pool command on an interface-by-interface basis, as follows:

• For all interfaces not configured with a peer default IP address mechanism (equivalent to selecting the peer default ip address pool command), the router uses the global default mechanism that is defined by the ip address-pool command.
• If you select the peer default ip address pool pool-name form of this command, then the router uses the locally configured pool on this interface and does not follow the global default mechanism.
• If you select the peer default ip address ip-address form of this command, the specified IP address is assigned to any peer connecting to this interface and any global default mechanism is overridden for this interface.
• If you select the peer default ip address dhcp form of this command, the DHCP proxy-client mechanism is used by default on this interface and any global default mechanism is overridden for this interface.
• If you select the peer default ip address dhcp-pool form of this command, the DHCP on-demand address pooling mechanism is used by default on this interface and any global default mechanism is overridden for this interface.

Examples

The following command specifies that this interface will use a local IP address pool named pool3:

The following command specifies that this interface will use the IP address 172.19.34.21:

The following command reenables the global default mechanism to be used on this interface:

The following example specifies address 192.168.7.51 for asynchronous interface 6:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

When a network device dials in to a Cisco network access server (NAS) that is configured to assign an IP address to the network device, the NAS attempts to assign the device the address it was assigned previously. If that address is unavailable or if no address in the pool was assigned previously, the NAS then assigns the next available address in its pool.

 

Command History

 

Usage Guidelines

The peer ip address forced command is used for point-to-point interfaces that support a link framing protocol such as PPP where the NAS will assign a peer IP address from an address pool as a result of the following conditions:

• The NAS is configured with a pool of network addresses at the interface supporting the peers (configured by use of the ip local-pool command).
• The NAS is configured to assign IP addresses to peers from a pool. A pool of IP addresses can be configured and applied at the interface by use of the ip address-pool command and the peer default ip address pool command or as a RADIUS server directive.
• The peer is configured to request an IP address from the NAS server (for example, as configured by use of the ip address negotiated command).

To force the NAS to allocate the next available IP address from the pool for the interface, use the peer ip address forced command. Any attempts to allocate a previously held IP address or a specifically requested IP address are suppressed; instead, the NAS allocates the next available IP address from the specified pool. This feature can be used to prevent users from obtaining the same IP address for each dial-in session.

Examples

The following example specifies that the interface will allocate the next available address from the pool whenever an address is requested from a pool:

The following example specifies that the interface will allow a peer to negotiate an IP address or will attempt to assign a previously assigned address:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Command is disabled.

 

Command History

 

Usage Guidelines

This command provides the ability to control or restrict the use of pool names supplied by AAA to only those pool names that are configured on the router. This ability is useful in cases where the AAA server and the router and its local configuration are controlled by different administrators, as would be the case for a wholesale dial supplier where the AAA servers are owned by individual customers.

When the peer match aaa-pools command is configured on an interface, the IP address pool names used are those specified in the local configuration as part of the peer default ip address command and the pool names supplied by the AAA server.

When the no peer match aaa-pools command is used, pool name selection is controlled by the AAA server, as follows: When the AAA server supplies a pool name, that is the only pool used. If AAA does not supply a pool name, then the normal IP default pool name processing is used as described in the peer default ip address command page.

Examples

The following example shows how to configure pool name restrictions in a Resource Pool Management (RPM) customer profile template:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

No backup IP address pool names are configured

 

Command History

 

Usage Guidelines

The peer pool backup command is useful in large-scale dial-out environments with a large number of independently controlled AAA servers. Difficulties arise when the network access server (NAS) must provide IP address pool name resolution when a new pool is introduced by one of the AAA servers before that pool is set up on the NAS, or when an existing local pool becomes exhausted but the AAA server actually has other pools that would be acceptable as IP address sources.

The peer pool backup command uses the local pool names configured with the peer default ip address pool interface configuration command to supplement the pool names supplied by AAA. The problems of pool name resolution and exhaustion can be solved by configuring backup pool names on a per-interface basis using both the peer default ip address pool and peer pool backup interface configuration commands.

You may also configure local restrictions on the use of AAA-supplied pool names to a NAS-specified set by adding the peer match aaa-pools interface configuration command to the configuration. The peer match aaa-pools command specifies that any AAA-supplied pool name must match one of the pool names supplied with the peer default ip address pool command. See the “Examples” section for an example.

Examples

In the following example, the search order for backup pool names set by the peer default ip address pool command is pool1 then pool2. These pools will be used when the NAS cannot resolve a pool name or when an existing pool of IP addresses is exhausted.

In the following example, assume that there is a AAA-supplied IP address pool named poolA. By adding the peer match aaa-pools command to the configuration, the AAA-supplied pool named poolA will not be used because it does not appear in the peer default ip address pool command; only the pools named pool1 and pool2 will be searched.

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Dynamic pools are loaded

 

Command History

 

Usage Guidelines

The peer pool static command controls attempts by the pool software to load dynamic pools in response to a pool request from a specific interface. These dynamic pools are loaded at system startup and refreshed whenever a pool name not configured on the network access server (NAS) is specified for IP address allocation. Because the behavior of the NAS in response to a missing pool name can be changed using the peer pool backup interface configuration command, you may need to use the peer pool static command to control attempts to load all dynamic pools when the AAA-supplied pool name is not an existing local pool name. The peer pool static command provides a two-minute interval between attempts to download dynamic IP pools when a missing pool name is encountered.

Examples

The following partial example shows how to disable loading dynamic pools using the peer pool static command:

In this configuration, any attempt to load a dynamic pool name is suppressed; only the backup pool names defined by the peer default ip address pool command will be used.

 

Related Commands

 

Syntax Description

 

Command Default

Both incoming and outgoing calls are permitted.

 

Command History

 

Usage Guidelines

After a dial peer is associated with an incoming call, the permission is checked to determine whether incoming calls are permitted on the dial peer. If permission is not set to orig or both, the incoming call is blocked.

After a dial peer is matched for an outgoing call, the permission is checked to determine whether outgoing calls are permitted on the dial peer. If permission is not set to term or both, the outgoing call using this dial peer fails.

Note The call may “rotary” to the next dial peer if the current dial peer does not have the huntstop command set.

Examples

The following example configures a dial peer and sets its permission to both originate and terminate calls:

 

Related Commands

 

Syntax Description

 

Command Default

Command is disabled. All modems are configured to be part of the system default modem pool.

 

Command History

 

Usage Guidelines

For a complete description of modem pools and how they are configured on Cisco access servers, see the command page for the modem-pool command.

Replace the modem1 - modemN arguments with the modem TTY line numbers that correspond with the range of modems you want in the modem pool. TTY line numbers start from 1, and they map to modem numbers that start from 0. For example, if you want to include modems 1/0 through 1/23 in a pool range, use the TTY line numbers 1 to 24. To verify the modem to TTY line numbering scheme, use the show modem slot / port command.

Note MICA technologies modems and Microcom modems support incoming analog calls over ISDN PRI. However, only MICA modems support modem pooling for CT1 and CE1 configurations with channel–associated signaling.

Examples

The following example assigns modem TTY line numbers 30 to 50 to a modem pool. The Dialed Number Information Service (DNIS) number is set to 2000. The customers dialing 2000 are guaranteed access to 21 modems. The 22nd client to dial in is refused connectivity because the maximum number of allowable connections is exceeded.

The following configuration rejects the pool-range 30 command, because modem TTY line 30 is already a member of the modem pool v90service, which was configured in the previous example. Each modem in the access server is automatically assigned to a unique TTY line. TTY line numbers are assigned according to your shelf, slot, or port hardware configuration.

 

Related Commands

 

Syntax Description

 

Command Default

Command is disabled.

 

Command History

 

Usage Guidelines

The port command helps you to enter the port configuration mode. The port configuration mode allows you to shut down or put individual ports or ranges of ports in busyout mode.

Examples

The following example shows how to enter port configuration mode on ports 1 to 18 to perform further tasks on the ports:

 

Related Commands

 

Syntax Description

 

Command Default

Modem diagnostics tests are disabled.

 

Command History

Examples

The following example shows how to set the modem autotest to run once per week at 3:00 a.m. Additionally, the autotest activates if the system detects a modem error count higher than 40 errors.

Determine the current time set on the access server with the show clock EXEC command. In this example, the time and date set is 3:00 p.m, Monday, January 6, 2003:

Enter global configuration mode and set the time you want the modem autotest to activate. In this example, the access server is configured to run the modem autotest at 3:00 a.m. and every 168 hours (week) thereafter:

Configure the autotest to activate if the system detects a high modem error count. In this example, the autotest activates if the system detects a modem error count higher than 40 errors. For the list of modem errors that are monitored by the modem autotest command, see the show modem call-stats command.

 

Related Commands

 

Syntax Description

 

Command History

 

Usage Guidelines

When you connect from a remote node computer to an EXEC session on the access server and want to connect from the access server to a device on the network, issue the ppp command.

If you specify an address for the TACACS server (either /default or @ tacacs-server), the address must be the first parameter in the command after you type ppp. If you do not specify an address or enter the default keyword, you are prompted for an IP address or host name. You can enter the default keyword at this point.

To terminate a session, disconnect from the device on the network using the command specific to that device. Then, exit from the EXEC by using the exit command.

Examples

The following example shows a line that is in asynchronous mode using PPP encapsulation. The name of the computer (ntpc in this example) must be in the Domain Name System (DNS) so that it can be resolved to a real IP address). The computer must be running a terminal emulator program.

 

Syntax Description

 

Command Default

0xA0000.

 

Command History

 

Usage Guidelines

The ACCM is a four octet hexadecimal number that is sent to a peer in a PPP outbound Config-Request packet, informing the peer of which characters need to be escaped during transmission of Asynchronous HDLC (AHDLC) frames containing control characters. The escaped characters set by the ppp accm command are useful for allowing data to pass uninterpreted through a network that would normally interpret the control sequences as a command.

For example, the ^Q and ^S characters are software flow control commands used by asynchronous modems to start and stop data transmissions. To allow these characters to be sent as part of a data stream and not be interpreted as control codes by intervening devices, the characters must be escaped, and the ppp accm command specifies which characters to use.

The TIA/EIA/IS-835-B requires that the PDSN propose an ACCM of 0x00000000. To be compliant with TIA/EIA/IS-835-B, ppp accm 00000000 must be configured on the virtual template interface on Cisco PDSN.

The ppp accm command is meaningful only on asynchronous interfaces. If entered on other interface types, it will be ignored.

Examples

In the following example, all characters can be transmitted intact to the receiver so that it is not necessary for the transmitter to escape anything:

 

Related Commands

 

Syntax Description

 

Command Default

ACFC handling is automatically selected based on the type of link, as follows: For asynchronous links, the router responds as if the request keyword were selected and the router includes the ACFC option in outbound configuration requests. For synchronous links, the router responds as if the forbid keyword were selected and the ACFC option is not sent out in configuration outbound requests and requests from a peer to add the ACFC option are not accepted.

 

Command History

 

Usage Guidelines

This command configures ACFC requests in outbound configuration requests. The ppp acfc local command allows ACFC handling to be disabled, thus allowing the HDLC framing and the protocol field to remain uncompressed.

Prior to the introduction of the ppp acfc local command, negotiation and use of ACFC was entirely dependent upon the link type (synchronous or asynchronous) and was not under the independent control of a system administrator, and this is still the default condition. The ppp acfc local command allows the system administrator to control over when PPP negotiates the HDLC ACFC options during initial LCP negotiations, and how the results of the PPP negotiation are applied.

Note Using ACFC can result in minor gains in effective bandwidth because they reduce the amount of framing overhead for each packet. However, using ACFC changes the alignment of the network data in the frame, which in turn can impair the switching efficiency of the packets both at the local and remote ends of the connection. For these reasons, it is generally recommended that ACFC not be enabled without carefully considering the potential results.

Examples

The following example shows how to configure a router to exclude ACFC options from its configuration requests:

 

Related Commands

 

Syntax Description

 

Command Default

ACFC handling is automatically selected based on the type of link, as follows: For asynchronous links, the router responds as if the apply keyword were selected and the router accepts ACFC options received from a remote peer and may perform ACFC on frames sent to the peer. For synchronous links, the router responds as if the ignore keyword were selected and ACFC options received from a remote peer are accepted, but ACFC is not performed on frames sent to the remote peer.

 

Command History

 

Usage Guidelines

If ACFC is negotiated during PPP negotiation, Cisco routers may omit the HDLC header on links using HDLC encapsulation. This command allows ACFC handling to be disabled during PPP negotiation, thus allowing the HDLC framing and the protocol field to remain uncompressed.

Prior to the introduction of the ppp acfc remote command, negotiation and use of ACFC was entirely dependent upon the link type (synchronous or asynchronous) and was not under the independent control of a system administrator, and this is still the default condition. The ppp acfc remote command allows the system administrator control over when PPP negotiates the HDLC ACFC options during initial LCP negotiations, and how the results of the PPP negotiation are applied.

Note Using ACFC can result in minor gains in effective bandwidth because they reduce the amount of framing overhead for each packet. However, using ACFC changes the alignment of the network data in the frame, which in turn can impair the switching efficiency of the packets both at the local and remote ends of the connection. For these reasons, it is generally recommended that ACFC not be enabled without carefully considering the potential results.

Examples

The following example configures ACFC options received from a remote peer to be rejected:

 

Related Commands

 

Syntax Description

 

Command Default

Peers can initiate the addition of links to a multilink bundle; the timer is disabled.

 

Command History

 

Usage Guidelines

This command can be included in a virtual interface template for configuring virtual interfaces or can be used to configure a dialer interface.

Examples

The following example configures a dialer interface to accept calls. Accepting calls is the default, but the command is included for the sake of the example.

 

Related Commands

 

Syntax Description

 

Command Default

Callback is disabled, and no callback parameters are set. The timer is disabled.

 

Command History

Examples

The following example configures a BRI interface for active mode BAP:

 

Related Commands

 

Syntax Description

 

Command Default

accept, request : Peers can initiate link removal and this router also can initiate link removal.
no ppp bap drop after-retries : The link is not dropped when there is no response to drop requests.
timer : Disabled, no default value is defined.

 

Command History

 

Usage Guidelines

The no ppp bap drop accept command disables the router’s ability to respond favorably to link drop requests from a peer. However, the router can still remove the link when it receives such requests.

The no ppp bap drop after-retries command is the default behavior; the ppp bap drop after-retries command must be entered explicitly to be effective.

The no ppp bap drop request command disables the router’s ability to send link drop requests to a peer. However, the peer can still remove the link on its own behalf; for example, when there is too little traffic to justify keeping the link up.

The ppp bap max command specifies the maximum number of requests and retries.

Examples

The following partial example sets a 60-second wait between drop requests:

 

Related Commands

 

Syntax Description

 

Command Default

ISDN interfaces are added to the multilink bundle ( isdn keyword).

 

Command History

 

Usage Guidelines

The choice of keywords must suit the interfaces configured for Multilink PPP. For example, if you have configured a dialer rotary with only ISDN interfaces, only the isdn keyword would be appropriate. If the configuration allows both ISDN and asynchronous interfaces, both isdn and analog keywords could be used; the multilink bundle could then consist of both ISDN and asynchronous links. Bandwidth Allocation Protocol (BAP) dynamically determines which interfaces are applicable.

Examples

The following example configures a dialer interface for passive mode BAP and for both ISDN and asynchronous serial links:

 

Related Commands

 

Syntax Description

 

Command Default

1 dial attempt
3 indication retries
3 request retries
5 searches for free dialers

 

Command History

 

Usage Guidelines

In compliance with RFC 2125, the no form of this command explicitly removes any status indication retry limit and is displayed in the router configuration.

The ppp bap max dialers command works in conjunction with the dialer rotor and dialer priority interface commands, which can be used to determine free dialers based upon the priority or the best available. Dialers include all interfaces that are configured under the dialer group leader (the dialer interface itself). The dialer group leader is displayed as the Master Interface in the show ppp bap grou p output.

BAP bases its link type and phone number decisions upon the ordering of the interfaces. This decision is suited to a mixed media environment of both ISDN and analog interfaces, where it may be desirable to choose the ISDN link over the asynchronous or vice versa.

Note that this decision also will limit the number of potential phone numbers that can be included in a CallResponse or CallbackRequest; the maximum number is limited to 20. For example, ten BRI interfaces with two numbers per interface.

Examples

The following partial example accepts the default number of attempts to dial a number and the default number of indication retries, but configures a limit of four times to send requests:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Command is enabled.

 

Command History

 

Usage Guidelines

If the load is being monitored and the incoming peer requests that a link be dropped when the current traffic load is above the dialer load (that is, there is enough traffic to justify the current number of links), the router will not drop the link. In addition, when the traffic falls below the threshold, Bandwidth Allocation Protocol (BAP) tries to drop a link.

The no form of this command indicates that incoming peer requests to add a link are not subject to the bundle load threshold. However, other criteria must be met before a favorable response is sent.

Examples

The following partial example configures BAP not to validate peer requests against the current bundle load and the configured dialer load threshold:

 

Related Commands

 

Syntax Description

 

Command Default

No base number is provided.

 

Command History

 

Usage Guidelines

Use this command to supply a local default number to be exchanged between peers in order to establish a multilink bundle.

This command is applicable on both the dialer interface and the individual physical interfaces.

If a peer requests that a number be supplied and no PPP Bandwidth Allocation Protocol (BAP) default number is defined, it might not be possible for the peer to access the interface. However, the peer can access the interface if it has the number already or the number it dialed originally is the same as the number for establishing a Multilink PPP (MLP) bundle.

Note During BAP negotiations between peers, the called party indicates the number to call for BAP if it is different from the number the peer originally dialed. The called party responds with information about the phone number delta (the changes to be made in the right-most digits dialed). This information indicates the number of digits that are different from the number originally dialed and what those digits should be.

For example, if the remote peer dialed 5550159876, and the ppp bap number command had the default number 5550159912, the local router would respond “3 | 912.” In the response, a vertical bar ( |) is used to divide the number of digits to change from the number sequence to use instead. In the “3 | 912” response, the local router instructs the calling interface to replace the right-most three digits with “912” for BAP.

This command is used by the client side for dialing instructions when communicating with the server. Use the prefix keyword on the Always On/Dynamic ISDN (AO/DI) client side to specify what will precede any number dialed to a multilink peer. For example, the client issues a call request to the server whereby the server issues a call response that includes the dialing number the client should use and the format this number should be in (national or subscriber). The client then dials the number supplied by the server, preceded by any prefix information contained in the ppp bap number prefix command. Figure 1 shows an overview about the information exchange between the client and the server.

Figure 1 Client and Server Response Sequence

Use the format keyword on the AO/DI server side to specify how many digits should be returned by BAP. BAP will return the numbers based on either a national or subscriber format. The value that is returned is preceded by the prefix before dialing occurs. For example, if the format national keywords are configured, then the national format (which is equivalent to ten digits) is returned (during BAP negotiation) from the server.

Note The ppp bap number prefix and ppp bap number format keyword options cannot be combined to a single-string command line; they must be entered in two separate command strings.

Examples

In the following example, the AO/DI client uses a ppp bap prefix value of 9, which indicates that the dialed number of 5550134 will be preceded by a 9. The number that is actually dialed is 95550134. The AO/DI server uses a subscriber format, which indicates that when the client asks the server for the numbers to dial, BAP will return seven digits.

Client Router

Server Router

In the following example, the AO/DI client uses a ppp bap prefix value of 1, which indicates that the dialed number of 5550178 will be preceded by a 1. The number that is actually dialed is 19195550178 because the server is using a national format, and BAP therefore, returns ten digits.

Client Router

Server Router

The following example configures a physical interface with both a default number and a secondary number:

 

Related Commands

 

Syntax Description

 

Command Default

Enabled
pending : 20 seconds
response : 3 seconds

 

Command History

 

Usage Guidelines

The no ppp bap timeout response command resets the timer to the default value.The no ppp bap timeout pending command removes the pending-action timeout entirely (in compliance with the BAP specification).

Examples

The following example configures BAP to wait 45 seconds before timing out pending actions:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Command is disabled.

 

Command History

 

Usage Guidelines

When you configure a serial or ISDN interface for half-bridging, you configure it to function as a node on an Ethernet subnetwork. It communicates with a bridge on the subnetwork by sending and receiving bridge packets. The serial or ISDN interface converts bridge packets to routed packets and forwards them, as needed.

The serial interface must be configured with an AppleTalk address for communication on the Ethernet subnetwork, and the AppleTalk address must have the same AppleTalk cable range as the bridge.

You cannot configure a serial interface for both half-bridging and for transparent bridging. No more than one half-bridge should be on any subnetwork.

Examples

The following example configures serial interface 0 for half-bridging of AppleTalk. The remote bridge and other Ethernet nodes must be on the same network.

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Command is disabled.

 

Command History

 

Usage Guidelines

When you configure a serial or ISDN interface for half-bridging, you configure it to function as a node on an Ethernet subnetwork. It communicates with a bridge on the subnetwork by sending and receiving bridge packets. The serial interface converts bridge packets to routed packets and forwards them, as needed.

The interface must be configured with an IP address for communication on the Ethernet subnetwork, and the IP address must be on the same subnetwork as the bridge.

You cannot configure a serial interface for both half-bridging and for transparent bridging.

No more than one half-bridge should be on any subnetwork.

Examples

The following example configures serial interface 0 for half-bridging of IP. The remote bridge and other Ethernet nodes must be on the same subnetwork.

 

Related Commands

 

Syntax Description

 

Command Default

The default encapsulation is novell-ether.

 

Command History

 

Usage Guidelines

When you configure a serial interface for half-bridging, you configure it to function as a node on an Ethernet subnetwork. It communicates with a bridge on the subnetwork by sending and receiving bridge packets. The serial interface converts bridge packets to routed packets and forwards them, as needed.

The serial interface must be configured with an IPX address for communication on the Ethernet subnetwork, and the IPX address must be on the same subnetwork as the bridge.

You cannot configure a serial interface for both half-bridging and for transparent bridging.

No more than one half-bridge should be on any subnetwork.

Examples

The following example configures serial interface 0 for half-bridging of IPX. The remote bridge and other Ethernet nodes must be on the same subnetwork.

 

Related Commands

 

Syntax Description

 

Command Default

Callback requests are neither accepted nor requested.

 

Command History

 

Usage Guidelines

An interface can request PPP callback only if the interface is configured for PPP authentication with Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP).

If an interface of the callback server is configured with ppp callback accept and the client attempts to cancel the callback and connect, Cisco IOS software will refuse the request and disconnect the client.

If a client is allowed to cancel callbacks and connects, the ppp callback permit command must be used instead of the ppp callback accept command on the callback server interface.

Examples

The following example configures a previously defined dialer interface to accept PPP callback requests:

 

Related Commands

 

Syntax Description

 

Command Default

Callback requests are not accepted on asynchronous interfaces.

 

Command History

 

Usage Guidelines

PPP callback can be initiated only if the interface is configured for authentication using CHAP or PAP.

Examples

The following example accepts a callback request from an RFC-compliant PPP client:

The following example accepts a callback request from a non-RFC-compliant PPP client:

 

Related Commands

 

Syntax Description

 

Command Default

Command is disabled by default.

 

Command History

 

Usage Guidelines

This command sets the username used when the CLID is not available. This username is used only in the case where the ppp dnis command is configured and the CLID is not available.

Examples

The following example shows how to configure a call to user1:

 

Related Commands

 

Syntax Description

 

Defaults

Disabled (no direction configured)

 

Command History

 

Usage Guidelines

The ppp direction command is useful when a router is connected to an interface type where there is either no inherent call direction, such as with a back-to-back or leased-line connection, or where an external dial device such as a CSU/DSU or an ISDN terminal adapter is connected to the interface.

The configured call direction will always override the automatically detected direction, even on dial interfaces where the true direction is known.

The call direction is used mainly internally by PPP authentication, as follows:

• If doing bidirectional authentication, PPP will wait to send its authentication credentials to the peer if the direction is call-in, and the no ppp chap wait, no ppp pap wait, or no ppp eap wait commands are not configured.
• PPP uses the call direction internally to detect spoofed Challenge Handshake Authentication Protocol (CHAP) sessions.
• If the direction is call-in, PPP requires that the remote names used in a peer’s CHAP challenge and CHAP response be the same.

The call direction is also used for callback processing.

Typically, you will not need to configure this command. If you do, you should configure the opposite of the command on the other side of the link, so one side is call-out and one side is call-in.

Examples

The following example determines the call direction on a back-to-back serial connection:

 

Related Commands

 

Syntax Description

 

Command Default

This command is disabled by default.

 

Command History

 

Usage Guidelines

This command enables a method of authenticating and authorizing a user based on the DNIS. The DNIS is the number dialed by the user. If the dialed number for this session matches one of the numbers configured in the ppp dnis command, the user is automatically authenticated and authorized for the session. Any other configured PPP authentication is not performed. In the case of DNIS authentication, the Calling Line Identification (CLID) is used as the username. If the CLID is unavailable, the username is the name configured with the ppp caller name command. If neither the CLID nor a caller name is configured, the username will automatically be set to “no-clid.”

Examples

The following example shows how to set the DNIS for a call:

 

Related Commands

 

Syntax Description

 

Command Default

MPPE encryption is disabled.

 

Command History

 

Usage Guidelines

PPP encapsulation must be enabled before you can use the ppp encrypt mppe command.

All of the configurable MPPE options must be identical on both tunnel endpoints.

The auto keyword is offered only on 128-bit images.

Note The ppp authentication ms-chap command must be added to the interface that will carry Point-to-Point Tunnel Protocol (PPTP)-MPPE traffic. All Windows clients using MPPE need the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) application. This is a Microsoft design requirement.

Stateful encryption is not appropriate for links that have high loss rates because the state information is updated with each packet received, but cannot be updated correctly for packets that are not received. Losing a packet means loss of state (transmissions are no longer synchronous). Losing state triggers expensive resynchronization mechanisms, and more packets will be lost during the recovery period. Any link that experiences more than the occasional random drop is therefore unsuitable for stateful encryption mechanisms. The same is also true for stateful compressions. For this reason, stateful encryption may not be appropriate for lossy network environments such as Layer 2 tunnels on the Internet.

The interleaving of packets among fragments of larger packets on a Multilink PPP (MLP) bundle (enabled with the ppp multilink interleave command) is not supported with this command.

Examples

The following example shows a virtual template configured to perform 40-bit MPPE encryption:

 

Related Commands

 

Syntax Description

 

Command Default

The default length depends on the platform. That is, the default length is twice the maximum number of PPP-supported interfaces on that platform.

 

Command History

 

Usage Guidelines

The exact value of the packets queued depends on the number of PPP sessions supported. The default value works in most cases. It is not recommended to set a different value unless your Cisco technical support representative directs you to do so for deployment-specific tuning purposes.

The command specifies that only packets that are actually queued are counted; packets that are discarded at interrupt because they do not pass various checks are not counted. Preprocessed packets are also not counted. Any type of packet queued to the PPP process is counted.

Examples

The following example shows how to specify the maximum number of packets to be queued to the PPP process:

 

Syntax Description

 

Command Default

No servers are configured, and no address request is made.

 

Command History

Examples

The following examples show use of the ppp ipcp command:

The following examples show how to use the no form of the ppp ipcp command:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

No default route

 

Command History

 

Usage Guidelines

This command allows a PPP virtual template to dynamically add a default route pointing to the virtual access interface created by the virtual template.

A customer premises equipment (CPE) router with PPP over an ATM or Frame Relay connection can access the Internet without turning on any other routing.

Examples

The following example shows how to configure the PPP default route on the virtual access interface:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

The PPP IPCP is not set to a predictive state.

 

Command History

 

Usage Guidelines

The ppp ipcp predictive command is useful in networks that accept connections from devices that require a reduction in the IPCP 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 IPCP negotiation strategy make this time reduction possible:

• Send an IPCP Configure-Ack packet after sending an IPCP Configure-Nak packet.
• Send IPCP Configure-Nak and Configure-Ack packets after rejecting certain configuration options.

These changes can reduce connection delay by approximately 40 percent.

Note Any Configure-Request packet received in the Open state is ignored until the software receives Configure-Request packets with identifying numbers greater than what was last acknowledged, in which case the software disables the predictive mode and processes the Configure-Request packet using normal IPCP negotiation operations.

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

Examples

The following example sets the link control protocol (LCP) and IPCP to predictive states on a group asynchronous interface:

 

Related Commands

 

Syntax Description

 

Command Default

168 bytes

 

Command History

 

Usage Guidelines

There are two types of IP header compression used over PPP: Van Jacobsen header compression defined in RFC 1332 and enabled with the ip tcp header-compression command, and IPHC defined in RFC 2509 and enabled with the ip rtp header-compression command. 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 the 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
• The RTP marker bit

Examples

The following example shows how to change the maximum size of the largest IP header that may be compressed from the default of 168 bytes to 114 bytes:

 

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 to 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 shows how to configure 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 shows how to configure 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 shows how to configure 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 shows how to configure 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.

 

Related Commands