#信服智创#【项目案例】AF+AC分层改造：一次企业出口架构解耦实践与控制平面问题复盘

AF+AC分层改造：

一次企业出口架构解耦实践与控制平面问题复盘

目录：
一、项目背景：一台“身兼数职”的老将
二、问题分析：单体重载架构的三大隐痛
   1. 资源“内卷”，性能波动明显
   2. 故障“放大”，任意异常皆影响全局
   3. 单点“风险”，设备无冗余
三、方案设计：从“设备升级”到“架构重构”
   1. 方案对比
四、简要实施过程：能力迁移与架构重构
   1. 阶段一：出口能力从AC“剥离”至AF
   2. 阶段二：AC改造为双网桥透明模式
五、关键问题复盘：一次“控制面漂移”的诡异问题
   1. 现象
   2. 第一反应
   3. 转向怀疑网络
   4. 关键转折点
六、根因分析：透明模式下的“路径依赖”真相
   1. 核心机制
   2. 路径推演
   3. 本质问题
七、解决方案：构建控制流量确定性路径
   1. 方案一：补齐网桥2管理IP
   2. 方案二：带外管理网络（增强方案）
   3. 方案三：通过LACP（链路聚合）主动控制流量路径
八、项目价值总结
   1. 架构价值：能力解耦，职责清晰
   2. 运维价值：故障域收敛，排障清晰
   3. 技术发现：透明≠无状态
九、经验沉淀：从案例到可复用设计原则
   1. 原则一：能力解耦优先于设备升级
   2. 原则二：透明部署必须设计控制流路径
   3. 原则三：架构改造必须具备可回退能力
十、结语

一、项目背景：一台“身兼数职”的老将
某中型企业网络长期采用传统单设备出口架构：
Internet
↓
深信服AC-1800（出口网关 + 上网行为管理）
↓
核心交换机
↓
办公终端


该设备（2017年部署）长期承担四类核心职责：
①三层网关（PPPoE / 路由 / NAT）
②用户认证与准入控制
③上网行为管控与审计
④SSL解密

可以说，当时它是网络和安全的中枢。但随着时间推移，这套“一体化”架构的弊端开始显露。

二、问题分析：单体重载架构的三大隐痛
客户选择改造，并非设备损坏，而是这套架构在日常运行中，问题越来越频繁：
1. 资源“内卷”，性能波动明显
现象：SSL解密与上网管控，与路由、NAT争抢同一块CPU资源。
后果：业务高峰期，CPU时常飙升至85%-95%，甚至100%，导致网页打开延迟达到3-5秒，视频会议卡顿。


2. 故障“放大”，任意异常皆影响全局
由于AC是唯一出口，任何问题都会导致“全网不可用”：
①NAT异常 = 网络故障
②策略异常 = 业务中断
③性能瓶颈 = 全网抖动
故障域完全没有收敛。

3. 单点“风险”，设备无冗余
作为唯一出口节点，设备一旦异常（如电源故障、系统死锁、设备宕机），整个公司网络便陷入瘫痪，且无法快速切换。

客户核心目标：不是换一台新设备，而是重构架构，将网络转发能力与安全审计能力解耦。

三、方案设计：从“设备升级”到“架构重构”
1. 方案对比

方 案	描述	结论
方案A	新AC替换旧AC	仅更换新型号AC，架构不变；问题会延续，性能瓶颈可能再次出现
方案B	AF + AC 分层架构（最终选择）	AF负责网络出口，AC专注行为管理        能力解耦，职责清晰，故障域收敛

我们评估了两个方案：
最终目标架构：
Internet → 深信服AF (路由/NAT/安全) → 深信服AC (审计/管控) → 核心交换机 → 办公终端

设计思想：
让AF做它擅长的“确定性转发”、“安全防护”，让AC回归它本该专注的“可视化管控与审计”。从“单体设备”到“能力栈分层”。



四、简要实施过程：能力迁移与架构重构
为了保证业务不中断，我们采用了分阶段、可回退的迁移策略。
1. 阶段一：出口能力从AC“剥离”至AF
将AC上的网络层配置，完整迁移到新部署的AF上（相当于给网络出口换了个“大脑”）：
①网络配置：PPPoE/专线接口、默认/静态路由。
②NAT策略：同步并清理了多年积累的数十条冗余规则。
③基础安全：配置了必要的访问控制策略。
④关键原则：此阶段只做“平移”，保证业务连续性第一。
风险控制措施：
保留原AC出口路径不下线：在AF接管前，原有链路保持可用，确保可快速切回

2. 阶段二：AC改造为双网桥透明模式
将原来的出口AC“降级”为透明网桥，串联在AF和核心交换机之间（让它专心做“观察员”）：
①网桥1：ETH0 ↔ ETH2
②网桥2：ETH1 ↔ ETH3
关键注意点：
务必使用硬件Bypass网口对，避免设备断电导致网络中断。

完成网络层迁移后，再将上网认证、流量管控、SSL解密等策略从旧AC迁移至新AC上。


五、关键问题复盘：一次“控制面漂移”的诡异问题
在双网桥透明部署后，出现了一个极为“诡异”的现象：
1. 现象
同一VLAN、相同配置的不同办公终端，一部分可以正常访问AC的管理界面，另一部分则完全不通，Ping管理IP也是时通时断。

2. 第一反应
“配置出错了？”反复检查了AC的网桥配置、管理IP等，确认无误。

3. 转向怀疑网络
“难道交换机有隐藏ACL？”我又花了一整个下午排查核心/接入交换机的配置，VLAN、ACL、STP一切正常。问题依旧。

4. 关键转折点
当我将所有出问题的终端对比分析后，发现了一个规律：
①交换机A的终端 → 可正常访问AC管理界面。
②交换机B的终端 → 无法访问AC管理界面。

此时才意识到，问题从“配置错误”转向了 “流量路径差异” 。
同样是去往AC管理IP的流量，因为来源不同，走的路径不一样，结果也不同。


六、根因分析：透明模式下的“路径依赖”真相
进一步回溯AC的双网桥设计，发现了根源：
1. 核心机制
在透明网桥模式下，管理IP并非“漂浮”在所有网桥上，而是属于某个特定网桥的控制平面对象。
在本案例中，管理IP仅配置在了网桥1上。网桥2没有配置管理IP。

2. 路径推演
①成功的路径：
终端流量从交换机A出发 → 进入AC的网桥1 → AC控制平面识别并响应 → 正常通信。

②失败的路径：
终端流量从交换机B出发 → 通过链路进入AC的网桥2 → 网桥2作为“纯数据平面”无法关联到网桥1的控制平面 → 包被丢弃或无法响应 → 管理IP不可达。

3. 本质问题
在双网桥透明模式下，控制平面存在“路径依赖”。
当多链路接入环境导致流量随机进入不同网桥时，就发生了 “控制面漂移”——请求来了，但控制面不在这里。


七、解决方案：构建控制流量确定性路径
1. 方案一：补齐网桥2管理 IP
①网桥1：管理IP A
②网桥2：管理IP B
③实现双控制面冗余
此方案不推荐：涉及到各网桥不能同网段、vlan通信、vlanif接口sub IP，实现较复杂

2. 方案二：带外管理网络（增强方案）
实施方式：
①独立管理口
②管理流量与业务流量隔离
实现效果：
控制台访问恢复稳定
①不再依赖接入位置
②控制平面路径确定性建立

3. 方案三：通过LACP（链路聚合）主动控制流量路径
实施方式：
①在AF与核心交换机之间配置LACP聚合。
②将AC的两个网桥串联在聚合链路中间。
③关键一步：通过调整交换机侧LACP的接口优先级，强制指定承载管理IP的网桥1所连接的链路为主用链路。
实现效果：
①管理流量固定：所有去往管理IP的控制流量，100%进入网桥1。
②数据流量冗余：网桥2所在的链路作为数据转发备用。
③价值：从“被动适配随机路径”转变为 “主动控制确定路径”。

八、项目价值总结
最终，所有问题圆满解决，架构平稳落地。
1. 架构价值：能力解耦，职责清晰
从“单体出口”升级为“AF(网络边界) + AC(行为审计)”分层架构，网络与安全能力彻底分离。

2. 运维价值：故障域收敛，排障清晰
AF出问题，排查网络层；AC出问题，排查策略层。互不干扰，排障路径一目了然。

3. 技术发现：透明≠无状态
透明网桥模式下，控制平面仍有“归属感”，多链路部署必须设计控制流确定性，避免“路径漂移”。


九、经验沉淀：从案例到可复用设计原则
如果说本次项目解决的是一个具体问题，那么更重要的是对以下通用设计原则的验证：
1. 原则一：能力解耦优先于设备升级
在出口设备长期承载多种职能时，应优先通过架构拆分实现能力解耦，而非简单替换设备。
价值：
①避免资源竞争
②降低故障放大效应
③提升系统扩展性

2. 原则二：透明部署必须设计控制流路径
透明网桥对数据流透明，但控制平面具有归属。
多链路场景必须确保：
①控制流具备确定路径
②避免路径随机

推荐手段：
①单独带外管理（优先）
②链路聚合引导（进阶）

3. 原则三：架构改造必须具备可回退能力
所有网络改造必须设计回退路径：
①保留旧链路
②新旧路径并行
③支持快速切换
本项目通过“新IP + 保留原出口路径”，实现秒级回退，大幅降低实施风险。

十、结语
这次改造的最大收获，不只是完成了一次设备替换，而是深入理解了透明网桥下控制平面的行为逻辑。

一个好的架构，不是设备的堆叠，而是让每一类能力各司其职，并为所有流量（包括控制流）设计一条确定的、可预期的路径。

感谢投稿，已收录文章！