MPLS标签引发网络故障
2015-12-03
笔者所在单位有多个分支机构,各分支机构通过租用运营商的线路连接至笔者所在单位的城域网路由器,再通过地址转换设备使用统一的互联网出口访问互联网。单位对外发布业务的服务器部署于DMZ区,通过边缘层的防火墙发布至外网。各分支机构通过互联网访问发布的业务。图1是内部网络拓扑图。
图1 网络拓扑结构
故障现象
单位发布了一套视频学习系统供业务培训使用,系统部署于DMZ区,通过防火墙向互联网发布,分支机构通过公网访问该系统。系统上线后,部分分支反映用户在客户端播放视频时出现卡顿的现象,但是从客户端能正常Ping通系统的公网地址202.x.x.36。位于笔者单位内部的用户能正常访问该系统。
图2 抓包信息
排障思路
根据故障现象及和分支维护人员的沟通,笔者分析故障的可能原因如下。
1.服务器性能不足。
2.网络、安全设备性能不足。
3.到各分支链路带宽不足。
4.运营商城域网线路问题。
排障过程
1.监测服务器。在服务器上对CPU、内存、存储、网络进行检测,服务器使用率比较低,系统运行正常。
2.监测网络、安全设备。对服务器接入网络、核心交换机、防火墙的CPU、内存、包转发进行检测,也在合理的范围内。防火墙的安全策略也没有问题,上网行为审计设备没有限制带宽。鉴于笔者所在单位内部的用户能正常通过公网访问视频,可基本排除中心服务器端出现故障的可能。
3.监测各分支链路带宽。登录到分支路由器,分支路由器上的CPU、内存使用率也很低,端口无明显错误报文,端口数据流量不高,线路也比较稳定。
4.经监测以上几个方面从表面看都没有问题,没有办法,笔者到其中一个分支,观察故障现象。在该分支上 Ping系统的公网地址没有问题,但是看视频时确实卡顿,只能通过抓包的方式分析故障原因。
故障解决
分别在故障分支客户端上抓包,发现有大量的要求重传的报文和丢失的报文(如图2)。
与在中心端客户端所抓的包文做比较,在中心端的抓包没有此现象。
通过对比两者的抓包结果和两者的网络区别,突然想到,分支到中心端的线路是专线线路,会不会是运行商的MPLS线路呢,这样的话,数据包就会在运营商的网络设备上打上MPLS标签,数据包很有可能超过网络设备的MTU值,就会造成数据包分片,甚至部分分片的数据包丢失。马上联系运营商确认,结果确实如此。
马上查阅相关资料,使用两种方式解决此问题。
一是在客户端通过Ping -l 加上字节数到服务器确认两者的MTU,然后在Windows 操作系统下通过netsh interface ipv4 set subinterface "本地连接"mtu=1480 store=persistent命令修改了客户端的MTU值,重启电脑再查看服务器视频,视频能够流畅播放了。
二是在分支机构的接入路由器接口上通过“tcp mss 884”命令将MSS值改为884字节,所有的电脑都能正常播放视频了。
故障分析
由于中心到分支使用了嵌套的MPLS网络,在IP包前封装了MPLS标签,导致MTU的增大超过了1500字节,进而使报文被分片处理,导致了访问服务器效率降低。同时,被分片的的字节过小的话,会被安全设备当做攻击报文而丢弃。修改MTU值或MSS值后,报文不会被分包处理,提高了访问效率。