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.
PPP Data Link Layer Frame Structure
PPP transmits data frames that have the same structure as High-level Data Link Control (HDLC) frames. PPP uses a bit-oriented, synchronous transmission method with a single-frame format for all data and control exchanges.
Figure 14 illustrates the PPP frame structure and a description of each field follows.
| Field | Definition |
|---|---|
| Flag |
The flag field begins and ends each frame with a unique pattern of 01111110. Generally a single flag ends one frame and begins the next. All active stations attached to the link continuously search for the flag sequence to synchronize the start of the next frame. The sending and receiving stations use a process called bit stuffing to avoid the loss of synchronization due to the arbitrary appearance of the 01111110 bit pattern within the data stream. When bit stuffing, the sending station adds a 0 after the fifth 1 in a non-flag bit stream. Then the receiving station monitors the bit stream. If the receiver detects a bit pattern of five ones, it examines the sixth bit. If the sixth bit is a 0, the receiver deletes it. If the sixth bit is a 1 and the seventh bit is a 0, the receiver accepts the combination as the end of frame flag. |
| Address | The address field is a single octet (8 bits) and contains the binary sequence 11111111 (0xff hexadecimal). This is known as the All-Station Address. PPP does not assign individual station addresses. |
| Control | The control field is a single octet and contains the binary sequence 00000011 (0x03 hexadecimal). This sequence identifies the Unnumbered Information (UI) command with the P/F bit set to zero. |
| Protocol |
PPP defines the protocol field; it is not found in the true HDLC frame format. The protocol field is 2 octets (16 bits) and its value identifies the protocol datagram encapsulated in the Information field of the frame. Protocol field values in the "cxxx" range indicate that datagrams belong to the Link Control Protocol (LCP). Values in the "8xxx" range indicate that datagrams belong to the Network Control Protocols (NCP). Values in the "0xxx" and "2xxx" range identify the network protocol of IP datagrams and IP header compression format as specified in RFCs 2507 and 2509. |
| Information |
The information field contains the datagram for the protocol specified in the protocol field. This is zero or more octets. This information field is present for all I-frames and only some U-frames. When the protocol type is LCP, exactly one LCP packet is encapsulated in the information field of PPP data link layer frames. |
| Frame Check Sequence (FCS) | The frame check sequence field is a 16-bit Cyclic Redundancy Check (CRC). |
Link Establishment Packet. Establishes and configures a link.
Link Termination Packet. Terminates a link.
Link Maintenance Packet. Manages and debugs a link.
Figure 15 illustrates the structure of the LCP packet and a description of each field follows.
Figure 15 LCP Frame Structure
Code
The code field is one octet in length and identifies the
type of LCP packet. The codes in Table 13 distinguish
the packet types. They are described in more detail in later sections.
Table 13 LCP Packet Codes
Code
Packet Type
1
Configure-Request (Link Establishment)
2
Configure-ACK (Link Establishment)
3
Configure-NAK (Link Establishment)
4
Configure-Reject (Link Establishment)
5
Terminate-Request (Link Termination)
6
Terminate-ACK (Link Termination)
7
Code-Reject (Link Termination)
8
Protocol-Reject (Link Maintenance)
9
Echo-Request (Link Maintenance)
10
Echo-Reply (Link Maintenance)
11
Discard-Request (Link Maintenance)
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 14.
| NCP | Specified in RFC . . . | OpenROUTE Software supports . . . |
|---|---|---|
| AppleTalk Control Protocol (ATCP) | 1378 |
The AppleTalk-Address option. The AppleTalk packet is encapsulated in the Information field of the PPP data frame. The encapsulated AppleTalk packet begins with an extended Datagram Delivery Protocol (DDP) header. |
| Bandwidth Allocation Control Protocol (BACP) | 2125 | Bandwidth Allocation Control Protocol (BACP) manages bandwidth between two peers on a point-to-point link. See BAP and BACP. |
| Bridging Network Control Protocol (BNCP) | 1220 | The IEEE 802.5 Line Identification Option and the Tinygram Compression Option. |
| IP Control Protocol (IPCP) | All IPCP options. They are | |
| IPX Control Protocol (IPXCP) | 1552 |
Does not send any IPXCP options. However, it accepts the following IPXCP options if the remote router sends them:
|
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 use MP, enter the enable mp PPP configuration command. MP has several other configuration commands:| To set the . . . | Use this command . . . |
|---|---|
| Endpoint Discriminator (EID) value that identifies the MP bundles that this peer creates. | set mp discriminator |
| Initial number of connections (or bundles) to use when OpenROUTE first makes a call to the remote router. | set mp initial-bundle-size |
|
Maximum number of connections that MP can use. The default is 2. For ISDN BRI devices, setting the maximum to 1 guarantees the remote router, when calling the local router, only gets one of the two available B channels. This is useful when the local router accesses two separate remote sites at once. |
set mp max-bundle-size |
| Sequence number header format used in the MP encapsulation header to long or short. | set mp sequence-num-len |
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.
The local router does not respond to requests to use PAP from devices calling in to the local router. Doing so poses a security risk because PAP names and passwords are transmitted in clear text. An intruder could dial in to the router, obtain the router's name and PAP password, and then use that information to pose as the router.
Using Both PAP and CHAP
If an Nx Networks router is enabled to authenticate another router using PAP and CHAP, OpenROUTE requests CHAP first and then allows the remote router to use PAP if it does not support CHAP.
3000 Series cannot fall back from CHAP to PAP when another router is the authenticator because, by PPP specification, if a router supports CHAP, and the other router asks for CHAP, the first router must use CHAP.
This may cause confusion if you configure a PAP password on the 3000 Series router and then enable the other router to authenticate using PAP and CHAP. When the other router asks for CHAP, 3000 Series complies, but PPP authentication fails because 3000 Series does not have a CHAP secret configured.
If PAP authentication is required, then the other router (of any brand) must only request PAP. 3000 Series complies and returns the PAP password that you configured.
How PAP Works
PAP is a simpler protocol than CHAP because it uses a two-way handshake and does not encrypt the password that identifies the peer to the authenticator. The PAP authentication process is as follows:
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.
The CHAP authentication process is as follows:
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.
CHAP depends on knowing the name of the remote router. The local router uses the remote router's name, which is contained in the CHAP challenge, to look up the secret that it uses to reply to the remote router. However, you may not know that name because some ISPs or network administrators provide only your account name and the CHAP secret that you must use to log into that account. They may not provide the remote router name.
OpenROUTE includes a feature that simplifies CHAP when the local router places a call to a remote router. If the local router does not know the name that the remote router sends in the CHAP challenge, the local router uses the CHAP secret configured for the dial destination.
For example, if you configure an interface with a destination of Boston, and the remote router identifies itself in its CHAP challenge with a different name that is unknown to the local router, then OpenROUTE uses the CHAP secret configured for Boston to build a CHAP response.
Therefore, if you do not know the name of the remote router,
add a CHAP secret (using the add secret command)
for the remote router's destination address name that you entered using the
set destination command at the 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.
Configuring Call-back
This feature has three separate, mutually exclusive options when you enable Call-back. The following sections describe these options. In each of the examples below, the interface you are configuring has dial-on-demand enabled by setting the idle time to a nonzero value, that is Circuit Config <NET-#> set idle 60
Request
This option causes the local router to request the remote router to call back. If the remote router agrees, then the local router hangs up the call and waits for the return call. If the remote router rejects the Call-back request, then the local router leaves the line connected as if it never requested the Call-back.
This option is useful for a telecommuter who configures a router to call an employer in order to reverse the charges back to the employer. In the following example, the remote destination router is called my-job.
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
You can use Caller-ID, PAP, or CHAP with the accept option to identify the caller.
This option supports the Internet Service Provider (ISP) who wants to connect to the local router. The ISP can request a Call-back from the local router to the ISP, my-isp, so the local router bears the cost of the call. The local router only calls back the ISP if the ISP requests a Call-back.
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
If you enable this option, you must have outbound calls enabled using 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
Character Sequence Substitution
The data compression software works by replacing frequently-occurring character sequences with single characters that represent the sequences. The sequences can be words, blank spaces, numbers, or any other string in the data stream. The substitution characters are called index characters.
For example, the character sequences that make up the words "the" and "computer" may appear separately throughout an ASCII text file in a data stream. The data compression software substitutes a single character for each of the words. Further, if the words appear together as "the computer," a different index character replaces the phrase. This substitution scheme in effect compresses the data.
Histories (Dictionaries)
Data compression histories maintain an association between each repeatedly occurring sequence and its index character. The histories must be the same at the sending and receiving routers to ensure accurate compression and decompression. Compression protocol messages implement the history coordination and the router must closely monitor the link between the routers to maintain the coordination. If a packet is lost, the history is reset. The longer you build a history, the higher the compression ratio.
Compression Protocols and Algorithms
The router implements the following data compression protocols and algorithms. The data compression software runs in the router's data link layer.
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 16.
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 16 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 17 illustrates the structure of the RTP header packet and a description of each field follows.
Figure 17 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.IP_HEADER 0x0021
COMPRESSED_TCP 0x002D
UNCOMPRESSED_TCP 0x002F
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.
Displaying the PPP Prompts
To display the PPP configuration prompt
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>
Note: If you enable a PPP interface for bridging, Nx Networks recommends that you enable Bandwidth Reservation System.
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>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>
PPP Config <NET-1>set chap local-name
Local router name? [GT70local]? gt70
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.
| Command | Function |
|---|---|
| Add [C] | Adds a PAP password or CHAP secret. |
| Change [C] | Changes a PAP password or CHAP secret. |
| Clear [M] | Clears all statistics from PPP interfaces. |
| Delete [C] | Deletes a PAP password or CHAP secret. |
| Disable [C] | Disables Call-back, Echo, Multilink PPP, PAP and CHAP, and data compression on this PPP interface. |
| Enable [C] | Enables Call-back, Echo, Multilink PPP, PAP and CHAP, and data compression on this PPP interface. |
| Exit [C] [M] | Returns to the previous prompt. |
| List [C] [M] | Lists the PPP configuration, statistics, and counters. |
| Rhc [M] | Displays information about RTP header compression. |
| Set [C] | Sets PPP parameters and the parameters and/or options for BNCP, CCP (data compression), PAP, CHAP, IPCP, LCP, and MP. |
| Thc [M] | Displays information about TCP header compression. |
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
If you do not know the name of the remote router, add a secret using 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.
Router name []? GT70remote1
Router secret []? remotesecret
Router name []?mygt70
Router password []?rtc
Router name []?remote70
Router secret []?wilder
clear
Delete [C]
Deletes a remote router's PAP password or CHAP secret. There are two reasons to delete a password or secret:
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.
Router name []? GT70remote
Router name []? GT70remote
ccp
Disables the Compression Control Protocol (CCP) on this interface.
chap answering-calls
Disables the local router from requiring CHAP authentication from a remote router when the local router answers a call.
Example: disable chap answering-calls
chap originating-calls
Disables the local router from requiring CHAP authentication from a remote router when the local router places a call.
Example: disable chap originating-calls
mp
Disables Multilink PPP (MP) on this interface. If you disable MP, the local router does not initiate MP negotiation. However, if the remote router initiates MP negotiation, the local router does negotiate MP.
pap answering-calls
Disables the local router from requiring PAP authentication from a remote router when the local router answers a call.
Example: disable pap answering-calls
echo
Disables sending LCP maintenance packets. Disabling echo may improve performance slightly.
Enable [C]
Enables data compression, CHAP and PAP, Multilink PPP, and LCP echos on this PPP interface.
Example: enable call-back accept
ccp
Enables the Compression Control Protocol (CCP) on this interface.
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.
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.
Exit [C] [M]
Returns to the previous prompt.
exit
List [C] [M]
The next sections describe the list commands available at the PPP Config <NET-#> prompt and the PPP <NET-#> prompt.
List [C]
At the PPP Config <NET-#> prompt, list displays information related to the PPP interface and its protocol parameters and options.
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
|
LCP Parameters
| |
|
Config Request Tries
| Number of times LCP sends configure-request packets to a peer station while attempting to open a PPP link. Exceeding the count halts configure-request transmission. |
|
Terminate Tries
| Number of times LCP sends terminate-request packets to a peer station to close a PPP link. Exceeding the count halts terminate-request transmission. |
|
Callback Mode
|
Displays the configuration of the Call-back feature. See Call-back Feature for a description of the modes. |
|
Config Nak Tries
| Number of times LCP sends configure-nak (nak=not acknowledged) packets to a peer station while attempting to open a PPP link. |
|
Retry Timer
| Amount of time, in milliseconds, that elapses before LCP's transmission of configure-request (to open the link) and terminate-request (to close the link) packets is timed out. This timer is the time to wait before retransmitting configure-request and terminate-request packets. |
|
Callback Delay
| Amount of time, in milliseconds, the local router waits between the hanging up of the telephone and subsequently making the call-back to the remote router. |
|
LCP Options
| |
|
Max Receive Unit
| Maximum size of the information field in a PPP frame. |
|
Magic Number
| Indicates whether the magic number loopback detection option is enabled or disabled. |
|
Async Control Char. Map ACCM
| Provides a method to negotiate the use of control characters transparently on an asynchronous link. |
|
Protocol Field Comp (PFC):
|
Indicates whether Protocol Field Compression is enabled or disabled. See Protocol Field Compression (PFC). |
|
Addr/Cntl Field Comp (ACFC)
|
Indicates whether Address/Control Field Compression is enabled or disabled. See Addr/Cntl Field Compression (ACFC). |
|
Echo Requests
| Indicates whether sending of LCP maintenance packets is enabled or disabled. Disable if running a large volume of traffic. Enable when first setting up network configuration. |
|
CHAP Parameters
| |
|
CHAP on Call Answer
| Indicates whether CHAP is enabled or disabled when answering calls. |
|
CHAP on Call Originate
| Indicates whether CHAP is enabled or disabled when originating calls. |
|
Local Name
| Name that this interface uses to identify itself to other devices. The default is the host name of the router. Otherwise, this field shows the name you entered using the set chap local-name command. |
|
Challenge Tries
| The number of times the local router, as authenticator, transmits a CHAP challenge packet. If the router does not receive a CHAP response after this number of tries, it closes the connection. The range is 1 to 100. The default is 20. |
|
Challenge Timeout (mSec)
|
Sets how long the local router, as peer, waits for a CHAP challenge packet from the remote router. When this time expires, authentication fails and the local router closes the connection. The range is 200 to 150000 milliseconds. The default is 15000. |
|
Response Timeout (mSec)
|
If the local router is the
|
|
Challenge Algorithm
| MD5 Message-Digest Algorithm. Copyright© RSA Data Security, Inc. |
|
CHAP Secrets
| Lists the CHAP secret for each router. |
|
PAP Parameters
| |
|
PAP on Call Answer
| Indicates whether PAP is enabled or disabled when the local router answers a call. |
|
Local Name
| Name that this interface uses to identify itself to other devices. The default is the host name of the router. Otherwise, this field shows the name you entered using the set pap local-name command. |
|
Local Password
| Password on the local router. This is the password that the local router sends to the remote router during PAP authentication. |
|
Max Request Timeouts
| The number of times the local router, as authenticator, waits to receive a PAP Request packet. If it does not receive a PAP request after this number of tries, it closes the connection. The range is 1 to 100. The default is 20. |
|
Request Timeout (mSec)
| How long the local router, as authenticator, waits for a PAP Request packet. This timer starts at the end of the Link Establishment phase of PPP. If the router does not receive a PAP Request packet after this timer expires, it waits again. It repeats this process until the Max Request Timeouts counter counts down to zero. The range is 200 to 150000 milliseconds. The default is 15000. |
|
Retry Timeout (mSec)
| How long the local router, as the peer, waits for a PAP ACK or NAK after it sends a PAP Request packet. When this timer expires, the local router retransmits the PAP Request. The local router keeps trying as many times as are set in the Max Request Timeouts parameter. The range is 200 to 30000 milliseconds. The default is 3000. |
|
PAP Passwords
| Lists the PAP password for each router. |
|
NCP Parameters
| |
|
Config Request Tries
| Number of times NCP sends configure-request packets to a peer station while attempting to open an NCP connection. Exceeding the count halts configure-request transmission. |
|
Terminate Tries
| Number of times NCP sends terminate-request packets to a peer station to close an NCP connection. Exceeding the count halts terminate-request transmission. |
|
Config Nak tries
| Number of times NCP sends configure-nak (nak=not acknowledged) packets to a peer station while attempting to open an NCP connection. |
|
Retry Timer
| Amount of time, in milliseconds, that elapses before NCP's transmission of configure-request (to open the link) and terminate-request (to close the link) packets is timed out. This timer is the time to wait before retransmitting configure-request and terminate-request packets. |
|
IPCP Options
| |
|
RTP Header Compression
|
Displays whether or not IPCP is using Real-Time Transport Protocol (RTP) header compression and the header compression format. Possible values are IPHC Format or None. |
|
Compression Slots
| Displays the number of configured compression slots for TCP header compression or for RTP header compression. The limit for concurrent sessions for each type of header compression is 256. Each RTP header compression session creates two TCP header compression sessions, and the two TCP header compression sessions remain open until the parent RTP header compression session is completed. |
|
TCP Header Compression
|
Displays whether or not IPCP is using TCP/IP header compression and the TCP/IP header compression format. Possible values are IPHC Format, Van Jacobson, or None.This option is automatically enabled if you enable RTP header compression. |
|
IP Address
|
Displays whether or not IPCP is configured to send the local IP address to the remote end of the link or to request the IP address from the remote end of the link. In order to properly establish the link, the software overrides the setting for sending the local IP address in two cases:
|
|
Multilink PPP Configuration
| |
|
MP
| Indicates whether Multilink PPP is enabled or disabled. |
|
Initial MP Bundle Size
| Number of MP bundle member links requested on an outbound call. |
|
Maximum MP Bundle Size
| Number of member links to accept in a bundle. This is also the limit on how many links MP can use when dynamic bandwidth allocation is enabled. |
|
Discriminator
| Indicates whether a discriminator is set to default or to be generated. |
|
Sequence Number Length
| Indicates whether the long or short sequence number header format is used in MP packets. |
|
Bandwidth-on- Demand
| Type of dynamic bandwidth allocation to be used. The choices are Off (none), Slow, Medium, and Fast. The last three choices control how quickly the local router responds to changes in bandwidth. |
|
High-Utilization Threshold
| When the average utilization of the entire Multilink bundle exceeds this threshold, MP opens another circuit to add more bandwidth. |
|
Low-Utilization Threshold
| If more than one circuit is open, when the average utilization of the entire Multilink bundle falls below this threshold, MP drops one circuit. |
|
CCP Options
| |
|
Data Compression
| Shows whether data compression is currently enabled or disabled on this interface. |
|
Algorithm list
| Displays the current compression algorithms followed by the options configured using the set ccp options command. |
|
Stac: histories
| The number of separate compression histories to maintain. The valid options are 0 and 1. |
|
Stac: check_mode
| There are three methods for detecting lost packets: LCB (Longitudinal Check Byte), CRC (Cyclical Redundancy Check), and SEQ (Sequence number). SEQ is the default. |
bncp
Lists the Bridging Network Control Protocol (BNCP) options.
BNCP Options
------------
Tinygram Compression: DISABLED
CCP Options
-----------
Data Compression enabled
Algorithm list: Stac-LZS
Stac: histories 1
Stac: check_mode SEQ
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
IPCP Options
------------
RTP Header Compression: IPHC Format
Compression Slots: 256
TCP Header Compression: IPHC Format
Compression Slots: 20
IP Address: Send, Request
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
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%
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
NCP Parameters
---------------
Config Request Tries: 10 Config Nak Tries: 5
Terminate Tries: 2 Retry Timer: 3000
PAP Passwords
Router Password
------ --------
gt70local localpw
CHAP Secrets
Router Secret
------ ------
gt70remote sample secret
ap2
Lists statistics on the AppleTalk Phase 2 (AP2) packets received and transmitted over the PPP interface.
AP2 Statistic In Out
------------ -- ---
Packets: 349 351
Octets: 128488 129412
Prot Rejects: 0
ATCP Statistic In Out
--------------- -- ---
Packets: 0 0
Octets: 0 0
Prot Rejects: 0 -
BACP Statistic In Out
------------- -- ---
Packets: 2 2
Octets: 20 20
Prot Rejects: 0 -
BNCP Statistic In Out
--------------- -- ---
Packets: 0 0
Octets: 0 0
Prot Rejects: 0 -
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
CHAP Statistics In Out
--------------- -- ---
Packets: 6 14
Octets: 130 801
Challenges: 0 8
Responses: 6 0
Successes: 0 4
Failures: 0 2
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
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
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