Support a new ACL Table Type that combines L3 ACL and L3V6 ACL Tables
支持一种新的 ACL 表类型，该类型结合了 L3 ACL 和 L3V6 ACL 表
SONiC supports different in-built ACL Table types. These ACL table types have a pre-defined set of ACL match-fields, ACL actions and bind points. L3 and L3V6 are such in-built ACL Table types. These ACL tables support packet actions like drop, redirect etc.
SONiC 支持不同的内置 ACL 表类型。这些 ACL 表类型具有预定义的 ACL 匹配字段、ACL 动作和绑定点。L3 和 L3V6 是此类内置 ACL 表类型。这些 ACL 表支持丢弃、重定向等数据包动作。
L3 ACL Table type supports matching IPv4 fields like Source IPv4 address, Destination IPv4 address etc.
Similarly, L3V6 ACL Table type supports matching IPv6 fields like Source IPv6 address, Destination IPv6 address etc.
L3 ACL 表类型支持匹配 IPv4 字段，如源 IPv4 地址、目的 IPv4 地址等。类似地，L3V6 ACL 表类型支持匹配 IPv6 字段，如源 IPv6 地址、目的 IPv6 地址等。
Currently SONiC creates separate SAI ACL tables for L3 and L3V6 ACLs. In some ASICs, if a user wants both v4 and v6 rules, they would end up using two hardware ACL tables instead of one. This is sub-optimal in ASICs where both v4 and v6 ACLs can be supported using the same hardware ACL table.
目前 SONiC 为 L3 和 L3V6 ACL 创建独立的 SAI ACL 表。在某些 ASIC 中，如果用户需要同时使用 v4 和 v6 规则，最终会使用两个硬件 ACL 表而不是一个。在可以同时使用同一个硬件 ACL 表支持 v4 和 v6 ACL 的 ASIC 中，这是次优的。
The proposal is to give the operator an ability to configure L3 and L3V6 ACLs in the same hardware ACL Table wherever the underlying platform supports it.
提议是让操作员能够在底层平台支持的情况下，在同一个硬件 ACL 表中配置 L3 和 L3V6 ACL。
Note: SONiC already supports this optimization for MIRROR and MIRRORV6 ACL tables. Only L3 and L3V6 ACL tables have not been optimized so far.
注意：SONiC 已支持对 MIRROR 和 MIRRORV6 ACL 表进行此优化。目前仅 L3 和 L3V6 ACL 表尚未被优化。
- Support a new ACL Table Type that combines L3 ACL and L3V6 ACL Tables
支持一种新的 ACL 表类型，该类型结合了 L3 ACL 和 L3V6 ACL 表- Introduction to L3 and L3V6 ACL Table Types
L3 和 L3V6 ACL 表类型简介 - Problem overview 问题概述
- Table of Contents
目录- Revision 修订
- Scope 范围
- Terminology 术语
- Overview 概述
- Requirements 需求
- Architecture Design 架构设计
- High-Level Design 高层设计
- SAI API
- Configuration and management
配置和管理 - CLI
- Warmboot and Fastboot Design Impact
Warmboot 和 Fastboot 设计影响 - Restrictions/Limitations
限制/局限性 - Testing Requirements/Design
测试需求/设计
- Introduction to L3 and L3V6 ACL Table Types
| Rev 修订 | Date 日期 | Author 作者 | Change Description 变更描述 |
|---|---|---|---|
| 0.1 | 18/Feb/23 | Ravindranath (Marvell) 拉维德兰纳特（Marvell） | Initial Version. 初版。 |
| 0.2 | 21/Mar/23 | Ravindranath (Marvell) 拉维德兰纳特（Marvell） | Updates based on the community discussion on 21/Feb/23 and other offline comments 基于 2023 年 2 月 21 日社区讨论和其他线下评论的更新 |
This document discusses the various options to combine L3 and L3V6 ACL tables in SAI on supported hardware. It then provides the high level design in SONiC to support a new ACL table type called L3V4V6.
本文档讨论了在支持硬件的 SAI 中合并 L3 和 L3V6 ACL 表的各种选项。然后，它提供了 SONiC 中支持一种新的 ACL 表类型 L3V4V6 的高级设计。
| SONiC User ACL Table Types SONiC 用户 ACL 表类型 |
Description 描述 |
|---|---|
| L3 ACL table type L3 ACL 表类型 | A built-in ACL table type in SONiC that can match IPv4 fields along with incoming port and support ACL redirect and packet ACL actions. SONiC 中的一个内置 ACL 表类型，可以匹配 IPv4 字段以及入站端口，并支持 ACL 重定向和报文 ACL 操作。 |
| L3V6 ACL table type L3V6 ACL 表类型 | A built-in ACL table type in SONiC that can match IPv6 fields along with incoming port and support redirect and packet ACL actions. SONiC 中的一个内置 ACL 表类型，可以匹配 IPv6 字段以及入站端口，并支持重定向和报文 ACL 操作。 |
| Mirror ACL table type 镜像 ACL 表类型 | A built-in ACL table type in SONiC that can match IPv4 fields and supports Mirror ACL action. SONiC 中的一个内置 ACL 表类型，可以匹配 IPv4 字段，并支持 Mirror ACL 动作。 |
| MirrorV6 ACL table type MirrorV6 ACL 表类型 | A built-in ACL table type in SONiC that can match IPv6 fields and supports Mirror ACL action. SONiC 中的一个内置 ACL 表类型，可以匹配 IPv6 字段，并支持 Mirror ACL 动作。 |
| Custom ACL table types 自定义 ACL 表类型 | A recent enhancement where one or more ACL table types can be created by the user specifying the match-field list, action-list and the bindpoint-types list. 近期增强功能，用户可以通过指定匹配字段列表、动作列表和绑定点类型列表来创建一个或多个 ACL 表类型。 |
This document describes the orchagent support by which user can create a new ACL table of type L3V4V6 on platforms that support this feature.
本文档描述了 orchagent 支持的功能，用户可以在支持此特性的平台上创建新的 L3V4V6 类型 ACL 表。
In several ASICs, IPv4 and IPv6 ACL rules can be supported in the same ACL table. Further, in many hardware, when the hardware tables (TCAMs) are configured to match IPv6 addresses, the hardware can use the same resources to match the corresponding IPv4 packet fields without incurring additional hardware resources (like TCAM width). For example, IPv6 Destination address (128b) and IPv4 Destination address (32b) keys can be fit using only 128 bits instead of 128 + 32bits.
在多个 ASIC 中，IPv4 和 IPv6 ACL 规则可以在同一个 ACL 表中支持。此外，在许多硬件中，当硬件表（TCAM）配置为匹配 IPv6 地址时，硬件可以使用相同的资源来匹配相应的 IPv4 数据包字段，而无需额外硬件资源（如 TCAM 宽度）。例如，IPv6 目标地址（128b）和 IPv4 目标地址（32b）密钥可以使用仅 128 位来匹配，而不是 128 + 32 位。
So in these types of hardware, during ACL table creation, when a v6 match field is added, it is desirable to add the corresponding v4 match field. This does not cost any extra hardware resource and at the same time gives the user the flexibility to create IPv4 ACL rules in these ACL tables.
因此在这些类型的硬件中，在创建 ACL 表时，当添加一个 v6 匹配字段时，最好同时添加相应的 v4 匹配字段。这不会消耗任何额外的硬件资源，同时也能让用户在 ACL 表中创建 IPv4 ACL 规则，从而获得灵活性。
Note: SAI lacks a mechanism to identify this platform capability and it is left for the NOS to customise the ACL tables based on the platform type.
Refer opencomputeproject/SAI#1408 (comment)
注意：SAI 缺乏一种识别此平台能力的机制，因此需要 NOS 根据平台类型自定义 ACL 表。参考 opencomputeproject/SAI#1408 (comment)
- Support v6 and v4 ACL rules with a single underlying SAI ACL table.
使用单个底层 SAI ACL 表支持 v6 和 v4 ACL 规则。- This will be enabled only on platforms needing this optimization.
这将仅在需要此优化的平台上启用。
- This will be enabled only on platforms needing this optimization.
- Allow the operator the flexibility to choose when to use this optimization
允许操作员选择何时使用此优化
ACL Orchagent is enhanced to achieve these requirements. There are no architecture changes.
ACL Orchagent 已增强以实现这些要求。没有架构变更。
The following design options were considered for implementing this solution:
在实现此解决方案时，考虑了以下设计选项：
- Option-A: Follow the existing SONiC behavior to combine Mirror ACL table and MirrorV6 ACL table.
选项 A：遵循现有的 SONiC 行为，将 Mirror ACL 表和 MirrorV6 ACL 表合并。 - Option-B: Extend the existing L3V6 ACL table type to include v4 fields.
选项 B：扩展现有的 L3V6 ACL 表类型，以包含 v4 字段。 - Option-C: Create a new ACL table type called L3V4V6 that combines v4 and v6.
选项 C：创建一个新的 ACL 表类型 L3V4V6，该类型结合了 v4 和 v6。
Today, Orchagent already optimizes Mirror and MirrorV6 ACL table creation for platforms that support it. Orchagent does this by using a static compile time check to determine platforms that support v4 and v6 Mirror ACL rules in the same ACL table. On these platforms, when user creates a MirrorV4 (or a MirrorV6) ACL table in the CONFIG_DB, orchagent creates a single SAI ACL Table that has both v4 and v6 match fields. Later, when the user creates another MirrorV6 (or a MirrorV4) ACL table with the same ACL direction in CONFIG_DB, orchagent reuses the previously created SAI ACL table.
目前，Orchagent 已经针对支持该功能的平台优化了 Mirror 和 MirrorV6 ACL 表的创建。Orchagent 通过在编译时使用静态检查来确定在同一 ACL 表中支持 v4 和 v6 Mirror ACL 规则的平台。在这些平台上，当用户在 CONFIG_DB 中创建 MirrorV4（或 MirrorV6）ACL 表时，Orchagent 会创建一个包含 v4 和 v6 匹配字段的单一 SAI ACL 表。之后，当用户在 CONFIG_DB 中创建另一个具有相同 ACL 方向的 MirrorV6（或 MirrorV4）ACL 表时，Orchagent 会重用之前创建的 SAI ACL 表。
The below diagram illustrates the behavior of the optimization in supported platforms when both these ACL tables are created in the same ACL direction, say ingress.
The user sees two different ACL tables irrespective of the platform. Orchagent, internally enables the optimization based on the platform and this is transparent to the end user.
下图展示了当这两个 ACL 表在同一 ACL 方向（例如入站）创建时，在支持的平台上优化行为。无论平台如何，用户都会看到两个不同的 ACL 表。Orchagent 内部根据平台启用优化，这对最终用户是透明的。
- Ease for the operator: the operator does not need to change their ACL configuration based on the platform. The operator configuration remains identical, and orchagent internally does the merging based on the platform type.
操作员便利性：操作员无需根据平台更改其 ACL 配置。操作员配置保持一致，而 orchagent 根据平台类型在内部进行合并。
However, this mechanism has several disadvantages
然而，这种机制存在一些缺点
-
Today, the MirrorV4 and v6 ACL tables are combined based on platform specific checks done at compile time. These are done using platform names since SAI does not have a mechanism to detect the ASIC capability to combine tables. The flip side of these platform checks is that the platform vendor has to decide at compile time between these two choices: either always combine or never combine. There is no mechanism to configure this based on the deployments/customers. In some deployments, when the operator has no v6 rules, we would need the optimization disabled so that the hardware TCAM tables width can be reduced. However disabling this optimization would need a new build.
目前，MirrorV4 和 v6 ACL 表是基于编译时进行的特定平台检查而合并的。这些检查使用平台名称进行，因为 SAI 没有检测 ASIC 能力以合并表的机制。这些平台检查的另一面是，平台供应商必须在编译时在这两个选择之间做出决定：要么始终合并，要么永不合并。没有机制可以根据部署/客户进行配置。在某些部署中，当操作员没有 v6 规则时，我们需要禁用此优化，以减少硬件 TCAM 表的宽度。然而，禁用此优化需要一个新的构建。 -
SONiC cannot support more than one ACL table type of Mirror. If Orchagent has to support multiple mirror ACL tables, then orchagent has to identify which Mirror table is to be combined with which MirrorV6 table. This would need additional inputs from the operator.
SONiC 不支持超过一种类型的 Mirror ACL 表。如果 Orchagent 需要支持多个 Mirror ACL 表，那么 Orchagent 必须识别哪个 Mirror 表要与哪个 MirrorV6 表组合。这需要操作员提供额外的输入。 -
With the optimization enabled, the user configuration in CONFIG_DB and the actual ASIC_DB configuration are different. Say the user configures the Mirror ACL table to ports P1 and P2 and MirrorV6 table to port P3 and P4. Orchagent configures the ASIC to bind the combined table to only the ports configured on Mirror ACL table i.e., ports P1 and P2. Ports P3 and P4 do not undergo the ACL table lookup contrary to user's configuration.
启用优化后，CONFIG_DB 中的用户配置与实际的 ASIC_DB 配置是不同的。假设用户将 Mirror ACL 表配置到端口 P1 和 P2，将 MirrorV6 表配置到端口 P3 和 P4。Orchagent 配置 ASIC 仅将组合表绑定到 Mirror ACL 表中配置的端口，即端口 P1 和 P2。端口 P3 和 P4 不进行 ACL 表查找，这与用户的配置相反。 -
Similarly, when the user deletes one of the ACL tables, orchagent deletes the combined ACL table from the hardware even though the user expects the other ACL table to still be present and bound to the attached ports.
类似地，当用户删除其中一个 ACL 表时，orchagent 会从硬件中删除组合的 ACL 表，尽管用户期望其他 ACL 表仍然存在并绑定到连接的端口。
As explained before, in several ASIC platforms, including v4 matchfields along with v6 matchfields does not cost extra hardware resources. Hence, on these platforms, v4 matchfields will be included in table type L3V6. In the below table, the second column shows the matchfields in current L3V6 ACL table. The third column shows the matchfields that will be added to L3V6 on platforms that needs this optimization.
如前所述，在多个 ASIC 平台上，同时包含 IPv4 匹配字段和 IPv6 匹配字段不会额外消耗硬件资源。因此，在这些平台上，IPv4 匹配字段将被包含在表类型 L3V6 中。在下表中，第二列显示了当前 L3V6 ACL 表中的匹配字段，第三列显示了在需要此优化的平台上将添加到 L3V6 的匹配字段。
/*
* Type of Tables and Supported Match Types
* |----------------------------------------------------|
* | | Original | New L3V6 on |
* | Match Type | L3V6 | optimized |
* | | | platforms |
* |----------------------------------------------------|
* | MATCH_OUTER_VLAN_ID | √ | √ |
* |----------------------------------------------------|
* | MATCH_ACL_IP_TYPE | √ | √ |
* | MATCH_ETHER_TYPE | | √ |
* |----------------------------------------------------|
* | MATCH_SRC_IPV6 | √ | √ |
* | MATCH_DST_IPV6 | √ | √ |
* | MATCH_SRC_IP | | √ |
* | MATCH_DST_IP | | √ |
* |----------------------------------------------------|
* | MATCH_ICMPV6_TYPE | √ | √ |
* | MATCH_ICMPV6_CODE | √ | √ |
* | MATCH_ICMP_TYPE | | √ |
* | MATCH_ICMP_CODE | | √ |
* |----------------------------------------------------|
* | MATCH_IP_PROTOCOL | √ | √ |
* | MATCH_NEXT_HEADER | √ | √ |
* | ---------------------------------------------------|
* | MATCH_L4_SRC_PORT | √ | √ |
* | MATCH_L4_DST_PORT | √ | √ |
* | MATCH_TCP_FLAGS | √ | √ |
* |----------------------------------------------------|
*/
- Operator can create multiple L3 and L3V6 ACL tables. This would not be possible if we use option-A.
运营商可以创建多个 L3 和 L3V6 ACL 表。如果使用选项-A，这将不可能。 - Gives the flexibility to the operator to utilize unused space in L3V6 ACL table for L3 ACL rules.
为运营商提供了灵活性，可以使用 L3V6 ACL 表中的未用空间来配置 L3 ACL 规则。
- If there are many v4 rules and many v6 rules, the user can continue to use separate L3 and L3V6 ACL Tables.
如果存在大量 v4 规则和大量 v6 规则，用户可以继续使用独立的 L3 和 L3V6 ACL 表。
- No impact on other platforms
对其他平台无影响
- If the operator decides to use the optimization, the operator needs to modify the ACL configuration, i.e., operator must modify the V4 ACL rules that need to be placed in L3V6 ACL table- the rule's ACL Table is renamed to the L3V6 ACL table.
如果运营商决定使用优化，运营商需要修改 ACL 配置，即运营商必须修改需要放置在 L3V6 ACL 表中的 V4 ACL 规则——该规则的 ACL 表被重命名为 L3V6 ACL 表。
Create a new built-in table type called L3V4V6 with the following match types:
创建一个名为 L3V4V6 的新内置表类型，包含以下匹配类型：
/*
* Supported Match Types in a new table type L3V4V6
* |-------------------------------------|
* | | |
* | Match Type | New L3V4V6 |
* | | |
* |-------------------------------------|
* | MATCH_OUTER_VLAN_ID | √ |
* |-------------------------------------|
* | MATCH_ACL_IP_TYPE | √ |
* | MATCH_ETHER_TYPE | √ |
* |-------------------------------------|
* | MATCH_SRC_IPV6 | √ |
* | MATCH_DST_IPV6 | √ |
* | MATCH_SRC_IP | √ |
* | MATCH_DST_IP | √ |
* |-------------------------------------|
* | MATCH_ICMPV6_TYPE | √ |
* | MATCH_ICMPV6_CODE | √ |
* | MATCH_ICMP_TYPE | √ |
* | MATCH_ICMP_CODE | √ |
* |-------------------------------------|
* | MATCH_IP_PROTOCOL | √ |
* | MATCH_NEXT_HEADER | √ |
* | ------------------------------------|
* | MATCH_L4_SRC_PORT | √ |
* | MATCH_L4_DST_PORT | √ |
* | MATCH_TCP_FLAGS | √ |
* |-------------------------------------|
*/
On platforms supporting v4 and v6 in a single SAI ACL table, this new L3V4V6 ACL table is supported.
在支持在单个 SAI ACL 表中同时处理 v4 和 v6 的平台上，这个新的 L3V4V6 ACL 表是受支持的。
On platforms NOT supporting v4 and v6 in a single SAI ACL table, this new L3V4V6 ACL table will be supported by orchagent's special handling. Orchagent would internally create and manage two SAI ACL tables as shown in the right picture below. The operator is agnostic about the underlying ASIC behavior and only sees a consolidated SONiC ACL table.
在那些不支持在单个 SAI ACL 表中同时处理 v4 和 v6 的平台上，这个新的 L3V4V6 ACL 表将通过 orchagent 的特殊处理来支持。Orchagent 将在内部创建和管理两个 SAI ACL 表，如下面的右图所示。操作员对底层的 ASIC 行为不透明，只能看到一个整合的 SONiC ACL 表。
Note: 注意：
- Due to the lack of SAI APIs to detect this capability, platform checks in orchagent code are used to detect the support.
由于缺乏用于检测此功能的 SAI API，orchagent 代码中的平台检查被用来检测支持情况。 - Currently, phase-1 is supported. On non-supporting ASICs, when operator creates an ACL table of type L3V4V6, orchagent throws an error in syslog.
目前支持阶段 1。在不支持 ASIC 的设备上，当操作员创建类型为 L3V4V6 的 ACL 表时，orchagent 会在 syslog 中抛出错误。 - Phase-2 will be implemented in the future release.
阶段 2 将在未来的版本中实现。
- Readability: L3V4V6 ACL table type conveys to the operator that the ACL table type supports v4 and v6 match qualifiers.
可读性：L3V4V6 ACL 表类型向操作员传达了该 ACL 表类型支持 v4 和 v6 匹配限定符。 - Allows the operator the flexibility to use only L3 ACL tables when the deployment does not need v6 rules.
允许操作员在部署不需要 v6 规则时，仅使用 L3 ACL 表。 - Using the same config across ASIC families: Once the future plan of orchagent creating separate v4 and v6 SAI ACL tables on unsupported platform is done, the operator can have the same ACL configuration across ASIC platforms.
跨 ASIC 系列使用相同配置：一旦未来计划在不受支持平台上由 orchagent 创建独立的 v4 和 v6 SAI ACL 表完成，操作员就可以在 ASIC 平台上使用相同的 ACL 配置。
Based on the above design considerations and feedback from the community, option-C is implemented.
New fields are added to the ACL capability in STATE_DB to help applications identify the platforms where the new L3V4V6 ACL table is supported; this is done for both ingress and egress individually.
基于上述设计考虑和社区反馈，实现了选项 C。在 STATE_DB 的 ACL 能力中添加了新字段，以帮助应用程序识别支持新 L3V4V6 ACL 表的平台；这针对入站和出站分别进行。
Matches supported in L3V4V6 table
L3V4V6 表中支持的匹配项
- VLAN_ID
- IP_TYPE*
- ETHER_TYPE*
- SRC_IPV6
- DST_IPV6
- SRC_IP
- DST_IP
- ICMPV6_TYPE
- ICMPV6_CODE
- ICMP_TYPE
- ICMP_CODE
- IP_PROTOCOL
- NEXT_HEADER
- L4_SRC_PORT
- L4_DST_PORT
- TCP_FLAGS
*Note: It is recommended that every ACL Rule should include at least one of [IP_TYPE, ETHER_TYPE] in the matching criteria when matching of L3 header fields. When we handle unsupported platforms by adding two ACL tables in SAI, this allows orchestrator to decide in which underlying SAI ACL table to place the rule in. In phase-1, if these fields are not provided in the ACL rule, the underlying SAI platform must do one of the following:
*注意：建议在匹配 L3 头部字段时，每个 ACL 规则在匹配条件中都应至少包含一个[IP_TYPE, ETHER_TYPE]。当我们通过在 SAI 中添加两个 ACL 表来处理不支持的平台时，这允许编排器决定将规则放置在哪个底层 SAI ACL 表中。在第一阶段，如果 ACL 规则中未提供这些字段，底层 SAI 平台必须执行以下操作之一：
- install a single rule if the hardware supports it, or
如果硬件支持，则安装单个规则，或 - make multiple rules (one rule per IP type), or
创建多个规则（每个 IP 类型一个规则），或 - throw error as unsupported.
抛出错误，指示不支持。
Actions allowed in the table of the type L3V4V6
允许在 L3V4V6 类型表中执行的操作
The default actions supported in the new table type are the same as L3 and L3V6, viz.,
新表类型中默认支持的操作与 L3 和 L3V6 相同，即
- PACKET_ACTION
- REDIRECT_ACTION
Note: The above actions would be added to the ACL table based on the ACL capability. For example, on platforms where REDIRECT_ACTION is not supported in the egress direction, the only action supported will be PACKET_ACTION. This is similar to what is being done today for L3 and L3V6 ACL tables.
注意：上述操作将根据 ACL 功能添加到 ACL 表中。例如，在出口方向不支持 REDIRECT_ACTION 的平台上，唯一支持的操作将是 PACKET_ACTION。这与目前对 L3 和 L3V6 ACL 表的操作类似。
Bindpoints supported in the table of the type L3V4V6
The same as L3 and L3V6 ACL table, viz.,
支持 L3V4V6 类型的表中的绑定点与 L3 和 L3V6 ACL 表相同，
- Port 端口
- LAG 聚合链路
The new ACL table type called L3V4V6 is created during Orchagent initialization.
在 Orchagent 初始化过程中会创建新的 ACL 表类型 L3V4V6。
aclorch::init() -> initDefaultTableTypes() -> addAclTableType(TABLE_TYPE_L3V4V6)
Using platform specific checks, AclOrch identifies platforms where L3V4V6 ACL tables can be supported. Creation of an ACL table of type L3V4V6 on an unsupported platform results in orchagent logging an error in the syslog. A SAI ACL table create call is done only on supported platforms; this avoids crashes on unsupported platforms. In the future, orchagent would internally create separate v4 and v6 ACL tables on these unsupported platforms.
通过平台特定的检查，AclOrch 识别出可以支持 L3V4V6 ACL 表的平台。在不支持的平台上创建 L3V4V6 类型的 ACL 表会导致 orchagent 在 syslog 中记录错误。只有在支持的平台才会执行 SAI ACL 表创建调用；这避免了在不支持的平台上的崩溃。未来，orchagent 将在这些不支持的平台上内部创建独立的 v4 和 v6 ACL 表。
A new field called supported_L3V4V6 is added to the ACL capability in STATE_DB. This field is set to true by orchagent during 'AclOrch init' on platforms where v4 fields and v6 fields can be matched in the same hardware ACL table. This provides an interface to the operator to identify the platforms where the new L3V4V6 ACL table is supported. In the future, this field will be used by Orchagent to implement a single user configured L3V4V6 ACL table as two underlying SAI ACL tables on platforms where v4 fields and v6 fields cannot be matched in the same hardware ACL table.
在 STATE_DB 的 ACL 能力中添加了一个名为 supported_L3V4V6 的新字段。在 v4 字段和 v6 字段可以在同一硬件 ACL 表中匹配的平台上，orchagent 在'AclOrch init'期间将该字段设置为 true。这为操作员提供了一个接口，用于识别支持新 L3V4V6 ACL 表的平台。未来，orchagent 将使用该字段在 v4 字段和 v6 字段不能在同一硬件 ACL 表中匹配的平台上实现单个用户配置的 L3V4V6 ACL 表，将其作为两个底层的 SAI ACL 表。
127.0.0.1:6379[6]> hgetall "ACL_STAGE_CAPABILITY_TABLE|INGRESS"
:
:
1) "supported_L3V4V6"
2) "true"
127.0.0.1:6379[6]> hgetall "ACL_STAGE_CAPABILITY_TABLE|EGRESS"
:
:
5) "supported_L3V4V6"
6) "true"
There are no new SAI APIs required for this feature.
此功能不需要新的 SAI API。
--- a/models/yang/sonic/sonic-acl.yang
+++ b/models/yang/sonic/sonic-acl.yang
container sonic-acl {
container ACL_TABLE {
:
:
leaf type {
type enumeration {
enum MIRROR;
enum MIRRORV6;
enum L3;
enum L3V6;
+ enum L3V4V6;
}
}
:
:
}
}
}
Example: 示例：
{
"ACL_TABLE": {
"DATAACL": {
"STAGE": "INGRESS",
"TYPE" : "L3V4V6",
"PORTS": [
"Ethernet0",
"Ethernet1"
]
}
},
"ACL_RULE": {
"DATAACL|RULE1": {
"ETHER_TYPE": "0x0800",
"PRIORITY": "5",
"DST_IP": "20.2.2.2/32",
"PACKET_ACTION": "DROP"
}
"DATAACL|RULE2": {
"IP_TYPE": "IPV6ANY",
"PRIORITY": "6",
"DST_IPV6": "2001::2/64",
"PACKET_ACTION": "DROP"
}
}
}
The existing CLI is extended to support the new table type.
现有的 CLI 已扩展以支持新的表类型。
config acl add table -s <stage> -p <ports> <table_name> <table_type>
table_type needs to be passed as "L3V4V6" to create a table of the new L3V4V6 type.
要创建新的 L3V4V6 类型的表，需要将 table_type 传递为"L3V4V6"。
Example : config acl add table -s ingress -p Ethernet0 DATAACL L3V4V6
There is no impact on warmboot or fastboot.
对热启动或快速启动没有影响。
- SONiC does not specify the ACL table priority when an ACL table is being created in SAI. (Refer SAI_ACL_TABLE_GROUP_MEMBER_ATTR_PRIORITY). So, when more than one ACL table is bound to a port, and if these ACL tables result in conflicting actions, the winner is not predictable. This will be addressed in phase-2 by enhancing config DB to let the operator configure the ACL table priority.
当在 SAI 中创建 ACL 表时，SONiC 没有指定 ACL 表的优先级。（参考 SAI_ACL_TABLE_GROUP_MEMBER_ATTR_PRIORITY）。因此，当多个 ACL 表绑定到同一个端口，并且这些 ACL 表导致动作冲突时，胜者不可预测。这将在第二阶段通过增强配置数据库来让操作员配置 ACL 表的优先级来解决。 - "IP_TYPE" or "ETHER_TYPE" must be specified for ACL rules added in L3V4V6 ACL table. This will be used in phase-2 to decide on which underlying SAI ACL table a given ACL rule should be placed in.
对于添加到 L3V4V6 ACL 表中的 ACL 规则，必须指定"IP_TYPE"或"ETHER_TYPE"。这将在第二阶段用于决定给定的 ACL 规则应该放置在哪个底层 SAI ACL 表中。
- Verify ACL Capability in STATE_DB on supported platforms.
在支持的平台上验证 STATE_DB 中的 ACL 功能。- The new field
supported_L3V4V6must be true.
新字段supported_L3V4V6必须为 true。
- The new field
- Verify ACL Capability in STATE_DB on non-supported platforms.
在不受支持的平台上验证 STATE_DB 中的 ACL 功能。- The new field
supported_L3V4V6must be false.
新字段supported_L3V4V6必须为 false。
- The new field
- Create IPv4 ACL rules (match SRC-IP, DST-IP, ICMP Type, ICMP Code, EtherType) on L3V4V6 ACL table.
在 L3V4V6 ACL 表中创建 IPv4 ACL 规则（匹配源 IP、目的 IP、ICMP 类型、ICMP 代码、以太网类型）。- This MUST pass in supported platforms
这必须在支持的平台上通过。 - This should fail with meaningful error messages in non-supported platforms.
这应该在不受支持的平台上以有意义的错误消息失败。
- This MUST pass in supported platforms
- Create IPv6 ACL rules (match SRC-IPv6, DST-IPv6, ICMPv6 Type, ICMPv6 Code, EtherType) on L3V4V6 ACL table.
在 L3V4V6 ACL 表中创建 IPv6 ACL 规则（匹配源 IPv6、目的 IPv6、ICMPv6 类型、ICMPv6 代码、以太网类型）。- This MUST pass in supported platforms
这必须在支持的平台上通过 - This should fail with meaningful error messages in non-supported platforms.
在不支持的平台上，这应该以有意义的错误消息失败。
- This MUST pass in supported platforms
- On supported platforms, test full ACL workflow: create V4 and V6 ACL Rules on L3V4V6 ACL Table type, set packet action, get the ACL rules and counters, delete ACL rules and then delete the ACL table.
在支持的平台上，测试完整的 ACL 工作流程：在 L3V4V6 ACL 表类型上创建 V4 和 V6 ACL 规则，设置数据包操作，获取 ACL 规则和计数器，删除 ACL 规则，然后删除 ACL 表。
- Modify existing sonic-mgmt(PTF) test_acl.py to test the L3V4V6 ACL table on ingress and egress on supported platforms
修改现有的 sonic-mgmt(PTF) test_acl.py 以在支持的平台上测试 L3V4V6 ACL 表在入站和出站上的功能- Traffic Testing must pass for v4 and v6
流量测试必须通过 IPv4 和 IPv6
- Traffic Testing must pass for v4 and v6