- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
01-PPP配置
本章节下载： 01-PPP配置 (708.22 KB)
PPP（Point-to-Point Protocol，点对点协议）是一种点对点的链路层协议。它能够提供用户认证，易于扩充，并且支持同/异步通信。
PPP定义了一整套协议，包括：
· 链路控制协议（Link Control Protocol，LCP）：用来建立、拆除和监控数据链路。
· 网络控制协议（Network Control Protocol，NCP）：用来协商在数据链路上所传输的网络层报文的一些属性和类型。
· 认证协议：用来对用户进行认证，包括PAP（Password Authentication Protocol，密码认证协议）、CHAP（Challenge Handshake Authentication Protocol，质询握手认证协议）、MSCHAP（Microsoft CHAP，微软CHAP协议）和MSCHAPv2（微软CHAP协议版本2）。
PPP协议处于TCP/IP的数据链路层，主要用在支持全双工的同异步链路上，进行点到点之间的数据传输。
图1-1 PPP在协议栈中的位置
PPP主要由以下几类协议族组成：
· 链路控制协议族，主要用来建立、拆除和监控PPP数据链路。
· 网络层控制协议族，主要用来协商在该数据链路上所传输的数据包的格式与类型。
· PPP扩展协议族，主要用于提供对PPP功能的进一步支持。例如，PPP提供了用于网络安全方面的认证协议族CHAP和PAP。
PPP报文封装格式如图1-2所示。
图1-2 PPP报文格式
· Flag域
Flag域标识一个物理帧的起始和结束，该字节为0x7E。
· Address域
Address域可以唯一标识对端。PPP协议是被运用在点对点的链路上，因此，使用PPP协议互连的两个通信设备无须知道对方的数据链路层地址。按照协议的规定将该字节填充为全1的广播地址，对于PPP协议来说，该字段无实际意义。
· Control域
该字段缺省值为0x03，表明为无序号帧，PPP默认没有采用序列号和确认机制来实现可靠传输。
Address和Control域一起标识此报文为PPP报文，即PPP报文头为FF03。
· Protocol域
Protocol域可用来区分PPP数据帧中信息域所承载的数据包类型。
Protocol域的内容必须依据ISO 3309的地址扩展机制所给出的规定。该机制规定协议域所填充的内容必须为奇数，也就是要求最低有效字节的最低有效位为“1”，最高有效字节的最低有效位为“0”。
如果当发送端发送的PPP数据帧的协议域字段不符合上述规定，接收端则会认为此数据帧是不可识别的。接收端向发送端发送一个Protocol-Reject报文，在该报文尾部将填充被拒绝报文的协议号。
表1-1 常见协议代码
|
协议代码 |
协议类型 |
|
0021 |
Internet Protocol |
|
002b |
Novell IPX |
|
002d |
Van Jacobson Compressed TCP/IP |
|
002f |
Van Jacobson Uncompressed TCP/IP |
|
8021 |
Internet Protocol Control Protocol |
|
802b |
Novell IPX Control Protocol |
|
8031 |
Bridging NC |
|
C021 |
Link Control Protocol |
|
C023 |
Password Authentication Protocol |
|
C223 |
Challenge Handshake Authentication Protocol |
· Information域
Information域最大长度是1500字节，其中包括填充域的内容。Information域的最大长度称为最大接收单元MRU（Maximum Receive Unit）。MRU的缺省值为1500字节，在实际应用当中可根据实际需要进行MRU的协商。
如果Information域长度不足，可被填充，但不是必须的。如果填充则需通信双方的两端能辨认出填充信息和真正需要传送的信息，方可正常通信。
· FCS域
FCS域的功能主要对PPP数据帧传输的正确性进行检测。
在数据帧中引入了一些传输的保证机制，会引入更多的开销，这样可能会增加应用层交互的延迟。
LCP报文封装格式请参见PPP报文封装的帧格式
。
在链路建立阶段，PPP协议通过LCP报文进行链路的建立和协商。此时LCP报文作为PPP的净载荷被封装在PPP数据帧的Information域中，PPP数据帧的协议域的值固定填充0xC021。
在链路建立阶段的整个过程中信息域的内容是变化的，它包括很多种类型的报文，所以这些报文也要通过相应的字段来区分。
· Code域
Code域的长度为一个字节，主要是用来标识LCP数据报文的类型。
在链路建立阶段，接收方接收到LCP数据报文。当其Code域的值无效时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。
表1-2 常见code值
|
code值 |
报文类型 |
|
0x01 |
Configure-Request |
|
0x02 |
Configure-Ack |
|
0x03 |
Configure-Nak |
|
0x04 |
Configure-Reject |
|
0x05 |
Terminate-Request |
|
0x06 |
Terminate-Ack |
|
0x07 |
Code-Reject |
|
0x08 |
Protocol-Reject |
|
0x09 |
Echo-Request |
|
0x0A |
Echo-Reply |
|
0x0B |
Discard-Request |
|
0x0C |
Reserved |
· Identifier域
Identifier域为1个字节，用来匹配请求和响应，当Identifier域值为非法时，该报文将被丢弃。
通常一个配置请求报文的ID是从0x01开始逐步加1的。当对端接收到该配置请求报文后，无论使用何种报文回应对方，但必须要求回应报文中的ID要与接收报文中的ID一致。
· Length域
Length域的值就是该LCP报文的总字节数据。它是Code域、Identifier域、Length域和Data域四个域长度的总和。
Length域所指示字节数之外的字节将被当作填充字节而忽略掉，而且该域的内容不能超过MRU的值。
· Data域
Data域所包含的是协商报文的内容，这个内容包含以下字段。
¡ Type为协商选项类型。
¡ Length为协商选项长度，它是指Data域的总长度，也就是包含Type、Length和Data。
¡ Data为协商选项的详细信息。
表1-3 常见Type中的协商类型值
|
协商类型值 |
协商报文类型 |
|
0x01 |
Maximum-Receive-Unit |
|
0x02 |
Async-Control-Character-Map |
|
0x03 |
Authentication-Protocol |
|
0x04 |
Quality-Protocol |
|
0x05 |
Magic-Number |
|
0x06 |
RESERVED |
|
0x07 |
Protocol-Field-Compression |
|
0x08 |
Address-and-Control-Field-Compression |
PPP链路建立过程如图1-3所示：
(1) PPP初始状态为不活动（Dead）状态，当物理层Up后，PPP会进入链路建立（Establish）阶段。
(2) PPP在Establish阶段主要进行LCP协商。LCP协商内容包括：Authentication-Protocol（认证协议类型）、MRU（Maximum-Receive-Unit，最大接收单元）、Magic-Number（魔术字）、PFC（Protocol-Field-Compression，协议字段压缩）、ACFC（Address-and-Control-Field-Compression，地址控制字段压缩）等选项。如果LCP协商失败，LCP会上报Fail事件，PPP回到Dead状态；如果LCP协商成功，LCP进入Opened状态，LCP会上报Up事件，表示链路已经建立（此时对于网络层而言PPP链路还未建立，还不能够在上面成功传输网络层报文）。
(3) 如果配置了认证，则进入Authenticate阶段，开始PAP、CHAP、MSCHAP或MSCHAPv2认证。如果认证失败，LCP会上报Fail事件，进入Terminate阶段，拆除链路，LCP状态转为Down，PPP回到Dead状态；如果认证成功，LCP会上报Success事件。
(4) 如果配置了网络层协议，则进入Network协商阶段，进行NCP协商（如IPCP协商、IPv6CP协商）。如果NCP协商成功，链路就会UP，就可以开始承载协商指定的网络层报文；如果NCP协商失败，NCP会上报Down事件，进入Terminate阶段。（对于IPCP协商，如果接口配置了IP地址，则进行IPCP协商，IPCP协商通过后，PPP才可以承载IP报文。IPCP协商内容包括：IP地址、DNS服务器地址等。）
(5) 到此，PPP链路将一直保持通信，直至有明确的LCP或NCP消息关闭这条链路，或发生了某些外部事件（例如用户的干预）。
图1-3 PPP链路建立过程
Dead阶段也称为物理层不可用阶段。PPP链路都需从这个阶段开始和结束。
当通信双方的两端检测到物理线路激活（通常是检测到链路上有载波信号）时，就会从Dead阶段进入Establish阶段，即链路建立阶段。
链路被断开后也同样会返回到链路不可用阶段。
在Establish阶段，PPP链路进行LCP协商。协商内容包括工作方式是SP（Single-link PPP）还是MP（Multilink PPP）、最大接收单元MRU、认证方式和魔术字（Magic-Number）等选项。当完成配置报文的交换后，则会继续进入下一个阶段。
链路建立完成后，可以根据链路两端设备的配置，选择下一个阶段进入认证阶段或网络层协议阶段。这个选择取决于用户在链路两端设备进行的配置。
在Establish阶段，LCP的状态机会发生如下改变。
· 当链路处于不可用阶段时，此时LCP的状态机处于初始化Initial状态或准备启动Starting状态。当检测到链路可用时，则物理层会向链路层发送一个Up事件。链路层收到该事件后，会将LCP的状态机从当前状态改变为Request-Sent（请求发送）状态，根据此时的状态机LCP会进行相应的动作，也就是开始发送Configure-Request报文来配置数据链路。
· 如果本端设备先收到Configure-Ack报文，则LCP的状态机从Request-Sent状态改变为Ack-Received状态，本端向对端发送Configure-Ack报文以后，LCP的状态机从Ack-Received状态改变为Open状态。
· 如果本端设备先向对端发送Configure-Ack报文，则LCP的状态机从Request-Sent状态改变为Ack-Sent状态，本端收到对端发送的Configure-Ack报文以后，LCP的状态机从Ack-Sent状态改变为Open状态。
· LCP状态机变为Open状态以后就完成当前阶段的协商，并继续进入下一个阶段。
缺省情况下，PPP链路不进行认证。如果要求认证，在链路建立阶段必须指定认证协议。
PPP提供密码认证协议PAP和质询握手认证协议CHAP两种认证方式。
PPP的认证方式可以分为单向认证和双向认证：
· 单向认证是指一端作为认证方，另一端作为被认证方。
· 双向认证是单向认证的简单叠加，即两端都是既作为认证方又作为被认证方。
PAP认证方式为两次握手认证，采用简单口令。
PAP认证的过程如图1-4所示。
图1-4 PAP认证过程
(3) 认证方根据本地用户表查看是否有被认证方的用户名
¡ 若有，则查看口令是否正确，
- 若口令正确，则认证通过；
- 若口令不正确，则认证失败。
¡ 若没有，则认证失败。
PAP报文封装在协议域为0xC023的PPP数据链路层帧的信息域中。PAP报文的帧格式如图1-5所示。
PAP认证报文帧格式中各字段的含义如表1-4所示。
表1-4 PAP认证报文帧格式各字段解释表
|
字段 |
长度（字节） |
|
Code |
1 |
|
Identifier |
1 |
|
Length |
2 |
|
Data |
0或者多个字节 |
CHAP认证方式为三次握手认证协议。它只在网络上传输用户名，而并不传输用户密码，因此安全性要比PAP高。
CHAP的认证过程如图1-6所示。
CHAP单向认证过程分为两种情况：认证方配置了用户名和认证方未配置用户名。推荐使用认证方配置了用户名的方式，这样可以对认证方的用户名进行确认。
· 认证方配置了用户名的认证过程
a. 认证方主动发起认证请求，构造一个包含随机数的报文，并同时附带本端的用户名发送给被认证方（Challenge）。
b. 被认证方接到认证方的认证请求后，先检查本端接口上是否配置了CHAP密码。
- 如果接口配置了CHAP密码，则根据报文ID、CHAP密码和报文中的随机数，利用Hash算法计算Hash值，将所得Hash值和被认证方自己的用户名发回认证方（Response）。
- 如果接口未配置CHAP密码，则根据此报文中认证方的用户名在本端的用户表查找该用户对应的密码，根据报文ID、此用户密码和报文中的随机数，利用Hash算法计算Hash值，将所得Hash值和被认证方自己的用户名发回认证方（Response）。
c. 认证方先根据收到的报文中被认证方的用户名在本端查找到该用户对应的密码，然后再根据报文ID、被认证方密码和Challenge报文中的随机数，利用Hash算法计算Hash值，并与Response报文中的Hash值进行比较，若比较结果一致，认证通过，若比较结果不一致，认证失败。
· 认证方未配置用户名的认证过程
d. 认证方主动发起认证请求，向被认证方发送一个包含随机数的报文（Challenge）。
e. 被认证方接到认证方的认证请求后，根据报文ID、配置的CHAP密码和报文中的随机数，利用Hash算法计算Hash值，将所得Hash值和自己的用户名发回认证方（Response）。
f. 认证方先根据收到的报文中被认证方的用户名在本端查找到该用户对应的密码，然后再根据报文ID、被认证方密码和报文中的随机数，利用Hash算法计算Hash值，并与Response报文中的Hash值进行比较，若比较结果一致，认证通过，若比较结果不一致，认证失败。
CHAP报文封装在协议域为0xC223的PPP数据链路层帧的信息域中。CHAP报文的帧格式如图所示。
CHAP认证报文帧格式中各字段的含义如表1-5所示。
表1-5 CHAP认证报文帧格式各字段解释表
|
字段 |
长度（字节） |
|
Code |
1 |
|
Identifier |
1 |
|
Length |
2 |
|
Data |
0或者多个字节 |
CHAP与PAP认证存在如下差异：
· PAP认证中，在链路上发送简单口令，完成PPP链路建立后，被认证方会不停地在链路上反复发送用户名和口令，直到身份认证过程结束，所以安全性不高。当实际应用过程中，对安全性要求不高时，可以采用PAP认证建立PPP连接。
· CHAP认证中，认证协议为三次握手认证协议。它只在网络上传输用户名，而并不传输用户密码，因此安全性比PAP认证高。当实际应用过程中，对安全性要求较高时，可以采用CHAP认证建立PPP连接。
PPP完成了前面几个阶段，通过NCP协商来选择和配置一个网络层协议并进行网络层参数协商。每个NCP协议可在任何时间打开和关闭，当一个NCP的状态机变成Open状态时，则PPP就可以开始在链路上承载网络层数据传输。
PPP能在任何时候终止链路。当载波丢失、认证失败或管理员人为关闭链路等情况均会导致链路终止。
PPP提供了在其链路上进行安全认证的手段，使得在PPP链路上实施AAA变的切实可行。将PPP与AAA结合，可在PPP链路上对对端用户进行认证、计费。
PPP支持如下认证方式：PAP、CHAP、MSCHAP、MSCHAPv2。
PAP为两次握手协议，它通过用户名和密码来对用户进行认证。
PAP在网络上以明文的方式传递用户名和密码，认证报文如果在传输过程中被截获，便有可能对网络安全造成威胁。因此，它适用于对网络安全要求相对较低的环境。
CHAP为三次握手协议。
CHAP认证过程分为两种方式：认证方配置了用户名、认证方未配置用户名。推荐使用认证方配置用户名的方式，这样被认证方可以对认证方的身份进行确认。
CHAP只在网络上传输用户名，并不传输用户密码（准确的讲，它不直接传输用户密码，传输的是用MD5算法将用户密码与一个随机报文ID一起计算的结果），因此它的安全性要比PAP高。
MSCHAP为三次握手协议，认证过程与CHAP类似，MSCHAP与CHAP的不同之处在于：
· MSCHAP采用的加密算法是0x80。
· MSCHAP支持重传机制。在被认证方认证失败的情况下，如果认证方允许被认证方进行重传，被认证方会将认证相关信息重新发回认证方，认证方根据此信息重新对被认证方进行认证。认证方最多允许被认证方重传3次。
MSCHAPv2为三次握手协议，认证过程与CHAP类似，MSCHAPv2与CHAP的不同之处在于：
· MSCHAPv2采用的加密算法是0x81。
· MSCHAPv2通过报文捎带的方式实现了认证方和被认证方的双向认证。
· MSCHAPv2支持重传机制。在被认证方认证失败的情况下，如果认证方允许被认证方进行重传，被认证方会将认证相关信息重新发回认证方，认证方根据此信息重新对被认证方进行认证。认证方最多允许被认证方重传3次。
· MSCHAPv2支持修改密码机制。被认证方由于密码过期导致认证失败时，被认证方会将用户输入的新密码信息发回认证方，认证方根据新密码信息重新进行认证。
在IPv4网络中，PPP进行IPCP协商过程中可以进行IP地址、DNS服务器地址的协商。
PPP在进行IPCP协商的过程中可以进行IP地址的协商，即一端给另一端分配IP地址。
在PPP协商IP地址的过程中，设备可以分为两种角色：
· Client端：若本端接口封装的链路层协议为PPP但还未配置IP地址，而对端已有IP地址时，用户可为本端接口配置IP地址可协商属性，使本端接口作为Client端接受由对端（Server端）分配的IP地址。该方式主要用于设备在通过ISP访问Internet时，由ISP分配IP地址。
· Server端：若设备作为Server端为Client端分配IP地址，则应先配置地址池（可以是PPP地址池或者DHCP地址池），然后在ISP域下关联地址池，或者在接口下指定为Client端分配的IP地址或者地址池，最后再配置Server端的IP地址，开始进行IPCP协商。
当Client端配置了IP地址可协商属性后，Server端根据AAA认证结果（关于AAA的介绍请参见“安全配置指导”中的“AAA”）和接口下的配置，按照如下顺序给Client端分配IP地址：
· 如果AAA认证服务器为Client端设置了IP地址或者地址池信息，则Server端将采用此信息为Client端分配IP地址（这种情况下，为Client端分配的IP地址或者分配IP地址所采用的地址池信息是在AAA认证服务器上进行配置的，Server端不需要进行特殊配置）。
· 如果Client端认证时使用的ISP域下设置了为Client端分配IP地址的地址池，则Server端将采用此地址池为Client端分配IP地址。
· 如果Server端的接口下指定了为Client端分配的IP地址或者地址池，则Server端将采用此信息为Client端分配IP地址。
设备在进行IPCP协商的过程中可以进行DNS服务器地址协商。设备既可以作为Client端接收其它设备分配的DNS服务器地址，也可以作为Server端向其它设备提供DNS服务器地址。通常情况下：
· 当主机与设备通过PPP协议相连时，设备应配置为Server端，为对端主机指定DNS服务器地址，这样主机就可以通过域名直接访问Internet；
· 当设备通过PPP协议连接运营商的接入服务器时，设备应配置为Client端，被动接收或主动请求接入服务器指定DNS服务器地址，这样设备就可以使用接入服务器分配的DNS来解析域名。
在IPv6网络中，PPP进行IPv6CP协商过程中，只协商出IPv6接口标识，不能协商出IPv6地址、IPv6 DNS服务器地址。
PPP进行IPv6CP协商过程中，只协商出IPv6接口标识，不能直接协商出IPv6地址。
客户端可以通过如下几种方式分配到IPv6全球单播地址：
· NDRA方式：客户端通过ND协议中的RA报文获得IPv6地址前缀。客户端采用RA报文中携带的前缀和IPv6CP协商的IPv6接口标识一起组合生成IPv6全球单播地址。RA报文中携带的IPv6地址前缀的来源有三种：AAA授权的IPv6前缀、接口下配置的RA前缀、接口下配置的IPv6全球单播地址的前缀。三种来源的优先级依次降低，AAA授权的优先级最高。关于ND协议的详细介绍请参见“三层技术-IP业务配置指导”中的“IPv6基础”。
· DHCPv6（IA_NA）方式：客户端通过DHCPv6协议申请IPv6全球单播地址。在服务器端可以通过AAA授权为每个客户端分配不同的地址池，当授权了地址池后，DHCPv6在分配IPv6地址时会从地址池中获取IPv6地址分配给客户端。如果AAA未授权地址池，DHCPv6会根据服务器端的IPv6地址查找匹配的地址池为客户端分配地址。关于DHCPv6协议的详细介绍请参见“三层技术-IP业务配置指导”中的“DHCPv6”。
· DHCPv6（IA_PD）方式：客户端通过DHCPv6协议申请代理前缀，客户端通过代理前缀为下面的主机分配IPv6全球单播地址。代理前缀分配方式中地址池的选择原则和通过DHCPv6协议分配IPv6全球单播地址方式中地址池的选择原则一致。
根据组网不同，主机获取IPv6地址的方式如下：
· 当主机通过桥设备或者直连接入设备时，设备可以采用上述的方式NDRA方式或IA_NA直接为主机分配IPv6全球单播地址。
· 当主机通过路由器接入设备时，设备可以采用IA_PD方式为路由器分配IPv6前缀，路由器把这些IPv6前缀分配给主机来生成IPv6全球单播地址。
· NDRA+IA_PD、IA_NA+IA_PD可以根据实际组网需求进行组合使用，以满足多种地址分配方式的需求。
在IPv6网络中，IPv6 DNS服务器地址的分配有如下两种方式：
· AAA授权IPv6 DNS服务器地址，通过ND协议中的RA报文将此IPv6 DNS服务器地址分配给主机。
· DHCPv6客户端向DHCPv6服务器申请IPv6 DNS服务器地址。
PPP配置任务如下：
(1) 配置虚拟模板接口
¡ 创建虚拟模板接口
在PPPoE和L2TP组网中，需要本配置。
¡ （可选）恢复当前虚拟模板接口的缺省配置
¡ （可选）配置处理虚拟模板接口流量的slot
(2) 配置PPP认证
请选择以下一项任务进行配置：
¡ 配置PAP认证
在网络安全要求较高的环境下，需要配置PPP认证。
(3) （可选）配置轮询功能
(4) （可选）配置PPP协商参数
¡ 配置ACFC协商
¡ 配置PFC协商
(5) （可选）配置PPP IPHC压缩功能
在低速链路上，每个语音报文中报文头消耗大部分的带宽。为了减少报文头对带宽的消耗，可以在PPP链路上使用IPHC压缩功能，对报文头进行压缩。
(6) （可选）配置PPP用户的nas-port-type属性
(7) （可选）配置PPP计费统计功能
(8) （可选）配置PPP接入用户日志信息功能
VT（Virtual Template，虚拟模板）是用于配置一个VA（Virtual Access，虚拟访问）接口的模板。在PPPoE、L2TP和MP应用中需要创建一个VA接口与对端交换数据。此时，系统将选择一个VT，以便动态地创建一个VA接口。
在PPPoE和L2TP应用中可借助VT接口来实现PPP协议的相关功能。有关PPPoE和L2TP的相关介绍，请参见“二层技术-广域网接入配置指导”中的“PPPoE”和和“VPN配置指导”中的“L2TP”。
(1) 进入系统视图。
system-view
(2) 创建虚拟模板接口并进入虚拟模板接口视图。
interface virtual-template number
(3) （可选）配置接口的描述信息。
description text
缺省情况下，接口的描述信息为“该接口的接口名 Interface”，比如：Virtual-Template1 Interface。
(4) （可选）配置接口的MTU值。
mtu size
缺省情况下，虚拟模板接口的MTU值为1500字节。
(5) （可选）配置接口的期望带宽。
bandwidth bandwidth-value
缺省情况下，接口的期望带宽＝接口的波特率÷1000（kbps）。
接口下的某些配置恢复到缺省情况后，会对设备上当前运行的业务产生影响。建议您在执行该命令前，完全了解其对网络产生的影响。
您可以在执行default命令后通过display this命令确认执行效果。对于未能成功恢复缺省的配置，建议您查阅相关功能的命令手册，手工执行恢复该配置缺省情况的命令。如果操作仍然不能成功，您可以通过设备的提示信息定位原因。
(1) 进入系统视图。
system-view
(2) 进入虚拟模板接口视图。
interface virtual-template number
(3) 恢复当前接口的缺省配置。
default
当要求同一个虚拟模板接口的流量必须在同一个slot上进行处理时，可以在虚拟模板接口下配置处理接口流量的slot。
为提高当前接口处理流量的可靠性，可以通过service命令和service standby命令为接口分别指定一个主用slot和一个备用slot进行流量处理。
接口上同时配置了主用slot和备用slot时，流量处理的机制如下：
· 当主用slot不可用时，流量由备用slot处理。之后，即使主用slot恢复可用，流量也继续由备用slot处理；仅当备用slot不可用时，流量才切换到主用slot。
· 当主用slot和备用slot均不可用时，流量由接收报文的slot处理；之后，主用slot和备用slot谁先恢复可用，流量就由谁处理。
如果接口上未配置主用slot和备用slot，则业务处理在接收报文的slot上进行。
为避免不必要的流量切换，建议配置主用slot后，再配置备用slot。如果先配置备用slot，则流量由备用slot处理；在配置主用slot后，流量将会从备用slot切换到主用slot。
(1) 进入系统视图。
system-view
(2) 进入虚拟模板接口视图。
interface virtual-template number
(3) 配置处理接口流量的主用slot。
service slot slot-number
缺省情况下，未配置处理接口流量的主用slot。
(4) 配置处理接口流量的备用slot。
service standby slot slot-number
缺省情况下，未配置处理接口流量的备用slot。
PPP支持的认证方式包括：PAP、CHAP、MSCHAP、MSCHAPv2。用户可以同时配置多种认证方式，在LCP协商过程中，认证方根据用户配置的认证方式顺序逐一与被认证方进行协商，直到协商通过。如果协商过程中，被认证方回应的协商报文中携带了建议使用的认证方式，认证方查找配置中存在该认证方式，则直接使用该认证方式进行认证。
在认证方上，若采用本地AAA认证，则认证方必须为被认证方配置本地用户的用户名和密码，若采用远程AAA认证，则远程AAA服务器上需要配置被认证方的用户名和密码。
不论是在本地还是AAA服务器上为被认证方配置的用户名和密码必须与被认证方上通过ppp pap local-user命令配置的用户名和密码相同。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置本地认证对端的方式为PAP。
ppp authentication-mode pap [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情况下，PPP协议不进行认证。
(4) 配置本地AAA认证或者远程AAA认证。
具体配置请参见“安全配置指导”中的“AAA”。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置本地被对端以PAP方式认证时本地发送的PAP用户名和密码。
ppp pap local-user username password { cipher | simple } string
缺省情况下，被对端以PAP方式认证时，本地设备发送的用户名和密码均为空。
查看配置的密码信息时，无论采用明文或密文加密，密码都将按密文方式显示。
在认证方上，若采用本地AAA认证，则认证方必须为被认证方配置本地用户的用户名和密码，若采用远程AAA认证，则远程AAA服务器上需要配置被认证方的用户名和密码。
不论是在本地还是AAA服务器上为被认证方配置的用户名和密码必须满足如下要求：
· 用户名必须与被认证方上通过ppp chap user命令配置的被认证方的用户名相同。
· 密码必须与被认证方上为认证方配置的用户名的密码相同。
在被认证方上，若采用本地AAA认证，则被认证方必须为认证方配置本地用户的用户名和密码，若采用远程AAA认证，则远程AAA服务器上需要配置认证方的用户名和密码。
不论是在本地还是AAA服务器上为认证方配置的用户名和密码必须满足如下要求：
· 用户名必须与认证方上通过ppp chap user命令配置的认证方的用户名相同。
· 密码必须与认证方上为被认证方配置的用户名的密码相同。
在被认证方上不能通过ppp chap password命令配置进行CHAP认证时采用的密码，否则即使认证方配置了用户名，CHAP仍将按照认证方未配置用户名的情况进行认证。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置本地认证对端的方式为CHAP。
ppp authentication-mode chap [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情况下，PPP协议不进行认证。
(4) 配置采用CHAP认证时认证方的用户名。
ppp chap user username
缺省情况下，CHAP认证的用户名为空。
(5) 配置本地AAA认证或者远程AAA认证。
具体配置请参见“安全配置指导”中的“AAA”。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置采用CHAP认证时被认证方的用户名。
ppp chap user username
缺省情况下，CHAP认证的用户名为空。
(4) 配置本地AAA认证或者远程AAA认证。
具体配置请参见“安全配置指导”中的“AAA”。
在认证方上，若采用本地AAA认证，则认证方必须为被认证方配置本地用户的用户名和密码，若采用远程AAA认证，则远程AAA服务器上需要配置被认证方的用户名和密码。
不论是在本地还是AAA服务器上为被认证方配置的用户名和密码必须满足如下要求：
· 用户名必须与被认证方上通过ppp chap user命令配置的被认证方的用户名相同。
· 密码必须与被认证方上通过ppp chap password命令配置的密码相同。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置本地认证对端的方式为CHAP。
ppp authentication-mode chap [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情况下，PPP协议不进行认证。
(4) 配置本地AAA认证或者远程AAA认证。
具体配置请参见“安全配置指导”中的“AAA”。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置采用CHAP认证时被认证方的用户名。
ppp chap user username
缺省情况下，CHAP认证的用户名为空。
(4) 设置CHAP认证密码。
ppp chap password { cipher | simple } password
缺省情况下，未配置进行CHAP认证时采用的密码。
查看配置的密码信息时，无论采用明文或密文加密，密码都将按密文方式显示。
设备只能作为MSCHAP和MSCHAPv2的认证方来对其它设备进行认证。
MSCHAPv2认证只有在RADIUS认证的方式下，才能支持修改密码机制。
MSCHAPv2认证时不支持为PPP用户配置认证方式为none。
在认证方上，若采用本地AAA认证，则认证方必须为被认证方配置本地用户的用户名和密码，若采用远程AAA认证，则远程AAA服务器上需要配置被认证方的用户名和密码。不论是在本地还是AAA服务器上为被认证方配置的用户名和密码必须与被认证方上的配置相同。
若认证方配置了用户名，则在被认证方上为认证方配置的用户名必须与认证方上ppp chap user命令配置的用户名相同。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置本地认证对端的方式为MSCHAP或MSCHAPv2。
ppp authentication-mode { ms-chap | ms-chap-v2 } [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情况下，PPP协议不进行认证。
(4) 配置采用MSCHAP或MSCHAPv2认证时认证方的用户名。
ppp chap user username
(5) 配置本地AAA认证或者远程AAA认证。
具体配置请参见“安全配置指导”中的“AAA”。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置本地认证对端的方式为MSCHAP或MSCHAPv2。
ppp authentication-mode { ms-chap | ms-chap-v2 } [ [ call-in ] domain { isp-name | default enable isp-name } ]
缺省情况下，PPP协议不进行认证。
(4) 配置本地AAA认证或者远程AAA认证。
具体配置请参见“安全配置指导”中的“AAA”。
PPP协议使用轮询机制来确认链路状态是否正常。
当接口上封装的链路层协议为PPP时，链路层会周期性地向对端发送keepalive报文（可以通过timer-hold命令修改keepalive报文的发送周期）。如果接口在retry个（可以通过timer-hold retry命令修改该个数）keepalive周期内没有收到keepalive报文的应答，链路层会认为对端故障，上报链路层Down。
如果将keepalive报文的发送周期配置为0秒，则本端不主动发送keepalive报文；当本端收到对端主动发送过来的keepalive报文时，仍可以对该keepalive报文进行应答。
在速率非常低的链路上，keepalive周期和retry值不能配置过小。因为在低速链路上，大报文可能会需要很长的时间才能传送完毕，这样就会延迟keepalive报文的发送与接收。而接口如果在retry个keepalive周期内没有收到keepalive报文的应答，它就会认为链路发生故障。如果keepalive报文被延迟的时间超过接口的这个限制，链路就会被认为发生故障而被关闭。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置接口发送keepalive报文的周期。
timer-hold seconds
缺省情况下，接口发送keepalive报文的周期为10秒。
(4) 配置接口在多少个keepalive周期内未收到keepalive报文的应答就拆除链路。
timer-hold retry retry
缺省情况下，接口在5个keepalive周期内未收到keepalive报文的应答就拆除链路。
在PPP协商过程中，如果协商超时时间间隔内未收到对端的应答报文，则PPP将会重发前一次发送的报文。
在PPP链路两端设备对LCP协商报文的处理速度差异较大的情况下，为避免因一端无法及时处理对端发送的LCP协商报文而导致对端重传，可在对协商报文处理速度较快的设备上配置LCP协商的延迟时间。配置LCP协商的延迟时间后，当接口物理层UP时PPP将在延迟时间超时后才会主动进行LCP协商；如果在延迟时间内本端设备收到对端设备发送的LCP协商报文，则本端设备将不再等待延迟时间超时，而是直接进行LCP协商。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置协商超时时间间隔。
ppp timer negotiate seconds
缺省情况下，协商超时时间间隔为3秒。
(4) （可选）配置LCP协商的延迟时间。
ppp lcp delay milliseconds
缺省情况下，接口物理层UP后，PPP立即进行LCP协商。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 为接口配置IP地址可协商属性。
ip address ppp-negotiate
缺省情况下，接口未配置IP地址可协商属性。
多次执行本命令和ip address命令，最后一次执行的命令生效。关于ip address命令的详细介绍，请参见“三层技术-IP业务命令参考”中的“IP地址”。
目前Server端为Client端分配IP地址支持以下三种方式：
· 在接口下指定为Client端分配的IP地址。
· 从接口下指定的地址池（支持PPP地址池和DHCP地址池）中为Client端分配IP地址。
· 从ISP域下关联的地址池（支持PPP地址池和DHCP地址池）中为Client端分配IP地址。
不需要进行PPP认证的PPP用户可以使用在接口下指定为Client端分配的IP地址和从接口下指定的地址池中为Client端分配IP地址两种地址分配方式。同时配置这两种方式，最后一次的配置生效。
需要进行PPP认证的PPP用户可以使用全部的三种方式。同时配置多种方式时，以ISP域下关联的地址池优先，然后是接口下指定为Client端分配的IP地址或者地址池（接口下同时配置这两种方式时，最后一次的配置生效）。
如果用户配置了名称相同的PPP地址池和DHCP地址池，并采用该名称的地址池为对端分配IP地址，则系统只会使用PPP地址池来分配IP地址。
当通过PPP地址池给用户分配IP地址时，请确保PPP地址池中不包含该PPP地址池的网关地址。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置接口为Client端分配的IP地址。
remote address ip-address
缺省情况下，接口不为Client端分配IP地址。
(4) 配置Server端的IP地址。
ip address ip-address
缺省情况下，接口未配置IP地址。
(1) 进入系统视图。
system-view
(2) 配置PPP地址池。
ip pool pool-name start-ip-address [ end-ip-address ] [ group group-name ]
(3) （可选）配置PPP地址池的网关地址。
ip pool pool-name gateway ip-address [ vpn-instance vpn-instance-name ]
缺省情况下，未为PPP地址池配置网关地址。
(4) （可选）配置PPP地址池路由。
ppp ip-pool route ip-address { mask-length | mask } [ vpn-instance vpn-instance-name ]
缺省情况下，未配置PPP地址池路由。
需要保证配置的PPP地址池路由网段覆盖PPP地址池网段范围。
(5) 进入接口视图。
interface interface-type interface-number
(6) 使用PPP地址池为Client端分配IP地址。
remote address pool pool-name
缺省情况下，接口不为Client端分配IP地址。
(7) 配置Server端的IP地址。
ip address ip-address
缺省情况下，接口未配置IP地址。
(1) 进入系统视图。
system-view
(2) 配置DHCP功能。
¡ 如果Server端同时作为DHCP服务器，则在Server端上配置DHCP服务器、DHCP地址池相关内容。
¡ 如果Server端作为DHCP中继，则在Server端上配置DHCP中继相关内容（必须配置DHCP中继用户地址表项记录功能、DHCP中继地址池），并在远端DHCP服务器上配置DHCP地址池。
DHCP服务器和DHCP中继的具体配置介绍请参见“三层技术-IP业务配置指导”中的“DHCP服务器”和“DHCP中继”。
(3) 进入接口视图。
interface interface-type interface-number
(4) 使用DHCP地址池为Client端分配IP地址。
remote address pool pool-name
缺省情况下，接口不为Client端分配IP地址。
(5) （可选）配置PPP用户作为DHCP客户端时使用的DHCP客户端ID。
remote address dhcp client-identifier { callingnum | username }
缺省情况下，未配置PPP用户作为DHCP客户端时使用的DHCP客户端ID。
当使用PPP用户名作为DHCP客户端ID时，请确保各个上线用户分别使用不同的PPP用户名上线。
(6) 配置Server端的IP地址。
ip address ip-address
缺省情况下，接口未配置IP地址。
(1) 进入系统视图。
system-view
(2) 配置PPP地址池。
ip pool pool-name start-ip-address [ end-ip-address ] [ group group-name ]
缺省情况下，未配置PPP地址池。
(3) （可选）配置PPP地址池的网关地址。
ip pool pool-name gateway ip-address [ vpn-instance vpn-instance-name ]
缺省情况下，未为PPP地址池配置网关地址。
(4) （可选）配置PPP地址池路由。
ppp ip-pool route ip-address { mask-length | mask } [ vpn-instance vpn-instance-name ]
缺省情况下，未配置PPP地址池路由。
用户需要保证配置的PPP地址池路由网段覆盖PPP地址池网段范围。
(5) 进入ISP域视图。
domain isp-name
(6) 在ISP域下关联PPP地址池为Client端分配IP地址。
authorization-attribute ip-pool pool-name
缺省情况下，ISP域下未关联PPP地址池。
本命令的详细介绍请参见“安全命令参考”中的“AAA”。
(7) 退回系统视图。
quit
(8) 进入接口视图。
interface interface-type interface-number
(9) 配置Server端的IP地址。
ip address ip-address
缺省情况下，接口未配置IP地址。
(1) 进入系统视图。
system-view
(2) 配置DHCP功能。
¡ 如果Server端同时作为DHCP服务器，则在Server端上配置DHCP服务器、DHCP地址池相关内容。
¡ 如果Server端作为DHCP中继，则在Server端上配置DHCP中继相关内容（必须配置DHCP中继用户地址表项记录功能、DHCP中继地址池），并在远端DHCP服务器上配置DHCP地址池。
DHCP服务器和DHCP中继的具体配置介绍请参见“三层技术-IP业务配置指导”中的“DHCP服务器”和“DHCP中继”。
(3) 进入ISP域视图。
domain isp-name
(4) 在ISP域下关联DHCP地址池或DHCP中继地址池为Client端分配IP地址。
authorization-attribute ip-pool pool-name
缺省情况下，ISP域下未关联DHCP地址池或DHCP中继地址池。
本命令的详细介绍请参见“安全命令参考”中的“AAA”。
(5) 退回系统视图。
quit
(6) 进入接口视图。
interface interface-type interface-number
(7) （可选）配置PPP用户作为DHCP客户端时使用的DHCP客户端ID。
remote address dhcp client-identifier { callingnum | username }
缺省情况下，未配置PPP用户作为DHCP客户端时使用的DHCP客户端ID。
当使用PPP用户名作为DHCP客户端ID时，请确保各个上线用户分别使用不同的PPP用户名上线。
(8) 配置Server端的IP地址。
ip address ip-address
缺省情况下，接口未配置IP地址。
开启接口的IP网段检查功能后，当IPCP协商时，本地会检查对端的IP地址与本端接口的IP地址是否在同一网段，如果不在同一网段，则IPCP协商失败。
如果接口的IP网段检查功能处于关闭状态，则在IPCP协商阶段不进行接口IP网段检查。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 开启接口的IP网段检查功能。
ppp ipcp remote-address match
缺省情况下，接口的IP网段检查功能处于关闭状态。
一般情况下，Client端配置了ppp ipcp dns request命令后，Server端才会为本端指定DNS服务器地址。有一些特殊的设备，Client端并未请求，Server端却要强制为Client端指定DNS服务器地址，从而导致协商不通过，为了适应这种情况，Client端可以配置ppp ipcp dns admit-any命令以便可以被动地接收对端指定的DNS服务器地址。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置设备主动请求对端指定DNS服务器地址。
ppp ipcp dns request
缺省情况下，禁止设备主动向对端请求DNS服务器地址。
(4) 配置设备可以被动地接收对端指定的DNS服务器地址，即设备不发送DNS请求，也能接收对端设备分配的DNS服务器地址。
ppp ipcp dns admit-any
缺省情况下，设备不会被动地接收对端设备指定的DNS服务器的IP地址。
在配置了ppp ipcp dns request命令的情况下，可以不配置本命令。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置设备为对端设备指定DNS服务器地址。
ppp ipcp dns primary-dns-address [ secondary-dns-address ]
缺省情况下，设备不为对端设备指定DNS服务器的IP地址。
配置本命令后，Server端不会主动给Client端指定DNS的地址，只有收到Client端的请求后，Server端才会为对端指定DNS服务器地址。
缺省情况下，PPP报文中的地址字段的值固定为0xFF，控制字段的值固定为0x03，既然这两个字段的值是固定的，就可以对这两个字段进行压缩。
ACFC协商选项字段用来通知对端，本端可以接收地址和控制字段被压缩的报文。
ACFC协商在LCP协商阶段进行，对于LCP报文不进行地址字段和控制字段压缩，以确保LCP协商过程顺利进行。当LCP协商通过后，对于发送的非LCP报文将进行地址字段和控制字段压缩，以增加链路的有效载荷。
建议在低速链路上配置本功能。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置本地发送ACFC协商请求，即LCP协商时本地发送的协商请求携带ACFC协商选项。
ppp acfc local-request
缺省情况下，LCP协商时本地发送的协商请求不携带ACFC协商选项。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置拒绝对端的ACFC协商请求，即LCP协商时拒绝对端携带的ACFC协商选项。
ppp acfc remote-reject
缺省情况下，接受对端的ACFC协商请求，即LCP协商时接受对端携带的ACFC协商选项，并且发送的报文进行地址控制字段压缩。
缺省情况下，PPP报文中的协议字段长度为2字节，然而，目前典型的协议字段取值都小于256，所以可以压缩成一个字节来区分协议类型。
PFC协商选项字段用来通知对端，本端可以接收协议字段被压缩成一个字节的报文。
PFC协商在LCP协商阶段进行，对于LCP报文不进行协议字段压缩，以确保LCP协商过程顺利进行。当LCP协商通过后，对于发送的非LCP报文将进行协议字段压缩，如果协议字段的头8比特为全零，则不添加此8比特，以增加链路的有效载荷。
建议在低速链路上配置本功能。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置本地发送PFC协商请求，即LCP协商时本地发送的协商请求携带PFC协商选项。
ppp pfc local-request
缺省情况下，LCP协商时本地发送的协商请求不携带PFC协商选项。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 配置拒绝对端的PFC协商请求，即LCP协商时拒绝对端携带的PFC协商选项。
ppp pfc remote-reject
缺省情况下，接受对端的PFC协商请求，即LCP协商时接受对端携带的PFC协商选项，并且发送的报文进行协议字段压缩。
IPHC（IP Header Compression，IP报文头压缩）协议主要应用于低速链路上的语音通信。
在低速链路上，每个语音报文中报文头消耗大部分的带宽。为了减少报文头对带宽的消耗，可以在PPP链路上使用IPHC压缩功能，对报文头进行压缩。
IPHC压缩分为如下两种：
· RTP头压缩：对报文中的RTP/UDP/IP头（长度共40字节）进行压缩。
· TCP头压缩：对报文中的TCP/IP头（长度共40字节）进行压缩。
用户必须在链路的两端同时开启IPHC压缩功能，该功能才生效。
在虚拟模板接口、Dialer接口上开启/关闭IPHC压缩功能时，配置不会立即生效，只有对此接口或者其绑定的物理接口依次进行shutdown和undo shutdown操作后，配置才能生效。
只有在开启IPHC压缩功能后，才能配置接口上允许进行RTP头/TCP头压缩的最大连接数，并且需要对接口依次进行shutdown和undo shutdown操作后，配置才能生效。在关闭IPHC压缩功能后，配置将被清除。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 开启PPP IPHC压缩功能。
ppp compression iphc enable [ nonstandard ]
缺省情况下，IPHC压缩功能处于关闭状态。
与非H3C设备互通时需要配置nonstandard参数。
配置nonstandard参数后，仅支持RTP头压缩，不支持TCP头压缩。
(4) 配置接口上允许进行RTP头压缩的最大连接数。
ppp compression iphc rtp-connections number
缺省情况下，接口上允许进行RTP头压缩的最大连接数为16。
(5) 配置接口上允许进行TCP头压缩的最大连接数。
ppp compression iphc tcp-connections number
缺省情况下，接口上允许进行TCP头压缩的最大连接数为16。
本特性用来配置RADIUS认证计费时所携带的nas-port-type属性。关于nas-port-type属性的详细介绍请参见RFC 2865。
本特性配置后仅对新接入的用户生效，对当前已经存在用户无影响。
(1) 进入系统视图。
system-view
(2) 进入虚拟模板接口视图。
interface virtual-template number
(3) 配置接口的nas-port-type属性。
nas-port-type { ethernet | virtual }
缺省情况下，nas-port-type属性由PPP用户的业务类型和承载链路类型决定：
¡ 如果是PPPoE业务，nas-port-type属性为ethernet。
¡ 如果是L2TP业务，nas-port-type属性为virtual。
PPP协议可以为每条PPP链路提供基于流量的计费统计功能，具体统计内容包括出入两个方向上流经本链路的报文数和字节数。AAA可以获取这些流量统计信息用于计费控制。关于AAA计费的详细介绍请参见“安全配置指导”中的“AAA”。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 开启PPP计费统计功能。
ppp account-statistics enable [ acl { acl-number | name acl-name } ]
缺省情况下，PPP计费统计功能处于关闭状态。
PPP接入用户日志是为了满足网络管理员维护的需要，对用户的上线、下线、上线失败的信息进行记录，包括用户名、IP地址、接口名称、两层VLAN、MAC地址、上线失败原因、下线原因等。设备生成的PPP日志信息会交给信息中心模块处理，信息中心模块的配置将决定日志信息的发送规则和发送方向。关于信息中心的详细描述请参见“网络管理和监控配置指导”中的“信息中心”。
为了防止设备输出过多的PPP日志信息，一般情况下建议不要开启此功能。
(1) 进入系统视图。
system-view
(2) 开启PPP接入用户日志信息功能。
ppp access-user log enable [ abnormal-logout | failed-login | normal-logout | successful-login ] *
缺省情况下，PPP接入用户日志信息功能处于关闭状态。
在完成上述配置后，在任意视图下执行display命令可以显示PPP配置后的运行情况，通过查看显示信息验证配置的效果。
在用户视图下执行reset命令可以清除相应接口的统计信息。
表1-6 PPP显示和维护
|
操作 |
命令 |
|
显示PPP接入用户的信息 |
display ppp access-user { domain domain-name | interface interface-type interface-number [ count ] | ip-address ipv4-address | ipv6-address ipv6-address | username user-name | user-type { lac | lns | pppoe } [ count ] } |
|
显示PPP的协商报文统计信息 |
display ppp packet statistics [ slot slot-number ] |
|
显示PPP地址池的信息 |
display ip pool [ pool-name | group group-name ] |
|
显示虚拟模板接口的相关信息 |
display interface [ virtual-template [ interface-number ] ] [ brief [ description | down ] ] |
|
显示IPHC压缩的统计信息 |
display ppp compression iphc { rtp | tcp } [ interface interface-type interface-number ] |
|
清除IPHC压缩的统计信息 |
reset ppp compression iphc [ rtp | tcp ] [ interface interface-type interface-number ] |
|
强制PPP用户下线 |
reset ppp access-user { ip-address ipv4-address [ vpn-instance ipv4-vpn-instance-name ] | ipv6-address ipv6-address [ vpn-instance ipv6-vpn-instance-name ] | username user-name } |
|
清除PPP的协商报文统计信息 |
reset ppp packet statistics [ slot slot-number ] |
PPPoE（Point-to-Point Protocol over Ethernet，在以太网上承载PPP协议）是对PPP协议的扩展，它在以太网上建立PPPoE会话，将PPP报文封装在以太网帧之内，在以太网上提供点对点的连接，解决了PPP无法应用于以太网的问题。PPPoE还可以通过远端接入设备对接入的每台主机实现控制、认证、计费功能。由于很好地结合了以太网的经济性及PPP良好的可扩展性与管理控制功能，PPPoE被广泛应用于小区接入组网等环境中。
PPPoE使用Client/Server模型。PPPoE Client向PPPoE Server发起连接请求，两者之间会话协商通过后，就建立PPPoE会话，此后PPPoE Server向PPPoE Client提供接入控制、认证、计费等功能。
根据PPPoE会话的起点所在位置的不同，PPPoE分为Router-Initiated和Host-Initiated两种组网结构。
如图2-1所示，在Router-Initiated组网结构中，PPPoE会话是在两台设备之间建立的，所有用户终端设备均通过该PPPoE会话进行数据传输。在这种组网结构中，PPPoE Client位于企业内部网络，PPPoE server则由运营商提供。用户终端设备无需安装PPPoE客户端拨号软件，通常一个企业使用一个共享账号接入网络。
如图2-2所示，在Host-Initiated组网结构中，每台用户终端设备都需要安装PPPoE客户端拨号软件。这些设备作为PPPoE client，与运营商的PPPoE server单独建立PPPoE会话。这样做的好处在于能够方便运营商对用户进行有效的计费和管理控制。
图2-2 Host-Initiated组网结构图
PPPoE报文的格式就是在以太网帧中携带PPP报文。其报文封装结构如图2-3所示。
表2-1 PPPoE报文字段信息描述表
|
字段 |
含义 |
|
Destination_address |
一个以太网单播目的地址或者以太网广播地址（0xffffffffffff）： · 对于Discovery阶段来，该字段的值是单播或者广播地址，PPPoEClient寻找PPPoEServer的过程使用广播地址，确认PPPoEServer后使用单播地址 · 对于Session阶段，该字段必须是Discovery阶段已确定的通信对方的单播地址 |
|
Source_address |
源设备的以太网MAC地址 |
|
Ether_type |
设置为0x8863（Discovery阶段）或者0x8864（Session阶段） |
|
Ver |
4bits，PPPoE版本号，值为0x1 |
|
Type |
4bits，PPPoE类型，值为0x1 |
|
Code |
8bits，PPPoE报文类型： · Code取值为0x00，表示会话数据 · Code取值为0x09，表示PADI报文 · Code取值为0x07，表示PADO或PADT报文 · Code取值为0x19，表示PADR报文 · Code取值为0x65，表示PADS报文 |
|
Session_ID |
16bits，对于一个给定的PPP会话，该值是一个固定值，并且与以太网Source_address和Destination_address一起实际地定义了一个PPP会话。值0xffff为将来的使用保留，不允许使用 |
|
Length |
16bits，定义PPPoE的Payload长度。不包括以太网头部和PPPoE头部的长度 |
|
PPP Packet |
PPP报文结构请参见PPP的基本概念 PPP报文封装的帧格式 |
PPPoE用户上线过程要经过PPPoE协商和PPP协商两个阶段，其中PPP协商包括LCP协商、PAP/CHAP认证、NCP协商等阶段。
PPPoE协商是Device为用户分配PPPoE接入用的Session ID，用来唯一标识一条用户与Device之间的PPPoE虚拟链路。PPPoE的协商过程如图2-4所示。
(1) 用户广播一个PADI（PPPoE Active Discovery Initiation，PPPoE激活发现起始）报文，在此报文中包含用户想要得到的服务类型信息。
(2) 以太网内的所有接入集中器（如图中的Device）在收到这个初始化报文后，将其中请求的服务与自己能提供的服务进行比较，其中可以为此用户提供此服务的Device回应PADO（PPPoE Active Discovery Offer，PPPoE激活发现服务）报文。
(3) 用户可能会收到多个Device回应的PADO报文。用户根据一定的条件从返回PADO报文的Device中选定符合条件的Device，并向它返回一个会话请求报文PADR（非广播）（PPPoE Active Discovery Request，PPPoE激活发现请求），在PADR报文中封装所需的服务信息。
(4) 被选定的Device在收到PADR报文后开始进入PPP会话阶段。它会产生一个会话标识以唯一的标识它和主机的这段PPPoE会话。并把这个特定的会话标识包含在会话确认报文PADS（PPPoE Active Discovery Session-confirmation，PPPoE激活发现会话确认）中回应给用户，如果没有错误发生就进入到PPP会话阶段，而用户在收到会话确认报文后如果没有错误发生也进入到PPP会话阶段。
图2-4 PPPoE协商过程
PPP协商包括LCP协商、PAP/CHAP认证、NCP协商等阶段。
进入PPP协商阶段后，首先开始LCP协商，LCP协商过程如图2-5所示：
(1) 用户与Device互相发送LCP Configure-Request报文。
(2) 双方收到Configure-Request报文后，根据报文中协商选项支持情况做出适当的回应（请参见表2-2）。若两端都回应了Configure-ACK，则标志LCP链路建立成功，否则会继续发送Request报文：
¡ 如果在设定的LCP协商间隔与协商次数内，对端回应了Configure-ACK，则LCP链路建立成功。
¡ 如果在超过了设定的LCP协商次数后，对端尚未回应Configure-ACK，则终止LCP协商。
(3) LCP链路建立成功后，Device会周期性的向用户发送LCP Echo-Request报文，然后接收对端回应的Echo-Reply报文，来探测LCP链路是否正常，以维持LCP连接。
图2-5 LCP协商的基本过程
|
回应报文类型 |
含义 |
|
Configure-ACK |
若完全支持对端的LCP选项，则回应Configure-ACK报文，报文中必须完全协带对端Request报文中的选项 |
|
Configure-NAK |
若支持对端的协商选项，但不认可该项协商的内容，则回应Configure-NAK报文，在Configure-NAK的选项中填上本端期望的内容，如：对端MRU值为1500，而本端期望MRU值为1492，则在Configure-NAK报文中埴上1492 |
|
Configure-Reject |
若不能支持对端的协商选项，则回应Configure-Reject报文，报文中带上不能支持的选项 |
LCP协商完成后，进入认证阶段，分为PAP认证和CHAP认证两种认证方式。
· PAP认证
PAP为两次握手协议，它通过用户名及密码来对用户进行认证，且以明文的方式传递用户名及密码，因此，适用于对网络安全要求相对较低的环境。PAP认证过程如图2-6所示：
a. 被认证方发送本端的用户名及密码到认证方。
b. 认证方根据本端的用户表查看是否存在此用户。
¡ 若存在，则认证密码是否正确。
- 若密码正确，则发送Authenticate-ACK报文到对端，通告对端已被允许进入下一阶段协商。
- 若密码不正确，则发送Authenticate-NAK报文到对端，通告对端认证失败。
¡ 若不存在，则认证失败。
认证失败后，不会直接将链路关闭。只有当认证不过次数达到一定值时，才会关闭链路。
图2-6 PAP认证流程
· CHAP认证
CHAP为三次握手协议。只在网络上传输用户名，并不传输用户密码，因此它的安全性要比PAP高。CHAP的认证如图2-7所示。
c. 认证方主动发起认证请求，认证方向被认证方发送一些包含随机数的报文（Challenge），并同时将本端的用户名附带上一起发送给被认证方。
d. 被认证方接到认证方的认证请求后，先检查本端接口上是否配置了CHAP密码。
- 若已配置CHAP密码，则被认证方通过哈希算法对报文ID、配置的密码和报文中的随机数计算哈希值，将该哈希值和自己的用户名发回认证方（Response）。
- 若未配置CHAP密码，则根据此报文中认证方的用户名在本端的用户表查找该用户对应的密码，通过哈希算法对报文ID、此用户的密码和报文中的随机数计算哈希值，将生成的哈希值和被认证方自己的用户名发回认证方（Response）。
e. 认证方通过哈希算法对报文ID、自己保存的被认证方密码和Challenge报文中的随机数计算哈希值，并与Response报文中的哈希值进行比较，若比较结果一致，认证通过，若比较结果不一致，认证失败。
图2-7 CHAP认证流程
NCP协商主要功能是协商PPP报文的网络层参数，如IPCP、IPv6CP等，其中最为常见的是IPCP协议。PPPoE用户主要通过IPCP协议来获取访问网络的IP地址或IP地址段。
如图2-8所示，NCP流程与LCP流程类似，用户与Device之间互相发送Configure-Request报文并且互相回应Configure-ACK报文后，标志NCP协商成功，可以正常访问网络。
图2-8 NCP的基本协商流程
下面将介绍NCP协商中常见的IPCP协议及IPv6CP协议。
· IPCP
IPCP协商过程是基于PPP状态机进行协商的。经过双方协商，通过配置请求、配置确认、配置否认等报文交换配置信息，最终IPCP状态由initial（或closed）状态变为Opened状态。IPCP状态变为Opened的条件必须是发送方和接收方都发送和接收过确认报文。
IPCP协商过程中，协商报文可包含多个选项，即参数，如IP Address、网关、掩码等。各个选项的拒绝或否认都不影响IPCP的协商成功，此外，IPCP还支持无选项协商。
· IPv6CP
IPv6控制协议（IPv6CP）是一种网络控制协议。IPv6CP主要负责在点对点链路终端双方上配置，可用及停用IPv6协议模块，可协商的参数包括接口ID和IPv6压缩协议。IPv6CP使用与链路控制协议（LCP）相同的包交换机制。但只有在PPP达到网络层协议阶段时，IPv6CP包才可以被交换。在达到这种阶段前接收的IPv6CP包需要被丢弃。
目前，IPv6CP协商的选项只支持接口ID的协商，不支持IPv6压缩协议的协商。
IPv6网络中，PPP用户与IPoE用户都需要使用ND协议或DHCPv6协议完成全球单播地址和配置信息的分配，使用DHCPv6协议的IA_PD选项完成CPE路由模式下LAN口IPv6前缀的分配。
在PPPoE用户上线交互过程中，会对接口MTU及MRU的值进行协商，然后进行双方报文的发送及接收。其协商方式主要分为如下两种。
PPPoE发现阶段：
· 如果用户报文中携带PPP-Max-Payload字段且该值大于1492，该值将和BAS接口下的MTU值减8进行比较，取较小值作为协商值，并命名为PPP_MRU_Max，该协商值不是最终MTU协商结果，是作为参考值之一。
· 如果用户报文中携带的PPP-Max-Payload字段小于等于1492。则PPP_MRU_Max取缺省值1492，作为参考值之一。
· 如果用户报文没有携带PPP-Max-Payload字段，则取PPP_MRU_Max为0，不作为参考值之一。
LCP协商阶段：
· 用户如果在LCP阶段的Config-Request报文中携带有MRU字段：
¡ 如果用户报文中携带的MRU与PPPoE发现阶段协商出的PPP_MRU_Max相等，将取用户携带的MRU作为用户的最终MTU。
¡ 如果用户报文中携带的MRU与PPPoE发现阶段协商出的PPP_MRU_Max不相等或者PPP_MRU_Max为0，用户携带的MRU将会和VT下的MTU值减8进行比较，取最小值作为用户的最终MTU。
· 用户如果在LCP阶段的Config-Request报文没有携带MRU字段，则取1492和VT下的MTU值减8进行比较，取最小的值作为用户最终的MTU。
PPPoE发现阶段：
· 用户报文中如果携带PPP-Max-Payload字段，该值与BAS口下的MTU的较小值作为协商值，命名为PPP_MRU_Max，该值不是最终MTU协商结果，是作为参考值之一。
· 用户报文中如果没有携带PPP-Max-Payload字段，则取PPP_MRU_Max为缺省值0，不作为参考值。
LCP协商阶段：
· 用户如果在LCP阶段的Config-Request报文携带有MRU字段，该值将会和VT下的MTU比较，取最小值作为用户的最终MTU。
· 用户如果在LCP阶段的Config-Request报文没有携带MRU字段：
¡ 如果用户在PPPoE发现阶段没有协商PPP_MRU_Max，则取VT下的MTU作为用户最终的MTU。
¡ 如果在PPPoE发现阶段协商了PPP_MRU_Max，则取VT下的MTU和PPP-Max-Payload的最小值作为用户最终的MTU。
PPPoE Server目前支持以下接口类型：
· 三层以太网接口/三层以太网子接口
· 三层聚合接口/三层聚合子接口
· VLAN接口
PPPoE会话有三种工作模式：永久在线模式、按需拨号模式、诊断模式。
· 永久在线模式：当物理线路up后，设备会立即发起PPPoE呼叫，建立PPPoE会话。除非用户删除PPPoE会话，否则此PPPoE会话将一直存在。
· 按需拨号模式：当物理线路up后，设备不会立即发起PPPoE呼叫，只有当有数据需要传送时，设备才会发起PPPoE呼叫，建立PPPoE会话。如果PPPoE链路的空闲时间超过用户配置的值，设备会自动中止PPPoE会话。
· 诊断模式：设备在配置完成后立即发起PPPoE呼叫，建立PPPoE会话。每隔用户配置的重建时间间隔，设备会自动断开该会话、并重新发起呼叫建立会话。通过定期建立、删除PPPoE会话，可以监控PPPoE链路是否处于正常工作状态。
PPPoE会话的工作模式由对应的拨号接口的配置决定：
· 当Dialer接口的链路空闲时间（通过dialer timer idle命令配置）配置为0，且Dialer接口上未配置dialer diagnose命令时，PPPoE会话将工作在永久在线模式。
· 当Dialer接口的链路空闲时间（通过dialer timer idle命令配置）配置不为0，且Dialer接口上未配置dialer diagnose命令时，PPPoE会话将工作在按需拨号模式。
· 当Dialer接口上配置了dialer diagnose命令时，PPPoE会话将工作在诊断模式。
PPPoE Client配置任务如下：
(1) 配置拨号接口
(2) 配置PPPoE会话
(3) （可选）复位PPPoE会话
在配置PPPoE会话之前，需要先配置一个Dialer接口，并在接口上开启共享DDR。每个PPPoE会话唯一对应一个Dialer bundle，而每个Dialer bundle又唯一对应一个Dialer接口。这样就相当于通过一个Dialer接口可以创建一个PPPoE会话。
(1) 进入系统视图。
system-view
(2) 创建拨号访问组，并配置拨号控制规则。
dialer-group group-number rule { ip | ipv6 } { deny | permit | acl { acl-number | name acl-name } }
仅工作在按需拨号模式下需要配置本命令。
(3) 创建Dialer接口，并进入该Dialer接口视图。
interface dialer number
(4) 配置接口IP地址。
ip address { address mask | ppp-negotiate }
缺省情况下，接口未配置IP地址。
(5) 开启共享DDR。
dialer bundle enable
缺省情况下，接口上未开启共享DDR。
(6) 配置该拨号接口关联的拨号访问组，将该接口与拨号控制规则关联起来。
dialer-group group-number
缺省情况下，接口不与任何拨号访问组相关联。
仅工作在按需拨号模式下需要配置本命令。
(7) 配置链路空闲时间。
dialer timer idle idle [ in | in-out ]
缺省情况下，链路空闲时间为120秒。
未配置dialer diagnose时，当idle配置为0时，PPPoE会话工作在永久在线模式下，不为0时工作在按需拨号模式下。
(8) 配置DDR应用工作在诊断模式。
dialer diagnose [ interval interval ]
缺省情况下，工作在非诊断模式。
仅工作在诊断模式下需要配置本命令。
(9) （可选）配置DDR自动拨号的间隔时间。
dialer timer autodial autodial-interval
缺省情况下，DDR自动拨号的间隔时间为300秒。
当链路断开后将启动自动拨号定时器，等待自动拨号定时器超时后再重新发起呼叫。
为了在链路断开时可以尽快自动重新拨号，建议将自动拨号的时间间隔配置的小一些。
(10) （可选）配置Dialer接口的MTU值。
mtu size
缺省情况下，Dialer接口的MTU值为1500字节。
对于PPPoE Client应用的Dialer接口，应修改其MTU值，保证分片后的报文加上2个字节的PPP头和6个字节的PPPoE头之后的总长度不超过对应PPPoE会话所在接口的MTU值。
(11) （可选）配置Dialer接口的TCP最大报文段长度。
tcp mss value
缺省情况下，未配置接口的TCP最大报文段长度。
一般情况下，TCP最大报文段长度等于出接口的IP MTU减40，对于PPPoE Client应用的Dialer接口，应修改其TCP MSS值为1452，保证分片后的报文加上2个字节的PPP头和6个字节的PPPoE头，再加上40个字节的IP头之后的总长度不超过对应PPPoE会话所在接口的MTU值。
有关该命令的详细介绍，请参见“三层技术-IP业务命令参考”中的“IP性能优化”。
当成功建立PPPoE会话后，系统将自动创建一个VA接口，用于和对端进行报文交互。VA接口支持通过display interface virtual-access命令查看接口相关信息，但不支持对该接口进行配置。
VA接口随着PPPoE会话的建立，由系统自动创建，PPPoE会话拆除后，系统自动删除。
(1) 进入系统视图。
system-view
(2) 进入接口视图。
interface interface-type interface-number
(3) 建立一个PPPoE会话，并且指定该会话所对应的Dialer bundle。
pppoe-client dial-bundle-number number [ no-hostuniq ]
该Dialer bundle的序号number需要与Dialer接口的编号相同。
当PPPoE会话工作在永久在线模式或诊断模式时，如果使用reset pppoe-client命令复位PPPoE会话，设备会在自动拨号定时器超时后自动重新建立PPPoE会话。
当PPPoE会话工作在按需拨号模式时，如果使用reset pppoe-client命令复位PPPoE会话，设备会在有数据需要传送时，才重新建立PPPoE会话。
请在用户视图下执行本命令，复位PPPoE会话。
reset pppoe-client { all | dial-bundle-number number }
在完成上述配置后，在任意视图下执行display命令可以显示PPPoE Client配置后的运行情况，通过查看显示信息验证配置的效果。
在用户视图下执行reset命令可以清除PPPoE会话的协议报文统计信息。
表2-3 PPPoE Client显示和维护
|
操作 |
命令 |
|
显示PPPoE会话的概要信息 |
display pppoe-client session summary [ dial-bundle-number number ] |
|
显示PPPoE会话的协议报文统计信息 |
display pppoe-client session packet [ dial-bundle-number number ] |
|
清除PPPoE会话的协议报文统计信息 |
reset pppoe-client session packet [ dial-bundle-number number ] |
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
