关于 Linux 中 firewalld 的一些笔记整理
写在前面嗯,今天和小伙伴们分享一些 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
自智网络简介
概要随着人们日常生活中依赖的网络设备、系统和应用程序越来越多,对网络的管理比以往任何时候都更加重要。应用程序对网络安全、可用性和性能的要求越来越高,并且要求在跨越不同协议和系统的复杂网络上实时解决网络问题,使得对网络的管理越来越困难。就在网络管理的重要性日益提升的时候,网络却已经变得如此复杂以至于似乎无法管理。在这样一个新时代,网络管理需要有根本性变更,而不只是闭合优化分析个别协议。网络运营商需要数据驱动,基于机器学习的端到端模型,基于高级策略目标的应用程序性能优化,以及底层组件的整体视图。运营商需要能够基于分类和检测算法做出实时闭环决策,而不只是对网络检测数据执行离线分析异常检测算法。换句话说,网络应该学会自我驱动。这篇论文探讨了这一概念,并讨论应该如何实现这一目标。达成这一雄心勃勃的目标需要将测量和实时控制更紧密耦合在一起,并依靠学习对网络应用和系统进行推理和预测,而不是对个别协议进行闭合分析。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 系统方法 | 9. 接入网
随着互联网和数据中心流量的爆炸式增长,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.