1、交换机配置ACL，接口下是否包含一个隐含的拒绝所有数据的ACL
1）对于S3250，S3750，S3760系列产品，应用到硬件的访问列表末尾不隐含“拒绝所有数据流”语句，而隐含“通过所有数据流”语句。
2）对于其他型号交换机末尾都有隐含拒绝所有数据流的语句
2、在SVI接口下配置ACL，需要对该vlan下转发的二层报文也生效，如何设置
1）作用在三层接口的安全ACL称为Router
ACLs，Router ACLs仅对三层转发的路由报文生效，作用于SVI上的安全ACL同时对于VLAN内的桥转发报文及VLAN间的路由报文生效，从而导致VLAN内用户无法通信等异常现象。
2）为满足SVI ACL的Router
ACLs特性，锐捷交换系列产品开发了SVI Router ACLs使能指令。开启该功能后，作用在SVI上的安全ACL仅对VLAN间的三层转发报文生效，而不对VLAN内的桥转发报文进行控制。
3）缺省情况下，SVI
Router ACLs关闭，SVI ACL同时对VLAN间的三层转发报文及VLAN内的桥转发报文生效。
可以在全局模式下开启该命令，只对三层转发报文生效。
Ruijie(config)# svi
router-acls enable
注：只有32E、S37E、S5750交换机上支持该命令。
3、S12K在配置ACL时提示Entries
are full, or not supported by device
出现提示的原因应该是有两种，一种是ACE表项满了，一种是不支持range配置方式
在配置ACL时出现如下提示：
SXNU12(config-if-GigabitEthernet 4/3)#ip access-group To160.10 out
Entries are full, or not
supported by device
*Dec 6 01:49:12:
%SECURITY-3-TCAM_RESOURCE_LIMIT: TCAM resource is temporary not available.
*Dec 6 01:49:12: %ACL-6-ATTACH: Fail to
attach acl
实际TCAM表项并没有满，线卡是DA类线卡，原因是因为该线卡out方向ACL不支持range选项。
SXNU8606(config-ext-nacl)#ip access-list extended To160.10
SXNU8606(config-ext-nacl)# 5 deny icmp any any
SXNU8606(config-ext-nacl)#$202.207.160.2
host 202.207.160.10
SXNU8606(config-ext-nacl)#$202.207.160.89
host 202.207.160.10
SXNU8606(config-ext-nacl)#
30 permit tcp any eq www host 202.207.160.10
SXNU8606(config-ext-nacl)#$55
host 202.207.160.10 range 1976 1979//out方向ACL不支持带range选项
4、S21端口配置端口安全，绑定IP+MAC，提示错误：%
Error: Attribute conflict
S21端口安全功能不能与ACL共用。
5、S26/26E/S29E/3250E/3760E/5750
接入安全组件（安全通道、全局IP和MAC绑定、端口安全、 802.1X认证、GSN绑定、IP Source Guard、arp-check）与ACL共用说明
1）默认情况（也就是兼容模式）下，如果存在安全ACL的Pemit表项，Pemit和默认Deny的ACE不会被安装到硬件，不生效，其他Deny表项的ACE正常生效。
2）如果在非兼容模式下共用时，安全ACL的Pemit和Deny同时生效；但是此时硬件表项的损耗较大，导致各种接入控制应用、网络安全应用的可用硬件表项容量下降，损耗严重时将导致各种安全应用由于硬件资源不足而开启失败。假设接入控制用户为M，安全ACL的ACE表项为N，在RGOS兼容模式共存下，耗费的表项最大为M+N条；而在RGOS非兼容模式共存下，耗费的表项最大为M*N条
调整命令：
Ruijie(config)#no
rgos-security compatible
配置后需要重启生效。
6、S29/3760/5760接入安全组件（安全通道、全局IP和MAC绑定、端口安全、
802.1X认证、GSN绑定、IP Source Guard、arp-check）与ACL共用说明
不管兼容还是非兼容模式，安全ACL的Pemit和Deny同时生效。
7、关于交换机上面配置tcp
neq方式的acl的限制说明
1）S2600、S2600E、S3000E、S5750产品，对于EA类线卡或者设备（比如57v1.0硬件），作用在IN或OUT方向的Expert
扩展acl都不支持TCP、UDP报文4层端口的“neq”匹配；对于EB类线卡或者设备（比如57v2.0硬件），作用在IN方向的Expert
扩展acl不支持TCP、UDP报文4层端口的“neq”匹配，作用在OUT方向的ACL仅支持TCP、UDP报文4层端口的“eq”匹配。
2）S8600 系列产品，对于EB类和EC线卡,
作用在IN或OUT方向的Expert 扩展acl都不支持TCP、UDP报文4层端口的“neq”匹配；作用在IN方向的Expert扩展acl不支持TCP、UDP报文4层端口的“neq”匹配，作用在OUT方向的ACL仅支持TCP、UDP报文4层端口的“eq”匹配。
3）S12000系列产品，对于EA线卡,
作用在IN或OUT方向的Expert 扩展acl都不支持TCP、UDP报文4层端口的“neq”匹配；作用在IN方向的Expert 扩展acl不支持TCP、UDP报文4层端口的“neq”匹配，作用在OUT方向的ACL仅支持TCP、UDP报文4层端口的“eq”匹配。
8、S8606，接口配置dot1x与ACL兼容问题说明
？
当前S86的1X与物理接口或者SVI口上的ACL共用时，存在如下几种组合情况：
1）物理接口配置ACL与dot1x，ACL里面的ACE有permit xx，也有deny xx的组合
a）用户1x认证前，报文具体是怎么被控制的
b）用户1x认证后，报文是怎么被控制的
〈--- 满足ACL的报文优先受ACL控制(ACL的permit不生效，deny会生效)；不满足ACL的报文，受dot1x认证控制(认证成功的用户报文允许转发,
未认证的用户报文不允许转发)。
2）SVI接口配置ACL与dot1x，ACL里面的ACE有permit
xx，也有deny xx的组合
a）用户1x认证前，报文具体是怎么被控制的
b）用户1x认证后，报文是怎么被控制的
〈--- SVI接口的ACL的permit和deny表项都会下发,
且SVI的ACL关联的是所有实际物理端口（该vlan所对应的access或者trunk口）. ACL(不包含默认deny表项)高于1x认证, 1x认证高于ACL的默认deny表项.
兼容问题具体说明如下：
1. 物理接口配置ACL与dot1x共用的情况:
ip access-list
extended 199
10 permit ip
host 10.11.12.13 any
20 deny ip host
10.10.10.10 any
interface
GigabitEthernet 1/1
ip access-group
199 in
dot1x
port-control auto
《---- ACL的表项只下发deny表项.
permit表项不下发, 即只有deny表项生效。所以主机10.10.10.10不管是否认证都无法被放行，而主机10.11.12.13认证前无法被放行，如果dot1x认证成功能报文可以被放行。
2. 物理口配置dot1x, SVI口配置ACL
ip access-list
extended 199
10 permit ip
host 10.11.12.13 any
20 deny ip host
10.10.10.10 any
interface
GigabitEthernet 1/1
switchport
access vlan 163
dot1x
port-control auto
interface VLAN
163
ip address
10.0.0.1 255.0.0.0
ip access-group
199 in
〈--- 满足ACL的报文受ACL控制(ACL的permit和deny都会生效),
不满足ACL的报文, 受1x认证控制(认证的用户报文允许转发, 未认证的用户报文不允许转发)。这样主机10.11.12.13不需要1X认证就可以被放通，而主机10.10.10.10未认证报文无法放行，1X认证后报文被放行，除此两个主机外，其他的IP认证前无法访问，1X认证成功后报文可被放行。
〈--- SVI ACL下发的时候是下发到所有物理端口，不关心物理口是access口还是trunk口。
综上:
(1) 物理口ACL和dot1x共存时,
物理口ACL会自动过滤permit表项，只有deny语句优先生效，然后才是认证后dot1x生效。
(2) 如果是SVI关联ACL和dot1x共存时，
permit也会生效, 且优先级比1x认证高, 所以如果报文匹配ACL的某个语句时，直接按照该语句的策略放通或者丢弃，而后不匹配ACL的才继续通过dot1x来认证控制，这样可能导致未认证的用户由于匹配中permit也可以转发。
9、5760，配置，删除，增加ACL的条目数量可能导致部分表项不生效
？
1）、5760只有一个资源整合器，第一次在SVI下调用acl，资源整合器会生效，使得1条ACE只占用1条ACE硬件资源；
2）、当在另外一个SVI下，调用另外一条ACL时候，占用的硬件ACE表项=ACE条目*接口数（所有的接口）。由于整个设备硬件资源表项是有限的，所以超过后不能保证ACL生效；
3）、如果接口下no掉第一次调用的ACL，再在SVI口下调用ACL，此时资源整合器不一定会进行整合。也就是说，可能调用的时候，硬件ACE表项的计算依然是：硬件ACE表项=ace条目*接口数（所有的接口）。
解决方法：
1）、no掉所有接口下调用的ACL，重新调用。（如果出现部分ACE生效，部分ACE不生效的情况，建议可以将所有的ACE都删除重新配置，重新调用）。建议调用的时候，先调用ACE表项比较多的ACL，这样可以更好的利用资源整合器。
10、S5760在no
switchport的端口上面配置out ACL报错？
S5760所有版本不支持out方向的ACL，建议用in方向ACL。
11、交换机是否支持在接口下同时调用IP的ACL和MAC的ACL
？
不支持，只支持在接口下使用其中一种ACL，并且该种ACL也只能使用一条，不能同时配置两条IP
ACL或者两条MAC ACL。
Ruijie(config)#int g0/1
Ruijie(config-if-GigabitEthernet
0/1)#ip access-group 100 in
Ruijie(config-if-GigabitEthernet
0/1)#mac access-group 700 in
Another acl has attached at GigabitEthernet 0/1,
Operation fail
12、对于支持ACL计数功能的交换机，如何用其定位丢包问题
使用该功能的目的：
客户网络出现丢包的情况，可以通过ACL计数功能来定位丢报点，方便我们后续进一步排查。（注：并非所有交换机都支持该功能，若设备支持ip
access-list count命令，就可能支持该能，建议以实际情况为准）
举如下案例：
1）客户网络环境：
客户电脑的网关在S57上，S57与S86通过三层口互联
PC （10.1.1.1） ----- G0/1 （10.1.1.254）S57（20.1.1.1）
G0/2 ----- G1/1 (20.1.1.2 )S86
2）客户问题：
客户PCping S86出现丢包，但是不确定报文丢在哪台设备上。
3）ACL调用：
可以在5750-e的G0/12还有86的G1/1口的in方向和out方向都调用一条acl：
i . 在两台交换机上分别创建ACL 100 与 101
ip access-list
extend 100
permit ip host
10.1.1.1 host 20.1.1.2---》匹配的是pc到86的报文
permit ip any
any --------》必须要配置这条，不然客户的网络会受到影响；
ip access-list
extend 101
permit ip host
20.1.1.2 host 10.1.1.1 ---》匹配的是86到pc的回包
permit ip any
any
ip access-list
count 100
ip access-list
count 101
ii. 在设备上调用ACL
S57E
int g0/2
ip access-list 100 in
ip access-list 101 out
S86
int g1/1
ip access-list 100 out
ip access-list 101 in
iii. 开始ping报文测试
然后在pc上ping
20.1.1.2 10个数据包。这样，正常不丢包应该57E和上acl
100中permit ip host 10.1.1.1 host 20.1.1.2 这条ace应该有匹配到10个包，acl101中permit ip host
20.1.1.2 host 10.1.1.1 这条ace也应该匹配到10个；通过show access-list 100 、 show access-list 101 可以查看到当前ACL的匹配情况
S8610#ping 20.1.1.2 source 10.1.1.1 ntimes 100
Sending 5, 100-byte ICMP
Echoes to 218.200.187.172, timeout is 2 seconds:
< press Ctrl+C to break
>
...!!...!!!.......!!.!!.....!!.!!!..!!.....!!.!!!.!!!!!.!!!........!!!...!!!!.!!!!..!!!..!!.!!!....!
Success rate is 49 percent (49/100), round-trip min/avg/max = 1/1/1 ms
S8610#show access-lists
ip access-list extended 100
10 permit ip
host 10.1.1.1 host 20.1.1.2 (100 match)
100 permit ip any any (25373 matchs)
ip access-list extended 101
10 permit ip
host 20.1.1.2 host 10.1.1.1 (49 match)
100 permit ip any any (25373 matchs)
acl定位发现：通过以上测试效果可以发现，S86可以发出报文，但是没有接收到回应报文，丢包点在S86上一级设备。
13、交换机配置ACL时，使用中文名称，在SecureCRT显示时可能会出现乱码
出现乱码如下：
解决方法：在SecureCRT的选项中将字符编码修改为GB2312，即可以正常显示ACL的中文名称。
14、29E是否能够实现和6220上一样的permit tcp any any established的功能
S29E上没有实现这个功能。
因为S6220上permit tcp any any established是允许TCP Flag 中的RST或ACK置位的报文通过，而不管其他位是否被置上。
S29E上没有实现这个功能，S29E上对TCP Flag的过滤必须匹配TCP Flag的每一位均匹配，例如:
permit tcp any any match-all rst 允许TCP Flag RST置位，其他位为0的报文通过，TCP
FLAGS总共有6位，无法实现只匹配其中某2位的功能。
15、如何配置可以使专家ACL放通所有报文？