全新NGFW ONC引流方案故障处理案例
1、故障背景
场景拓扑
现网拓扑和业务说明如下：
整体方案采用INC ServiceChain引流方案，模式为透明模式（no sw+no ip）模式。防火墙采用路由模式虚拟连接对方法。
故障现象描述
开启INC的业务编排，对业务进行引流到防火墙后，业务不通。
2、故障排查方法
2.1故障定位
2.2故障原因分析
1、 定位故障点
防火墙进行sniffer抓包，现场并未抓取到报文，怀疑是引流交换机问题。
防火墙抓包命令：diagnose sniffer packet any ‘host x.x.x.x’ 4 l
- 如果有抓到报文，但没有进行转发，可确定是防火墙问题，可结合debug功能判断是什么原因导致的丢包。
diagnose debug enable //开启debug
diagnose debug flow filter addr x.x.x.x //过滤x.x.x.x的地址相关debug信息
diagnose debug flow trace start 10 //打印10条debug信息
- 如果没有抓取到报文，大概率是引流交换机方面的问题。
2、查看INC和交换机配置，并未发现问题
3、查看INC下发的流表
使用show of flow 查看流表下发情况，参数是否正确以及count值是否有变化。如果相应的count字段的数值有不断增加，说明引流成功。
获取的其中一个流表如下：
{table="0", duration_sec="177", priority="1500", flags="0x0",idle_timeout="0", hard_timeout="0", cookie="0xe51efb3520000",packet_count="10",byte_count="1298".match=oxm{in_port=“1",eth_type="0x800",ipv4_src=“30.7.0.0",ipv4_src_mask="255.255.255.0"}instructions=[apply{acts=[set_field{field:eth_src=“00:d0:f8:22:33:e5"}, set_field{field:eth_dst="1a:11:11:11:13"}, output{port=“2"}]}]}
相关字段解析：
1) duration_sec="177" 表项存在的时间
2) priority=“1500”：该流表的优先级，越大越优先。
3) packet_count， byte_count：该流表已经匹配的报文总数，报文总大小。
4) Match字段后面的括号中就是要匹配的项目，匹配的项目都是“与”关系，必须都满足才能匹配到：
（1）in_port=“1 ”：从index值为4的口进入交换机的数据，该编号和交换机实际接口编号不一定一一对应，需要在交换机上用show of port，查看编号和实际接口对应的关系；
（2） eth_type=“0x800”：ip报文；
（3） ipv4_src， ipv4_src_mask ，ipv4_dst， ipv4_dst_mask：目的地址段和目的段的掩码；
（4） ip_proto="6" 四层协议号，6表示TCP，17表示UDP
（5）tcp_src="100", tcp_dst="100" 四层协议的源目端口号，若为UDP则为udp_src="100", udp_dst="100"
5) set_field{field:eth_src=“00:d0:f8:22:33:e5”}, set_field{field:eth_dst=“1a:11:11:11:13”}：如果匹配到了报文，则将报文源MAC修改为00:d0:f8:22:33:e5，目的MAC修改为1a:11:11:11:13
6) output{port=“2 ”}：采取的动作，将数据转发到index值为2的接口；
4、通过流表发现count值有变化，但是防火墙依然没有抓到任何报文。为确定交换机是否正常引流，可通过配置ACL计数的方式对连接防火墙的接口进行计数，如果能计数正常，表示引流没问题。
5、由于ACL计数正确，表示交换机已正常发送报文，判断是防火墙问题。更换防火墙接口测试，依然无法抓到报文。具体ACL计数配置方法可参照以下脚本
6、主机直连防火墙，在防火墙接口上配置一个三层地址，发现除mgmt口外均无法正常ping通，怀疑是NP芯片故障导致（mgmt口的流量都经过CPU，不经NP芯片转发）。
7、重启设备，发现NP芯片报错，判断是硬件问题。
3、故障解决方案/规避方案
由于硬件问题，只能返厂进行设备维修。
共有 0 条评论