思科ACI数据中心网络策略详解：Contract类型、部署机制与实践指南

基于早期笔记，由 AI 模型辅助重构，旨在深入剖析思科应用中心基础设施 (ACI) 中的核心策略控制组件 —— Contract。

🎯 一句话理解：Contract 是 ACI 中控制“谁能访问谁”的安全策略，就像大楼的门禁系统——它定义了哪些人（EPG）可以通过哪些门（Filter）访问哪些区域。

📍 知识导航图

一、Contract 的基本构成

1.1 三层结构模型

层级	组件	作用	类比
容器层	Contract	策略的逻辑容器，定义作用范围	门禁策略文件
规则集层	Subject	Filter 的集合，支持方向控制	策略章节
规则层	Filter	具体的协议匹配条件	具体的放行/拒绝规则

1.2 Scope（作用范围）

作用范围定义了 Contract 生效的边界，遵循从紧到松的原则：

作用范围从小到大：

┌─────────────────────────────────────────────────────────┐
│  Global (跨 Tenant)                                      │
│  ┌───────────────────────────────────────────────────┐  │
│  │  Tenant                                           │  │
│  │  ┌─────────────────────────────────────────────┐  │  │
│  │  │  VRF                                        │  │  │
│  │  │  ┌───────────────────────────────────────┐  │  │  │
│  │  │  │  Application Profile                  │  │  │  │
│  │  │  └───────────────────────────────────────┘  │  │  │
│  │  └─────────────────────────────────────────────┘  │  │
│  └───────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

1.3 Subject 配置选项

选项	说明
Apply Both Directions	双向应用规则（推荐配置）
Reverse Filter Ports	反向流量时自动交换源/目的端口
Subject Labels	用于策略分组和管理

1.4 Filter 详解

Filter 是构成策略的最细粒度规则，决定了流量的具体命运。

二、Contract 类型全解析

2.1 类型对比总览

类型	作用域	优先级	主要用途	推荐度
Standard	灵活	普通	常规 EPG 间通信	⭐⭐⭐⭐⭐
vzTaboo	EPG	5 (最高)	黑名单优先拒绝	⭐⭐
vzAny	VRF	-	VRF 级别统一策略	⭐⭐⭐⭐
vzCPIf	跨 Tenant	-	共享服务	⭐⭐⭐⭐
vzOOBBrCP	管理域	-	OOB 管理访问	⭐⭐⭐

2.2 vzTaboo（黑名单 Contract）

vzTaboo 拥有最高优先级 (black_list=5)，用于实现“先拒绝，后放行”的黑名单逻辑。

优先级：black_list(5) —— 最高优先级

┌─────────────────────────────────────────────────┐
│                     流量处理顺序                   │
│                                                 │
│   流量 ──▶ [vzTaboo 检查] ──▶ [Standard 检查]   │
│                 │                    │          │
│              匹配 Deny            匹配 Permit   │
│                 │                    │          │
│                 ▼                    ▼          │
│              丢弃 ✗               放行 ✓        │
└─────────────────────────────────────────────────┘

⚠️ 实践建议：vzTaboo 配置复杂且容易引起理解混乱，不推荐使用。

替代方案：

• • Standard Contract 的 Filter: Deny（更灵活可控）
• • Contract Exception / Filter Exception（意图更直接）

2.3 vzAny（VRF 级别 Contract）

vzAny 允许将一个 Contract 快速应用到整个 VRF 下的所有 EPG，简化批量策略管理。

┌─────────────────────────────────────────────────┐
│                    VRF                          │
│  ┌─────────────────────────────────────────┐    │
│  │              vzAny                      │    │
│  │  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐       │    │
│  │  │EPG1 │ │EPG2 │ │EPG3 │ │EPG4 │       │    │
│  │  └─────┘ └─────┘ └─────┘ └─────┘       │    │
│  │         统一应用 Contract               │    │
│  └─────────────────────────────────────────┘    │
└─────────────────────────────────────────────────┘

关键限制与注意事项：

场景	限制
Shared Service	vzAny 只能作为 Consumer
Scope 为 Tenant/Global	可能导致意外流量被放行
L3out 场景	EPG→L3out 可通，即使 L3out 未配置 contract

💡 LAB 经验：在 VRF 中只添加 vzAny 作为 consumer；当特定流量有问题时，再手动给对应的 EPG 添加 provider contract。这是一种“先通后控”的调试思路。

2.4 vzCPIf（跨 Tenant 共享服务）

vzCPIf 用于实现跨租户的服务共享，例如让多个业务部门访问公共的打印或OA服务。

┌────────────────┐          ┌────────────────┐
│   Tenant A     │          │   Tenant B     │
│  (Provider)    │          │  (Consumer)    │
│                │          │                │
│  ┌──────────┐  │          │  ┌──────────┐  │
│  │ 共享服务  │  │◀─────────│  │  业务EPG  │  │
│  │ OA/打印机 │  │ Contract │  │          │  │
│  └──────────┘  │ Interface │  └──────────┘  │
│                │          │                │
│  Export        │          │  Add Consumed  │
│  Contract ────────────────▶ Contract IF   │
└────────────────┘          └────────────────┘

⚠️ 冲突规则：如果一个 Contract 已经被用作 vzAny 的 provider，则不能再用于 shared service（vzCPIf），配置时需注意规避。

2.5 Unenforced Policy

这是一种特殊的 VRF 级别策略模式，旨在简化初始部署。

特性	说明
效果	VRF 内所有 EPG 默认互通
优势	无需为内部互访添加 CAM rules，节省硬件表项
注意	作为 shared service 对外提供服务时，仍需要配置 contract（这会影响到路由表的生成）

三、Contract 部署机制

理解 Contract 从配置到生效的部署机制，是进行高级排错的基础。

3.1 部署流程

3.2 部署位置对比

不同类型的规则，其生效位置和实现方式也不同。

规则类型	部署位置	实现方式	路径
actrlRule	Leaf only	Hardware/TCAM	/mit/sys/actrl/
actrlMgmtRule	All Leaf & Spine	Software/iptables	/mit/sys/actrl/
Taboo	Leaf/Spine	取决于 mgmt EPG	-

3.3 OOB/INB 管理流量特殊处理

带外（OOB）和带内（INB）管理流量因其目的地是交换机本身的管理接口（CPU），其处理路径与普通数据流量截然不同。

OOB & INB 流量路径：
┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   流量 ──▶ Supervisor/CPU ──▶ iptables 处理                     │
│                                                                 │
│   特点：                                                        │
│   • dPcTag = any (不关心目的 EPG)                               │
│   • scopeId 只有 oob & inb 两个 VRF                             │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

OOB 关键配置路径验证：

检查项	命令/路径
Prefix 状态	cat /mit/sys/ctx-[vxlan-2555904]/pfx-[0.0.0.0--0]/summary
FIB 验证	cat /proc/net/fib_trie (Id 251)
MgmtRule 状态	cat /mit/sys/actrl/scope-2555904/mr-2555904-s-16386-d-any-f-13/summary

四、Contract MO 与 CLI 速查

4.1 核心 MO 关系图

通过管理对象（MO）的关系视图，可以更清晰地理解 Contract 在 ACI 对象模型中的位置和关联。

4.2 常用验证命令

掌握关键 MO 是进行 API 级排错和自动化的前提。

验证目的	MO/命令
EPG 是否部署到节点	fvEpP (Endpoint Profile)
Zoning Rule 状态	actrlRule
Contract 部署情况	vzCollectionDef
EPG attach 确认	vzConsDef

4.3 Leaf 常用 CLI

以下命令帮助你在 Leaf 交换机上快速验证 Contract 部署机制的实际状态。

# 查看 zoning rules
show zoning-rule

# 查看特定 VRF 的 rules
show zoning-rule scope <vrf-id>

# 查看 contract 统计
show system internal policy-mgr stats

# 验证 TCAM 条目
show platform internal hal l3 sobjects

五、实践经验与避坑指南

5.1 常见问题速查表

问题现象	可能原因	排查方向
EPG 间不通	Contract 未正确配置	检查 fvRsCons/fvRsProv 关联
Shared Service 失败	vzAny 被错误地用作 provider	确认 vzAny 在共享服务中仅作为 consumer
意外流量放行	vzAny 结合了过宽的 Scope（如 Tenant/Global）	收窄 Contract 的 Scope 范围
OOB 无法访问	MgmtRule 操作状态 (operSt) 异常	检查 actrlMgmtRule 对象状态

5.2 最佳实践清单

• • ✅ 优先使用 Standard Contract，逻辑清晰，避免使用容易引发困惑的 vzTaboo。
• • ✅ vzAny 仅作为 Consumer 使用，尤其在 Shared Service 场景下。
• • ✅ Shared Service 配置前，确认目标 Contract 未被本 VRF 的 vzAny 占用。
• • ✅ Scope 选择遵循最小权限原则，从 Application Profile 或 VRF 开始，谨慎使用 Tenant 和 Global Scope。
• • ✅ 定期检查 zoning-rule 部署状态，确保策略已正确下发到硬件。

📝 知识检验

问题：在 ACI 中配置跨 Tenant 的共享服务时，以下哪个说法是正确的？

A. vzAny 可以同时作为 Provider 和 Consumer
B. 如果 Contract 已用于 vzAny 的 provider，仍可用于 shared service
C. vzCPIf 需要在 Provider Tenant 导出 Contract，Consumer Tenant 添加 Contract Interface
D. Unenforced Policy 下无需任何 Contract 即可实现跨 Tenant 通信  

答案：C

解析：

• • A 错误：vzAny 作为 shared service 时只能作为 Consumer。
• • B 错误：Contract 如果已用于 vzAny provider，则不能再用于 shared service，二者冲突。
• • C 正确：这是配置 vzCPIf（跨租户合同接口）的标准操作流程。
• • D 错误：即使 VRF 内启用了 Unenforced Policy，跨 Tenant 通信也必须通过显式配置的 Contract Interface 来实现。

🚀 下一步学习建议

1. 动手实验：在 LAB 环境中实际配置 Standard、vzAny、vzCPIf 等各类 Contract，并使用 show zoning-rule 命令观察其规则生成和优先级的变化。
2. 深入 MO：利用 APIC 的 API Inspector 工具，追踪一次 Contract 配置从 GUI 点击到后台 MO 创建的完整链条，深化对 ACI 对象模型的理解。
3. 故障排查：模拟 Contract 配置错误（如忘记关联、Scope 过宽）导致的网络不通场景，练习使用 CLI 和 MO 查询命令定位问题根因。
4. 进阶主题：研究 Contract 如何与 L3out（外部网络连接）、Service Graph（服务链）等高级功能进行联动配置，构建更复杂的策略模型。

📌 记住：Contract 是 ACI 以应用为中心的安全模型的核心。透彻理解其层级结构（Contract → Subject → Filter）和底层部署机制（APIC → ObjectStore → TCAM/iptables），是掌握 ACI 策略控制精髓、高效运维数据中心网络的关键。如果你想就网络策略或系统架构进行更深入的探讨，可以访问云栈社区与更多技术同仁交流。