为什么防火墙不让配置traffic-policy

为什么不推荐混用？

您需要先理解两个核心概念的区别：

• traffic-policy (流量策略)：这是较早期的技术，主要基于IP地址、端口等“四层信息”来做流量整形、带宽限速。它可以做访问控制（允许/拒绝），但这不是它的设计初衷。

• security-policy (安全策略)：这是V7平台主推的新一代策略。它不仅能基于IP/端口，还能基于应用、用户、终端、时间等七层信息进行精细化控制，功能更强大、配置更灵活。

巡检系统报“不让配”，主要基于以下两个原因：

1. 功能重叠，且后者更优：如果使用traffic-policy来做基础的“允许/拒绝”访问控制，它的功能远不如security-policy强大。官方认为这是一种落后的配置方式，推荐统一使用security-policy来管理和维护。

2. 潜在的配置冲突风险：这是最关键的技术原因。根据H3C官方文档，设备处理流量的逻辑是安全策略优先于包过滤（或流量策略）。这意味着，如果你混用两者，可能出现配置了traffic-policy允许访问，但security-policy的默认动作是拒绝，导致访问失败的“奇怪”现象，增加排查难度。

 如果非要配置，会有什么影响？

如果忽略建议，执意配置traffic-policy来管控访问，可能会遇到以下问题：

• 功能不完整： 如果你试图用它来禁止外网访问内网的某个高危端口，它会生效，但配置和管理会非常繁琐。如果还想基于“哪个用户”、“哪个应用”来更精细地控制，它就做不到了。

• 策略冲突与排查困难： 当traffic-policy和security-policy的规则存在冲突时，遵循“安全策略优先”的原则，您精心配置的流量策略可能并未生效。更麻烦的是，排查问题时需要同时检查两套配置，增加了运维的复杂度。

• 限速机制的“不准确”问题：这并非bug，而是设计上的“特性”。traffic-policy的限速机制主要基于会话发起方向（上行）的流量。对于一些特殊的流量模型（比如测速网站的下行流量，它只是对上行的回应），限速可能完全无效，导致策略看起来“没起作用”，给故障排查带来困扰

官方推荐的做法是将访问控制功能迁移到统一、强大的 security-policy 上。

您可以按以下步骤进行平滑迁移：

1. 审查现有策略：先通过命令行 display traffic-policy 和 display security-policy ip 看看当前都有哪些配置。

2. 规划新策略：将traffic-policy中用于“访问控制”的规则，在security-policy中重新配置一份。同时，把您想要做的“带宽限速”也通过安全策略的“DPI”或“带宽管理”功能来实现。

3. 测试与切换：在新的security-policy生效后，观察一段时间，确认业务正常。之后，就可以通过 undo traffic-policy 命令清除旧的流量策略了。