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

PPPoE PPPoE测试说明测试说明 * 英文目录标题:35-40pt 颜色: R153 G0 B0 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文目录标题:35-40pt 颜色: R153 G0 B0 字体:黑体 英文目录正文:28-30pt 子目录 (2-5级) :20-30pt 颜色:黑色 内部使用字体 : FrutigerNext LT Regular 外部使用字体 : Arial 中文目录正文:28-30pt 子目录(2-5级):20-30pt 颜色:黑色 字体:细黑体 目录目录 pp功能场景说明功能场景说明 pp测试技术指导测试技术指导 pp测试用例说明测试用例说明 pp问题诊断方法问题诊断方法 PPPoEPPPoE简单介绍简单介绍 PPPoE 的英文是Point-to-Point Protocol over Ethernet，中文 意思是以太网上的PPP。 PPPoE协议提供了在广播式的网络（如以太网）中多台主 机连接到远端的访问集中器（访问集中器也称为宽带接入 服务器）上的一种标准。 Page 3 PPPoEPPPoE简单介绍简单介绍 PPPoE服务器 设备提供了PPPoE服务器的功能，支持动 态分配IP地址，提供多种认证方式，和防火 墙配合，可以对内部网络提供安全保障，适 用于校园、智能小区等通过以太网接入 Internet的组网应用。 。 PPPoE客户端 局域网内所有主机通过同一个PPPoE会话 传送数据，主机上不用安装PPPoE客户端拨 号软件，而且同一个局域网中的所有主机可 以共享一个帐号。 Page 4 PPPoEPPPoE帧格式帧格式 以太网的帧格式 Page 5 PPPoEPPPoE帧格式帧格式 Destination_address域 以太网单播目的地址或者以太网广播地址（ 0xFFFFFFFF）。 在Discovery数据包中，该域的值是以太网广播地 址。 在PPPoE会话流量中，该域必须是Discovery阶段 已经确定的通信对方的单播地址。 Source_address域 源设备的以太网MAC地址。 Ethernet_Type域 当值为0x8863时表示Discovery阶段 当值为0x8864时表示PPPoE会话阶段 Page 6 PPPoEPPPoE帧格式帧格式 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 PPPoEPPPoE会话建立过程会话建立过程 PPPoE会话建立过程分为以下两个阶段： Discovery阶段：地址发现阶段 PPPoE Session阶段：PPPoE会话阶段 为了在以太网上建立点到点连接，每 一个PPPoE会话必须知道通信对方的以太 网地址，并建立一个唯一的会话标识符。 PPPoE通过地址发现协议查找对方的以太 网地址。 Page 8 PPPoEPPPoE会话建立会话建立-PPP-PPP建链过程建链过程 PPP链路的建立是通过一系列的协商完成的： LCP除了用于建立、拆除和监控PPP数据链路 ，还主要进行链路层参数的协商，如MRU、 验证方式 NCP主要用于协商在该数据链路上所传输的 数据包的格式与类型，如IP地址 lPPP链路建立过程： Page 9 PPPoEPPPoE会话建立会话建立-PPP-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 PPPoEPPPoE会话建立会话建立-PPP-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 PPPoEPPPoE会话建立会话建立-PPP-PPP建链过程建链过程 PPP链路建立过程的简单描述如下： 6、 NCP协商成功后，PPP链路将一直保持通信。PPP运行过程中，可以 随时中断连接，物理链路断开、认证失败、超时定时器时间到、管理员通 过配置关闭连接等动作都可能导致进入链路进入Terminate阶段 7、进入Terminate阶段后且资源释放完，即 进入Dead阶段。 Page 12 PPPoEPPPoE会话建立会话建立-Discovery-Discovery Discovery阶段基本原理 当主机开始通过PPPoE接入服务器时，它必须先识别接入 端的以太网MAC地址，建立PPPoE的Session_ID。这就是 Discovery阶段的目的。 Discovery阶段由四个过程组成。完成之后通信双方都会知 道PPPoE的Session_ID以及对方以太网地址，它们共同确 定了唯一的PPPoE会话 共分为四个阶段 Page 13 PPPoEPPPoE会话建立会话建立-Discovery-Discovery 1.主机在本以太网内广播一个PADI（PPPoE Active Discovery Initial）报文，在此报文中包含主机想要得到的服务类型信息 。 Page 14 PPPoEPPPoE会话建立会话建立-Discovery-Discovery 2.以太网内的所有服务器收到这个PADI报文后，将其中请求 的服务与自己能提供的服务进行比较，可以提供此服务的服 务器发回PADO（PPPoE Active Discovery Offer）报文。 Page 15 PPPoEPPPoE会话建立会话建立-Discovery-Discovery 3.主机可能收到多个服务器的PADO报文，主机将依据PADO 的内容，从多个服务器中选择一个，并向它发回一个会话请 求报文PADR（PPPoE Active Discovery Request)。 Page 16 PPPoEPPPoE会话建立会话建立-Discovery-Discovery 4.服务器产生一个唯一的会话标识，标识和主机的这段 PPPoE会话。并把此会话标识通过会话确认报文PADS（ PPPoE Active Discovery Session-confirmation）发回给主机， 如果没有错误，双方进入PPPoE Session阶段 Page 17 PPPoEPPPoE会话阶段会话阶段-PPPoE Session-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 PPPoEPPPoE会话阶段会话阶段-PPPoE Session-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 ClientPPPoE Client 测试过程中很重要的一部分是配置DCC， 然后绑定物理接口。 Page 24 # dialer-rule dialer-rule 1 ip permit # interface Dialer1 link-protocol ppp ip address ppp-negotiate dialer user user2 dialer-group 1 dialer bundle 1 # interface GigabitEthernet0/0/0/ pppoe-client dial-bundle-number 1 # 配置配置PPPoE ServerPPPoE Server 通过虚拟接口模板与物理接口绑定完成 Server配置。 Page 25 # ip pool pool1 # ip pool pool1 network 192.168.10.10 mask 255.255.255.0 gateway-list 192.168.10.1 # interface Virtual-Template1 remote address pool pool1 ip address 192.168.10.10 255.255.255.0 # interface GigabitEthernet0/0/1 pppoe-server bind Virtual-Template 1 # 英文目录标题:35-40pt 颜色: R153 G0 B0 内部使用字体 : FrutigerNext LT Medium 外部使用字体 : Arial 中文目录标题:35-40pt 颜色: R153 G0 B0 字体:黑体 英文目录正文:28-30pt 子目录 (2-5级) :20-30pt 颜色:黑色 内部使用字体 : FrutigerNext LT Regular 外部使用字体 : Arial 中文目录正文:28-30pt 子目录(2-5级):20-30pt 颜色:黑色 字体:细黑体 目录目录 pp功能场景说明功能场景说明 pp测试技术指导测试技术指导 pp测试用例说明测试用例说明 pp问题诊断方法问题诊断方法 PPPoEPPPoE测试用例说明测试用例说明 PPPoE Client 该用例测试设备PPPoE Client功能 测试方法 设备上配置PPPoE Client功能，通过创建Dialer 口与物理接口进行绑定。然后配置PPPoE Server端，检查拨号状态是否成功。 Page 27 PPPoEPPPoE测试用例说明测试用例说明 PPPoE Server 该用例测试设备PPPoE Server功能 测试方法 设备上配置PPPoE Server功能，通过创建虚拟 接口模板与物理接口进行绑定。然后配置 PPPoE Client端，检查拨号状态是否成功。 Page 28 目录目录 功能场景说明功能场景说明 测试技术指导测试技术指导 测试用例说明测试用例说明 问题诊断方法问题诊断方法 PPPoEPPPoE测试诊断方法测试诊断方法 在配置各设备后发现PPPoE 用户无法拨入 ，请使用下面的故障诊断流程，如图所示 。 Page 30 Page 31 PPPoEPPPoE测试诊断方法测试诊断方法 主要检查思路： 检查虚拟接口模板是否配置正确。 检查是否分配到IP 地址。 l其他检查思路： 检查链路是否建立成功 检查网络侧是否有回应报文 检查路由器是否拒绝呼叫 检查数据通道协议是否Up Page 32 实际组网 lPPPoE Client 与PPPoE Server互通简单场景。 Page 33 Page 34 PPP标准帧格式 校验标志标志地址信息域控制 协议域 1字节缺省1500字节 7EFF03 7E 1字节1字节1/2字节2/4字节1字节 q标志域：每个帧采用一个标志序列开始和结束，其为二进序列01111110（0x7e）。所有实现连续检查这个标志， 该标志用作帧同步。 q地址域：一个单一的字节，包含二进制序列11111111（0xff），表示所有节点地址，必须总是被识别和接收。 q控制域：缺省为0x03，表示用户数据传输采用无序号帧。 q协议域：由一个或两个字节组成，标识封装在报文的信息域里的数据报类型。 q信息域：是0个或更多的字节，包含数据报信息。包含填充但不包含协议域在内信息域的最大长度，称为最大接 收单元（MRU），默认值是1500字节。 q填充域：在传输的时候，信息域会被填充若干字节以达到MRU。每个协议负责根据实际信息的大小确定填充的 字节数。 q帧校验序列域：缺省为16比特（两个字节），也可以根据应用，通过LCP协商为32比特。FCS域计算的范围覆盖了 地址、控制、协议、信息和填充域的全部比特。 填充域 常见协议字段编码 q常见协议字段编码 0021Internet Protocol-IP 002bNovell IPX 0023OSI NPDU(Network Protocol Data Unit) Protocol 0281MPLS unicast packet 0283MPLS multicast packet 002dVan Jacobson Compressed TCP/IP 002fVan Jacobson Uncompressed TCP/IP 8021Internet Protocol Control Protocol-IPCP 802bNovell IPX Control Protocol 8023OSI Control Protocol 8281MPLS Control Protocol 8031Bridging NC C021Link Control Protocol-LCP C023Password Authentication Protocol-认证阶段用到 C223Challenge 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控制报文格式 标识域代码域长度域 数据 1字节1字节2字节 标志地址控制协议域 校验标志 0x7E0xFF0x037E 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 协商阶段Check point备注具体协商过程 LCPLCP : acksent opened LCP建链成功LCP协商具体过程 认证阶段CHAP : WaitAAA ServerSuccess 或者 PAP : WaitAAA ServerSuccess 认证成功认证阶段过程 NCPIPCP : ackrcvd opened IPCP协商成功IPCP协商过程 链路维持阶段code EchoReply(0a)链路心跳正常链路心跳检测过 程 LCP定位一指禅 Page 40 协商具体阶 段 Check point备注具体阶段异常错误检 索 initial starting LCP : initial starting 协商过程FAQ starting- reqsent LCP : starting reqsent 协商过程 reqsent- acksent LCP : reqsent acksent 协商过程 acksent- opened LCP : acksent opened LCP协商完成协商过程 认证阶段定位一指禅 协商具体阶段Check point备注具体阶段异常错误检索 Initial SendChallenge CHAP : Initial SendChallenge 或者 Initial ServerListen 认证过程FAQ SendChallenge - - WaitAAA CHAP : SendChallenge WaitAAA 或者 PAP : ServerListen WaitAAA 认证过程 WaitAAA ServerSuccess CHAP : WaitAAA ServerSuccess 或者 PAP : WaitAAA ServerSuccess 认证成 功 认证过程 Page 41 IPCP定位一指禅 协商具体阶段Check point备注具体阶段异常错误检索 initial starting IPCP : initial starting 开始过程FAQ starting reqsent IPCP : starting - - reqsent 请求阶段 reqsent ackrcvd reqsent ackrcvd 确认阶段 ackrcvd opened IPCP : ackrcvd opened IPCP协商成功IPCP协商成功 Page 42 链路维护定位一指禅 协商具体阶段Check point备注具体阶段异常错误检索 EchoRequest(09)-发送心跳 检测报文 code EchoRequest( 09) 发送心跳报文发送心跳报文FAQ EchoReply(0a)-发送心跳回 复报文 code EchoReply(0a), 发送心跳报文发送心跳报文 Page 43 PPP LCP交互流程 Page 44 2次交互两种情况： p第一次交互中，接收方不认可Config- Request报文中部分配置参数选项中的值 ，则回送Config-Nak报文，携带希望的配 置参数选项内容； p第二次交互中，发送方重新发送一个 Config-Request报文，将第一次交互中对 方不认可的选项信息值修改为可以认可的 内容。 p第一次交互中，接收方无法识别Config- Request报文中部分配置参数选项，则回 送Config-Reject报文，携带无法识别的内 容； p第二次交互中，发送方重新发送一个 Config-Request报文，将第一次交互中对 方无法识别的选项信息删除。 p接收方对接收到的Config-Request报文携带 的所有配置项内容均认可，则回应一个 Config-Ack报文。 p 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 lLCP阶段： 首先打开连接，然后确定相关通信参数(包括MTU、compress type、及链路认证类型。链路设置完后确认帧，然后是可 选的链路质量确认阶段，LCP确定链路质量 在链路建立阶段，PPP协议通过LCP报文进行链路的建立和协商 过程。此时LCP报文作为PPP的净载荷被封装在PPP数据 帧的信息域中，PPP数据帧的协议域的值固定填充 0xC021。 在链路建立阶段的整个过程中信息域的内容是变化的，它包括 很多种类型的报文，所以这些报文也要通过相应的字段 来区分。 Code域 代码域的长度为一个字节，主要是用来标识LCP数据报文的类 型。 在链路建立阶段，接收方接收到LCP数据报文。当其代码域的 值无效时，就会向对端发送一个LCP的代码拒绝报文（ Code-Reject报文）。 常见code值 code值报文类型 0x01Configure-Request 0x02Configure-Ack 0x03Configure-Nak 0x04Configure-Reject 0x05Terminate-Request 0x06Terminate-Ack 0x07Code-Reject 0x08Protocol-Reject 0x09Echo-Request 0x0AEcho-Reply 0x0BDiscard-Request 0x0CReserved 常见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 认证阶段 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 201