5.4 OpenFlow 与其他技术的集成
5.4 OpenFlow 与其他技术的集成
本节摘要：OpenFlow 很少单打独斗：Overlay 隧道（VXLAN/GRE）的封装封装在数据面由它执行、控制由它下发；与 VLAN 传统网络共存要处理编号与生成树的冲突；云平台（OpenStack 等）通过 SDN 控制器把网络抽象成 API；BGP 等传统协议则常在域间与它接力。本节逐条讲这些接缝的设计。
学习目标
阅读完本节，你应当能够：
- 说明 OpenFlow 在 Overlay 方案里承担的具体职责
- 设计 OpenFlow 域与传统 VLAN/BGP 网络的边界
- 描述云平台集成中各组件的分工
与 Overlay 隧道：手与脑的分工
VXLAN/GRE Overlay 里，OpenFlow 的分工非常清晰：
| 职责 | 承担者 | 用到的机制 |
|---|---|---|
| 隧道封装/解封装 | OpenFlow 交换机 | PUSH/POP 动作、SET_FIELD 写 VNI |
| 隧道目的地决策 | 控制器 | 虚机位置表 → Flow-Mod |
| 虚机生命周期事件 | 云平台 | 调用控制器北向 API |
OpenFlow 与周边技术的集成边界
与 VLAN 传统网络共存
三件事必须做在前面：
- VLAN 编号重规划：OpenFlow 域内使用的 VLAN 段与现网段隔离，或干脆用 metadata 替代 VLAN 做租户标识（数量不受 4094 限制）
- 生成树划界：混合边界交换机上生成树与流表的管辖范围要明确——流表条目优先级高于 STP 阻塞端口的默认行为时，可能绕过 STP 造成环路，边界处务必显式配 NO_FWD 或依赖 STP 拓扑约束
- MAC 学习对齐：传统交换机的 MAC 表与控制器的主机库会各自老化，迁移场景容易出现"一半通了另一半没通"的中间态，边界上设保守的老化时间并接受短暂不一致
与云平台集成
以 OpenStack 为例的标准接法：Neutron 的 ML2 机制驱动对接 SDN 控制器（OpenDaylight/ONOS 均有驱动），虚机的创建、迁移、删除事件经北向 API 通知控制器，控制器把这些事件翻译成流表变更。值得注意的是 OVS 这一层：计算节点的 OVS 既是 OpenFlow 交换机又是隧道端点，OpenFlow 流表同时承担本地虚机交换与远程隧道封装——解剖一台生产计算节点的流表，你会看到 2.3 节的多级流水线在真实世界的完整应用。
与 BGP 接力
运营商场景的常见拼法：域内（数据中心或城域）用 OpenFlow 做流级调度，域间用 BGP 通告可达性。控制器内置 BGP 扬声器（或外挂 BGP 守护进程），把内部虚机网段宣告出去，同时把学到的外部路由写进边界流表。域间保持标准协议、域内保持完全控制——这个切分兼顾了互操作性与灵活性。
⚠️ 常见坑：集成方案没有"单一事实源"。虚机位置既在云平台数据库又在控制器主机库又在流表里，三方不同步时网络行为随机。设计时明确谁写谁读，其他方只缓存。
动手：一条 VXLAN 封装流的解剖
Overlay 分工讲完，用解剖台把"手"的动作看清楚。目标：h1 的流量进隧道到远端 vtep。规则分两级——入口分类装桶、封装由流表动作完成：
# OVS 上以 VXLAN 建隧道端口（控制面由 ovsdb/控制器协作，此处手工） sudo ovs-vsctl add-port s1 vx0 -- set interface vx0 type=vxlan \ options:remote_ip=10.0.9.2 options:key=100 # 流表：命中 h1 的 IP 流，打上 VNI 并从隧道口出 sudo ovs-ofctl -O OpenFlow13 add-flow s1 \ "table=0,priority=300,ip,nw_src=10.0.0.1,actions=set_field:100->tun_id,output:vx0" # 内层才是 h1->h2 的 ICMP
抓包证据把三层分工钉死：vni 0x64（十进制 100）来自流表的 SET_FIELD，封装动作发生在交换机数据面，全程控制器只出过一条 Flow-Mod——所谓"封装在数据面、控制在控制器"，落到字节就是这样。排障时同样按层拆：外层 UDP 不通查 underlay 路由，外层通内层不通查 VNI 与流表匹配，内层单侧不通查对端解封装规则。VXLAN 之外的 GRE 场景只是隧道类型与 key 语义不同，方法论原样搬用。
Overlay 故障分层排查 { 外层 UDP 不通 -> 查 underlay 路由与 vtep 互访（ping 对端 physical IP） 外层通、内层不通 -> 查 VNI 是否一致、流表 match 是否命中（dump-flows 计数） 内层单侧不通 -> 查对端解封装规则与 MAC 表（tcpdump 分侧对比） 间歇性断 -> 查位置事实源是否分叉（云平台 vs 控制器对账） } → 每层用一个最小命令取证，不猜
集成的红线：单一事实源怎么守住
与云平台集成的技术路径不难，难在权限边界。位置信息（哪个虚机在哪个主机）只能有一个写者：通常约定为云平台管位置、SDN 控制器管转发，控制器订阅虚机迁移事件而不是反向去查。违规的典型症状是虚机热迁移后间歇性失联——两套系统对"虚机在哪"各有答案，流表按旧答案铺，ARP 按新答案回。治理手段说穿了很朴素：接口层面只留一条事件订阅通道，删掉一切旁路查询；审计层面对账脚本定期比对两边的位置表。集成的失败很少在协议，几乎都在"谁说了算"没写清楚。
集成话题收尾处补一个实用的优先级建议：四种集成里，与 Overlay 隧道的集成最成熟、收益最直接，应作为第一个落地项；与 VLAN 共存次之，多为改造过渡期需求；云平台集成投入最大，应等团队对控制器与流表的掌控过关后再启动；BGP 接力则基本只出现在多域规模场景，中小环境可以无限期推迟。集成路线图按这个顺序排，每一步的收益都能支撑下一步的投入，反过来按宣传热度选型（先上云平台集成）的团队，多半会卡在第 3 章 3.2 节讲过的能力差异细节上。
本节要点回顾
- Overlay 分工：封装在交换机（PUSH/SET_FIELD）、控制归控制器、生命周期归云平台
- VLAN 共存三件事：编号重规划、生成树划界、MAC 老化对齐
- 云平台接法：北向 API + 计算节点 OVS 双角色
- BGP 接力：域间标准协议、域内完全控制
- 单一事实源：位置信息只允许一个写者
部署之后，安全与管理是最后的必修课——进入第 6 章。