路由协议和架构/软件定义网络简介
互联网仍然是30年前定义的那样：一个非常高效的管道，以高速传输比特，几乎使用相同的协议和相同的理念。
网络设备是整体式的：每个路由器除了包含用于报文转发的专用硬件外，还包含自己的操作系统和自己的应用程序。这种基础设施对创新封闭：客户无法安装软件组件，而是由硬件制造商设置，而硬件制造商如果已经是市场领导者（例如思科），则对创新不感兴趣。
软件定义网络（SDN）引入了对网络进行编程的可能性，它基于三个支柱
- 控制和转发功能分离：软件，智能组件，与硬件分离；
- 控制集中化：整个网络由一个控制器协调，它由一个网络操作系统和用户定义的网络应用程序（例如路由协议、负载均衡器、防火墙）组成；
- 定义明确的接口:
- 北向：网络操作系统向网络应用程序公开API；
- 南向：网络操作系统驱动网络节点，网络节点由简单的报文转发硬件组成。
网络操作系统是一个软件层，它为上层应用程序提供网络的全局抽象视图。从网络“上方”的视图可以实现例如流量工程：决策由负载均衡器的集中逻辑做出，因此对所有网络节点都一致
- 主动模式：在设备开始转发报文之前，控制器先验地用所有会话所需的规则填充转发表；
- 被动模式：当会话中的第一个报文到达时，设备将其发送给控制器，控制器做出决策并通知设备该会话中转发报文所需的规则。
一个网络切片层可以向软件显示一个与实际物理基础设施不同的网络拓扑：它可以配置为向每个系统操作实例显示不同的虚拟拓扑（例如实际链路的子集）→ 某个公司的流量策略只影响属于该公司的网络部分。
- 问题
- 控制器：它可能构成单点故障和瓶颈；
- 通用性：防火墙需要检查所有报文，不仅仅是会话中的第一个报文→ 设备和控制器之间会产生大量流量；
- 可扩展性：为了获得高性能，转发硬件不能太简单；
- 经济：硬件简化有悖于主要网络供应商的经济利益。
OpenFlow，在2008年左右推出，是南向接口的实现。
它可以以多种方式部署
- 规则：它们通常是基于流的，也就是说，根据（MAC 地址、IP 地址、TCP 端口）元组定义；
- 控制器：它通常是物理集中式的，但它甚至可以是物理分布式的（即使仍然是逻辑集中式的）；
- 模式：它通常是被动的，但没有什么可以阻止使用主动模式。
一个或多个操作与每个规则相关联，例如
- 将报文转发到端口(s)；
- 封装并转发到控制器；
- 丢弃报文；
- 发送到正常的处理管道（即经典路由表）；
- 修改字段（例如 NAT：更改地址和端口）。
- OpenFlow 1.3
它引入了一些有趣的功能
- 转发表被分成多个子表（例如防火墙、路由等），每个应用程序访问其子表→ 每个报文在表中按顺序进行多次匹配；
- 虚拟交换机（vSwitch，例如 Open vSwitch）：它不是在硬件中实现，而是在由软件进程模拟的交换机上运行→ 在两个不同服务器上的两个 vSwitch 之间可以创建 GRE 逻辑隧道，穿过传统的交换机网络：
#网络功能虚拟化.
- 问题
- 数据平面：它只处理报文转发→ 它适合于报文转发是相对于数据平面来说占主导地位的环境（例如数据中心），但它似乎不适合 ISP 网络；
- 实用性：南向接口不像北向接口那样有趣：它由网络操作系统开发者使用，而不是由应用程序开发者使用；
- 硬件成本：规则可以基于大量的字段，这使得条目非常宽→ 所需的 TCAM 昂贵且发热量大；
- 灵活性：与开放网络基金会 (ONF)（VMware）相比，OpenDaylight 项目（思科）更喜欢网络配置协议（NETCONF），它不会明确地制定规则，而是不知道读取或设置的值的语义→ 它可以被 SDN 控制器用来配置设备上的一些高级功能，例如 ISP 网络上检测到故障为严重时使用的“备份路由”。
不仅要将报文转发到正确的方向，还要提供面向数据平面的服务，这些服务处理报文（例如防火墙、NAT、网络监控器）。
如今，服务可以添加到接入路由器 (BNG)，也可以通过服务卡添加，方法是连接称为设备的盒子：一个设备是一个独立的离散硬件设备，具有集成软件（固件），专门用于提供特定服务。设备通过物理线缆串联连接，形成一个静态服务链，每个报文必须经过所有服务才能退出设备。
- 缺点
- 敏捷性 在供应新服务方面：设备应该与设备物理连接；
- 灵活性：为了连接一个新的设备，链需要暂时断开，停止网络服务；
- 可靠性：有故障的设备会断开链，停止网络服务；
- 优化：每个设备都具有固定的可用资源，在工作高峰期间，它无法利用此时可能由另一个设备释放的资源。
每个设备都连接到 OpenFlow 交换机的输出端口和输入端口，流量通过动态确定的服务链，服务链通过定义从交换机端口到另一个端口的路径的 OpenFlow 规则来决定。
- 优点
- 灵活性: 添加新设备需要 SDN 控制器在不停止网络服务的情况下动态更改 OpenFlow 规则；
- 可靠性: SDN 控制器对 OpenFlow 规则的动态更改足以恢复网络服务；
- 业务: 路径可以根据客户（公司）进行区分→流量只经过客户购买的服务。
- 缺点
- 敏捷性 在供应新服务方面：设备应该与设备物理连接；
- 优化: 每个设备都有固定数量的可用资源，在工作高峰期，它无法利用此时其他设备可能留出的空闲资源；
- 向后兼容性: 设备应更换为支持 OpenFlow 的交换机。
服务在纯软件流程中实现：交换机连接到在多个远程服务器上模拟的 OpenFlow vSwitches，每个服务器都有一个能够运行 **虚拟机** (VM) 的虚拟机管理程序，服务在其中运行。
- 扩展
服务性能可以通过三种方式增强
- **垂直扩展**：为 VM 分配更多硬件资源→如果服务无法适当地 利用可用硬件（例如，单线程程序从多线程环境中获益不多），这可能还不够；
- **水平扩展**：多个 VM 在同一台物理服务器上并行运行→需要一个 负载均衡器 将流量发送到负载最轻的 VM，VM 需要 同步；
- 多台服务器: 多个 VM 在多台物理服务器上并行运行→需要另一个负载均衡器将流量发送到负载最轻的服务器。
- 优点
- 敏捷性 在配置新服务方面：可以通过下载和启动软件映像来动态启用新服务；
- 优化: 服务器硬件资源在 VM 之间共享；
- 向后兼容性: 如果交换机不支持 OpenFlow，则可以在不更换设备的情况下利用 vSwitches 之间的 GRE 隧道；
- 整合: 晚上可以减少并行运行的 VM 数量（**缩减**）并减少分配的硬件资源（**缩减**）。
- 缺点
- 流量: 经典的 NFV 模型可能需要数据包在服务器之间跨交换机传输，从而阻塞服务器所在的网络；
- 效率: 服务器使用通用 CPU，而不是专用硬件（例如线路卡），并且目前尚无有效的硬件加速技术；
- 迁移: 当用户移动时，VM 实例应移动到最近的服务器，并应尽快启动；
- 可扩展性: 该架构具有很高的可扩展性潜力，但在多个服务实例并行运行时，会遇到同步和负载均衡问题。
**OpenStack**，于 2010 年推出，是一个开源的分布式操作系统
- Linux
- 它处理它运行的 单个本地 主机；
- 进程 是执行单元；
- OpenStack
- 它运行在称为 **控制器节点** 的 远程服务器 上；
- 它处理云中的 多个分布式 物理服务器，称为 **计算节点**；
- 虚拟机 是执行单元。
每个 **计算节点** 包括以下组件
- 传统操作系统: 它处理物理服务器上的本地硬件；
- 代理: 它接收来自控制器节点的命令，例如启动 VM；
- vSwitch（例如 Open vSwitch）：它将服务器连接到网络基础设施。
**控制器节点** 的一项任务是在当前负载最轻的计算节点上启动 VM。