防火墙双机热备典型故障现象及定位.docx
《防火墙双机热备典型故障现象及定位.docx》由会员分享，可在线阅读，更多相关《防火墙双机热备典型故障现象及定位.docx（14页珍藏版）》请在冰豆网上搜索。
防火墙双机热备典型故障现象及定位
双机热备份典型故障现象及定位
当前现网组网基本上都是双机热备份组网，而现在由于双机热备份配置或者是组网带来的问题导致现网业务中断也是多有案例出现，下面就几个典型案例来介绍防火墙双机热备份组网中的常见故障及故障定位解决办法。
1案例一：
双机热备份组网部分业务中断的问题
业务与软件部门在河北某局点于2007年11月用两台Eudemon1000替换NetScreen的防火墙NS500，业务割接之后发现部分业务不通，最终定位为双机热备份配置的问题。
1.1组网图：
组网图如下所示，其中图中注明的新增的两台Eudemon1000是替换掉NS500割入的设备，防火墙使用路由模式组网，使用的版本是EU300&500&1000&SP1800-VRP3.30-0359（08）。
1.2防火墙配置：
防火墙配置如下附件所示：
由于此次割接是Eudemon防火墙替换NS500的防火墙，所以防火墙的配置基本上是把NS500的配置翻译成防火墙的配置之后割接上去。
1.3故障现象：
防火墙割接上去之后，发现用一个测试软件从trust到dmz域做NAToutbound出去访问一个指定的server不通，但是可以从防火墙上ping通此server服务器，查看防火墙会话，有从测试PC到server的会话。
刚开始业务与软件部门的兄弟开始检查配置，找自己的部门人员分析，反复查看配置及组网，对比防火墙和NS500的配置之后，仍然没有发现任何疑点，因为NAT地址的地址以前在NS500上使用是可以的对外发起访问的，但是在Eudemon1000上却对外发起访问不成功，由于此次割接只是用防火墙Eudemon1000替换NS500，其他设备没有什么改动，初步定位问题出现在防火墙上。
但是防火墙上已经建立了从内网访问server的会话，如果按照防火墙的转发原理，只要回来的报文能到达防火墙，都能命中会话转发到测试PC上。
1.4定位过程：
最后现场技术支持和用服找到防火墙研发，防火墙研发登陆到防火墙上，开始进行定位。
首先查看从测试PC到指定Server的会话，确实是存在从测试PC到指定Server的TCP会话，同时存在从F5到Server的会话。
当时让现场工程师从F5pingServer，发现ping不通，然后查看防火墙上的从测试PC到Server的会话，发现会话的老化时间都是10S钟。
根据上面的现象，初步断定是报文从防火墙做NAT出去之后回来的报文没有达到防火墙上，因为如果报文能回到防火墙上，会命中会话转发到F5或者是测试PC上，ping和TCP的三次握手能完成，F5能ping通Server，从测试PC到Server的TCP连接的会话老化时间应该是20分钟而不是10S。
首先让现场工程师查看从防火墙的上行设备上是否有地址池地址的路由能到达防火墙，查看路由没有问题，然后查看防火墙上行设备上的对应的地址池的ARP表项是否正确，发现此设备上没有到地址池的ARP表项，所以导致到防火墙NAT地址池的地址的报文因为没有ARP转发不到防火墙上。
通过在防火墙上行设备上ping防火墙的NAT地址的地址，使上行设备主动请求防火墙的NAT地址池的ARP，还是得不到防火墙NAT地址池的ARP。
最后查看防火墙的NAT地址池的配置，发现配置的NAT地址池的VRRPID和回来的报文的接口上的VRRP的ID不一致，把VRRPID修改成回来报文的入接口的VRRP的ID，F5能ping通Server，测试PC能正确和Server建立连接，问题解决。
1.5原因分析：
防火墙做双机热备份，配置的NAT地址池的地址需要带上出接口的VRRP的ID，保证和防火墙相连的设备请求NAT地址池地址的ARP的时候，主防火墙能正确的回应ARP报文而备防火墙不回应此ARP请求。
如果出接口的VRRPID和NAT地址池上的VRRP的ID不一致，主备防火墙都不会回应此ARP请求，导致业务中断。
如果NAT地址池不带VRRP的ID，主备防火墙都会使用接口MAC地址回应此ARP请求，会导致报文被转发到备防火墙上，出现业务时而通时而不通的情况。
如果出接口没有配置VRRP的ID，配置NAT地址池或者是NATServer的时候不带VRRP的ID，也不能带其他接口的VRRP的ID。
1.6问题定位思路：
此问题虽然是由配置引起的，但是也涵盖了双机热备份定位的思路，这些问题基本上是部分业务中断。
1：
首先排除包过滤的原因，以及攻击防范的原因。
2：
查看防火墙上的会话的状态，用ping进行测试，查看如果有对应的ICMP的会话，但是仍然ping不通，就要查看icmp的回应报文是否达到发火墙了。
3：
对于判断是回应的报文没有到达防火墙上，可以查看防火墙上下行的路由是否配置正确，ARP表项是否正确，如果不正确，查看并修改配置。
4：
如果配置没有问题，查看业务故障的时候备防火墙的日志信息，如果有出现主备倒换的日志，说明备防火墙发生备－>主－>备的倒换，更新了上下行设备的ARP表，导致业务异常，此时需要在防火墙上下行配置静态ARP，恢复业务，并寻求技术支持。
1.7类似问题的其他局点：
坦桑尼亚局点曾经也因为NAT地址池和NATServer的问题导致业务中断，最后在NAT地址池和NATServer上配置上VRRP的ID后业务恢复。
2案例二：
双机热备份组网全网业务中断的问题。
PS部门2007年8月在江苏某局点新上线2套GPRS设备，其中涉及到四台防火墙，分别部署在两个机房，两个机房的配置和组网完全对称，其中一个机房在运行中发生业务全网业务中断，主备倒换之后业务恢复，另外一个机房的防火墙没有出现此问题。
问题没有复现，后来研发到现网支持，并进行相关业务割接的时候复现问题，最终定位为防火墙双机热备的问题。
2.1组网图：
组网图如下所示，两个机房形成对称组网，其中左边的机房出现了全网业务中断的情况，二右边的机房业务一直都运行正常，两边机房组网配置几乎完全一样。
图中虚线表示是备份链路，防火墙上下行设备都起VRRP，防火墙起HRP。
2.2防火墙配置：
防火墙下行是交换机，做二层转发用，防火墙上行是NE40，上面配置二层板，能透传组播及广播报文。
附件中是防火墙的配置，除了主备防火墙的ACL不一致之外，其他的配置都没有什么问题。
2.3故障现象：
当时发生故障的时候，现场工程师正在防火墙上做配置同步的操作，当时现场工程师发现不能连接到公网上，并且GGSN上报GTP隧道中断，打开包过滤，没有任何效果，业务仍然中断，后来直接通过拔掉主防火墙和NE40相连的接口的光模块，防火墙发生主备倒换，业务恢复正常。
再把主防火墙上的光模块插上，主防火墙重新抢占为主，此时业务正常，由于业务中断时间10分钟左右，客户并不知道，业务恢复之后，防火墙研发人员赶赴南京进行问题的定位。
2.4定位过程：
当时现场操作的是合作方工程师，根据他们的描述，业务发生中断的时候没有在防火墙上做任何的操作，并且后来问题一直都没有复现，给问题定位带来了比较大的困难（现场工程师对发生故障的前后细节准确而详细的描述能给定位问题带来极大的帮助）。
后来通过查看防火墙当时记录的日志信息，发现发生故障之前，防火墙上有做配置同步的操作（现场工程师一直都没有反馈这一点）。
在做了好几次配置同步的操作之后，备防火墙上出现主VGMP出现备－>主－>备的倒换。
出现这种日志之后，现场工程师发现业务中断，在NE40的和CISCO相连的接口抓包显示，所有的业务都能从6502经过防火墙转发到NE40上，但是从NE40回来的报文在NE40至防火墙上被丢掉了，6502和防火墙直连的接口上抓不到报文。
初步结论是回来的报文在NE40的上行口到防火墙的下行口之间被丢掉了，但是不能确定是防火墙丢包还是NE40丢包。
根据日志分析，发生故障前在主防火墙上做了配置同步的操作，由于此局点ACL的配置非常的多，接近5000条规则，ACL下发到NP板很消耗CPU资源，导致CPU占用率比较高，所以此时主备防火墙收到的主防火墙的VGMP的报文没有备即使送到VGMP模块，导致备防火墙VGMP超时，发生备－>主的切换，而切换之后又收到了VGMP的报文，备防火墙上的VGMP重新切换成备状态。
在VGMP备－>主的切换的时候，会发送VRRP虚地址的免费ARP，由于防火墙上行是NE40，备防火墙发送VRRP虚地址的ARP导致NE40更新了自身的ARP表，使得报文转发到备防火墙上，业务中断。
根据上面日志分析的结论，后来在南京进行现网业务调整的时候，通过在备防火墙上下发ACL和应用策略路由等，业务中断的现象复现，在业务中断的时候，采集防火墙以及上下行设备的诊断信息，以及ARP表的信息，发现NE40上的ARP表确实是被更新了，导致流量转发到备防火墙上，备防火墙接口有大量的流量进入防火墙，但是没有报文从备防火墙出来，业务中断，证实了通过日志分析的结论。
2.5原因分析：
此现网故障原因是防火墙主备组网，备防火墙瞬间发生备－>主－>备的倒换，备防火墙发送VRRP虚地址和NAT地址池地址的免费ARP，导致NE40的ARP表项被更新，报文被转发到被防火墙上。
防火墙双机热备份组网，防火墙如果收到目的MAC是VRRP虚MAC报文，会判断此虚MAC的VRRP是否为主，如果为主，则正常进行转发，如果是为备，直接丢弃报文。
防火墙收到的报文的目的MAC是接口的MAC地址，主备防火墙都会进行转发。
防火墙上行的NE40到防火墙的下一跳的目的IP地址是VRRP虚地址，在备防火墙发送了VRRP虚地址的免费ARP之后，NE40更新了VRRP虚地址的ARP，报文备转发到备防火墙上，所有的报文备丢弃。
防火墙下行的6502来说，因为GGSN/SGSN的网关的地址是VRRP的虚地址，所以GGSN/SGSN发往防火墙的报文的目的MAC都是VRRP的虚MAC，而6502为二层转发，主防火墙每秒钟会发一次VRRP的Hello报文，更新6502的MAC表，所以GGSN/SGSN发送到6502上的报文能备正确的转发到主防火墙上。
对于此问题，当防火墙上ACL的配置很多，是在主防火墙上执行配置同步或者是在备防火墙上配置ACL的时候出现的，所以不进行配置的操作就不会出现这个问题。
同时如果由于这个原因导致业务中断，可以通过手动使防火墙发生主备倒换来恢复业务。
如果不做任何操作，NE40的ARP在发生老化之前（ARP表项20分钟老化）会请求VRRP虚地址的ARP，这个时候主防火墙会回应此ARP请求，业务能在20分钟内自动恢复正常。
可以通过升级防火墙最新维护版本解决此问题。
2.6问题定位思路：
对于发生全网业务中断的问题，通常就是因为备防火墙VGMP发生主备倒换，导致上下行设备的ARP表发生错误，报文转发到备防火墙上导致的。
基本定位思路如下：
1：
首先排除包过滤的原因，以及攻击防范的原因。
2：
查看防火墙上的会话的状态，用ping进行测试，查看如果有对应的ICMP的会话，但是仍然ping不通，就要查看icmp的回应报文是否达到发火墙了。
3：
对于判断是回应的报文没有到达防火墙上，可以查看防火墙上下行的路由是否配置正确，ARP表项是否正确，如果不正确，查看并修改配置。
4：
如果配置没有问题，查看业务故障的时候备防火墙的日志信息，如果有出现主备倒换的日志，说明备防火墙发生备－>主－>备的倒换，更新了上下行设备的ARP表，导致业务异常，此时需要在防火墙上下行配置静态ARP，恢复业务，并寻求技术支持。
2.7类似问题的其他局点：
防火墙双机热备份组网，备防火墙发生主备倒换导致全网业务中断，也在其他局点发生过，其中南非局点也是因为备防火墙VGMP发生了备－>主－>备的倒换，导致上下行设备的ARP表项错误，业务中断。
下面附件中是南非问题的分析报告：
3案例三：
双机热备份组网业务瞬断的问题。
2007年6月重庆某局点，防火墙透明模式割接上线之后，出现部分业务瞬断的情况，防火墙双机热备组网情况下，业务出现瞬断，现网出现此种情况的原因大部分是由于透明模式下防火墙备份MAC转发表导致的问题。
3.1组网图：
现网组网图如下所示，防火墙上下行都是交换机，防火墙透明模式接入，上下行交换机起STP协议，保证链路不成环，防火墙配置允许备机转发。
简化后的组网图如下所示：
3.2防火墙配置：
防火墙上下行都是交换机，防火墙透明模式接入，上下行交换机二层接入，起STP协议，防火墙不支持STP协议，直接透传STP的报文。
配置入下附件所示：
3.3故障现象：
割接的主要过程分为几部分：
1割接一台Eudemon到主用链路过程
割接组网：
首先，割接Eudemon500到主用链路DCN6506和IDC6506上，同时上下行分别串入一台交换机，串入交换机主要的目的是为了能够镜像抓包。
观察DCN6506，5500和IDC6506的MAC转发表正常，STP状态稳定，IDC6506的ARP表也正常。
DCN网管中心从DCN的维护终端登陆IDC的服务器操作正常，通过防火墙上下行交换机对比抓包，没有报文丢弃。
连续观察两个整点，IDC服务器向DCN的多个网元取数据正常，通过防火墙上下行交换机对比抓包，没有报文丢弃。
2割接另一台Eudemon到备用链路过程
主用链路防火墙割接上网后，观察了两个多小时，业务都是正常的，说明防火墙转发业务没有问题，所以准备割接另一台Eudemon到备用链路DCN5500和IDC6506之间。
割接备用链路之前，参考韩工的建议，将主用链路的两台交换机撤下来，组网变成了：
观察了一下，业务恢复正常后，在备用链路串入了另外一台防火墙：
这时候，出现了一个问题：
从IDC6506下的测试PC，pingDCN的网关10.190.44.254出现不定期的丢包。
3.4定位过程：
通过察看DCN6506，5500和IDC6506的信息都没有看出什么异常信息。
为了确定是不是防火墙丢弃的报文，决定在主用链路上再串入交换机进行抓包分析：
1）将业务先倒到备用链路上。
2）主用链路Eudemon两侧分别串入一台交换机。
3）将业务倒回到主用链路上。
4）交换机上下行进行抓包，同时对比分析。
上下行抓包进行对比分析，发现丢包是IDC6506向网关10.190.44.254发送的icmprequest报文有时候被防火墙丢弃了。
再查询两台防火墙的MAC转发表，主用链路防火墙的MAC转发表是正确的：
HRP_Mdisplayfirewalltransparentaddress
Vlan-IDMac-addressActionInterfaceTypeAging-timeTTL
30000-0c07-ac03permitG1/0/0dynamic00:
20:
0000:
20:
00
30050-0b79-4140permitG1/0/0dynamic00:
20:
0000:
19:
11
300e0-fcce-87b6permitG2/0/0dynamic00:
20:
0000:
20:
00
30009-124d-ba42permitG2/0/0dynamic00:
20:
0000:
20:
00
30009-127d-7735permitG2/0/0dynamic00:
20:
0000:
09:
47
3000f-e250-3c90permitG2/0/0dynamic00:
20:
0000:
09:
51
3000f-e21f-77a0permitG1/0/0dynamic00:
20:
0000:
12:
28
300e0-fc09-bcf9permitG2/0/0dynamic00:
20:
0000:
19:
24
30006-d6ff-8140permitG1/0/0dynamic00:
20:
0000:
12:
48
3000b-5fdb-a4e1permitG1/0/0dynamic00:
20:
0000:
20:
00
3000a-4124-b126permitG1/0/0dynamic00:
20:
0000:
12:
20
其中：
0000-0c07-ac03是DCN网关MAC，对应IP地址10.190.44.254；
0009-124d-ba42是IDCVLAN3接口MAC，对应IP地址10.190.44.251；
防火墙的G1/0/0连接DCN的6506；G2/0/0连接IDC6506。
备用链路防火墙的MAC转发表是错误的：
HRP_Sdisplayfirewalltransparentaddress
Vlan-IDMac-addressActionInterfaceTypeAging-timeTTL
30006-d6ff-8140permitG2/0/0dynamic00:
20:
0000:
02:
01
30000-0c07-ac03permitG2/0/0dynamic00:
20:
0000:
02:
01
30010-7bd2-051dpermitG1/0/0dynamic00:
20:
0000:
02:
12
30009-127d-7736permitG2/0/0dynamic00:
20:
0000:
02:
16
300e0-fcce-87b6permitG2/0/0dynamic00:
20:
0000:
05:
31
30009-124d-ba42permitG2/0/0dynamic00:
20:
0000:
08:
59
0000-0c07-ac03是DCN网关MAC，对应IP地址10.190.44.254，在备用链路上从G2/0/0学习到了。
备用防火墙从G2/0/0学习到该MAC地址的原因是：
如上图所示：
DCN6506，5500和IDC6506组成了一个VLAN3的环，防火墙放在中间的链路只是起到透明的作用，不影响STP协议状态。
现网的STP协议稳定后的状态如蓝色线所示：
只有DCN5500到Eudemon500之间的接口是处于block阻塞状态；其他的接口都是forwarding状态，可以转发报文。
那么DCN6506和IDC6506在VLAN3内发送的组播（CISCO路由器启用了HSRP协议，会周期发送HELLO报文）和广播报文（ARP报文）都会广播到备用链路的Eudemon500上，如绿色线所示，备用链路防火墙就会从GE2/0/0学习到DCN网关MAC。
3.5原因分析：
主备防火墙同时在线后，出现丢包的原因就找到了：
主备链路的防火墙通过中间心跳线备份配置，状态表（session表，ARP表，MAC转发表）。
备用链路防火墙因为组网的关系，从GE2/0/0学习到DCN网关MAC，这个表项备份到主设备后，会刷新主防火墙的MAC转发表，此时如果有报文从IDC6506发送到DCN6506的时候，防火墙会因为查不到DCN网关的MAC而丢弃报文。
因为主用链路报文很多，所以主用链路防火墙会从GE1/0/0口重新学习到正确的DCN网关的MAC，这样主用链路通信就会正常。
由于防火墙是透明模式，依靠MAC表进行转发，所以一旦MAC出错，就会影响到报文的转发，出现业务中断，同时由于所有的报文都能更新防火墙的MAC转发表，所以在业务出现中断的时候，只要有其他报文过来刷新MAC表，防火墙就能正常转发。
但是由于备防火墙能学习到MAC表并且备份到主防火墙上，所以导致业务又出现中断，这样就形成了业务瞬断的现象，或者是业务不稳定。
对于此问题防火墙最新维护版本已经解决此问题，可以升级到最新维护版本。
在最新维护版本上，如果配置允许备机转发，将不再备份MAC转发表，如果不配置允许备机转发，备防火墙将学习不到MAC转发表，也不会带来问题。
3.6问题定位思路：
所有的双机热备份的问题的定位思路都是差不多的，在配置没有问题的情况下，需要查看转发的关键的表项如ARP表和MAC表。
由于透明模式下防火墙要靠MAC转发表进行转发，所以在在业务出现故障的时候，不仅要查看防火墙上下行的ARP表，MAC转发表，STP状态，还需要查看防火墙的MAC转发表。
基本定位思路如下：
1：
首先排除包过滤的原因，以及攻击防范的原因。
2：
透明模式，直接查看防火墙及上下行设备的MAC转发表，如果MAC转发表出错，可是shutdown防火墙之间的心跳线，不让MAC表进行备份，或者是升级到最新维护版本，以及寻求技术支持。
3.7类似问题的其他局点：
对于防火墙透明模式，在浙江省某局点也因为备防火墙向主防火墙备份MAC转发表导致业务瞬断的问题，大致情况描述如下：
现网情况说明：
组网结构S3553E300SBC成口字型组网。
S3552和SBC都启VRRP，E300透明模式，组网如下所示：
S3552-E300-SBC
|||
S3552-E300-SBC
SBC光纤接口地址SBC1主172.16.254.8.SBC2备172.16.254.9,虚地址172.16.254.10，其中从S3552和E300PING我SBC虚地址会丢包，没有规律信，有时候几个包丢一个，有时后十几个包丢一个，ping接口实地址没有丢包是正常的，拔掉一备用的SBC连接E300的光纤，从S3552和E300PINGSBC虚地址没有丢包是正常的。
从SBC主PINGS3552虚地址没有丢包是正常的。
从SBC备PINGSBC虚地址也会丢包。
测试尝试：
1.在SBC和S3552和E300绑定SBC的虚地址172.16.254.10的MGC地址，PING还是丢包。
2.倒换SBC，把主用切换到SBC2,测试还是丢包。
3.从S3552到SBC做地址的静态路由，测试还是丢包
原因分析：
防火墙上下行都起VRRP，由于VRRP的报文是广播报文，并且S3552和SBC都是使用的VRRP的虚地址作为指向对方的网关地址，在VRRP报文通过E300转发的过程中，主备防火墙都能学习到的VRRP虚地址的MAC转发表，如果备防火墙把学习到的MAC转发表备份到主防火墙上，将导致主防火墙MAC转发表出错，出现业务中断。
由于备防火墙每个8秒左右备份一次MAC转发表，MAC表从备防火墙备份到主防火墙的时候，主防火墙MAC转发表错误，发生丢包。
3553和SBC的VRRP每秒钟会发送一个VRRP的Hello报文，更新主防火墙的MAC转发表，MAC转发表恢复正常，业务正常。
由于以上原因所以出现没有规律性的丢包。
此问题通过升级到防火墙最新维护版本之后解决。
升级会员 