见微知著-浅析数通交换机之二

前言

交换机是数通行业高速发展的一个缩影。“点石成金”的先驱们不懈的探索，使交换机产业迅猛发展。相比于时下的交换机，早期的产品，无论是性能还是功能都有很大差距，但每个产品的出现都有其时代意义。让我们进入时光隧道，跟随前辈的足迹，去探访垦荒的年代吧。
本文既非工程学术文档，亦非原厂文宣，乃见微知著，温故而知新，文笔粗拙，贻笑大方。

<续前文>

2.4.5 分类引擎的实现

不同的应用对分类引擎的性能要求会有差异，这主要取决于：

1）支持的分类规则的性质

2）连接端口的数据速率

3）分类前可能聚合的端口数

一般情况下，分类引擎只能看到来自某个端口的VLAN标记的数据帧。如果没有要叠加处理的隐含规则，引擎所要做的工作就比较简单，只需解析标记并提取相关字段（如VLAN标识符和优先级等）。由于这都是固定操作，几乎不需要什么灵活性，所以这些功能可以使用硬件逻辑实现。

由于支持多个聚合的百兆或千兆端口的接入交换机可能要处理数量众多且复杂的VLAN或优先级分配规则，所以简单的硬件逻辑通常无法提供所需的功能或灵活性。此外千兆线速转发意味着每秒处理近150万帧。因此，分类引擎会是接入交换机研发中极为重要的部分。此类引擎的工程实现有以下考量点：

硬件逻辑：如果VLAN和优先级规则仅限于简单的算法（如基于端口、MAC地址或协议类型等），则分类引擎仍可以使用固定功能逻辑来实现。即用专门设计电路来解析和提取相关预定帧字段中的信息。注意，以相对较低的成本来实现线速转发，是以低规则复杂性为前提的。

分类处理器：如果需要处理的规则有较大的灵活性，则可使用CPU来解析和分析数据帧。此分类处理器上会运行精确字段检测所需执行的操作，为此必须进行权衡。基于CPU的设计可以提供很大的灵活性，但性能将弱于以相同成本提供的基于纯硬件的解决方案。只能靠增加成本来提高处理性能（采用更快的或多个处理器），或者只能是更低的性能（较慢的端口数据速率或非线速转发）。因而市场上出现了许多专门为分类引擎和类似用途而量身定制的专用网络处理器。它们通常包括多个RISC处理器、嵌入式控制存储器和针对交换机应用而优化的高速数据路径。

可编程状态机：虽然CPU非常灵活，但基于软件的引擎对于非常高的端口速率（如千兆或更高）有时可能性能不济。标准的嵌入式CPU可以提供比实际需要更多的灵活性。分类引擎必须根据一组预编程的规则高速解析和比较数据帧字段，但它不需要通用CPU所提供的较多的算力或数据处理功能。因此，一些高性能交换机的设计会将解析和比较引擎使用可编程有限状态机来实现，而不是使用传统的CPU。最终，VLAN或优先级规则集可以用一系列位字符串和偏移量来表示，这些位字符串和偏移量将与接收到的数据帧进行比对。可采用可配置的硬件，用于固定或可变位置字段中的任意模式匹配进行优化，而不是用软件实现。所需的逻辑数量会比采用通用CPU少很多。因此，与基于纯软件的解决方案相比，可以用更低的成本实现性能优化。可编程状态机可以用传统逻辑实现，作为可编程微引擎（本质上是具有高度限制指令集的专用CPU），甚至可以通过现场可编程门阵列（FPGA）中的嵌入式逻辑块实现。在大多数情况下，嵌入式存储器（通常是SRAM）用于存储规则集。正常情况下，千兆以太网的完整数据帧会每隔672ns到达一次。即使是采用专用逻辑也很难在此间隔时间内处理大量规则。因此，无论采用何种方法，大多数实现都会采用某种形式的流水线技术进行处理，以便依照顺序处理多个规则。流水线为分类处理留出了更多时间。但是，它会增加所有已处理数据帧的绝对时延。即可通过设置流水线并在多个数据帧上并行处理各种规则来对数据帧进行分类，每个数据帧会进入交换机转发之前的流水线进程。注意，流水线时延需要在合理的限度内设置上限，即不能用任意长的流水线来解决分类处理的性能问题。对于时间敏感型应用程序流（如交互式语音流量）的高优先级数据帧，必须确保系统在确定其优先级时不会产生过度时延。该时延会导致对适用于某一特定功能的规则数量设定了上限。

2.5VLAN筛选器

VLAN筛选器模块实现了VLAN输入筛选器功能。

可接受的数据帧筛选器：核心交换机可以做到仅允许转发带有显式VLAN标记的数据帧，并丢弃未标记的数据帧。如前图所示，交换机数据帧头会有一个标志位，指示在收到数据帧时是否做了标记。可接受的数据帧筛选器只需检查此标志并采取适当的操作。

无论交换机采用何种方法转发未标记数据帧，目标地址位于保留组播范围内的数据帧仍必须在本地处理。例如核心交换机仍必须实现生成树协议，其数据帧可能未标记。因此交换机数据帧头中BPDU标志位如果被置位，将覆盖VLAN可接受的帧筛选器。BPDU必须始终被传递到本地内部管理处理器。

VLAN入口筛选器：在管理控制下，当接收数据帧的端口不处于数据帧所属的VLAN设置的成员中时，交换机可能会接受（或拒绝）数据帧。当设置为拒绝时，VLAN将变为对称;仅接受来自还允许交换机为此VLAN发出数据帧的端口的帧。非对称VLAN可以通过接受来自禁止交换机为给定VLAN发送数据帧的端口的帧来创建。

2.6 查找引擎

查找引擎是交换机转发流程的核心组件。此模块必须决定如何处理已成功通过所有先前的收集、分类和VLAN筛选器操作的数据帧。查找的结果是给定数据帧和输出端口的对应关系，以便进一步处理可能的传输。

对筛选数据库执行表查找。此动态维护的数据库包含目的地址和VLAN到可访问目的端口的当前映射。对于支持IEEE802.1p组播修剪的交换机，筛选数据库将包括单播和组播映射。在没有查找失败的情况下，发送到单播目的地址的数据帧应映射到单个输出端口，发送到组播目的地址的数据帧将映射到一个或多个输出端口。

下图为VLAN筛选数据库工作流程示意图：

2.6.1 生成输出矢量

如上图所示，查找引擎将接收数据帧中的目的地址、该数据帧所属的VLAN以及内部交换机数据帧头中的标志位作为其输入，并提供此数据帧将要转发到的端口矢量作为输出。目的地址位于数据帧缓存区内的已知位置（通常是数据帧中的第一个字段），VLAN标识符和标志位存储在内部交换机数据帧头中，这是由分类引擎完成确定的。在这种情况下，只需要目的地址来确定适当的输出端口，VLAN成员身份信息不会改变查找决策。在VLAN感知交换机中，在确定要转发每个接收数据帧的端口时，必须考虑VLAN成员身份，不能将数据帧发送到不在为与该数据帧关联的VLAN设置的成员的端口上。

下图为筛选数据库处理流程示意图：

根据筛选数据库的内容，输出端口向量可以是：

单个输出端口：以下是数据帧的典型应用场景：目的地址是已知单播，并且从中获知数据库表项的端口位于接收数据帧所属的VLAN的成员中。目的地址是已知的组播，只需要一个端口即可到达侦听该组播的所有设备，并且该端口位于接收的数据帧所属的VLAN成员中。

多个输出端口：如果目的地址是组播或未知单播，则可以将数据帧转发到多个输出端口。该数据帧将被定向到为接收的数据帧所属的VLAN设置的成员中的所有端口（数据帧到达的端口除外）。

本地内部管理处理器端口：为简化查找引擎的设计，本地内部管理处理器通常会是交换机的一个端口，即引擎的可能输出之一是本地数据帧。在以下场景中，数据帧可能会被定向到本地处理器端口：分类引擎已确定数据帧在为链路约束协议保留的地址范围内（如内部交换机标数据帧头中的标志位所示）。

目的地址与交换机上启用的GARP应用程序（如GMRP或GVRP）相关联：目的地址等于交换机端口之一的MAC地址，即数据帧作为终端发送到交换机本身。这些数据帧可以封装网络管理流量（如SNMP、Telnet等）或在交换机上运行的任何其他更高层应用程序。

查找失败处理：本地内部管理处理器可用于处理查找异常情况，如接收属于交换机未知的VLAN的数据帧。

在某些情况下，除了交换机的一个或多个输出端口之外，将数据帧转发到本地内部管理处理器会是一种实现方法。当数据帧携带组播目的地址，并且本地内部管理处理器参与该组播地址映射到的更高层应用程序或协议时，可能会发生这种情况。

无输出端口：在某些情况下，查找引擎应丢弃数据帧，甚至不将其发送到本地内部管理处理器。如在使用纯独立VLAN学习的交换机中，如果接收到具有已知单播目的地址数据帧，但其VLAN关联与该目的地址所属的VLAN关联不同，则应丢弃该数据帧。无论目的地址是否已知，VLAN都是不正确的，不应转发该数据帧。注意，数据帧是永远不会被转发到它到达的同一端口。这会违反数据链路的非重复不变性规则。

2.6.2 维护过滤数据库

实际上，只需通过源地址学习和老化即可维护简单桥接中的过滤数据库。功能齐全的交换机不仅需要知道每个已知单播源的端口映射，还需要知道已注册组播地址的映射以及为每个VLAN设置的端口成员信息。因此过滤数据库由各种进程所管理维护，如上图所示：静态数据库表项通过网络管理在管理员控制下人工手动创建和修改。

动态单播表项是通过检查接收数据帧中的源地址来学习的。组播表项是通过GARP组播注册协议（GMRP）学习的。端口VLAN映射通过管理员控制和GARPVLAN注册协议的组合进行维护。地址学习可以针对每个VLAN或同一数据结构中的多个VLAN独立执行。

2.6.3 查找实现

查找引擎的实现通常高度绑定于产品和供应商。根据查找操作的复杂性以及所支持的端口的数量和速率，查找引擎有下列实现方式：

内容可寻址存储器（CAM）：通过专用关联存储提供几乎即时的搜索和更新功能。伪CAM，即使用标准存储器（通常是SRAM）和模拟CAM操作的有限状态机。与真正的CAM相比，伪CAM的成本和性能都较低。嵌入式微型引擎在软件控制下提供灵活、可编程的查找。

方法的组合：如用于最近使用的表项缓存的小型CAM，以及在缓存未命中时基于CPU的回退。

查找引擎通常有以下两种工程实现方式：

集中式查找：在此工程实现方式中，单个引擎用于对从所有端口接收的所有数据帧执行表查找，如下图所示。

虽然此引擎的负载是所有端口的查找要求的总和，但整个交换机只需要一个引擎，从而降低了总体成本。由于单个引擎的性能限制，此方式主要用于速率相对较低的中等数量端口的交换机（如百兆以太网桌面和工作组交换机）。当使用共享内存或共享总线交换结构时，集中式查找最合适。

分布式查找：如果单个查找引擎无法跟上交换机上所有端口的数据帧到达速率，则通常需要为每个端口或端口组提供单独的查找引擎，如下图所示：

虽然该工程实现方式的成本通常大于单个查找引擎的成本，但此方式提供了更高、更具可扩展性的性能级别。组合的查找引擎的功能随着交换机上部署的端口数量而增加。除了增加的成本之外，还必须解决正确分发和维护过滤数据库内容的问题，以便查找引擎以一致的方式运行。通常，这意味着存在用于在端口接口之间分发数据库更新的控制数据路径。筛选数据库常在高速RAM中实现，位于查找引擎本身的外部。根据查找引擎所需的内存带宽，内存接口可以是传统的地址/数据总线，也可以使用DDR或其他加速技术。随着芯片密度的增长，新的设计使用嵌入式存储器，即筛选数据库可以位于查找引擎芯片本身，由于内存的宽度几乎是无限的，所以这就可以实现极高速的内存交换率。无需使用传统的32位或64位宽数据路径，内部存储器宽度可以是256位、512位或更多位，从而有效地增加可用内存带宽。

<未完待续>

%astra%