本页说明数据包如何流经 MikroTik RouterOS，详细介绍了桥接、路由、MPLS 决策与防火墙链之间的交互。文中包含展示从入口到出口各数据包处理阶段的示意图，以及路由表和防火墙链等关键组件的说明。

RouterOS 中的数据包流

更高级的防火墙设置，或复杂任务（例如流量优先级划分、路由策略），在需要利用多个 RouterOS 功能时，都需要了解：这些功能如何协同工作？何时以及为何会发生什么？

RouterOS 数据包流示意图和流程示例将尝试回答这些问题。

要在一张图中表示数据包发生的一切会非常复杂；因此，数据包流示意图被分为三个部分：

• 总体示意图。
• 详细的桥接、路由和 MPLS 流程图。
• 显示 prerouting、input、forward、output 和 postrouting 中包含哪些功能以及按什么顺序排列的示意图。

总体数据包流示意图

让我们看一下总体示意图。它乍看之下很复杂，但当我们结合示例梳理该图之后，它就会变得清晰得多。

示意图中央有 4 个方框：Bridging、Routing、MPLS decisions 和 local router processes。例如，如果数据包需要通过路由器进行路由，数据包将按下图所示的方式流动。无需深入每个功能，数据包进入 in-interface，路由器确定它是 IP 流量且需要被路由，数据包经过所有路由处理并从 out-interface 离开。

让我们看另一个示例，它说明了当数据包的目的地是路由器时会发生什么。例如，in-interface 收到一个 ICMP（ping）数据包，其目的地是路由器本身，因此该数据包将进入 local-in 处理。数据包处理完毕后，路由器内部会生成一个 ICMP（ping）回复（local-out 处理），并通过 out-interface 发送出去。

在我们进一步举例之前，先简单说明每个方框：

• Physical in-interface —— 路由器接收数据包的起点。
• Logical in-interface —— 解封装后数据包（来自隧道、IPsec 等）的起点。
• Local in —— 目的地为路由器本身的数据包的最后一个点。
• Interface HTB (Hierarchical Token Bucket) —— 接口队列。
• Physical out-interface —— 数据包实际发送出去之前的最后一个点。
• Logical out-interface —— 数据包封装之前（到隧道、IPsec 等）的最后一个点。
• Local out —— 路由器生成的数据包的起点。

现在是时候更深入地了解桥接、MPLS 和路由流程内部发生了什么。

在我们进一步举例之前，先简单说明每个方框：

• Routing decision —— 遍历路由表中的路由，为数据包的目的 IP 地址查找匹配项。找到匹配项时——数据包将被进一步处理；没有匹配项时——数据包将被丢弃。
• MPLS decision —— 根据 MPLS 转发表决定如何处理数据包。
• Bridging decision —— bridge 遍历 MAC 地址表，为数据包的目的 MAC 地址查找匹配项。找到匹配项时——数据包将被进一步处理；没有匹配项时——将创建数据包的多个副本，并洪泛发送数据包（通过所有 bridge 端口发送）。单个数据包副本也会到达 bridge input 链，因为 bridge 接口本身也是众多目的地之一。使用 vlan-filtering=yes 时，因 /interface/bridge/vlan 表而不被允许的数据包将在此阶段被丢弃。
• use-ip-firewall —— bridge 设置中是否启用了 'use-ip-firewall' 选项。
• ipsec-policy —— 数据包是否匹配任何已配置的 IPsec 策略。

链

RouterOS 由几个默认链组成。这些链允许你在各个点过滤数据包：

• PREROUTING 链：此链中的规则适用于刚刚到达网络接口的数据包。此链存在于 nat、mangle 和 raw 表中。
• INPUT 链：此链中的规则适用于即将交给本地进程处理的数据包。此链存在于 mangle 和 filter 表中。
• OUTPUT 链：此处的规则适用于进程刚刚产生的数据包。此链存在于 raw、mangle、nat 和 filter 表中。
• FORWARD 链：此处的规则适用于任何通过当前主机路由的数据包。此链仅存在于 mangle 和 filter 表中。
• POSTROUTING 链：此链中的规则适用于刚刚离开网络接口的数据包。此链存在于 nat 和 mangle 表中。

prerouting、input、forward、output 和 postrouting 块中的每一个都包含更多功能，这些在数据包流示意图的第三部分中进行了说明：

在我们进一步举例之前，先简单说明每个方框：

• Hotspot-in —— 允许捕获否则会被连接跟踪丢弃的流量——这样我们的 Hotspot 功能即使网络设置一片混乱也能提供连接。
• RAW Prerouting —— RAW 表 prerouting 链。
• Connection tracking —— 数据包由连接跟踪处理。
• Mangle Prerouting —— Mangle prerouting 链。
• Mangle Input —— Mangle input 链。
• Filter Input —— 防火墙 filter input 链。
• HTB Global —— 队列树。
• Simple Queues —— 可用于为特定目标限制流量的功能。
• TTL —— 指示路由数据包的 Time To Live（TTL）减少 1 的确切位置。如果 TTL 变为 0，数据包将被丢弃。
• Mangle Forward —— Mangle forward 链。
• Filter Forward —— Filter forward 链。
• Accounting —— 身份验证、授权和计费（AAA）功能处理。
• RAW Output —— RAW 表 output 链。
• Mangle Output —— Mangle output 链。
• Filter Output —— 防火墙 filter output 链。
• Routing Adjustment —— 这是一种变通方法，允许在 mangle 链 output 中设置策略路由（routing-mark）。
• Mangle Postrouting —— Mangle postrouting 链。
• Src Nat —— 网络地址转换 srcnat 链。
• Dst Nat —— 网络地址转换 dstnat 链。
• Hotspot-out —— 对返回客户端的数据包撤销 hotspot-in 所做的一切。

路由数据包的处理流程

Forward

现在，让我们来看第一个示例：数据包通过路由器被路由，并深入了解数据包经过哪些功能：

我们已经了解到，数据包进入 in-interface，路由器确定它是 IP 数据包且需要被路由，这里就开始复杂的流程：

1. 数据包进入 prerouting 处理：
   1. 检查是否存在 hotspot，并为 hotspot 使用而修改数据包。
   2. 通过 RAW prerouting 链处理数据包。
   3. 将数据包发送通过连接跟踪。
   4. 通过 Mangle prerouting 链处理数据包。
   5. 通过 NAT 的 dst-nat 链处理数据包。
2. 让数据包经过路由表以做出路由决策。
3. 数据包进入 forward 处理：
   1. 检查 TTL 值。
   2. 通过 Mangle forward 链处理数据包。
   3. 通过 Filter forward 链处理数据包。
   4. 将数据包发送到 accounting 处理。
4. 数据包进入 postrouting 处理：
   1. 通过 Mangle postrouting 链处理数据包。
   2. 通过 NAT 的 src-nat 链处理数据包。
   3. 如果存在 hotspot，撤销在 hotspot-in 中所做的任何修改。
   4. 通过队列树（HTB Global）处理数据包。
   5. 通过简单队列处理数据包。
5. 检查是否存在 IPsec，然后通过 IPsec 策略处理。

Input

我们已经了解到，数据包进入 in-interface，路由器确定它是 IP 数据包且需要被路由，这里就开始复杂的流程：

1. 当数据包的目的地是路由器（routing input）时，会发生非常类似的过程：数据包进入 prerouting 处理：
   1. • 检查是否存在 hotspot，并为 hotspot 使用而修改数据包。
   2. • 通过 RAW prerouting 链处理数据包。
   3. • 将数据包发送通过连接跟踪。
   4. • 通过 Mangle prerouting 链处理数据包。
   5. • 通过 NAT 的 dst-nat 链处理数据包。
2. 让数据包经过路由表以做出路由决策。
3. 数据包进入 input 处理：
   1. • 通过 Mangle input 链处理数据包。
   2. • 通过 Filter input 链处理数据包。
   3. • 通过队列树（HTB Global）处理数据包。
   4. • 通过简单队列处理数据包。
4. 检查是否存在 IPsec，然后通过 IPsec 策略处理它。

Output

或者当数据包由路由器产生时（routing output）：

1. 数据包由路由器本身产生。
   1. 数据包经过路由表以做出路由决策。
2. 数据包进入 output 处理。
   1. 通过 Bridge decision 处理数据包。
   2. 将数据包发送通过连接跟踪。
   3. 通过 Mangle output 链处理数据包。
   4. 通过 Filter output 链处理数据包。
   5. 将数据包发送到 routing adjustment（策略路由）。
3. 数据包进入 postrouting 处理。
   1. • 通过 Mangle postrouting 链处理数据包。
   2. • 通过 NAT 的 src-nat 链处理数据包。
   3. • 如果存在 hotspot，撤销在 hotspot-in 中所做的任何修改。
   4. • 通过队列树（HTB Global）处理数据包。
   5. • 通过简单队列处理数据包。
4. 检查是否存在 IPsec，然后通过 IPsec 策略处理。

桥接数据包的处理流程

下面讨论 RouterOS 中一般的桥接过程。大多数数据包总是遵循相同的处理路径，但在某些配置中（例如启用 VLAN filtering、horizon、STP、DHCP 或 IGMP snooping 时），一些数据包可能会被区别对待。请访问桥接手册以获取更具体的信息。

Bridge Forward

Bridge forward 是当一个数据包从一个 bridge 端口转发到另一个 bridge 端口时发生的过程，本质上是连接同一网络上的多个设备。在 in-interface 上收到数据包后，设备确定 in-interface 是一个 bridge 端口，因此数据包被传递通过桥接过程：

1. 数据包经过 bridge NAT dst-nat 链，在那里可以更改 MAC 目的地和优先级，除此之外，数据包可以被简单地接受、丢弃或标记。
2. 检查 bridge 设置中是否启用了 use-ip-firewall 选项。
3. 让数据包经过 bridge host 表以做出转发决策。最终被洪泛的数据包（例如广播、多播、未知单播流量）会按 bridge 端口复制，然后在 bridge forward 链中被进一步处理。使用 vlan-filtering=yes 时，因 /interface/bridge/vlan 表而不被允许的数据包将在此阶段被丢弃。
4. 数据包经过 bridge filter forward 链，在那里可以更改优先级，或者数据包可以被简单地接受、丢弃或标记。
5. 检查 bridge 设置中是否启用了 use-ip-firewall 选项。
6. 数据包经过 bridge NAT src-nat 链，在那里可以更改 MAC 源和优先级，除此之外，数据包可以被简单地接受、丢弃或标记。
7. 检查 bridge 设置中是否启用了 use-ip-firewall 选项。

信息

对于 RouterOS v6：
启用 bridge vlan-filtering 时，收到的未标记数据包可能会在 "DST-NAT" 块之前被封装到 VLAN 头中，这意味着这些数据包可以使用 mac-protocol=vlan 和 vlan-encap 设置进行过滤。如果出接口的 frame-types 设置为 admit-all 或 admit-only-untagged-and-priority-tagged，则可能发生封装。

带标记的数据包可能会在 "BRIDGING DECISION" 块上被解封装，这意味着这些数据包将不再匹配 mac-protocol=vlan 和 vlan-encap 设置。如果数据包的 VLAN ID 与出端口的 untagged VLAN 成员身份匹配，则可能发生解封装。

对于 RouterOS v7 及更新版本：

启用 bridge vlan-filtering 时，收到的未标记数据包可能会在 "BRIDGING-DECISION" 块上被封装到 VLAN 头中，这意味着这些数据包可以使用 mac-protocol=vlan 和 vlan-encap 设置进行过滤。如果出接口的 frame-types 设置为 admit-all 或 admit-only-untagged-and-priority-tagged，则可能发生封装。

带标记的数据包可能会在 "BRIDGING DECISION" 块上被解封装，这意味着这些数据包将不再匹配 mac-protocol=vlan 和 vlan-encap 设置。如果数据包的 VLAN ID 与出端口的 untagged VLAN 成员身份匹配，则可能发生解封装。

Bridge Input

Bridge input 是当数据包的目的地为 bridge 接口时发生的过程。最常见的情况是你需要访问 bridge 接口上运行的某些服务（例如 DHCP 服务器），或者你需要将流量路由到其他网络。最初的步骤与 bridge forward 过程类似——在 in-interface 上收到数据包后，设备确定 in-interface 是一个 bridge 端口，因此数据包被传递通过桥接过程：

1. 数据包经过 bridge NAT dst-nat 链，在那里可以更改 MAC 目的地和优先级，除此之外，数据包可以被简单地接受、丢弃或标记。
2. 检查 bridge 设置中是否启用了 use-ip-firewall 选项。
3. 让数据包经过 bridge host 表以做出转发决策。目的 MAC 地址与 bridge MAC 地址匹配的数据包将被传递到 bridge input 链。最终被洪泛的数据包（例如广播、多播、未知单播流量）也会到达 bridge input 链，因为 bridge 接口本身也是众多目的地之一。
4. 数据包经过 bridge filter input 链，在那里可以更改优先级，或者数据包可以被简单地接受、丢弃或标记。

Bridge Output

Bridge output 是当数据包应通过一个或多个 bridge 端口离开设备时发生的过程。最常见的情况是 bridge 接口本身尝试访问连接到某个 bridge 端口的设备（例如 bridge 接口上运行的 DHCP 服务器响应 DHCP 客户端时）。在数据包由其他更高级别的 RouterOS 进程处理后，设备最终确定输出接口是 bridge，数据包就被传递通过桥接过程：

1. 让数据包经过 bridge host 表以做出转发决策。最终被洪泛的数据包（例如广播、多播、未知单播流量）会按 bridge 端口复制，然后在 bridge output 链中被进一步处理。
2. 数据包经过 bridge filter output 链，在那里可以更改优先级，或者数据包可以被简单地接受、丢弃或标记。
3. 数据包经过 bridge NAT src-nat 链，在那里可以更改 MAC 源和优先级，除此之外，数据包可以被简单地接受、丢弃或标记。
4. 检查 bridge 设置中是否启用了 use-ip-firewall 选项。

启用防火墙时的 Forward

在某些网络配置中，你可能需要对桥接流量的路由链启用额外处理，例如使用简单队列或 IP 防火墙。当 bridge 设置中启用 use-ip-firewall 时，就可以做到这一点。请注意，额外处理将消耗更多 CPU 资源来处理这些数据包。所有步骤已在前面几点中讨论过；下面是回顾：

1. 数据包经过 bridge NAT dst-nat 链。
2. 启用 use-ip-firewall 选项后，数据包将在 prerouting 链中被进一步处理。
3. 数据包进入 prerouting 处理。
4. 让数据包经过 bridge host 表以做出转发决策。
5. 数据包经过 bridge filter forward 链。
6. 启用 use-ip-firewall 选项后，数据包将在 routing forward 链中被进一步处理。
7. 数据包进入 routing forward 处理。
8. 数据包经过 bridge NAT src-nat 链。
9. 启用 use-ip-firewall 选项后，数据包将在 postrouting 链中被进一步处理。
10. 数据包进入 postrouting 处理。

硬件卸载数据包的处理流程

在上一个主题中，我们仅讨论了需要主 CPU 处理才能通过正确 bridge 端口转发数据包的软件桥接。大多数 MikroTik 设备都配备了专用的交换硬件，即所谓的 switch chip 或 switch ASIC。这使我们能够将一些桥接功能（例如 bridge 端口之间的数据包转发或数据包过滤）卸载到这个专用硬件芯片上，而不消耗任何 CPU 资源。在 RouterOS 中，我们将此功能命名为 Bridge Hardware (HW) Offloading。不同的 MikroTik 设备可能具有不同的 switch chip，每个芯片可用的功能集也不同，因此请务必访问本文以获取更多详细信息——Bridge Hardware Offloading。

警告

当 out-interface 被硬件卸载且 bridge Fast Path 未激活时，Interface HTB 将无法正常工作。

• Switching decision —— 很大程度上取决于交换机型。此块控制所有与交换相关的任务，例如主机学习、数据包转发、过滤、VLAN 标记/去标记等。某些交换机配置可以改变数据包流。
• switch-cpu port —— 用于主 CPU 与其他 switch 端口之间通信的特殊用途 switch 端口。请注意，switch-cpu 端口不会在 RouterOS 的任何地方显示，除了 switch 菜单。任何与软件相关的配置（例如 interface-list）都不能应用到此端口。到达 CPU 的数据包会自动与物理 in-interface 关联。

然而，硬件卸载并不限制设备只能使用硬件功能；相反，可以同时利用硬件和软件处理。这确实需要深入理解数据包如何穿过 switch chip 以及它们究竟何时被传递给主 CPU。

信息

在 /interface/ethernet/switch 菜单及其子菜单中发现的交换机功能，例如 ACL 规则、镜像、入站/出站速率限制器、QoS 和 L3HW（VLAN 间路由除外），可能不依赖 bridge 硬件卸载。因此，它们可能被应用到未在硬件卸载 bridge 中配置的接口上。

Switch Forward

我们将进一步讨论启用 bridge 硬件卸载且数据包在单个 switch chip 上的两个交换端口之间转发时的数据包流。这是最常见也是最简单的示例：

1. 交换机检查 in-interface 是否为硬件卸载接口。
2. 交换机让数据包经过 switch host 表以做出转发决策。如果交换机找到与目的 MAC 地址匹配的项，数据包将通过物理接口发送出去。最终被洪泛的数据包（例如广播、多播、未知单播流量）会被复制并发送到每个硬件卸载的 switch 端口。

Switch 到 CPU 的 Input

此过程发生在物理接口上收到数据包，且其目的地是 switch-cpu 端口以进行进一步软件处理时。通往 switch-cpu 的路径有两条。一条是根本未使用硬件卸载和交换（例如用于路由的独立接口，或故意禁用 HW 卸载的桥接接口），因此数据包只是被传递出去进行软件处理。另一条路径是在 in-interface 上激活了硬件卸载时采用的。这会导致数据包经过 switching decision，交换机可能因多种原因将数据包转发到 switch-cpu 端口：

• 数据包的目的 MAC 地址与本地 MAC 地址匹配，例如当数据包的目的地是本地 bridge 接口时。
• 数据包可能被洪泛到所有 switch 端口，包括 switch-cpu 端口，例如收到广播、多播或未知单播流量时。
• 交换机可能已学习到某些主机只能通过 CPU 访问（switch-cpu 端口学习将在下一节讨论），例如当 bridge 同时包含 HW 和非 HW 卸载接口时，例如无线、EoIP 甚至以太网接口。
• 数据包被有意复制到 switch-cpu，例如用于数据包检查。
• 数据包由交换机配置触发，应在软件中处理，例如 DHCP 或 IGMP snooping。

查看 in-interface 为硬件卸载时的数据包遍历过程：

1. 交换机检查 in-interface 是否为硬件卸载接口。
2. 让数据包经过 switch host 表以做出转发决策。如果上述任何一点成立，数据包将被转发到 switch-cpu 端口。
3. 数据包通过 switch-cpu 端口离开，并将由 RouterOS 数据包流进一步处理。

警告

任何由 switch chip 洪泛的已接收数据包都不会被软件 bridge 再次洪泛到同一个 HW 卸载交换机组。这可以防止形成重复数据包。

CPU Output 到 Switch

此过程发生在数据包离开 RouterOS 软件处理并在 switch-cpu 端口上被接收时。同样，数据包可以走两条路径。一条是根本未使用硬件卸载和交换（例如用于路由的独立接口，或故意禁用 HW 卸载的桥接接口），因此数据包只是通过物理 out-interface 发送出去。另一条路径是在 out-interface 上激活了硬件卸载时采用的。这会导致数据包经过 switching decision。与任何其他 switch 端口一样，交换机会从 switch-cpu 端口上接收的数据包中学习源 MAC 地址。当 bridge 同时包含 HW 和非 HW 卸载接口时，这很有用，因为交换机可以学习哪些帧应转发到 CPU。查看 out-interface 为硬件卸载时的数据包遍历过程：

1. 离开 RouterOS 软件处理的数据包在 switch-cpu 端口上被接收。
2. 交换机检查 out-interface 是否为硬件卸载接口。
3. 交换机让数据包经过 switch host 表以做出转发决策。如果交换机找到与目的 MAC 地址匹配的项，数据包将通过物理接口发送出去。最终被洪泛的数据包（例如广播、多播、未知单播流量）会被复制并发送到每个硬件卸载的 switch 端口。

警告

软件 bridge 通过 HW 卸载接口发送洪泛数据包时，只会为每个 HW 卸载交换机组发送单个数据包副本，而不是每个 HW 卸载接口一个。实际的洪泛将由 switch chip 完成；这可以防止形成重复数据包。

MPLS 数据包的处理流程

Pop Label

Switch Label

Push Label

MPLS IP VPN

在 VPNv4 设置中，到达需要转发到 CE 路由器的 PE 路由器的数据包并不是典型的 "forward"。

如果入站标签和目的地都绑定到 VRF，则在 MPLS 标签被弹出后：

• 目的地址是路由器本地的，则数据包被移动到 LOCAL_IN。
• 目的地址在 CE 网络中，则数据包被移动到 LOCAL_OUT。

危险

从 MPLS 云转发到 CE 网络的数据包将不会出现在 forward 中。 例如，从 src:111.15.0.1 到 dst:111.13.0.1 的流量

[admin@CCR2004_2XS] /mpls/forwarding-table> print 
Flags: L - LDP, P - VPN
Columns: LABEL, VRF, PREFIX, NEXTHOPS
#   LABEL  VRF      PREFIX         NEXTHOPS                                                                                                           
0 P    17  myVrf    111.13.0.0/24  
4 L    20  main     203.0.113.2    { label=impl-null; nh=111.11.0.1; interface=sfp-sfpplus1 }
[admin@CCR2004_2XS] /mpls/forwarding-table>                                                           
...

[admin@CCR2004_2XS] /ip/route> print detail 
Flags: D - dynamic; X - disabled, I - inactive, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, i - is-is, d - dhcp, v - vpn, m - modem, y - bgp-mpls-vpn; 
H - hw-offloaded; + - ecmp 

   DAc   dst-address=111.11.0.0/24 routing-table=main gateway=sfp-sfpplus1 immediate-gw=sfp-sfpplus1 distance=0 scope=10 suppress-hw-offload=no 
         local-address=111.11.0.2%sfp-sfpplus1 
   DAc   dst-address=203.0.113.1/32 routing-table=main gateway=lo immediate-gw=lo distance=0 scope=10 suppress-hw-offload=no local-address=203.0.113.1%lo 
   DAo   dst-address=203.0.113.2/32 routing-table=main gateway=111.11.0.1%sfp-sfpplus1 immediate-gw=111.11.0.1%sfp-sfpplus1 distance=110 scope=20 target-scope=10 
         suppress-hw-offload=no 
   DAc   dst-address=111.13.0.0/24 routing-table=myVrf gateway=sfp-sfpplus2@myVrf immediate-gw=sfp-sfpplus2 distance=0 scope=10 suppress-hw-offload=no 
         local-address=111.13.0.2%sfp-sfpplus2@myVrf 
   DAy   dst-address=111.15.0.0/24 routing-table=myVrf gateway=203.0.113.2 immediate-gw=111.11.0.1%sfp-sfpplus1 distance=200 scope=40 target-scope=30 suppress-hw-offload=no [admin@CCR2004_2XS] /ip/route>              

该数据包将出现在 output 和 postrouting 链中，因为现在它是一个本地产生的数据包，其源 MAC 地址等于 vrfInterface：

08:10:55 firewall,info output: in:(unknown 0) out:sfp-sfpplus2, connection-state:established src-mac f2:b5:e9:17:18:3b, proto ICMP (type 8, code 0), 111.15.0.1->111.13.0.1, len 56
08:10:55 firewall,info postrouting: in:myVrf out:sfp-sfpplus2, connection-state:established src-mac f2:b5:e9:17:18:3b, proto ICMP (type 8, code 0), 111.15.0.1->111.13.0.1, len 56

另一方面，沿 CE→PE 方向路由的数据包在被发送到 MPLS 之前，会像任何其他路由 IP 流量一样出现在 "forward" 中：

 08:10:55 firewall,info prerouting: in:sfp-sfpplus2 out:(unknown 0), connection-state:established src-mac dc:2c:6e:46:f8:93, proto ICMP (type 0, code 0), 111.13.0.1->111.15.0.1, len 56
 08:10:55 firewall,info forward: in:sfp-sfpplus2 out:sfp-sfpplus1, connection-state:established src-mac dc:2c:6e:46:f8:93, proto ICMP (type 0, code 0), 111.13.0.1->111.15.0.1, len 56
 08:10:55 firewall,info postrouting: in:sfp-sfpplus2 out:sfp-sfpplus1, connection-state:established src-mac dc:2c:6e:46:f8:93, proto ICMP (type 0, code 0), 111.13.0.1->111.15.0.1, len 56
 

但可能存在例外。如果回复数据包的目的 IP 是路由器本地的，并且连接跟踪正在执行 NAT 转换，那么连接跟踪将“强制”数据包经过防火墙 prerouting/forward/postrouting 链。

逻辑接口

到目前为止，我们查看的是 in 或 out 接口为实际物理接口（以太网、无线）的示例，但如果路由器收到隧道封装的数据包，数据包将如何流动？

让我们假设有一个 IPIP 数据包进入路由器。由于它是一个常规的 IPv4 数据包，它将通过所有与路由相关的功能（直到图中的 "J"）。然后路由器将检查数据包是否需要被解封装。在这种情况下，它是 IPIP 数据包，所以“是”，将数据包发送到解封装。之后，数据包将再次循环经过所有功能，但这次是作为解封装后的 IPv4 数据包。

这一点非常重要，因为数据包实际上会两次经过防火墙，所以如果存在严格的防火墙，那么对于 IPIP 封装的数据包以及解封装后的 IP 数据包都应该有 "accept" 规则。

信息

使用启用了 vlan-filtering 的 bridge 进行数据包封装和解封装与逻辑接口无关。更多细节请参见桥接部分。

IPSec 策略

让我们看看另一种隧道类型——IPSec。这种类型的 VPN 没有逻辑接口，但处理方式类似。

数据包不是通过逻辑接口处理，而是通过 IPSec 策略处理。在路由决策 (2) 和 input 防火墙处理 (3) 之后，路由器尝试将源和目标与 IPsec 策略匹配。当策略匹配数据包时，它被发送进行解密 (5)。解密后，数据包再次进入 PREROUTING 处理 (6) 并开始另一个处理循环，但这次是解封装后的数据包。

相同的过程适用于封装，但顺序相反。第一个 IP 数据包经过各项功能处理，然后与 IPsec 策略匹配 (5)、被封装 (6)，然后被发送到第二个循环中进行处理 (7-10)。

Fast Path

从我们目前所学的内容来看，很明显这种数据包处理会消耗大量 CPU 资源。为了加速，第一个 RouterOS v6 中引入了 FastPath。它所做的就是跳过 Linux 内核中的处理，基本上是以一些 RouterOS 功能换取性能。为了让 FastPath 工作，需要接口驱动支持和特定的配置条件。

Fast Path 的工作方式

FastPath 是一个接口驱动扩展，允许驱动直接与特定的 RouterOS 功能通信并跳过所有其他功能。

只有当至少源接口支持 fast path 时，数据包才能由 fast path 处理器转发。要完成完整的快速转发，还需要目的接口的支持。

目前，RouterOS 有以下 FastPath 处理器：

• IP traffic processing
• FastTrack
• Traffic Generator
• MPLS
• Bridge

满足以下条件时使用 FastPath 处理器：

• 未配置防火墙规则。
• 未配置 parent=global 的简单队列或队列树。
• 未配置 mesh 或 metarouter 接口。
• Sniffer 或 torch 未运行。
• 连接跟踪未激活。
• IP accounting 已禁用。
• 未配置 VRF（/ip/vrf 为空）。
• 未使用 hotspot（/ip/hotspot 没有接口）。
• 未配置 IPSec 策略。
• /tool/mac-scan 未在使用中。
• /tool/ip-scan 未在使用中。

警告

如果使用了 FastTrack，无论上述条件是否满足，数据包都将走 FastPath 路径。 如果接口支持此功能，Traffic Generator 会自动使用 FastPath。

目前，MPLS fast-path 适用于 MPLS 交换流量（以 MPLS 进入路由器且必须以 MPLS 离开路由器的帧）以及执行 VPLS 封装/解封装的 VPLS 端点。其他 MPLS 入口和出口将像以前一样运行。

满足以下条件时使用 Bridge 处理器：

• 没有 bridge Calea、filter、NAT 规则。
• use-ip-firewall 已禁用。
• 没有 mesh、MetaRouter 接口配置。
• sniffer、torch 和 traffic generator 未运行。
• bridge vlan-filtering 已禁用（自 RouterOS 7.2 版本起该条件已移除）。
• bridge dhcp-snooping 已禁用。

警告

vlan-filtering bridge 上的 FastPath 不支持优先级标记的数据包（带有 VLAN 头但 VLAN ID = 0 的数据包）。这些数据包通过慢速路径重定向。 支持 FastPath 的接口：

EoIP、Gre、IPIP、VXLAN 和 L2TP 接口有一个按接口的设置 allow-fast-path. 在这些接口上允许 fast path 的副作用是，会绕过通过 fast-path 传输的封装数据包的防火墙、连接跟踪、简单队列、parent=global 的队列树、IP accounting、IPsec、hotspot universal client、vrf 分配。此外，分片数据包无法在 FastPath 中接收。

信息

是否正在使用 FastPath 可以通过 /interface/print stats-detail 验证 唯一能保证 FastPath 的接口队列是 only-hardware-queue。如果你需要硬件以外的接口队列，那么数据包将不会完全走 FastPath，但性能影响不大，因为 "interface queue" 是数据包流中的最后一步。

数据包可能通过从 FastPath 切换到 SlowPath 而走 Half-FastPath，反之则不行。因此，例如，如果接收接口支持 FastPath，但出接口不支持，那么路由器将尽可能通过 FastPath 处理器处理数据包，然后继续使用 SlowPath。如果接收接口不支持 FastPath 但出接口支持，数据包将全程通过 SlowPath 处理。

FastTrack

Fasttrack 可以解读为 Fast Path + Connection Tracking。它允许将连接标记为 "fast-tracked"，属于 fast-tracked 连接的数据包将被标记为走 fast-path 路径。此类连接的连接表条目现在将具有 fast-tracked 标志。

警告

FastTrack 数据包会绕过防火墙、连接跟踪、简单队列、parent=global 的队列树、ip traffic-flow、IP accounting、IPSec、hotspot universal client、VRF 分配，因此管理员需要确保 FastTrack 不会干扰其他配置！ 要将连接标记为 fast-tracked，为防火墙 filter 和 mangle 实现了一个新动作 "fasttrack-connection"。目前，只有 TCP 和 UDP 连接可以被 fast-track，并且为了维护连接跟踪条目，一些随机数据包仍将被发送到慢速路径。在设计启用 "fasttrack" 的防火墙时必须考虑到这一点。

FastTrack 处理器还支持源和目的 NAT，因此不需要为经过 NAT 的连接设置特殊例外。

危险

属于 fast-tracked 连接的流量在 FastPath 中传输，这意味着它不会被其他路由器 L3 功能（防火墙、队列、IPsec、IP accounting、VRF 分配等）看到。Fasttrack 查找在路由标记设置之前进行路由，因此它仅适用于主路由表。 在家庭路由器上开始使用此功能最简单的方法是为所有 established, related 连接启用 "fasttrack"：

/ip/firewall/filter 
add chain=forward action=fasttrack-connection connection-state=established,related \
  comment="fasttrack established/related"
add chain=forward action=accept connection-state=established,related \
  comment="accept established/related"

请注意，第一条规则将 established/related 连接标记为 fast-tracked，第二条规则仍然是必需的，用于接受属于这些连接的数据包。原因如前所述，fast-tracked 连接中的一些随机数据包仍会通过慢速路径发送，且只有 UDP 和 TCP 会被 fast-track，但我们仍然希望接受其他协议的数据包。

添加 "FastTrack" 规则后，列表顶部出现了一条特殊的虚拟规则。这不是实际的规则，它用于视觉提示，表明某些流量正在走 FastPath，不会到达其他防火墙规则。

警告

FastTrack 只能在主路由表中处理数据包，因此系统管理员有责任不要 FastTrack 经过非主路由表的连接（即通过 mangle action=mark-routing 规则处理的连接）。否则数据包可能通过主路由表被错误路由。 只要存在至少一个 fast-tracked 连接跟踪条目，这些规则就会出现，并在最后一个 fast-tracked 连接在连接表中超时后消失。

警告

连接在被关闭、超时或路由器重启之前一直保持 FastTracked。

配置示例：将特定主机排除在 FastTrack 之外

/ip/firewall/filter
add action=accept chain=forward connection-state=established,related src-address=192.168.88.111
add action=accept chain=forward connection-state=established,related dst-address=192.168.88.111
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=no
add action=accept chain=forward connection-state=established,related

在此示例中，我们通过先使用防火墙规则同时针对源和目标接受主机 192.168.88.111，将其排除在 Fast-track 之外。思路是——不允许该流量到达 FastTrack 动作。

注意："排除" 规则必须放在 fasttrack 过滤器之前；顺序很重要。

要求

满足以下条件时 FastTrack 处于活动状态：

• 没有 mesh、metarouter 接口配置。
• Sniffer、torch 和 traffic generator 未运行。
• /tool/mac-scan 未在使用中。
• /tool/ip-scan 未在使用中。
• 在 IP/Settings 下启用了 FastPath 和 Route cache（route cache 条件不适用于 RouterOS v7 或更新版本）。
• 如果连接经过 bridge 接口，则启用了 Bridge FastPath。

面向视障人士的数据包流

以下 DOCX 格式文档以针对视障人士优化的方式描述了该示意图。说明由 Apex CoVantage 提供，由 Benetech 负责。它们不再更新。

• Packet flow, optimized document.