PPPoEserver-client以及各个流程信息说明.ppt

PPPoE测试说明,2019/8/8,目录,功能场景说明 测试技术指导 测试用例说明 问题诊断方法,PPPoE简单介绍,PPPoE 的英文是Point-to-Point Protocol over Ethernet，中文意思是以太网上的PPP。 PPPoE协议提供了在广播式的网络（如以太网）中多台主机连接到远端的访问集中器（访问集中器也称为宽带接入服务器）上的一种标准。,Page 3,PPPoE简单介绍,PPPoE服务器 设备提供了PPPoE服务器的功能，支持动态分配IP地址，提供多种认证方式，和防火墙配合，可以对内部网络提供安全保障，适用于校园、智能小区等通过以太网接入Internet的组网应用。 。 PPPoE客户端 局域网内所有主机通过同一个PPPoE会话传送数据，主机上不用安装PPPoE客户端拨号软件，而且同一个局域网中的所有主机可以共享一个帐号。,Page 4,PPPoE帧格式,以太网的帧格式,Page 5,PPPoE帧格式,Destination_address域 以太网单播目的地址或者以太网广播地址（0xFFFFFFFF）。 在Discovery数据包中，该域的值是以太网广播地址。 在PPPoE会话流量中，该域必须是Discovery阶段已经确定的通信对方的单播地址。 Source_address域 源设备的以太网MAC地址。 Ethernet_Type域 当值为0x8863时表示Discovery阶段 当值为0x8864时表示PPPoE会话阶段,Page 6,PPPoE帧格式,Payload域 VER：长度是4比特。PPPoE规范的本版本必须设置为0x01。 Type：长度是4比特。PPPoE规范的本版本必须设置为0x01。 Code：长度是8比特。其定义在后面的Discovery和PPPoE会话中分别指定。 Session_ID：长度是16比特。是一个网络字节序的无符号值。其值在后面Discovery数据包中定义。 Length：长度是16比特。该值是PPPoE的Payload长度。它不包括以太网头部和PPPoE头部的长度。 Payload：PPPoE的Payload，包含0个或多个Tag。,Page 7,PPPoE会话建立过程,PPPoE会话建立过程分为以下两个阶段： Discovery阶段：地址发现阶段 PPPoE Session阶段：PPPoE会话阶段 为了在以太网上建立点到点连接，每一个PPPoE会话必须知道通信对方的以太网地址，并建立一个唯一的会话标识符。PPPoE通过地址发现协议查找对方的以太网地址。,Page 8,PPPoE会话建立-PPP建链过程,PPP链路的建立是通过一系列的协商完成的： LCP除了用于建立、拆除和监控PPP数据链路，还主要进行链路层参数的协商，如MRU、验证方式 NCP主要用于协商在该数据链路上所传输的数据包的格式与类型，如IP地址 PPP链路建立过程：,Page 9,PPPoE会话建立-PPP建链过程,PPP链路建立过程的简单描述如下： 1、PPP协议运行总是以Dead阶段开始和结束。通常处在这个状态的时间很短，仅仅是检测到硬件设备后（即硬件连接状态为Up）就进入Establish阶段。 2、在Establish阶段，PPP链路进行LCP协商。协商内容包括工作方式是SP（Single-link PPP）还是MP（Multilink PPP）、最大接收单元MRU、验证方式、魔术字（magic number）和异步字符映射等选项。LCP协商成功后进入Opened状态，表示底层链路已经建立。 3、如果配置了验证，将进入Authenticate阶段，开始CHAP或PAP验证。如果没有配置验证，则直接进入Network阶段。,Page 10,PPPoE会话建立-PPP建链过程,PPP链路建立过程的简单描述如下： 4、对于Authenticate阶段，如果验证失败，进入Terminate阶段，拆 除链路，LCP状态转为Closed。如果验证成功，进入Network阶段， 此时LCP状态仍为Opened，而NCP状态从Initial转到Starting。 5、在Network阶段，PPP链路进行NCP协商，NCP协商包括IPCP（IP Control Protocol）、MPLSCP（MPLS Control Protocol）等协商。IPCP协商主要包括双方的IP地址。通过NCP协商来选择和配置一个网络层协议。只有相应的网络层协议协商成功后（相应协议的NCP协商状态为Opened），该网络层协议才可以通过这条PPP链路发送报文。例如：IPCP协商通过后，这条PPP链路才可以承载IP报文。,Page 11,PPPoE会话建立-PPP建链过程,PPP链路建立过程的简单描述如下： 6、 NCP协商成功后，PPP链路将一直保持通信。PPP运行过程中，可以随时中断连接，物理链路断开、认证失败、超时定时器时间到、管理员通过配置关闭连接等动作都可能导致进入链路进入Terminate阶段 7、进入Terminate阶段后且资源释放完，即进入Dead阶段。,Page 12,PPPoE会话建立-Discovery,Discovery阶段基本原理 当主机开始通过PPPoE接入服务器时，它必须先识别接入端的以太网MAC地址，建立PPPoE的Session_ID。这就是Discovery阶段的目的。 Discovery阶段由四个过程组成。完成之后通信双方都会知道PPPoE的Session_ID以及对方以太网地址，它们共同确定了唯一的PPPoE会话 共分为四个阶段,Page 13,PPPoE会话建立-Discovery,1.主机在本以太网内广播一个PADI（PPPoE Active Discovery Initial）报文，在此报文中包含主机想要得到的服务类型信息。,Page 14,PPPoE会话建立-Discovery,2.以太网内的所有服务器收到这个PADI报文后，将其中请求的服务与自己能提供的服务进行比较，可以提供此服务的服务器发回PADO（PPPoE Active Discovery Offer）报文。,Page 15,PPPoE会话建立-Discovery,3.主机可能收到多个服务器的PADO报文，主机将依据PADO的内容，从多个服务器中选择一个，并向它发回一个会话请求报文PADR（PPPoE Active Discovery Request)。,Page 16,PPPoE会话建立-Discovery,4.服务器产生一个唯一的会话标识，标识和主机的这段PPPoE会话。并把此会话标识通过会话确认报文PADS（PPPoE Active Discovery Session-confirmation）发回给主机，如果没有错误，双方进入PPPoE Session阶段,Page 17,PPPoE会话阶段-PPPoE Session,PPPoE会话（PPPoE Session）开始后，PPP报文作为PPPoE帧的净荷，封装在以太网帧发送到对端。 这时所有的以太网数据包都是单播的。 Ethernet_Type域设置为0x8864。 PPPoE的Code必须设置为0x00。 PPPoE会话的Session_ID不允许发生改变，必须是Discovery阶段所指定的值。 PPPoE的Payload包含一个PPP帧。PPP帧的开始字段是PPP Protocol-ID。,Page 18,PPPoE会话阶段-PPPoE Session,从主机发送到接入服务器的PPP LCP数据包示例图 进入PPPoE Session阶段后，主机或服务器任何一方都可发PADT报文通知对方结束PPPoE会话。,Page 19,典型应用场景,PPPoE Client 当AR设备将PPPoE作为一种WAN（Wide Area Network）接入方式时，AR充当PPPoE Client的角色，BRAS（Broadband Remote Access Server）作为PPPoE Server。,Page 20,典型应用场景,PPPoE Server AR1200设备提供了PPPoE Server的功能，支持动态分配IP地址，提供本地认证、RADIUS/HWTACACS等多种认证方式，适用于校园、智能小区等通过以太网接入Internet的组网应用。,Page 21,目录,功能场景说明 测试技术指导 测试用例说明 问题诊断方法,简单测试场景,PPPoE Client 与PPPoE Server互通简单场景。,Page 23,配置PPPoE Client,测试过程中很重要的一部分是配置DCC，然后绑定物理接口。,Page 24,配置PPPoE Server,通过虚拟接口模板与物理接口绑定完成Server配置。,Page 25,目录,功能场景说明 测试技术指导 测试用例说明 问题诊断方法,PPPoE测试用例说明,PPPoE Client 该用例测试设备PPPoE Client功能 测试方法 设备上配置PPPoE Client功能，通过创建Dialer口与物理接口进行绑定。然后配置PPPoE Server端，检查拨号状态是否成功。,Page 27,PPPoE测试用例说明,PPPoE Server 该用例测试设备PPPoE Server功能 测试方法 设备上配置PPPoE Server功能，通过创建虚拟接口模板与物理接口进行绑定。然后配置PPPoE Client端，检查拨号状态是否成功。,Page 28,目录,功能场景说明 测试技术指导 测试用例说明 问题诊断方法,PPPoE测试诊断方法,在配置各设备后发现PPPoE 用户无法拨入，请使用下面的故障诊断流程，如图所示。,Page 30,Page 31,PPPoE测试诊断方法,主要检查思路： 检查虚拟接口模板是否配置正确。 检查是否分配到IP 地址。 其他检查思路： 检查链路是否建立成功 检查网络侧是否有回应报文 检查路由器是否拒绝呼叫 检查数据通道协议是否Up,Page 32,实际组网,PPPoE Client 与PPPoE Server互通简单场景。,Page 33,Page 34,PPP标准帧格式,校验,标志,标志,地址,信息域,控制,协议域,1字节,缺省1500字节,7E,FF,03,7E,1字节,1字节,1/2字节,2/4字节,1字节,标志域：每个帧采用一个标志序列开始和结束，其为二进序列01111110（0x7e）。所有实现连续检查这个标志，该标志用作帧同步。 地址域：一个单一的字节，包含二进制序列11111111（0xff），表示所有节点地址，必须总是被识别和接收。 控制域：缺省为0x03，表示用户数据传输采用无序号帧。 协议域：由一个或两个字节组成，标识封装在报文的信息域里的数据报类型。 信息域：是0个或更多的字节，包含数据报信息。包含填充但不包含协议域在内信息域的最大长度，称为最大接收单元（MRU），默认值是1500字节。 填充域：在传输的时候，信息域会被填充若干字节以达到MRU。每个协议负责根据实际信息的大小确定填充的字节数。 帧校验序列域：缺省为16比特（两个字节），也可以根据应用，通过LCP协商为32比特。FCS域计算的范围覆盖了地址、控制、协议、信息和填充域的全部比特。,填充域,常见协议字段编码,常见协议字段编码 0021 Internet Protocol-IP 002b Novell IPX 0023 OSI NPDU(Network Protocol Data Unit) Protocol 0281 MPLS unicast packet 0283 MPLS multicast packet 002d Van Jacobson Compressed TCP/IP 002f Van Jacobson Uncompressed TCP/IP 8021 Internet Protocol Control Protocol-IPCP 802b Novell IPX Control Protocol 8023 OSI Control Protocol 8281 MPLS Control Protocol 8031 Bridging NC C021 Link Control Protocol-LCP C023 Password Authentication Protocol-认证阶段用到 C223 Challenge Handshake Authentication Protocol-认证阶段用到,Page 35,Page 36,LCP控制报文类型,LCP报文类型由代码域标识：,链路维护报文(管理调试链路),链路配置报文(建立和配置链路),链路终结报文(终止链路),0x01 Configure-Request 0x02 Configure-Ack 0x03 Configure_Nak 0x04 Configure-Reject 0x05 Terminate-Request 0x06 Terminate-Reply 0x07 Code-Reject 0x08 Protocol-Reject 0x09 Echo-Request 0x0A Echo-Reply 0x0B Discard-Request 0x0C Identification 0x0D Time-Remaining,Page 37,NCP控制报文格式,标志,地址,控制,协议域,校验,标志,0x7E,0xFF,0x03,7E,0x8021 Internet Protocol Control Protocol 0x8023 OSI Control Protocol 0x8281 MPLS Control Protocol,此处提到的NCP的报文格式和LCP报文格式一致，不同报文类型对应的数据域的格式不同。,0x01 Configure-Request 0x02 Configure-Ack 0x03 Configure_Nak 0x04 Configure-Reject 0x05 Terminate-Request 0x06 Terminate-Reply 0x07 Code-Reject,NCP支持的报文类型：,PPP 测试诊断方法,可以通过如下命令查看ppp协商的整个过程 debugging ppp all interface * *的选取： 如果是server端则为Virtual-Template接口，如果是拨号端则为dialer接口。 通过这条Debug信息，可以将PPP的协议报文打印出来，看报文交互有没有问题 备注： 目前我们的调试信息是有时间限制的，时间一到就不在打印调试信息，所以有时候可能有疑问，怎么没有PPP报文了，在用户视图下通过这条命令可以设置调试信息的关闭时间，设置为0则不关闭 debugging timeout ? integer The time in minutes when the debug will be sto pped debugging timeout 下面介绍ppp的具体打印信息，如果遇到异常的打印信息，请参考异常信息FAQ,Page 38,PPPoE定位一指禅,Page 39,LCP定位一指禅,Page 40,认证阶段定位一指禅,Page 41,IPCP定位一指禅,Page 42,链路维护定位一指禅,Page 43,PPP LCP交互流程,Page 44,2次交互两种情况： 第一次交互中，接收方不认可Config-Request报文中部分配置参数选项中的值，则回送Config-Nak报文，携带希望的配置参数选项内容； 第二次交互中，发送方重新发送一个Config-Request报文，将第一次交互中对方不认可的选项信息值修改为可以认可的内容。 第一次交互中，接收方无法识别Config-Request报文中部分配置参数选项，则回送Config-Reject报文，携带无法识别的内容； 第二次交互中，发送方重新发送一个Config-Request报文，将第一次交互中对方无法识别的选项信息删除。,接收方对接收到的Config-Request报文携带的所有配置项内容均认可，则回应一个Config-Ack报文。 Config-Ack报文中唯一修改的内容就是代码域。,正常的LCP交互过程,需要重新协商的LCP交互过程,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: PPP State Change: Virtual-Template47:0 LCP : initial starting 观察点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 Change: Virtual-Template47:0 LCP : starting reqsent 观察点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), id 1, len 19 MRU(1), len 4, val 05d4 AuthProto(3), len 5, CHAP c22305 MagicNumber(5), len 6, val 0d928bd0 /starting状态就LCP报文协商参数,Page 45,LCP阶段： 首先打开连接，然后确定相关通信参数(包括MTU、compress type、及链路认证类型。链路设置完后确认帧，然后是可选的链路质量确认阶段，LCP确定链路质量 在链路建立阶段，PPP协议通过LCP报文进行链路的建立和协商过程。此时LCP报文作为PPP的净载荷被封装在PPP数据帧的信息域中，PPP数据帧的协议域的值固定填充0xC021。 在链路建立阶段的整个过程中信息域的内容是变化的，它包括很多种类型的报文，所以这些报文也要通过相应的字段来区分。 Code域 代码域的长度为一个字节，主要是用来标识LCP数据报文的类型。 在链路建立阶段，接收方接收到LCP数据报文。当其代码域的值无效时，就会向对端发送一个LCP的代码拒绝报文（Code-Reject报文）。,常见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 Packet: Virtual-Template47:0 Input LCP(c021) Pkt, Len 18 State reqsent, code 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 18 State reqsent, code 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 观察点2：发出ack报文，状态变为acksent,Page 46,PPP 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), id 1, len 19 MRU(1), len 4, val 05d4 AuthProto(3), len 5, CHAP c22305 MagicNumber(5), len 6, val 0d928bd0 /收到对端的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 观察点4：收到ack报文，LCP状态变为opened,Page 47,异常信息FAQ,PPP link was closed because the status of the physical layer was Down./物理层Down 检查接口下得相关配置和物理连接。 LCP negotiation failed because the result cannot be accepted. LCP协商结果不可接受（一般是由于认证协商未完成） PPP negotiated again because PPP received a Code-Reject packet. 这是LCP中二次协商的过程，由于接收端不认识ConfigRequest中某些选项，此是中间过程，可不关注。 PPP negotiated again because PPP received a Configure-Nak packet. LCP二次协商收到一个Configure-Nak报文，此是中间过程，可不关注。 PPP negotiated again because PPP received Configure-Ack packet. LCP二次协商收到一个Configure-Ack报文，此是中间过程，可不关注。 LCP negotiated again because LCP received Configure-Request packet. LCP二次协商收到一个Configure-Request报文，此是中间过程，可不关注。 Please encapsulate PPP first. 此为ppp协议一致性问题，请检查ppp的配置。 The interface does not exist. 请检查相关的接口配置。,Page 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/debug2: 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(01), id 1, len 21 Value_Size: 16 Value: fc 9b 56 e1 53 e3 a6 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 观察点1： Jan 20 2011 14:44:37.420.6+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Input CHAP(c223) Pkt, Len 27 State SendChallenge, 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,Authenticate-Ack和Authenticate-Nak用于回应Authentiacte-Request，通知被验证方验证结果，如果用户名密码匹配，则回应Authenticate-Ack，否则回应Authenticate-Nak并终止链路。 CHAP单向验证过程分为两种情况:验证方配置了用户名和验证方没有配置用户名。 验证方配置了用户名的CHAP验证过程如下： 1.验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文（challenge），并同时将本端的用户名附带上一期发送给被验证方； 2.被验证方接到验证方得验证请求后，根据此报文中验证方得用户名在本端的用户表查找该用户对应的密码，如果再用户表找到了与验证方用户名相同的用户， 便利用报文ID，此用户的密钥（密码）和MD5算法对该随机报文进行加密，将生成的密文和被验证方自己的用户名发回验证方（Response）； 3.验证方用自己保存的被验证方密码和MD5算法对原随机报文加密，比较二者的密文，根据比较结果返回不同的相应（Acknowledge or Not Acknowledge）,认证阶段, Jan 20 2011 14:44:37.420.7+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 CHAP 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 WaitAAA 观察点2：将用户名密码发到AAA Jan 20 2011 14:44:37.420.9+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-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 ServerSuccess 观察点3：AAA返回成功 Jan 20 2011 14:44:37.420.11+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output CHAP(c223) Pkt, Len 20 State ServerSuccess, code SUCCESS(03), id 1, len 16 Message: Welcome to . /发出认证成功的报文给对端,Page 50,验证方没有配置用户名的CHAP验证过程如下： 1.验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文（Challenge） 2.验证方接到验证方得验证请求后，利用报文ID，缺省的CHAP密码和MD5算法对该随机报文进行加密，讲生成的密文和自己的用户名发回验证方（Response）； 3.验证方用自己保存的被验证方密码和MD5算法对原随机报文加密，比较2者的密文，根据比较结果返回不同的响应（Acknowledge or Not Acknowledge） CHAP只在网络上传输用户名，而并不传输用户口令(准确地讲,它不直接传输口令,传输的是用MD5算法将口令与一随机报文ID一起计算的结果),因此它的安全性要比PAP高.,异常情况FAQ,PPP link was closed because CHAP authentication failed. /CHAP认证失败 检查chap配置的认证密码是否正确 PPP link was closed 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 closed 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 51,IPCP,IPCP阶段： Jan 20 2011 14:44:37.420.12+08:00 AR2220 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 state initial Jan 20 2011 14:44:37.420.15+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 IPCP : initial starting 观察点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 Jan 20 2011 14:44:37.420.17+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 IPCP : starting reqsent 观察点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 ConfReq(01), id 1, len 10 IP Address(3), len 6, val 2f2f2f2f /发送ipcp请求报文，携带本端ip地址,Page 52,IPCP, 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请求报文，携带地址为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, Le