Configuring PPP negotiation
PPP negotiation parameters that can be configured are as follows:
Negotiation timeout time
IP address negotiation
DNS address negotiation
ACCM negotiation
ACFC negotiation
PFC negotiation
Configuring the PPP negotiation timeout time
Negotiation timeout time determines the interval for sending request packets. During PPP negotiation, if no response is received from the peer during a specific period after the local device sends a packet, the device sends the packet again. The period is known as negotiation timeout time, which is in the range of 1 to 10 seconds.
To configure the PPP negotiation timeout time:
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter interface view. | interface interface-type interface-number | N/A |
3. Configure the negotiation timeout time. | ppp timer negotiate seconds | Optional. 3 seconds by default. |
Configuring IP address negotiation
IP address negotiation can be implemented in the following two modes:
The router operating as the client—This mode applies when a local interface uses PPP as its link layer protocol but does not have an IP address, whereas the peer is configured with an IP address and with an address pool. In this mode, the interface accepts an IP address allocated by its peer. This mode is used for situations where the router accesses the Internet through an ISP.
The router operating as the server—In this mode, you must configure a local IP address pool in domain view or system view to specify the range of the IP addresses to be allocated, and then bind the address pool to the interface in interface view.
To configure the local end as the client:
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter interface view. | interface interface-type interface-number | N/A |
3. Enable IP address negotiation. | ip address ppp-negotiate | N/A |
To configure the local end as the server when PPP authentication is not enabled:
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Assign an IP address of a global address pool to the peer or specify the IP address to be allocated to the peer. |
| Use either method. As for the remote address pool command, if the pool-number argument is not provided, the global address pool numbered 0 is used. |
To configure the local end as the server when PPP authentication is enabled:
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter ISP domain view. | domain domain-name | N/A |
3. Define the domain address pool. | ip pool pool-number { low-ip-address [ high-ip-address ] | remote server-ip-address } | You must define an address pool in a specified domain at the time of PPP authentication. |
4. Return to system view. | quit | N/A |
5. Enter interface view. | interface interface-type interface-number | N/A |
6. Specify the address pool for IP address allocation. | remote address pool [ pool-number ] | If you configure the remote address pool command without providing the pool-number argument, all the address pools in the domain are used in ascending order of pool number for IP address allocation. |
7. Disable the peer end from using the locally configured IP address. | ppp ipcp remote-address forced | Optional. By default, the peer end is allowed to use the locally configured IP address. In this case, the local end does not allocate an IP address to the peer end if the latter already has an IP address. |
Configuring DNS server IP address negotiation
PPP address negotiation can also determine the DNS server IP address. You can configure a device to allocate the DNS server IP address to the peer or receive the DNS server IP address from the peer. For a PPP link between a host and a device, the DNS server IP address is allocated by the device so that the host can access the Internet directly using domain names. For a PPP link established between a device and the access server of a carrier, the DNS server IP address is usually allocated by the access server so that the device can resolve domain names by using the allocated address.
Configure DNS server settings depending on the role of your device in PPP negotiation.
Configuring the local end as the client
To configure settings for DNS server IP address negotiation when the device is functioning as the client in PPP negotiation:
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter interface view. | interface interface-type interface-number | N/A |
3. Enable the local end to request the peer for a DNS server IP address. | ppp ipcp dns request | By default, a device does not request its peer for a DNS server IP address. |
4. Enable the local end to accept the DNS server IP address assigned by the peer. | ppp ipcp dns admit-any | Optional. By default, a device does not accept the DNS server IP address assigned by the peer. |
![[NOTE: ]](images/note.png) | NOTE: The server will specify a DNS server IP address for a client in PPP negotiation only after the client is configured with the ppp ipcp dns request command. For some special devices to forcibly specify DNS server IP addresses for clients that dot not initiate requests, you must configure the ppp ipcp dns admit-any command on these devices. | |
Configuring the local end as the server
To configure settings for DNS server IP address negotiation when the device is functioning as the server in PPP negotiation:
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter interface view. | interface interface-type interface-number | N/A |
3. Enable the local end to assign a DNS server IP address to the peer. | ppp ipcp dns primary-dns-address [ secondary-dns-address ] | By default, a device does not assign a DNS server IP address to the peer. The server specifies a DNS server IP address for a client only after receiving a request from the client. |
Configuring ACCM negotiation
The escape mechanism is implemented to transparently transmit asynchronous control characters on asynchronous links. This is to avoid payloads being treated as control characters when the payloads contain the same characters as the control characters. The length of each asynchronous control character is 1 byte. PPP uses the escape mechanism to map all 1-byte asynchronous control characters into 2-byte characters. This increases the bandwidth consumed by asynchronous control characters and as a result reduces effective payload bandwidth.
The ACCM configuration option provides a method to negotiate the use of control character transparency on asynchronous links. The ACCM field contains 32 bits numbered 1 to 32 from left to right. Each bit corresponds to an asynchronous control character numbered the same. If the value of a bit is 0, the system does not escape the corresponding asynchronous control character. If the value of a bit is 1, the system escapes the corresponding asynchronous control character by prefacing it with a backslash (\). For example, if the value of the bit numbered 19 is 0, the asynchronous control character numbered 19 (DC3, Control-S) will be sent without being escaped.
ACCM negotiation is implemented at the LCP negotiation phase. After ACCM negotiation is completed, the peer escapes asynchronous control characters according to the Async Control Character Mappings when sending packets.
By default, the ACCM field takes the value of 0x000A0000. To reduce the bandwidth consumed by asynchronous control characters and increase effective payload bandwidth on low-rate links, set the ACCM field to 0x0 (the system does not escape asynchronous control characters).
To configure ACCM negotiation:
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter interface view. | interface interface-type interface-number | N/A |
3. Configure the ACCM value. | ppp accm hex-number | Optional. By default, the ACCM value is 0x000A0000. |
| NOTE: ACCM negotiation applies only on asynchronous links. | |
Configuring ACFC negotiation
By default, in a PPP packet, the address field is fixed to 0xFF, and the control field is fixed to 0x03. The fixed values make it easy to compress these two fields.
ACFC negotiation notifies the peer that the local end can receive packets carrying compressed address and control fields.
ACFC negotiation is implemented at the LCP negotiation stage. After the ACFC negotiation is completed, the device compresses the address and control fields of non-LCP packets before sending them out, and does not add address and control fields to them, thus increasing effective payload bandwidth on the link. To ensure successful LCP negotiation, do not apply the compression to LCP packets.
Hewlett Packard Enterprise recommends that you use the ACFC configuration option on low-speed links.
Configuring the local end to send ACFC requests
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter interface view. | interface interface-type interface-number | N/A |
3. Configure the local end to send ACFC requests, that is, to include the ACFC option in its outbound LCP negotiation requests. | ppp acfc local request | By default, the local end does not include the ACFC option in its outbound LCP negotiation requests. |
Configuring how the local end handles the ACFC requests received from the peer
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter interface view. | interface interface-type interface-number | N/A |
3. Configure how the local end handles the ACFC requests received from the peer. |
| Optional. By default, the local end accepts the ACFC requests from the remote peer, but does not perform ACFC on frames sent to the peer. |
Configuring PFC negotiation
By default, the length of the protocol field in a PPP packet is 2 bytes. Because data protocols are typically assigned protocol field values less than 256, the PPP protocol field can be compressed from 2 bytes to 1 byte to indicate protocol types.
PFC negotiation notifies the peer that the local end can receive the packets with single-byte protocol fields.
PFC negotiation is implemented at the LCP negotiation stage. After PFC negotiation is completed, the device compresses the protocol fields of non-LCP packets before sending them out. If the first 8 bits of the protocol field are all zeros, the device does not add them, thus increasing effective payload bandwidth on the link. To ensure successful LCP negotiation, the compression does not apply to LCP packets.
Hewlett Packard Enterprise recommends that you use this configuration option on low-speed links.
Configuring the local end to send PFC requests
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter interface view. | interface interface-type interface-number | N/A |
3. Configure the local end to send PFC requests, that is, to include the PFC option in its outbound LCP negotiation requests. | ppp pfc local request | By default, the local end does not include the PFC option in its outbound LCP negotiation requests. |
Configuring how the local end handles the PFC requests received from the peer
Step | Command | Remarks |
|---|---|---|
1. Enter system view. | system-view | N/A |
2. Enter interface view. | interface interface-type interface-number | N/A |
3. Configure how the local end handles the PFC requests received from the peer. |
| Optional. By default, the device accepts PFC requests received from the peer, but does not perform PFC on frames sent to the peer. |