isdn的map中的name参数的作用
isdn的map中的name参数有什么用？我觉得应该和认证有关，可是当我开启认证时，无论是否有这个参数，都可以通。所以就 搞不懂这个参数的作用了。
1、两边同时开启chap，然后把name设置为和对端主机名不一样。
2、两边不启用认证，name设置为和对端主机名不一样。
3、两边不启用认证，均不设置name。
4、两边开启chap，一边设置name,一边不设置。
5、两边开启chap,两边均不设置name
按照以上做一个调试
作了一些调试，结果如下
1。 可以通
2 可以通
3 可以通
4 可以通
5 可以通
感觉很奇怪，是不是我什么地方的配置作错了？但是我就是按照要求调试的？
还有就是我发现CHAP认证只在一边应用也可以通（前提是两端在全局模式下配置的USERNAME和PASSWORD一定要正确 ），很奇怪？
6、两边启用chap，设置name和对端主机的username不一致
7、两边启用chap，一边设置name和对端主机的username不一致，另一边一致。
单边认证的问题，这么调试：注意username和hostname一样
8、一边有username password，同时ppp auth chap;一边没username password，也没有ppp authen chap
9、一边有username password，没有ppp auth chap，另一边相反。
debug ppp negotiation
6。。。可以通
7。。。可以通
8。。。不行
调试信息：R3 PING R5 （V11）
01:10:05: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
01:10:05: BR0:1 PPP: Treating connection as a callout
01:10:05: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
01:10:05: BR0:1 LCP: O CONFREQ [Closed] id 92 len 15
01:10:05: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
01:10:05: BR0:1 LCP: MagicNumber 0xE05E6C89 (0x0506E05E6C89)
01:10:05: BR0:1 LCP: I CONFREQ [REQsent] id 96 len 10
//////////////////////这里少AuthProto CHAP着句话 （因为R5没有开启CHAP）
01:10:05: BR0:1 LCP: MagicNumber 0x004D0547 (0x0506004D0547)
01:10:05: BR0:1 LCP: O CONFACK [REQsent] id 96 len 10
//////////////////////这里少AuthProto CHAP着句话
01:10:05: BR0:1 LCP: MagicNumber 0x004D0547 (0x0506004D0547)
01:10:05: BR0:1 LCP: I CONFACK [ACKsent] id 92 len 15
01:10:05: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
01:10:05: BR0:1 LCP: MagicNumber 0xE05E6C89 (0x0506E05E6C89)
01:10:05: BR0:1 LCP: State is Open
01:10:05: BR0:1 PPP: Phase is AUTHENTICATING, by this end [0 sess, 0 load]
01:10:05: BR0:1 CHAP: O CHALLENGE id 67 len 29 from "Rack01R3"//////////////仅仅有发出，没有收到任何回复
01:10:05: BR0:1 LCP: I TERMREQ [Open] id 97 len 4
01:10:05: BR0:1 LCP: O TERMACK [Open] id 97 len 4
01:10:05: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
01:10:05: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
01:10:05: BR0:1 LCP: State is Closed
01:10:05: BR0:1 PPP: Phase is DOWN [0 sess, 0 load]
9。。。不行
调试信息：R3 PING R5 （V11）
01:17:30: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
01:17:30: BR0:1 PPP: Treating connection as a callout
01:17:30: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
01:17:30: BR0:1 PPP: No remote authentication for call-out
01:17:30: BR0:1 LCP: O CONFREQ [Closed] id 101 len 10
01:17:30: BR0:1 LCP: MagicNumber 0xE06535B2 (0x0506E06535B2)//////////////缺少 AuthProto CHAP
01:17:30: BR0:1 LCP: I CONFREQ [REQsent] id 102 len 15
01:17:30: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
01:17:30: BR0:1 LCP: MagicNumber 0x0053CE66 (0x05060053CE66)
01:17:30: BR0:1 LCP: O CONFACK [REQsent] id 102 len 15
01:17:30: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
01:17:30: BR0:1 LCP: MagicNumber 0x0053CE66 (0x05060053CE66)
01:17:30: BR0:1 LCP: I CONFACK [ACKsent] id 101 len 10
01:17:30: BR0:1 LCP: MagicNumber 0xE06535B2 (0x0506E06535B2)
01:17:30: BR0:1 LCP: State is Open
01:17:30: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]
01:17:30: BR0:1 CHAP: I CHALLENGE id 67 len 30 from "Rack01R5"
01:17:30: BR0:1 CHAP: Username Rack01R5 not found //////////////没有配置USERNAMEH和PASSWORD
01:17:30: BR0:1 CHAP: Unable to authenticate for peer
01:17:30: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
01:17:30: BR0:1 LCP: O TERMREQ [Open] id 102 len 4
01:17:30: BR0:1 LCP: I TERMACK [TERMsent] id 102 len 4
01:17:30: BR0:1 LCP: State is Closed
01:17:30: BR0:1 PPP: Phase is DOWN [0 sess, 0 load]
那么是否DIALER MAP 中的NAME真的和认证没有关系?
结论：从调试信息可以看出CHAP认证分成4个阶段。
1。Phase is ESTABLISHING（两台设备会检查是否都有开启CHAP）（无论两端是否都是CHAP，这个状态的接受都是State is Open。但是：一端CHAP，一端PAP，会出现State is Closed）
2。Phase is AUTHENTICATING（开始检查是否有正确的USERNAME和PASSWORD）
3。Phase is TERMINATING
4。Phase is DOWN还有一个新问题。
就是一端是CHAP，一端是PAP。
肯定回不通，但是为什么用DEBUG PPP NGE回看到两台设备会不停的互法希望建立认证的请求？
是不是着两个认证都有一个和对方建立请求的最大次数在控制？
1、chap：Router《---》Router默认都是双向挑战
2、如果一边没有ppp auth chap，即为单边挑战。
3、即使单边挑战，因不在线上传递Password，但是hash时要用到，因此一定是两边均有username password. hash出错的提示：“MD/DES compare failed" ”
4、PAP和chap是完全无法兼容的，具体请求的次数，可debug查看，30分钟，如果一直在请求，那么是无限的。
5、重新调试一次“1-7”的内容，每次把dial map name均设置为任意，不和hostname和username 一致。
我知道那个NAME参数有什么用了。（但是还有问题）
这个参数的一个作用应该是在这里：在callback中。callback-server 的参数username要和dialer map 中的name一样才行。
调试信息：当两者不一样
Rack01R3#
03:43:48: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:43:48: BR0:1 PPP: Using dialer call direction
03:43:48: BR0:1 PPP: Treating connection as a callout
03:43:48: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
03:43:48: BR0:1 LCP: O CONFREQ [Closed] id 69 len 18
03:43:48: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
03:43:48: BR0:1 LCP: MagicNumber 0x00D941F4 (0x050600D941F4)
03:43:48: BR0:1 LCP: Callback 0 (0x0D0300)
03:43:48: BR0:1 LCP: I CONFREQ [REQsent] id 68 len 15
03:43:48: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
03:43:48: BR0:1 LCP: MagicNumber 0xE0EC8E8E (0x0506E0EC8E8E)
03:43:48: BR0:1 LCP: O CONFACK [REQsent] id 68 len 15
03:43:48: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
03:43:48: BR0:1 LCP: MagicNumber 0xE0EC8E8E (0x0506E0EC8E8E)
03:43:48: BR0:1 LCP: I CONFACK [ACKsent] id 69 len 18
03:43:48: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
03:43:48: BR0:1 LCP: MagicNumber 0x00D941F4 (0x050600D941F4)
03:43:
48: BR0:1 LCP: Callback 0 (0x0D0300)
03:43:48: BR0:1 LCP: State is Open
03:43:48: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load]
03:43:48: BR0:1 CHAP: O CHALLENGE id 107 len 29 from "Rack01R3"
03:43:48: BR0:1 CHAP: I CHALLENGE id 115 len 29 from "Rack01R5"
03:43:48: BR0:1 CHAP: O RESPONSE id 115 len 29 from "Rack01R3"
03:43:48: BR0:1 CHAP: I SUCCESS id 115 len 4
03:43:48: BR0:1 CHAP: I RESPONSE id 107 len 29 from "Rack01R5"
03:43:48: BR0:1 CHAP: O SUCCESS id 107 len 4
03:43:48: BR0:1 IPCP: PPP phase is AUTHENTICATING, discarding packet ///////这时候会丢包。应该是名称没有通过验证造成的。但是，上面几行debug信息显示chap认证已经完成了，那为什 么还会出现这种现象呢？
03:43:48: BR0:1 CDPCP: PPP phase is AUTHENTICATING, discarding packet
03:43:49: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
03:43:49: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 810555 Rack01R5
03:43:49: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 810555 Rack01R5, call lasted 1 seconds
03:43:49: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
03:43:49: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
03:43:49: BR0:1 LCP: State is Closed
03:43:49: BR0:1 PPP: Phase is DOWN [0 sess, 0 load]
03:43:50: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to downRack01R3#
Rack01R3#另：当两者一样时的debug信息
03:47:54: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:47:54: BR0:1 PPP: Treating connection as a callout
03:47:54: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
03:47:54: BR0:1 LCP: O CONFREQ [Closed] id 72 len 15
03:47:54: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
03:47:54: BR0:1 LCP: MagicNumber 0xE0EEE86F (0x0506E0EEE86F)
03:47:54: BR0:1 LCP: I CONFREQ [REQsent] id 73 len 15
03:47:54: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
03:47:54: BR0:1 LCP: MagicNumber 0x00DB9BEA (0x050600DB9BEA)
03:47:54: BR0:1 LCP: O CONFACK [REQsent] id 73 len 15
03:47:54: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
03:47:54: BR0:1 LCP: MagicNumber 0x00DB9BEA (0x050600DB9BEA)
03:47:54: BR0:1 LCP: I CONFACK [ACKsent] id 72 len 15
03:47:54: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
03:47:54: BR0:1 LCP: MagicNumber 0xE0EEE86F (0x0506E0EEE86F)
03:47:54: BR0:1 LCP: State is Open
03:47:54: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load]
03:47:54: BR0:1 CHAP: O CHALLENGE id 119 len 29 from "Rack01R5"
03:47:54: BR0:1 CHAP: I CHALLENGE id 111 len 29 from "Rack01R3"
03:47:54: BR0:1 CHAP: O RESPONSE id 111 len 29 from "Rack01R5"
03:47:54: BR0:1 CHAP: I SUCCESS id 111 len 4
03:47:54: BR0:1 CHAP: I RESPONSE id 119 len 29 from "Rack01R3"
03:47:54: BR0:1 CHAP: O SUCCESS id 119 len 4
03:47:54: BR0:1 PPP: Phase is UP [0 sess, 0 load]
03:47:54: BR0:1 IPCP: O CONFREQ [Closed] id 59 len 10 /////////////////////这里就很正常了
03:47:54: BR0:1 IPCP: Address 133.1.35.5 (0x030685012305)
03:47:54: BR0:1 CDPCP: O CONFREQ [Closed] id 59 len 4
03:47:54: BR0:1 IPCP: I CONFREQ [REQsent] id 34 len 10
03:47:54: BR0:1 IPCP: Address 133.1.35.3 (0x030685012303)
03:47:54: BR0:1 IPCP: O CONFACK [REQsent] id 34 len 10
03:47:54: BR0:1 IPCP: Address 133.1.35.3 (0x030685012303)
03:47:54: BR0:1 CDPCP: I CONFREQ [REQsent] id 34 len 4
03:47:54: BR0:1 CDPCP: O CONFACK [REQsent] id 34 len 4
03:47:54: BR0:1 IPCP: I CONFACK [ACKsent] id 59 len 10
03:47:54: BR0:1 IPCP: Address 133.1.35.5 (0x030685012305)
03:47:54: BR0:1 IPCP: State is Open
03:47:54: BR0:1 CDPCP: I CONFACK [ACKsent] id 59 len 4
03:47:54: BR0:1 CDPCP: State is Open这个name原来我们做测试时和chap/pap有直接关系的。
callback对对端的name验证，在chap之后，即chap通过，但是callback不接受也是有可能。
在isdn链路封装hdlc时name后面的名字对链路没有任何影响，因为hdlc没有类似于ppp的二层，所以不关心此参数 另外按照各位老大的提示做了实验。在单边不加电话号码的时候。NAME配置错误。是无发PING通的。但是除了R3和R5。其他 所有的路由器都能PING通这两个BRI口。而且我加入EIGRP后R3和R5都可以建立邻居。但是不能传播路由。但在OSPF 下就没办法形成邻居。但是为什么加了电话号码后就可以不管NAME参数了呢？而且有 一边不加DIALER MAP也可以PING通。？？？而且DIALER MAP了自己的IP后，可以PING通自己。这是为什么？电话可以自己拨自己的吗？
