案例分析:MPLS网络里数据帧长度导致的问题

    网络拓扑如图，从结构上来看，这个网络采用了一个比较典型的接入模式。用户通过二层交换机或是三层交换机接入汇聚设备BH6808，再通过BH6808的MPLS功能接入到骨干INTERNET&MPLS网络里。各设备接口IP分配参看拓扑图，BH6808和骨干网络之间运行OSPF和MPLS协议，OSPF通告直连网段和指向172.0.0.0/24的静态路由；三层交换机采用静态路由方式。在调试结束后，在PC A和PC B都做了相关的测试，PING各个接口地址和DNS服务器地址都可达。

    二、问题描述

    在网络接入实际用户时，出现了问题，从现场反馈的信息里，可以了解到一个重要的信息：三层交换机接入的用户在打开部分网页时，不能正常开启，但DNS可以解析到，而二层交换机接入的用户则一切都比较正常。

    其中比较典型的一个网站就是上海盛大网络（www.shanda.com.cn）的主页在三层交换机接入的用户不能打开。

    三、问题分析及处理过程

    从网络结构和现象上分析，BH6808下接三层交换机或是二层交换机的结构变化，对于IP网络的影响应该基本上不会涉及到骨干网络，初步怀疑两种结构的两种结果应该就是和BH6808和接入交换机有关系，然后开始按照这个思路开始排查问题。

    在做进一步分析前，可以做一些简单的、有效果的工作来减小问题的排查范围。比如设备替换法，更换不同系列的三层交换机或是将该三层交换机改成二层交换机测试，更换不同系列设备可以确定故障和单台设备没有关系；将三层交换机改成二层交换机测试可以确定故障和该交换机的物理端口特性没有关系（担心物理端口对某些报文的影响），但更换三层设备无效，故障现象仍如前面描述的情况。将三层交换机切换成二层功能，交换机下的用户就可以访问所有网站，跟前面描述的情况一样。从而排除了接入设备的问题。

    进一步，在接入层设备上对打开上海盛大网络（www.shanda.com.cn）的主页进行抓包分析。对抓到的报文做对比分析，可以看到二层交换机接入用户的HTTP交互的完全过程，是从TCP连接到HTTP报文的传送，HTTP数据报文的长度为1518字节；而三层交换机接入用户的HTTP交互过程里，只存在TCP连接，没有HTTP报文的传送！现在问题的问题排查点出来了， 这些报文丢在哪儿呢，为什么丢呢？

    通过MIRROR各个设备的上行端口，逐级排查，最后确定在三层交换机接入的方式下，BH6808上行端口就没有收到CISCO设备发过来的HTTP报文，也就是说实际上是CISCO设备把HTTTP数据报文丢弃了，为什么呢？如前所说，对于IP网络来说，BH6808下接三层交换机或是二层交换机的结构变化，对于骨干的CISCO设备应该是没有影响的，但请注意两点：

    1、对于接入二、三层交换机，在BH6808上体现的就是目的网段是直连或是静态路由。比如，如果接入的是二层交换机，目的网段是192.168.2.0/24的为直连路由；而接入三层交换机，目的网段是172.0.0.0./24，则应该是静态路由。
    2、BH6808和CISCO设备之间运行了MPLS。

    这两点会导致出现什么情况了，在BH6808上SHOW 相关的信息：
    show mpls ldp bindings 172.0.0.0/24
    Prefix 172.0.0.0/24
      local binding: label: 2118
      remote binding:
          192.168.0.1:0.0  label: 208            status: Liberal

    show mpls ip binding ldp  172.0.0.0/24
    Prefix: 172.0.0.0/24
       Oper Type: php     In Label:2118      Out_if:netbar1

    show mpls forwarding-table 172.0.0.0/24
    Local    Outgoing        Prefix               Outgoing       Next Hop
    label    label           or  vc id            interface
    2118     3               172.0.0.0/24    netbar1        192.168.1.2

    通过这些信息，可以确定CISCO设备在发送目的IP为172.0.0.0/24的数据包时应该是携带了MPLS标签的，标签值为2118.

    show mpls ldp bindings 192.168.2.2/24
    Prefix 192.168.2.2/24
    local binding: label: implicit-null
      remote binding:
          192.168.0.1:0.0  label: 218            status: Liberal

    直连网段则为空标签，根据MPLS PHP（倒数第二跳弹出）的机制，可以确定CISCO设备在发送目的IP为192.168.2.2/24的数据包时应该是不携带MPLS标签的IP报文。而目的IP为172.0.0.0/24的数据包时是携带了MPLS标签的，恰恰是携带标签的这些数据包，在HTTP传输过程中没有传达到BIG6800上来。那么，简单想一想就可以得出这样的结论：没有加MPLS的报文CISCO设备能发出，而加了MPLS的报文CISCO设备没能发出来！ 这两种报文的区别在哪里呢（为何加了MPLS就发不出来呢）？

    到此，可以把问题怀疑到了数据报文的长度上来了，因为网页的HTTP报文长度本身已经到了以太网帧的最大长度1518，加上MPLS标签的4个字节，在三层交换机接入的情况下，在CISCO设备和BH6808之间的数据帧最长应该是1522字节；而二层交换机接入时，在CISCO设备和BH6808之间的数据帧最长只会是1518字节（不会有标签）。可以确定BH6808能够接受的以数据帧MTU长度是1544字节，但CISCO设备呢？在和CISCO设备的管理人员沟通后发现CISCO设备和BH6808对接的EH2/1端口实际上的以数据帧最长长度是1518字节，所以当需要发往172.0.0.0/24的数据帧长度达到1522字节后，CISCO设备EH2/1端口将会丢弃这些数据帧。

    在修改了CISCO设备EH2/1端口的数据帧MTU后，上网业务全部恢复正常，二层交换机和三层交换机的用户都可以正常开启海盛大网络（www.shanda.com.cn）的主页，问题解决!!

    四、总结

    这个网络问题还是比较“隐蔽”的，首先应该分析出网络结构不同对数据转发和数据格式的不同影响，同时下接三层交换机不能正常通信是因为CISCO设备EH2/1端口支持的数据帧长度不够，导致该端口丢弃MPLS报文。

    此外，还请注意端口支持的数据帧长度和接口MTU的区别，接口的MTU一般是指的IP数据的长度（在SHOW INTERFACE时可以查看），该长度值对一些协议有很重要的作用，比如OSPF在邻居建立时需要检查该长度值，所以不能随便修改，而端口可以接受的数据帧长度则是可以改变的，这个数据帧长度包括了802.1Q和MPLS标签的长度。

    对于MPLS交换机，目前的实现方式是非直连路由不分配空标签，不执行PHP。其原因在于目前的实现方式里不能确定非直连路由的下一跳是否也是MPLS交换机，也就是不能确定MPLS交换机自己不能确定自己是不是LSP里的倒数第二跳。

    请大家在看完这个案例后，在实际应用中，注意正确处理上述的情况！

    五、后记

    这个网络问题基本上和港湾设备没有关系，但从现象上来看问题点在港湾设备上，而其他厂商的设备我们又不能过多把握和控制，因此可以通过一些手段排除自己的问题，在排除的过程中，定位找出真正的故障点！