策略路由惹故障

引言： 本文介绍一则由策略路由引起的故障及排除过程，期间抓包验证“数据包来回路径不一致”被防火墙检测丢弃的现象。本文重点分享了解决网络疑难问题的过程与方法，并给出一种在防火墙存在状态下不影响源端网段间互访的策略路由写法。

故障现象

一天，某单位资深工程师给笔者打了求助电话，起因是该单位外网内部分网段无法访问局域网内系统，但均能上互联网办公。在笔者的要求下，工程师画了该单位外网的简单拓扑图如图1所示。

该单位外网采用高可用性网络架构。出口采用电信运营商和政务网双出口冗余热备；核心层采用虚拟化技术，由两台国产H3C 7500系列高端交换机IRF虚拟化成一台交换机；接入层（服务器区）采用多模光纤聚合链路上联。现在的现象是：某些网段（如172.18.49.0/24网段下）的计算机无法访问172.18.54.0/24网段下的服务器，无 法Ping通，但是该核心交换机下的其他网段却正常，并且所有网段均能上网。

故障分析

这个网络架构属于经典的网络架构图。核心交换机（可以看成一个交换机）下面的网段同属于一个交换区，如果没有特别的网络策略或防火墙，理论上，互通没有任何问题（H3C交换机默认是开启网段间路由的）。问题出现了，本着“分析验证”的思路，逐步开展以下分析。

1.排除服务器区域故障点

部分网段能访问服务器区网段，说明服务器服务应该正常。该工程师还给笔者强调前几天还是正常的，期间没人动过服务器配置，这使笔者暂时排除服务器及服务器所在网段的设备问题。

2.排除接入网段故障

故障点所在的接入交换机网段能够正常上网，说明接入交换机的设备和网路也应正常。

3.排除核心交换机故障

有网段能访问，说明核心交换机网段间路由是没被关闭的。再说，该工程师强调“前几天都正常”、“网段间是直接链路聚合上联交换机的”、“没有网络阻拦策略和防火墙”。如果这样的话，理论上没问题。

图1 外网拓扑简图

图2 原数据包流图分析

笔者要求远程查看核心交换机的配置，发现该单位为了流量负载均衡，部分网段采用了策略路由配置。在核心交换机上定义策略DianXinPre，为类DianXin指定流行为DianXinBehavior（下一跳为电信路由接口），为类ZhenWu指定流行为ZhenWuBehavior（下一跳为政务路由接口）。和故障网段相关的配置信息简述如下：

#通过Acl匹配，定义不同数据流向的类

# 定义不同类的下一跳数据路径

redirect next-hop 电信路由下联口IP

traffic behavior ZhenWuBehavior

redirect next-hop 政务路由下联口IP

#把类和特定流向关联，形成策略

4.排除策略路由配置错误

看到目标网段有策略路由配置，我们知道，策略路由的优先级高于静态路由，莫非数据包从接入交换机上联口进入核心交换机时，被直接策略转向电信路由器后没有回包，导致无法被Ping通？我绘制了如图2所示的数据包流图。

172.18.49.0/24 ping 172.18.54.0/24数据包流图沿虚线流向，数据包沿虚线①-②方向到目标网段，目标网段因为有策略路由，故回包沿③先到电信路由器（不是直接通过核心交换机转给源端），然后电信路由器要写条目的为172.18.49.0/24的回程静态路由指向核心交换机（即线路④）返回到核心交换机，然后再沿线路⑤回包到源端。问题有可能出现在线路④上。

可是，经验老道的工程师当时就打消了我的疑问。工程师说，这点他还是知道的，明确有回程路由，否则前几天不会通。在我的要求下，他自己又登录设备验证了有回程路由。

分析陷入了僵局，笔者要求分别从源端和目的端抓包分析（如图3和图4）。

图3 源端抓包

图4 目的端抓包

图5 新数据包流图分析

由图3和图4可以看出，源端发包只有request包，就是没有服务器响应包，无法建立TCP连接，而服务器端抓包正常（能Ping通源地址）。原因已经很明确了，源地址在访问服务器的时候，服务器端没有回程数据包！

可是，工程师不承认上面的分析。笔者要求，远程桌面亲自查看，工程师登录了设备，原来是一台某大厂商的防火墙，并找出回程静态路由配置。笔者问，不是说是路由器吗，怎么会是防火墙？工程师说，上个星期把出口换成防火墙了，但路由器的配置一一对应迁移到防火墙了，后来测试“一切”正常。一看到防火墙，笔者犹豫了，是不是有什么阻拦策略呢？查看发现，回程静态路由确实存在并且正确。问题出在哪里呢？

再次结合数据包流图分析过程并特别留意服务器回程的数据包，问题突然豁然开朗。

如 图5所 示，172.18.49.0/24 沿虚线①-②传输数据包，由于172.18.54.0/24网段做策略路由，优先级高于静态路由，回包被策略到电信出口防火墙，由于是状态检测包过滤的防火墙，事先没有请求包通过而直接返回数据包，防火墙认为是攻击行为，故直接拦截掉了。笔者启用了该防火墙的非状态检测包过滤功能，困扰该工程师的难题立刻解决了。

为什么一开始服务器端却能Ping通客户端呢？其实，很好理解。服务器发起的访问包被策略路由沿虚线③转发到防火墙（防火墙对合理的请求包是允许通过的），然后通过静态路由沿虚线④到核心交换机，后到客户端；客户端回包，直接通过核心交换机返回到服务器端，一次通信连接顺理成章地建立成功。

故障解决

知道问题原因，故障暂时解决了。可是，该工程师说，这不是长久的解决办法，启用防火墙的非状态检测包过滤功能就意味着防火墙的部分安全功能被废弃了。

确实如此，策略服务器网段的业务需求不能改变（因为外网发布需要），其他网段的需求也不能妥协，能否有兼顾的解决办法呢？登录虚拟化的核心交换机并查看相关厂家文档，研究后给出一种在防火墙存在状态下不影响源端网段间互访的策略路由写法：

在原策略路由基础上新增类Lan（到本地局域网网段的数据流），指定流行为LanBehavior（采用流量过滤filter permit，而不是定义下一跳地址），然后在策略DianXinPre的首条增加Lan和LanBehavior的关联。

#通过Acl匹配，新增本局域网网段间数据流的类

#对本局域网网段间的流量采用流量过滤，而不是定义下一跳地址

#在策略中首先匹配局域网内数据流量

至此，故障完全解决。笔者在原来配置的基础上加了特定局域网内网段的数据包流量过滤的写法。凡是目的为局域网内部网段（ACL 3000匹配）的数据包，流行为是允许，并在策略的第一条不让交换机给“扔”到上联防火墙（或路由器）。H3C或华为设备的策略路由“流行为”，是对应符合流分类的报文做出相应的QoS动作，例如流量监管、流量过滤、流量重定向、重标记、流量统计等。而平时，大家多用流量重定向（redirect nexthop IP），对流量过滤则很少使用，相关资料也很少提及，但这个功能是非常重要的。还有一点需要强调，在定义策略中为类指定采用的流行 为（classifier tcl-name behavior behavior-name）是从上向下匹配执行的，上下顺序也极为重要，不能颠倒。

经验总结

1.数据包来回路径不一致可以正常通信，不影响业务。但是中间有防火墙就会有例外就有可能会被阻拦（没请求经过而直接返回的连接会被拦截）。

2.策略路由写法不全面不缜密，归根结底是对策略路由技术理解的不够到位不够深刻。

出现问题，要根据数据包流图冷静分析，不要被“原来‘一切’正常”、“确定没问题”、“我验证过”所遮目，逐步分析每一个可能的故障点。以前一个小小的配置修改或者设备变动就会为日后的故障埋下伏笔，特别是变更后问题没有及时发现，一段时间后才发现的故障，更难察觉。随着信息化发展的规模化、复杂化，只有不断学习才能更好地适应形势发展要求。