04-Layer 2—WAN Access Configuration Guide

HomeSupportRoutersCR16000-M SeriesConfigure & DeployConfiguration GuidesH3C CR16000-M Routers Configuration Guides-R838x-6W10104-Layer 2—WAN Access Configuration Guide
01-PPP configuration
Title Size Download
01-PPP configuration 541.36 KB

Contents

Configuring PPP·· 1

About PPP· 1

PPP protocols· 1

PPP link establishment process· 1

PPP authentication· 2

PPP for IPv4· 3

PPP for IPv6· 3

Protocols and standards· 5

PPP tasks at a glance· 5

Enabling PPP encapsulation on an interface· 6

Configuring a VT interface· 6

Creating a VT interface· 6

Restoring the default settings for the VT interface· 7

Configuring PPP authentication· 7

About PPP authentication· 7

Configuring PAP authentication· 7

Configuring CHAP authentication (authenticator name is configured) 8

Configuring CHAP authentication (authenticator name is not configured) 9

Configuring MS-CHAP or MS-CHAP-V2 authentication· 10

Configuring the polling feature· 11

Configuring a VT interface not to perform keepalive detection when the uplink traffic of PPP users is updated  12

Enabling fast reply for keepalive packets· 12

Configuring PPP negotiation· 13

Configuring the PPP negotiation timeout time· 13

Configuring IPv4 address negotiation on the client 13

Configuring IPv4 address negotiation on the server 14

Configuring IPv6 address negotiation on the server 16

Configuring a BRAS to allow a remote user to come online by using a self-configured static IP address  18

Enabling IP segment match· 19

Configuring DNS server IP address negotiation on the client 19

Configuring DNS server IP address negotiation on the server 20

Enabling PPP link quality monitoring· 20

Configuring magic number check for PPP· 21

Enabling MRU check for PPP packets· 21

Specifying that PPP users cannot come online successfully if the online requests do not carry usernames  22

Enabling PPP user blocking· 23

Enabling per-username PPP user blocking· 23

Configuration per-MAC PPP user blocking· 23

Setting the online PPP session count alarm thresholds on the device· 24

Enabling SNMP notifications for the PPP module· 25

Display and maintenance commands for PPP· 25

PPP configuration examples· 26

Example: Configuring one-way PAP authentication· 26

Example: Configuring two-way PAP authentication· 28

Example: Configuring one-way CHAP authentication· 30

Example: Specifying an IP address for the client on the server interface· 32

Example: Specifying an IP address pool on the server interface· 33

Example: Using the IP address pool associated with an ISP domain· 35

Configuring MP·· 37

About MP· 37

Benefit 37

Interface type· 37

MP tasks at a glance· 37

Configuring MP through an MP-group interface· 37

About MP-group interfaces· 37

Tasks at a glance· 37

Creating an MP-group interface· 38

Assigning a physical interface to the MP-group interface· 38

Configuring the polling feature on the MP-group interface· 38

Configuring MP parameters· 39

Restoring the default settings for the MP-group interface· 39

Configuring short sequence number header format negotiation· 40

Configuring the MP endpoint discriminator 40

Enabling SNMP notifications for MP packet loss· 41

Display and maintenance commands for MP· 42

MP configuration examples· 42

Example: Configuring an MP-group interface· 42

 

 


Configuring PPP

About PPP

Point-to-Point Protocol (PPP) is a point-to-point link layer protocol. It provides user authentication, supports synchronous/asynchronous communication, and allows for easy extension.

PPP protocols

PPP includes the following protocols:

·     Link control protocol (LCP)—Establishes, tears down, and monitors data links.

·     Network control protocol (NCP)—Negotiates the packet format and type for data links.

·     Authentication protocols—Authenticate users. Protocols include the following:

¡     Password Authentication Protocol (PAP).

¡     Challenge Handshake Authentication Protocol (CHAP).

¡     Microsoft CHAP (MS-CHAP).

¡     Microsoft CHAP Version 2 (MS-CHAP-V2).

PPP link establishment process

Figure 1 shows the PPP link establishment process.

Figure 1 PPP link establishment process

1.     Initially, PPP is in Link Dead phase. After the physical layer goes up, PPP enters the Link Establishment phase (Establish).

2.     In the Link Establishment phase, the LCP negotiation is performed. The LCP configuration options include Authentication-Protocol, Async-Control-Character-Map (ACCM), Maximum-Receive-Unit (MRU), Magic-Number, Protocol-Field-Compression (PFC), Address-and-Control-Field-Compression (ACFC), and MP.

¡     If the negotiation fails, LCP reports a Fail event, and PPP returns to the Dead phase.

¡     If the negotiation succeeds, LCP enters the Opened state and reports an Up event, indicating that the underlying layer link has been established. At this time, the PPP link is not established for the network layer, and network layer packets cannot be transmitted over the link.

3.     If authentication is configured, the PPP link enters the Authentication phase, where PAP, CHAP, MS-CHAP, or MS-CHAP-V2 authentication is performed.

¡     If the client fails to pass the authentication, LCP reports a Fail event and enters the Link Termination phase. In this phase, the link is torn down and LCP goes down.

¡     If the client passes the authentication, LCP reports a Success event.

4.     If a network layer protocol is configured, the PPP link enters the Network-Layer Protocol phase for NCP negotiation, such as IPCP negotiation and IPv6CP negotiation.

¡     If the NCP negotiation succeeds, the link goes up and becomes ready to carry negotiated network-layer protocol packets.

¡     If the NCP negotiation fails, NCP reports a Down event and enters the Link Termination phase.

If the interface is configured with an IP address, the IPCP negotiation is performed. IPCP configuration options include IP addresses and DNS server IP addresses. After the IPCP negotiation succeeds, the link can carry IP packets.

5.     After the NCP negotiation is performed, the PPP link remains active until either of the following events occurs:

¡     Explicit LCP or NCP frames close the link.

¡     Some external events take place (for example, the intervention of a user).

PPP authentication

PPP supports the following authentication methods:

PAP

PAP is a two-way handshake authentication protocol using the username and password. PAP sends username/password pairs in plain text over the network. If authentication packets are intercepted in transit, network security might be threatened. For this reason, it is suitable only for low-security environments.

CHAP

CHAP is a three-way handshake authentication protocol.

CHAP transmits usernames but not passwords over the network. It transmits the result calculated from the password and random packet ID by using the MD5 algorithm.

CHAP is more secure than PAP. The authenticator may or may not be configured with a username. As a best practice, configure a username for the authenticator, which makes it easier for the peer to verify the identity of the authenticator.

MS-CHAP

MS-CHAP is a three-way handshake authentication protocol. MS-CHAP differs from CHAP in that MS-CHAP provides authentication retry. If the peer fails authentication, it is allowed to retransmit authentication information to the authenticator for reauthentication. The authenticator allows a peer to retransmit a maximum of three times.

MS-CHAP-V2

MS-CHAP-V2 is a three-way handshake authentication protocol.

MS-CHAP-V2 differs from CHAP as follows:

·     MS-CHAP-V2 provides two-way authentication by piggybacking a peer challenge on the Response packet and an authenticator response on the Acknowledge packet.

·     MS-CHAP-V2 supports authentication retry. If the peer fails authentication, it is allowed to retransmit authentication information to the authenticator for reauthentication. The authenticator allows a peer to retransmit a maximum of three times.

·     MS-CHAP-V2 supports password change. If the peer fails authentication because of an expired password, it will send the new password entered by the user to the authenticator for reauthentication.

PPP for IPv4

On IPv4 networks, PPP negotiates the IP address and DNS server address during IPCP negotiation.

IP address negotiation

IP address negotiation enables one end to assign an IP address to the other.

An interface can act as a client or a server during IP address negotiation:

·     Client—Obtains an IP address from the server. Use the client mode when the device accesses the Internet through an ISP.

·     Server—Assigns an IP address to the client. Before you configure the IP address of the server, you must perform one of the following tasks:

¡     Configure a local address pool and associate the pool with the ISP domain.

¡     Specify an IP address or an IP address pool for the client on the interface.

When IP address negotiation is enabled on a client, the server selects an IP address for the client in the following sequence:

1.     If the AAA server configures an IP address or address pool for the client, the server selects that IP address or an IP address from the pool. The IP address or address pool is configured on the AAA server instead of the PPP server. ‍For information about AAA, see BRAS Services Configuration Guide.

2.     If an address pool is associated with the ISP domain used during client authentication, the server selects an IP address from the pool.

3.     If an IP address or address pool is specified for the client on the interface of the server, the server selects that IP address or an IP address from that pool.

DNS server address negotiation

IPCP negotiation can determine the DNS server IP address.

When the device is connected to a host, configure the device as the server to assign the DNS server IP address to the host.

When the device is connected to an ISP access server, configure the device as the client. Then, the device can obtain the DNS server IP address from the ISP access server.

PPP for IPv6

On IPv6 networks, PPP negotiates only the IPv6 interface identifier instead of the IPv6 address and IPv6 DNS server address during IPv6CP negotiation. All authentication users have to obtain IPv6 global unicast addresses and IPv6 DNS server addresses by using ND or DHCPv6 protocols.

IPv6 address assignment

A host can get an IPv6 global unicast address through the following methods:

·     NDRA—The host obtains an IPv6 prefix in an RA message. The host then generates an IPv6 global unicast address by combining the IPv6 prefix and the negotiated IPv6 interface identifier. The IPv6 prefix in the RA message is determined in the following sequence:

a.     IPv6 prefix authorized by an AAA server through the Framed-IPv6-Prefix attribute.

b.     IPv6 prefix authorized in an ISP domain.

c.     Prefix in the ND prefix pool authorized in an ISP domain.

d.     Prefix in the 128-bit IPv6 global unicast address authorized by an AAA server through the Framed-IPv6-Address attribute. If an interface identifier has been authorized by an AAA server through the Framed-Interface-Id attribute, skip this step and go to step f.

e.     Prefix in the 128-bit IPv6 global unicast address authorized by using the authorization-attribute ipv6 command in local user view. If an interface identifier has been authorized by an AAA server through the Framed-Interface-Id attribute, skip this step and go to step f.

f.     RA prefix configured on the interface.

g.     Prefix in the IPv6 global unicast address configured on the interface.

The negotiated IPv6 interface identifiers are determined in the following sequence:

a.     Interface identifier authorized by an AAA server through the Framed-Interface-Id attribute.

b.     Interface identifier in the 128-bit IPv6 global unicast address authorized by an AAA server through the Framed-IPv6-Address attribute. If an IPv6 prefix has been authorized by an AAA server through the Framed-IPv6-Prefix attribute, skip this step and go to step d.

c.     Interface identifier in the 128-bit IPv6 global unicast address authorized by using the authorization-attribute ipv6 command in local user view. If an IPv6 prefix has been authorized by an AAA server through the Framed-IPv6-Prefix attribute, skip this step and go to step d.

d.     Interface identifier automatically generated for the PPP user when the ipv6cp assign-interface-id command is executed in an ISP domain.

e.     Non-zero interface identifier that is carried by the user and does not conflict with any other interface identifier.

f.     Interface identifier automatically generated for the PPP user when the interface identifier carried by the user is invalid.

The ND prefix pool authorized by AAA and the IA_NA method are mutually exclusive. For information about the ND protocol, see Layer 3—IP Services Configuration Guide.

·     DHCPv6 (IA_NA)—The host requests an IPv6 global unicast address through DHCPv6. The server assigns an IPv6 address to the host from the address pool authorized by AAA. If no AAA-authorized address pool exists, DHCPv6 uses the address pool that matches the server's IPv6 address to assign an IPv6 address to the host. For information about DHCPv6, see BRAS Services Configuration Guide.

After an IPv6 address pool is authorized to users, IA_NA also supports authorizing the specified 128-bit IPv6 global unicast addresses to PPP users through the following methods:

¡     Authorizing 128-bit IPv6 global unicast addresses by an AAA server through the Framed-IPv6-Address attribute.

¡     Authorizing 128-bit IPv6 global unicast addresses by using the authorization-attribute ipv6 command in local user view.

Make sure the 128-bit IPv6 global unicast addresses authorized by using the two methods above are within the authorized IPv6 address pool. Otherwise, the 128-bit IPv6 global unicast addresses authorized by using the two methods above are not used, and IPv6 addresses in the IPv6 address pool are randomly allocated to users.

·     DHCPv6 (IA_PD)—A client-side device requests prefixes through DHCPv6 and assigns them to downstream hosts. The hosts then use the prefixes to generate global IPv6 addresses. This method uses the same principle of selecting address pools as the DHCPv6 (IA_NA) method.

The device can assign a host an IPv6 address in either of the following ways:

·     When the host connects to the device directly or through a bridge device, the device can use the NDRA method or the IA_NA method.

·     When the host accesses the device through a router, the device can use the IA_PD method to assign an IPv6 prefix to the router. The router assigns the prefix to the host to generate an IPv6 global unicast address.

·     You can use the NDRA+IA_PD combination or the IA_NA+IA_PD combination as needed to meet address assignment requirements in different scenarios.

IPv6 DNS server address assignment

On IPv6 networks, two methods are available for the IPv6 DNS server address assignment:

·     The client obtains the IPv6 DNS server address from the DNS server options carried in ND RA packets. The DNS server option carried in RA packets can be authorized by AAA or configured by using the ipv6 nd ra dns server command on an interface. If both the IPv6 DNS server option authorized by AAA and the IPv6 DNS server option configured on an interface are available, the RA packets carry both options, with the AAA-authorized one in the front. If the two options conflict, the AAA-authorized one applies. For more information about the ipv6 nd ra dns server command, see Layer 3—IP Services Command Reference.

·     The DHCPv6 client requests an IPv6 DNS server address from the DHCPv6 server.

Protocols and standards

RFC 1661: The Point-to-Point Protocol (PPP)

PPP tasks at a glance

To configure PPP, perform the following tasks:

1.     Enabling PPP encapsulation on an interface

2.     Configuring a VT interface

¡     Creating a VT interface

In a PPPoE or L2TP network, you must configure VT interfaces. For more information about PPPoE and L2TP, see BRAS Services Configuration Guide.

¡     (Optional.) Restoring the default settings for the VT interface

3.     Configuring PPP authentication

Choose one of the following tasks:

¡     Configuring PAP authentication

¡     Configuring CHAP authentication (authenticator name is configured)

¡     Configuring CHAP authentication (authenticator name is not configured)

¡     Configuring MS-CHAP or MS-CHAP-V2 authentication

Configure PPP authentication for high-security environments.

4.     (Optional.) Configuring the polling feature

5.     (Optional.) Configuring a VT interface not to perform keepalive detection when the uplink traffic of PPP users is updated

6.     (Optional.) Enabling fast reply for keepalive packets

7.     (Optional.) Configuring PPP negotiation

¡     Configuring the PPP negotiation timeout time

¡     Configuring IPv4 address negotiation on the client

¡     Configuring IPv4 address negotiation on the server

¡     Configuring IPv6 address negotiation on the server

¡     Configuring a BRAS to allow a remote user to come online by using a self-configured static IP address

¡     Enabling IP segment match

¡     Configuring DNS server IP address negotiation on the client

¡     Configuring DNS server IP address negotiation on the server

8.     (Optional.) Enabling PPP link quality monitoring

9.     (Optional.) Configuring magic number check for PPP

10.     (Optional.) Enabling MRU check for PPP packets

11.     (Optional.) Specifying that PPP users cannot come online successfully if the online requests do not carry usernames

12.     (Optional.) Enabling PPP user blocking

¡     Enabling per-username PPP user blocking

¡     Configuration per-MAC PPP user blocking

13.     (Optional.) Setting the online PPP session count alarm thresholds on the device

14.     (Optional.) Enabling SNMP notifications for the PPP module

Enabling PPP encapsulation on an interface

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Enable PPP encapsulation on the interface.

link-protocol ppp

By default, all interfaces except Ethernet interfaces and VLAN interfaces use PPP as the link layer protocol.

Configuring a VT interface

Creating a VT interface

About VT interfaces

Virtual-template (VT) interfaces are logical interfaces manually created on devices. A VT interface can implement the functionality of a physical WAN interface with PPP encapsulation enabled.

In PPPoE and L2TP applications, you can use VT interfaces to implement related functions of PPP. For more information about PPPoE and L2TP, see "Configuring PPPoE" and "Configuring L2TP."

Procedure

1.     Enter system view.

system-view

2.     Create a VT interface and enter its view.

interface virtual-template number

3.     (Optional.) Set the interface description.

description text

By default, the description of a VT interface is interface name Interface, for example, Virtual-Template1 Interface.

4.     (Optional.) Set the MTU size of the interface.

mtu size

By default, the MTU of a VT interface varies by interface card.

5.     (Optional.) Set the expected bandwidth of the VT interface.

bandwidth bandwidth-value

By default, the expected bandwidth (in kbps) is the interface baud rate divided by 1000.

Restoring the default settings for the VT interface

Restrictions and guidelines

The default command might interrupt ongoing network services. Make sure you are fully aware of the impact of this command when you execute it on a live network.

The default command might fail to restore the default settings for some commands for reasons such as command dependencies or system restrictions. Use the display this command in interface view to identify these commands. Use the undo forms of these commands or follow the command reference to individually restore their default settings. If your restoration attempt still fails, follow the error message instructions to resolve the problem.

Procedure

1.     Enter system view.

system-view

2.     Enter VT interface view.

interface virtual-template number

3.     Restore the default settings for the interface.

default

Configuring PPP authentication

About PPP authentication

You can configure several authentication modes simultaneously. In LCP negotiation, the authenticator negotiates with the peer in the sequence of configured authentication modes until the LCP negotiation succeeds. If the response packet from the peer carries a recommended authentication mode, the authenticator directly uses the authentication mode if it finds the mode configured.

Configuring PAP authentication

Restrictions and guidelines for PAP authentication

For local AAA authentication, the username and password of the peer must be configured on the authenticator.

For remote AAA authentication, the username and password of the peer must be configured on the remote AAA server.

The username and password configured for the peer must be the same as those configured on the peer by using the ppp pap local-user command.

Configuring the authenticator

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure the authenticator to authenticate the peer by using PAP.

ppp authentication-mode pap [ domain { isp-name | default enable isp-name } ]

By default, PPP authentication is disabled.

4.     Configure local or remote AAA authentication.

For information about AAA, see BRAS Services Configuration Guide.

Configuring the peer

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure the PAP username and password sent from the peer to the authenticator when the peer is authenticated by the authenticator by using PAP.

ppp pap local-user username password { cipher | simple } string

By default, when being authenticated by the authenticator by using PAP, the peer sends null username and password to the authenticator.

For security purposes, the password specified in plaintext form and ciphertext form will be stored in encrypted form.

Configuring CHAP authentication (authenticator name is configured)

Restrictions and guidelines for CHAP authentication (authenticator name is configured)

When you configure the authenticator, follow these guidelines:

·     For local AAA authentication, the username and password of the peer must be configured on the authenticator.

·     For remote AAA authentication, the username and password of the peer must be configured on the remote AAA server.

·     The username and password configured for the peer must meet the following requirements:

¡     The username configured for the peer must be the same as that configured on the peer by using the ppp chap user command.

¡     The passwords configured for the authenticator and peer must be the same.

When you configure the peer, follow these guidelines:

·     For local AAA authentication, the username and password of the authenticator must be configured on the peer.

·     For remote AAA authentication, the username and password of the authenticator must be configured on the remote AAA server.

·     The username and password configured for the authenticator must meet the following requirements:

¡     The username configured for the authenticator must be the same as that configured on the authenticator by using the ppp chap user command.

¡     The passwords configured for the authenticator and peer must be the same.

·     The peer does not support the CHAP authentication password configured by using the ppp chap password command. CHAP authentication (authenticator name is configured) will apply even if the authentication name is configured.

Configuring the authenticator

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure the authenticator to authenticate the peer by using CHAP.

ppp authentication-mode chap [ domain { isp-name | default enable isp-name } ]

By default, PPP authentication is disabled.

4.     Configure a username for the CHAP authenticator.

ppp chap user username

The default setting is null.

5.     Configure local or remote AAA authentication.

For information about AAA, see BRAS Services Configuration Guide.

Configuring the peer

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure a username for the CHAP peer.

ppp chap user username

The default setting is null.

4.     Configure local or remote AAA authentication.

For information about AAA, see BRAS Services Configuration Guide.

Configuring CHAP authentication (authenticator name is not configured)

Restrictions and guidelines for CHAP authentication (authenticator name is not configured)

For local AAA authentication, the username and password of the peer must be configured on the authenticator.

For remote AAA authentication, the username and password of the peer must be configured on the remote AAA server.

The username and password configured for the peer must meet the following requirements:

·     The username configured for the peer must be the same as that configured on the peer by using the ppp chap user command.

·     The password configured for the peer must be the same as that configured on the peer by using the ppp chap password command.

Configuring the authenticator

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure the authenticator to authenticate the peer by using CHAP.

ppp authentication-mode chap [ domain { isp-name | default enable isp-name } ]

By default, PPP authentication is disabled.

4.     Configure local or remote AAA authentication.

For information about AAA, see BRAS Services Configuration Guide.

Configuring the peer

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure a username for the CHAP peer.

ppp chap user username

The default setting is null.

4.     Set the CHAP authentication password.

ppp chap password { cipher | simple } string

The default setting is null.

For security purposes, the password specified in plaintext form and ciphertext form will be stored in encrypted form.

Configuring MS-CHAP or MS-CHAP-V2 authentication

Restrictions and guidelines for MS-CHAP or MS-CHAP-V2 authentication

The device can only act as an authenticator for MS-CHAP or MS-CHAP-V2 authentication.

L2TP supports only MS-CHAP authentication.

MS-CHAP-V2 authentication supports password change only when using RADIUS.

As a best practice, do not set the authentication method for PPP users to none when MS-CHAP-V2 authentication is used.

For local AAA authentication, the username and password of the peer must be configured on the authenticator. For remote AAA authentication, the username and password of the peer must be configured on the remote AAA server. The username and password of the peer configured on the authenticator or remote AAA server must be the same as those configured on the peer.

If authentication name is configured, the username configured for the authenticator on the peer must be the same as that configured on the authenticator by using the ppp chap user command.

Configuring MS-CHAP or MS-CHAP-V2 authentication (authenticator name is configured)

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure the authenticator to authenticate the peer by using MS-CHAP or MS-CHAP-V2.

ppp authentication-mode { ms-chap | ms-chap-v2 } [ domain { isp-name | default enable isp-name } ]

By default, PPP authentication is disabled.

4.     Configure a username for the MS-CHAP or MS-CHAP-V2 authenticator.

ppp chap user username

5.     Configure local or remote AAA authentication.

For information about AAA, see BRAS Services Configuration Guide.

Configuring MS-CHAP or MS-CHAP-V2 authentication (authenticator name is not configured)

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure the authenticator to authenticate the peer by using MS-CHAP or MS-CHAP-V2.

ppp authentication-mode { ms-chap | ms-chap-v2 } [ domain { isp-name | default enable isp-name } ]

By default, PPP authentication is disabled.

4.     Configure local or remote AAA authentication.

For information about AAA, see BRAS Services Configuration Guide.

Configuring the polling feature

About this task

The polling feature checks PPP link state.

On an interface that uses PPP encapsulation, the link layer sends keepalive packets at keepalive intervals to detect the availability of the peer. If the interface has received no response to keepalive packets when the keepalive retry limit is reached, it determines that the link has failed and reports a link layer down event.

To set the keepalive retry limit, use the timer-hold retry command.

The value 0 disables an interface from sending keepalive packets. In this case, the interface can respond to keepalive packets from the peer.

Restrictions and guidelines

On a slow link, increase the keepalive interval to prevent false shutdown of the interface. This situation might occur when keepalive packets are delayed because a large packet is being transmitted on the link.

The keepalive interval must be smaller than the negotiation timeout time.

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Set the keepalive interval.

timer-hold seconds

By default, the keepalive interval is 10 seconds for a POS or serial interface and 60 seconds for a VT interface.

4.     Set the keepalive retry limit.

timer-hold retry retries

By default, the keepalive retry limit is 5 for a POS or serial interface and 3 for a VT interface.

Configuring a VT interface not to perform keepalive detection when the uplink traffic of PPP users is updated

About this task

If the configured keepalive interval (timer-hold seconds) or keepalive retry limit (timer-hold retry retries) is small, users might go offline because the interface cannot receive keepalive packets from the peer when congestion occurs in the network. To prevent keepalive packets from making the congestion deteriorate or causing users to frequently go offline, configure this feature.

With this feature configured, if the uplink traffic of PPP users is updated within a keepalive interval, the keepalive timer is reset, and online detection will not be performed. Otherwise, keepalive packets are sent to detect online users after the keepalive interval expires. For example, suppose you set the keepalive interval to 10 seconds by using the timer-hold command. If uplink traffic of PPP users is updated at the 5th second, the keepalive timer is reset. In this way, the sending of keepalive packets is delayed. If uplink traffic is updated within the next keepalive interval (10 seconds), the keepalive timer is reset again.

Restrictions and guidelines

To balance the overall device performance and ensure that the device operates at the best performance, the device uses the periodical statistics collection mechanism to collect user traffic update conditions. When a large number of users are online, you can configure the device to reset the keepalive timer and not to perform keepalive detection if the uplink traffic of a user is updated within one keepalive interval. In this case, as a best practice, increase the keepalive interval by using the timer-hold seconds command. If you do not do that, when the traffic of some users is updated within one keepalive interval, the device might fail to timely collect traffic update conditions of these users. As a result, the device considers that the traffic is not updated for these users, and sends detection packets to these users.

Procedure

1.     Enter system view.

system-view

2.     Enter VT interface view.

interface virtual-template number

3.     Configure the VT interface not to perform keepalive detection when the uplink traffic of PPP users is updated.

ppp keepalive datacheck

By default, keepalive packets are sent to detect online users after the keepalive interval expires no matter whether the uplink traffic of PPP users is updated within a keepalive interval.

Enabling fast reply for keepalive packets

About this task

This feature allows the hardware to automatically identify and reply to incoming keepalive requests, which can prevent DDoS attacks.

Restrictions and guidelines

This feature takes effect only on keepalive packets received from Ethernet links.

Procedure

1.     Enter system view.

system-view

2.     Enable fast reply for keepalive packets.

ppp keepalive fast-reply enable

By default, fast reply is enabled for keepalive packets.

Configuring PPP negotiation

Configuring the PPP negotiation timeout time

About this task

The device starts the PPP negotiation timeout timer after sending a packet. If no response is received before the timer expires, the device sends the packet again.

Restrictions and guidelines

If two ends of a PPP link vary greatly in the LCP negotiation packet processing rate, configure the delay timer on the end with a higher processing rate. The LCP negotiation delay timer prevents frequent LCP negotiation packet retransmission. After the physical layer comes up, PPP starts LCP negotiation when the delay timer expires. If PPP receives LCP negotiation packets before the delay timer expires, it starts LCP negotiation immediately.

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     (Optional.) Configure the LCP negotiation delay timer.

ppp lcp delay milliseconds

By default, PPP starts LCP negotiation after the physical layer comes up.

4.     Configure the negotiation timeout time.

ppp timer negotiate seconds

The default setting is 3 seconds.

Configuring IPv4 address negotiation on the client

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Enable IP address negotiation.

ip address ppp-negotiate

By default, IP address negotiation is not enabled.

If you execute this command and the ip address command multiple times, the most recent configuration takes effect. For more information about the ip address command, see Layer 3—IP Services Command Reference.

Configuring IPv4 address negotiation on the server

About this task

Configure the server to assign an IP address to a client by using the following methods:

·     Method 1: Specify an IP address for the client on the server interface.

·     Method 2: Specify an address pool on the server interface.

·     Method 3: Associate an address pool with an ISP domain.

·     Method 4: Authorize an IP address to a client by using the AAA server.

Restrictions and guidelines for IP address negotiation on the server

For clients requiring no authentication, you can use either method 1 or method 2. When both method 1 and method 2 are configured, the most recent configuration takes effect.

For clients requiring authentication, you can use one or more of the four methods. When multiple methods are configured, method 4 takes precedence over method 3, and method 3 takes precedence over method 1 or method 2. When both method 1 and method 2 are configured, the most recent configuration takes effect.

When you use method 4, enable DHCP on the AAA server by using the dhcp enable command and authorize an IP address to the client. For more information about the dhcp enable command, see BRAS Services Command Reference.

Specifying an IP address for the client on the server interface

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure the interface to assign an IP address to the peer.

remote address ip-address

By default, an interface does not assign an IP address to the peer.

4.     Configure an IP address for the interface.

ip address ip-address

By default, no IP address is configured on an interface.

Specifying an IP address pool on the server interface

1.     Enter system view.

system-view

2.     Configure DHCP.

¡     If the server acts as a DHCP server, perform the following tasks:

-     Configure the DHCP server.

-     Configure an IP address pool on the server.

¡     If the server acts as a DHCP relay agent, perform the following tasks:

-     Configure the DHCP relay agent on the server.

-     Configure an IP address pool on the remote DHCP server.

-     Enable the DHCP relay agent to record relay entries.

-     Configure a DHCP relay address pool.

For information about configuring a DHCP server and a DHCP relay agent, see BRAS Services Configuration Guide.

3.     Enter interface view.

interface interface-type interface-number

4.     Configure the interface to assign an IP address from the configured IP address pool to the peer.

remote address pool pool-name

By default, an interface does not assign an IP address to the peer.

5.     (Optional.) Configure the method of generating DHCP client IDs when PPP users act as DHCP clients.

remote address dhcp client-identifier { { callingnum | username } [ session-info ] | session-info }

By default, the method of generating DHCP client IDs when PPP users act as DHCP clients is not configured.

When DHCP client IDs are generated based on PPP usernames, make sure different users use different PPP usernames to come online.

6.     Configure an IP address for the interface.

ip address ip-address

By default, no IP address is configured on an interface.

Associating an IP address pool with an ISP domain

1.     Enter system view.

system-view

2.     Configure DHCP.

¡     If the server acts as a DHCP server, perform the following tasks:

-     Configure the DHCP server.

-     Configure an IP address pool on the server.

¡     If the server acts as a DHCP relay agent, perform the following tasks:

-     Configure the DHCP relay agent on the server.

-     Configure an IP address pool on the remote DHCP server.

-     Enable the DHCP relay agent to record relay entries.

-     Configure a DHCP relay address pool.

For information about configuring a DHCP server and a DHCP relay agent, see BRAS Services Configuration Guide.

3.     Enter ISP domain view.

domain name isp-name

4.     Associate the ISP domain with the configured IP address pool or DHCP relay address pool for address assignment.

authorization-attribute ip-pool pool-name

By default, no IP address pool or DHCP relay address pool is associated.

For more information about this command, see BRAS Services Command Reference.

5.     Return to system view.

quit

6.     Enter interface view.

interface interface-type interface-number

7.     (Optional.) Configure the method of generating DHCP client IDs when PPP users act as DHCP clients.

remote address dhcp client-identifier { { callingnum | username } [ session-info ] | session-info }

By default, the method of generating DHCP client IDs when PPP users act as DHCP clients is not configured.

When DHCP client IDs are generated based on PPP usernames, make sure different users use different PPP usernames to come online.

8.     Configure an IP address for the interface.

ip address ip-address

By default, no IP address is configured on an interface.

Configuring IPv6 address negotiation on the server

Assigning an IPv6 address by using the NDRA method

1.     Enter VT interface view.

interface virtual-template interface-number

2.     Enable the interface to advertise RA messages.

undo ipv6 nd ra halt

3.     Configure the prefix information in RA messages on the interface.

ipv6 nd ra prefix { ipv6-prefix prefix-length | ipv6-prefix/prefix-length } [ valid-lifetime preferred-lifetime [ no-autoconfig | off-link ] * ]

The IPv6 prefix in the RA message is determined in the following sequence:

¡     IPv6 prefix authorized by AAA.

¡     Prefix in the ND prefix pool authorized by AAA.

¡     RA prefix configured on the interface.

¡     Prefix of the IPv6 global unicast address configured on the interface.

If the ipv6 nd ra prefix command is executed on both a user access interface and the VT interface bound to the interface, the command takes effect only on the VT interface.

4.     Set the other stateful configuration flag (O) to 1 in RA advertisements to be sent.

ipv6 nd autoconfig other-flag

You can also execute this command in ISP domain view. Execute this command in at least one of ISP domain view and interface view.

5.     Return to system view.

quit

6.     Enter user access interface view.

interface interface-type interface-number

7.     Configure the interface to automatically generate a link-local address.

ipv6 address auto link-local

8.     Enable the interface to advertise RA messages.

undo ipv6 nd ra halt

9.     Enable the DHCPv6 server.

ipv6 dhcp select server

10.     Return to system view.

quit

11.     Create an ISP domain and enter its view.

domain name isp-name

12.     Configure an IPv6 prefix authorized to the user in the ISP domain.

authorization-attribute ipv6-prefix ipv6-prefix prefix-length

Assigning an IPv6 address by using the IA_NA method

1.     Enter VT interface view.

interface virtual-template interface-number

2.     Enable the interface to advertise RA messages.

undo ipv6 nd ra halt

3.     Set the managed address configuration flag (M) to 1 in RA advertisements to be sent.

ipv6 nd autoconfig managed-address-flag

You can also execute this command in ISP domain view. Execute this command in at least one of ISP domain view and interface view.

4.     Set the other stateful configuration flag (O) to 1 in RA advertisements to be sent.

ipv6 nd autoconfig other-flag

You can also execute this command in ISP domain view. Execute this command in at least one of ISP domain view and interface view.

5.     Return to system view.

quit

6.     Enter user access interface view.

interface interface-type interface-number

7.     Configure the interface to automatically generate a link-local address.

ipv6 address auto link-local

8.     Enable the interface to advertise RA messages.

undo ipv6 nd ra halt

9.     Enable the DHCPv6 server.

ipv6 dhcp select server

10.     Return to system view.

quit

11.     Configure an IPv6 address pool and configure an ISP domain to authorize the address pool to users.

For more information, see BRAS Services Configuration Guide.

Assigning an IPv6 address by using the IA_PD method

1.     Enter user access interface view.

interface interface-type interface-number

2.     Configure the interface to automatically generate a link-local address.

ipv6 address auto link-local

3.     Enable the interface to advertise RA messages.

undo ipv6 nd ra halt

4.     Enable the DHCPv6 server.

ipv6 dhcp select server

5.     Return to system view.

quit

6.     Create a prefix pool and specify the prefix and the assigned prefix length for the pool.

ipv6 dhcp prefix-pool prefix-pool-number prefix prefix/prefix-len assign-len assign-len

7.     Create an IPv6 address pool and enter its view.

For more information, see BRAS Services Configuration Guide.

8.     Apply a prefix pool to the IPv6 address pool, so the DHCPv6 server can dynamically select a prefix from the prefix pool for the client.

prefix-pool prefix-pool-number [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] [ export-route [ preference preference | tag tag ] * ]

9.     Return to system view.

quit

10.     Create an ISP domain and enter its view.

domain name isp-name

11.     Configure the user authorization attribute in the ISP domain.

authorization-attribute ipv6-pool pool-name

Configuring a BRAS to allow a remote user to come online by using a self-configured static IP address

About this task

By default, a PPPoE user must use an IP address dynamically allocated by the BRAS (PPPoE server) or authorized by the AAA server during the onboarding process, and a BRAS does not allow a user to come online by using a self-configured static IP address.

On some networks, for a user to come online by using a self-configured static IP address, you can configure this feature on the BRAS. With this feature configured, a BRAS to allow a remote user to come online by using a self-configured static IP address. After the user passes authentication and comes online, the BRAS will maintain session information for the user based on the static IP address.

Restrictions and guidelines

This feature applies to only PPPoE users in the BRAS access scenario.

To avoid IP conflicts between users, plan the IP addresses reasonably. Make sure the dynamically allocated IP addresses do not contain static IP addresses used by access users and the static IP address of each access user is unique. If you cannot do that, the user cannot come online in the IPv4 or IPv6 protocol stack because of IP address conflicts.

When you configure this feature on an IPv4 network, follow these restrictions and guidelines:

·     You must use an IP address pool to deploy the gateway address information to the address management module. For example, specify the export-route keyword when executing the gateway-list command in a common IP address pool. Also, you must authorize the IP address pool in the authentication domain of the user.

·     You can specify the DNS server address for users in the authorized IP address pool.

When you configure this feature on an IPv6 network, follow these restrictions and guidelines:

·     For the access interface of an IPv6 static user, do not configure NDRA initiation on the interface. If both NDRA initiation and IPv6 static user access are configured on an interface, only the NDRA initiation method takes effect.

·     To prevent an IPv6 static user from failing to come online because the NDRA initiation method is mistakenly configured, as a best practice, execute the ipv6 nd autoconfig managed-address-flag command to prevent the IPv6 static user from coming online through NDRA initiation on at least one of the VT interface of the IPv6 static user and the authentication domain of the user. 

·     For the access interface of an IPv6 static user, if you also configure the IA_NA initiation method on the interface, some endpoints will first obtain addresses through IA_NA initiation. After the endpoints obtain addresses through IA_NA initiation, the static addresses configured for the endpoints will not take effect. Therefore, as a best practice, execute the undo ipv6 dhcp select command on the access interfaces of an IPv6 static user to prevent the IPv6 static user from obtaining an address through IA_NA. (The default configuration.)

·     The IPv6 DNS server address of a user must be manually configured, and cannot be obtained through any other method (for example, DHCPv6).

 

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure the BRAS to allow a remote user to come online by using a self-configured static IP address.

ppp accept remote-ip-address

By default, a BRAS does not allow a remote user to come online by using a self-configured static IP address.

4.     Configure the BRAS to allow a remote user to come online by using a self-configured static IPv6 global unicast address.

ppp accept remote-ipv6-address

By default, a BRAS does not allow a remote user to come online by using a self-configured static IPv6 global unicast address.

Enabling IP segment match

About this task

This feature enables the local interface to check whether its IP address and the IP address of the remote interface are in the same network segment. If they are not, IPCP negotiation fails.

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Enable IP segment match.

ppp ipcp remote-address match

By default, this feature is disabled.

Configuring DNS server IP address negotiation on the client

About this task

During PPP negotiation, the server will assign a DNS server IP address only for a client configured with the ppp ipcp dns request command. For some special devices to forcibly assign DNS server IP addresses to clients that do not initiate requests, configure the ppp ipcp dns admit-any command on these devices.

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Enable the device to request the peer for a DNS server IP address.

ppp ipcp dns request

By default, a client does not request its peer for a DNS server IP address.

4.     Configure the device to accept the DNS server IP addresses assigned by the peer even though it does not request the peer for the DNS server IP addresses.

ppp ipcp dns admit-any

By default, a device does not accept the DNS server IP addresses assigned by the peer if it does not request the peer for the DNS server IP addresses.

This command is not necessary if the ppp ipcp dns request command is configured.

Configuring DNS server IP address negotiation on the server

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Specify the primary and secondary DNS server IP addresses to be allocated to the peer in PPP negotiation.

ppp ipcp dns primary-dns-address [ secondary-dns-address ]

By default, a device does not allocate DNS server IP addresses to its peer if the peer does not request them.

After this command is configured, the server allocate DNS server IP addresses to a client that initiates requests.

Enabling PPP link quality monitoring

About this task

PPP link quality monitoring (LQM) monitors the quality (packet loss ratio and packet error ratio) of PPP links (including those in MP bundles) in real time.

If PPP LQM is not enabled, each end of a PPP link periodically sends keepalives to its peer. If PPP LQM is enabled, Link Quality Reports (LQRs) packets replace keepalives to monitor the link.

The system uses received LQR packets to measure the link quality. If two consecutive measured results are below the close-percentage, the system shuts down the link. Then the system measures the link quality at an interval that is ten times the LQR interval. If three consecutive measured results are higher than the PPP LQM resume-percentage, the system brings up the link.

Restrictions and guidelines

A shut-down link must experience a minimum of 30 keepalive intervals before it can come up again. As a best practice, do not set the keepalive interval to a large value.

If you enable PPP LQM on both sides of a PPP link, make sure both sides have the same PPP LQM settings. Typically, there is no need to enable PPP LQM on both sides of a PPP link.

This feature does not affect existing users.

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Enable PPP LQM.

ppp lqm close-percentage close-percentage [ resume-percentage resume-percentage ]

By default, PPP LQM is disabled.

Configuring magic number check for PPP

About this task

In the PPP link establishment process, the magic number is negotiated. After the negotiation, both the local end and the peer end save their magic numbers locally.

The local end sends Echo-Request packets carrying its own magic number. When magic number check is enabled on both the local end and the peer end, the peer end will compare its own magic number with the magic number in the received Echo-Request packets. If they are the same, the link status is considered as normal, and the peer end replies with Echo-Reply packets carrying its own magic number. The local end also compares its own magic number with the magic number carried in the received Echo-Reply packets.

A link is disconnected and LCP negotiation is restarted when either of the following events occurs on either end:

·     When fast reply for keepalive packets is enabled:

¡     The magic number check fails for five Echo-Request packets in total.

¡     The magic number check fails for five consecutive Echo-Reply packets.

·     When fast reply for keepalive packets is disabled, the magic number check fails for five consecutive Echo-Request or Echo-Reply packets.

Only the end with magic number check enabled can check the magic number in received Echo-Request or Echo-Reply packets.

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Enable magic number check for PPP.

ppp magic-number-check

By default, magic number check is disabled for PPP.

Enabling MRU check for PPP packets

About this task

In PPP Link Establishment phase, the Maximum-Receive-Unit (MRU) value is negotiated in the LCP negotiation. When the MTUs of interfaces on the two end of a link are different, PPP uses the smaller MTU as the link MRU.

By default, the device does not perform MRU check if the MTU in a received PPP packet is larger than the negotiated MRU. With MRU check enabled, the device discards a received PPP packet if the MTU in the packet is larger than the negotiated MRU.

Restrictions and guidelines

As a best practice to enhance system security, enable MRU check. Otherwise, a fake peer might attack the device by sending a large number of PPP packets with MTUs larger than the negotiated MRU.

Procedure

1.     Enter system view.

system-view

2.     Enable MRU check for PPP packets.

ppp mru-check enable

By default, MRU check for PPP packets is disabled.

Specifying that PPP users cannot come online successfully if the online requests do not carry usernames

About this task

The username format is userid@isp-name. A username is considered as empty when both the user ID and ISP domain name are empty. If the user ID is empty but the ISP domain name is not empty, the username is considered as non-empty.

By default, when PPP user online requests do not carry the usernames (the usernames are empty), the following rules apply:

·     For PPPoE users, the user MAC addresses in the requests are used as the usernames.

·     For L2TP users, the calling numbers in the requests are used as the usernames.

If the network environment needs strictly checking the username validity, you can configure this feature. With this feature configured, when the device receives online requests without usernames from PPPoE or L2TP users, the device does not use the user MAC addresses or calling numbers in the requests as usernames for AAA authentication, and the device directly returns authentication failure to users.

Restrictions and guidelines

When the device uses the user MAC addresses or calling numbers in the requests as the usernames for AAA authentication, neither the contents nor the format of the information will be modified.

Procedure

1.     Enter system view.

system-view

2.     Enter VT interface view.

interface virtual-template number

3.     Specify that PPP users cannot come online successfully if the online requests do not carry usernames on the VT interface.

ppp username check

By default, PPP users can come online successfully if the online requests do not carry usernames.

Enabling PPP user blocking

Enabling per-username PPP user blocking

About this task

This feature blocks a PPP user for a period if the user fails authentication consecutively for the specified number of times within the detection period. This feature helps prevent illegal users from using the method of exhaustion to obtain the password, and reduces authentication packets sent to the authentication server. Packets from the blocked users will be discarded during the blocking period, and will be processed when the blocking period expires.

Restrictions and guidelines

This feature uniquely identifies a blocked user by username and ISP domain name. (non-vBRAS-CPs.)

This feature identify users by username and domain name. Users that have the same username but belong to different domains are processes as different users.

Procedure

1.     Enter system view.

system-view

2.     Enable PPP user blocking.

ppp authentication chasten auth-failure auth-period blocking-period

By default, a PPP user will be blocked for 300 seconds if the user fails authentication consecutively for six times within 60 seconds.

Configuration per-MAC PPP user blocking

About this task

In addition to the per-username PPP user blocking, you can configure per-MAC PPP user blocking. This feature blocks PPP users using the same MAC address for a period if these users fail authentication consecutively for the specified number of times within the detection period. This feature helps prevent illegal users from using the method of exhaustion to obtain the password, and reduces authentication packets sent to the authentication server. Packets from the blocked users will be discarded during the blocking period, and will be processed when the blocking period expires. Packets from the blocked MAC address will be processed when the blocking period expires.

Compared with the per-username PPP user blocking, per-MAC PPP user blocking can effectively avoid issues that the username is automatically changed and one account establishes multiple sessions. Additionally, the two features can cooperate to perform attack prevention for PPP users in different perspectives.

Restrictions and guidelines

This feature uniquely identifies a blocked user by its MAC address, inner VLAN, outer VLAN, and access interface. (non-vBRAS-CPs.)

For PPP users that use the same MAC address but are in different VLANs or use different access interfaces, the device will collect authentication failure statistics for them and block them separately.

Procedure

1.     Enter system view.

system-view

2.     Enable per-MAC PPP user blocking.

ppp authentication chasten per-mac [ multi-sessions ] auth-failure auth-period blocking-period

By default, a user will be blocked for 300 seconds if the consecutive authentication failures of the user reach six times within 60 seconds.

When a MAC address can establish more than one PPP session, to enable per-MAC PPP user blocking, you must specify the multi-sessions keyword.

Setting the online PPP session count alarm thresholds on the device

About this task

The online PPP session count on the device refers to the total number of online PPP sessions on the device.

You can use this command to set the upper alarm threshold and lower alarm threshold for the PPP session count. When the PPP session count exceeds the upper alarm threshold or drops below the lower threshold, an alarm is triggered automatically. Then, the administrator can promptly know the online user conditions of the network. Additionally, the administrator can use the display access-user command to view the total number of online PPP sessions.

The user session count alarm function counts only PPPoE user sessions that occupy session resources. Either a single-stack PPPoE user or dual-stack PPPoE user occupies one session resource.

Suppose the maximum number of online PPP sessions allowed is a, the upper alarm threshold is b, and the lower alarm threshold is c. The following rules apply:

·     When the online PPP session count exceeds a×b or drops below a×c, the corresponding alarm information is output.

·     When the online PPP session count returns between the upper alarm threshold and lower alarm threshold, the alarm clearing information is output.

In some special cases, the online PPP session count frequently changes in the critical range, which causes frequent output of alarm information and alarm clearing information. To avoid this problem, the system introduces a buffer area when the online PPP session count recovers from the upper or lower threshold. The buffer area size is 10% of the difference between the upper threshold and the lower threshold. Suppose the buffer area size is d. Then, d=a×(b-c)÷10. When the online PPP session count drops below a×b-d or exceeds a×c+d, the alarm clearing information is output.

For example, suppose a is 1000, b is 80%, and c is 20%. Then, d= a×(b-c)÷10=1000×(80%-20%)÷10=1000×60%÷10=600÷10=60.

When the online PPP session count exceeds the upper threshold a×b=1000×80%=800, the upper threshold alarm is output. When the online PPP session count restores to be smaller than a×b-d=800-60=740, the alarm clearing information is output.

When the online PPP session count drops below the lower threshold a×c=1000×20%=200, the lower threshold alarm is output. When the online PPP session count restores to be greater than a×c+d=200+60=260, the alarm clearing information is output.

The upper threshold alarm information output and the alarm clearing information output both contain logs and traps. For traps to be correctly sent to the NMS host, you must execute the snmp-agent trap enable user-warning-threshold command in addition to configuring the SNMP alarm feature correctly.

Restrictions and guidelines

The upper alarm threshold must be greater than the lower alarm threshold.

Procedure

1.     Enter system view.

system-view

2.     Configure the upper and lower online PPP session count alarm thresholds on the device.

ppp session-threshold { lower-limit lower-limit-value | upper-limit upper-limit-value }

By default, the upper online PPP session count alarm threshold is 100, and the lower online PPP session count alarm threshold is 0.

3.     Enable the device-level user count trap feature.

snmp-agent trap enable user-warning-threshold

By default, the device-level user count trap feature is disabled.

For more information about this command, see BRAS Services Command Reference.

Enabling SNMP notifications for the PPP module

About this task

With SNMP notifications enabled for the PPP module, traps will be generated when critical events of the specified type (for example, loops occur or are removed on both ends of a PPP link) occur to the PPP module. The generated traps are sent to the SNMP module of the device. You can specify how the traps are output through setting the trap output parameters in SNMP. For more information about traps, see SNMP configuration in Network Management and Monitoring Configuration Guide.

Restrictions and guidelines

If you do not specify any keyword when enabling this feature, SNMP notifications are enabled for the PPP LCP, loop detection, and NCP modules.

Procedure

1.     Enter system view.

system-view

2.     Enable SNMP notifications for the PPP module.

snmp-agent trap enable ppp [ lcp | loopback-detect | ncp ] *

By default, the SNMP notifications are disabled for the PPP module.

Display and maintenance commands for PPP

Execute display commands in any view and reset commands in user view.

 

Task

Command

Display information about VT interfaces.

display interface [ virtual-template [ interface-number ] ] [ brief [ description | down ] ]

Display per-MAC blocking information about PPP users.

display ppp chasten per-mac { auth-failed | blocked } [ mac mac-address ] [ interface interface-type interface-number ]

Display statistics about PPP user blocking.

display ppp chasten statistics

Display blocking information about PPP users.

display ppp chasten user { auth-failed | blocked } [ username user-name ]

Display the packet loss ratio statistics for the PPP user detection packets.

display ppp keepalive packet-loss-ratio [ interface interface-type interface-number [ s-vlan svlan-id ] ] [ slot slot-number ]

Display PPP negotiation packet statistics.

display ppp packet statistics [ slot slot-number ]

Unblock PPP users.

reset ppp chasten blocked-user [ username user-name ]

Unblock PPP users blocked by per-MAC PPP user blocking.

reset ppp chasten per-mac blocked [ mac mac-address [ s-vlan vlan-id [ c-vlan vlan-id ] ] ] [ interface interface-type interface-number ]

Clear the packet loss ratio statistics for the PPP user detection packets on the device.

reset ppp keepalive packet-loss-ratio [ interface interface-type interface-number ] [ slot slot-number ]

Clear PPP negotiation packet statistics.

reset ppp packet statistics [ slot slot-number ]

PPP configuration examples

Example: Configuring one-way PAP authentication

Network configuration

As shown in Figure 2, configure Router A to authenticate Router B by using PAP, but Router B not to authenticate Router A.

Figure 2 Network diagram

Procedure

1.     Configure Router A:

# Create a user account for Router B.

<RouterA> system-view

[RouterA] local-user userb class network

# Set a password for the user account.

[RouterA-luser-network-userb] password simple 123456TESTplat&!

# Set the service type of the user account to PPP.

[RouterA-luser-network-userb] service-type ppp

[RouterA-luser-network-userb] quit

# Enable PPP encapsulation on Serial 3/0/1:0. By default, an interface uses PPP encapsulation.

[RouterA] interface serial 3/0/1:0

[RouterA-Serial3/0/1:0] link-protocol ppp

# Set the authentication mode to PAP.

[RouterA-Serial3/0/1:0] ppp authentication-mode pap domain system

# Assign an IP address to Serial 3/0/1:0.

[RouterA-Serial3/0/1:0] ip address 200.1.1.1 16

[RouterA-Serial3/0/1:0] quit

# Configure local authentication for the PPP users in the default ISP domain (system).

[RouterA] domain name system

[RouterA-isp-system] authentication ppp local

[RouterA-isp-system] quit

2.     Configure Router B:

# Enable PPP encapsulation on Serial 3/0/1:0. By default, an interface uses PPP encapsulation.

<RouterB> system-view

[RouterB] interface serial 3/0/1:0

[RouterB-Serial3/0/1:0] link-protocol ppp

# On Serial 3/0/1:0, configure the PAP username and password sent from Router B to Router A when Router B is authenticated by Router A using PAP.

[RouterB-Serial3/0/1:0] ppp pap local-user userb password simple 123456TESTplat&!

# Assign an IP address to Serial 3/0/1:0 of Router B.

[RouterB-Serial3/0/1:0] ip address 200.1.1.2 16

[RouterB-Serial3/0/1:0] quit

Verifying the configuration

# Use the display interface serial command to display information about Serial 3/0/1:0 of Router B.

[RouterB] display interface serial 3/0/1:0

Serial3/0/1:0

Current state: UP

Line protocol state: UP

Description: Serial3/0/1:0 Interface

Bandwidth: 64kbps

Maximum transmission unit: 1500

Hold timer: 10 seconds, retry times: 5

Internet address: 200.1.1.2/16 (primary)

Link layer protocol: PPP

LCP: opened, IPCP: opened

...

The output shows that:

·     The physical layer status and link layer status of the interface are both up.

·     The states of LCP and IPCP are both Opened, indicating that PPP negotiation has succeeded.

# Verify that Router A and Router B can ping each other.

[RouterB] ping 200.1.1.1

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss Ping 200.1.1.1 (200.1.1.1): 56 data bytes, press CTRL+C to break

56 bytes from 200.1.1.1: icmp_seq=0 ttl=128 time=3.197 ms

56 bytes from 200.1.1.1: icmp_seq=1 ttl=128 time=2.594 ms

56 bytes from 200.1.1.1: icmp_seq=2 ttl=128 time=2.739 ms

56 bytes from 200.1.1.1: icmp_seq=3 ttl=128 time=1.738 ms

56 bytes from 200.1.1.1: icmp_seq=4 ttl=128 time=1.744 ms

 

--- Ping statistics for 200.1.1.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.738/2.402/3.197/0.576 ms

Example: Configuring two-way PAP authentication

Network configuration

As shown in Figure 3, configure Router A and Router B to authenticate each other.

Figure 3 Network diagram

Procedure

1.     Configure Router A:

# Create a user account for Router B.

<RouterA> system-view

[RouterA] local-user userb class network

# Set a password for the user account.

[RouterA-luser-network-userb] password simple 123456TESTplat&!

# Set the service type of the user account to PPP.

[RouterA-luser-network-userb] service-type ppp

[RouterA-luser-network-userb] quit

# Enable PPP encapsulation on Serial 3/0/1:0. By default, an interface uses PPP encapsulation.

[RouterA] interface serial 3/0/1:0

[RouterA-Serial3/0/1:0] link-protocol ppp

# Set the authentication mode to PAP.

[RouterA-Serial3/0/1:0] ppp authentication-mode pap domain system

# Configure the PAP username and password sent from Router A to Router B when Router A is authenticated by Router B using PAP.

[RouterA-Serial3/0/1:0] ppp pap local-user usera password simple 123456TESTplat&!

# Assign an IP address to Serial 3/0/1:0 of Router A.

[RouterA-Serial3/0/1:0] ip address 200.1.1.1 16

[RouterA-Serial3/0/1:0] quit

# Configure local authentication for the PPP users in the default ISP domain (system).

[RouterA] domain name system

[RouterA-isp-system] authentication ppp local

[RouterA-isp-system] quit

2.     Configure Router B:

# Create a user account for Router A on Router B.

<RouterB> system-view

[RouterB] local-user usera class network

# Set a password for the user account.

[RouterB-luser-network-usera] password simple 123456TESTplat&!

# Set the service type of the user account to PPP.

[RouterB-luser-network-usera] service-type ppp

[RouterB-luser-network-usera] quit

# Enable PPP encapsulation on Serial 3/0/1:0. By default, an interface uses PPP encapsulation.

[RouterB] interface serial 3/0/1:0

[RouterB-Serial3/0/1:0] link-protocol ppp

# Set the authentication mode to PAP on Serial 3/0/1:0.

[RouterB-Serial3/0/1:0] ppp authentication-mode pap domain system

# On Serial 3/0/1:0, configure the PAP username and password sent from Router B to Router A when Router B is authenticated by Router A using PAP.

[RouterB-Serial3/0/1:0] ppp pap local-user userb password simple 123456TESTplat&!

# Assign an IP address to Serial 3/0/1:0.

[RouterB-Serial3/0/1:0] ip address 200.1.1.2 16

[RouterB-Serial3/0/1:0] quit

# Configure local authentication for the PPP users in the default ISP domain (system).

[RouterB] domain name system

[RouterB-isp-system] authentication ppp local

[RouterB-isp-system] quit

Verifying the configuration

# Use the display interface serial command to display information about Serial 3/0/1:0 of Router B.

[RouterB] display interface serial 3/0/1:0

Serial3/0/1:0

Current state: UP

Line protocol state: UP

Description: Serial3/0/1:0 Interface

Bandwidth: 64kbps

Maximum transmission unit: 1500

Hold timer: 10 seconds, retry times: 5

Internet address: 200.1.1.2/16 (primary)

Link layer protocol: PPP

LCP opened, IPCP opened

...

The output shows that:

·     The physical layer status and link layer status of the interface are both up.

·     The states of LCP and IPCP are both Opened, indicating that PPP negotiation has succeeded.

# Verify that Router B can successfully ping Router A.

[RouterB] ping 200.1.1.1

Ping 200.1.1.1 (200.1.1.1): 56 data bytes, press CTRL+C to break

56 bytes from 200.1.1.1: icmp_seq=0 ttl=128 time=3.197 ms

56 bytes from 200.1.1.1: icmp_seq=1 ttl=128 time=2.594 ms

56 bytes from 200.1.1.1: icmp_seq=2 ttl=128 time=2.739 ms

56 bytes from 200.1.1.1: icmp_seq=3 ttl=128 time=1.738 ms

56 bytes from 200.1.1.1: icmp_seq=4 ttl=128 time=1.744 ms

 

--- Ping statistics for 200.1.1.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.738/2.402/3.197/0.576 ms

Example: Configuring one-way CHAP authentication

Network configuration

As shown in Figure 4, configure Router A to authenticate Router B by using CHAP.

Figure 4 Network diagram

Procedure (authenticator name is configured)

1.     Configure Router A:

# Create a user account for Router B.

<RouterA> system-view

[RouterA] local-user userb class network

# Set a password for the user account.

[RouterA-luser-network-userb] password simple 123456TESTplat&!

# Set the service type of the user account to PPP.

[RouterA-luser-network-userb] service-type ppp

[RouterA-luser-network-userb] quit

# Enable PPP encapsulation on Serial 3/0/1:0. By default, an interface uses PPP encapsulation.

[RouterA] interface serial 3/0/1:0

[RouterA-Serial3/0/1:0] link-protocol ppp

# On Serial 3/0/1:0, configure the username for Router A when Router A authenticates Router B.

[RouterA-Serial3/0/1:0] ppp chap user usera

# Set the authentication mode to CHAP on Serial 3/0/1:0.

[RouterA-Serial3/0/1:0] ppp authentication-mode chap domain system

# Assign an IP address to Serial 3/0/1:0.

[RouterA-Serial3/0/1:0] ip address 200.1.1.1 16

[RouterA-Serial3/0/1:0] quit

# Configure local authentication for the PPP users in the default ISP domain (system).

[RouterA] domain name system

[RouterA-isp-system] authentication ppp local

[RouterA-isp-system] quit

2.     Configure Router B:

# Create a user account for Router A on Router B.

<RouterB> system-view

[RouterB] local-user usera class network

# Set a password for the user account.

[RouterB-luser-network-usera] password simple 123456TESTplat&!

# Set the service type of the user account to PPP.

[RouterB-luser-network-usera] service-type ppp

[RouterB-luser-network-usera] quit

# Enable PPP encapsulation on Serial 3/0/1:0. By default, an interface uses PPP encapsulation.

[RouterB] interface serial 3/0/1:0

[RouterB-Serial3/0/1:0] link-protocol ppp

# Configure the username for Router B when Router B is authenticated.

[RouterB-Serial3/0/1:0] ppp chap user userb

# Assign an IP address to Serial 3/0/1:0 of Router B.

[RouterB-Serial3/0/1:0] ip address 200.1.1.2 16

[RouterB-Serial3/0/1:0] quit

Procedure (authenticator name is not configured)

1.     Configure Router A:

# Create a user account for Router B.

<RouterA> system-view

[RouterA] local-user userb class network

# Set a password for the user account.

[RouterA-luser-network-userb] password simple 123456TESTplat&!

# Set the service type of the user account to PPP.

[RouterA-luser-network-userb] service-type ppp

[RouterA-luser-network-userb] quit

# Set the authentication mode to CHAP on Serial 3/0/1:0.

[RouterA] interface serial 3/0/1:0

[RouterA-Serial3/0/1:0] ppp authentication-mode chap domain system

# Assign an IP address to Serial 3/0/1:0.

[RouterA-Serial3/0/1:0] ip address 200.1.1.1 16

[RouterA-Serial3/0/1:0] quit

# Configure local authentication for the PPP users in the default ISP domain (system).

[RouterA] domain name system

[RouterA-isp-system] authentication ppp local

[RouterA-isp-system] quit

2.     Configure Router B:

# On Serial 3/0/1:0, configure the username of Router B when Router B is authenticated.

<RouterB> system-view

[RouterB] interface serial 3/0/1:0

[RouterB-Serial3/0/1:0] ppp chap user userb

# Set the default CHAP password on Serial 3/0/1:0.

[RouterB-Serial3/0/1:0] ppp chap password simple 123456TESTplat&!

# Assign an IP address to Serial 3/0/1:0.

[RouterB-Serial3/0/1:0] ip address 200.1.1.2 16

[RouterB-Serial3/0/1:0] quit

Verifying the configuration

# Use the display interface serial command to display information about Serial 3/0/1:0 of Router B.

[RouterB] display interface serial 3/0/1:0

Serial3/0/1:0

Current state: UP

Line protocol state: UP

Description: Serial3/0/1:0 Interface

Bandwidth: 64kbps

Maximum transmission unit: 1500

Hold timer: 10 seconds, retry times: 5

Internet address: 200.1.1.2/16 (primary)

Link layer protocol: PPP

LCP opened, IPCP opened

...

The output shows that:

·     The physical layer status and link layer status of the interface are both up.

·     The states of LCP and IPCP are both Opened, indicating that PPP negotiation has succeeded.

# Verify that Router A and Router B can ping each other.

[RouterB] ping 200.1.1.1

Ping 200.1.1.1 (200.1.1.1): 56 data bytes, press CTRL+C to break

56 bytes from 200.1.1.1: icmp_seq=0 ttl=128 time=3.197 ms

56 bytes from 200.1.1.1: icmp_seq=1 ttl=128 time=2.594 ms

56 bytes from 200.1.1.1: icmp_seq=2 ttl=128 time=2.739 ms

56 bytes from 200.1.1.1: icmp_seq=3 ttl=128 time=1.738 ms

56 bytes from 200.1.1.1: icmp_seq=4 ttl=128 time=1.744 ms

 

--- Ping statistics for 200.1.1.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.738/2.402/3.197/0.576 ms

Example: Specifying an IP address for the client on the server interface

Network configuration

As shown in Figure 5, configure Router A to allocate an IP address to Serial 3/0/1:0 of Router B through PPP negotiation. The IP address is specified on an interface of Router A.

Figure 5 Network diagram

Procedure

1.     Configure Router A:

# Configure an IP address to be assigned to the peer interface on Serial 3/0/1:0.

<RouterA> system-view

[RouterA] interface serial 3/0/1:0

[RouterA-Serial3/0/1:0] remote address 200.1.1.10

# Configure an IP address for Serial 3/0/1:0.

[RouterA-Serial3/0/1:0] ip address 200.1.1.1 16

[RouterA-Serial3/0/1:0] quit

2.     Enable IP address negotiation on Serial 3/0/1:0 of Router B.

<RouterB> system-view

[RouterB] interface serial 3/0/1:0

[RouterB-Serial3/0/1:0] ip address ppp-negotiate

[RouterB-Serial3/0/1:0] quit

Verifying the configuration

# Display summary information about Serial 3/0/1:0 on Router B.

[RouterB] display interface serial 3/0/1:0 brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface            Link Protocol Primary IP      Description

Ser3/0/1:0             UP   UP       200.1.1.10

The output shows Serial 3/0/1:0 obtains IP address 200.1.1.10 through PPP negotiation.

# Verify that Router B can ping Serial 3/0/1:0 of Router A.

[RouterB] ping 200.1.1.1

Ping 200.1.1.1 (200.1.1.1): 56 data bytes, press CTRL+C to break

56 bytes from 200.1.1.1: icmp_seq=0 ttl=128 time=3.197 ms

56 bytes from 200.1.1.1: icmp_seq=1 ttl=128 time=2.594 ms

56 bytes from 200.1.1.1: icmp_seq=2 ttl=128 time=2.739 ms

56 bytes from 200.1.1.1: icmp_seq=3 ttl=128 time=1.738 ms

56 bytes from 200.1.1.1: icmp_seq=4 ttl=128 time=1.744 ms

 

--- Ping statistics for 200.1.1.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.738/2.402/3.197/0.576 ms

Example: Specifying an IP address pool on the server interface

Network configuration

As shown in Figure 6, configure Router A to allocate an IP address from the IP address pool on an interface of Router A to Serial 3/0/1:0 of Router B through PPP negotiation.

Figure 6 Network diagram

Procedure

1.     Configure Router A:

# Enable DHCP.

<RouterA> system-view

[RouterA] dhcp enable

# Create IP address pool pool1, and specify the subnet for dynamic allocation and a gateway address in the address pool.

[RouterA] ip pool pool1

[RouterA-ip-pool-pool1] network 200.1.1.0 24

[RouterA-ip-pool-pool1] gateway-list 200.1.1.1

# Exclude IP address 200.1.1.1 from dynamic allocation in the address pool.

[RouterA-ip-pool-pool1] forbidden-ip 200.1.1.1

[RouterA-ip-pool-pool1] quit

# Configure Serial 3/0/1:0 to assign an IP address from IP address pool pool1 to the peer interface.

[RouterA] interface serial 3/0/1:0

[RouterA-Serial3/0/1:0] remote address pool pool1

# Configure an IP address for Serial 3/0/1:0.

[RouterA-Serial3/0/1:0] ip address 200.1.1.1 16

[RouterA-Serial3/0/1:0] quit

2.     Enable IP address negotiation on Serial 3/0/1:0 of Router B.

<RouterB> system-view

[RouterB] interface serial 3/0/1:0

[RouterB-Serial3/0/1:0] ip address ppp-negotiate

[RouterB-Serial3/0/1:0] quit

Verifying the configuration

# Display summary information about Serial 3/0/1:0 on Router B.

[RouterB] display interface serial 3/0/1:0 brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface            Link Protocol Primary IP      Description

Ser3/0/1:0             UP   UP       200.1.1.2

The output shows that Serial 3/0/1:0 has obtained IP address 200.1.1.2 through PPP negotiation.

# Verify that Router B can ping Serial 3/0/1:0 of Router A.

[RouterB] ping 200.1.1.1

Ping 200.1.1.1 (200.1.1.1): 56 data bytes, press CTRL+C to break

56 bytes from 200.1.1.1: icmp_seq=0 ttl=128 time=3.197 ms

56 bytes from 200.1.1.1: icmp_seq=1 ttl=128 time=2.594 ms

56 bytes from 200.1.1.1: icmp_seq=2 ttl=128 time=2.739 ms

56 bytes from 200.1.1.1: icmp_seq=3 ttl=128 time=1.738 ms

56 bytes from 200.1.1.1: icmp_seq=4 ttl=128 time=1.744 ms

--- Ping statistics for 200.1.1.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.738/2.402/3.197/0.576 ms

# Display binding information about assigned IP addresses on Router A.

[RouterA] display dhcp server ip-in-use

IP address       Client identifier/    Lease expiration      Type

                 Hardware address

200.1.1.2        0030-3030-302e-3030-  Unlimited             Auto(C)

                 3030-2e30-3030-362d

The output shows that one IP address of the IP address pool has been assigned.

Example: Using the IP address pool associated with an ISP domain

Network configuration

As shown in Figure 7, configure Router A to allocate an IP address from the IP address pool associated with the ISP domain to Serial 3/0/1:0 of Router B through PPP negotiation.

Figure 7 Network diagram

Procedure

1.     Configure Router A:

# Enable DHCP.

<RouterA> system-view

[RouterA] dhcp enable

# Create IP address pool pool1, and specify the subnet for dynamic allocation and a gateway address in the address pool.

[RouterA] ip pool pool1

[RouterA-ip-pool-pool1] network 200.1.1.0 24

[RouterA-ip-pool-pool1] gateway-list 200.1.1.1

# Exclude IP address 200.1.1.1 from dynamic allocation in the address pool.

[RouterA-ip-pool-pool1] forbidden-ip 200.1.1.1

[RouterA-ip-pool-pool1] quit

# Create a local user for Router B.

[RouterA] local-user userb class network

# Set a password for the local user.

[RouterA-luser-network-userb] password simple 123456TESTplat&!

# Set the service type to PPP for the local user.

[RouterA-luser-network-userb] service-type ppp

[RouterA-luser-network-userb] quit

# Create ISP domain dm1 and associate the ISP domain with IP address pool pool1.

[RouterA] domain name dm1

[RouterA-isp-dm1] authorization-attribute ip-pool pool1

[RouterA-isp-dm1] quit

# Configure Serial 3/0/1:0 to authenticate the peer interface in ISP domain dm1 by using PAP.

[RouterA] interface serial 3/0/1:0

[RouterA-Serial3/0/1:0] ppp authentication-mode pap domain dm1

# Configure an IP address for Serial 3/0/1:0.

[RouterA-Serial3/0/1:0] ip address 200.1.1.1 16

[RouterA-Serial3/0/1:0] quit

2.     Configure Router B:

# On Serial 3/0/1:0, configure the username and password for PAP authentication by Router A.

<RouterB> system-view

[RouterB] interface serial 3/0/1:0

[RouterB-Serial3/0/1:0] ppp pap local-user userb password simple 123456TESTplat&!

# Enable IP address negotiation on Serial 3/0/1:0.

<RouterB> system-view

[RouterB] interface serial 3/0/1:0

[RouterB-Serial3/0/1:0] ip address ppp-negotiate

[RouterB-Serial3/0/1:0] quit

Verifying the configuration

# Display summary information about Serial 3/0/1:0 on Router B.

[RouterB] display interface serial 3/0/1:0 brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface            Link Protocol Primary IP      Description

Ser3/0/1:0             UP   UP       200.1.1.2

The output shows that Serial 3/0/1:0 has obtained IP address 200.1.1.2 through PPP negotiation.

# Verify that Router B can ping Serial 3/0/1:0 of Router A.

[RouterB-Serial3/0/1:0] ping 200.1.1.1

Ping 200.1.1.1 (200.1.1.1): 56 data bytes, press CTRL+C to break

56 bytes from 200.1.1.1: icmp_seq=0 ttl=128 time=3.197 ms

56 bytes from 200.1.1.1: icmp_seq=1 ttl=128 time=2.594 ms

56 bytes from 200.1.1.1: icmp_seq=2 ttl=128 time=2.739 ms

56 bytes from 200.1.1.1: icmp_seq=3 ttl=128 time=1.738 ms

56 bytes from 200.1.1.1: icmp_seq=4 ttl=128 time=1.744 ms

 

--- Ping statistics for 200.1.1.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.738/2.402/3.197/0.576 ms

# Display binding information about assigned IP addresses on Router A.

[RouterA] display dhcp server ip-in-use

IP address       Client identifier/    Lease expiration      Type

                 Hardware address

200.1.1.2        0030-3030-302e-3030-  Unlimited             Auto(C)

                 3030-2e30-3030-362d

The output shows that one IP address of the IP address pool has been assigned.

 

 


Configuring MP

About MP

Multilink PPP (MP) allows you to bind multiple PPP links into one MP bundle for increasing bandwidth. If a packet is larger than the minimum packet size for fragmentation, MP fragments the packet and distributes the fragments across multiple PPP links to the peer. The peer reassembles them into one packet and passes the packet to the network layer.

Benefit

In addition to increasing bandwidth, MP also provides link-layer load sharing, which can implement backup. MP fragmentation can reduce transmission delay, especially on low-speed links.

Interface type

MP is available on all physical or virtual interfaces with PPP encapsulation enabled, including serial and PPPoX (PPPoE) interfaces. In MP configuration, however, as a best practice, include only one type of interfaces in an MP bundle.

MP tasks at a glance

To configure MP, perform the following tasks:

1.     Configuring MP through an MP-group interface

2.     (Optional.) Configuring short sequence number header format negotiation

3.     (Optional.) Configuring the MP endpoint discriminator

4.     (Optional.) Enabling SNMP notifications for MP packet loss

Configuring MP through an MP-group interface

About MP-group interfaces

MP-group interfaces are intended only for MP. On an MP-group interface, only one bundle is allowed, and links cannot be bundled according to the peer discriminator.

Tasks at a glance

To configure MP by using through an MP-group interface, perform the following tasks:

1.     Creating an MP-group interface

2.     Assigning a physical interface to the MP-group interface

3.     (Optional.) Configuring the polling feature on the MP-group interface

4.     (Optional.) Configuring MP parameters

5.     (Optional.) Restoring the default settings for the MP-group interface

Creating an MP-group interface

1.     Enter system view.

system-view

2.     Create an MP-group interface and enter its view.

interface mp-group mp-number

3.     (Optional.) Set the interface description.

description text

The default setting is interface name Interface, for example, MP-group3/0/1 Interface.

4.     (Optional.) Set the MTU size of the interface.

mtu size

The default setting is 1500 bytes.

5.     (Optional.) Set the expected bandwidth of the interface.

bandwidth bandwidth-value

By default, the expected bandwidth (in kbps) is the interface baud rate divided by 1000.

6.     (Optional.) Bring up the interface.

undo shutdown

By default, an interface is up.

Assigning a physical interface to the MP-group interface

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Assign the interface to a specified MP-group interface, and enable MP for the interface.

ppp mp mp-group mp-number

By default, an interface is enabled with PPP.

Configuring the polling feature on the MP-group interface

About this task

MP-group interfaces use the polling feature to check link state.

A MP-group interface sends keepalives at keepalive intervals to detect the availability of the peer. If the interface fails to receive keepalives when the keepalive retry limit is reached, it tears down the link and reports a link layer down event.

To set the keepalive retry limit, use the timer-hold retry command.

The keepalive interval of 0 disables sending of keepalives.

Restrictions and guidelines

On a slow link, increase the keepalive interval to prevent false shutdown of the interface. This situation might occur when keepalives are delayed because a large packet is being transmitted on the link.

Procedure

1.     Enter system view.

system-view

2.     Enter MP-group interface view.

interface mp-group mp-number

3.     Set the keepalive interval.

timer-hold seconds

The default setting is 10 seconds.

4.     Set the keepalive retry limit.

timer-hold retry retries

The default setting is 5.

Configuring MP parameters

1.     Enter system view.

system-view

2.     Enter MP-group interface or dialer interface view.

interface mp-group mp-number

3.     (Optional.) Set the maximum number of links in an MP bundle.

ppp mp max-bind max-bind-num

The default is 31.

The configuration takes effect after you execute the shutdown and undo shutdown command on the interface.

4.     (Optional.) Set the minimum size of MP fragments.

ppp mp min-fragment size

The default setting is 128 bytes.

5.     (Optional.) Configure the timer for MP to wait for the expected fragment.

ppp mp timer lost-fragment seconds

By default, the timer is 30 seconds.

6.     (Optional.) Disable MP fragmentation.

ppp mp fragment disable

By default, MP fragmentation is enabled.

7.     (Optional.) Enable the strict load sharing mode.

ppp mp load-sharing mode strict-round-robin

By default, an MP-group interface uses the smart load sharing mode.

Restoring the default settings for the MP-group interface

Restrictions and guidelines

The default command might interrupt ongoing network services. Make sure you are fully aware of the impact of this command when you execute it on a live network.

The default command might fail to restore the default settings for some commands for reasons such as command dependencies or system restrictions. Use the display this command in interface view to identify these commands. Use the undo forms of these commands or follow the command reference to individually restore their default settings. If your restoration attempt still fails, follow the error message instructions to resolve the problem.

Procedure

1.     Enter system view.

system-view

2.     Enter MP-group interface view.

interface mp-group mp-number

3.     Restore the default settings for the interface.

default

Configuring short sequence number header format negotiation

About this task

By default, an MP bundle receives and transmits fragments with long sequence numbers.

Restrictions and guidelines

Configure this feature on the local end or peer that receives fragments with short sequence numbers.

·     To receive fragments with short sequence numbers, the local end should request the peer to transmit short sequence numbers during LCP negotiation. After the negotiation succeeds, the peer transmits fragments with short sequence numbers.

·     To transmit fragments with short sequence numbers, the local end should ask the peer to send a request for receiving short sequence numbers during LCP negotiation. After the negotiation succeeds, the local end transmits fragments with short sequence numbers.

The sequence number format (long or short) of an MP bundle depends on the configuration of the first channel joining the MP bundle.

To negotiate the use of short sequence numbers on an MP bundle, configure this feature on all its channels.

Configuring this feature will cause PPP re-negotiation.

Procedure

1.     Enter system view

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Trigger MP short sequence number header negotiation, specifying that the interface receive fragments with short sequence numbers after the negotiation succeeds.

ppp mp short-sequence

By default, long sequence number header format negotiation is performed.

Configuring the MP endpoint discriminator

About this task

When MP is configured by using an MP-group interface, the negotiating endpoints do not base their binding decisions on the endpoint discriminator. By default, the endpoint discriminator of an interface in an MP-group interface is the MP-group interface name. When you configure an endpoint discriminator for the interface, the configured MP endpoint discriminator takes effect.

If the endpoint discriminator exceeds 20 bytes, the first 20 bytes are taken as the endpoint discriminator.

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Configure the MP endpoint discriminator.

ppp mp endpoint endpoint

The endpoint option carries the device name on an interface.

Enabling SNMP notifications for MP packet loss

About this task

With SNMP notifications enabled for MP packet loss, when the lost packets of all MP bundle links on the device meet the alarm threshold conditions, traps are generated. The generated traps are sent to the SNMP module of the device. You can specify how the traps are output through setting the trap output parameters in SNMP. For more information about traps, see SNMP configuration in Network Management and Monitoring Configuration Guide.

The alarm triggering threshold is calculated by using the xE-y formula, where E is 10.

For this feature, packet loss occurs when a packet received on the local end is dropped because the packet is invalid (for example, the packet fails to be reassembled because a fragment is dropped).

After you enable SNMP notifications for MP packet loss, the following rules apply within a statistics polling interval (configured by using the flow-interval command) in system view:

·     When the packet loss ratio (total number of lost packets/total number of received packets) of all MP bundle links on the device is equal to or greater than the packet loss ratio alarm triggering threshold, traps are generated.

·     When the packet loss ratio (total number of lost packets/total number of received packets) of all MP bundle links on the device is equal to or less than the packet loss ratio alarm clearing threshold, alarm clearing traps are generated.

Restrictions and guidelines

Both the snmp-agent trap enable mp command and the snmp-agent trap enable mp loss-packet-alarm command can enable SNMP notifications for MP packet loss.

Make sure the packet loss ratio alarm triggering threshold is greater than the packet loss ratio alarm clearing threshold.

Procedure

1.     Enter system view.

system-view

2.     Enable SNMP notifications for MP packet loss.

snmp-agent trap enable mp [ loss-packet-alarm ]

By default, the SNMP notifications are disabled for MP packet loss.

3.     Set the MP packet loss ratio alarm thresholds.

ppp mp loss-packet-threshold alarm coefficient-value exponent-value resume resume-coefficient-value resume-exponent-value

By default, the packet loss ratio alarm triggering threshold is 3*10-5, and the packet loss ratio alarm clearing threshold is 1*10-5.

If you execute this command multiple times, the most recent configuration takes effect.

Display and maintenance commands for MP

Execute display commands in any view and reset commands in user view.

 

Task

Command

Display information about one or all MP-group interfaces.

display interface [ mp-group [ interface-number ] ] [ brief [ description | down ] ]

Display MP information.

display ppp mp [ interface interface-type interface-number ]

Clear the statistics for MP-group interfaces.

reset counters interface [ mp-group [ interface-number ] ]

MP configuration examples

Example: Configuring an MP-group interface

Network configuration

As shown in Figure 8, to enable MP for Serial 3/0/1:0 and Serial3/0/2:0, configure an MP-group interface.

Figure 8 Network diagram

Procedure

1.     Configure Router A:

# Create an MP-group interface, and configure an IP address for it.

<RouterA> system-view

[RouterA] interface mp-group 3/0/1

[RouterA-MP-group3/0/1] ip address 1.1.1.1 24

# Configure interface Serial 3/0/1:0.

[RouterA-MP-group3/0/1] quit

[RouterA] interface serial 3/0/1:0

[RouterA-Serial3/0/1:0] link-protocol ppp

[RouterA-Serial3/0/1:0] ppp mp mp-group 3/0/1

[RouterA-Serial3/0/1:0] shutdown

[RouterA-Serial3/0/1:0] undo shutdown

[RouterA-Serial3/0/1:0] quit

# Configure interface Serial3/0/2:0.

[RouterA] interface serial 3/0/2:0

[RouterA-Serial3/0/2:0] link-protocol ppp

[RouterA-Serial3/0/2:0] ppp mp mp-group 3/0/1

[RouterA-Serial3/0/2:0] shutdown

[RouterA-Serial3/0/2:0] undo shutdown

[RouterA-Serial3/0/2:0] quit

2.     Configure Router B:

# Create an MP-group interface, and configure an IP address for it.

[RouterB] interface mp-group 3/0/1

[RouterB-MP-group3/0/1] ip address 1.1.1.2 24

[RouterB-MP-group3/0/1] quit

# Configure interface Serial 3/0/1:0.

[RouterB] interface serial 3/0/1:0

[RouterB-Serial3/0/1:0] link-protocol ppp

[RouterB-Serial3/0/1:0] ppp mp mp-group 3/0/1

[RouterB-Serial3/0/1:0] shutdown

[RouterB-Serial3/0/1:0] undo shutdown

[RouterB-Serial3/0/1:0] quit

# Configure interface Serial3/0/2:0.

[RouterB] interface serial 3/0/2:0

[RouterB-Serial3/0/2:0] link-protocol ppp

[RouterB-Serial3/0/2:0] ppp mp mp-group 3/0/1

[RouterB-Serial3/0/2:0] shutdown

[RouterB-Serial3/0/2:0] undo shutdown

[RouterB-Serial3/0/2:0] quit

Verifying the configuration

# Display MP information on Router A.

[RouterA] display ppp mp

Template: MP-group3/0/1

max-bind: 16, fragment: enabled, min-fragment: 128

Master link: MP-group3/0/1, Active members: 2, Bundle Multilink

Peer's endPoint descriptor: MP-group3/0/1

Sequence format: short (rcv)/long (sent)

Bundle Up Time: 2019/11/04  09:03:16:612

0 lost fragments, 0 reordered, 0 unassigned, 0 interleaved

Sequence: 0 (rcvd)/0 (sent)

Active member channels: 2 members

      Serial3/0/1:0               Up-Time:2019/11/04  09:03:16:613

      Serial3/0/2:0               Up-Time:2019/11/04  09:03:42:945

# Display information about interface MP-group 3/0/1 on Router A.

[RouterA] display interface mp-group 3/0/1

MP-group3/0/1

Current state: UP

Line protocol state: UP

Description: MP-group3/0/1 Interface

Bandwidth: 2048kbps

Maximum transmission unit: 1500

Hold timer: 10 seconds, retry times: 5

Internet address: 1.1.1.1/24 (primary)

Link layer protocol: PPP

LCP: opened, MP: opened, IPCP: opened

Physical: MP, baudrate: 2048000 bps

Last link flapping: Never

Last clearing of counters: Never

Last 300 seconds input rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Last 300 seconds output rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Input: 2 packets, 80 bytes, 0 drops

Output: 2 packets, 24 bytes, 0 drops

# Ping Router B from Router A.

[RouterA] ping 1.1.1.2

Ping 1.1.1.2 (1.1.1.2): 56 data bytes, press CTRL+C to break

56 bytes from 1.1.1.2: icmp_seq=0 ttl=255 time=4.000 ms

56 bytes from 1.1.1.2: icmp_seq=1 ttl=255 time=1.000 ms

56 bytes from 1.1.1.2: icmp_seq=2 ttl=255 time=0.000 ms

56 bytes from 1.1.1.2: icmp_seq=3 ttl=255 time=7.000 ms

56 bytes from 1.1.1.2: icmp_seq=4 ttl=255 time=1.000 ms

 

--- Ping statistics for 1.1.1.2 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.000/2.600/7.000/2.577 ms

 


 

  • Cloud & AI
  • InterConnect
  • Intelligent Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become A Partner
  • Partner Policy & Program
  • Global Learning
  • Partner Sales Resources
  • Partner Business Management
  • Service Business
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网