BCM交换芯片之L4分析

ReloadNow

已于 2022-04-22 15:13:41 修改

阅读量4.3k

点赞数

分类专栏：交换原理文章标签：网络安全嵌入式硬件

于 2022-03-28 19:07:19 首次发布

本文链接：https://blog.csdn.net/wangyayayaya/article/details/123795127

版权

交换原理专栏收录该内容

6 篇文章

订阅专栏

1 ContentAware processor

1.1 各厂家的L4功能

交换芯片ACL功能在不同的厂家中有不同的叫法，BCM称为ContentAware processor，Marvell称为Policy Control List（简称PCL），Realtek和Centec称为Access Control List 。

ContentAware Process(CAP)可用于ACL、DSCP、Qos等类型的运用。过滤功能可以作用于10/100/1000GbE端口上，或者Higig口。有三种不同的过滤查找：

– Ingress CAP处理。对于GbE和10GbE端口，Ingress查找发生于L2个L3 pre-routed packets.

– Higig查找。Higig查找是针对Higig端口报文Ingress，Higig查找有类似的过滤容量.

– Egress CAP。Egress查找是针对GbE和10GbE的报文Egress.

各CAP所处的位置如图所示：

1.2 BCM的并行查找机制

CAP查找引擎使用三重CAM技术（Ternary CAM，简称TCAM），三重CAM技术由16个ingress或者4个egressBroadScale并行CAP处理器，它们可以独立操作。每个BroadScale CA查找处理器包含各自的搜索机制，这种机制能够创建各自的行为以及各自更新meter和counter。可能会有16个内部（或者4个给ECAP使用）匹配，每个BroadScale　处理器可以有一个match，这样对于一个特定的报文就会造成16个内部（或者4个）meters或者counters被更新。而且BCM56620支持CAE扩展，可以作为第17个查找处理器。在这种环境下, 所有的非冲突行为都是允许的。

1.3 BCM L4的流程

冲突行为可以根据优先级被操作。以下是BroadScale ContentAware查找处理器的五个主要处理步骤：

a. Intelligent Protocol-aware Selector(智能协议识别选择器)。选择产生key值的域（即指定匹配的字段）

b. ContentAware Lookup Engine(CAP查找引擎)。执行key查找（key由前面的过程产生），输出匹配entry位置的地址(地址指向ACTION)。CA查找引擎是一个将输入和所有entries比较的memory。比较的结果是100%匹配的entry地址。如果有多个entry匹配到，低物理地址的那个entry将会返回(wangyab:同一个Slice内部，先匹配先生效；slice间，编号越大，优先级越高)。另外, CA查找引擎的每个entry都有一个mask，可以选择每个Memory Entry的特定位,与输入报文匹配bits。这允许可以不考虑输入报文不关心的field。

c. CA Policy Engine。包含匹配以后的action

d. CA Meter与Statisctics Engine。实现policy与统计收集

e. CA Action Resolution engine。解决了多个ACL同时匹配的问题。（如果匹配到了多个，则需要Resolution来决定执行哪条，类似于其它方案的仲裁器）

1.4 BCM支持的Field

Ingress、Egress和Higig查找有类似的过滤能力。下面是能被CAP操作的一般的过滤检查：

–TCP/UDP端口号范围

–检测或者过滤源端口为1-1024的TCP报文

–基于报文头部信息进行过滤

1.5 BCM支持的action

–改变Tos或者802.1p优先级

–dscp重标记

–event notification to CPU，upon filter match

–copy to cpu

2 ICAP Processor

2.1 ICAP的资源大小

一般情况下：

– 8K rule(每个slice有512条，共计16个slice)，一个slice就是一个CAP处理器

–8K meter(每个slice有512个，256个meter对)

–8K Byte counter(每slice有512个)和8K packet counter(每个slice有512个)

BCM部分芯片有12个slice，部分芯片有10个slice。

16个slice的芯片如：BCM56342M系列。

12个slice的芯片如：BCM56170系列.

10个slice的芯片如: BCM56842系列.

ICAP原理如：

3 Ingress Field Process

3.1 Ingress Field Process处理流程

主要的ContentAware引擎位于Ingress pipeline VFP block后面。Ingress FP 引擎也称为IFP。IFP有两部分内容：internal slice和external slice。本文只覆盖internal slice。

IFP包含了16个internal slices，每个slice有512条entry，总共8K rule entry。每个slice可以通过FP_SLICE_ENABLE寄存器开关。每个internal slice Entry有213 bit。213 bit-field分成5个field selector。另外，每个Entry有一个精细54-bit的TCAM表(FP_GLOBAL_MASK_TCAM)，可以用来过滤Ingress端口。

IFP的流程如下：

Key值是通过Field Selection计算得出的，Field Selection是基于端口的，通过FP_PORT_FIELD_SEL的配置，可以确定每个slice每个FP的模式，从而针对每个报文计算key值。计算后的key值通过TCAM引擎与配置的entry进行比对。所以同一个报文可以产生多个Key值，命中不同slice的tcam表，所以需要Poliy Engine仲裁。

3.2 IFP Field Selector 域选择器

协议域选择器被分成7个部分：FP1(34bit长度)，FP2(128bit长度)，FP3(32bit长度)，FIXED(13bit长度), FP4(6bit长度)，总共213bit。

每个Field Selector有多种模式，用户可以配置这些模式来有效的解析报文。VFP的Field selector会应用到整个设备，而IFP Field Seletor是基于每个端口的。例如，port 1能够让FP1设置到mode 4，端口2可以让FP1设置到mode 5。FP filed selector可以通过FP_PORT_FIELD_SEL table编程。相关的FP_SLICE_INDEX_CONTROL.slice_select_bitmap的bit位为0时，表就是根据ingress端口来索引。对于non-Higig端口和Higig查找端口来说，FP_PORT_FIELD_SEL表的索引直接是ingress端口号。FP_SLICE_INDEX_CONTROL.slice_select_bitmap位为1时，FP_PORT_FIELD_SEL 通过UDF_OFFSET表中的两个输出结果来选择。

各选择器的配置如下：

3.2.1域的定义

一下仅列出部分常用的Field，全部Field信息，可以通过sdk命令fp list qualifiers来查看。

OUTER_TPID_ENCODE

表明输入报文的外层VLAN的TPID信息

• 2'b00: Outer TPID is 0x8100
• 2'b01: Outer TPID is 0x9100
• 2'b10: Outer TPID is 0x88A8
• 2'b11: Outer TPID is none of above

INNER_TPID_ENCODE

表明输入报文的内层VLAN的TPID信息.

• 2'b00: Outer TPID is 0x8100
• 2'b01: Outer TPID is 0x9100
• 2'b10: Outer TPID is 0x88A8
• 2'b11: Outer TPID is none of above

OVID

外层VLAN信息.

ETHERTYPE

16bit以太网报文类型.

MACDA

目的MAC地址.

MACSA

源MAC地址.

IP_INFO

3bit大小，包含IP报文的分片信息

LOOKUP_STATUS

lookup_status的大小为16bit，包含报文的查找状态。

CLASS_ID

class id是从前几个阶段生成的特定自定义值，这些值被带到IFP中，通常用于分类

数据包流

3.2.2 特殊域

LOOKUP_STATUS

lookup_status的大小为16bit，包含报文的查找状态，实际使用十分频繁。

–[0]mpls bos终结

–[1]Vlan Translation Hit：表明ingress vlan translation 使能，在VLAN_XLATE表查找中匹配到了。

–[2]Valid Vlan

–[4:3]Ingress 端口生成树(spanning tree)状态

–[5]L2 Source lookup hit:表明在L2_ENTRY表或者EXT_L2_ENTRY表中存在L2 source查找匹配

–[6] L2 source static hit：在L2 source查找到一个静态的

–[7]L2 destination lookup hit:

–[8]Outer MPLS lable action POP

–[9]L2 User Entry table hit

–[10]L3 Source lookup hit：对于L3单播报文，在L3 ENTRY表中命中L3 Source查找(ARP表)。如果匹配的entry在L3_DEFIP、L3_DEFIP_128或者EXT_DEFIP表中，该bit位始终为0(注:同时匹配L3 ENTRY和LPM的报文改位为0，L3 LPM源地址查找一般用于URF中)

–[11] L3 Destination lookup hit

–[12] IPMC Hit

–[13] LPM table lookup hit:对于L3单播，命中到了L3_DEFIP、L3_DEFIP_128、EXT_DEFIP 表中（路由表）。如果匹配的entry在L3_ENTRY表中，该bit位始终为0(注:同时匹配L3 ENTRY和LPM的报文改位为0)

–[14] L2 Source miss/station movement

下列情况下，该位会置成1：

- MAC SA is all zero(源MAC地址全0)
- Bit 40 of MAC SA is 1(源MAC地址的第40位为1)
- Station movement found in L2 source lookup（L2源查找出现迁移,通常使用ivl，当按照mac+vlan迁移时会出现这种情况）
- L2 source lookup miss(L2源地址查找失败，通常是新学习的MAC地址)

–[15] Delected as DOS attack packet：根据DOC_CONTROL1和CONTROL_2寄存器来控制。

CLASS_ID

class id是从前几个阶段生成的特定自定义值，这些值被带到IFP中，通常用于分类

数据包流。

IFP可以使用classid作为查找键来识别一个数据包是否属于用户定义的flow，使用class id将消耗较小的entry。例如，可能需要将特殊的QOS规则应用于由分组MAC标识的业务流。该流量的成员列表中可能有数百个不相关的MAC DA。如果未使用类ID，则QOS规则可能需要数百条IFP entry。但是，通过为L2_条目中的所有MAC DA分配相同的class id，QOS规则可以只要class id是IFP查找key的一部分，就可以由单个IFP条目覆盖。

BCM56620设备支持三种类型的class id：Lookup Class、Forward Class和Interface Class。查找class id由源class id和目的地class id组成，每个ID为6位。下列出了每个项目的IFP字段名

称：

每种类型的class id可能来自于不同的源头.Lookup class ID通常来源于L2/L3表中的class id。

下表描述了不同的interface class的配置。

3.3 IFP Double-/Quadruple-Wide Mode

BCM提供了扩展Key长度的方法。

如果用户解析的数据超过213 bit，用户可以配置IFP为Double或者Quadruple-wide模式。Double-wide模式下，Filtering bits长度为426 bit，Quadruple-wide的模式下，Filtering bits长度为852 bit。

配置成Double-wide可以配置成两种方法中的一种。一种方法是将一个slice中的2个entry作为一个entry使用。这种方法称为Double-wide 。每个slice支持512个基本entry，使用double-wide以后，减少到了256条entry。

第二种方法称为slice-pairing，从每个slice中拿出一个entry，组成单独的一个entry。两种方式都可以差生426-bit Field。在Doule-wide方法下，actions可以从index 0-256发生，在slice-pairing模式下，action可以从两个slice发生。例如，如果slice 0和slice 1捆绑在一起，action可以从两个slice实施。两种模式的主要差别是：

–Double-wide有256个entries，action只从TCAM A实施，entry编号为0-255

–Slice-pairing有512 entries，action从两个slice实施。

Slice-pairing只能在两个相邻的slice中实现，并且是以偶数开始的。例如，slice 0和slice 1，slice 2和slice 3可以绑定到一起。Slice 1不能和slice 3绑定到一起，slice 1也不能和slice 2绑定到一起。

下图中描述了double-wide和slice-pairing的区别:

在double-wide mode下，两个TCAM被当做1个使用。TCM-A 的0-255编程看起来就像是single-wide模式。TCAM-A的Field的定义直接和single-wide模式相同。TCAM-B entry 256-511与TCAM-A使用不同的key,TCAM-B的Key如下：

DW IFP key(207) = {DWFP1(41), DWFP2(128) , DWFP3(32), DWFP4(6)}

3.4 行为仲裁

在一个slice中或者对个slice间，会发生多条entries匹配的情况。ContentAware使用一下策略来解决冲突：

规则1：如果在一个slice里面，多个entries匹配到，只有低的索引的entry的action才会实施.

规则2: 如果在多个slices间，多个entries匹配到，并且actions不冲突，所有的action都会执行，除了DROP、REPLACE和REDIRECT(注：会造成"丢弃优先").

规则3：所有的非冲突entries/slices的行为都会实施

规则4：不考虑slice编号，DROP、REPLACE和REDIRECT比其它优先级有更高的优先级（注：多个slice都命中了，有一个是丢弃，动作就为丢弃，即“丢弃优先”）。DROP有最高的优先级，接下来是REPLACE、然后是REDIRECT

规则5：–如果在slices之间有多个匹配并且冲突了，例如一个匹配是REPLACE，另外一个是DO NOT REPLACE，那么更高优先级slices的action将会获胜。更多信息参见Visual Slice Mapping

3.5 Visual Slice

3.5.1 Visual Slice Mapping

不像之前的StrataXGS III家族，BCM56620可以通过virtual sliceing来重新分配slice的优先级。虚拟slice映射的好处是不必将field重新安排到不同的slice中就能给予action新的优先级（注：之前的slice优先级是根据物理地址来的，不能改变，要想改变entry的优先级只能，将在另外一个slice上创建新的entry）。如果没有虚拟slice映射，action解析就是基于物理slice优先级。物理编号高的slice有更高的优先级。例如，物理slice4的优先级比物理slice2的优先级要高，action冲突发生时，行为就是slice4的行为。

有了虚拟slice映射，用户可以重新编程物理slice的虚拟slice编号。由于action解析是基于虚拟slice编号。Action实际上重新编程了物理slice的优先级。例如，物理slice-4可以映射到虚拟slice-2，物理slice 2可以重新映射到虚拟slice-4。在这种情况下，当行为冲突时，虚拟slice-4的action在执行（注：虚拟slice的编号越大，优先级越高；物理slice编号越大，优先级越高。两者是一致的）。虚拟slice映射可以通过FP_SLICE_MAP table配置。

当应用slice-pairing模式到虚拟slice时，物理slice绑定对必须编程为数字连续的虚拟slice，虚拟slice要和物理slice有相同的奇偶性。例如，为了使用绑定slice 1和slice 0的slice，slice 1的虚拟slice编号必须是一个奇数(如：7)，slice 0的虚拟slice编号必须是slice 1的虚拟编号减去1（为6）

如果虚拟slice映射不使用，用户必须在FP_SLICE_MAP中将虚拟slice和物理slice编号保持一致。另外，要求任何两个slice不应该有相同的虚拟slice。

3.5.2 Visual Slice Grouping

除了重新分配virtual slice编号以外，BCM56620允许用户将virtual slices聚合(group)到一起，virtual grouping（虚拟聚合，动名词）是由FP_SLICE_MAP表控制的。VFP和EFP也支持Virtual Slice Mapping，是通过VFP_SLICE_MAP和EFP_SLICE_MAP控制的。每个virtual slice就是一个virtual group的成员，芯片支持多达17个virtual groups。Virtual slice只包含virtual slice（注：不包含物理slice）。一个virtual group可以包含一个或者多个virtual slice。例如，virtual group #1 可以由virtual slice 2，4，10组成，同时virtual group #2可以包含virtual slice 1，3。每个virtual slice group只从最高级的virtual slice输出action(行为)，最高级的排名在virtual group的所有slice中排名（注：virtual group有三个virtual slice 1，4，7，9，那么最高级的slice为9。当virtual group的acl匹配时，action为最高级的slice的action）。虚拟组的好处是提供在多个感兴趣的slice之间提供分层行为，而不需要处理action。当slices聚合以后，跨越多个slice的行为在他们同时匹配时就不能同时生效了。例如，如果virtual slice 2， 4和10在一个group里面，并且他们都match acl，结果action从virtual 10中执行。或者说，如果只有slice 2在这个group中match，action从vrtual 2中执行。当slices聚合时，当多个slices都match时，就不会出现多个action执行的情况。

在virtual group中，不会出现action resolution（注：行为仲裁，多个acl同时命中时，action的执行问题），action是有更高virtual slice number决定的。

例：Virtual group 1有virtual slice 0，2，10组成。Virtual group 3由slice 1，3，7组成。如果所有的slices都匹配，假如slice 10和7的action不冲突，来自与slice 10和slice 7的行为都会执行。例如，如果slice 7预示DROP行为，slice 10预示DO_NOT_DROP行为，这些行为冲突了，结果是只有slice 10的行为执行。

在BCM56620中，对输入报文的不同类型，有三种映射。这样可以对不同的运用分配不同的action resolution 行为。例如，用户可以配置物理slice 5有一个更高的virtual slice 编号（例如，13）给L2 Packet使用，配置一个较低的virtual优先级（例如，4）给IPV4使用。(注：针对不同类型的报文L2/IPV4/IPV6，将SLICE映射到不同的VIRTUAL GROUP当中)。

4 SDK命令行的使用

支持virtual sliceing的bcm聚合芯片，SDK提供了很便利的接口来使用IFP，用户不需要再考虑slice的分配问题。SDK使用了"group"的概念，通过bcm_field_group_create来管理"group"，内部slice的分配、管理完全由SDK完成。

一个例子如下：

a 创建qset

fp qset clear
fp qset add SrcMac
fp qset add DstMac
fp qset add SrcIp
fp qset add DstIp
fp qset add InPorts
fp qset add OuterVlan
fp qset add OuterVlanId
fp qset add OuterVlanPri
fp qset add OuterVlanCfi
fp qset add L4SrcPort
fp qset add L4DstPort
fp qset add EtherType
fp qset add IpProtocol
fp qset add SrcClassL2
fp qset add IpType
fp qset add HiGig
fp qset add Stage
fp qset add InterfaceClassL2
fp qset add IngressStpState
fp qset add L2SrcStatic
fp qset add L2StationMove