Figure 1 PPP Frame Structure
This document provides information about the Point-to-Point Protocol (PPP), including PPP authentication protocols (PAP and CHAP), Multilink PPP (MP) and data compression over PPP. The document also explains how to configure PPP interfaces and describes the PPP commands. It includes the following topics:
PPP Overview
The PPP Link Control Protocol
The PPP Network Control Protocols
Multilink PPP
PAP and CHAP
Call-back Feature
Data Compression
Real-Time Transport Protocol (RTP) Header Compression
Displaying the PPP Prompts
Configuring PPP
Configuring PAP
Configuring CHAP
PPP Commands
Displaying Statistics for PPP Interfaces
PPP Overview
Point-to-Point Protocol (PPP) is designed for simple links that transport packets between two peers. PPP provides a method for transmitting datagrams at the data link layer over serial point-to-point and ISDN links. PPP supports synchronous, asynchronous, and ISDN data transmission and provides the following services:
Link Control Protocol (LCP) to establish, configure, and test the link connection, and to automatically agree on encapsulation format options.
Encapsulation of protocol datagrams to provide for multiplexing of different network layer protocols simultaneously over the same link.
Network Control Protocols (NCPs) to establish and configure different network-layer protocols. PPP allows the use of multiple network-layer protocols.
The OpenROUTE software supports the Internet Protocol Control Protocol (IPCP), the AppleTalk® Control Protocol (ATCP), the Bandwidth Allocation Control Protocol (BACP), the Bridging Network Control Protocol (BNCP), and the IPX Control Protocol (IPXCP).
Multilink PPP to provide bandwidth on demand, including bandwidth allocation protocols (BAP and BACP)
PPP authentication protocols (PAP and CHAP).
Data Compression over PPP.
Real-Time Transport Protocol (RTP) Header Compression over PPP.
Link Establishment Packet. Establishes and configures a link.
Link Termination Packet. Terminates a link.
Link Maintenance Packet. Manages and debugs a link.
Figure 2 LCP Frame Structure
Code
The code field is one octet in length and identifies the type of LCP packet. The codes in Table 2 distinguish the packet types. They are described in more detail in later sections.
Table 2 LCP Packet Codes
Identifier
The identifier field is one octet in length and is used to match packet requests and replies.
Length
The length field is two octets in length and indicates the total length (including the first and last fields) of the LCP packet.
Data (Optional)
The data field is zero or more octets as indicated by the length field. The format of this field is determined by the code.
Link Establishment Packets
Link Establishment Packets establish and configure a point-to-point link using the following packet types:
Link Termination Packets
Link Termination Packets close a link and include the following packet types:
Link Maintenance Packets
Link Maintenance Packets manage and debug a link, and include the following packet types:
The PPP Network Control Protocols
PPP has a family of Network Control Protocols (NCPs) that are responsible for configuring, enabling, and disabling the network layer protocols on both ends of the link. NCP packets cannot be exchanged until LCP has opened the connection and the link reaches the Open state.
PPP supports the Network Control Protocols in Table 3.
Multilink PPP
OpenROUTE software supports standard Multilink PPP (MP) as defined in RFC 1990. MP combines multiple physical links between a fixed pair of systems into one logical link. This logical link is called a bundle, and it has greater bandwidth than any of the individual links.
You can use MP on multiple PPP devices that connect two systems. This includes ISDN, as well as serial connections. For example, on ISDN BRI devices, MP combines the two B channels into one logical link.
PPP negotiates MP in the LCP Configure Request. Once LCP transitions into the Open state, MP makes a determination: Does the new link join an existing bundle or start a new one? MP makes this determination based on information acquired about the peer's identity during authentication (if it was run) and by using an Endpoint Discriminator (EID), which was also negotiated in the LCP Configure Request.Note:
If authentication was not run, it is possible to get the peer's identity on ISDN calls that provide caller ID.
To set up Multilink PPP using more than one physical device, you need to add a manual stack to your router configuration.
Bandwidth-on-demand
Bandwidth-on-demand is a feature of MP that monitors the traffic utilization of calls and automatically opens additional connections when data traffic on the existing connections exceed a threshold that you configure. For ISDN BRI connections, bandwidth-on-demand is valuable when the telephone company charges separately for each B channel. You need to use the second B channel only during periods of heavy traffic.
OpenROUTE software determines traffic utilization by measuring the bytes per second passing the connection(s). It computes this measurement using a weighted average of traffic over the last 32 seconds. Three built-in sets of weights provide a Fast, Medium, or Slow response time to changes in traffic load. To enable bandwidth-on-demand enter set mp bandwidth-on-demand followed by Fast, Medium, or Slow.
MP decides to add or drop connections by comparing the traffic utilization to two thresholds that you set using the set mp high-utilization and set mp low-utilization commands. The default low and high utilization thresholds are 35% and 70%, respectively. When traffic on the interface exceeds 70% of its capacity, MP opens another link (if available) to provide more bandwidth. If traffic on the interface (counting across all connections currently in use) falls below 35%, then OpenROUTE drops the second connection. (OpenROUTE does not drop the first connection unless the dial-on-demand idle time expires).
Using Multilink PPP with Two OpenROUTE ISDN Routers
3000 Series software has sophisticated call collision logic within Multilink PPP (MP) that normally assembles a multilink bundle of two ISDN B channels even when two 3000 Series routers call each other simultaneously. However, that software requires each router to know the identity of the other router. Therefore, when two routers are both enabled to place outbound calls to each other, you must have caller ID provisioned on your ISDN switch or have PPP PAP or CHAP enabled on the router, so the two routers can identify each other. Otherwise, one of the two calls is refused and call retries begin. This can cause some "thrashing" as call collisions continue to occur while the second B channel is brought up.
BAP and BACP
If you are using Multilink PPP (MP), you need to be able to manage bandwidth over MP. Bandwidth Allocation Protocol (BAP) and its associated protocol, Bandwidth Allocation Control Protocol (BACP), manage bandwidth between two peers on a point-to-point link.
BAP is a method for managing the dynamic bandwidth requirements of an MP bundle and defining datagrams for adding and removing individual links in the bundle. The local and remote peer use these datagrams to coordinate the addition and removal of Link Control Protocol (LCP) links to and from the MP bundle. BAP also specifies which peer is responsible for which decisions regarding managing bandwidth during a multilink connection. (See RFC 2125.)
BAP starts after the first link of the MP bundle is established.
BACP is the control protocol that negotiates the configuration BAP uses during each BAP session. It works essentially in the same way as LCP. It uses the same packet exchange mechanism as LCP. BACP negotiates after PPP has negotiated MP and reached the network-layer protocol phase. Packets received before this phase is reached are silently discarded. BACP is negotiated once per multilink bundle. When it is negotiated on any of the links in a multilink bundle, it is opened for all of the links in the bundle.
During the negotiation phase of BACP, a favored peer is determined. This is the only BACP configuration option currently defined (in RFC 2125). The favored peer is the originator of the first call.
When Bandwidth-on-demand is off, the router does not initiate BACP negotiation. When bandwidth-on-demand is on, BACP initiates BACP negotiation after the LCP link is established. All bandwidth increases and decreases are then negotiated with the peer, who either accepts or refuses the request.
PAP and CHAP
OpenROUTE provides two authentication methods, the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). CHAP uses the RSA Data Security, Inc. MD5 Message-Digest Algorithm, Copyright, 1990.
This discussion of PAP and CHAP uses the following terms:
Selecting the Authentication Method
The authenticator and peer negotiate an authentication protocol during the Link Establishment phase of PPP. To do so, the authenticator requests the peer to use either PAP or CHAP. If the peer replies that it
Supports that protocol, the two systems perform the authentication process, as described in the next sections.
Does not support that protocol, the authenticator requests a different protocol or it closes the connection.
Does not receive a response, it waits a configurable period of time and sends the PAP packet again, repeating this until it receives a positive (ACK) or negative (NAK) response.
Receives a positive response, it brings up the Network Control Protocols (NCPs) for the forwarding protocols, such as IP or IPX.
Receives a negative response, authentication fails and the authenticator closes the connection.
If it does not receive one, it waits a configurable number of trials. If it still does not receive a PAP packet, it closes the connection.
If it does receive one, it compares the password for the peer's name in its local memory to the password in the PAP packet and, if they match, it returns a positive acknowledgment (ACK) to the peer. If the password does not match, it returns a negative acknowledgment (NAK) to the peer and closes the connection.
If the authenticator does not receive a response after a configurable time, it retransmits the challenge. The authenticator can repeat this a configurable number of times until it gives up and terminates the connection.
The peer then encrypts the message contained in the challenge using this secret and transmits the encrypted result back to the authenticator in a response packet that contains the peer's name.
CHAP does not transmit the secret over the link. You must configure the same secret on both routers.
If the values match, the authenticator transmits a success packet and brings up the Network Control Protocols (NCPs); otherwise, it transmits a failure packet and terminates the connection.
Once the peer receives a successful acknowledgment packet, it brings up its Network Control Protocols.
If the peer receives a failure response, it terminates the connection.
Circuit Config <NET-#> prompt.
Call-back Feature
The Call-back feature causes a local router to use an incoming call as a signal to call back a remote router. OpenROUTE uses the Link Control Protocol (LCP) Callback option, as defined in RFC 1570, to control Call-back processing. Call-back is typically used with dial-on-demand.
The default is to have Call-back disabled. If the remote router requests Call-back and Call-back is disabled on the local router, the local route rejects the request.
Using the Call-back Feature on an ISDN Interface
On an ISDN interface, you can set up Call-back so that the local router does not answer the incoming call, and the remote router does not incur the expense of placing the call. This feature is sometimes called D-channel Call-back.
D-channel Call-back only works on the first call received from the caller. If the calling router calls a second time after one call is already established, the receiving router answers the second call momentarily, and then drops the call. Then, the receiving router makes a second call-back.
To work around this problem, configure the remote router (that is, the router making the call) to call only once.
If you're using Multilink PPP (MP), configure the router receiving the call to bring up the second call either by enabling Bandwidth-on-Demand or by setting the MP initial-bundle-size to two.
Identifying the Call-back Destination
The local router never calls back a caller that it cannot identify or that fails authentication. It calls only destinations that you set at the Circuit Config <NET-#> prompt. Ideally, you should set up your router to use Caller-ID, PAP, or CHAP so that it can identify which destination to call. If you set up Call-back on an ISDN interface using the Always option, described below, the router does not answer the incoming call. Therefore, it is preferable to use Caller-ID to identify the caller.
Using Caller-ID with Call-back assures the following:
The router calls back the remote router that Caller-ID identifies. This means that you can enable multiple circuits to always perform a Call-back, and the router uses Caller-ID to call back the correct remote router.
The router does not place a call to a configured destination when it receives a call from an unknown, and possibly malicious, party.
Circuit Config <NET-#> set idle 60
Config>network 1
Circuit Config <NET-1>set destination
Assign destination address name [ ]?my-job
Circuit Config <NET-1> set idle
Idle timer (seconds, 0 means always active) [ ]? 60
Circuit Config <NET-1> ppp
Point-to-Point user configuration
PPP Config <NET-1> enable call-back request
Config>network 1
Circuit Config <NET-1>set destination
Assign destination address name [ ]?my-isp
Circuit Config <NET-1> set idle
Idle timer (seconds, 0 means always active) [ ]? 60
Circuit Config <NET-1> ppp
Point-to-Point user configuration
PPP Config <NET-1> enable call-back accept
Circuit Config <NET-1>enable outbound
Timing problems can occur if the Call-back is performed too quickly or too slowly. The set lcp parameters command lets you define how long the local router waits between hanging up the telephone and making the Call-back to the remote router. The following example shows an interface configured to always call back the remote router, my-isp, whenever the local router receives a call from the ISP.Config>network 1
Circuit Config <NET-1>set destination
Assign destination address name [ ]?my-isp
Circuit Config <NET-1> enable outbound
Circuit Config <NET-1> set idle
Idle timer (seconds, 0 means always active) [ ]? 60
Circuit Config <NET-1> ppp
Point-to-Point user configuration
PPP Config <NET-1> enable call-back always
Compression Control Protocol (CCP)
The router uses CCP to negotiate the choice of a compression algorithm with the other router on the link.
CCP is an Internet Engineering Task Force (IETF) draft protocol (RFC 1962).
Compression algorithms
Compression algorithms carry out the actual compression of outgoing data and decompression of incoming data. The algorithms use an independent compression history for each direction on the link.
An important consideration in choosing a compression algorithm is its compression ratio: the size of the original data stream relative to the compressed data stream. The greater the ratio the more effective the compression. Compression algorithms typically have compression ratios between 2:1 and 3:1.
Note: The OpenROUTE 2.3 software supports only one algorithm, the Stac® LZS® compression algorithm.
The compression ratio depends heavily on the data to be transmitted. ASCII English text is highly compressible (with a large compression ratio). Executable binary data are generally moderately compressible. Data that are precompressed by an application (for example, compressed image data streams like MPEG or JPEG) are not compressible.
Compression algorithm interfaces
These are modules that interface between the PPP software and a particular compression algorithm.
Negotiating a Compression Algorithm
When the router brings up a PPP link, it initiates an exchange of CCP packets as part of the link establishment. The router negotiates with its peer router to set the compression algorithm.
Compressing Data
The router performs PPP network layer encapsulation and then hands the data stream to the compression algorithm interface. The interface manipulates the PPP packet for compression by the compression algorithm.
The compression algorithm uses its compression history (dictionary) to carry out the compression of the data stream.
Transmitting the Compressed Data
The router sends the compressed datagram to the MAC layer. If Multilink PPP is enabled, one of the physical channels is selected. Then the HDLC software generates a physical frame to be transmitted to the WAN link. See Figure 3.
The compression process is reversed at the peer router on the WAN link. The negotiated compression algorithm and the compressor algorithm interface decompress the data in the packet.
Figure 3 Data Compression on the Router
Real-Time Transport Protocol (RTP) Header Compression
Beginning with router software release 5.5, Nx Networks' routers support Real-time Transport Protocol (RTP) header compression over PPP connections. As specified in RFC 2508, Compressing IP/UDP/RTP headers for Low-Speed Serial Links, the implementation on Nx Networks' routers combines compression of IP, UDP, and RTP headers on a link-by-link basis. To support RTP header compression, the router's Internet Protocol Control Protocol (IPCP) header format is expanded to include configuration parameters for IP compression as specified in RFC 2509, IP Header Compression over PPP.
What is RTP?
RTP provides end-to-end network transport services for applications that transmit real-time data, as specified in RFC 1889, RTP: A Transport Protocol for Real-time Applications. RTP's network transport services include payload type identification, sequence numbering, timestamping, and delivery monitoring. RTP runs over UDP to take advantage of UDP's multiplexing and checksum services. RTP does not address resource reservation, and it does not guarantee quality of service (QOS) for real-time traffic. RTP relies on services such as IP DiffServ to provide QOS for an application.
Real-Time Control Protocol (RTCP) augments RTP's data transport function, providing a means of monitoring data delivery as well as limited control and identification functions. RTCP periodically sends information relevant to the calculation of packet loss rate, packet transmission delay, and delay jitter to all senders and receivers of a session. Applications use this data to characterize the current state of the network. Some applications can use the data to adjust their transmission rates and to help relieve congestion.
The RTP Header Packet
The RTP header consists of elements that are common among all applications and elements that programmers can modify. Programmers can also add elements to the RTP header to suit the requirements of a specific application.
Because real-time applications are bandwidth intensive, voice and video packets are normally compressed. The 40 byte header for IP, UDP, and RTP is too large an overhead for a 20 byte payload when operating over a slow speed line. In order to reduce transmission delay while sending small voice packets over slow links (64 kbps), RTP header compression reduces the header size to 2 or 4 (with UDP checksum) bytes. This improves interactive response time for real-time traffic.
Figure 4 illustrates the structure of the RTP header packet and a description of each field follows.
Figure 4 RTP Header Packet Structure
How RTP Header Compression Works
RTP occurs in two stages—compression at the source and decompression at the destination. RTP header compression makes use of the fact that half the bytes in IP and UDP headers remain constant over the life of a session. Even when some fields, such as sequence number, change in every packet, the difference between packets is often constant.
For each RTP packet, the compressor sends to the decompressor identification of the header type; if the header type is FULL_HEADER, the decompressor maintains the uncompressed header. For any type of compressed header, the decompressor maintains the constant difference between consecutive packets in certain header fields. This is called the first-order difference. The decompressor reconstructs the original header for compressed headers by adding the first-order differences to the uncompressed headers as each compressed packet is received.
As long as the first-order difference remains the same, the compressor sends a second-order difference of zero. If the second-order difference is non-zero, the compressor sends a new first-order difference to the decompressor.
RTP Session Context
Both compressor and decompressor maintain a shared state for each session, which is called the session context. The combination of IP source and destination addresses, the UDP source and destination ports, and the RTP synchronizing source (SSRC) field make up the session context for RTP sessions. A hash of these fields, called the session context identifier (CID), indexes into the session context table and is carried in the compressed packet to indicate the context under which the packet should be interpreted at the decompressor.
Compression Format
RTP header compression over a particular link is a data link function, which the router negotiates using IPCP data link protocol. The router implements the RTP header compression according to the new "IP header compression format" specified in RFCs 2507, 2509. This "IP header compression format" is generic enough to support IPV4/IPV6 TCP, UDP, AH and ESP header compressions. Because RTP is a UDP application, PPP negotiates both TCP and UDP header compression according to the new format. PPP recognizes and processes the following protocol identifiers.
Release 5.4 and earlier of the router software supports TCP header compression using the RFC 1144 implementation. Protocol identifiers for these packet formats as shown below:FULL_HEADER 0x0061
COMPRESSED_TCP 0x0063
COMPRESSED_TCP_NODELTA 0x2063
COMPRESSED_NON_TCP 0x0065
COMPRESSED_UDP_8 0x0067
COMPRESSED_UDP_16 0x2067
COMPRESSED_RTP_8 0x0069
COMPRESSED_RTP_16 0x2069
CONTEXT_STATE 0x2065
Both old and new COMPRESSED_TCP packet identifiers indicate the same Van Jacobson differential encoding. However, the packet formats are different and the new packet formats can support new protocol identifiers such as FULL_HEADER and COMPRESSED_TCP_NODELTA. According to the RTP protocol specification, the aggregate RTCP bandwidth used by all participants in a session will not be more than 5% of the session bandwidth; therefore, RTCP packets are not compressed. All fragmented packets and packets with less than 12 bytes of UDP data are not compressed.IP_HEADER 0x0021
COMPRESSED_TCP 0x002D
UNCOMPRESSED_TCP 0x002F
Config> prompt to display a list of interfaces.
Config>network
What is the network number [0]? 1
Circuit Configuration
Circuit Config <NET-1>
Circuit Config <NET-1> ppp
Point-to-Point user configuration
PPP Config <NET-1>
Monitor>list interface
Self-Test Self-Test Maintenance
Nt Interface Passed Failed Failed
0 Eth/0 2 0 0
1 PPP/0 0 0 0
2 PPP/1 0 0 0
Monitor>network 1
Circuit <NET-1>
Circuit <NET-1>ppp
Point-to-Point Console
PPP <NET-1>
Config>network
What is the network number [0]? 1
Circuit Configuration
Circuit Config <NET-1> ppp
Point-to-Point user configuration
PPP Config <NET-1>
If you are running bridging, enter Yes to set the MRU automatically. Bridging cannot run on PPP interfaces if the MRU is less than the maximum Ethernet frame size. Setting the MRU to automatic prevents this problem.
PPP Config <NET-1>set lcp options
Set Maximum Receive Unit (MRU) automatically? [Yes]:
Magic Number [no]:
Async Control Char. Map (ACCM) [0x0]?
Protocol Field Compression(PFC) [yes]:
Address/Control Field Compression(ACFC) [yes]:PPP Config <NET-1>set lcp parameters
Config tries [10]?
NAK tries [5]?
Terminate tries [2]?
Retry timer (mSec) [3000]?
Callback Delay (mSec) [600]?
PPP Config <NET-1>set ipcp
RTP Header Compression (IP Header Compression Format) [yes]?
Number of RTP Slots [6]? 10
Number of TCP Slots [12]? 20
Send our IP address [no]?
Request their IP address [no]?
PPP Config <NET-1>set parameters
Config tries [10]?
NAK tries [5]?
Terminate tries [2]?
Retry timer (mSec) [3000]?
PPP Config <NET-1>enable mp
PPP Config <NET-1>set mp ?
DISCRIMINATOR
SEQUENCE-NUM-LEN
BANDWIDTH-ON-DEMAND
INITIAL-BUNDLE-SIZE
MAX-BUNDLE-SIZE
HIGH-UTILIZATION
LOW-UTILIZATION
PPP Config <NET-1>exit
Circuit Config <NET-1>set destination
Assign destination address name [ ]?my-isp
Circuit Config <NET-1> set idle
Idle timer (seconds, 0 means always active) [ ]? 60
Circuit Config <NET-1> ppp
Point-to-Point user configuration
PPP Config <NET-1> enable call-back always
Note: You must enable PAP or CHAP on any interface that you configure the Call-back feature.
PPP Config <NET-1>enable ccp
PPP Config <NET-1>set ccp options
STAC: # histories [1]?
STAC: check mode (0=none, 1=LCB, 2=CRC, 3=Seq) [3]?
IP Config> prompt.
PPP Config <NET-1>exit
Circuit Config <NET-1>exit
Config> protocol ip
IP Config>
IP config>add address
Which net is this address for [0]? 1
New address [0.0.0.0]? 0.0.0.1
Allow dynamic address assignment(Yes or [No]): yes
Address mask [255.255.255.0]?
Config>
Ctrl P*restart
Are you sure you want to restart the gateway? (Yes or [No]):yes
Config>set hostname
What is the new host name []?GTlocal
Config>network
What is the network number [0]? 1
Circuit Configuration
Circuit Config <NET-1> ppp
Point-to-Point user configuration
PPP Config <NET-1>
PPP Config <NET-1>add password
Router name []? GTlocal
Router password []? localpw
PPP Config <NET-1>add password
Router name []? GTremote
Router password []? remotepw
The default is to allow any router that passed authentication to connect. You must have previously used the add password command to define a password for each router you enter.
You create the access list at the Circuit Config <NET-#> prompt.
PPP Config <NET-1>exit
Circuit Config <NET-1>set access-list
Enter 1st name: ? GT70remote1
Enter 2nd name: ? GT70remote2
Enter 3rd name: ?
PPP Config <NET-1>enable pap answering-calls
PPP Config <NET-1>set pap parameters
Max Request Timeouts [20]?
Request Timeout (mSec) [15000]?
Retry Timeout (mSec) [3000]?
PPP Config <NET-1> prompt and restart the router to activate the new configuration.
PPP Config <NET-1> exit
Circuit Config <NET-1> exit
Config>Ctrl P*restart
Are you sure you want to restart the gateway? (Yes or [No]):yes
Config>set hostname
What is the new host name []?GTlocal
Config>network
What is the network number [0]? 1
Circuit Configuration
Circuit Config <NET-1> ppp
Point-to-Point user configuration
PPP Config <NET-1>
Nx Networks recommends that you do not use this command to override the default of using the host name to identify the PPP interface. Use this command only if the local router needs to identify itself differently on different PPP interfaces.
PPP Config <NET-1>set chap local-name
Local router name? [GT70local]? gt70
If you do not know the name of the remote router, then add a secret for the destination address name you entered for the remote router using the set destination command at the Circuit Config <NET-#> prompt. The local router uses the secret you define for the destination address name if it cannot find a secret for the name in the remote router's CHAP challenge packet.
PPP Config <NET-1>add secret
Router name []? GT70remote
Router secret []? remotesecret
The default is to allow any router that passed authentication to connect. You must have previously used the add secret command to define a secret for each router you enter.
You create the access list at the Circuit Config <NET-#> prompt.
PPP Config <NET-1>exit
Circuit Config <NET-1>set access-list
Enter 1st name: ? GT70remote1
Enter 2nd name: ? GT70remote2
Enter 3rd name: ?
PPP Config <NET-1>enable chap answering-calls
PPP Config <NET-1>enable chap originating-calls
Note: Typically, you should enable CHAP when the local router answers an incoming call. If you enable CHAP when the local router originates a call, you should be aware that some routers refuse to reply to CHAP requests from a remote caller.
PPP Config <NET-1>set chap parameters
Challenge tries [10]?
Challenge timeout (mSec) [15000]?
Response timeout (mSec) [3000]?
PPP Config <NET-1> prompt and restart the router to activate the new configuration.
PPP Config <NET-1>exit
Circuit Config>Ctrl P*restart
Are you sure you want to restart the gateway? (Yes or [No]):yes
Not all parameters apply to all router platforms. Press Space twice after you type a command to display the available parameters for each command for your router. Enter help for information about using the command line interface.
[C] means the command is available at the PPP Config <NET-#> prompt.
[M] means the command is available at the PPP<NET-#> prompt.
Add [C]
Adds an entry to the tables of PAP passwords and CHAP secrets that the router uses during authentication. The local router uses the remote router's name to search these tables to find the corresponding password or secret that authenticates connections from that router. The router also uses these tables to store the password and/or secret that authenticates the local router to others.
A router name can have both a secret and a password associated with it. If you define both, the router can use either PAP or CHAP to authenticate that remote router.
The router shares the table of passwords and secrets among all PPP interfaces. Once you enter a password or secret, it is available to all interfaces.
To modify an existing password or secret, use the change command
The local router, if the local router needs to use PAP to identify itself to other routers.
All remote routers that the local router must authenticate using PAP.
add password
Router name []? GT70remote1
Router password []? remotepw
Circuit Config <NET-#> prompt. The local router uses the secret you define for the destination address name if it cannot find a secret for the name in the remote router's CHAP challenge packet.
Example: add secret
Router name []? GT70remote1
Router secret []? remotesecret
change password
Router name []?mygt70
Router password []?rtc
change secret
Router name []?remote70
Router secret []?wilder
clear
You no longer want to allow the remote router to communicate with the local router.
You no longer want the local router to provide a password to other routers. You control this by removing (or never adding) a password for the local router's name.
delete password
Router name []? GT70remote
delete secret
Router name []? GT70remote
disable call-back
disable ccp
disable chap answering-calls
disable chap originating-calls
disable mp
disable pap answering-calls
disable echo
Example:
enable call-back accept ccp
Enables the Compression Control Protocol (CCP) on this interface.
Example: enable ccp chap answering-calls
Enables the local router to require CHAP authentication from a remote router when the local router answers a call. This is the typical use of CHAP.
Example: enable chap answering-calls chap originating-calls
Enables the local router to require CHAP authentication from a remote router when the local router places a call. Normally, you would not enable this option because the local router identifies the remote router by the telephone number that the local router calls.
Example: enable chap originating-calls mp
Enables Multilink PPP (MP) on this interface. Enabling MP causes the local router to initiate MP negotiation in LCP Configure Request packets.
Example: enable mp pap answering-calls
Enables the local router to require PAP authentication from a remote router when the local router answers a call. This option is disabled by default.
Example: enable pap answering-calls echo
Enables sending LCP maintenance packets. This helps the local router to verify that the remote router is functioning properly.
Example: enable echo Exit [C] [M]
Returns to the previous prompt.
Syntax: exit
exit
PPP Config <NET-#> prompt and the PPP <NET-#> prompt.
PPP Config <NET-#> prompt, list displays information related to the PPP interface and its protocol parameters and options.
Syntax: list
list all
LCP Parameters
--------------
Config Request Tries: 10 Config Nak Tries: 5
Terminate Tries: 2 Retry Timer: 3000
Callback Mode: Accept Callback Delay: 600LCP Options
-----------
Max Receive Unit: 1500 Magic Number: No
Async Control Char. Map(ACCM): 0
Protocol Field Comp(PFC): Yes Addr/Cntl Field Comp(ACFC): Yes
Echo Requests: DISABLEDCHAP Parameters
---------------
CHAP on Call Answer: Enabled
CHAP on Call Originate: Disabled
Local Name: gt70local
Challenge tries: 10
Challenge timeout(mSec): 15000
Response timeout(mSec): 3000
Challenge Algorithm:RSA Data Security,Inc. MD5 Message-Digest AlgorithmCHAP Secrets
Router Secret
------ ------
boise etcPAP Parameters
--------------
PAP on Call Answer: Enabled
Local Name: gt70local
Local Password: localpw
Max Request Timeouts: 20
Request Timeout(mSec): 15000
Retry Timout(mSec): 3000PAP Passwords
Router Password
------ --------
local localpassword
my_gt70 localpassword
remoterouter remotepassword
mygt70 xxx
gt70local localpwNCP Parameters
---------------
Config Request Tries: 20 Config Nak Tries: 10
Terminate Tries: 10 Retry Timer: 3000
IPCP Options
------------
RTP Header Compression: IPHC Format
Compression Slots: 256
TCP Header Compression: IPHC Format
Compression Slots: 20
IP Address: Send, Request
Multilink PPP Configuration
---------------------------
MP: Enabled
Initial MP bundle size: 2
Maximum MP bundle size: 2
Discriminator: Default
Sequence Number Length: Long
Bandwidth-on-Demand: Off
High-Utilization Threshold: 70%
Low-Utilization Threshold: 35%CCP Options
-----------
Data Compression enabled
Algorithm list: Stac-LZS
Stac: histories 1
Stac: check_mode SEQ
bncp
Lists the Bridging Network Control Protocol (BNCP) options.
Example: list bncp
BNCP Options
------------
Tinygram Compression: DISABLED
list ccp
CCP Options
-----------
Data Compression enabled
Algorithm list: Stac-LZS
Stac: histories 1
Stac: check_mode SEQ
list chap
CHAP Parameters
---------------
CHAP on Call Answer: Enabled
CHAP on Call Originate: Enabled
Local Name: gt70local
Challenge tries: 10
Challenge timeout(mSec): 15000
Response timeout(mSec): 3000
Challenge Algorithm:RSA Data Security,Inc. MD5 Message-Digest Algorithm
list ipcp
IPCP Options
------------
RTP Header Compression: IPHC Format
Compression Slots: 256
TCP Header Compression: IPHC Format
Compression Slots: 20
IP Address: Send, Request
list lcp
LCP Parameters
--------------
Config Request Tries: 10 Config Nak Tries: 5
Terminate Tries: 2 Retry Timer: 3000
Callback Mode: Accept Callback Delay: 600LCP Options
-----------
Max Receive Unit: 1500 Magic Number: No
Async Control Char. Map(ACCM): 0
Protocol Field Comp(PFC) Yes Addr/Cntl Field Comp(ACFC) Yes
Echo Requests: DISABLED
list mp
Multilink PPP Configuration
---------------------------
MP: Enabled
Initial MP bundle size: 1
Maximum MP bundle size: 2
Discriminator: Default
Sequence Number Length: Long
Bandwidth-on-Demand: Fast
High-Utilization Threshold: 70%
Low-Utilization Threshold: 35%
list pap
PAP Parameters
--------------
PAP on Call Answer: Enabled
Local Name: gt70local
Local Password: localpw
Max Request Timeouts: 20
Request Timeout(mSec): 15000
Retry Timout(mSec): 3000
list parameters
NCP Parameters
---------------
Config Request Tries: 10 Config Nak Tries: 5
Terminate Tries: 2 Retry Timer: 3000
list password
PAP Passwords
Router Password
------ --------
gt70local localpw
list secret
CHAP Secrets
Router Secret
------ ------
gt70remote sample secret
list all
list ap2
AP2 Statistic In Out
------------ -- ---
Packets: 349 351
Octets: 128488 129412
Prot Rejects: 0
list atcp
ATCP Statistic In Out
--------------- -- ---
Packets: 0 0
Octets: 0 0
Prot Rejects: 0 -
list bacp
BACP Statistic In Out
------------- -- ---
Packets: 2 2
Octets: 20 20
Prot Rejects: 0 -
list bncp
BNCP Statistic In Out
--------------- -- ---
Packets: 0 0
Octets: 0 0
Prot Rejects: 0 -
list ccp
CCP Statistic In Out
------------- -- ---
Packets: 746703 746703
Octets: 4480326 4480326
Reset Reqs: 120 72
Reset Acks: 72 120
Prot Rejects: 0 -
Max size of transmit compression dictionary: 8398
Local (transmit) compressor: Stac-LZS
Local (transmit) compressor statistics:
Recent compression ratio: 2.1:1
Size of receive decompression dictionary: 4424
Remote (receive) compressor: Stac-LZS
Remote (receive) decompressor statistics:
Recent compression ratio: 1.6:1
list chap
CHAP Statistics In Out
--------------- -- ---
Packets: 6 14
Octets: 130 801
Challenges: 0 8
Responses: 6 0
Successes: 0 4
Failures: 0 2
list compression
Compression Statistic In Out
--------------------- -- ---
Packets: 0 0
Octets: 0 0
Compressed Octets: 0 0
Incompressible Packets: 0 0
Discarded Packets: 0 0
Copied Packets: 0 0
Prot Rejects: 0 -
list control atcp
ATCP State: Closed
Previous State: Closed
Time Since Change: 6 hours, 27 minutes and 7 seconds
AppleTalk Address Info:
Common network number = 12
Local node ID = 49
Remote node ID = 76
BACP State: Open
Previous State: Ack Sent
Time Since Change: 21 minutes and 53 seconds
BACP Option Local Remote
___________ _____ ______
Favored Peer: 0xFFFFFFFF 0x1
|
BACP Option
| |
|
Favored Peer
| During the negotiation phase of BACP, a favored peer is determined. The favored peer is the originator of the first call. |
BNCP State: Closed
Previous State: Closed
Time Since Change: 5 hours, 25 minutes and 3 seconds
BNCP Option Local Remote
----------- ----- ------
Tinygram Compression DISABLED DISABLED
Source-route Info:
Remote side does not support source-route bridging
CCP State: Open
Previous State: Ack Sent
Time Since Change: 43 seconds
Local (transmit) compressor: Stac-LZS histories 1, check_mode SEQ
Remote (receive) compressor: Stac-LZS histories 1, check_mode SEQ
list control chap
CHAP Option
-----------
CHAP on Call Answer: Enabled
CHAP on Call Originate: Enabled
Local Name: gt70-2
Remote Router Name: gt70-1
Max Challenges: 20
Challenge timeout 15000
Response timeout 3000
Challenge Algorithm:RSA Data Security,Inc. MD5 Message-Digest Algorithm
CHAP State: Opened
Previous State: Success Sent
Time Since Change: 1 minute and 28 seconds
list control ipcp
IPCP State: Open
Previous State: Ack Rcvd
Time Since Change: 23 hours, 34 minutes, and 34 secondsIPCP Option Local Remote
----------- ----- ------
IP Address 20.20.20.1 20.20.20.2
TCP header comp slots 20 20 (IPHC Format)
RTP header comp slots 256 256 (IPHC Format)
Max period between FH 256 256 Comp Packets
Max time between FH 5 5 Seconds
Max compressible header 168 168 Bytes
IPXCP State: Closed
Previous State: Closed
Time Since Change: 2 hours, 9 minutes and 2 seconds
list control lcp
Version: 1
LCP State: Listen
Previous State: Req Sent
Time Since Change: 8 seconds
LCP Option Local Remote
---------- ----- ------
Max Receive Unit: 2048 1500
Async Control Char Map: FFFFFFFF FFFFFFFF
Authentication: CHAP CHAP
Magic Number: B87DA37F None
Echo Requests: DISABLED
Protocol Compr: No No
Addr/Cntl Compr: No No
Link Discriminator: 1 1
32-Bit Checksum: No No
Breakdown per LCP
-----------------
LCP 1:
------
Version: 1
Time Since Change: 1 minute and 21 seconds
MP Option Local Remote
--------- ----- ------
Max Rcv Recon Units: 2048 2048
Discriminator: class: 1 class: 0
addr: 0114872C addr