PPPoE调试信息说明

1、2022-3-6PPPoE 的英文是Point-to-Point Protocol over Ethernet，中文意思是以太网上的PPP。PPPoE协议提供了在广播式的网络（如以太网）中多台主机连接到远端的访问集中器（访问集中器也称为宽带接入服务器）上的一种标准。Page 3PPPoE服务器设备提供了PPPoE服务器的功能，支持动态分配IP地址，提供多种认证方式，和防火墙配合，可以对内部网络提供安全保障，适用于校园、智能小区等通过以太网接入Internet的组网应用。 。PPPoE客户端局域网内所有主机通过同一个PPPoE会话传送数据，主机上不用安装PPPoE客户端拨号软件，而且同一个局域网

2、中的所有主机可以共享一个帐号。Page 4以太网的帧格式Page 5Destination_address域以太网单播目的地址或者以太网广播地址（0 xFFFFFFFF）。在Discovery数据包中，该域的值是以太网广播地址。在PPPoE会话流量中，该域必须是Discovery阶段已经确定的通信对方的单播地址。Source_address域源设备的以太网MAC地址。Ethernet_Type域当值为0 x8863时表示Discovery阶段当值为0 x8864时表示PPPoE会话阶段Page 6Payload域VER：长度是4比特。PPPoE规范的本版本必须设置为0 x01。Type：长度是

3、4比特。PPPoE规范的本版本必须设置为0 x01。Code：长度是8比特。其定义在后面的Discovery和PPPoE会话中分别指定。Session_ID：长度是16比特。是一个网络字节序的无符号值。其值在后面Discovery数据包中定义。Length：长度是16比特。该值是PPPoE的Payload长度。它不包括以太网头部和PPPoE头部的长度。Payload：PPPoE的Payload，包含0个或多个Tag。Page 7PPPoE会话建立过程分为以下两个阶段：Discovery阶段：地址发现阶段PPPoE Session阶段：PPPoE会话阶段为了在以太网上建立点到点连接，每一个PPP

4、oE会话必须知道通信对方的以太网地址，并建立一个唯一的会话标识符。PPPoE通过地址发现协议查找对方的以太网地址。Page 8PPP链路的建立是通过一系列的协商完成的：LCP除了用于建立、拆除和监控PPP数据链路，还主要进行链路层参数的协商，如MRU、验证方式NCP主要用于协商在该数据链路上所传输的数据包的格式与类型，如IP地址lPPPPPP链路建立过程：链路建立过程：Page 9PPP链路建立过程的简单描述如下：1、PPP协议运行总是以Dead阶段开始和结束。通常处在这个状态的时间很短，仅仅是检测到硬件设备后（即硬件连接状态为Up）就进入Establish阶段。 2、在Establish阶段

5、，PPP链路进行LCP协商。协商内容包括工作方式是SP（Single-link PPP）还是MP（Multilink PPP）、最大接收单元MRU、验证方式、魔术字（magic number）和异步字符映射等选项。LCP协商成功后进入Opened状态，表示底层链路已经建立。3、如果配置了验证，将进入Authenticate阶段，开始CHAP或PAP验证。如果没有配置验证，则直接进入Network阶段。Page 10PPP链路建立过程的简单描述如下： 4、对于Authenticate阶段，如果验证失败，进入Terminate阶段，拆 除链路，LCP状态转为Closed。如果验证成功，进入Netw

6、ork阶段，此时LCP状态仍为Opened，而NCP状态从Initial转到Starting。 5 5、在Network阶段，PPP链路进行NCP协商，NCP协商包括IPCP（IP Control Protocol）、MPLSCP（MPLS Control Protocol）等协商。IPCP协商主要包括双方的IP地址。通过NCP协商来选择和配置一个网络层协议。只有相应的网络层协议协商成功后（相应协议的NCP协商状态为Opened），该网络层协议才可以通过这条PPP链路发送报文。例如：IPCP协商通过后，这条PPP链路才可以承载IP报文。Page 11PPP链路建立过程的简单描述如下： 6、 N

7、CP协商成功后，PPP链路将一直保持通信。PPP运行过程中，可以随时中断连接，物理链路断开、认证失败、超时定时器时间到、管理员通过配置关闭连接等动作都可能导致进入链路进入Terminate阶段 7 7、进入Terminate阶段后且资源释放完，即进入Dead阶段。Page 12Discovery阶段基本原理当主机开始通过PPPoE接入服务器时，它必须先识别接入端的以太网MAC地址，建立PPPoE的Session_ID。这就是Discovery阶段的目的。Discovery阶段由四个过程组成。完成之后通信双方都会知道PPPoE的Session_ID以及对方以太网地址，它们共同确定了唯一的PPPo

8、E会话共分为四个阶段Page 131.主机在本以太网内广播一个PADI（PPPoE Active Discovery Initial）报文，在此报文中包含主机想要得到的服务类型信息。Page 142.以太网内的所有服务器收到这个PADI报文后，将其中请求的服务与自己能提供的服务进行比较，可以提供此服务的服务器发回PADO（PPPoE Active Discovery Offer）报文。Page 153.主机可能收到多个服务器的PADO报文，主机将依据PADO的内容，从多个服务器中选择一个，并向它发回一个会话请求报文PADR（PPPoE Active Discovery Request)。Pag

9、e 164.服务器产生一个唯一的会话标识，标识和主机的这段PPPoE会话。并把此会话标识通过会话确认报文PADS（PPPoE Active Discovery Session-confirmation）发回给主机，如果没有错误，双方进入PPPoE Session阶段Page 17PPPoE会话（PPPoE Session）开始后，PPP报文作为PPPoE帧的净荷，封装在以太网帧发送到对端。这时所有的以太网数据包都是单播的。Ethernet_Type域设置为0 x8864。PPPoE的Code必须设置为0 x00。PPPoE会话的Session_ID不允许发生改变，必须是Discovery阶段所

10、指定的值。PPPoE的Payload包含一个PPP帧。PPP帧的开始字段是PPP Protocol-ID。Page 18从主机发送到接入服务器的PPP LCP数据包示例图进入PPPoE Session阶段后，主机或服务器任何一方都可发PADT报文通知对方结束PPPoE会话。 Page 19PPPoE Client当AR设备将PPPoE作为一种WAN（Wide Area Network）接入方式时，AR充当PPPoE Client的角色，BRAS（Broadband Remote Access Server）作为PPPoE Server。Page 20PPPoE Server AR1200设备提

11、供了PPPoE Server的功能，支持动态分配IP地址，提供本地认证、RADIUS/HWTACACS等多种认证方式，适用于校园、智能小区等通过以太网接入Internet的组网应用。Page 21PPPoE Client 与PPPoE Server互通简单场景。Page 23RouterAGE0/0/0RouterBGE0/0/1PPPoE ClientPPPoE Server测试过程中很重要的一部分是配置DCC，然后绑定物理接口。Page 24# # dialer-rule dialer-rule dialer-rule 1 ip permit dialer-rule 1 ip permit

12、 # #interface Dialer1interface Dialer1 link-protocol ppp link-protocol ppp ip address ppp-negotiate ip address ppp-negotiate dialer user user2 dialer user user2 dialer-group 1 dialer-group 1 dialer bundle 1 dialer bundle 1 # #interface GigabitEthernet0/0/0/interface GigabitEthernet0/0/0/ pppoe-clien

13、t dial-bundle-number 1 pppoe-client dial-bundle-number 1# #通过虚拟接口模板与物理接口绑定完成Server配置。Page 25# # ip pool pool1 ip pool pool1# #ip pool pool1ip pool pool1 network 192.168.10.10 mask 255.255.255.0 network 192.168.10.10 mask 255.255.255.0 gateway-list 192.168.10.1 gateway-list 192.168.10.1# #interface V

14、irtual-Template1interface Virtual-Template1 remote address pool pool1 remote address pool pool1 ip address 192.168.10.10 255.255.255.0 ip address 192.168.10.10 255.255.255.0# #interface GigabitEthernet0/0/1interface GigabitEthernet0/0/1 pppoe-server bind Virtual-Template 1 pppoe-server bind Virtual-

15、Template 1# #PPPoE Client该用例测试设备PPPoE Client功能测试方法设备上配置PPPoE Client功能，通过创建Dialer口与物理接口进行绑定。然后配置PPPoE Server端，检查拨号状态是否成功。Page 27PPPoE Server该用例测试设备PPPoE Server功能测试方法设备上配置PPPoE Server功能，通过创建虚拟接口模板与物理接口进行绑定。然后配置PPPoE Client端，检查拨号状态是否成功。Page 28在配置各设备后发现PPPoE 用户无法拨入，请使用下面的故障诊断流程，如图所示。Page 30Page 31主要检查思路

16、：检查虚拟接口模板是否配置正确。 检查是否分配到IP 地址。 l其他检查思路：其他检查思路：检查链路是否建立成功 检查网络侧是否有回应报文检查路由器是否拒绝呼叫 检查数据通道协议是否UpPage 32实际组网lPPPoE Client PPPoE Client 与与PPPoE ServerPPPoE Server互通简单场景。互通简单场景。Page 33RouterAGE0/0/0RouterBGE0/0/1PPPoE ClientPPPoE ServerPage 34PPPPPP标准帧格式校验标志标志地址信息域控制协议域协议域1字节缺省1500字节7EFF037E1字节1字节1/2字节2/4

17、字节1字节q标志域：标志域：每个帧采用一个标志序列开始和结束，其为二进序列01111110（0 x7e）。所有实现连续检查这个标志，该标志用作帧同步。q地址域：地址域：一个单一的字节，包含二进制序列11111111（0 xff），表示所有节点地址，必须总是被识别和接收。q控制域：控制域：缺省为0 x03，表示用户数据传输采用无序号帧。q协议域协议域：由一个或两个字节组成，标识封装在报文的信息域里的数据报类型。 q信息域：信息域：是0个或更多的字节，包含数据报信息。包含填充但不包含协议域在内信息域的最大长度，称为最大接收单元（MRU），默认值是1500字节。q填充域：填充域：在传输的时候，信息域

18、会被填充若干字节以达到MRU。每个协议负责根据实际信息的大小确定填充的字节数。q帧校验序列域：帧校验序列域：缺省为16比特（两个字节），也可以根据应用，通过LCP协商为32比特。FCS域计算的范围覆盖了地址、控制、协议、信息和填充域的全部比特。填充域常见协议字段编码q常见协议字段编码00210021Internet Protocol-IPInternet Protocol-IP002bNovell IPX0023OSI NPDU(Network Protocol Data Unit) Protocol0281MPLS unicast packet0283MPLS multicast packe

19、t002dVan Jacobson Compressed TCP/IP002fVan Jacobson Uncompressed TCP/IP80218021Internet Protocol Control Protocol-IPCPInternet Protocol Control Protocol-IPCP802bNovell IPX Control Protocol8023OSI Control Protocol8281MPLS Control Protocol8031Bridging NCC021C021Link Control Protocol-LCPLink Control Pr

20、otocol-LCPC023C023Password Authentication Protocol-Password Authentication Protocol-认证阶段用到认证阶段用到C223C223Challenge Handshake Authentication Protocol-Challenge Handshake Authentication Protocol-认证阶段用到认证阶段用到Page 35Page 36LCP控制报文类型LCP报文类型由代码域标识：链路维护报文(管理调试链路)链路配置报文(建立和配置链路)链路终结报文(终止链路)0 x01 Configure-Re

21、quest0 x02 Configure-Ack0 x03 Configure_Nak0 x04 Configure-Reject0 x05 Terminate-Request0 x06 Terminate-Reply0 x07 Code-Reject0 x08 Protocol-Reject0 x09 Echo-Request0 x0A Echo-Reply0 x0B Discard-Request0 x0C Identification0 x0D Time-RemainingPage 37NCP控制报文格式标识域代码域代码域长度域 数据1字节1字节2字节标志地址控制协议域校验标志0 x7E

22、0 xFF0 x037E0 x8021 Internet Protocol Control Protocol0 x8023 OSI Control Protocol0 x8281 MPLS Control Protocol此处提到的NCP的报文格式和LCP报文格式一致，不同报文类型对应的数据域的格式不同。0 x01 Configure-Request0 x02 Configure-Ack0 x03 Configure_Nak0 x04 Configure-Reject0 x05 Terminate-Request0 x06 Terminate-Reply0 x07 Code-RejectNCP

23、支持的报文类型：PPP 测试诊断方法 可以通过如下命令查看ppp协商的整个过程 debugging ppp all interface * *的选取： 如果是server端则为Virtual-Template接口，如果是拨号端则为dialer接口。 通过这条Debug信息，可以将PPP的协议报文打印出来，看报文交互有没有问题 备注： 目前我们的调试信息是有时间限制的，时间一到就不在打印调试信息，所以有时候可能有疑问，怎么没有PPP报文了，在用户视图下通过这条命令可以设置调试信息的关闭时间，设置为0则不关闭debugging timeout ? integer The time in minut

24、es when the debug will be sto pped debugging timeout 下面介绍ppp的具体打印信息，如果遇到异常的打印信息，请参考异常信息FAQPage 38PPPoE定位一指禅 Page 39协商阶段协商阶段Check pointCheck point备注备注具体协商过程具体协商过程LCPLCP : acksent - opened LCP建链成功LCP协商具体过程认证阶段CHAP : WaitAAA - ServerSuccess 或者PAP : WaitAAA - ServerSuccess 认证成功认证阶段过程NCPIPCP : ackrcvd -

25、ackrcvd - opened opened IPCP协商成功IPCP协商过程链路维持阶段code EchoReply(0a)EchoReply(0a)链路心跳正常链路心跳检测过程LCP定位一指禅Page 40协商具体阶协商具体阶段段Check pointCheck point备注备注具体阶段具体阶段异常错误检异常错误检索索initial - starting LCP : initial - starting 协商过程FAQstarting-reqsentLCP : starting - reqsent协商过程reqsent-acksentLCP : reqsent - acksent 协商

26、过程acksent-openedLCP : acksent - opened LCP协商完成协商过程认证阶段定位一指禅协商具体阶段协商具体阶段Check pointCheck point备注备注具体阶段具体阶段异常错误检索异常错误检索Initial - SendChallenge CHAP : Initial - CHAP : Initial - SendChallenge SendChallenge 或者或者Initial - Initial - ServerListen ServerListen 认证过程FAQSendChallenge - WaitAAA CHAP : CHAP : Se

27、ndChallenge - SendChallenge - WaitAAA WaitAAA 或者或者PAP : ServerListen PAP : ServerListen - WaitAAA - WaitAAA 认证过程WaitAAA - ServerSuccessCHAP : WaitAAA - CHAP : WaitAAA - ServerSuccess ServerSuccess 或者或者PAP : WaitAAA - PAP : WaitAAA - ServerSuccessServerSuccess认证成功认证过程Page 41IPCP定位一指禅协商具体阶段协商具体阶段Check

28、 pointCheck point备注备注具体阶段具体阶段异常错误检索异常错误检索initial - starting IPCP : initial - initial - starting starting 开始过程FAQstarting - reqsent IPCP : starting - starting - reqsent reqsent 请求阶段reqsent - ackrcvd reqsent - reqsent - ackrcvd ackrcvd 确认阶段ackrcvd - opened IPCP : ackrcvd - ackrcvd - opened opened IPCP

29、协商成功IPCP协商成功Page 42链路维护定位一指禅协商具体阶段协商具体阶段Check pointCheck point备注备注具体阶段具体阶段异常错误检索异常错误检索EchoRequest(09)-发送心发送心跳检测报文跳检测报文code EchoRequestEchoRequest(09)(09)发送心跳报文发送心跳报文FAQEchoReply(0a)-EchoReply(0a)-发送心跳回发送心跳回复报文复报文code EchoReply(0EchoReply(0a),a),发送心跳报文发送心跳报文Page 43PPP LCP交互流程Page 442次交互两种情况：p第一次交互中，接

30、收方不认可Config-Request报文中部分配置参数选项中的值，则回送Config-Nak报文，携带希望的配置参数选项内容；p第二次交互中，发送方重新发送一个Config-Request报文，将第一次交互中对方不认可的选项信息值修改为可以认可的内容。p第一次交互中，接收方无法识别Config-Request报文中部分配置参数选项，则回送Config-Reject报文，携带无法识别的内容；p第二次交互中，发送方重新发送一个Config-Request报文，将第一次交互中对方无法识别的选项信息删除。p接收方对接收到的Config-Request报文携带的所有配置项内容均认可，则回应一个Conf

31、ig-Ack报文。p Config-Ack报文中唯一修改的内容就是代码域。正常的正常的LCPLCP交互过程交互过程需要重新协商的需要重新协商的LCPLCP交互过程交互过程PPP LCP阶段（Server 侧）LCP阶段： Jan 20 2011 14:44:37.380.2+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 LCP Open Event state initial /LCP 初始状态为 initial Jan 20 2011 14:44:37.380.3+08:00 AR2220 PPP/7/debug2: P

32、PP State Change: Virtual-Template47:0 LCP : initial - starting initial - starting 观察点观察点1 1 Jan 20 2011 14:44:37.380.4+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 LCP Lower Up Event state starting /收到up事件后变为starting Jan 20 2011 14:44:37.380.5+08:00 AR2220 PPP/7/debug2: PPP State Chang

33、e: Virtual-Template47:0 LCP : starting - reqsent starting - reqsent 观察点观察点2 2： Jan 20 2011 14:44:37.380.6+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output LCP(c021) Pkt, Len 23 State reqsent, code ConfReq(01)ConfReq(01), id 1, len 19 MRU(1), len 4, val 05d4 AuthProto(3), len 5, CHA

34、P c22305 MagicNumber(5), len 6, val 0d928bd0 /starting状态就LCP报文协商参数 Page 45lLCP阶段：阶段：首先打开连接，然后确定相关通信参数(包括MTU、compress type、及链路认证类型。链路设置完后确认帧，然后是可选的链路质量确认阶段，LCP确定链路质量在链路建立阶段，PPP协议通过LCP报文进行链路的建立和协商过程。此时LCP报文作为PPP的净载荷被封装在PPP数据帧的信息域中，PPP数据帧的协议域的值固定填充0 xC021。在链路建立阶段的整个过程中信息域的内容是变化的，它包括很多种类型的报文，所以这些报文也要通过相

35、应的字段来区分。Code域代码域的长度为一个字节，主要是用来标识LCP数据报文的类型。在链路建立阶段，接收方接收到LCP数据报文。当其代码域的值无效时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。常见code值code值报文类型0 x01Configure-Request0 x02Configure-Ack0 x03Configure-Nak0 x04Configure-Reject0 x05Terminate-Request0 x06Terminate-Ack0 x07Code-Reject0 x08Protocol-Reject0 x09Echo-Request0

36、 x0AEcho-Reply0 x0BDiscard-Request0 x0CReserved常见code值 PPP LCP阶段 Jan 20 2011 14:44:37.410.2+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 LCP RCR+(Receive Config Good Request) Event state reqsent /发出LCPrequest请求则状态变为reqsent Jan 20 2011 14:44:37.410.1+08:00 AR2220 PPP/7/debug2: PPP Packe

37、t: Virtual-Template47:0 Input LCP(c021) Pkt, Len 18 State reqsent, code ConfReq(01), ConfReq(01), id 1, len 14 MRU(1), len 4, val 012c MagicNumber(5), len 6, val 0f600dcc /收到对端发过来的LCP请求 Jan 20 2011 14:44:37.410.3+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output LCP(c021) Pkt, Len 1

38、8 State reqsent, code ConfAck(02), ConfAck(02), id 1, len 14 MRU(1), len 4, val 012c MagicNumber(5), len 6, val 0f600dcc /针对对端的LCP请求发出LCP回应报文 Jan 20 2011 14:44:37.410.4+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 LCP : reqsent - acksent reqsent - acksent 观察点观察点2 2：发出发出ackack报文，

39、状态变为报文，状态变为acksentPage 46PPP LCP阶段 Jan 20 2011 14:44:37.410.5+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Input LCP(c021) Pkt, Len 23 State acksent, code ConfAck(02), ConfAck(02), id 1, len 19 MRU(1), len 4, val 05d4 AuthProto(3), len 5, CHAP c22305 MagicNumber(5), len 6, val 0d928bd

40、0 /收到对端的LCP回应报文 Jan 20 2011 14:44:37.410.6+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 LCP RCA(Receive Config Ack) Event state acksent Jan 20 2011 14:44:37.410.7+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 LCP : acksent - opened acksent - opened 观察点4：收到ack报文，LCP状

41、态变为openedPage 47异常信息FAQPPP link was closed because the status of the physical layer was Down./PPP link was closed because the status of the physical layer was Down./物理层物理层DownDown 检查接口下得相关配置和物理连接。LCP negotiation failed because the result cannot be accepted.LCP negotiation failed because the result c

42、annot be accepted. LCP协商结果不可接受（一般是由于认证协商未完成）PPP negotiated again because PPP received a Code-Reject packet. PPP negotiated again because PPP received a Code-Reject packet. 这是LCP中二次协商的过程，由于接收端不认识ConfigRequest中某些选项，此是中间过程，可不关注。PPP negotiated again because PPP received a Configure-Nak packet. PPP negot

43、iated again because PPP received a Configure-Nak packet. LCP二次协商收到一个Configure-Nak报文，此是中间过程，可不关注。PPP negotiated again because PPP received Configure-Ack packet. PPP negotiated again because PPP received Configure-Ack packet. LCP二次协商收到一个Configure-Ack报文，此是中间过程，可不关注。LCP negotiated again because LCP rece

44、ived Configure-Request packet. LCP negotiated again because LCP received Configure-Request packet. LCP二次协商收到一个Configure-Request报文，此是中间过程，可不关注。Please encapsulate PPP first. Please encapsulate PPP first. 此为ppp协议一致性问题，请检查ppp的配置。The interface does not exist. The interface does not exist. 请检查相关的接口配置。Page

45、 48认证阶段 Jan 20 2011 14:44:37.420.1+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 : Enter Authenticate Phase ! /进入认证阶段 Jan 20 2011 14:44:37.420.2+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 CHAP Initial Event state Initial Jan 20 2011 14:44:37.420.3+08:00 AR2220 PPP/7/debu

46、g2: PPP Event: Virtual-Template47:0 CHAP Server Lower Up Event state Initial Jan 20 2011 14:44:37.420.4+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output CHAP(c223) Pkt, Len 25 State Initial, code Challenge(01code Challenge(01), id 1, len 21 Value_Size: 16 Value: fc 9b 56 e1 53 e3 a

47、6 26 1b 54 e5 e2 a1 ed 90 87 Name: /作为认证方发出挑战报文 Jan 20 2011 14:44:37.420.5+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 CHAP : Initial - SendChallenge : Initial - SendChallenge 观察点观察点1 1： Jan 20 2011 14:44:37.420.6+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Inpu

48、t CHAP(c223) Pkt, Len 27 State SendChallenge, code Response(02), code Response(02), id 1, len 23 Value_Size: 16 Value: fa c0 4f 2d 45 e3 22 52 65 0 54 27 32 d4 8a c9 Name: zx /收到对端的回应报文，包含用户名和加密后的密码 Page 49认证阶段 Jan 20 2011 14:44:37.420.7+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 CHA

49、P Receive Response Event state SendChallenge Jan 20 2011 14:44:37.420.8+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 CHAP : SendChallenge - SendChallenge - WaitAAA WaitAAA 观察点观察点2 2：将用户名密码发到将用户名密码发到AAA AAA Jan 20 2011 14:44:37.420.9+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-

50、Template47:0 CHAP AAA Result Event state WaitAAA Jan 20 2011 14:44:37.420.10+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 CHAP : WaitAAA - WaitAAA - ServerSuccess ServerSuccess 观察点观察点3 3：AAAAAA返回成功返回成功 Jan 20 2011 14:44:37.420.11+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Te

51、mplate47:0 Output CHAP(c223) Pkt, Len 20 State ServerSuccess, code SUCCESS(03), code SUCCESS(03), id 1, len 16 Message: Welcome to . /发出认证成功的报文给对端Page 50l验证方没有配置用户名的验证方没有配置用户名的CHAPCHAP验证过程如下：验证过程如下：l1. 1.验证方主动发起验证请求，验证方向被验证方发送一验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文（些随机产生的报文（ChallengeChallenge）l2. 2.验证方接到验证

52、方得验证请求后，利用报文验证方接到验证方得验证请求后，利用报文IDID，缺，缺省的省的CHAPCHAP密码和密码和MD5MD5算法对该随机报文进行加密，讲算法对该随机报文进行加密，讲生成的密文和自己的用户名发回验证方（生成的密文和自己的用户名发回验证方（ResponseResponse）；）；l3. 3.验证方用自己保存的被验证方密码和验证方用自己保存的被验证方密码和MD5MD5算法对原随算法对原随机报文加密，比较机报文加密，比较2 2者的密文，根据比较结果返回不同者的密文，根据比较结果返回不同的响应（的响应（Acknowledge or Not AcknowledgeAcknowledge

53、or Not Acknowledge）lCHAPCHAP只在网络上传输用户名，而并不传输用户口令只在网络上传输用户名，而并不传输用户口令( (准确地讲准确地讲, ,它不直接传输口令它不直接传输口令, ,传输的是用传输的是用MD5MD5算法将口算法将口令与一随机报文令与一随机报文IDID一起计算的结果一起计算的结果), ),因此它的安全性要因此它的安全性要比比PAPPAP高高. .异常情况FAQPPP link was closed because CHAP authentication failed. /CHAP认证失败 检查chap配置的认证密码是否正确PPP link was closed

54、 because PAP authentication failed. /PAP认证失败 检查pap认证配置是否正确PPP link was closed because PAP protocol was rejected. /PAP认证协商被拒绝 检查pap认证的配置是否正确authentication failed and PPP link was closed because CHAP was disabled on the peer./对端未设置CHAP认证账号 请配置对端的chap认证用户名和密码authentication failed and PPP link was close

55、d because PAP was disabled on the peer. /对端未设置PAP认证账号 请检查两边PAP配置是否在正确。PPP link was closed because the CHAP protocol was rejected. 请检查client和server的chap配置（比如如果server配了认证为chap，而client没有配置chap认证帐号） The encrypted password is invalid. 请检查CHAP密码配置。Page 51IPCPIPCP阶段： Jan 20 2011 14:44:37.420.12+08:00 AR222

56、0 PPP/7/debug2: PPP Event: Virtual-Template47:0 : Ask peers IP address Jan 20 2011 14:44:37.420.13+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 : Get Peers IP address 21.0.15.253 Jan 20 2011 14:44:37.420.14+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 IPCP Open Event stat

57、e initial Jan 20 2011 14:44:37.420.15+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 IPCP : initial - starting IPCP : initial - starting 观察点观察点1 1：进进入IPCP协商阶段 Jan 20 2011 14:44:37.420.16+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 IPCP Lower Up Event state starting

58、Jan 20 2011 14:44:37.420.17+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 IPCP : starting - reqsent IPCP : starting - reqsent 观察点观察点2 2 Jan 20 2011 14:44:37.420.18+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output IPCP(8021) Pkt, Len 14 State reqsent, code ConfRe

59、q(01), id 1, len 10 IP Address(3), len 6, val 2f2f2f2f /发送ipcp请求报文，携带本端ip地址 Page 52IPCP Jan 20 2011 14:44:37.420.19+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Input IPCP(8021) Pkt, Len 26 State reqsent, code ConfReq(01), id 1, len 22 IP Address(3), len 6, val 00000000 /收到对端的ipcp请求报文

60、，携带地址为0.0.0.0 Jan 20 2011 14:44:37.420.20+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 IPCP RCR-(Receive Config Bad Request) Event state reqsent Jan 20 2011 14:44:37.420.21+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output IPCP(8021) Pkt, Len 20 State reqsent, code Con