Truman Boyes零与一

存档 · 路由 · 近况

在 SDN 中传统协议仍然重要

作者：Truman Boyes · · 6 分钟阅读

首先，我已经说了一年多了：我们早就一直在做 SDN。作为整个行业，我们一直在把变更写进网络，按照我们自己的设想，决定何时何地发生，并做一些协议本身通常不提供的事。

说实话，几乎所有协议（OSPF、IS‑IS、RIP、MP‑BGP 等）只干一件事：它们广播向量，或者说目的地的可达性。有些协议做得更好，有些协议还能携带更多信息，比如标签、社区、目标等。然后你在路由节点上加上一层逻辑来解释收到的路由数据，进而做决定。还记得策略路由（PBR）吗？这和 SDN 有什么区别？我敢说，SDN 为实现 8‑10 年前在 PBR 讨论中提出的很多想法提供了可能。

我花了很多时间沉浸在 SDN 实现、演示、厂商会议，甚至直接写代码的工作中。当你想要对网络进行变更时，需要先问几个基本问题：

  • 这次网络变更需要动态进行吗？
  • 动态到底指什么？是每天、每周，还是完全灵活、非确定性的方式（比如用户随时点按钮就会改变网络）？
  • 我们有工具可以防止出现糟糕的情况吗？（想象一下，如果你允许在网络中动态创建 MPLS LSP，若不为 RSVP‑TE 对象设定安全上限，或者不限制路径数量，会发生什么？）
  • 这个“简单程序”会有多复杂？

协议都有状态机；它们学习并分发信息，拥有明确的例程和清晰的行为实现。这点对大多数由 IETF 定义、被广泛使用的路由协议都适用。此外，人们已经学会如何使用这些协议，而对那些允许扩展功能的协议，几乎可以用灵活的框架实现任何你想做的事。比如：IS‑IS TLV 或全新的 BGP SAFI / NLRI / GENAPP。

网络软件行业已经向开发者和运营者提供了大量资源。我们想要以编程方式进行配置更改并在节点上执行“show 命令”，可以使用任何现代编程语言（PERL、Python、Ruby 等）的 Expect 库，或使用 NETCONF、RESTAPI、YANG、OpenFlow 协议或 SNMP 等替代数据模型。

于是，选择越多，复杂性导致的瘫痪感也越强。我们以 CLOUD 为例，考虑网络拓扑和自动化的灵活性需求。在一个非常简单的场景中，云环境中的每个租户都需要基本的网络隔离和路由。在企业云中，这通常表现为带有 DHCP 分配的 VLAN。如果虚拟机（VM）与网络的关联能够灵活，云管理系统就能很好地工作；因此，让 VLAN 的创建能够自动化就显得很有用。

在 OpenStack 中，这可以通过 nova‑network 实现；如果你使用 Linux 桥接，它会乐意在内核中创建新的 VLAN、IP 地址和桥接实例。自动化的挑战在于，实际情况往往更复杂——还有超管之外的流量入口和出口。可能涉及 VRF 接口绑定、ToR 上的 VLAN 创建，或 ToR 以及其他第 2/3 层设备上的安全策略，这些都会处理新实例网络的帧/包。

当然，Quantum 是一个可以动态创建资源的有用组件。我们甚至可以让 Quantum 驱动 RESTAPI 与 OpenFlow 控制器交互，或让 Quantum 直接对上游设备或 ToR 进行更改。但这会让事情变得非常复杂，因为我们已经决定了有多种方式在网络中传播变更事件。

说到网络，就有一套科学。信息分发有约定的方法，数据格式也有共识。许多协议在 IETF 经过审查，但厂商在实现时各有解读，随后厂商要么在 IETF 内争论，要么在消费市场的压力下修正代码，实现互操作。互操作对消费者有利，从长远来看，如果厂商想通过良好口碑和升级策略赢得客户，也对厂商有好处。

今天，在网络技术领域，我有很多方式来构建云网络。我可以完全拥抱覆盖网络阵营，做类似下面的事情：

  • 构建高度可扩展的第 3 层数据中心网络结构
  • 在每个 hypervisor 上安装最前沿的桥接和隧道软件（OVS 或类似的）
  • 预先搭建好所有面向公网的网络结构

现在，这整套软件网络可能确实能够运行；但想象一下它失灵时的情形。在网络故障的场景里，我们必须从某一层开始排查。先检查哪一层？问题是出在 hypervisor 之间的传输吗？如果是，这到底是传输本身的问题，还是隧道封装或 hypervisor 上的传输问题？ToR 上是否必须使用 VLAN？ToR 在与其他 ToR 之间的路由是否正确？

我认为需要提出的观点是：软件中的网络控制复杂性必须与现有行为非常相似，或者必须对其预期行为有极其透明的说明。这正是协议能带来的价值：它们不是黑箱；你可以阅读它们的工作原理，并且很快就能明白为什么某件事在工作或不工作。

前几天我和 BGP 的一位创建者讨论过这件事；我对他说：“我可以随便找个人，让他展示两套系统之间的 RIB‑OUT 和 RIB‑IN，就能得到真相；对我而言，BGP 就是事实”。是的，我相信一些定义明确的 XML‑RPC 或 REST 接口；但我真正喜欢 BGP 以及其他定义明确的协议，是因为它们有清晰的定义和行为。当然，当你涉及到复杂的 VPN 拓扑、在一系列表之间泄漏 Route Target 时，会提供足够的绳子让你把自己吊起来。但这正是把这样一种工具放在工具箱里的乐趣所在。你可以自由地构建极其复杂或易于理解的网络结构。

回到前面提到的想法；在云网络里，我们通常需要为每个租户创建一个 VLAN；但如果在虚拟机管理程序之外自动化这件事太复杂，我们可能会直接在 ToR 和 L2 基础设施上预先构建好所有 VLAN。不过，这种做法的缺点是可能会产生低效的二层域。更好的办法是让MVRP 在虚拟机管理程序上的虚拟交换机与 ToR 之间运行。通过 MVRP，OpenStack 的 Quantum 或 OVS 可以简单地向交换机通告 VLAN 的存在，二层域就会在直接相连的 ToR 上动态编程。

总的来说，我觉得为主机和网络节点之间的连接创建新模型很令人兴奋；但我们必须确保有足够的简单性或“真相节点”。应该有权威的可达性真相来源，在过去 30 年里，这体现在两个地方：RIB 和 FIB。当我们进入拥有自己状态、控制和抽象概念的新领域时，就需要一种方式来监控这种新行为。这并不是全新的概念；如今即使在网络领域，我们也很少看到光传输层（DWDM、SDH/SONET 等）和二层/三层的真正混合，但仍需记住，从互联网中仍有大量关于规模的经验可学。MP‑BGP、路由反射器、路由目标、NETCONF 等工具在 OpenFlow、Quantum 插件以及新 Linux Kernel 模块的世界中仍然非常有用。未来就在现在，过去也很重要。

comments

Originally published on truman.net. See the archived copy.