访问控制列表（Access Control Lists，ACL）是一种由一条或多条指令的集合，指令里面可以是报文的源地址、目标地址、协议类型、端口号等，根据这些指令设备来判断哪些数据接收，哪些数据需要拒绝接收。它类似于一种数据包过滤器。
当某个局域网中需要使某些主机无法访问指定的资源，时就需要这么一个技术实现流量的过滤，如下图所示，某公司为保障财务部数据安全，机制研发部门访问财务部服务器，但总裁办公室不受影响：
ACL是由一系列permit（允许）或deny（拒绝）语句组成的有序规则的列表，它单独是无法使用的，需要应用在业务模块中才能生效，如在NAT中调用、在防火墙的策略部署中被调用、在路由策略中被调用和用来通过流量过滤。
访问控制列表编号：在配置ACL时，每个ACL都会分配一个编号，不同编号代表不同的ACL；
规则：一个ACL通常由一条或多条“permit/deny”语句组成，一条语句就是一条规则；
规则编号：每条规则都有一个相应的编号，用来标识ACL规则，可以由用户指定；
动作：permit代表允许，deny代表拒绝，用来给规则设定相应动作；
匹配项：可以是源MAC地址、目的MAC，目的地址、协议类型等。
如：rule 10 permit source 1.1.1.0 0.0.0.255
代表：规则10允许源地址为1.1.1.0/24网段地址的报文通过。
（1）基本ACL：ACL编号2000-2999，只能用报文的源IP地址、分片时间和生效时间段来定义规则；
（2）高级ACL：ACL编号3000-3999，可以使用报文的源IP地址、目的IP地址、协议类型、源端口号、目的端口号、生效时间来定义规则；
（3）二层ACL：ACL编号4000-4999，使用报文的以太网帧头信息，如源MAC地址、目的MAC地址、二层协议类型等来定义规则；
（4）用户自定义ACL：ACL编号5000-5999，使用报文头、偏移位置、字符串掩码、用户自定义字符串来定义规则；
（5）用户ACL：ACL编号6000-6999，可用IP报文的源/目标IP地址、IP协议类型、ICMP类型、端口来定义规则；
除此之外，ACL还可以通过名称代替编号来标识ACL。
如：rule x permit source 1.1.1.0 0.0.0.255
ACL的匹配过程如下图所示：
（1）查找ACL是否存在
不存在：结束，匹配结果为不匹配；
存在：查找设备是否配置了ACL规则；
（2）是否存在ACL规则
不存在：结束，匹配结果为不匹配；
存在：从ACL编号最小的规则（rule）开始进行查找；
（3）查看是否命中规则
如果匹配上了permit规则，则停止查找规则，并返回ACL匹配结果为：匹 配如果匹配上了deny规则，则停止查找规则，并返回ACL匹配结果为：匹配
如果未匹配上规则，则继续查找下一条规则，以此循环。若查到最后依然没有匹配上，则匹配结果为：不匹配。
例：如下图所示
根据上述ACL匹配规则继续流量过滤，由上图可知规则4与规则3在不看编号大小的情况下是有冲突的，但是按ACL编号匹配规则，从编号小的进行匹配，匹配则命中。
ACL匹配位置：inbound和outbound
由上图所示：
当ACL配置在路由器左边，也就是输入的路由器的入口处叫做inbound方向，报文匹配过程如下所示：
当ACL配置在路由器右边，也就是路由器的输出口处叫做outbound方向，报文匹配过程如下所示：
访问控制列表ACL（Access Control List）是由一条或多条规则组成的集合。所谓规则，是指描述报文匹配条件的判断语句，这些条件可以是报文的源地址、目的地址、端口号等。
ACL本质上是一种报文过滤器，规则是过滤器的滤芯。设备基于这些规则进行报文匹配，可以过滤出特定的报文，并根据应用ACL的业务模块的处理策略来允许或阻止该报文通过。
ACL配置完成后，必须应用在业务模块中才能生效，其中最基本的ACL应用，就是在简化流策略/流策略中应用ACL，使设备能够基于全局、VLAN或接口下发ACL，实现对转发报文的过滤。此外，ACL还可以应用在Telnet、FTP、路由等模块。
业务模块之间的ACL默认处理动作和处理机制有所不同，具体请参见ACL应用模块的ACL默认动作和处理机制。
ACL可以实现对网络中报文流的精确识别和控制，达到控制网络访问行为、防止网络攻击和提高网络带宽利用率的目的，从而切实保障网络环境的安全性和网络服务质量的可靠性。
图1是一个典型的ACL应用组网场景。
某企业为保证财务数据安全，禁止研发部门访问财务服务器，但总裁办公室不受限制。实现方式：在Interface 1的入方向上部署ACL，禁止研发部门访问财务服务器的报文通过。Interface 2上无需部署ACL，总裁办公室访问财务服务器的报文默认允许通过。
保护企业内网环境安全，防止Internet病毒入侵。实现方式：在Interface 3的入方向上部署ACL，防止病毒通过该接口入侵。
ACL由一系列规则组成，通过将报文与ACL规则进行匹配，设备可以过滤出特定的报文。设备支持软件ACL和硬件ACL两种实现方式。
一条ACL的结构组成，如图所示。
ACL名称：通过名称来标识ACL，就像用域名代替IP地址一样，更加方便记忆。这种ACL，称为命名型ACL。
命名型ACL一旦创建成功，便不允许用户再修改其名称。
仅基本ACL与基本ACL6，以及高级ACL与高级ACL6，可以使用相同的ACL名称；其他类型ACL之间，不能使用相同的ACL名称。
命名型ACL实际上是“名字 数字”的形式，可以在定义命名型ACL时同时指定ACL编号。如果不指定编号，则由系统自动分配，设备为其分配的编号是该类型ACL可用编号中取值范围内的最大值。
ACL编号：用于标识ACL，也可以单独使用ACL编号，表明该ACL是数字型。
不同的ACL类型使用不同的ACL编号取值标识。
规则：即描述报文匹配条件的判断语句。
规则编号：用于标识ACL规则。可以自行配置规则编号，也可以由系统自动分配。
ACL规则的编号范围是0～4294967294，所有规则均按照规则编号从小到大进行排序。系统按照规则编号从小到大的顺序，将规则依次与报文匹配，一旦匹配上一条规则即停止匹配。
动作：报文处理动作，包括permit/deny两种，表示允许/拒绝。
匹配项：ACL定义了极其丰富的匹配项。除了图1中的源地址和生效时间段，ACL还支持很多其他规则匹配项。例如，二层以太网帧头信息（如源MAC、目的MAC、以太帧协议类型），三层报文信息（如目的IP地址、协议类型），以及四层报文信息（如TCP/UDP端口号）等。关于每种匹配项的详细介绍，请参见交换机支持的ACL及常用匹配项。
目前设备支持的ACL，有以下两种实现方式。
软件ACL：针对与本机交互的报文（必须上送CPU处理的报文），由软件实现来过滤报文的ACL，比如FTP、TFTP、Telnet、SNMP、HTTP、路由协议、组播协议中引用的ACL。
硬件ACL：针对所有报文，通过下发ACL资源到硬件来过滤报文的ACL，比如流策略、基于ACL的简化流策略、用户组以及为接口收到的报文添加外层Tag功能中引用的ACL。
过滤的报文类型不同：软件ACL用来过滤与本机交互的报文，硬件ACL可以用来过滤所有报文。
报文过滤方式不同：软件ACL是被上层软件引用来实现报文的过滤，硬件ACL是被下发到硬件来实现报文的过滤。通过软件ACL过滤报文时，会消耗CPU资源，通过硬件ACL过滤报文时，则会占用硬件资源。通过硬件ACL过滤报文的速度更快。
对不匹配ACL的报文的处理动作不同：当使用软件ACL时，如果报文未匹配上ACL中的规则，设备对该报文采取的动作为deny，即拒绝报文通过；当使用硬件ACL时，如果报文未匹配上ACL中的规则，设备对该报文采取的动作为permit，即允许报文通过。
交换机支持的ACL
如表所示，交换机支持的ACL规则包括过滤IPv4报文的ACL、过滤IPv6报文的ACL6以及既支持过滤IPv4报文又支持过滤IPv6报文的二层ACL和用户自定义ACL。
交换机支持的ACL匹配项种类非常丰富，其中最常用的匹配项包括以下几种。
所有ACL均支持根据生效时间段time-range time-name过滤报文。关于生效时间段的详细介绍，请参见ACL的生效时间段。
格式：
protocol-number | icmp | tcp | udp | gre | igmp | ip | ipinip |
ospf
高级ACL支持基于协议类型过滤报文，常用的协议类型如下表所示。
IP表示任何IP层协议。协议号的取值可以是1～255。
例如，当设备某个接口下的用户存在大量的攻击者时，如果希望能够禁止这个接口下的所有用户接入网络，则可以通过指定协议类型为IP来屏蔽这些用户的IP流量来达到目的。
配置如下：
rule deny ip //表示拒绝IP报文通过
源IP地址及其通配符掩码格式：source { source-address source-wildcard | any }
目的IP地址及其通配符掩码格式：destination { destination-address destination-wildcard | any }
基本ACL支持根据源IP地址过滤报文，高级ACL不仅支持源IP地址，还支持根据目的IP地址过滤报文。
将源/目的IP地址定义为规则匹配项时，需要在源/目的IP地址字段后面同时指定通配符掩码，用来与源/目的IP地址字段共同确定一个地址范围。
IP地址通配符掩码与IP地址的反向子网掩码类似，也是一个32比特位的数字字符串，用于指示IP地址中的哪些位将被检查。
各比特位中，“0”表示“检查相应的位”，“1”表示“不检查相应的位”，概括为一句话就是“检查0，忽略1”。但与IP地址子网掩码不同的是，子网掩码中的“0”和“1”要求必须连续，而通配符掩码中的“0”和“1”可以不连续。
通配符掩码可以为0，相当于0.0.0.0，表示源/目的地址为主机地址；也可以为255.255.255.255，表示任意IP地址，相当于指定any参数。
举一个IP地址通配符掩码的示例，当希望来自192.168.1.0/24网段的所有IP报文都能够通过，可以配置如下规则：
rule 5 permit ip source 192.168.1.0 0.0.0.255
规则中的通配符掩码为0.0.0.255，表示只需检查IP地址的前三组二进制八位数对应的比特位。因此，如果报文源IP地址的前24个比特位与参照地址的前24个比特位（192.168.1）相同，即报文的源IP地址是192.168.1.0/24网段的地址，则允许该报文通过。表2展示了该例的地址范围计算过程。
表2 通配符掩码示例
更多的IP地址与通配符掩码共同确定的地址范围示例，详见表3。
表3 IP地址与通配符掩码共同确定的地址范围
源MAC地址及其通配符掩码格式：
source-mac source-mac-address [ source-mac-mask ]
目的地址及其通配符掩码格式：
destination-mac dest-mac-address [ dest-mac-mask ]
仅二层ACL支持基于源/目的MAC地址过滤报文。
将源/目的MAC地址定义为规则匹配项时，可以在源/目的MAC地址字段后面同时指定通配符掩码，用来与源/目的MAC地址字段共同确定一个地址范围。
MAC地址通配符掩码的格式与MAC地址相同，采用十六进制数表示，共六个字节（48位），用于指示MAC地址中的哪些位将被检查。
与IP地址通配符掩码不同的是，MAC地址通配符掩码各比特位中，1表示“检查相应的位”，0表示“不检查相应的位”。如果不指定通配符掩码，则默认掩码为ffff-ffff-ffff，表示检查MAC地址的每一位。
MAC地址与通配符掩码共同确定的地址范围示例，如表4所示。
外层VLAN及其掩码格式：vlan-id vlan-id [ vlan-id-mask ]
内层VLAN及其掩码格式：cvlan-id cvlan-id [ cvlan-id-mask ]
二层ACL支持基于外层VLAN或内层VLAN编号过滤报文。
将VLAN编号定义为规则匹配项时，可以在VLAN编号字段后面同时指定VLAN掩码，用来与VLAN编号字段共同确定一个VLAN范围。
VLAN掩码的格式是十六进制形式，取值范围是0x0～0xFFF。如果不指定VLAN掩码，则默认掩码为0xFFF，表示检查VLAN编号的每一位。
VLAN编号与掩码共同确定的VLAN范围示例，如表5所示。
源端口号格式：
source-port { eq port | gt port | lt port | range port-start port-end }
目的端口号格式：
destination-port { eq port | gt port | lt port | range port-start port-end }
在高级ACL中，当协议类型指定为TCP或UDP时，设备支持基于TCP/UDP的源/目的端口号过滤报文。
其中，TCP/UDP端口号的比较符含义如下：
eq port：指定等于源/目的端口。
gt port：指定大于源/目的端口。
lt port：指定小于源/目的端口。
range port-start port-end：指定源/目的端口的范围。port-start是端口范围的起始，port-end是端口范围的结束。
TCP/UDP端口号可以使用数字表示，也可以用字符串（助记符）表示。例如，rule deny tcp destination-port eq 80，可以用rule deny tcp destination-port eq www替代。
常见TCP/UDP端口号及对应的字符串参见rule（高级ACL视图）中的常用TCP协议源端口号或者目的端口号与port的取值对应关系和常用UDP协议源端口号或者目的端口号与port的取值对应关系表。
格式：
tcp-flag { ack | established | fin | psh | rst | syn | urg }*
在高级ACL中，当协议类型指定为TCP时，设备支持基于TCP标志信息过滤报文。
TCP报文头有6个标志位：ack (acknowledge)、fin (finish)、psh (push)、rst (reset)、syn (synchronize)和urg (urgent)。
TCP标志信息中的established，表示标志位为ACK(010000)或RST(000100)。
指定tcp-flag的ACL规则可以用来实现单向访问控制。
假设，要求192.168.1.0/24网段用户可以主动访问192.168.2.0/24网段用户，但反过来192.168.2.0/24网段用户不能主动访问192.168.1.0/24。可通过在设备上连接192.168.2.0/24网段的接口入方向上，应用ACL规则来实现该需求。
由TCP建立连接和关闭连接的过程可知，只有在TCP中间连接过程的报文才会ACK=1或者RST=1。根据这个特点，配置如下两种ACL规则，允许TCP中间连接过程的报文通过，拒绝其他TCP报文通过，就可以限制192.168.2.0/24网段主动发起的TCP连接。
类型一：配置指定ack和rst参数的ACL规则
rule 5 permit tcp source 192.168.2.0 0.0.0.255 tcp-flag ack //允许ACK=1的TCP报文通过
rule 10 permit tcp source 192.168.2.0 0.0.0.255 tcp-flag rst //允许RST=1的TCP报文通过
rule 15 deny tcp source 192.168.2.0 0.0.0.255 //拒绝其他TCP报文通过
类型二：配置指定established参数的ACL规则
rule permit tcp source 192.168.2.0 0.0.0.255 tcp-flag established // established表示ACK=1或者RST=1，表示允许TCP中间连接过程的报文通过
rule deny tcp source 192.168.2.0 0.0.0.255 //拒绝其他TCP报文通过
格式：fragment
基本ACL和高级ACL支持基于IP分片信息过滤报文。
IP分片除了首片报文外，还有后续分片报文，又叫做非首片分片报文。仅首片分片报文携带四层信息（如TCP/UDP端口号等），后续分片报文均不携带。
网络设备收到分片报文后，会判断其是否是最后一个分片报文。如果不是，则为其分配内存空间，以便于最后一个分片报文到达后完成重组。黑客可以利用这一点，向接收方设备发起分片报文攻击，始终不向接收方发送最后一个分片报文。
为了解决这个问题，可以配置指定fragment匹配项的ACL规则来阻塞非首片分片报文，从而达到防范分片报文攻击的目的。
针对非分片报文、首片分片报文、非首片分片报文这三类报文，ACL的处理方式如表6所示。
例如，ACL 3012中存在以下规则：
acl number 3012
rule 5 deny tcp destination 192.168.2.2 0 fragment
rule 10 permit tcp destination 192.168.2.2 0 destination-port eq www
rule 15 deny ip
对于目的IP地址是192.168.2.2的TCP报文：
该报文是非分片报文或首片分片报文时：
如果该报文的目的端口号是80（www对应的端口号是80），则报文与rule 10匹配，报文被允许通过；如果该报文的目的端口号不是80，则报文与rule 15匹配，报文被拒绝通过。
该报文是非首片分片报文时：该报文与rule 5匹配，报文被拒绝通过。
设备将报文与ACL规则进行匹配时，遵循“一旦命中即停止匹配”的机制，如图1所示。
从上面的ACL匹配流程可以看出，报文与ACL规则匹配后，会产生两种结果：“命中规则”和“未命中规则”。
命中规则：指存在ACL，且在ACL中查找到了符合匹配条件的规则。
未命中规则：指不存在ACL，或ACL中无规则，再或者在ACL中遍历了所有规则都没有找到符合匹配条件的规则。
报文最终是被允许通过还是拒绝通过，实际是ACL规则中的指定动作和应用ACL的各个业务模块来共同决定。
不同的业务模块，对命中和未命中规则报文的处理方式也各不相同。例如，在Telnet模块中应用ACL，只要报文命中了规则且ACL规则动作为permit，就允许通过；
而在流策略中应用ACL，如果报文命中了规则且ACL规则动作为permit，但流行为动作配置的是deny，该报文仍会被拒绝通过。关于各个业务模块ACL处理机制的详细介绍，请参见ACL应用模块的ACL默认动作和处理机制。
如上面的流程图所示，一条ACL由多条rule规则组成时，这些规则可能存在重复或矛盾的地方。例如，在一条ACL中先后配置以下两条规则：
rule deny ip destination 10.1.0.0 0.0.255.255 //表示拒绝目的IP地址为10.1.0.0/16网段地址的报文通过
rule permit ip destination 10.1.1.0 0.0.0.255 //表示允许目的IP地址为10.1.1.0/24网段地址的报文通过，该网段地址范围小于10.1.0.0/16网段范围
对于目的IP=10.1.1.1的报文，如果系统先将deny规则与其匹配，则该报文会被拒绝通过。相反，如果系统先将permit规则与其匹配，则该报文会得到允许通过。
因此，对于规则之间存在重复或矛盾的情形，报文的匹配结果与ACL的匹配顺序是息息相关的。
设备支持两种ACL匹配顺序：配置顺序（config模式）和自动排序（auto模式）。缺省的ACL匹配顺序是config模式。
配置顺序，即系统按照ACL规则编号从小到大的顺序进行报文匹配，规则编号越小越容易被匹配。
如果配置规则时指定了规则编号，则规则编号越小，规则插入位置越靠前，该规则越先被匹配。
如果配置规则时未指定规则编号，则由系统自动为其分配一个编号。该编号是一个大于当前ACL内最大规则编号且是步长整数倍的最小整数，因此该规则会被最后匹配。
自动排序，是指系统使用“深度优先”的原则，将规则按照精确度从高到低进行排序，并按照精确度从高到低的顺序进行报文匹配。规则中定义的匹配项限制越严格，规则的精确度就越高，即优先级越高，系统越先匹配。各类ACL的“深度优先”顺序匹配原则如表1所示。
关于表1中提到的ACL匹配项的详细介绍，请参见交换机支持的ACL及常用匹配项。
在自动排序的ACL中配置规则时，不允许自行指定规则编号。系统能自动识别出该规则在这条ACL中对应的优先级，并为其分配一个适当的规则编号。
例如，在auto模式的高级ACL 3001中，先后配置以下两条规则：
rule deny ip destination 10.1.0.0 0.0.255.255 //表示拒绝目的IP地址为10.1.0.0/16网段地址的报文通过
rule permit ip destination 10.1.1.0 0.0.0.255 //表示允许目的IP地址为10.1.1.0/24网段地址的报文通过，该网段地址范围小于10.1.0.0/16网段范围
两条规则均没有带VPN实例，且协议范围、源IP地址范围相同，所以根据表1中高级ACL的深度优先匹配原则，接下来需要进一步比较规则的目的IP地址范围。
由于permit规则指定的目的地址范围小于deny规则，所以permit规则的精确度更高，系统为其分配的规则编号更小。配置完上述两条规则后，ACL 3001的规则排序如下：
acl number 3001 match-order auto
rule 5 permit ip destination 10.1.1.0 0.0.0.255
rule 10 deny ip destination 10.1.0.0 0.0.255.255
此时，如果再插入一条新的规则rule deny ip destination 10.1.1.1 0（目的IP地址范围是主机地址，优先级高于以上两条规则），则系统将按照规则的优先级关系，重新为各规则分配编号。插入新规则后，ACL 3001新的规则排序如下：
acl number 3001 match-order auto
rule 5 deny ip destination 10.1.1.1 0
rule 10 permit ip destination 10.1.1.0 0.0.0.255
rule 15 deny ip destination 10.1.0.0 0.0.255.255
相比config模式的ACL，auto模式ACL的规则匹配顺序更为复杂，但是auto模式ACL有其独特的应用场景。
例如，在网络部署初始阶段，为了保证网络安全性，管理员定义了较大的ACL匹配范围，用于丢弃不可信网段范围的所有IP报文。随着时间的推移，实际应用中需要允许这个大范围中某些特征的报文通过。
如果管理员采用的是auto模式，则只需要定义新的ACL规则，无需再考虑如何对这些规则进行排序避免报文被误丢弃。
