【阅读原文】戳：深度解读阿里云数据中心自研网络引擎文/黄一元、朱芳波从2018年投入第一代软硬件全自研交换机研发至今，阿里巴巴的自研网络硬件已覆盖并规模部署到阿里云的整个网络，成为了整个网络的基础。01 一切为了规模规模，是互联网数据中心和传统数据中心的最大区别，因此，通常会把这类互联网、云计算数据中心称作超大规模数据中心——hyperscale data center。阿里云在全球28个地域的86个可用区里运营着上百座数据中心，每个数据中心能够容纳几万台到十几万台服务器。庞大的数量催生了“三大规模”挑战：超大规模接入、超大规模运营、超大规模演进。超大规模接入白盒交换机胜任超大规模接入。第一，Scale Out理念和CLOS架构为硬件白盒化奠定了架构基础。Scale Out理念利用横向扩展来增加网络的接入能力，而不是一味增加单台设备的端口数量。CLOS架构则很好的贯彻了Scale Out的理念。这种网络架构能够用小规模、低成本的设备，构建大规模的网络，成为超大规模数据中心的事实架构标准。图 | Scale up vs Scale Out这样的背景下，盒式交换机终于有了用武之地，盒式交换机的设计复杂度相比传统的框式交换机要低，这就为硬件白盒化奠定了架构基础。第二，SDN让封闭系统变成开放系统。传统的数据中心交换机多为复杂的框式交换机，并且数据面、控制、管理完全由设备厂家控制，是一个封闭的系统。SDN的核心思想之一是开放和解耦，通过解耦把单个厂商封闭系统变成一个开放的系统。最具代表性的成果是商业化交换机芯片逐渐占据数据中心网络市场的主导地位，开源组织和开源软件也如雨后春笋般出现。白盒交换机有了架构的基础，也有了芯片基础。最后，不得不提的是SONiC这个交换机开放操作系统。由微软首先倡导，阿里巴巴主力推动的开源SONiC已经成为交换机开源操作系统的事实标准。至此，白盒交换机俨然成为了大规模数据中心的天选之子。超大规模运营白盒交换机解决超大规模网络的运营问题。传统网络的运营，类似于人工驾驶，每个运营人员就像驾驶员，需要操控好自己的车子，以应对突发路况，而当我们的交通网越来越大时，单纯依靠驾驶员自身的能力将无法达到最佳效率。超大规模网络的运营，类似于大交通网下的自动驾驶，通过为全网交换机赋予丰富的监控能力，再通过对大量数据的智能分析和集中处理能力，能够大幅提升超大规模网络的运营效率。超大规模演进白盒化帮助实现超大规模架构的快速部署和迭代，从更高的维度实现性能和成本的最优解。在依赖商业交换机的时代，整个网络的演进受限于厂家的方案，用户需求真正体现到设备厂家会存在迟滞；除此之外，在成本上，传统网络成本的降低，依赖于三方竞价等手段来降低单设备的成本，而白盒赋予其在更高维度上的成本优化方式。快速变化的业务驱动下，用户可第一时间享受到新芯片、新架构的红利，且能够形成长期稳定的架构演进方案，从而实现整体网络成本的降低。图 | 网络成本02自研之路起步与选择阿里巴巴基于全自研交换机的网络架构始于2018年。彼时100G模块已成为成熟的方案，商业12.8T交换芯片也刚刚出世，25G网卡的服务器也开始规模上线。在这样的背景下，有个最为恰当的选择：利用12.8T单芯片打造128个100G端口的交换机，从而实现网络性能、成本双赢。这里有必要做一些背景介绍。在三层CLOS架构下，整个网络能够接入网卡和服务器的数量，也就是我们所说的集群规模，取决于单台交换机的端口数量。图 | 集群规模-端口数量而交换机的单端口带宽则反映了业务对于带宽的需求。以12.8T交换芯片为例，基于单芯片的交换机可以设计成128x100G端口，或者32个400G端口。对于后者来说，带宽提升了但同时牺牲了接入的规模。而交换机的端口形态也决定了使用哪种光模块。因此，业务的需求，最终反映到了网络的架构和交换机端口形态的选择上。图 | 网络架构的平衡北美的四大互联网中也有出于对高带宽的需求，同时为了兼顾集群规模，而采用多个盒式交换机互连来形成一个逻辑上的大带宽多端口的Leaf/Spine交换机，并且一直延续这样的架构。其带来的影响是相比单芯片的盒式交换机组网方案，互连复杂度增加，同时互连跳数增加导致时延增加。基于当时自身的需求和产业链状况，阿里巴巴选择了一条最为适合自己、最为简洁的单芯片交换机方案。200G还是400G2019年底，在第一代架构规模上线之时，阿里云开始规划下一代的网络方案。此时25.6T交换芯片呼之欲出。走400G网络还是走200G网络成了争论的焦点。当时，一些北美互联网公司规划了800G/400G的互连方案，从技术上看，在光互连技术上确实领先业界。但是400G在可预见的几年内还不能达到较好的性价比；另一方面，基于25.6T芯片做400G端口的交换机，端口数量相比200G减少一半，整体的集群规模会降至200G网络的1/4，这是更为致命的一个问题。网络架构基于单芯片交换机这一方案不会轻易动摇。权衡利弊之后，阿里云选择了200G路线：既能保证架构和带宽平滑演进，又能保持集群规模，选择这一路线带来的挑战是需要驱动产业链去为200G的模块做好准备。从这一代开始，阿里云开始了自己的集群架构和交换机的演进之路。未来已来商业芯片还在按照既定的2年一代的节奏进行升级，51.2T芯片已跃出水面，真正的400G时代即将到来。对业务规划的深入理解、对产业的清晰认知和影响、对架构演进的合理规划，让阿里云比四年前更有自信。图 | 磐久数据中心自研交换机全链路自动化过去很长的时间里，网络设备的管理和运维都是以人手动为主，网络配置采用命令行，网络故障发现需要靠人肉通过Ping、Traceroute等基本工具来进行。阿里的每个大型数据中心都有几千台的交换机，依靠人来手工运维是不现实的。阿里云的数据中心网络利用软硬件自主可控，实现了运营的自动化和智能化。自动化运营包括很多方面，从最开始的自动化架构验证，到自动化的规模部署，再到自动化的新功能发布、软件版本升级，以及故障的自动化发现、隔离和恢复等。与厂商的封闭设备不同，阿里通过软硬件自研实现自主可控，从头打造了适合大规模运营的部署能力、监控能力、排障能力、升级能力等等。大规模自动化运营水到渠成，支撑规模运营的思想贯穿着交换机的整个生命周期。图 | 全链路自动化第二大脑从第一代自研交换机开始，阿里就将BMC引入到了交换机中，作为交换机的第二大脑。传统的交换机内，CPU负责了所有的控制和管理任务，一旦CPU出现问题，设备就会失联，也很难对故障进行追溯，故障的恢复也需要依赖人工干预。BMC的引入，将设备的管理任务搬到了BMC，CPU则专注于交换芯片的控制：在CPU挂死时，BMC能主动获取CPU的故障信息，同时结合设备上的实时传感器监控数据对故障过程和原因进行排查、分析；同时，BMC还能对CPU和设备进行恢复，避免了人工干预。图 | AliBMC第二生命线除了主架构交换机，阿里还将带外网络进行了全面的自研化改造。带外交换机和串口服务器是网络的第二道生命线，当带内出现问题时，往往要依赖于带外通道对故障进行排查和恢复。长期以来带外并未受到足够重视，供应、成本、稳定性这些都是老大难的问题。同时，主架构交换机自研的理念也带到了带外，除了解决供应、成本、稳定性这三大问题，也将自动化能力和丰富的运维特性带给了带外，极大提高了整个网络运营的效率。在规模部署和运营上，另一个不得不提的是“自研交换机+DAC的整机柜一体化方案”，该方案极大提升了交换机和服务器互连的稳定性，提升了建设和运营效率，关于这个主题，我们接下来会有单独的一篇文章去详细介绍。03生态的力量传统设备厂商设计一款交换机，需要有非常大的投入和很长的周期。对云计算厂商来说，效率是非常重要的。解法是什么？那就是——生态的力量。S³IP-网络标准化新引擎打造生态，推动生态，合作共赢，让白盒交换机的开发和集成更为简单。这也是阿里云在2020年推动发起S³IP的初衷和主旨。今天的S³IP，联合了国内几乎所有的头部互联网厂家，也吸引了业内主要的白盒交换机ODM厂家、商业芯片厂家。阿里云是如何打造网络标准化新引擎的呢？●  因为白盒交换机底层驱动向上接口的差异，造成了不同交换机需要投入重复的集成工作，为此阿里云提出了驱动接口标准化sysfs。●  因为交换机平台测试上存在的差异化，阿里云提出了平台测试标准化PIT。●  因为厂家SONiC系统和用户环境及需求存在的差异，阿里云提出了D4OS这一标准化的厂家出货的OS，不仅解决了统一的问题，同时也为D4OS植入了支持交换机大规模部署的程序，使得厂家OS能够无缝对接用户。●  在硬件层面，为了支持软件和系统更好地集成，从功能层面提出了硬件系统的基础能力需求。●  对于核心的CPU模组进行了标准化，统一了用户的需求，让用户和ODM的研发效率大大提升。可以说，S³IP从最朴素的想法出发，从点到面，已逐步构建了一个国内白盒交换机领域的标准体系。图 | S³IP今天，S³IP生态已吸引了7家头部互联网公司、1家运营商伙伴、10家交换机领域的系统厂家，7家芯片公司的加入，目前，已经贡献超过2万+行代码供生态伙伴使用，超过30款系统按照S³IP标准进行适配。S³IP当前的标准化覆盖了白盒交换机底层硬件、底层软件、平台测试，正在向芯片标准化进发。S³IP在扎根国内的同时，也不忘输出影响力到国际上。去年，S³IP将PIT/Sysfs推到了SONiC社区，PIT/Sysfs HLD PR已获通过；在未来网卡和交换机融合的新领域，S³IP也会和DASH社区保持紧密沟通。图 | S³IP-SONiCQSFP112除了S³IP这一白盒标准化组织，阿里在交换机端口的标准化上也进行了持续的推动和贡献，主导发起了QSFP112 MSA组织。阿里的网络架构，决定了在交换机设备上会持续走单芯片128端口的路线。结合交换芯片从25.6G到51.2G，再到102.4T的演进路线，阿里的交换机端口会长期使用4个lane的方案。简单来说，就是一个端口由四个高速串行电信号组成。当串行电信号的速率为25G，单个端口速率为100G，这就是业界现有的QSFP28标准。串行电信号的速率为50G，单个端口速率为200G，业界标准就是QSFP56标准。当确定了长期的架构方案后，我们发现：当串行电信号的速率达到112G的时候，也就是单端口400G的时候，业界还没有这样的标准（很大一部分原因是由于北美四大互联网的网络和交换机路线和我们存在差异，他们走的是单端口8个或16个高速串行信号的方案）。这便驱动了阿里云在2021年率先发起QSFP112标准。使得整个产业链为400G时代做好了准备，也为未来QSFP224标准打下了坚实的基础。图 | QSFP11204总结展望阿里的白盒交换机自研赶上了云计算快速发展的年代。经过多年的实战检验，阿里在白盒交换机领域积累了丰富的经验。归根到底，软硬件自研服务的是阿里整个网络架构的平滑和快速迭代，降低单位带宽的成本；同时，软硬件自研服务也为阿里的大规模自动化运营提供了基础。随着处理器和存储能力不断升级，AI等新应用的兴起，网络的性能变得愈加重要。在这样的背景下，阿里提出了“可预期网络”的理念。“可预期网络”的核心，是通过端和网的协同与融合，保证网络的带宽和延迟，这一思想的前提，是需要端侧和网侧的透明，而交换机的自主可控是这个思想的基础之一。和传统的计算不同，AI和智算有着特殊的流量模型，all-reduce的算法使得网络更容易出现Incast，而任务本身对于Incast造成的拥塞也更为敏感。新形势下，我们的AI网络如何搭建和优化？我们的自研交换机怎样配合新的网络架构去支持新的业务场景？这些都是阿里云“可预期网络”目前需要思考的问题。“可预期网络”的目标和新兴的智算业务，驱动着自研交换机的未来发展。我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。欢迎关注 “阿里云基础设施”同名微信、微博、知乎获取关于我们的更多信息~

阿里云专有网络 VPC 产品是基于软件定义网络的技术实现的，具备什么特点？

云计算ACP认证练习题： （多选）阿里云专有网络VPC 产品是基于软件定义网络的技术实现的，具备（）特点？ A. 无需购买硬件网络设备可以实现基本的网络设置 B. 可以按需配置网络设置 C. 网络访问控制规则固定，不能进行灵活的配置 D. 管理操作及配置实时生效

开发者学堂课程【ACP 云计算节选课程 ：弹性计算 ECS02-ECS 的组件】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1222/detail/18297弹性计算 ECS02-ECS 的组件 内容介绍一、ECS 的组成与功能二、ECS 的优势 一、ECS 的组成与功能1、基本组件在创建 ECS 的时候必须包含一些组件。（1）实例实例就等同于一台虚拟的服务站中包含了 CPU 内存，超多系统网络配置等等这些基础的计算组件。（2）磁盘和快照快照就是某一个时间点一块云盘或者是共享块存储的一个数据状态文件，这个常用于数据备份、数据恢复以及制作资金定向。（3）镜像镜像是提供实例的超多系统初始化应用数据以及预装的软件等等。（4）虚拟专有网络第一个是专有网络 VPC，第二个是绑定在专有网络 VPC 之上的 EIP 弹性功能 IP。专有网络其实是一个逻辑上彻底隔离的云上的试用网络，之后会有专门的章节讲述专有网络 VPC。（5）安全组其实是一种虚拟的防火墙，是用于设置实例的网络访问控制。（6）地域和可用区地域是相当于整个湖北省，湖北省内包含了许多城市，比如武汉、荆州等等都属于是在同一个地域内的不同的可用区。但是每个地域是完全独立的，不同的地域的可用区之间也是完全隔离的，但是同一个地域内的可用区之间使用低事业的链路是相连的。刚对这些组件有了基本的了解之后，再来看如何整合，如何去根据自身的需求选择。2、组件选择方法（1）实例规格第一种是共享型，第二种是通用型。共享型又称之为入门级实例，通用型又称之为企业级实例。在次看一下二者之间的区别。共享型又分为共享标准和突发性能两种。通用型分成很多种实例规格，其中分别是通用型、计算型、内存型、大数据型等等，都是比较针对性的，可以根据自己的需求去选择。入门级服务器和企业级服务器本质的区别其实就在于一个是为个人用户，一个是为企业用户提供云服务。入门级云服务器主要是面向个人和普通企业用户，企业级云服务器主要是面向大型企业级用户。刚才讲到入门级实例和企业级实例之间的一个本质的区别，对于企业规格的挑选有了一定的了解之后再来看系统盘和系统镜像的选择。（2）系统盘和系统镜像首先系统盘是必不可少的，家用的电脑也都配有，所以是 ECS 的必选组件。系统盘的大小可以根据自己的需求去选择。 其实阿里云服务器的超多系统就是通过系统镜像来安装的，比如要安装 Window 和 Linux 操作系统的话，就需要选择对应的系统镜像，所以系统镜像也是必不可少的。所了解到系统盘和操作系统之后再来看其他的组件。（3）磁盘、快照和自定义镜像磁盘就称之为系统盘和数据盘，二者都叫做磁盘。磁盘也可以叫做块存储。快照就是磁盘数据在某一个时间点上面的一个拷贝，就像拍照一样保留某一个时间点上的数据状态，作为一个备份或者是制作下面的自定义镜像。如果要大规模地复制同一个云服务器，对此不适用镜像而要一排排地配置就需要浪费大量的时间，这个时候就可以通过自定义镜像去制作，在短时间内就可以部署多台云服务器。（4）专有网络专有网络 VPC 基于软件定义网络（SDN）和隧道技术（Tunneling），为用户建立隔离的、可自定义的虚拟专有网络。功能：①提供 VLAN 级别的安全隔离，也就是不同的专有网络是在二重逻辑隔离的。②用户可以在自己创建的互联网之内去创建和管理其他的云产品实例。也就是在整个 VPC 的专用网络系列之下是不能在没有允许的情况下对内网进行随意访问的。③用户基于阿里云创建的自定义试用网络是可以完全掌控的，比如选择 IP 地址的范围还有包括配置的落入表和网关，这些都可以是自行配置的。④就是还可以通过专项 VPN 网关和高速通道将自己的专运网络连接到其他的专有网络或者是本地网络，形成一个按需定制的网络环境。专有网络之间在逻辑上是完全隔离的，所以如果想实现通讯，可以通过专线，可以通过 VPN 网关或者是云企业网去把它打通。方才所说的是云服务器必备的组件以及它的网络环境。（5）安全组①基本介绍不管用什么产品，都要离不开安全。安全组作为 ECS 必不可少的安全特象，看一下它的使用规则。安全组是一个虚拟的防火墙，它是用于设置单台或多台云服务器的网络访问控制，就相当于网络当中的一个访问控制列表。它属于云服务器重要的网络安全隔离的手段，主要是在云端划分安全域档。②安全组规则在这里需要注意的是每个实例至少属于一个安全组，否则是无法创建成功的。所以在创建的时候就需要去指定。可以通过添加安全组的规则允许或者是禁止安全组内的 ECS 对公网或是私网的访问。但是有个前提条件是添加安全组规则之前已经规划好了 ECS 实例需要禁止哪些公网或是私网的访问。为了安全起见安全植入方向大多采用的是拒绝访问策略的，这个时候就需要把允许访问的 IP 加入到安全组中。安全组的规则是由原 IP 地址或者是安全组的协议、端口、策略、网络类型组成的。 这是一个非常完整的安全组的规则，可以看到原安全组是在对面，因为它是一个入方向的，所以是 sg-002。这个协议采用的是 TCP 协议，端口号可以看到。策略写的是接收，网络类型是企业内部网络。③安全组实践在知道安全组规则之后，再来看如何配置它以及过程中的注意事项有哪些。第一个就是白名单而不是黑名单，为了安全起见建议将安全组作为白名单使用，就是默认拒绝所谓的访问，只添加所需要的 IP 地址和授权端口就可以。第二个就是“最小授权”原则，就是建议添加存储规格的时候遵循“最小授权”原则，比如开放端口作为远程登录的时候，建议只允许特定的 IP 地址访问，而不是所有的 IP 地址。第三个就是不同类型的应用实例使用不同的安全组，就是不同类型应用的实例加入到不同的安全组，分别运维去管理。第四点就是尽可能地保持单个安全组的规则简洁，就是单排实例加入到多个安全组中，单个安全组也可以加入多个安全组的规则。但是如果应用在单排实例上的安全组规则过多的时候，就会增加管理的负担，并且引入不该有的风险，所以这个也是不建议的。第五点就是不随意更新安全组的规则，建议不要修改线上环境使用的安全组，修改安全组设置会自动应用到组内其他的实例上，需要先克隆一个安全组并且在测试的环境中去调试，确保修改后实例之间仍旧能正常通讯再进行修改。最后一点就是不需要公网访问的资源，不提供公网 IP，以免浪费资源。刚才所介绍的是使用安全组时需要注意的事项，再来看地域和可用区的概念。（6）地域和可用区刚刚提到每个地域是完全独立的，不同的地域的可用区之间也是完全独立的。例如地域1和地域2，不同的地域之间是完全独立的，不同地域的可用区之间也是完全隔离的。但是相同地域的可用区A、可用区B和可用区C之间是采用的低演示链路去相连的，是可以互通的。需要注意的是在资源创建成功之后不能更改可用区，也不能够更改地域，所以在规划的时候一定要规划好。（7）弹性网卡弹性网卡其实是一个虚拟的网络接口，需要绑定到专有网络 VPC 之上才能够去使用。①类型弹性网卡的类型有分成两种，分别是主网卡和辅助网卡。主网卡是随着实例一起创建的，生命周期是与实例保持一致的，不支持从实例上解绑。辅助网卡是可以单独创建，支持自由地绑定到实例上或者是从实例上的解绑。②属性弹性网卡分为四个部分，第一是私有的 IP 地址，这是由实例一同创建的，是由实例去确定的。第二的 MAC 地址是全局唯一视弹性网卡的标识。第三是安全组，就是至少要加入到安全组中，一个弹性网卡至少要加入到安全组中，由安全组来控制进出弹性网卡的流量。网卡的名字也是只能有一个，相当于自己的名字一样。刚才所讲的是创建 ECS 必不可少的组件，再来看 ECS 的优势。 二、ECS 的优势总共分成稳定、弹性、安全、成本、易用性和可扩展性。最明显的优势是它可以自动宕机迁移。当一个 ECS 实例所在的物理机(NC)宕机时，ECS 系统将自动启动宕机迁移过程，即将此物理机上运行的云服务器都迁移到其他物理机上。举例说明： 就是在华东1（杭州）这个地域内的一个可用区中的物理机宕机之后，就会将实例 i-001迁移到同一个地域内的其他的物理机上面。这个过程持续的时间是5~10分钟。如果对可用性有更高的要求，就可以使用其他的云产品 SLB 负载均衡到多个 ECS 实例上面，就可以做到跨可用区的容载机制。刚才所介绍的是创建 ECS 所要用到的组件和它的一些基本概念，包括 ECS 的优势。现在就介绍 ECS 的使用方法包括如何创建 ECS 和它的一些部署。

写在前面嗯,今天和小伙伴们分享一些 firewall 的笔记内容涉及：zone 的介绍具和具体规则的添加服务，端口和协议，ICMP 阻塞，SNAT/DNAT,IP伪装，端口转发等Demofirewall 离线命令(服务未启动规则预设方式)理解不足小伙伴帮忙指正 傍晚时分，你坐在屋檐下，看着天慢慢地黑下去，心里寂寞而凄凉，感到自己的生命被剥夺了。当时我是个年轻人，但我害怕这样生活下去，衰老下去。在我看来，这是比死亡更可怕的事。--------王小波系统服务 firewalld 主要用于 管理防火墙链和规则，相对于 iptables.services ,它更灵活，表意性更强。对应的管理工具：firewall-cmd、firewall-config。需要说明的是，如果你在启动 firewalld 服务之前，使用 ipatables 添加了一些防火墙规则，那么，在启动后，添加的规则会消失。 iptables 是一个 内核命令。他不需要任何服务就可以使用 ，而 iptables.service ， firewalld.service 是用于 管理 iptables 链和规则的工具，它们存在的意义即可以在系统启动时自动加载保存的防火墙规则，在关机时卸载对应的规则。 单纯的通过 iptables 命令设置的 防火墙规则是基于内存的，类似 /proc 目录一样，会随着系统重启消失。所以如果你通过命令 iptables 配置了对应的规则。那么在开启 firewalld 之前一定要导出 之前配置的 iptables 规则。┌──[root@vms152.liruilongs.github.io]-[~] └─$iptables-save > ips先来看下区域这个概念：什么是区域？ What is a zone? A network zone defines the level of trust for network connections. This is a one to many relation, which means that a connection can only be part of one zone, but a zone can be used for many network connections. The zone defines the firewall features that are enabled in this zone: Predefined services A service is a combination of port and/or protocol entries. Optionally netfilter helper modules can be added and also a IPv4 and IPv6 destination address. Ports and protocols Definition of tcp or udp ports, where ports can be a single port or a port range. ICMP blocks Blocks selected Internet Control Message Protocol (ICMP) messages. These messages are either information requests or created as a reply to information requests or in error conditions. Masquerading The addresses of a private network are mapped to and hidden behind a public IP address. This is a form of address translation. Forward ports A forward port is either mapped to the same port on another host or to another port on the same host or to another port on another host. Rich language rules The rich language extends the elements (service, port, icmp-block, masquerade, forward-port and source-port) with additional source and destination addresses, logging, actions and limits for logs and actions. It can also be used for host or network white and black listing (for more information, please have a look at firewalld.richlanguage(5)). For more information on the zone file format, please have a look at firewalld.zone(5).帮助文档查看┌──[root@vms152.liruilongs.github.io]-[/var/spool] └─$man firewalld.zones| cat区域用于定义了在该区启用的防火墙功能：一个网络区域定义了网络连接的信任级别。这是一种一对多的的关系，这意味着一个连接只能是一个区域的一部分，但一个区可以被用于许多网络连接。可以把区域理解为一堆防火墙规则的别名。这些规则可以是常见的：服务，端口和协议，ICMP 阻塞，NAT,IP伪装，端口转发等查看当前防火墙的默认区域┌──[root@vms153.liruilongs.github.io]-[~] └─$firewall-cmd --state running ┌──[root@vms153.liruilongs.github.io]-[~] └─$firewall-cmd --get-default-zone trusted可以设置的区域┌──[root@vms153.liruilongs.github.io]-[~] └─$ firewall-cmd --get-zones block dmz drop external home internal public trusted work这些是由 firewalld 提供的区域，根据区域的默认信任级别从不受信任到受信任排序：drop:任何传入的网络数据包都被丢弃，没有回复。只能进行传出网络连接。block:任何传入的网络连接都会被 icmp-host-prohibited 消息拒绝，IPv4 和 icmp6-adm-prohibited IPv6。只有在此系统内发起的网络连接是可能的。public:用于公共场所。您不相信网络上的其他计算机不会损害您的计算机。仅接受选定的传入连接。external:用于启用伪装的外部网络，尤其是路由器。您不相信网络上的其他计算机不会损害您的计算机。仅接受选定的传入连接。dmz:对于您的非军事区中的计算机，这些计算机可公开访问，但对您的内部网络的访问权限有限。仅接受选定的传入连接。work: 用于工作区域。您大多相信网络上的其他计算机不会损害您的计算机。仅接受选定的传入连接。home:用于家庭区域。您大多相信网络上的其他计算机不会损害您的计算机。仅接受选定的传入连接。internal:用于内部网络。您大多相信网络上的其他计算机不会损害您的计算机。仅接受选定的传入连接。trusted:接受所有网络连接。一般情况下，我们用的比较多是 trusted 和 public 这两个区域。 trusted 一般用与添加类似黑名单一样的规则，public 添加类似白名单规则,。关于区域的其他的一些命令：设置查看默认区域┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --set-default-zone=work success ┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --get-default-zone work指定网卡设置查看区域┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --get-zone-of-interface=ens32 no zone ┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --zone=public --add-interface=ens32 success ┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --get-zone-of-interface=ens32 public查看所有网卡的区域┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --get-active-zones public interfaces: ens32 ┌──[root@vms152.liruilongs.github.io]-[~] └─$规则添加设置好区域之后，我们需要添加对应的规则，这里我们以 public 和 trusted 这两个区域为例：注意： 添加完规则一定要重载才可以使配置生效当前在public 区域，我们期望运行一些端口通信或者服务,添加某些允许的规则添加 允许服务通信┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --add-service=http success添加允许 端口/协议通信┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --add-port=30001/tcp success ┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --add-port=30005/udp success可以通过 firewall-cmd --list-all 查看当前端口的预设区域信息┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --list-all trusted target: ACCEPT icmp-block-inversion: no interfaces: sources: services: http ports: 30001/tcp 30005/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: timestamp-request timestamp-reply rich rules: ┌──[root@vms152.liruilongs.github.io]-[~] └─$当前在 trusted 区域，我添加一些 icmp 协议的限制的规则,用于解决,ICMP 时间戳请求响应漏洞添加 icmp-block 规则┌──[root@vms16.liruilongs.github.io]-[~] └─$firewall-cmd --add-icmp-block=timestamp-request --permanent success ┌──[root@vms16.liruilongs.github.io]-[~] └─$firewall-cmd --add-icmp-block=timestamp-reply --permanent success ┌──[root@vms16.liruilongs.github.io]-[~] └─$firewall-cmd --reload success ┌──[root@vms16.liruilongs.github.io]-[~] └─$firewall-cmd --list-icmp-blocks timestamp-request timestamp-reply查看区域的全部规则信息┌──[root@vms16.liruilongs.github.io]-[~] └─$firewall-cmd --list-all trusted target: ACCEPT icmp-block-inversion: no interfaces: sources: services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: timestamp-request timestamp-reply rich rules:配置 NATNAT 的出现，缓解了 IP 不够用的问题，使得我们可以通过 局域网访问到公网，实现私有 IP 到公共 IP 不同网段的访问，可以通过一台 Linux 机器，开启路由功能，通过 iptables 的 NAT 路由转发表实现。 使用 firewalld，可以配置以下网络地址转换(NAT)类型：IP 伪装源 NAT，SNAT(Source Network Address Translation)目标 NAT（DNAT）重定向需要做一些准备工作。开启 ipv4 的地址转发┌──[root@vms152.liruilongs.github.io]-[~] └─$echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf ┌──[root@vms152.liruilongs.github.io]-[~] └─$sysctl -p net.ipv4.ip_forward = 1 ┌──[root@vms152.liruilongs.github.io]-[~] └─$伪装和源 NAT（SNAT）配置开启 IP 地址伪装┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --zone=external --add-masquerade success ┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --zone=external --query-masquerade yes ┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --zone=external --delete-masquerade --permanent更改数据包的源 IP 地址。例如，互联网服务提供商不路由私有 IP 范围，如 10.0.0.0/8。如果您在网络中使用私有 IP 范围，并且用户应该能够访问 Internet 上的服务器，需要将这些范围内的数据包的源 IP 地址映射到公共 IP 地址。比如提供的 公网 IP 为 39.27.24.141， 你通过这个公网 IP 请求服务，实际你在内网机器 192.168.26.3 上面发出请求，使用 NAT 做了映射，根据 参考模型，网络层会添加目标端和源端的 IP 地址，通过 路由寻址获取下一跳地址，但是你请求源端地址是 192.168.26.3 这个 私有 IP 地址，所以公网 IP 的服务，没办法响应你的请求，那这个时候你可以更改 192.168.26.3 这个私有 IP 为做 NAT 的对应公网，否则数据出的去，但是回不来。伪装和 SNAT 相互类似。不同之处是：伪装自动使用传出接口的 IP 地址。因此，如果传出接口使用了动态 IP 地址，则使用伪装。SNAT 将数据包的源 IP 地址设置为指定的 IP 地址，且不会动态查找传出接口的 IP 地址。因此，SNAT 要比伪装更快。如果传出接口使用了固定 IP 地址，则使用 SNAT配置 SNAT内部访问外部，将source ip为src_net网段来的数据包伪装成external区域对应的网卡的地址rich规则firewall-cmd --zone=external --permanent \ --add-rich-rule='rule family="ipv4" source address="<src_net/mask>" masquerade’设置NAT规则也可实现（设置POSTROUTING），将 源IP 192.168.100.0/24 修改为 eth0 对应的IP地址,修改后的地址可以是 区域或者IP或则网卡firewall-cmd --permanent --direct \ --passthrough ipv4 -t nat POSTROUTING -o eth0 -j MASQUERADE -s 192.168.100.0/24 firewall-cmd --permanent --direct \ --passthrough ipv4 -t nat -A POSTROUTING -s <internal_ip|internal_net/mask> -j SNAT --to-source <external_ip> firewall-cmd --permanent --direct \ --passthrough ipv4 -t nat POSTROUTING -o ens0 -j MASQUERADE -s <internal_ip|internal_net/mask>目标 NAT（DNAT）使用此 NAT 类型重写传入数据包的目标地址和端口。例如，如果您的 Web 服务器使用私有 IP 范围内的 IP 地址，那么无法直接从互联网访问它，您可以在路由器上设置 DNAT 规则，以便将传入的流量重定向到此服务器。firewall-cmd --permanent --direct \ --passthrough ipv4 -t nat -A PREROUTING -d <external_ip> -j DNAT --to-destination <internal_ip>重定向(端口转发)这个类型是 IDT 的特殊示例，它根据链 hook 将数据包重定向到本地机器。例如，如果服务运行在与其标准端口不同的端口上，您可以将传入的流量从标准端口重定向到此特定端口。将访问本机’external_port’端口流量转发到’internal_ip’firewall-cmd --zone=external --permanent \ --add-forward-port=port=<external_port>:proto=tcp:toaddr=<internal_ip> 将访问本机’external_port’端口流量转发到’internal_ip’的’internal_port’firewall-cmd --zone=external --permanent \ --add-forward-port=port=<external_port>:proto=tcp:toport=<internal_port>:toaddr=<internal_ip> 区域 Target和信任源IPtarget是就是对该区域内流经的数据包作最终的处理动作，firewall-cmd --zone=public --set-target=DROP 要允许来自特定IP地址(或范围)的所有传入流量，使用–zone选项指定区域，并使用–add-source选项指定源IPfirewall-cmd --zone=public --add-source=192.168.100.10防火墙区域预设(防火墙离线命令)如果我们希望在防火墙启动之前设置相关区域，比如 K8s 集群中，在集群部署中我们关闭的 firewalld ，但是在之后的运维中我们需要开启防火墙，比如处理漏洞，那么这个时候我们可用通过 firewall-offline-cmd 命令来 在 firewalld 为启动之前设置区域或者规则。注意的是：需要成为 root 用户才能使用 firewall-offline-cmd。firewall-offline-cmd 只能提供有关永久环境的信息，也可以更改它。它使用带文件 IO 处理程序的 firewalld 核心。firewall-offline-cmd 可以在 firewalld 运行时使用，但不推荐使用。大约五秒钟后，使用 firewall-offline-cmd 所做的更改会在防火墙中可见。帮助文档查看┌──[root@vms152.liruilongs.github.io]-[~] └─$man firewall-offline-cmd看一个 Demo ，在运行的 k8s 集群中我们遇到了一个漏洞，解决这个漏洞需要开启防火墙。但是防火墙默认的区域是 public ，它会限制 k8s 的一些节点通信端口，并且会影响集群上的 SDN，所以我们需要在启动之前设置为 trusend┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --get-default-zone FirewallD is not running ┌──[root@vms152.liruilongs.github.io]-[~] └─$firewall-cmd --state not running ┌──[root@vms152.liruilongs.github.io]-[/var/spool] └─$firewall-offline-cmd --version 0.6.3当前防火墙未启动，通过命令修改默认区域┌──[root@vms152.liruilongs.github.io]-[/var/spool] └─$firewall-offline-cmd --get-default-zone public ┌──[root@vms152.liruilongs.github.io]-[/var/spool] └─$firewall-offline-cmd --set-default-zone=trusted success ┌──[root@vms152.liruilongs.github.io]-[/var/spool] └─$firewall-offline-cmd --get-default-zone trusted然后我们启动防火墙，查看设置的区域┌──[root@vms152.liruilongs.github.io]-[/var/spool] └─$systemctl start firewalld.service ┌──[root@vms152.liruilongs.github.io]-[/var/spool] └─$firewall-cmd --get-default-zone trusted博文参考https://firewalld.org/documentation/zone/predefined-zones.htmlhttps://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/securing_networks/assembly_configuring-nat-using-firewalld_using-and-configuring-firewalldhttps://blog.51cto.com/huanghai/2656485

《多租户Kubernetes实践：从容器运行时到SDN》多租户Kubernetes实践：从容器运行时到SDN 电子版下载地址： https://developer.aliyun.com/ebook/2055 电子书： </div>

概要随着人们日常生活中依赖的网络设备、系统和应用程序越来越多，对网络的管理比以往任何时候都更加重要。应用程序对网络安全、可用性和性能的要求越来越高，并且要求在跨越不同协议和系统的复杂网络上实时解决网络问题，使得对网络的管理越来越困难。就在网络管理的重要性日益提升的时候，网络却已经变得如此复杂以至于似乎无法管理。在这样一个新时代，网络管理需要有根本性变更，而不只是闭合优化分析个别协议。网络运营商需要数据驱动，基于机器学习的端到端模型，基于高级策略目标的应用程序性能优化，以及底层组件的整体视图。运营商需要能够基于分类和检测算法做出实时闭环决策，而不只是对网络检测数据执行离线分析异常检测算法。换句话说，网络应该学会自我驱动。这篇论文探讨了这一概念，并讨论应该如何实现这一目标。达成这一雄心勃勃的目标需要将测量和实时控制更紧密耦合在一起，并依靠学习对网络应用和系统进行推理和预测，而不是对个别协议进行闭合分析。1. 简介现代网络应用已经运行在一个前所未见的规模和范围上。虚拟现实和增强现实需要实时响应，使用容器部署的微服务带来了流量负载的快速变化，物联网(IoT)显著增加了连接设备的数量，同时也带来了新的安全和隐私问题。这些应用深入了我们的日常生活中，提高了对实时交互、高可用性、抵御攻击的弹性、无处不在的访问和大规模的期望，因此无形中提高了网络管理的门槛。网络管理一直是一项值得努力的工作，但现在更为关键。然而，网络管理仍然是一项西西弗斯式的任务。随着用户需求和网络复杂性的持续增长，网络运营商开发并使用脚本和工具来帮助他们规划、排除故障和保护网络。网络研究人员努力改进网络协议、优化设计、测量性能，但却始终无法跟上网络的要求，因为不同的协议、动态的网络条件，以及它们与用户体验之间的关系正变得越来越复杂。20 年前，我们曾希望(并成功的)创建干净、封闭的单一协议、应用程序和系统模型[4,24]。而今天，网络已经过于复杂，无法进行闭合分析。预测问题，如确定搜索查询响应时间将如何随缓存的位置而变化，更适合基于测量数据的统计推理和机器学习[29]。当然，我们必须对网络做出改变，使网络管理更容易，类似的话已经说了很多年，但仍然没有达到期望的目标。问题的部分原因在于业界持续关注于个别协议的设计、理解和调整，我们专注于更好的 BGP 模型，对 TCP、QUIC、DNS 或目前流行的协议进行优化。事实上，问题不在于协议，与单个协议相比，无法对整体网络系统进行建模，使得运营商很难理解网络中正在发生的事情。软件定义网络(SDN)提供了更强的可编程性和集中控制，但控制器仍然依赖于收集自己需要的数据，并在交换机中配置低级匹配规则，而 SDN 并不能改变现实的网络化系统过于复杂、无法用闭合模型进行分析的事实。作为网络研究人员，必须改变解决这些问题的方法。网络管理的一个雄心勃勃的目标是自智网络(self-driving network) ，其中(1)网络测量由任务驱动，并与网络控制紧密结合，(2)网络控制依赖整个网络的学习和大规模数据分析，而不是单个协议的封闭模型。最近的倡议提出了这一高级目标[14,28]，并与自动驾驶汽车进行类比，自动驾驶汽车可以做出决策，管理不确定性并降低风险，以完成某些任务(例如，前往某个目的地的交通)。本文详细探讨了这一目标，开发了自智网络的技术要求和特性，并概述了一个广泛的、跨学科的研究议程，可以让我们离实现这一目标更近。多年来，网络界始终致力于解决这一难题，从应用程序性能的预测模型[19,29]到基于网络流量分析的统计异常和入侵检测算法[2,7]，不一而足。然而，目前的技术水平只是为创建真正的自智网络这一更为雄心勃勃的计划奠定了基础。如今，测量仍然与网络控制分离，并不可避免的将网络运维人员置于控制回路中，从而引入了不确定性以及造成误差的可能性。如何利用我们所拥有的技术，并使其既能够实时控制又具有分布式的优点，在网络(以及更广泛的计算机科学)领域带来了全新的挑战:从高级策略中派生测量、推理和控制的规则: 自智网络应该将与性能或安全性相关的高级目标作为输入，并共同得出(1)该网络应该收集的测量数据，(2)该网络应该执行的推理，以及(3)该网络最终应该执行的决策。第 2 节介绍的编程语言抽象和对网络的程序化控制的新方向，最终可能实现这些功能。自动执行，实时推理: 过去十年证明了机器学习在检测和预测网络攻击方面的巨大潜力，我们必须在网络管理中不断增加的自动化推理工作的基础上，最终将其集成到一个控制回路中，从而实现更自动化的决策。第 3 节介绍了这一挑战的两个方面: (1)基于学习改善网络管理，(2)设计网络提高为学习算法提供数据的质量。在自智网络中，数据质量(Quality of Data, QoD)是服务质量(Quality of service, QoS)的前提，并最终是用户体验质量(Quality of experience, QoE)的前提。可扩展的数据面运维: 网络社区已经开始为这方面奠定基础，通过完全可编程的、独立于协议的数据平面(例如，Barefoot Tofino 芯片集[5]和 Netronome 网卡[30])以及为它们编程的语言(例如，P4[6])。通过这些进步，数据面现在开始支持带内测量，再加上分布式流分析平台，程序化网络控制的潜力巨大，不仅包括转发(已启用 SDN)，还包括测量数据的收集。第 4 节介绍了这些领域的研究挑战和机遇。运营商一直希望网络更容易管理，算法、机器学习、形式化方法、编程语言和硬件的发展，鼓励我们考虑更大的目标，即尽可能减轻运维人员的负担，甚至可能完全不需要人工运维。实际上，能够帮助我们实现这些目标的工具和技术正在出现，但我们还没有这一拼图的所有碎片，例如，对自动化控制或推理的需求对机器学习算法提出了新的要求。因此，自智网络对网络乃至计算机科学都是巨大的挑战。由于我们做的几乎所有事情都依赖于互联网，我们必须接受这一挑战。2. 准备开始自智网络的第一个组成部分是规划，网络运维人员指定高级策略，运行时系统生成相应的测量、推理和控制操作。自智网络应该依赖统一的框架来指定 SLA、全网范围的资源优化和包交互，以及可以生成运行在异构网络设备集上的分布式程序的运行时，以集成测量、推理和控制。2.1 定义复杂网络策略设想有这么一个网络，运营商可以指定　(1)客户期望(例如，延迟和抖动的统计保证);　(2)全网目标(例如，尽量减少拥塞);　(3)应用功能和业务(如:网络地址转换、访问控制、入侵检测)。客户期望(服务水平协议)。 网络运营商应指定服务水平协议(SLA)在保证网络指标(例如，延迟、抖动和 DDoS 响应时间)或用户体验质量指标(如 VoIP 的 MOS 或网页浏览加载时间)。每个 SLA 应该对应于流量的一个特定子集，该子集由数据包报头字段以及地点指定，或者更好的是，基于 Web 站点(如 www.netflix.com)或应用程序(如视频流)的更高级别名称指定。交互式应用程序可以确保包延迟至少在 99.9%的时间内小于 10 毫秒。SLA 可能对应于与客户的合同协议，并可以驱动监控(检测网络何时有违反保证的风险)、适应(在短期内缓解问题)和学习("学习"如何选择满足 SLA 的配置，同时避免浪费网络资源)。今天，服务提供商只是非正式的指定 SLA。尽管一些初步研究提出了用于指定 SLA 的语言[16,18]，但这些工作在自动监控、适应和学习方面没有完成闭环。网络目标(资源优化)。 网络运营商除了要满足客户的服务承诺外，亦要满足整个网络的目标，使其网络能高效、可靠的运作。这些目标可以自然的表达为优化问题，具有目标(objectives, 如最小化拥堵)和约束(constraints, 如节约流量或限制路径长度)，管理员应该能够将这些目标直接指定为优化问题。例如，一个常见的流量工程目标是最小化所有链路上某个链路利用率凸函数f()的总和(例如，∑lf(ul/cl))，其中链路利用率取决于流量矩阵(vij，从入口 i 到出口 j 的负载)和路由(rij)，从入口 i 到出口 j 的流量中穿过链路l的百分比)。也就是说，链路利用率是遵循遍历链路路径的所有流量矩阵的和(ul=∑ijrijl∗vij)。从而通过求解这一优化问题得到网络(rijl)。实践中，运行时必须决定多久收集一次测量指标(以及精确到什么程度)、改变路由的频率以及如何表示路由决策(基于网络设备的功能)。从拥挤的对端转移流量。 当某一特定链路上的流量超过阈值时，运营商可能希望将多余流量转移到另一条互连链路上。基于此策略，运行时系统应该监测第一条链路上的流量负载，并决定是否以及如何平衡负载，而不只是依赖于静态阈值。相关决策也可能依赖于更高级别的 QoE 要求监控关联流量获得的指标(如 MOS，甚至是来自应用程序的关于视频比特率或重新缓冲的直接信令)。检测、拦截非预期流量。 运营商可以制定某个策略来检测和缓解拒绝服务攻击(DoS)，该策略可能要求网络应该对从许多不同的发送方接收特定 DNS 响应消息的目的地的流量进行限流。基于此策略，运行时应该生成必要的监控查询，并根据监控结果对可疑流量进行限速，而不是等待检测到 DoS 攻击时的特定阈值，从而通过该策略可以指定某种检测技术(例如，通过端口扫描的顺序假设测试)来识别攻击。3. 适应动态环境网络的复杂性及其底层过程的动态特性使机器学习算法成为检测、诊断和缓解中断的天然工具。之前的工作应用了机器学习和用户交互技术，以改善网络安全[2,7,9]和性能[19,29]的具体方面。然而到目前为止，这些技术主要还是基于现有设计，而不是直接整合到网络控制中。例如，机器学习在网络安全方面的许多应用都涉及到大规模流量跟踪算法的开发和(通常是离线的)测试，下一步自然是将这些类型的推理和控制算法集成到网络决策和控制中。即使是应用现有的学习算法也经常遇到很多困难，部分原因是基于现有网络协议和技术不容易获得数据样本标签。另外，现在的机器学习算法往往不是为大容量、分布式和快速发展的网络数据量身定制的，现有算法也使得迭代精炼监督学习算法中使用的特征(对于大容量网络流量跟踪可能需要)或执行复杂的时间序列分析变得困难。本节我们将介绍机器学习和用户交互技术如何在自智网络领域提供帮助: (1)基于机器学习促进自智网络，在许多情况下，网络可以学习自己运行，避免由运维人员做出决定(第 3.1 节); (2)结合应用程序和人类用户的输入从而更好的改进学习算法(第 3.2 节)。3.1 通过学习改善运维网络应该提供高可用性、良好的应用程序性能，以及基于自动化和半自动化来应对中断，从而提升安全性。过去使用单点解决方案(例如，防火墙和垃圾邮件过滤器等中间体)来修补现有网络，与此相反，我们建议让网络内建这些中间体提供的功能。我们将讨论两个适合自智网络的管理领域: (1)满足性能要求和服务水平协议; (2)自动检测和减少不必要的通信(例如，垃圾邮件、DoS 攻击)。性能: 应用程序和服务水平协议。 要提供良好的网络性能，需要在短时间内对不断变化的网络条件做出反应。为某些应用程序提供良好的网络性能，需要理解应用级指标(例如，视频比特率，再缓冲事件)以及通过网络流量可以测量什么之间的关系。在其他情况下，运营商的任务可能涉及确定服务水平协议(SLA)，包括确定网络条件何时可能导致违反 SLA。当网络比较简单的时候，可以使用闭合分析来模拟(比如)TCP 连接的行为，以及预测特定网络的变化(例如，路由协议权重的变化)可能会对应用程序性能的影响。然而，在今天的网络中，不再容易进行这种闭合分析，因为网络的复杂性以及许多相互作用的网络组件共同影响了网络和应用程序的性能。通过收集、存储和分析附加数据的能力，网络可以生成模型，在利用率等较低级别指标和流媒体应用性能等较高级别指标之间建立更复杂的关系。例如，以前的工作已经建立了对特定配置决策如何最终影响网络搜索响应时间[29]建模的可能性。过去的工作已经证明，了解低级别网络特性(如往返延迟)和应用程序性能指标(如搜索响应时间)之间的关系是可能的。随着算法速度和复杂性的发展，加上数据平面可编程性的进步，应该考虑将这些技术扩展到有关实时性能监控的问题上来，包括应用级性能保证和 SLA 监控。安全: 非必要流量。 近年来，机器学习在统计异常检测中的应用取得了重大进展。研究人员开发出了新的学习算法，通过分析网络流量(从报文跟踪到 IPFIX 记录)[17]、DNS 查询[2]和域注册[8]，甚至 BGP 路由消息[15]来检测(甚至预测)攻击。然而，这些异常检测算法大多只在离线流量跟踪数据上进行了演示，这样的演示对于识别运行在独立网络设备上的异常检测算法的特征非常有用，从而为自智网络的前景带来了更多的挑战和机遇。其中一个挑战涉及到对这些算法进行调整，使其实时运行，并能够结合实时操作。例如，基于轻量级特征的简单回归模型可以在支持可定制特征提取和计算的可编程交换机中执行(例如基于 Barefoot Tofino 芯片组[5])，我们将在第 4.2 节进一步讨论。另一个挑战涉及开发新的机器学习算法，基于轻量级特征(例如基于元数据或粗统计)执行粗分类，并当分类不确定时触发更重量级特征的收集(例如来自数据包)，我们将在下一节中更详细探讨这种可能性。3.2 用更好的数据改善学习网络也应该量身定制，以提高提供给实时推理和预测算法的输入数据的质量。例如，用于网络安全的机器学习算法，如入侵检测，经常需要在标记数据上进行训练。然而，对于网络安全领域来说，获取标签数据是非常困难的，因为攻击比较罕见，而威胁是动态的，不断出现新的威胁和攻击类别。类似的，识别体验质量的降级通常需要来自应用程序和用户两者的输入。在本节中，我们将讨论未来的网络可能如何与学习算法共同设计，以提高算法的准确性，并提高为这些算法提供输入的数据的质量和数量。3.2.1 提高模型精度来自高级策略和拓扑依赖关系的输入。 传统机器学习方法在离线网络跟踪数据之上运行，几乎没有关于网络结构依赖关系的信息，因此，在做出任何有用的推理之前，必须推断出许多已知的信息。新的机器学习技术可能通过结合来自网络拓扑结构(例如，共享风险链接组)和高级策略的输入来更好的诊断网络问题。例如考虑检测影响可用性的网络故障的情况，尽管网络提供了丰富的数据，但缺乏单一框架综合处理异构数据，以形成关于潜在原因的假设。例如，当一条链路故障时，会产生链路告警、路由变化、流量漂移等问题。自智网络可以利用网络拓扑信息，而不是强迫机器学习算法从故障事件的观察中推断这些依赖关系。收集额外的数据以提高模型的准确性。 推断模型的准确性还可能取决于可用数据的类型和数量。许多情况下，推断算法会随着有更多附加数据样本或不同类型或粒度的数据而改进。可学习的网络可以使用基于相对轻量级或容易收集的网络数据的粗检测算法(例如，采样 IPFIX 日志，SNMP)来开发一个可能具有高于可接受的误报率的分类器。这个分类器的输出可能会触发额外的测量，例如测量(通过探针)网络不同部分，或者在某些情况下，用更昂贵的手段进行采样从而获取关于流量的更精确的信息(例如 DNS 查询日志、定时信息)。诸如带内网络遥测[13]等技术的出现使得不仅可以将额外的细粒度信息写入数据包中，而且还可以根据需要生成探测流量，从而有可能触发端到端或网络内部的细粒度主动或被动测量(如果算法需要这些信息)。3.2.2 提高数据质量增加标记数据的数量。 将机器学习应用于网络性能和安全问题的挑战之一是缺乏用于训练这些算法的标记数据。缺乏标记数据是当今网络的现状，其原因如下: 许多有趣的事件(1)是罕见的(即发生频率不够高，无法生成合理的训练集)、(2)新兴(即反映了某种以前未见过的新威胁或攻击)的或(3)动态的。在网络发生故障时，通常是由于网络设备的"一次性"错误配置造成的，该配置以意想不到的(以前没有观察到的)方式与网络上的其他设备交互。其他网络故障可能发生在物理硬件故障或特定的通信模式触发实现错误或配置错误时。不幸的是，由于每个故障本质上都是唯一的，基于过去的故障示例的训练可能无法产生能够检测和诊断未来故障的分类器。一个可以学习的网络可以直接从运维人员、网络配置，甚至可能从用户或应用程序吸收信息，以增加检测和推理算法可以用来训练的标记数据的数量。从用户输入。 来自最终用户的反馈可以帮助推动网络中额外的被动和主动测量。网络运营商通常可以看到网络本身的指标，但这些指标有时很难映射为用户体验。我们设想，通过用户的明确反馈，这些数据可能会更好的结合在一起，从而触发触发额外的被动或主动测量。例如，一种可能性是，Web 浏览器等应用程序有一个按钮，用户可以通过该按钮显式的指示应用程序性能较差(一个"我很沮丧"按钮)。这种反馈可能体现在应用程序流量中的包注释上，从而触发来自交换机的额外被动或主动测量。应用程序开发人员偶尔会通过一种被称为体验抽样的技术，对终端用户就单个应用程序的性能进行调查(例如，"您上次视频通话的体验如何?")。与经验抽样相关的一个挑战是何时对用户体验进行调查，偶尔的抽样可能导致应用程序性能数据不充分，而过于频繁的采样可能会激怒用户或导致用户提交不满意的回复。一个可能的研究方向是使用网络测量来驱动和自动化经验采样。例如，网络中的可编程交换机或仪表化的 OS 内核可能表明在某些条件下的退化，例如更高的丢包或延迟，或吞吐量的降低，类似的，服务器可能会在 TCP 流中看到较高的丢包或延迟。这些条件可以作为自动触发器来轮询用户的应用体验，通过适当集成，网络设备或服务器可以生成一个包，用户的操作系统或浏览器可以自动解析这个包来触发采样。从应用或操作系统输入。 终端用户应用程序通常有关于他们正在经历的性能精确信息(例如，是否发生了重新缓存事件，视频比特率是否发生改变)，但通常没有办法将这些信息传递给网络。类似的，操作系统可能有关于用户参与的额外信息，例如应用程序是否在前台运行，甚至可能用户是否在操作应用程序(或设备)。将有关应用程序性能和用户参与的信息传递给网络可以更有效的促进网络资源的使用。操作系统可以将有关应用程序状态的信息包含到网络流量中，网络随后可以使用这些信息将流量分配给更高或更低的优先级队列。例如，即使视频仍在继续，但网络可以安全的确定降低用户不再观看的高吞吐量视频流的优先级。来自应用程序和操作系统的附加信息，比如 TCP 统计信息，也可以用来标记数据流，可以用作今后查询数据流的属性。4. 越快越好前几节中的功能依赖于实时监控和预测、对大量网络流量的流分析以及线速处理能力，从聚合等简单功能到推理和预测等更复杂的功能。在自智网络的设计和应用方面，还有许多研究挑战，尤其是在使这些功能可扩展、分布式和实时化方面。4.1 数据平面流量分析灵活的包解析、匹配操作流水线以及在交换机和数据包头上维护状态的能力可以使网络支持高级度量抽象。紧凑的数据结构。 可编程交换机可以执行算术操作和维护表中的状态，允许交换机支持紧凑的数据结构，维护关于包流的统计信息。这些数据结构可以支持更高层次的抽象，例如维护集合(例如，布隆过滤器)，计数(例如，计数布隆过滤器或 Count-Min Sketch)，或计算非重复数据(例如，count distinct sketch)。最近研究表明，在新兴交换机上支持这类数据结构[20,26,31]、优化有限状态、计算资源和控制带宽方面还有很多工作要做。在数据包上承载状态。 许多网络任务需要跨越多点进行操作。使用状态标记数据包并在后续节点上更新状态的能力使数据平面能够支持一系列强大的抽象。例如，报头可以携带应用于该包的网络策略版本(例如，支持一致的策略更新[25]，集合或序列(例如，下一跳，网络路径，或灵活的流量代理[21])。或者携带确定性有限自动机的状态，用于评估包属性及其通过网络路径上的正则表达式，以基于这些属性测量或控制流量[23]。或者携带跨路径流量统计聚合，以收集路径级指标，如最大链路利用率或总排队延迟[13]。简化与其他数据集的连接。 分析常常需要将流量统计数据与其他数据集结合起来。例如，将报文目的地址与其自治系统(通过连接路由表数据)、网站或应用程序(通过连接 DNS 查询日志)或最终用户(通过连接认证服务器数据)相关联。这些信息可以促进测量数据的聚合、流量的路由及调度，以及基于更高级别策略的访问控制。在今天的网络中，这些关联非常繁琐，通常依赖于来自不同位置的粗粒度时间戳。数据平面可以通过两种方式简化关联过程。首先，数据平面可以通过同时分析和合并数据集，或者通过维护第二个数据集的有效表示(例如，一个与特定类中经过身份验证的用户相关联的 IP 地址表)来完成关联。其次，交换机可以标记数据包，例如，表示网络中的某个位置和相关的时间戳，这些信息可以简化后续的关联。4.2 数据平面预测模型如第 3 节所讨论的，机器学习已经应用于各种各样的网络监控任务，从性能监控到安全。然而，到目前为止，其中很多模型已经以纯离线的方式进行了演示和部署，流量以包的形式被捕获，IPFIX 记录或 DNS 查询以日志的形式从网络中收集，并用于训练检测模型，而模型也是在脱机状态下进行评估的。然而，这些模型中有许多包含了简单的特性，这些特性通常可以从单个数据包中计算或推断出来。可编程交换机可以从数据平面数据包中提取这些特征，甚至根据这些学习到的模型计算回归函数，本质上是在线计算预测函数，并对网络中的流量性质做出实时决策，而不需要离线分析。考虑基于机器学习的垃圾邮件过滤器，它依赖网络级别的特性，例如发送 IP 地址的自治系统，以及同时发送邮件的相邻 IP 地址的数量[9]。可编程交换机可以内联计算这些特征，并计算单个特征的加权线性组合，以计算消息是垃圾邮件的总体可能性。另一个例子涉及到基于 DNS 查找僵尸网络，通过分类器检测异常特征，例如在字典顺序上非常接近的查询，在短时间间隔内发生大量流量，并且托管在劣迹斑斑的 DNS 服务上。可编程交换机可以解析 DNS 查询来提取这些特性，并在交换机上检测与恶意活动相关的 DNS 查找，而不需要离线分析。5. 结论现代网络应用对性能、可靠性、可用性和安全性的要求不断提高，使得网络管理比以往任何时候都更加重要。与此同时，网络本身已经变得过于复杂，无法使用最先进的方法来管理，这些方法依赖基于单一协议和设备级别上的网络行为和性能的闭合模型。作为一个社区，我们必须考虑全新的网络管理方法: (1)依赖于数据驱动的模型，可以从较低级别指标预测端到端网络性能; (2)将测量与实时控制相结合，尽可能将运维人员从管理控制回路中排除。过去十年为设计自智网络奠定了基础，从统计异常检测和基于学习的故障排除工具到可编程网络和线速算法的紧凑数据结构，我们应该基于这些组件来构建现代应用所需的自智网络。参考文献[1] C. J. Anderson, N. Foster, A. Guha, J.-B. Jeannin, D. Kozen, C. Schlesinger, and D. Walker. NetKAT: Semantic foundations for networks. In ACM Principles of Programming Languages, pages 113–126, Jan. 2014.[2] M. Antonakakis, R. Perdisci, D. Dagon, W. Lee, and N. Feamster. Building a Dynamic Reputation System for DNS. In USENIX Security Symposium, pages 273–290, 2010.[3] M. T. Arashloo, Y. Koral, M. Greenberg, J. Rexford, and D. Walker. SNAP: Stateful network-wide abstractions for packet processing. In ACM SIGCOMM, Aug. 2016.[4] M. Arlitt, B. Krishnamurthy, and J. C. Mogul. Predicting shorttransfer latency from TCP arcana: A trace-based validation. In SIGCOMM Internet Measurement Conference, 2005.[5] Barefoot Tofino. https://barefootnetworks.com/technology/#tofino.[6] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford, C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese, and D. Walker. P4: Programming protocol-independent packet processors. ACM Computer Communications Review, 44(3):87–95, July 2014.[7] G. Gu, R. Perdisci, J. Zhang, and W. Lee. BotMiner: Clustering Analysis of Network Traffic for Protocol-and StructureIndependent Botnet Detection. In USENIX Security Symposium, volume 5, pages 139–154, 2008.[8] S. Hao, A. Kantchelian, B. Miller, V. Paxson, and N. Feamster. PREDATOR: Proactive Recognition and Elimination of Domain Abuse at Time-of-Registration. In ACM Conference on Computer and Communications Security (CCS), pages 1568–1579, 2016.[9] S. Hao, N. A. Syed, N. Feamster, A. G. Gray, and S. Krasser. Detecting Spammers with SNARE: Spatio-temporal Networklevel Automatic Reputation Engine. In USENIX Security Symposium, volume 9, 2009.[10] V. Heorhiadi, M. K. Reiter, and V. Sekar. Simplifying software-defined network optimization applications using SOL. In USENIX Networked Systems Design and Implementation, 2016.[11] P. Kazemian, G. Varghese, and N. McKeown. Header space analysis: Static checking for networks. In USENIX Networked Systems Design and Implementation, 2012.[12] A. Khurshid, X. Zou, W. Zhou, M. Casesar, and P. Godfrey. VeriFlow: Verifying network-wide invariants in real time. In USENIX Networked Systems Design and Implementation, 2013.[13] C. Kim, P. Bhide, E. Doe, H. Holbrook, A. Ghanwani, D. Daly, M. Hira, and B. Davie. In-band network telemetry (INT), June 2016. http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf.[14] K. Kompella. The Self-Driving Network: How to Realize It. North American Network Operators Group (NANOG), June 2017. https://www.nanog.org/sites/default/files/1_Kompella_The_Networking_Grand_Challenge.pdf.[15] M. Konte, R. Perdisci, and N. Feamster. ASwatch: An AS Reputation System to Expose Bulletproof Hosting ASes. ACM SIGCOMM Computer Communication Review, 45(4):625–638, 2015.[16] K. Kritikos, B. Pernici, P. Plebani, C. Cappiello, M. Comuzzi, S. Benbernou, I. Brandic, A. Kertesz, M. Sztaki, M. Parkin, and M. Carro. A survey on service quality description. ACM Computing Surveys, 46(1), Oct. 2013.[17] A. Lakhina, M. Crovella, and C. Diot. Diagnosing Networkwide Traffic Anomalies. In ACM SIGCOMM Computer Communication Review, volume 34, pages 219–230, 2004.[18] D. Lamanna, J. Skene, and W. Emmerich. SLAng: A languagefor defining service-level agreements. In IEEE Workshop on Future Trends of Distributed Computing Systems, pages 100–106, 2003.[19] Z. Li, M. Zhang, Z. Zhu, Y. Chen, A. G. Greenberg, and Y.-M. Wang. WebProphet: Automating Performance Prediction for Web Services. In USENIX Symposium on Networked Systems Design and Implementation (NSDI), volume 10, pages 143–158, 2010.[20] Z. Liu, A. Manousis, G. Vorsanger, V. Sekar, and V. Braverman. One sketch to rule them all: Rethinking network flow monitoring with UnivMon. In ACM SIGCOMM, Aug. 2016.[21] R. MacDavid, R. Birkner, O. Rottenstreich, A. Gupta, N. Feamster, and J. Rexford. Concise encoding of flow attributes in SDN switches. In ACM Symposium on SDN Research, pages 48–60, 2017.[22] J. McGlurg, H. Hojjat, N. Foster, and P. Cerny. Event-driven network programming. In ACM Programming Languages Design and Implementation, June 2016.[23] S. Narayana, M. Tahmasbi, J. Rexford, and D. Walker. Compiling path queries. In Networked Systems Design and Implementation, Mar. 2016.[24] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP Throughput: A Simple Model and Its Empirical Validation. ACM SIGCOMM Computer Communication Review, 28(4):303–314, 1998.[25] M. Reitblatt, N. Foster, J. Rexford, C. Schlesinger, andD. Walker. Abstractions for network update. In ACM SIGCOMM, Aug. 2012.[26] V. Sivaraman, S. Narayana, O. Rottenstreich, S. Muthukrishnan, and J. Rexford. Heavy-hitter Detection Entirely in theData Plane. In Symposium on SDN Research (SOSR), pages 164–176, 2017.[27] R. Soule, S. Basu, P. J. Marandi, F. Pedone, R. Kleinberg, E. G. Sirer, and N. Foster. Merlin: A language for provisioning network resources. In ACM CoNEXT Conference, Dec. 2014.[28] Designing self-driving networks workshop, Apr. 2017. http://forum.stanford.edu/events/2017selfdriving.php.[29] M. Tariq, A. Zeitoun, V. Valancius, N. Feamster, and M. Ammar. Answering what-if deployment and configuration questions with WISE. In ACM SIGCOMM, volume 38, pages 99–110, 2008.[30] B. Vinnakota. Netronome and P4: A brief history and a roadmap. https://www.netronome.com/blog/netronome-and-p4-a-brief-history-and-aroadmap/.[31] M. Yu, L. Jose, and R. Miao. Software Defined Traffic Measurement with OpenSketch. In Networked Systems Design and Implementation, volume 13, pages 29–42, 2013.

随着互联网和数据中心流量的爆炸式增长，SDN 已经逐步取代静态路由交换设备成为构建网络的主流方式，本系列是免费电子书《Software-Defined Networks: A Systems Approach》的中文版，完整介绍了 SDN 的概念、原理、架构和实现方式。原文: Software-Defined Networks: A Systems Approach第 9 章 接入网现在我们将注意力转向 SDN 最新出现的用例: 接入网，包括光纤到家和移动蜂窝网络。虽然现在还处于早期阶段(刚刚推出产品部署)，但有巨大的机会。本章描述了两个例子: 无源光网络(PON, Passive Optical Networks) 和无线接入网(RAN, Radio Access Networks) ，分别是光纤到家和移动蜂窝网络的核心。9.1 背景用于实现将家庭、企业和移动设备连接到互联网的最后一英里的网络技术有着独立于互联网其他部分的发展历程。这种发展已经持续了几十年，开始于对基于电路的语音通信的支持，然后逐渐增加了对基于 IP 的数据通信的支持。最终结果是一个巴洛克式的专用设备的集合，对于那些知道如何在 L2/L3 以太网交换机的集合上构建网络的人来说，这些设备看起来非常陌生。但这使得接入网成为 SDN 的沃土，为了理解这意味着什么，我们需要从对将要替换的传统系统的简要概述开始。我们将在介绍两种特定接入技术(PON/RAN)的上下文中开始。幸运的是，从高层往下看，它们的架构惊人的相似。当然，细节差别也很大，但隐藏(甚至消除)不必要的细节是 SDN 带来的主要价值之一。在讨论细节之前，需要再了解一点背景知识。提供宽带服务的 ISP(如电信公司或有线电视公司)通常经营着国家主干网络，连接到该主干网外围的是成百上千的边缘站点。在电信领域，这些边缘站点通常被称为中央机房(Central Offices) ，在有线通信领域，通常被称为头端(Head Ends) 。尽管这些名字暗示着"集中化"和"层次结构的根"，但都位于 ISP 网络的最边缘，是 ISP 连接客户的最后一英里的一端。基于 PON 和 RAN 的接入网就部署在这些设施中。9.1.1 无源光网络(Passive Optical Network)PON 是树形结构的光纤网络，从 ISP 边缘站点的一台设备开始，可以扩展到 1024 个家庭。PON 的名字来源于被动的无源分路器，这些分路器向上下游转发光信号，而没有对帧进行主动存储转发的能力。端点完成帧的拼接，对应的 ISP 设备被称为光终端(OLT, Optical Line Terminal) ，部署在家庭中的设备被称为光网络单元(ONU, Optical Network Unit) 。图 51 是一个 PON 的示例，简化为只有一个 ONU 和一个 OLT。在实际部署中，一个中心机房会有多个 OLT，分别连接数千个客户家庭。图 51 还突出显示了另一个细节，一个将接入网连接到 Internet 的 BNG(Broadband Network Gateway) 。BNG 是电信公司的一种设备，除了转发数据包外，还对用户进行身份验证，区分向每个客户提供的服务水平，并对流量进行计费。图 51. 连接中心机房 OLT 到家庭和企业 ONU 的 PON 示例。由于分路器是无源的，PON 实现了多接入协议。简单来说，上下游业务在两个不同的波长的光波上传输，因此是完全独立的。下行流量从 OLT 开始，信号沿着 PON 的每一条链路传播，每一帧都能够到达 ONU。然后 ONU 在帧中查看唯一的标识符，并接收该帧(如果标识符是自己)或丢弃(如果不是自己)。通过加密防止 ONU 窃听邻居的通信。上游流量在上游波长上进行时分复用，每个 ONU 周期性获得发送周期。PON 与以太网类似，定义了一种共享算法，经过多年发展，该算法可以适应越来越高的带宽。目前部署最广泛的是 G-PON(Gigabit-PON)，支持 2.25 Gbps 带宽。XGS-PON(10 Gigabit-PON)正在部署中。9.1.2 无线接入网(Radio Access Network)RAN 通过在无线电频谱的不同带宽上编码和传输数据来实现最后一跳。例如，传统的蜂窝技术范围从 700 MHz 到 2400 MHz，如今在 6 GHz 范围分配了新的中频频谱，而毫米波(mmWave)技术的频谱在 24 GHz 以上。如图 52 所示，给定地理区域(例如地铁站)中的一组基站相互连接，并和运行在中央机房中的移动核心网(Mobile Core)通信。移动核心网类似于 BNG(从高层架构来说)，充当连接接入网到 Internet 的 IP 网关，同时负责认证、QoS 和计费。与 BNG 不同，移动核心网还负责管理移动性(例如，记录当前哪个基站在为哪个有源设备服务，管理基站之间的切换，等等)。图 52. 无线接入网(RAN)，将一组蜂窝设备(User Equipment, UE)连接到中央机房的移动核心网。图中显示了移动核心网和一组由回传(backhaul)网络连接的基站。回传网络的实现取决于技术选择，可以基于以太网或基于 PON，但就我们的目的而言，重要的是理解 RAN 实际上是构建在回传网络之上的局域包交换网络，其中基站是该 overlay 网络的"节点"。数据包通过这个网络"路由"到达最合适的基站，并在给定时刻为每个移动设备(用户设备或 UE)提供服务[1]。转发决策由基站实现，基站负责做出以下决策: 切换(handover, 将给定终端的流量从一个基站切换到另一个基站)、负载均衡(load balancing, 一组基站根据其当前负载决定哪个应该为某个终端服务)和链路聚合(link aggregation, 多个基站决定联合向某个给定终端传输数据)。[1] 之所以说"路由"，是因为基于综合考虑移动跟踪和监控决定如何最有效利用无线频谱，而不是通常在有线网络中使用的最短路径标准。重要的是，基站协同实现一种分布式决策算法，然后根据这些决策相互转发数据包。9.1.3 关键结论(Key Takeaways)在讨论如何应用 SDN 原则之前，有三个关于这两种网络技术的结论。首先是"接入网"和"IP 网关"的区别。例如，光纤到家(Fiber-to-the-Home)是由 PON 和 BNG 结合实现的，同样，5G 蜂窝移动网络(5G Cellular Mobile Network)是由 RAN 和移动核心网(Mobile Core)结合实现的。本章主要关注如何将 SDN 应用到 PON 和 RAN 上，但正如我们在 7.4 节中已经看到的，SDN 也可以应用到 BNG 和移动核心网。两者都是增强的 IP 路由器，其新特性都是对运行在交换结构中的 P4 程序的扩展。 我们将在最后一节中回到这个主题，介绍 SD-Fabric 和接入网之间的关系。其次，因为 PON 是无源的，没有机会在网络内部进行软件控制。将 SDN 应用于 PON 涉及到对端点(即 OLT 和 ONU)的软件控制，并将这些端点之间的所有东西视为被动背板。此外，由于 ONU 是响应 OLT 指令的"哑"设备，这实际上可以归结为分解 OLT。最后，由于 RAN 是将一组基站连接起来的包交换网络(作为回传网络的 overlay)，因此有机会实现软件控制。这需要分解基站，正如我们将在本章后面看到的，基站在历史上运行多层协议栈，一旦被分解，这些组件就会分布在整个网络中，一些组件与无线电天线放在一起，一些组件与中央机房的移动核心网(Mobile Core)放在一起。换句话说，最终计划是"分割"和"分发"RAN 功能。为了更广泛理解分解 5G 移动网络所涉及的内容，以便在软件中实现，推荐以下配套书籍。延伸阅读:L. Peterson and O. Sunay. 5G Mobile Networks: A Systems Approach. June 2020.9.2 SD-PON将 SDN 应用于 PON 的机会在于，OLT 本质上是增强的 L2 交换机，配备了运行在每个交换机端口上的不同的 MAC 层帧协议。就像可以买到基于 OCP 规范的裸金属 L2 交换机一样，现在也可以买到 OLT。但在实际实现软件定义的 PON(SD-PON)之前，还需要解决三个问题[2]。[2] 为了与本书其他用例的命名方式一致，我们将其称为 SD-PON，但实际的 ONF 开源软件项目被称为 SEBA: SDN-Enabled Broadband Access。首先，为了知道网络要支持什么级别的服务，PON 需要将大量配置加载到每个 OLT 中。其次，部署到家庭中的 ONU 设备的能力有限，需要通过连接的上游 OLT 间接控制。最后，网络运营商并不一定可以只用裸机硬件，而是必须处理各种传统设备。为了解决这些问题，出现了图 53 中描述的 SD-PON 体系架构。基于该架构的生产网络现在已被电信公司部署到世界各地。为了简单起见，图中只显示一个 OLT，连接到两个 fabric 交换机。在实践中，这种架构对于聚合 OLT 很有必要，我们将在 9.4 节再解释细节，当前大家可以认为这些交换机都在第 7 章介绍的 SD-Fabric 的控制之下。下面我们将介绍 SD-PON 架构的其他部分。图 53. SD-PON 架构。首先是硬件抽象层，称为 VOLTHA(虚拟 OLT 硬件抽象, Virtual OLT Hardware Abstraction) 位于网络操作系统(例如 ONOS)和单个 OLT 之间。VOLTHA 提供北向 OpenFlow 接口，使 ONOS 能够像任何其他 SDN 设备一样控制 OLT，特定供应商的适配器在 OpenFlow 和 OLT 之间转换。原则上，这种转换可以在 ONOS 内部处理，ONOS 已经有健壮的南向适配器框架，但 VOLTHA 被设计为网络操作系统无关的，因此复制了大部分的机制。VOLTHA 必须正确处理许多细节，但在概念上没有什么新内容，主要是控制状态流(例如，为订阅者分配特定的 QoS 类)和监视状态流(例如，识别 ONU 何时连接或分离)。主要的不同点是需要将 Traffic Profile 文件(图中表示为 TP)加载到 OLT 中。这一配置文件指定运维人员期望 PON 支持的 QoS 类，通常在 OLT 启动时加载这这一配置状态，原则上，也可以由 ONOS 通过 gNMI/gNOI 进行管理。OLT 目前不支持像 gNMI 这样的通用 API，所以通过这种一次性方式处理。最后，也是最有趣的一点是，由于 ONOS 需要知道 ONU，但不能直接使用 OpenFlow 或任何其他 API 进行控制，因此该架构在 OLT 及其相连的 ONU 集合上构建了一个交换抽象层，在图 53 中由外部的灰色框表示。我们可以将这种网络模型看作是交换机，具有一组面向网络的端口(在通信行业中称为 NNI)和一组面向用户的端口(在通信行业中称为 UNI)。ONOS 把这个聚合网络当作一个逻辑交换机，每当用户打开家里的 ONU 时，ONOS 就会看到相应的 UNI 上有一个"port active"事件，并采取相应的操作，这些操作由图中所示的 SD-PON 控制套件实现。那么需要做什么操作呢？主要工作是将用户安全的连接到 Internet。例如，当一个 ONU 上线(对应于逻辑交换机上的一个端口变为活动状态)时，将启动 802.1X 授权流程，验证该 ONU 是否是已注册的客户。成功授权的结果是，SD-PON 程序指示 ONOS 通过 fabric(使用规定的 QoS 配置文件)建立一条路径，将用户连接到 L2 网络。接下来，连接到 ONU 的家庭路由器将发送一个 DHCP 请求，触发 IP 地址分配，并触发 ONOS 建立路由，将家庭路由器连接到上游 BNG(以及互联网)。9.3 SD-RAN关于 5G 的早期宣传主要是关于更多的带宽，但 5G 的承诺主要是关于从单一接入服务(宽带连接)扩展到更丰富的边缘服务和设备集合，包括支持沉浸式用户界面(如 AR/VR)、关键任务应用(如公共安全、自动驾驶汽车)和物联网(IoT)。只有当 SDN 原则应用于 RAN 时，这些新应用才可行，才能支持快速引入新特性。正因如此，移动网络运营商正在努力实现软件定义 RAN(SD-RAN)。延伸阅读:SD-RAN Project. Open Networking Foundation. August 2020.要理解 SD-RAN 的技术基础，重要的是要认识到，组成 RAN 的基站是专门的分组交换机。在给定地理区域内的一组基站相互协调，以分配和共享稀缺的无线电频谱。它们做出切换决策，共同为给定用户服务(可以把这看作链路聚合的 RAN 变体)，并根据连续测量的信号质量做出包调度决策。今天这些都是纯粹的局部决策，但将其转化为全局优化问题是 SDN 的专长。SD-RAN 的想法是让每个基站向 SDN 中央控制器报告本地收集到的关于无线电传输质量的统计数据，SDN 中央控制器结合来自一组基站的信息，构建一个关于无线电频谱如何被利用的全局视图。一套控制程序(例如，一个专注于切换，一个专注于链路聚合，一个专注于负载平衡，还有一个专注于频率管理)可以基于这些信息做出全局最优决策，并将控制指令推回到各个基站。这些控制指令不是在传输的单个片段的调度粒度上(即，在每个基站上仍然有实时调度程序，就像 SDN 控制的以太网交换机仍然有本地包调度程序一样)，但通过不到 10 毫秒的测量回路，确实对基站施加了接近实时的控制。9.3.1 分离式 RAN(Split RAN)为了更好了解这是如何工作的，我们从图 54 所示的关于基站包处理流水线的细粒度视图开始。请注意，该图将基站描述为流水线(从左到右对发送到 UE 的数据包进行处理)，但同样也可以将其视为协议栈。图 54. RAN 处理流水线，包括用户平面和控制平面两个组件。关键阶段如下。RRC(无线资源控制, Radio Resource Control): 在流水线中负责粗粒度配置以及策略相关方面。RRC 运行在 RAN 的控制平面上，不处理用户平面报文。PDCP(分组数据聚合协议, Packet Data Convergence Protocol): 负责对 IP 报头进行压缩解压缩、加密和完整性保护，并做出"早期"转发决策(即数据包是通过流水线发送到终端还是转发到另一个基站)。RLC(无线链路控制, Radio Link Control): 负责分割和重组，通过实现某种形式的 ARQ(自动重复请求, automatic repeat request)实现可靠发送/接收。MAC(媒体访问控制, Media Access Control): 负责缓冲、多路复用和解多路复用，包括什么时候传输哪些分片的实时调度决策。还能够做出"延迟"转发决策(即转发到包括 WiFi 在内的备选载波频率)。PHY(物理层, Physical Layer): 负责编码和调制，包括前向纠错(FEC)。图 54 中的最后两个阶段(D/A 转换和 RF 前端)不在本书范围之内。下一步是理解上面概述的功能是如何在物理组件之间划分的，从而实现集中和分布式部署的"分割"。历史上主流实现是"不分割"，如图 54 所示的整个流水线在一个基站中运行。展望未来，3GPP 标准已经被扩展到允许多个分割点，图 55 所示的分割正在由运营商领导的 O-RAN (Open RAN)联盟所积极推动，这也是本章其余部分所采用的方法。图 55. Split-RAN 处理流水线分割为中央单元(CU)，分布式单元(DU)和无线电单元(RU)。结果就是产生了类似于图 56 所示的 RAN 范围的配置，有一个运行在云上的中央单元(CU, Central Unit) 服务于多个分布式单元(DU, Distributed Unit) ，每个 DU 又服务于多个无线电单元(RU, Radio Unit) 。关键是，RRC(集中在 CU 中)只负责近实时的配置和控制决策，而 MAC 阶段的调度器负责所有实时调度决策。图 56. Split-RAN 架构，一个 CU 服务于多个 DU，每个 DU 服务于多个 RU。由于无线传输的调度决策是由 MAC 层实时做出的，不能根据过时的信道信息做出调度决策，因此 DU 需要在管理的 RU"附近"(在 1ms 时延内)，常见配置是在同一个铁塔上部署 DU 和 RU。但是当一个 RU 对应一个小扇区，许多 RU 分布在一个中等大小的地理区域(例如，商场、校园或工厂)，那么一个 DU 可能会服务于多个 RU。5G 毫米波技术的采用可能会使后者更加普遍。9.3.2 RAN 智能控制器(RAN Intelligent Controller)RRC 在图 54 中显示为基站的一部分，在图 55 中显示为 CU 的一部分，代表 RAN 的控制平面。因为控制决策是集中制定的，因此 CU 的配置可以自然映射到 SDN，但其目标不仅仅是重新创建 RRC 功能的传统集合，还想为引入额外的控制功能铺平道路。为此，SD-RAN 采用了一种与其他领域中使用的网络操作系统/控制应用程序架构相平行的设计(并在本书中进行了描述)。其结果是图 57 所示的设计，其中 RAN 智能控制器(RIC, RAN Intelligent Controller) 是 O-RAN 架构文档所称的集中式 SDN 控制器(因此我们在接下来的讨论中采用了这个术语)。"近实时"限定符表示 RIC 是 CU 中实现的 10-100 毫秒控制回路的一部分，而不是运行在 DU 中的 MAC 调度器所需的 1 毫秒控制回路。图 57. RIC 集中控制分离式 RAN 层次架构中的组件。如果进一步深入进去，图 58 显示了基于 ONOS 的 SD-RAN 用例示例。最值得注意的是，基于 ONOS 的 RIC 支持一组特定于 RAN 的北向和南向接口，原则上(但不是细节上)类似于前面章节描述的接口(例如，gNMI, gNOI, OpenFlow)。我们将在下一小节讨论这些接口。图 58. 通过调整和扩展 ONOS 实现兼容 O-RAN 的 RIC。基于 ONOS 的 RIC 利用了第 6 章中描述的拓扑服务，但也引入了两个新服务: Control 和 Telemetry。建立在 Atomix 键/值存储基础上的 Control Service 管理所有基站和用户设备的控制状态，包括哪个基站为每个用户设备服务，以及可以连接设备的"潜在链接"集。Telemetry Service 建立在时间序列数据库(TSDB, Time Series Database) 的基础上，跟踪 RAN 组件报告的链接质量信息。各种控制应用程序分析这些数据，并就 RAN 如何才能最好的满足其数据交付目标做出明智决策。图 58 中的示例 Control Apps (xApps)包含了一系列的可能性，但这并不是详尽列表。这些功能(链路聚合控制、干扰管理、负载均衡和切换控制)目前由仅具有局部可见性的单个基站实现，但它们具有全局影响。SDN 方案是集中收集可用的输入数据，做出全局最优决策，然后将各自的控制参数推回基站执行。O-RAN 联盟自 3G 以来，一直由 3GPP (3rd Generation Partnership Project)负责移动蜂窝网络的标准化，O-RAN (Open-RAN Alliance)是由移动网络运营商组成的联盟，定义了基于 SDN 的 5G 实施战略。考虑到 3GPP 已经是负责全球蜂窝网络互操作性的标准化机构，为什么还会有 O-RAN 联盟？答案是，随着时间的推移，3GPP 已经成为由供应商主导的组织。O-RAN 是由网络运营商创立的(AT&T 和中国移动是创始成员)，其目标是推动基于软件的实现，以打破当今市场供应商的垄断。更具体来说，3GPP 定义了可能的 RAN 解耦点，而 O-RAN 指定(并编纂)相应的接口。特别是 E2 接口，是围绕支持不同服务模型的思想构建的，是这个策略的核心。运营商是否能成功实现最终目标还有待观察。9.3.3 RIC 接口回到图 58 中提到的三个接口，每个接口的用途都类似于前面章节中描述的接口。前两个，A1 和 E2，正朝着 O-RAN 标准化的方向发展。第三种是图 58 中所示的 xApp SDK，尽管 O-RAN 的长期目标是聚合在统一的 API(和相应的 SDK)上，但当前是基于 ONOS 实现的(概念上类似于 Flow Objectives)。A1 接口为移动运营商的管理平面(通常被称为 OSS/BSS(运营支持系统/业务支持系统))提供了配置 RAN 的方法。到目前为止，我们还没有讨论通信 OSS/BSS，但可以肯定的是，这样的组件位于任何通信软件栈的顶部，是操作网络所需的所有配置设置和业务逻辑的源头，可以把它看作是 gNMI/gNOI 在 RAN 中的对应组件。Near-RT RIC 使用 E2 接口来控制底层的 RAN 组件(包括 CU、DU 和 RU)，可以将它看作 OpenFlow 在 RAN 中的对应组件。E2 接口的要求是能够将 Near-RT RIC 连接不同供应商的不同类型的 RAN 组件。这个要求反映在围绕服务模型(Service Model) 抽象的 API 中，其思想是每个 RAN 组件都发布一个服务模型，定义该组件能够支持的 RAN 功能集，RIC 对这个服务模型发出以下四种操作的组合。报告(Report): RIC 要求组件报告特定功能的配置值。插入(Insert): RIC 指示组件激活某个用户平面功能。控制(Control): RIC 指示组件激活某个控制平面功能。策略(Policy): RIC 设置某个已激活功能的策略参数。当然，可以被激活的相关功能、可以报告的变量以及可以设置的测量都是 RAN 组件通过其发布的服务模型定义的。综上所述，A1 和 E2 接口完成了 RAN 的三个主要控制回路中的两个: 外部(非实时)回路以 Non-RT RIC 为控制点，中间(近实时)回路以 Near-RT RIC 为控制点。第三个(内部)控制回路，在图 58 中没有显示，它运行在 DU 内部，包括实时调度器，嵌入在 RAN 流水线的 MAC 阶段。两个外控制回路大概的时间边界分别为>> 1s 和>10 ms，并假设实时控制回路<1 ms。Near-RT RIC 打开了引入基于策略的 RAN 控制的可能性，因此，如果运营商定义的策略发生了中断(异常)，表明需要外部回路的参与。例如，可以想象开发基于学习的控件，这些控件的推理引擎将作为应用程序运行在 Near-RT RIC，而非实时的学习引擎可以在其他地方运行。然后，Non-RT RIC 与 Near-RT RIC 交互，通过 A1 接口从管理平面向 Near-RT RIC 交付相关操作策略。最后，xApp SDK 原则上是 Flow Objectives 在 RAN 中的对应组件，是基于 ONOS 实现的，目前仅仅作为 E2 接口的"透传"，这意味着 xApps 必须知道可用的服务模型。这是有问题的，因为隐式的将应用程序与设备耦合了起来，但定义与设备无关的版本还在进行中。9.4 SD-Fabric 的角色正如本章前面所概述的那样，PON 和 RAN 都配有 IP 网关，该网关增强了特定的接入特性。位于运营商网络边缘的网关负责对用户访问进行授权，区分向用户提供的服务级别，并向用户收费。当用户从一个基站移动到另一个基站时，移动核心网还承担了跟踪移动性的额外责任。这些附加功能大部分运行在控制平面(甚至管理平面)中，数据平面的行为与任何其他 L3 网络非常相似，这意味着数据平面可以通过前面章节中看到的机制实现，或者更具体的说，通过第 7 章中描述的 SD-Fabric 解决方案实现，但需要考虑这两种特定接入技术，以及对 SD-Fabric 的影响。将 PON 连接到 Internet 的 BNG 有供应商定义的控制/管理平面，因此不需要行业范围的标准。数据平面需要支持 Q-in-Q 标签作为区分订户服务的机制，这是 SD-Fabric 提供此功能的原因之一。这意味着图 53 中所示的 fabric 交换机与图 13(来自第 2 章)和图 39(来自第 7 章)中所示的 fabric 交换机完全相同。换句话说，SD-Fabric 既将 OLT 连接到互联网，又将一组承载 BNG 控制和管理功能(以及运营商希望在边缘运行的任何其他 VNF)的服务器连接起来。将 RAN 连接到互联网的移动核心网是由 3GPP 标准化的，这使它成为了定义良好的示例(只在高层架构讨论，完整的 3GPP 规范远远超出了本书范围)。图 59 给出了架构概述，确定了组成 5G 移动核心网的功能块。图 59. 5G 移动核心网架构概述。从这个图中可以看到，UPF(用户平面功能, User Plane Function) 实现了数据平面(3GPP 称之为用户平面)。其他所有功能都是控制平面功能，其中 AMF 负责移动性管理，SMF 负责会话管理，AUSF 负责身份验证。所有其他功能块都对应于低级流程，AMF、SMF 和 AUSF 调用这些流程来完成工作，但就我们的目的而言，可以将整个功能块视为运行在商业服务器上的微服务。关于移动核心网控制平面的更多细节，以及具体实现选择的示例，我们推荐 Magma 和 SD-Core 开源项目。延伸阅读:Magma Core Project. Linux Foundation. 2021.SD-Core Project. Open Networking Foundation. 2021.对于我们的讨论来说，重要的是 UPF 也可以作为服务器托管的微服务来实现，就像任何基于软件的路由器一样。由于可以访问可编程交换网络，可以将该功能转移到交换机上。这正是 7.4 节中fabric.p4的upf扩展所做的事情。但除了转发 IP 数据包之外，还有什么额外的功能呢？UPF 执行三个额外的任务。首先，封装/解封装和基站之间通信的数据包，这些是 GTP-over-UDP/IP 封装的数据包。其次，根据运营商希望提供的不同 QoS 级别对数据包进行排队。这两项任务都可以在 P4 和底层可编程交换机中直接实现。第三个任务是"保存"发送到最近发生移动的终端的数据包，以便在相应的会话状态转换期间没有数据包被丢弃。这不是现在 P4 交换机所能支持的。因此，交换机会临时将这些数据包重定向到服务器上进行保存和重放，或者重定向到连接到这些服务器的 SmartNIC 上。MacDavid 和他的同事介绍了更详细的机制。延伸阅读:R. MacDavid, et al. A P4-based 5G User Plane Function. ACM SOSR. September 2021.从讨论中我们得到的主要结论是，接入网和交换网是 SDN 的互补用例，可以协同工作。交换网不仅将承载接入网控制平面功能的服务器(包括 RIC 和 xApps)连接起来，而且还代表接入网运行某些数据平面功能。当所有这些用例结合起来时，最终的结果是边缘接入云(access-edge cloud) :一个中等大小的由商用服务器和交换机构建的集群，部署在企业和其他边缘站点中，能够承载接入网工作负载和边缘服务工作负载。Aether 就是这种边缘云的开源示例，它将 SD-Fabric、SD-RAN 和 SD-Core 组合在自包含的包中，可以在企业中部署，并作为云服务进行管理。延伸阅读:Aether: 5G-Connected Edge. Open Networking Foundation. 2021.

1.2.2 控制平面: 中心化 vs 分布式在解耦控制平面和数据平面之后，接下来要考虑的是如何实现控制平面。一种选择是在交换机上运行实现控制面的软件。这样做意味着每个交换机都作为自治设备运行，与整个网络中的对等交换机通信，以构建本地路由表。为了方便起见，已经存在一组可用于此目的的协议: BGP、OSPF、RIP 等。这正是过去 30 多年来互联网一直采用的分布式控制平面。这种场景自有其价值。由于解耦带来了使用商用硅交换芯片构建低成本裸金属交换机的可能性，网络运营商可以从裸金属交换机供应商购买硬件，然后从其他供应商购买适当的控制平面软件，甚至可能使用这些软件的开源版本。这样做可能会降低成本和复杂性(因为只需要将所需的控制模块加载到设备上)，但不一定能实现 SDN 所承诺的创新速度。因为运营商仍然停留在缓慢的标准化过程中，这是今天的标准化协议所暗示的，也没能实现 SDN 先驱们所设想的新的网络抽象(例如 Shenker 在上面的演讲中提到的)。另一种选择是控制平面完全独立于数据平面，并在逻辑上集中管理，这是 SDN 的第二个设计原则。这意味着控制平面是部署在交换机之外的，例如可以在云上运行控制器。为了完整起见，我们注意到也可以采用混合方法，在云托管的控制器中，一些控制功能运行在交换机上，一些运行在交换机之外。我们说逻辑集中是因为收集状态的控制器需要维护全局数据结构(相对于在每个交换机上维护路由表)，这个数据结构的实现仍然可以分布在多个服务器上，通过云的最佳实践，实现服务的水平扩展，这对于可伸缩性和可用性都很重要，其中关键是这两个平面是独立配置和扩展的。如果需要增加数据平面容量，可以增加裸金属交换机。如果控制平面需要更多容量，可以添加计算服务器(或者更可能的是虚拟机)。图 6. 网络操作系统(NOS)托管一组控制应用程序，并为底层网络数据平面提供逻辑上集中的控制点。图 6 描述了与分布式数据平面相关联的集中式控制平面，但是更进一步，还引入了这种方法所隐含的关键组件: 网络操作系统(Network Operating System, NOS)。服务器操作系统(如 Linux, iOS、Android、Windows)提供了一组高级抽象，可以更容易实现应用程序(例如,用户可以读取和写入文件，而不是直接访问磁盘驱动器)，NOS 与此类似，可以更容易实现网络控制功能，也称为控制应用程序(Control Apps)。NOS 背后的思想是抽象交换机细节，并向应用开发人员提供网络分布(Network Map) 抽象。NOS 检测底层网络变化(例如，交换机、端口和连接的可用状态)，而控制应用只是在这个抽象上实现想要的行为。这意味着 NOS 承担了收集网络状态的负担(分布式算法中最困难的部分，例如链路状态和距离向量路由协议等)，而应用可以免费使用相关抽象，并在图上运行简单的最短路径算法，并将构建的流规则加载到底层交换机。下面是关于链路状态(Link-State)和距离矢量路由算法(Distance-Vector routing algorithms)的在线介绍。延伸阅读:Routing. Computer Networks: A Systems Approach, 2020.通过集中化相关逻辑，可以实现以前在分布式网络中不可能实现的事情: 计算全局优化解决方案。正如在后面章节中讨论的那样，已经公布的来自云供应商的证据证实了这种优势。多年来大家都很清楚，互联网完全分布式的方法并不适合全局优化，但直到 SDN，还没有真正可行的替代方案。SDN 使这种可能性成为现实，这就是提供集中式网络抽象的力量。"收集网络状态"的想法是 SDN 和 NOS 所扮演角色的核心。我们不讨论收集网络遥测数据的所有使用方式，例如解决配置错误或做长期规划，但我们会谈论可能需要控制平面立即做出反应的精确控制，一个明显的例子是每个端口上发送和接收的字节/数据包的数量。像 OpenFlow 这样的协议定义了向 NOS 报告此类统计报告的方法，此外还为 NOS 提供了基于其收集的信息配置新流规则的方法。中心化控制平面还有一个相关好处，随着我们讨论 SDN 用例，这个好处将变得更加清晰。逻辑集中的控制平面提供了单一的网络公开 API。将可编程 API 放在单个交换机和路由器上的想法已经出现了几十年，但没有产生多大影响，相比之下，对于整个交换机或路由器集合的中心 API 可以支持各种各样新用例。其中包括网络虚拟化、网络自动化和网络验证。以自动化为例，将 BGP 配置这样的事情自动化是相当困难的，因为很难推断当一组 BGP 节点开始彼此交互时如何回应。但是，如果中央控制平面公开了 API，可以通过 API 实现"创建一个连接以下端点集的隔离网络"，那么将该请求作为自动化配置系统的一部分就相当合理了。这正是许多现代云中的情况，其中网络资源和策略的供应可以与所有其他类型的操作(如绑定虚拟机或容器)一起自动化。回到集中式控制平面与分布式控制平面的最初问题，后者的支持者往往基于互联网首先采用分布式路由协议的历史原因: 规模化和容错。需要注意的是，任何集中式解决方案都会导致瓶颈，也就是单点故障。在服务器集群上分布式部署集中化控制平面可以缓解这两个问题，因为基于分布式系统开发的技术可以确保此类集群的高可用性和可伸缩性。关于控制平面集中化的第二个问题是，由于控制平面是远程的(即在交换机之外)，两个平面之间的链接增加了脆弱的攻击面。相反的观点是，非 SDN 网络已经有(并依赖)带外管理网络，所以这种攻击面由来已久。控制器可以使用这些管理网络，就像其他管理软件一样。还有一种观点认为，少量的集中式控制器比大量的分布式控制器所呈现的攻击面更小。可以这么说，虽然意见不同，但肯定有很多人支持中心化方法。控制域(Domain of Control)本节的"集中式 vs 分布式"框架旨在描述 SDN 设计空间的一个维度，而不是表明网络运营商面临非此即彼的情况。有许多因素会影响给定运营商在这个问题上的决定，但首先要确定 SDN 应用的域的范围。我们将在第 2 章中讨论示例用例，但是网络的自然发展突出了这个思考过程。从历史上看，每个交换机都有一个控制平面实例，它们在同一个机器上运行。当简单的路由器发展为机架式路由器时，M 个线卡通常对应有 N 个控制平面实例，在独立的硬件上运行，并通过管理网络相互通信。随着机架式路由器从普通交换机发展为多机架结构，SDN 提出了一种设计，将转发元素集中在一个可以运行在任何地方的控制平面下，并构建一个分布式系统。这样一个系统的优势在于可以使用现代技术来进行状态分发和管理，而不用受制于标准，关键是找到能够有可能使用集中式逻辑控制平面优化性能的域。本书介绍了 SDN 可以提供提供价值的几个这样的领域。1.2.3 数据平面: 可编程与固定功能设计空间的最后一个维度是考虑数据平面交换机是可编程的还是固定功能的，我们需要多说一点交换机的实现，从而理解这意味着什么。前面我们用一个简单模型讨论交换机，交换机的主要处理逻辑是从输入端口接收数据包，查找目的地址的 FIB(或者使用 OpenFlow 的术语流表)，然后根据匹配的表项将数据包输出到端口或端口组，这是低端交换机的合理实现策略(通用处理器上可以通过软件实现这一主处理循环)，但高性能交换机采用基于硬件的转发流水线。我们将在第 4 章深入介绍处理流水线，但目前重要的特征是，该流水线是否仅限于匹配数据包报头中的固定字段集(例如图 4 所示字段)，并执行固定的操作，或者是否将匹配的位模式和要执行的动作动态编程到交换机中。前者被称为固定功能流水线(fixed-function pipelines)，后者被称为可编程流水线(programmable pipelines)。但首先我们必须回答这个问题: "转发流水线到底是什么?"一种方式是考虑转发流水线而不是单个流表，就像前一节介绍的那样，交换机实际上实现了一系列流表，每个表项关注一个头字段的子集，也许跟某一个流规则相关联(例如，一个表项匹配 MAC 头，一个匹配 IP 报头，等等)，给定数据包被多个流表按顺序处理，这就是流水线，并最终决定如何转发。图 7 基于 OpenFlow 规范给出了这种流表流水线的一般示意图。其思想是，在数据包流经流水线时收集一组操作，并在最后阶段作执行。图 7. OpenFlow 转发流水线简单示意图。乍一看似乎并不重要，因为如图 4 所示的头字段都是众所周知的，交换机很容易对每个包计算偏移量(例如，表 0 匹配 MAC 头字段，表 1 尝试匹配 IP 字段，等等)。在这一点上，SDN 的最初想法是有意不涉及数据平面，并完全专注于可编程开放控制平面，但早期实施 SDN 控制器的经验暴露出两个问题。第一个问题是，随着 SDN 从研究实验阶段逐渐成熟，成为传统专有交换机的可行替代品，性能变得越来越重要。虽然流规则足以说明控制器想要编程到交换机中的转发行为，但交换机不一定有能力以有效方式实现该功能。为了确保高转发性能，流表使用高度优化的数据结构来实现，这些数据结构需要专门的内存，比如三元内容寻址内存(TCAM, Ternary Content Addressable Memory)。结果是只支持有限数量的条目，这意味着控制器必须谨慎使用。简而言之，控制器必须知道流水线的详细信息，以便配置一组交换机可以映射到硬件的流规则。因此，许多控制应用程序隐式的绑定到特定的转发流水线。这类似于编写只能在 x86 处理器上运行的 Java 或 Python 程序，并且不容易移植到 ARM 处理器上。事实证明，对转发流水线有更多的控制是必要的，因为我们不想将自己限制在单个供应商的流水线上，还需要抽象方法来指定流水线的行为，从而可以映射到任何给定交换机的物理流水线上。第二个问题是协议栈以意想不到的方式发生了变化，这意味着可能需要匹配的所有报头字段都是公开的这一假设是有缺陷的。例如，虽然 OpenFlow(以及早期的转发流水线)正确的包含了对 VLAN 标记的支持，这是在企业网络中创建虚拟网络的基础，但 4096 个可能的 VLAN 不足以支撑云可能承载的所有租户。为了解决这个问题，IETF 引入了一种新的封装，称为虚拟可扩展 LAN(VXLAN, Virtual Extensible LAN)。与之前的方法(将虚拟以太网帧封装在另一个以太网帧中)不同，VXLAN 将虚拟以太网帧封装在 UDP 包中。图 8 显示了 VXLAN 报头，以及交换机为了做出转发决定可能必须处理的所有包报头。图 8. VXLAN 报头封装在 UDP/IP 报文中。向 OpenFlow 添加对 VXLAN 的支持已经足够困难了，因为标准的批准需要时间，但是向固定功能的转发流水线添加对 VXLAN 的支持则是更为耗时: 需要改变硬件！ 有人可能会说，有了 VXLAN，我们现在就完成了协议栈的变更，但这是不可能的。例如，当与 HTTP 一起使用时，QUIC 正逐渐成为 TCP 的替代方案。另一个即将出现的例子是 MPLS vs SRv6。甚至 VXLAN 在某些情况下也被一种称为 GENEVE 的更灵活的新封装所取代。可编程转发流水线，加上可用于对流水线进行编程的高级语言，是对这两个问题的一个可行应对。这两者都是在最近几年出现的，以协议独立交换体系架构(PISA, Protocol Independent Switching Architecture) 和 P4 编程语言的形式出现。我们将在第 4 章中更详细讨论这两个问题，但目前最大的收获是，SDN 已经超越了其作为控制平面编程手段的最初目标。今天，SDN 还囊括了可编程数据平面的可能性。1.3 SDN: 定义综上所述，SDN 的初始定义很简单:控制平面和转发平面在物理上相互隔离，一个控制平面可以控制多台转发设备的网络。-- 来自 Nick McKeown 2013 年题为"软件定义网络"的演讲。这是第 1.2.1 节和第 1.2.2 节大段内容的简洁表述。从最初的定义开始，SDN 就被不同的利益相关方解释为更少(例如，对网络设备的可编程配置接口被称为 SDN)和更多(例如，SDN 还包括具有可编程转发流水线的交换机)，本书以更广阔的视角涵盖了整个领域。另一种定义 SDN 的方法是把它看作两个阶段。阶段 1 中，网络运营商获得了控制平面的所有权，现在在阶段 2 中，他们正在控制如何在数据平面中处理数据包。第二阶段仍处于开发阶段，但正如 Nick McKeown 所假设的那样，理想的最终状态是:"网络(理想情况下)将更多的被编程，更少的被运维操作。"也就是说，SDN 不仅仅是将控制权从设备商转移到运营商，最终，它是将控制权从设备商转移到运营商，再转移到用户。这是一个长期目标，其灵感来自于商用服务器和开源软件对计算机行业的贡献。但是我们仍然有很长的路要走，所以我们在第 10 章中对 SDN 旅程的下一阶段进行了适度的预测。延伸阅读:N. McKeown. FutureNet 2019. October 2019.

互联网流量正在每年以指数级增长，为了更高效的处理网络流量，各个组织都在开展下一代网络的研究和实验。特别是结合了 SDN、Segment Routing、带内遥测、应用感知等机制的技术和网络架构，得到了极大的关注。这篇文章介绍了欧洲 SIDN 实验室基于 P4 和 Intel Tofino 构建的 SCION 架构网络的实验，以一种灵活的、软件定义的方式，实现太比特速率的网络路由。原文链接：Future internet at terabit speeds: SCION in P4作为 2STiC 项目[1]的一部分，我们一直在 SIDN 实验室评估和试验未来的互联网架构，其中正在研究的一个架构是 SCION[2]。SCION 代表的是下一代网络的可扩展性、可控制性和隔离性，由瑞士苏黎世联邦理工大学及其附属公司 Anapaya Systems 开发。SCION 的目标是通过安全的域间路由和路径感知网络实现一个安全、稳定和透明的互联网。之前我们介绍了 SCION[3]（推荐还不熟悉 SCION 的读者阅读这篇介绍），并在视频演示[4]中展示了该技术的实际应用。在这篇文章中，我们会介绍基于 Intel Tofino 和 P4 实现的高速 SCION 路由器的原型。我们的目标是评估是否能利用 P4（一种网络设备编程语言）提供的灵活性，在硬件上直接运行 SCION 这样复杂的协议。SCIONSCION 实现了路径感知网络。这意味着发送方可以在自治系统（ASs，autonomous systems）级别上选择流量通过互联网的路径。这个被选择的路径，称为转发路径，并且会被包含在每个包中。转发路径由若干个所谓的 hop 字段组成。一个 hop 字段包含一个特定 AS 如何转发数据包的指令。另外，hop 字段通过加密 MAC 的保护，以确保只使用被授权的路径。正如我们在之前的文章[3]中所解释的那样，一条路径最多可以由三个路径段组成，其中每个路径段都由多个 hop 字段组合而成。组合之后，不同路径段中的 hop 字段定义了数据包将要遵循的路径。因此，路由器不再需要存储巨大的路由表[5]来转发带有特定 IP 前缀的数据包。相反，它们只需要查看包中的当前 hop 字段来决定将其转发到哪里。P4P4[6]是一种用于在交换机和网卡等网络设备上处理数据包的领域特定语言（DSL，Domain Specific Language）。它允许为网络设备增加对新协议的支持。这样做的好处是，我们不再需要等待供应商实现新的协议，并且可以轻松地在硬件上试验新的协议。P4 可以用来对软件交换机进行编程，但我们使用 P4 在 Intel Tofino ASIC[7]上实现 SCION 交换机。P4 中的一个关键概念是使用匹配操作表（match-action tables），这允许我们基于当前正在处理的包中所包含的值执行特定的操作。例如，在以太网中，我们匹配包中包含的目的 MAC 地址。根据查表结果，我们要么将数据包发送到一个特定的出口端口（如果匹配到了一个表项），要么将数据包发送到所有端口。在数据平面上可以以线速进行匹配，但是，添加和删除表项会比较慢，而且需要通过控制平面完成。实现 SCION加密的挑战基于 SCION 协议规范，我们开发了一个 SCION 边界路由器，负责在相邻的 AS 之间转发数据包。我们的实现包含了多个组件：P4 实现本身和若干个控制平面组件(见图 1)。当我们为 Tofino 实现 SCION 协议时，主要的挑战在于 Tofino 芯片缺乏对加密操作的支持。由于 hop 字段包含一个加密的 MAC，我们需要对所处理的每个包执行一个加密操作。一种方案是将数据包转发到控制平面进行验证，但这个流程会非常慢，将对性能造成严重的限制。幸运的是，hop 字段只用于基本 SCION 协议中的几个包。我们在当前实现中用一个静态表记录当前所有有效的 hop 字段，通过这种变通方案，我们暂时可以解决 Tofino 缺乏加密支持的问题。通过该表，我们可以验证输入报文的 hop 字段：如果在表中存在，则 hop 字段有效；否则，就认为它无效，数据包将被丢弃。为了支持这个功能，我们修改了生成 hop 字段的 SCION 控制服务器，以便在交换机上注册生成的 hop 字段。我们还需要添加对所谓的单跳路径的支持，它用于与尚未建立路径的直连节点通信。为了建立连接，第一个包不包含接收网络的有效 hop 字段，而是依赖边界路由器添加相应的字段。由于我们不能在数据平面中生成 hop 字段，所以我们用单跳路径将传入的数据包转发到交换机的控制平面。在那里，一个正确的 hop 字段会被计算出来并被添加到表中，然后更新的数据包被返回到数据平面并正常处理。最后，有一个进程会定期检查表中过期的 hop 字段并删除它们。因为我们不能很容易地检查数据平面中 hop 字段包含的时间戳，因此我们通过控制平面删除过期的 hop 字段。图 1：控制平面与数据平面的交互如果我们采用 SCION 信标的默认设置，即信标间隔 5 秒，有效时间约为 6 小时，我们将需要存储每个上游路径和下游接口组合的约 4250 个 hop 字段。在同时支持 IPv4 和 IPv6 的情况下，我们目前可以存储大约 16 万个 hop 字段，而在只支持 IPv4 或 IPv6 的情况下，我们可以存储大约 20 万个 hop 字段。例如，在后一种情况下，我们可以支持 3 个上游路径和 15 个下游接口。在实践中，这将取决于所使用的信标策略和设置。请注意，因为我们还没有对当前实现进行优化，所以这里可能还有改进的空间，从而可以最大限度地提高 MAC 验证表的容量。另外，如果自治系统中有多个边界路由器，则支持的 hop 数量可能会更多。还要注意，这里我们没有考虑单跳路径，但是实际网络中不太可能有很多单跳路径，而且我们可以为单跳字段设置相对较短的过期时间。对 SCION 报头的修改当我们开始实现时，遇到了 SCION 协议头格式的几个问题，这使得在我们的硬件上实现它变得困难或效率低下。例如，转发路径的结构相当复杂。转发路径由嵌套的列表结构组成：第一级列表包含一个信息字段，每个信息字段后面跟着另一个包含 hop 字段的列表。然后对每个路径段重复这个结构。虽然该结构在软件中编程相当简单，但在硬件上直接实现时，所有资源都需要静态分配，这是一个很大的挑战。另一个例子是，报头包含一个字段，该字段指示用于终端主机的地址类型，例如 IPv4 地址和 IPv6 地址。这些地址类型有不同的长度。数据包中只包含这些地址的类型，而不是长度，这就意味着终端主机之间的每个节点都需要知道地址类型。但是中间节点本来只需要知道地址的长度，因为它们本身并不处理地址。我们将这些和其他观察结果反馈给 SCION 团队，并提供建议的解决方案。这些解决方案随后包含在一个新版本的 SCION 报头中。例如，转发路径结构问题的解决方案是：首先包含不同分段的所有通用信息字段，然后列出所有 hop 字段。这使我们能够更有效地实现 SCION，并在路径中支持更多的 hop 字段。新旧路径布局设计如图 2 所示。图 2：SCION 报头中转发路径的新旧布局原型中实现的功能我们已经实现了 SCION 的基本转发功能。然而，我们还不支持所有的 SCION 功能。例如，我们还没有添加对等或返回 SCMP 错误消息的支持、通过为 SCION 提供额外安全性和 QoS 的 EPIC 和 COLIBRI 扩展、绑定到单个包的 hop 字段中的加密 MAC。因此，对于这些数据包，我们将不再能够使用将完整的 hop 字段存储在表中以进行验证的方案。根据使用这些扩展的数据包的数量，可以采用将它们转发到交换机的控制平面进行验证的方案，或者转发到提供硬件加密支持的外部节点。运行原型我们首先在 Tofino 软件模型上进行测试，以验证其功能。一旦它可以工作，我们就知道在实际硬件上运行也不会问题。为了实际运行我们的系统，我们使用了 2STiC 试验台[8]，该试验台由 P4 可编程设备组成，由位于荷兰的多个 2STiC 联盟合作伙伴部署。在我们的测试中，使用了三个 Edgecore Wedge 100BF-32X[9] 交换机，它有 32 个 QSFP28 端口，每个端口支持高达 100 Gbps 的传输速率。总的来说，每个交换机的最大吞吐量为 3.2 Tbps。另外，我们正在连接一个 APS Networks 的 BF2556X-1T[10]交换机，该交换机通过其 48 个 SFP28 和 8 个 QSFP28 端口提供 2.0 Tbps 的最大吞吐量。我们在一个小型网络拓扑上运行我们的系统，该网络由三个 SCION AS 组成，位于 2STiC 试验台的不同地点，并且正在连接第四个 AS（如图 3 所示）。在我们的测试中，每个 SCION AS 都包括上面的一个可编程交换机作为边界路由器，以及一个连接到相应交换机提供其他 SCION 服务的服务器。通过测试，我们展示了该系统在实际场景中的工作情况。今后将进行包括性能分析在内的更详细的评估。图 3：在 2STiC 测试平台上的测试网络拓扑，包括一个尚未连接的附加 AS。其中，AS112 是隔离域的核心，包含所有 AS 结论通过我们的实现，展示了 P4 和可编程网络设备的健壮性和灵活性，这允许我们在 ASIC 上直接运行 SCION 协议的实现。同时，我们已经证明可以在硬件上高速运行 SCION。我们的实现已经在 Github 上开源[11]。未来的工作包括优化实现以提供更高的性能，以及添加额外的功能和试验对 SCION 扩展的支持，如 EPIC 和 COLIBRI。我们将在今后的文章中更详细地讨论我们的实现和经验教训。致谢感谢 SURF[12]为 2STiC 测试台提供物理基础设施。这项工作是 2STiC 研究计划的一部分，这是一个由 AMS-IX、代尔夫特理工大学、NDIX、NLnet 实验室、SIDN 实验室、SURF、阿姆斯特丹大学和特文特大学合作的项目。Reference:[1] https://www.2stic.nl/[2] https://www.scion-architecture.net/[3] https://www.sidnlabs.nl/en/news-and-blogs/new-internet-infrastructures-an-introduction-to-scion[4] https://www.sidnlabs.nl/en/news-and-blogs/a-practical-demo-of-scion-a-new-internet-architecture[5] https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/[6] https://p4.org/[7] https://www.intel.com/content/www/us/en/products/network-io/programmable-ethernet-switch/tofino-series.html[8] https://www.2stic.nl/national-programmable-infrastructure.html[9] https://www.edge-core.com/productsInfo.php?cls=1&cls2=5&cls3=181&id=335[10] https://www.aps-networks.com/products/bf2556x-1t/[11] https://github.com/SIDN/p4-scion[12] https://www.surf.nl/