爱立信GGSN与Maipu路由器建L2TP失败故障的处理

蓉城喜鹊

最近和同事一起成功处理了一个GGSN充当LAC，与对端大客户LNS之间L2TP隧道无法建立的故障。现将相关处理过程share出来，与大家分享，同时也感谢GPRSHOME网站给我提供了不少的学习资料。

现网GGSN的配置为：

admin@GGSN-RE0> show configuration services ggsn apn gzdyj.yn
access-restrictions {
    selection-mode public;
}
routing-instance vrf_gzdyj;
pdp-context {
    address {
        0.0.0.0/0;
    }
    address-allocation l2tp;
}
l2tp {
    l2tp-routing-instance Gi;
    lac-address-range 172.16.1.1/32;
    lns {
        server 172.17.2.1 use-default-port;
    }
    message-attributes {
        calling-number;
    }
    hello-interval 30;
    receive-window 16;
    max-retry 4;
    max-retry-timeout 60;
    overlapping-addresses;
    no-spoofing-protection;
    ppp {
        authentication {
            protocol chap;
        }
        retry-timeout 2;
        max-retry 5;
        mru 1500;
    }
}

而对端大客户侧LNS设备为迈普公司的路由器，相关配置为：

user test@gzdyj.yn password 0 test

interface loopback100
ip address 172.17.2.1 255.255.255.255
exit


interface virtual-template1
encapsulation ppp
peer default ip address 1.1.1.1
ppp authentication chap
ppp mtu adaptive proxy
ip unnumber loopback100
exit

vpdn enable

vpdn-group 1
accept-dialin
  protocol l2tp
  virtual-template 1
  exit
no l2tp tunnel authentication
lcp renegotiation on-mismatch
exit

以完成以上配置后，客户反映L2TP无法拔通，经过抓包分析发现，LAC与LNS之间的Tunel已经建立完成，但在对拔号用户完成session建立，并进行LCP协商时，对端LNS就会发出CDN消息来中止session，同时发送StopCCN来中止隧道，整个L2TP拔号失败。

在这里，我们先来了解一下L2TP 的基本工作原理：

首先LAC和LNS之间会进行Tunnel的建立，这个Tunel是LAC与LNS之间的一个通道，是用来为许多用户服务的。当Tunel建立后，LAC会再次为每一个用户单独来建session。也就是说，一个Tunnel可以包括多个session（也就是一个tunnel可以包括多个用户的流量）。在建立tunnel时LAC和LNS都可以对隧道本身进行验证，而在随后建session时LAC和LNS又都可以对每个具体的用户来进行验证。如果第一个用户的在建session时已经完成了Tunnel的建立，而那么以后的用户不需要再来建Tunnel了，直接建session即可。

L2TP隧道的建立是一个三次握手的过程，首先由LAC发起隧道建立请求SCCRQ，LNS收到请求后进行应答SCCRP，最后LAC在收到应答后再给LNS返回确认SCCCN；隧道建立。
会话建立的过程与隧道类似，首先由LAC发起会话建立请求ICRQ，LNS收到请求后返回应答ICRP，LAC收到应答后返回确认ICCN，会话建立！

再次重复：L2TP的会话建立由PPP触发，隧道建立由会话触发。由于多个会话可以复用在一条隧道上，如果会话建立前隧道已经建立，则隧道不用重新建立。



在完成session后，LAC首先与LNS进行LCP协商，其次将使用PDP激活时用户PCO选项中的用户名与密码发送给LNS进行验证(这一部是可选的)，最后协商IPCP。

而在本次故障中，通过抓包分析，GGSN按正常的流程在执行L2TP的建立，而友商的路由器却无缘无故的中止会话：

相关的示意图为：


上图为l2tp的抓包


上图为LNS发出的CDN消息


上图为LNS发现的StopCCN消息

经过排查，最后发现L2TP不会建立的根本原因不在于配置问题，而在于maipu路由器对GGSN发出的LCP协商报文进行处理是周期时间过长，超过了GGSN默认的300ms，于是GGSN再次重发LCP协商，最终引起了maipu路由器单方中止L2TP会话。

因此爱立信GGSN在与maipu路由器建L2TP时，建议修改LCP协商超时值，由默认的300ms修改为30000ms就可以了。

所以需要在上述GGSN的APN配置中添加：

set  services ggsn apn gzdyj.yn l2tp ppp proxy-lcp-timeout 30000

---------------------------------------------------------------------------
由于涉及到隐私，IP地址与抓包文件不能共享哈！请谅解哈！

爱卫生

非常感谢分享。呵呵！以后多交流哈！

hycl5410

好东西~~学习学习~~

why_zero

好东西，值得分享

ccc123

分析的很好，要是ggsn上的配置能讲解一下就更好了，谢谢。。。。。