引：
CHAP验证为三次握手验证，验证过程如下：
１、Challenge：主演正方主动发起验证请求，主验证方向被验证方发送一个随机产生的数值，并同时将本端的用户名发送给被验证方。
２、Response：被验证方接收到主验证方的验证请求后，检查本地密码。如果本端接口上配置了默认的CHAP密码，则被验证方选用此密码；如果没有配置默认的CHAP密码，则被验证方根据主演正方的用户名在本端的用户表中查找该用户对应密码，并选用找到的密码。随后，被验证方利用MD5算法对报文ID，密码和随机数生成一个摘要，并将此摘要和自己的用户名发回给主验证方。
３、Acknowledge or Acknowledge：主验证方用MD5算法对报文ID、本地保存的被验证方密码和原随机数生成一个摘要，并与收到的摘要值进行比较。如果相同则向被验证方发送Acknowledge消息声明验证通过；如果不同则不通过，向被验证方发送Not Acknowledge。
本资料来自H3C 认证系列教程（H3C NE下册）
现在说一说 “ 如果没有配置默认的CHAP密码，则被验证方根据主演正方的用户名在本端的用户表中查找该用户对应密码，并选用找到的密码。” 这句话。
下面两个图是被验证方R4中没有在端口视图下配置用户R4密码 而主验证方R3在系统视图下配置了用户R4的密码的情况：
R3：
R4：
解释：主验证方R3将本端的用户名发送给被验证方R4。而R4中没有配置R3的CHAP密码，则被验证方R4根据主验证方R3的用户名在本端的用户表中查找该用户R3对应密码为R3(此时是错误的情况)，并选用找到的密码。随后，被验证R4方利用MD5算法对报文ID，密码和随机数生成一个摘要，并将此摘要和自己的用户名发回给主验证方。由于双方密码不一致，验证失败 ，R3与R4不通。
下面将双方密码改为一致：
R1：
R2：
将双方密码改为一致后 终于通了。。说明这种没有配置默认的CHAP密码的CHAP验证方式双方密码必须一致。
而两端路由器都在系统模式下将对端用户名和密码添加到本地 并在端口模式下配置本机用户名密码的 CHAP 和PAP验证方式 双方密码不必一致。
