山西某金融客户SR6608路由器3G L2TP拨号不通的问题

山西某金融客户SR6608路由器3G L2TP拨号不通的问题

一     组网：

二     问题描述：

2013年01月19日,山西某金融客户反馈，SR6608做LNS，3G拨号L2TP无法拨通。

三     过程分析：

分别在SR6608和MSR侧打开如下debug信息开关，对搜集信息进行了分析(命令行以SR6608为例，MSR也相同)：

<SR6608>debugging ppp all

<SR6608>debugging l2tp all

<SR6608>debugging radius packet

SR66侧（LNS）

1、 两次拨号，L2TP隧道及会话都能够正常建立：

*May 17 20:27:15:574 2010 SX_3GCS_R1 L2TP/7/L2TDBG: L2TP_CONTROL: Tunnel 1 recv SCCRQ when in state 1  from 192.168.232.1

*May 17 20:27:15:609 2010 SX_3GCS_R1 L2TP/7/L2TDBG: L2TP_CONTROL: Tunnel 1 sent SCCRP to Tunnel 1609

*May 17 20:27:15:629 2010 SX_3GCS_R1 L2TP/7/L2TDBG: L2TP_CONTROL: Tunnel 1 recv SCCCN when in state 3

*May 17 20:27:15:835 2010 SX_3GCS_R1 L2TP/7/L2TDBG: L2TP_CONTROL: Call 21219 recv ICRQ in state 2 from Call 0

*May 17 20:27:15:849 2010 SX_3GCS_R1 L2TP/7/L2TDBG: L2TP_CONTROL: Call 21219 sent a ICRP message to Remote Call 1080

*May 17 20:27:15:869 2010 SX_3GCS_R1 L2TP/7/L2TDBG: L2TP_CONTROL: Call 21219 recv ICCN in state 5 from Remote Call 1080

2、 第一次拨号PPP LCP协商不过：

*Apr 13 17:43:06:528 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Event:

      Virtual-Template7:0 LCP Open  Event

      state initial

*Apr 13 17:43:06:528 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP State Change:

      Virtual-Template7:0 LCP : initial --> starting

*Apr 13 17:43:06:528 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Event:

      Virtual-Template7:0 LCP Lower Up  Event

      state starting

*Apr 13 17:43:06:529 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP State Change:

      Virtual-Template7:0 LCP : starting --> reqsent// 本端发起PPP LCP ConfReq

*Apr 13 17:43:06:529 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Output LCP(c021) Pkt, Len 29

      State reqsent, code ConfReq(01), id 0, len 25

      MRU(1), len 4, val 05dc 

      ACCMAP(2), len 6, val ffffffff 

      AuthProto(3), len 5, CHAP c22305 

      MagicNumber(5), len 6, val 3e5b8307 

*Apr 13 17:43:09:451 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Event:

      Virtual-Template7:0 LCP TO+(Timeout with counter > 0)  Event

      state reqsent , Retransmit = 4  // 超时没有得到回应，重发请求

*Apr 13 17:43:09:451 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Output LCP(c021) Pkt, Len 29

      State reqsent, code ConfReq(01), id 1, len 25

      MRU(1), len 4, val 05dc 

      ACCMAP(2), len 6, val ffffffff 

      AuthProto(3), len 5, CHAP c22305 

      MagicNumber(5), len 6, val 3e5ba2bc 

*Apr 13 17:43:09:455 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Input  LCP(c021) Pkt, Len 18

      State reqsent, code ConfReq(01), id 1, len 14

      MagicNumber(5), len 6, val 9d685f70 

      MRU(1), len 4, val 05dc 

*Apr 13 17:43:09:455 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Event:

      Virtual-Template7:0 LCP RCR+(Receive Config Good Request)  Event

      state reqsent

*Apr 13 17:43:09:456 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Output LCP(c021) Pkt, Len 18

      State reqsent, code ConfAck(02), id 1, len 14

      MagicNumber(5), len 6, val 9d685f70 

      MRU(1), len 4, val 05dc 

*Apr 13 17:43:09:468 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP State Change:

      Virtual-Template7:0 LCP : reqsent --> acksent // 收到对端请求，回应ACK

……//中间debug信息省略

*Apr 13 17:43:21:451 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Event:

      Virtual-Template7:0 LCP TO-(Timeout with counter expired)  Event

      state acksent  //重试超时，对端一直没有确认，PPP LCP协商失败

*Apr 13 17:43:21:451 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP State Change:

      Virtual-Template7:0 LCP : acksent --> stopped//PPP 协商关闭

3、 第二次拨号PPP LCP协商通过，PAP认证通过，IPCP协商通过，地址已分配；

*May 17 20:27:18:899 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP State Change:

      Virtual-Template7:0 LCP : acksent --> opened

*May 17 20:27:18:939 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP State Change:

      Virtual-Template7:0 PAP : WaitAAA --> ServerSuccess

*May 17 20:27:18:958 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Output IPCP(8021) Pkt, Len 14

      State reqsent, code ConfReq(01), id 0, len 10

      IP Address(3), len 6, val ac101401 //172.16.20.1 VT口地址）

*May 17 20:27:18:998 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Input  IPCP(8021) Pkt, Len 14

      State reqsent, code ConfReq(01), id 1, len 10

      IP Address(3), len 6, val 00000000  //对端IP地址请求选项

*May 17 20:27:19:18 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Input IPCP(8021) Pkt, Len 14

      State reqsent, code ConfAck(02), id 0, len 10

      IP Address(3), len 6, val ac101401  //收到ACK，但是MSR上并没有发送该ACK

*May 17 20:27:19:19 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Output IPCP(8021) Pkt, Len 14

      State ackrcvd, code ConfNak(03), id 1, len 10

      IP Address(3), len 6, val ac101405  //为Client分配地址172.16.20.5，但是MSR上并没有收到

*May 17 20:27:19:39 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Input IPCP(8021) Pkt, Len 14

      State ackrcvd, code ConfReq(01), id 2, len 10

      IP Address(3), len 6, val ac101405  //使用分配的地址重新请求，这也不是MSR发送的

*May 17 20:27:19:39 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP Packet:

      Virtual-Template7:0 Output IPCP(8021) Pkt, Len 14

      State ackrcvd, code ConfAck(02), id 2, len 10

      IP Address(3), len 6, val ac101405  //确认请求，MSR也没有收到确认报文

*May 17 20:27:19:58 2010 SX_3GCS_R1 PPP/7/debug2:Slot=2;

  PPP State Change:

      Virtual-Template7:0 IPCP : ackrcvd --> opened  //PPP 协商成功

4、 PPP IPCP协商成功之后，L2TP拆链

*May 17 20:27:19:78 2010 SX_3GCS_R1 L2TP/7/L2TDBG: L2TP_CONTROL: Call 21219 recv CDN in state 9 from remote Call //立刻收到了对方发送的CDN报文，进行了拆链处理

MSR侧（3G VPN Client）,两次测试调试信息一致:

1、 PPP LCP协商通过，PAP认证通过

*May 17 21:07:18:867 2010 140817601 PPP/7/debug2:

  PPP State Change:

      Cellular0/0 LCP : ackrcvd --> opened

*May 17 21:07:21:276 2010 140817601 PPP/7/debug2:

  PPP State Change:

      Cellular0/0 PAP : SendRequest --> ClientSuccess

2、 PPP IPCP协商失败

*May 17 21:07:22:229 2010 140817601 PPP/7/debug2:

  PPP Packet:

      Cellular0/0 Output IPCP(8021) Pkt, Len 14

      State reqsent, code ConfReq(01), id 0, len 10

      IP Address(3), len 6, val 00000000 

*May 17 21:07:22:380 2010 140817601 PPP/7/debug2:

  PPP Packet:

      Cellular0/0 Input  IPCP(8021) Pkt, Len 32

      State reqsent, code ConfNak(03), id 0, len 28

      Primary DNS Server Address(81), len 6, val 0a0b0c0d 

      Secondary DNS Server Address(83), len 6, val 0a0b0c0e 

      Primary NBNS Server Address(82), len 6, val 0a0b0c0d 

      Secondary NBNS Server Address(84), len 6, val 0a0b0c0e 

//回应的Nak中并没有分配IP地址，重新请求

*May 17 21:07:22:631 2010 140817601 PPP/7/debug2:

  PPP Packet:

      Cellular0/0 Output IPCP(8021) Pkt, Len 14

      State reqsent, code ConfReq(01), id 1, len 10

      IP Address(3), len 6, val 00000000 

*May 17 21:07:22:782 2010 140817601 PPP/7/debug2:

  PPP Packet:

      Cellular0/0 Input  IPCP(8021) Pkt, Len 32

      State reqsent, code ConfNak(03), id 1, len 28

      Primary DNS Server Address(81), len 6, val 0a0b0c0d 

      Secondary DNS Server Address(83), len 6, val 0a0b0c0e 

      Primary NBNS Server Address(82), len 6, val 0a0b0c0d  

      Secondary NBNS Server Address(84), len 6, val 0a0b0c0e

//仍然没有分配IP地址，此后也一直协商不成功，最终失败。而NAK并非LNS回应的，同时Client也没有收到任何LNS的IPCP报文，从LNS上看，是发出ConfReq和ConfAck的，且IPCP协商成功。

LCP重协商，IPCP协商，对于LAC设备是透明的，而对比Client/LNS的调试信息，协商并非直接在Client-LNS之间进行的，后面和运营上确认中间是存在LAC设备的。需要确认运营商LAC设备的配置或实现机制，确认造成该现象的原因。

第一次拨号LNS发送的LCP ConfReq一直没有得到回应，最终定位是运营商LAC设备版本问题，升级版本之后LCP能够协商通过；

第二次拨号经过确认问题是因为运营商LAC设备配置问题。LAC上多配置了地址池，客户端认证通过后，LAC设备和SR6608同时给客户端分配地址，导致IPCP地址协商阶段错误，LAC删除地址池后解决问题。

补充知识：

1、什么时候需要配置强制LCP重协商？

客户端与LAC之间协商参数不能被LNS侧接受时，如一些协商选项LNS不支持，必须配置LCP重协商；

2、什么时候需要取消强制LCP重协商？

部分PPP客户端不支持进行第二次验证，此时必须去掉；

3、PPP LCP协商部分选项协商失败，是否有影响？

只要最终LCP能够协商通过，过程中选项协商失败没有影响；

4、PPP 不同NCP协商失败，是否有影响？

不同NCP协商是相互独立，只要有一个NCP（如IPCP）能够协商成功即可。

5、LNS什么时候会发送SLI报文？

SLI报文是LNS用于通知LAC，LNS与Client的ACCM选项协商结果。当协商结果与默认不一致时，就会发送。实际应用中，各设备制造商的LAC对ACCM要求可能不同，LNS需要根据LAC的要求配置是否发送ACCM消息。缺省情况下，LNS发送ACCM消息。如果LAC不希望收到ACCM消息，则需要设置LNS端不发送ACCM消息。

四     解决方法：

运营商LAC设备版本问题，升级版本之后LCP能够协商通过；

运营商LAC设备配置问题，修改配置解决。