1. ACI 到底是什么从一个运维夜班说起凌晨两点被电话叫醒核心交换机的某个 VLAN 突然不通了业务侧开始报障。你登录设备发现配置散落在十几台交换机的命令行里VLAN 放行、路由实例、ACL 策略各写各的没人说得清全网的策略到底长什么样。这种场景在传统数据中心网络里太常见了也是 ACI 这套架构被设计出来的直接原因。ACI 全称 Application Centric Infrastructure中文一般叫“以应用为中心的基础设施”。它是思科推出的一套软件定义网络SDN解决方案核心思路是把网络策略从一台台独立的交换机上抽出来集中到一个控制器里统一管理让网络跟着应用的需求走而不是让应用去迁就网络。说白了以前是“网络怎么配应用就怎么跑”现在是“应用需要什么策略网络自动生成对应的配置”。这套东西解决的核心问题是大规模数据中心里网络策略的部署、变更和排障效率。传统方式下加一个新业务可能要登录十几台设备改配置改完还得逐台核对ACI 里你只需要在控制器上定义一个“应用轮廓”策略会自动下发到所有相关设备。适合谁来了解做数据中心网络运维的、搞云平台底层网络的、以及需要频繁做网络变更的团队。哪怕你暂时用不上 ACI理解它背后的“策略与转发分离”思想对设计任何中大型网络都有帮助。我接触 ACI 有几年了从最开始被它的概念绕晕到后来能独立做策略设计和故障排查中间踩的坑不少。这篇就把 ACI 的核心概念、架构逻辑、实操要点和常见问题一次性讲清楚尽量说人话少堆术语。2. ACI 的整体架构与设计思路拆解2.1 为什么要把控制平面抽出来传统网络设备是“控制平面数据平面”合在一台盒子里每台设备自己算路由、自己转发。这种模式在小规模下没问题但到了几千台交换机的数据中心问题就来了每台设备都要维护全网的拓扑和路由信息收敛慢策略一致性难保证排障基本靠人肉。ACI 的做法是把控制平面单独抽出来放到一个叫 APICApplication Policy Infrastructure Controller的控制器集群里。APIC 负责计算策略、下发配置、维护拓扑交换机只负责转发。这就是典型的 SDN 思路控制与转发分离。注意APIC 不是“网管软件”它是真正参与转发决策的控制器。交换机启动后会跟 APIC 建立连接从 APIC 拉取策略。APIC 挂了已下发的策略还在交换机上继续生效但新的变更就做不了了。所以生产环境 APIC 必须做集群通常是 3 台起步。为什么这么设计因为策略集中管理后一致性有了保证。你在 APIC 上定义一条“Web 层可以访问 DB 层的 3306 端口”这条策略会以统一的形式存在不会出现某台交换机漏配的情况。变更效率也从“逐台改”变成“改一处全网生效”。2.2 核心组件都有哪些ACI 的组件不算多但每个都得搞清楚不然看文档会晕。我整理了一张表把关键组件和职责列出来组件全称职责类比APICApplication Policy Infrastructure Controller策略计算、配置下发、拓扑管理大脑SpineSpine Switch高速转发连接 Leaf骨干LeafLeaf Switch接入服务器和网络设备接入层FabricACI FabricSpineLeaf 组成的整体网络整个神经系统Spine-Leaf 是 ACI 的物理拓扑基础。所有 Leaf 上行连到所有 SpineSpine 之间不互连这是关键Spine 之间没有直接链路。服务器接在 Leaf 上。这种拓扑的好处是任意两个 Leaf 之间的通信最多经过一个 Spine跳数固定延迟可预测。提示Spine 之间不互连是 ACI 的硬性设计别想着去连。早期有人试图把 Spine 互联来“增加冗余”结果破坏了 fabric 的转发模型出了不少怪问题。2.3 策略模型ACI 的灵魂ACI 最核心的创新是它的策略模型。传统网络里策略是“设备接口VLANACL”的组合分散且难追踪。ACI 把这些抽象成几个层次化的对象Tenant租户最顶层的逻辑隔离单元相当于一个独立的策略容器。不同租户之间默认完全隔离。Application Profile应用轮廓简称 AP一个租户下可以有多个 AP每个 AP 代表一组相关的应用。EPGEndpoint Group端点组AP 下的对象是一组具有相同策略需求的端点的集合。EPG 是策略的最小单位。Contract合约定义 EPG 之间如何通信包括用什么协议、什么端口。这套模型的逻辑是你先定义“谁”EPG再定义“谁能跟谁说话、怎么说”Contract最后把 EPG 映射到具体的物理接口或 VLAN 上。策略和物理位置解耦了服务器换机架、换 Leaf只要还属于同一个 EPG策略就不用改。我个人的体会是理解 EPG 和 Contract 是入门 ACI 的关键。很多人卡在这里是因为习惯了“VLANACL”的思维总想把 EPG 当成 VLAN 来用。其实 EPG 比 VLAN 灵活得多一个 EPG 可以跨多个 VLAN一个 VLAN 也可以承载多个 EPG配合微段隔离。3. 核心概念深度解析与实操要点3.1 EPG 与 Contract 的配合逻辑EPG 是“一组端点”Contract 是“通信规则”。两者配合的方式是Contract 由“提供方 EPG”和“消费方 EPG”共同引用。提供方定义“我提供什么服务”消费方定义“我要消费什么服务”两边都引用同一个 Contract通信才被允许。举个例子。假设有个 Web 应用前端是 Web 服务器后端是数据库。你会建两个 EPGWeb-EPG 和 DB-EPG。然后建一个 Contract里面定义一个 Filter允许 TCP 3306。Web-EPG 作为消费方引用这个 ContractDB-EPG 作为提供方引用这个 Contract。这样 Web 就能访问 DB 的 3306其他流量默认被拒。注意ACI 的默认策略是“默认拒绝”。不引用 Contract 的 EPG 之间完全不通。这跟传统网络“默认放行”是反过来的刚开始会不习惯但安全性好很多。实操中有一个容易踩的坑Contract 的方向。提供方和消费方的引用方向不能搞反否则策略不生效。我见过有人把提供方和消费方写反了排查了半天才发现。记住一个口诀谁提供服务谁当提供方谁访问服务谁当消费方。3.2 VRF 与 BD 的作用和区别VRFVirtual Routing and Forwarding和 BDBridge Domain是 ACI 里两个容易混淆的概念。简单说VRF管的是三层路由隔离。不同 VRF 之间路由表独立默认不互通。相当于传统网络里的 VRF-lite。BD管的是二层广播域。一个 BD 对应一个子网相当于传统网络里的 VLAN网关。一个 VRF 下可以挂多个 BDBD 之间通过 VRF 做路由。EPG 必须关联到一个 BDBD 必须关联到一个 VRF。这个层级关系不能乱。概念层级作用对应传统概念VRF三层路由隔离VRF-liteBD二层广播域网关VLANSVIEPG策略端点分组无直接对应提示BD 的网关配置有个细节ACI 里叫“BD 的子网”配置时要指定是“公共子网”还是“私有子网”。公共子网会在 fabric 内广播私有子网只在本地 Leaf 生效。选错了会导致跨 Leaf 通信异常。3.3 微段隔离与 ESG如果 EPG 是“粗粒度”的分组那微段Micro-Segmentation就是“细粒度”的。同一个 EPG 内的端点默认是可以互相通信的但如果你需要更细的控制比如同一 EPG 里的 Web 服务器之间也要隔离就得用微段。微段通过 ESGEndpoint Security Group实现。ESG 可以基于 IP、VM 属性等条件动态划分端点然后通过 Contract 控制 ESG 之间的通信。这在多租户或者高安全要求的场景下很有用。我实测下来微段配置比普通 EPG 复杂不少主要是 ESG 的匹配规则要写清楚。如果规则写得太宽可能把不该隔离的端点也隔离了写得太窄又起不到隔离效果。建议先在测试环境验证规则再上生产。4. 实操过程与核心环节实现4.1 初始化配置从零搭建 Fabric假设你拿到三台 APIC 和一批 Spine/Leaf 交换机怎么从零把 fabric 拉起来我按实际操作的顺序梳理一遍。第一步APIC 初始化。每台 APIC 上电后通过 console 或 KVM 进入初始化向导。需要配置的是APIC 的管理 IP、网关、DNSAPIC 集群的 IP 池三台 APIC 要在一个子网Fabric 的 TEP 地址池用于 fabric 内部通信Fabric 的 VLAN 池用于 infra VLAN这些地址池规划要提前做好不能跟现有网络冲突。TEP 地址池尤其重要它是 fabric 内部转发的地址规划不好后期扩容会麻烦。第二步交换机发现。交换机上电后如果配置了正确的 infra VLAN 和 APIC 地址会自动跟 APIC 建立连接出现在 APIC 的“Fabric Membership”里。你需要手动把每台交换机注册进来指定它的角色Spine 还是 Leaf和 ID。注意交换机注册时Spine 和 Leaf 的角色不能选错。选错了要重新注册比较麻烦。注册前先核对好每台设备的角色。第三步配置 NTP 和 DNS。这一步容易被忽略但很重要。APIC 和交换机的时间必须同步否则证书会出问题fabric 可能起不来。DNS 也要配好不然 APIC 解析不了主机名某些功能会异常。第四步验证 fabric 健康状态。在 APIC 的 Dashboard 上看 fabric 的健康分数。正常情况下应该是 100 分。如果有问题点进去看具体的 fault逐个排查。4.2 策略配置从 Tenant 到 ContractFabric 拉起来后就可以配策略了。我以一个典型的 Web 应用为例走一遍完整流程。创建 Tenant。在 APIC 上新建一个 Tenant名字比如叫“WebApp-Tenant”。Tenant 是逻辑隔离单元不同 Tenant 之间默认不通。创建 VRF 和 BD。在 Tenant 下建一个 VRF比如“WebApp-VRF”。然后在 VRF 下建两个 BD“Web-BD”和“DB-BD”。Web-BD 配子网 10.1.1.0/24DB-BD 配子网 10.1.2.0/24。创建 EPG。在 Tenant 下建一个 Application Profile叫“WebApp-AP”。在 AP 下建两个 EPG“Web-EPG”和“DB-EPG”。Web-EPG 关联 Web-BDDB-EPG 关联 DB-BD。创建 Contract。新建一个 Contract叫“Web-to-DB”。在里面建一个 Filter允许 TCP 3306。然后 Web-EPG 作为消费方引用这个 ContractDB-EPG 作为提供方引用。映射到物理接口。最后把 EPG 映射到 Leaf 的物理接口或 VLAN 上。比如 Web-EPG 映射到 Leaf1 的 eth1/1DB-EPG 映射到 Leaf2 的 eth1/1。配置完成后Web 服务器应该能访问 DB 的 3306其他端口不通。如果通不了先检查 Contract 的方向和 Filter 的端口配置。4.3 参数计算子网和 VLAN 池的规划ACI 里有些参数需要提前算好不能随便填。我列几个关键的TEP 地址池。每个 Leaf 和 Spine 都需要一个 TEP 地址用于 fabric 内部通信。TEP 地址池的大小取决于 fabric 的规模。假设你有 10 台 Leaf 和 2 台 Spine每台设备一个 TEP 地址那至少需要 12 个地址。但考虑到扩容建议预留一倍以上。比如用 /24 的子网够 254 个地址基本够用。Infra VLAN。这是 fabric 内部通信的 VLAN默认是 4093不同版本可能不同。这个 VLAN 不能跟业务 VLAN 冲突规划时要注意。VLAN 池。ACI 里可以定义 VLAN 池用于动态分配 VLAN。VLAN 池的范围要跟现有网络的 VLAN 规划协调避免冲突。提示TEP 地址池和 Infra VLAN 一旦配置后期修改很麻烦基本要重建 fabric。所以初始化时一定要规划好别拍脑袋填。5. 常见问题与排查技巧实录5.1 策略不生效的排查思路策略配了但不生效是 ACI 里最常见的问题。我总结了一个排查顺序检查 Contract 方向。提供方和消费方有没有引用反这是最高频的原因。检查 Filter 配置。端口、协议对不对有没有漏配检查 EPG 映射。EPG 有没有正确映射到物理接口或 VLAN端点有没有真的在 EPG 里检查 BD 和 VRF。EPG 关联的 BD 对不对BD 关联的 VRF 对不对看 APIC 的 Fault。APIC 会把配置问题以 fault 的形式报出来点进去看具体描述。我遇到过最隐蔽的一次是 EPG 映射到了错误的 Leaf 接口。因为服务器是双上行的一台 Leaf 的接口映射对了另一台映射错了导致部分流量不通。这种问题看 fault 看不出来得手动核对接口映射。5.2 Fabric 健康分数下降的常见原因APIC Dashboard 上的健康分数如果掉下来通常是这几类问题现象可能原因排查方法分数缓慢下降某台交换机 CPU/内存高看交换机的资源监控分数突然掉到 0APIC 集群脑裂检查 APIC 之间的连接分数波动链路 flapping看接口的 error 计数分数低但业务正常非关键 fault看 fault 的严重级别注意不是所有 fault 都要立刻处理。有些 fault 是“警告”级别不影响业务。但“严重”级别的 fault 必须处理否则可能影响转发。5.3 升级和扩容的注意事项ACI 的升级和扩容有一些坑我踩过几次升级前一定要看兼容性矩阵。APIC 版本和交换机版本必须兼容不能随便升。升级顺序是先升 APIC再升交换机。升级过程中业务会中断要安排窗口。扩容时新交换机注册进 fabric 后要检查它的配置有没有被正确下发。有时候新交换机会因为版本不一致或者配置模板问题策略下发失败。备份升级和扩容前一定要做配置备份。APIC 支持配置导出导出的文件要保存好。万一出问题可以回滚。5.4 常见问题速查表问题可能原因解决方法EPG 之间不通Contract 未引用或方向反检查 Contract 引用跨 Leaf 通信异常BD 子网类型选错改为公共子网APIC 无法登录证书过期或集群脑裂检查 APIC 集群状态交换机注册失败Infra VLAN 或 APIC 地址错核对交换机配置策略下发慢APIC 负载高检查 APIC 资源6. 我个人在 ACI 实操中的几点体会先说一个最实在的别把 ACI 当传统网络来配。我刚开始接触时总想着用 VLAN 的思维去套 EPG结果越配越乱。后来强迫自己按“先定义 EPG再定义 Contract最后映射”的顺序来思路就顺了。ACI 的策略模型是自顶向下的你得先想清楚应用之间的通信关系再去配网络。第二个体会是文档和实际有差距。官方文档写得很全但有些细节只有实际配过才知道。比如 Contract 的方向问题文档里一笔带过但实际配反了就是不通。还有 BD 子网的公共/私有选项文档里解释得比较抽象实际配错了跨 Leaf 就不通。这些坑踩过一次就记住了。第三个是测试环境很重要。ACI 的变更影响面大一个策略改错可能影响整个租户。有条件的话先在测试 fabric 上验证再上生产。没条件的话至少要在变更前做好配置备份变更后立刻验证业务。最后分享一个小技巧APIC 的 API 很好用。很多重复性的配置用 GUI 点很慢用 API 脚本批量做效率高很多。比如批量创建 EPG、批量绑定 Contract写个 Python 脚本调 APIC 的 REST API几分钟就能搞定。我后来把常用的配置都写成了脚本变更效率提升了不少。当然脚本操作有风险一定要先在测试环境验证别直接在生产上跑。
