6506QACL工作原理.docx
《6506QACL工作原理.docx》由会员分享，可在线阅读，更多相关《6506QACL工作原理.docx（24页珍藏版）》请在冰点文库上搜索。
6506QACL工作原理
6506QACL工作原理及案例分析
6506的QACL工作比较特殊，配置起来有许多注意事项，随着6500系列产品在全球的展开，维护和技术支持任务会越来越重，有必要向广大用服兄弟解释芯片的工作原理，公布一些技术细节。
一、规则匹配过程
首先介绍一下6506采用的芯片的结构：
1、PT表项（PacketTypeTable）：
用于设置报文的封装格式、以太网类型等；
其中几个常用的字段为：
Encapsulation:
报文的封装类型，包括EthernetII,IEEE802.2/802.3SNAP,Netware802.3Raw,
IEEE802.2/802.3;
Ethernettype:
以太网类型，只对EthernetII,IEEE802.2/802.3SNAP有效；
PackettypeID:
如果所有字段匹配上后，就得到一个ID号，以与别的表项相区别；
表中除了ID字段的其他字段属于匹配字段，有相应Mask设置，如果Mask=0,则表示该字段是不关心的，即不参与比较/匹配过程。
ID字段的取值是由程序控制的，如果两个表项其他的字段完全相同，则他们的ID号就是相同的。
2、SrHG表项（SourceHostGroupTable）:
用于设置源二、三层信息，如源IP,源Mac,源端口等；
3、
DstHG表项（DestinationHostGroupTable）:
用于设置目的二、三层信息，如目的IP，目的Mac，目的端口等；
SrHG表项与DstHG表项在CAM表中的表示是相同的，实际上是同一张表，当Source/Destination=0时，表示记录的是源信息，是SrHG表；当Source/Destination=1时，表示记录的是目的信息，是DstHG表。
其中几个常用的字段为：
Entrytype:
表项类型，有IP,IPX,L2,L3四个类型，其中L3没有用到；类型不同对其后各
字段的解释就不同。
还有一点要格外注意：
我们的qaclmode有L2/L3（Link/IP）
两种模式，type=L2只在L2Mode下有效，type=IP/IPX只在L3Mode下有效。
有时配置的规则不起作用，可能是Mode没有设置正确；
IPAddress:
报文的源或目的IP，只对type=IP有效；
DiffServ/IPPrecedence:
IP优先级，DSCP；
PhysicalPortMask:
端口掩码，表示对从哪些端口进/出的报文，规则生效。
我们配置IP
规则时，在多个端口下发，在底层只占用了一个SrHG表项，就是应为该字段
可以表示多个端口信息。
这显然大大节约了表项资源；
VlanID:
我们当前只支持入Vlan设置，且只能在Link规则才可配；
MacAddress:
报文的源或目的Mac，只对type=L2有效；
PhysicalPort:
物理端口号，表示对从哪些端口进/出的报文，规则生效。
HostGroupID:
如果所有字段匹配上后，就得到一个ID号，以与别的表项相区别；
表中除了ID字段的其他字段属于匹配字段，有相应Mask设置，如果Mask=0,则表示该字段是不关心的，即不参与比较/匹配过程。
ID字段的取值是由程序控制的，如果两个表项除去Port外其他的字段完全相同，则他们的ID号就是相同的。
4、SrL4表项（SourceLayer4Table）：
用于设置协议类型、TCPFlag、L4源端口号、Socket等；
5、DstL4表项（DestinationLayer4Table）：
用于设置协议类型、TCPFlag、L4目的端口号、Socket等；
SrL4表项与DstL4表项在CAM表中的表示是相同的，实际上是同一张表，当Source/Destination=0时，表示记录的是源信息，是SrL4表；当Source/Destination=1时，表示记录的是目的信息，是DstL4表。
其中几个常用的字段为：
Type:
表项类型，有IP,IPX两个类型，类型不同对其后各字段的解释就不同。
L4Protocol:
报文的TransportLayer协议号，如配置了Tcp规则，该字段=6；
PortNumber:
TCP/UDP报文的端口号；
L4LayerGroupID:
如果所有字段匹配上后，就得到一个ID号，以与别的表项相区别；
表中除了ID字段的其他字段属于匹配字段，有相应Mask设置，如果Mask=0,则表示该字段是不关心的，即不参与比较/匹配过程。
ID字段的取值是由程序控制的，如果两个表项其他的字段完全相同，则他们的ID号就是相同的。
6、
MR表项（MainRuleTable）：
用于设置相应匹配动作。
有上述五张表，我们可以得到5个ID号；这5个ID就表示我们对该规则的匹配条件，现在就
可以来做相应动作了。
MR表项就是匹配这几个ID号，然后做相应动作。
表中的这几个ID字段属于匹配字段，有相应Mask设置，如果Mask=0,则表示该字段是不关心的，即不参与比较/匹配过程
配置一条规则时，要根据规则内容分散到不同的多个表项中去。
即上层下发一条流规则，底层需要将其内容进行分解，设置到不同的硬件表项当中去。
（我们首先要明确规则是如何进行分解，底层有哪些表项？
）
例1：
aclnamer1advanced
rule0permittcpsoure1.1.1.10eq10destination1.1.1.20eq20
inte2/0/1
packet-filterinboundipr1rule0
底层将设置5个表项:
SrHG表项：
包含信息source1.1.1.10，inte2/0/1;
DstHG表项：
包含信息destination1.1.1.20;
SrL4表项：
包含信息tcp,soureporteq10;
DstL4表项：
包含信息tcp,destinationporteq20;
MR表项：
包含信息permit动作。
例2：
aclnamer2link
rule0denyrarpingress0-0-1egress0-0-3
inte2/0/1
packet-filterinboundlinkr2rule0
底层将设置4个表项：
PT表项：
包含信息Ethernettype=0835;
SrHG表项：
包含信息SrMac0-0-1,inte2/0/1；
DstHG表项：
包含信息DstMac0-0-3；
MR表项：
包含信息deny动作。
每下发一条规则到芯片，都会设置相应表项，当然表项的个数是随着规则内容不同而变化的。
（如例2中的规则只有PT,SrHG,DstHG三个表项）芯片的规则匹配要经过一系列的查找过程。
前5张表都有一个ID号，芯片对前5张表，按表项在CAM中的位置一次匹配，匹配上第一个表项，记下其ID号；接着匹配下一张表，这样得到5个ID号；（如例2中的规则没有SrL4,DstL4表项，在匹配这两个表时，就匹配上缺省表项得到SrL4ID=0和DstL4ID=0）最后，在根据这5个ID号去匹配MR表（对例2中的规则，其MR表项的SrL4ID和DstL4ID字段，要设为不关心。
），并执行相应的动作。
从该过程来看，每个报文进行匹配时，对每一张表只匹配了一次，这虽然大大提高了匹配速度，但显然是非穷举的方法，在某些情况下会造成规则匹配不上等情况。
我们的规则之所以难配，都是这个原因造成的。
以下对几个典型例子进行分析：
例3:
rule1:
protocol61.1.1.10.0.0.0eq201.1.1.30.0.0.0
rule2:
protocol61.1.1.10.0.0.01.1.1.30.0.0.0eq30precedence4
PT
SrHG
DstHG
SrL4
DstL4
MR
rule1
1.1.1.1,in:
3（id=1）
1.1.1.3（id=1）
Tcp,port:
20（id=1）
（-,1,1,1,-）
rule2
1.1.1.1,in:
3precedence:
4（id=2）
1.1.1.3precedence:
4（id=2）
Tcp,port:
30（id=2）
（-,2,2,-,2）
在端口3上，先下发rule1,再下发rule2；
在处理这些表项时，对每个表项按“长度”（有多少个有效字段）进行排序，如rule1的SrHG有2个有效字段，而rule2的SrHG有3个有效字段，所以匹配SrHG表项时，就先匹配rule2的SrHG表项（注意这里对IP地址的大小网段没有做区分）。
MR的表项有效字段个数相同，就先匹配后下发的MR表项。
构造报文1.1.1.1（eq20）==>1.1.1.3，该报文的tos域为0x10（precedence:
4）。
它的匹配情况是：
（0,2,2,1,0），没有匹配上任何一条规则。
例4:
rule1:
any1.1.1.20.0.0.0
rule2:
1.1.1.10.0.0.01.1.1.30.0.0.0
PT
SrHG
DstHG
SrL4
DstL4
MR
rule1
in:
2,5,6（id=1）
1.1.1.2（id=1）
（-,1,1,-,-）
rule2
1.1.1.1,in:
2,3,4（id=2）
1.1.1.3（id=2）
（-,2,2,-,-）
先在端口2,5,6上，下发rule2,
再在端口2,3,4上，下发rule1；
构造报文1.1.1.1==>1.1.1.3ingress2
匹配情况是（0,2,2,0,0），匹配上rule2。
但若构造报文1.1.1.1==>1.1.1.2ingress2
它的匹配情况是（0,2,1,0,0），没有匹配上任何一条规则。
从中可以看出，如果下发的配置比较相似，就比较容易出问题。
这是芯片特性决定的，只能尽量减小其影响，不能完全规避。
其中心就是这是个不完全匹配的过程。
我们的处理一般是，对规则做一些变通。
既然本质是不完全匹配，我们就再构造出几个辅助规则，使之变为完全匹配。
如对例3，我们构造规则
rule3:
protocol61.1.1.10.0.0.0eq201.1.1.30.0.0.0precedence4
rule3与rule1的动作相同。
PT
SrHG
DstHG
SrL4
DstL4
MR
rule1
1.1.1.1,in:
3（id=1）
1.1.1.3（id=1）
Tcp,port:
20（id=1）
（-,1,1,1,-）
rule2
1.1.1.1,in:
3precedence:
4（id=2）
1.1.1.3precedence:
4（id=2）
Tcp,port:
30（id=2）
（-,2,2,-,2）
rule3
1.1.1.1,in:
3precedence:
4（id=2）
1.1.1.3precedence:
4（id=2）
Tcp,port:
20（id=1）
（-,2,2,1,-）
这样对报文1.1.1.1（eq20）==>1.1.1.3precedence4
它的匹配情况是：
（0,2,2,1,0），匹配上rule3,由于rule3与rule1的动作相同，也就相当于匹配上rule1。
与规则匹配有关的另一个关键点是表项的匹配次序。
芯片在匹配每一张表时是按照从低地址向高地址的次序来匹配的，因此如何组织这些表项就是一个很重要的问题。
同时我们也讨论一下下发ACL规则个数的问题。
CAM表中的表项个数是有限的，固定不变的。
PT表项个数为64个，但由于PTID只有5位，其实可用的只有32项；HG表项有128项，而SrHGID和DstHGID各占6位，相当于SrHG表项有64项，DstHG也有64项；L4表项与HG的情况相同，SrL4与DstL4表项也是各有64项；而MR表项有512条，可谓非常多了。
在下发规则时，我们对每张表从高地址开始分配，因此后下发的往往排在下面，优先级会高一些。
为了使匹配过程更合理一些，在处理这些表项时，对每个表项按“长度”（有多少个有效字段）进行排序，长度大的放在低地址处，长度小的放在高地址处。
（注意这里对IP地址的大小网段没有做区分）。
MR的表项有效字段个数相同，就先匹配后下发的MR表项。
因此，配置了许多ACL规则，下发次序是非常重要的，这决定了哪些表项被匹配，哪些没有被匹配。
经常有人问这样的问题：
6506能够下发多少条ACL规则？
为什么我下发了60条就不能再下发了？
准确的数目谁也不能确定，因为每一条规则下发时对应的底层表项个数不相同，而下发的个数就是受底层表项资源的限制；资源耗尽了，就不能再下发了。
一般来说，也就是60条左右。
因为下发规则时，总要在端口上下发，就要占用一个SrHGID，而总共只有64个这种ID,在初始化时，我们又占去了几条，可用的大约在60条左右。
当然，如果深究，就麻烦的多。
其中一点就是not-carefor-interface。
Not-carefor-interface是一个非常重要的参数，用在packet-filter命令当中。
虽然也是在端口上下发，但其不设置端口信息，相当于该规则在这个芯片上全局有效。
它对于节约表项资源有重大价值有重要意义，也使得组网配置更加灵活，有时少了它，甚至都不能满足组网需求。
二、案例部分
以上我们分析了S6506芯片的工作原理，以及可能遇到的问题。
本节通过一些实例来进一步详细解释。
例5、6506上配置4个网段，每个网段包含一个服务器的小网段。
要求：
任何一台PC可以访问每一个服务器网段，相同网段可以互访，而不同网段的PC机不能互访。
举例如下：
假设4个网段分别为：
10.1.0.0/16
10.2.0.0/16
10.3.0.0/16
10.4.0.0/16
而4个服务器小网段分别为：
10.1.1.0/24
10.2.1.0/24
10.3.1.0/24
10.4.1.0/24
6506上配置了FT48和GB8U两块业务板。
具体配置如下：
/*任何一台PC可以访问每一个服务器网段*/
aclnameAccessServeradvanced
rule0permitipdestination10.1.1.00.0.0.255
rule1permitipdestination10.2.1.00.0.0.255
rule2permitipdestination10.3.1.00.0.0.255
rule3permitipdestination10.4.1.00.0.0.255
rule4permitipsource10.1.1.00.0.0.255
rule5permitipsource10.2.1.00.0.0.255
rule6permitipsource10.3.1.00.0.0.255
rule7permitipsource10.4.1.00.0.0.255
/*相同网段可以互访*/
aclnameAccessInsideadvanced
rule0permitipsource10.1.0.00.0.255.255destination10.1.0.00.0.255.255
rule1permitipsource10.2.0.00.0.255.255destination10.2.0.00.0.255.255
rule2permitipsource10.3.0.00.0.255.255destination10.3.0.00.0.255.255
rule3permitipsource10.4.0.00.0.255.255destination10.4.0.00.0.255.255
/*不同网段的PC机不能互访*/
aclnameDenyInteradvanced
rule0denyip
/*接下来，要在相关芯片上全局下发，假设在slot1上插有GB8U,slot3上插有FT48，要把上述规则在这两块板子的所有芯片全局下发*/
/*在GB8U上全局下发*/
intg1/0/1
packet-filterinboundipDenyInternot-carefor-interface
packet-filterinboundipAccessInsidenot-carefor-interface
packet-filterinboundipAccessServernot-carefor-interface
/*在FT48上全局下发*/
/*先在第一个芯片上下发*/
inte3/0/1
packet-filterinboundipDenyInternot-carefor-interface
packet-filterinboundipAccessInsidenot-carefor-interface
packet-filterinboundipAccessServernot-carefor-interface
/*再在第二个芯片上下发*/
inte3/0/48
packet-filterinboundipDenyInternot-carefor-interface
packet-filterinboundipAccessInsidenot-carefor-interface
packet-filterinboundipAccessServernot-carefor-interface
为什么要这样做？
还是列表来分析吧。
PT
SrHG
DstHG
SrL4
DstL4
MR
AccessServee_0
10.1.10/24（id=1）
（-,-,1,-,-）
AccessServee_1
10.2.10/24（id=2）
（-,-,2,-,-）
AccessServee_2
10.3.10/24（id=3）
（-,-,3,-,-）
AccessServee_3
10.4.10/24（id=4）
（-,-,4,-,-）
AccessServee_4
10.1.10/24（id=1）
（-,1,-,-,-）
AccessServee_5
10.2.10/24（id=2）
（-,2,-,-,-）
AccessServee_6
10.3.10/24（id=3）
（-,3,-,-,-）
AccessServee_7
10.4.10/24（id=4）
（-,4,-,-,-）
AccessInside_0
10.1.0.0/16（id=5）
10.1.0.0/16（id=5）
（-,5,5,-,-）
AccessInside_1
10.2.0.0/16（id=6）
10.2.0.0/16（id=6）
（-,6,6,-,-）
AccessInside_2
10.3.0.0/16（id=7）
10.3.0.0/16（id=7）
（-,7,7,-,-）
AccessInside_3
10.4.0.0/16（id=8）
10.4.0.0/16（id=8）
（-,8,8,-,-）
DedyInter_3
（-,-,-,-,-）
按我们的下发次序，对各表项的匹配次序为从上到下进行。
大家可以构造几个报文来验证一下其正确性。
如果再要求只有网段10.1.0.0/16可以访问外部网络。
aclnameAccessOutsideadvanced
rule0permitipsource10.1.0.00.0.255.255destination0.0.0.0127.255.255.255
rule1permitipsource10.1.0.00.0.255.255destination128.0.0.0127.255.255.255
rule2permitipsource0.0.0.0127.255.255.255destination10.1.0.00.0.255.255
rule3permitipsource128.0.0.0127.255.255.255destination10.1.0.00.0.255.255
rule4permitipsource10.1.1.00.0.0.255destination0.0.0.0127.255.255.255
rule5permitipsource10.1.1.00.0.0.255destination128.0.0.0127.255.255.255
rule6permitipsource0.0.0.0127.255.255.255destination10.1.1.00.0.0.255
rule7permitipsource128.0.0.0127.255.255.255destination10.1.1.00.0.0.255
在接口上按如下次序下发：
packet-filterinboundipDenyInternot-carefor-interface
packet-filterinboundipAccessOutsidenot-carefor-interface
packet-filterinboundipAccessInsidenot-carefor-interface
packet-filterinboundipAccessServernot-carefor-interface
上例中有大小网段的嵌套关系，因此规则的下发次序至观重要，我们总是把大网段先下发，而小网段后下发。
否则，将先匹配大网段，而永远不会匹配到小网段。
例6：
VLAN2:
10.42.12.129-10.42.12.190255.255.255.192
VLAN3:
10.42.12.193-10.42.12.254255.255.
升级会员 