疑惑，找到了对应的案例。
- 0关注
- 0收藏，128浏览
问题描述：
防火墙旁挂核心，核心上pbr引流到防火墙再出去，我记得之前旁挂要接2根线。现在我用一根线也模拟成功了，那就是1根线也可以呗？
案列如下：
组网简化拓扑如下图所示，PC 将上传数据给 Server，要求该上传数据流量，经过 FW 过滤转发。
SW 作为 PC 和 Server 的网关，承担三层转发。
根据需求，其业务流量转发，如下图所示，按照 ① -> ② -> ③ -> ④ 路径转发。
具体部署思路为：
1、在 SW 的 PC 网关 Vlan-interface 11 上部署 PBR ，将流量重定向给FW，及实现 ① -> ② 转发。
2、在 FW 上配置 缺省路由，确保流量经过 FW 安全策略过滤后，仍会给 SW。SW 收到 FW 发来的流量后，查找本地转发表，将流量转发给 Server，及实现 ③ -> ④ 转发。
问题描述
根据部署思路，在相关 SW 和 FW 部署后，发现 PC 无法将流量上传给 Server。
通过在PC 上 treacert 20.1.1.88 , 发现流量在 SW 和 FW 之间反复横跳，及如下图所示：
上传流量实际转发路径为：① -> ② -> ③ -> ② -> ③ -> ② ->......
过程分析
通过检查 SW 上的 快速转发表 ip fast-forwarding cache ，发现 “源IP=10.1.1.88，目前IP=20.1.1.88”的流量，在 SW 的快转表中，始终指向 FW 作为下一跳。
因此当流量首次经过 ① -> ② -> ③ ，SW 收到了 FW 转发回来的流量后，仍然按照前期（① -> ② ）形成的快速转发表，将流量又再次扔给 FW，因此导致流量转发路径始终为 ① -> ② -> ③ -> ② -> ③ -> ② ->......
解决方法
目前 Comware V7 平台交换机设备缺省均使能了 “快速转发功能”和“ 快速转发负载分担功能”，表项老化时间缺省为30秒。
开启快速转发负载分担功能后，当一条数据流从不同入接口上来进行转发时，不再根据入接口不同区分数据流，根据报文中的信息标识一条数据流。
因此按照上述故障案例，PC to Server 的流量，对于 SW 而言 无论是从 Vlan-interface 11 收到，还是从 Vlan-interface 33收到，缺省 SW 认为是同一个流量，及按照 display ip fast-forwarding cache 快速转发表转发。
要解决上述旁路转发的问题，需要在 SW 上关闭快速转发负载分担功能，及 增加 [SW] undo ip fast-forwarding load-sharing
关闭快速转发负载分担功能后，将会根据入接口的不同对已标识的数据流再次做出区分，即将入接口作为区分数据流的另一特征标识。及从 FW 发回给 SW 的流量将不再直接匹配 display ip fast-forwarding cache 快速转发表转发，而是 SW 重新进行转发计算，将流量从 Server 网关接口发送给 Server。
关键部署步骤&命令：
1. 核心SW配置
连接FW的端口配置Trunk：
interface GigabitEthernetX/X
port link-type trunk
port trunk permit vlan 11 20 100 200 # 允许PC/Server业务VLAN+旁挂专用VLAN（100=引流入FW，200=FW回流）
PC网关Vlanif11配置PBR引流：
acl number 3000
rule 10 permit ip source 192.168.11.0 0.0.0.255 destination 192.168.20.0 0.0.0.255
policy-based-route pbr1 permit node 10
if-match acl 3000
apply ip-address next-hop 192.168.100.2 # FW的VLAN100子接口IP
interface Vlan-interface11
ip policy-based-route pbr1
2. FW配置
创建子接口区分流量：
interface GigabitEthernetX/X.100
感觉不太可能，策略路由比路由表的优先级高，本地转发表就不清楚了。你做实验了吗？
而且，访问时双向的过程，sever回来的时候怎么走呢？
给你直白总结 + 回答你的核心疑问：
1、旁挂防火墙「一根线到底行不行？」
- 上行引流（PBR）把流量丢给防火墙
- 防火墙查策略 + 路由，回包还给核心
- 核心正常查表转发落地
- 一根【引流进防火墙】
- 一根【防火墙回注流量】
2、你遇到的「流量来回横跳、环路反弹」根本原因
- 交换机默认开启：
ip fast-forwarding enable
ip fast-forwarding load-sharing
- 快速转发不区分入接口，只看「源 IP + 目的 IP」五元组
- PC→服务器流量：
- 从终端 VLAN 进来 → PBR 甩给防火墙
- 防火墙处理完，从旁挂互联 VLAN / 接口送回核心
- 交换机快转表不认 “入接口差异”，判定是同一条流
- 直接复用之前快转表：又扔回防火墙 → 永久来回反弹
3、唯一根治命令（生产环境标准最优解法）
undo ip fast-forwarding load-sharing
关闭后的原理变化
- 快转表 加入「入接口」作为流区分条件
- 终端侧入接口过来的流量：匹配 PBR→去防火墙
- 防火墙回传、旁挂接口入流量：重新路由查表，不走 PBR、不反弹
- 完美隔离来回流量，单线旁挂彻底正常
4、两种旁挂架构对比（帮你彻底理解）
🔹 老旧双線旁挂（冗余隔离）
- 接口 A：核心 → 防火墙（引流）
- 接口 B：防火墙 → 核心（回注）
- 优点：天然隔离来回流量，不会触发快转环路
- 缺点：浪费接口、配置繁琐
🔹 现在单线旁挂（主流极简）
- 同一个三层互联网段 / 接口，双向互通
- 只需一条命令关闭：
undo ip fast-forwarding load-sharing - 精简拓扑、节省口资源、维护简单
- 现网项目大量落地，完全标准合规
5、最终结论（直接回答你）
- ✅ 防火墙旁挂，单根线完全可以用，架构没问题
- ❌ 流量环路、来回横跳，不是单线导致，是 V7 默认快转负载分担机制导致
- ✅ 全局敲一条
undo ip fast-forwarding load-sharing永久解决 - 以后所有 H3C V7 交换机 + 单链路旁挂防火墙，提前敲这条命令，规避所有同类坑
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明