赫斯曼交换机环网失效现象的分析与研究

刘其勇

（南京地铁运营有限责任公司，江苏 南京 210012）

0 引 言

在赫斯曼交换机运行过程中，正常业务的单播数据会出现被广播的现象，导致车地无线传输网络速度大幅下降，下发大小约2 GB的单个乘客信息系统（Passenger Information System，PIS）视频文件需要20～30 h，使得车载PIS视频文件下发功能并不具备真正意义上的可使用性[1-3]。针对这一问题展开分析与研究，从而完善与优化车地无线传输网络。

1 研究背景

南京地铁S1号线自2014年7月1日建成通车以来，PIS系统一直采取禄口基地线下通过U盘直接拷贝视频文件的方式下发车载PIS视频文件。原始设计的PIS系统通过车地无线传输网络下发视频文件的功能始终无法正常使用，问题主要体现在控制中心PIS视频服务器的视频流通过有线网络和无线网络后传输至车载PIS服务器，下发单个PIS视频文件所需要的时间较长[4]。

南京地铁S1号线PIS系统由赫斯曼MACH1000骨干网交换机组成一个骨干网，赫斯曼RS20交换机组成AP交换机环网，设置在控制中心的PIS视频服务器控制数据报文通过有线网络和无线网络到达车载PIS服务器，完成轨旁对列车点对点的单播功能，如图1所示[5]。

图1 PIS系统网络

2 问题回顾

首先，对禄口基地运用库内的任意一个AP交换机进行抓包。将赫斯曼RS20交换机的业务端口（连接AP端口）的VLAN设置由VLAN100 Trunk模式改为VLAN100 access模式，以便抓取业务报文。S1号线共配置15列电客车，禄口基地运用库内有3列车，其中2车升弓上电、9车和13车降弓下电（车载PIS系统不工作）。此外，其余12列车在正线上电运行。在用Wireshark抓包软件进行分析时发现，在138 s内镜像端口共捕获数据包429 795个，包含了全部13列已上电列车的数据包，除去两列车降弓下电外，所有升弓上电列车收/发的数据包均能被捕获到。抓取的数据包如图2所示。控制中心PIS服务器（源地址为192.10.61.17）发送数据至其他所有列车，目的地址为192.168.X.4（X车车头）/192.168.X.5（X车车尾），其中IP地址的第3字节X表示列车编号。

图2 AP交换机抓包数据

通过以上抓包数据，可知任意一个AP交换机端口的带宽被占用了20～40 Mb/s，且大多数流量为其他列车通信数据。对于目标列车来说，带宽几乎被其他列车流量完全占用。业务端口数据流量如图3所示。

图3 业务端口数据流量

发送至AP交换机的数据包中充满了大量被广播的单播数据包，即本应被交换机以单播形式转发的数据包现在被以广播的形式发送到了每一个终端处。与正常的单独送信相比，整个网络的传输负荷是呈指数性上升的。图3是镜像端口138 s时间内捕获的数据包I/O（输入输出）图，共捕获数据包429 795个，平均带宽33 Mb/s，峰值带宽46 Mb/s。根据实际测量，发送至AP交换机的数据速率高达30～40 Mb/s，而中心下发至车辆的实时视频信息和控制信息所使用的带宽设计值为6 Mb/s，故至少有4/5的数据包因AP交换机无法送出而被丢弃。

其次，对控制中心的骨干网交换机进行抓包分析。由于同样可以抓取到服务器与所有列车交互的用户数据报协议（User Datagram Protocol，UDP）业务数据，因此验证了本应单播的业务数据包确实被赫思曼交换机广播转发。骨干网交换机抓包数据如图4所示。

图4 骨干网交换机抓包数据

最后，对PIS系统网络中位于赫斯曼骨干网交换机上游的华为3层交换机展开抓包分析。由于未抓到上述UDP业务数据包，因此证明单播数据包被广播转发并非上游华为交换机所为。

结合上述分析结果，可以确定PIS系统车地通信不佳的原因是正常业务单播数据包被赫斯曼交换机广播占用业务带宽，进而导致环网失效。基于此，对这一现象展开研究与分析。

3 原因分析

首先查看控制中心骨干网交换机的MAC地址表项，以验证交换机是否能正确学习到相关MAC地址表[6,7]。通过观察MAC表，发现全线赫斯曼交换机的MAC地址表一直反复处于不断清空再学习的状态，因此初步判断为交换机存在MAC地址表被清空的时间段，在此时间段内赫斯曼交换机会对业务报文做出广播处理。其次进一步检查全线赫斯曼交换机日志，发现翠屏山站赫斯曼交换机存在异常，此交换机的1.7端口开启SubRing的Redundant Manager功能，从日志来看此端口状态一直不断变化，基本上每秒都会产生收敛日志，导致交换机向全网广播FLUSH FDB刷新消息，进而导致全网交换机不断清空MAC地址表。检查翠屏山赫斯曼交换机1.7端口下所接的子环交换机配置，发现收集的交换机配置没有AP0723-SW，而是DP11的配置，而DP11没有相关子环的正确配置。基于此，怀疑此交换机配置错误。最后检查车载直播软件工作状态，发现列车自动监控系统（Automatic Train Control，ATS）服务器上的车载直播软件一直给多列车发送直播业务数据，包括一部分未在线列车[8]。由于赫斯曼交换机MAC地址表中没有未在线列车的MAC地址，因此服务器发送至未在线列车的数据包被全网广播转发，占用业务带宽。

通过以上排查信息得知，赫斯曼交换机环网失效的原因主要有以下两点。一是网络中存在交换机环网协议配置错误，导致向全网广播FLUSH FDB刷新消息，全网交换机不断地去清空MAC地址表，环网处于失效状态。二是车载直播软件机制问题导致去往未在线列车的业务数据包被全网广播转发，由于未在线列车的MAC地址在赫斯曼交换机上不存在，因此控制中心PIS视频服务器发往列车的流量被网络广播转发，所有列车都收到其他列车的无效数据包，造成业务带宽被严重挤压，从而影响视频业务的正常传输。

4 整改措施

断开赫斯曼AP0723（172.26.129.187）交换机的端口1.1，保证子环处于单链路状态。关闭交换机拨码开关，登录赫思曼AP0723（172.26.129.187）交换机Web配置界面，删除现有环网协议Hiper-Ring配置。选择介质冗余协议（Media Redundancy Protocol，MRP），选择环网端口1.1和1.2，开启功能并配置环网Vlan15。配置完成后开启1.1端口，从网管上检查交换机连接状态，检查环网冗余状态是否运行正常，最后保存全局配置。除此之外，在远程下发视频文件或其他较大数据需要无线传输时，通过暂时关闭车载直播软件的方式大幅提高有效业务带宽[9,10]。

整改完毕后，测试车地远程传输视频文件功能，有效业务带宽达到3.5 Mb/s左右，实现了显著提升。

5 结 语

本课题研究成果已经帮助S1号线技术人员成功解决正常业务单播数据被交换机广播转发时车地网络无法正常通信的问题，目前工作人员只需在控制中心远程操作便可以将视频文件下发至在线列车，无需等待线路停运后登上每一辆列车进行视频文件的本地上传工作，大大提高了工作效率，减轻了工作负担。