灵犀一指

一、 组网：

客户组网拓扑示意图如上，采用两台S7500E作为核心网关设备，两台S7500E之间采用聚合链路互联。S7500E下联第三方防火墙，两台防火墙之间做热备，FW-M标示此防火墙为主，FW-S标示此防火墙为备，主备防火墙分别连接至两台S7500E设备，正常情况下，主防火墙上联到核心的端口转发数据，备用防火墙的上联端口处于阻塞状态不转发数据。两台防火墙之间采用心跳来进行检测，当主用防火墙故障时，备用防火墙上联端口将快速切换到转发状态以保证数据的正常转发。接入层采用我司的S3600和S5800交换机，都做纯二层转发，S3600下挂PC不经过防火墙，数据直接由核心转发出去，S5800下挂PC需要经过防火墙过滤之后才能转发数据。S5800分别双上行连接至主备防火墙。整网启用MSTP，都处于实例0，S7500E-1作为MSTP主根，S7500E-2作为MSTP备根。

二、 问题描述：

客户反馈近期网络多次发生中断情况，具体现象是部分业务有中断情况，且业务中断面慢慢扩散，最后整网内业务呈现时通时断的现象，此时从S7500E 无法telnet到S5800 设备。每次故障出现后，客户都是通过重启两台S7500E设备之后业务逐步恢复正常。

三、 过程分析：

针对客户反馈每次出现网络故障都是重启S7500E之后恢复的，我们首先把排查重点放在核心的两台S7500E上，对其诊断信息进行了细致的分析，并没有发现设备存在软硬件的异常情况。但设备的诊断信息里记录的一些MAC迁移的表项引起了我们的关注，MAC迁移表项即同一个MAC地址在短时间内学习到不同的端口，这往往是存在链路中断导致数据转发路径改变或者网络里产生环路的标志。下面是我们从核心设备S7500E的诊断信息中发现的MAC迁移的记录。

===================L2MAC MOVE Record INFO===========

MacAddress Vlan Agg Mod Port ->Agg Mod Port Cnt LatestTime Del

0 :16:41:2d:bd:ba 1000 0 4 3 ->1 0 0 3325 2011/8 /2 16:11:46 1

0 :23:89:af:7f:eb 248 0 4 2 ->1 0 0 3330 2011/8 /2 16:11:46 1

0 :23:89:af:84:c2 248 0 4 5 ->1 0 0 4 2011/8 /2 16:11:49 1

0 :23:89:af:83:f0 248 0 4 2 ->0 10 1 1 2011/8 /2 16:11:47 1

0 :50:56:95:26:75 1 0 10 1 ->1 0 0 6 2011/8 /2 16:11:49 1

0 :23:89:af:83:99 248 0 4 5 ->1 0 0 13 2011/8 /2 16:11:51 1

0 :50:56:95:d :19 1 1 0 0 ->0 10 1 12 2011/8 /2 16:11:49 1

0 :e0:fc:3d:7f:5d 248 1 0 0 ->0 10 1 3 2011/8 /2 16:17:59 1

0 :e0:fc:30:52:ac 248 1 0 0 ->0 10 1 6 2011/8 /2 16:11:54 1

其中两个MAC地址:

0016-412d-bdba在端口G8/0/4和聚合组1之间迁移；

0023-89af-7feb在端口G8/0/3 和聚合1之间迁移，这两个MAC地址的迁移次数达到3000多次，这个是比较明显的环路的特征。对这两个MAC进行查询发现，这两个MAC地址的设备都是直接连接在75E-1的slot 8槽位，而且都是单链路上行，正常情况下，MAC地址不可能学习到75E-1和75E-2之间的聚合链路上，从拓扑上来看，环路可能会产生在如下图中红色标注的路径

既然环路产生在这中间，那就说明备防火墙原本阻塞的链路得变成转发状态，主备防火墙都转发数据了，否则数据不可能在红色实线标示的路径上转发，由此我们有理由怀疑防火墙出现双主的情况，这就需要查看一下防火墙上的日志信息，看看防火墙是否出现主备切换之类的。结果在防火墙的日志信息中发现如下日志条目：

从日志来看，防火墙多次出现HA切换，发现两个防火墙之间发生HA切换的时间和故障发生时间比较吻合, 两边防火墙都是master的时候，都转发报文，这样就具备了产生环路的条件。结合S7500E的日志，故障发生的情况就比较明显了(防火墙时间和75E系统时间一致)

首先15:15:15 防火墙发生了HA切换

紧接着15:17:07发生了LLDP邻居down的事件，这说明S7500E和下挂的S5800之间的LLDP邻居断了，此时肯定无法从S7500E telnet S5800了。

%Aug 2 15:17:07:557 2011 ZWSW1 LLDP/2/AGEOUTREM:Slot=3;Port GigabitEthernet3/0/1 (IfIndex 26214400):Neighbor aged out, chassis ID: 0023-89ae-d6c0, port ID: GigabitEthernet1/0/1.

此后LLDP邻居多次出现中断的情况，一直到最终网络恢复。

我们前面提到了整网已经启用了MSTP，为何还能出现环路呢？那么MSTP为何没有阻止掉环路呢？为了弄清楚这个疑问我们继续登录到S5800查看其STP状态，发现下挂S5800计算的根桥竟然是自己本身，而S7500E上已经通过stp instance 0 root primary确定了自己的根桥地位，但防火墙下挂的S5800仍然认为自己是根桥，那就只有一个可能，就是S5800和S75E之间的STP BPDU报文没有交互成功。我们在在这台S5800上开启debugging stp packet receive查看STP BPDU报文的交互情况，发现此设备没有收到任何的BPDU报文，所以STP没有阻断环路的原因在于BPDU报文被中间设备丢弃了，BPDU报文没有交互成功。综合我们的分析，故障原因就比较清楚了，其根本原因有两点:

1) 防火墙发生HA，变为双master使得网络具备了环路产生的条件

2) S5800和 S75E之间的BPDU报文被中间防火墙丢弃，导致STP没有在环路产生的时候阻塞掉链路。

这两点导致了故障的产生，如果重启S75E设备，则环路的条件被破坏，如果此时防火墙再不发生HA切换，则故障就不会再发生，这就是重启S75E能够恢复故障的原因。

四、 解决方法：

通过我们的分析，故障的始作俑者终于浮出水面，通过客户联系防火墙厂家，防火墙厂家也承认了设备存在这样的已知bug:

1) 防火墙在某个触发条件下会无故发生HA切换，出现双Master；

2) 防火墙主备模式下，会出现将BPDU报文丢弃的情况。

通过此故障我们得到的启示是，尽管客户反馈每次故障都是重启我们的设备来恢复的，但是故障产生的根本原因未必就一定是我们设备。另外实际上客户的网络在开局的时候就存在了STP计算的问题，只不过在没有环路的情况下，问题没有暴露出来，所以在开局的时候要去检查一下STP的状态是否符合了我们规划的预期，这样可以消除此类隐患。