在前面的几个小节中描述了关于标准与扩展ACL的应用，并演示了具体的配置过程，在本节小编主要对ACL的应用事项进行一下总结，其中包括ACL的输写形式、ACL的应用位置、ACL条目的增加与删除，具体如下：
关于ACL语句的输写形式：
access-list 1permit host 等于access-list 1 permit 的功能，语句中的host是申明配置的地址是一个主机地址，它等于反码的全匹配(),以全匹配形式出现的反码，表示匹配的IP地址是一个主机IP地址。
access-list 102permit tcp eq www 等于access-list 102 permit tcp any any eq 80的功能，语句中的源IP地址和目标IP地址都是0，指示源和目标IP地址可以是任意IP地址;源地址和目标地址的反码都是255，指示不关心任何位，它就等同于在扩展ACL中源和目标IP地址都以any关键字出现的情况;eqwww就等于eq 80，因为TCP 80号端口正是众所周知的www服务端口，但是这里提出一个注意事项，如果Web服务器的端口没有使用众所周知的80号端口，出于某种安全原因或者特殊要求，服务器管理员自定义了Web的服务端口号，那么，在输写ACL时，就只能在eq关键字之后申明具体的端口号，而不是申明www，否则ACL将无法完成匹配。
access-list 102permit ip host host 等于access-list 102 permit ip ;ACL的语句中的'源IP和目标IP都是具体的主机IP地址，所以可以在ACL语句中使有host关键字申明主机地址，它和反码的全匹配形式所表示的意义同种。
关于ACL应用位置的设计：
n 标准ACL只关心源地址，所以必须将其应用到距离控制目标最近的接口位置。
n 扩展ACL既关心源地址，又关心目标地址，建议将其应用到距离控制源最近的接口位置，这样可以优化流量，减少主干网上没有必要的流量开销。
n 在同一接口、同一协议、同一方向只能应用一个访问控制列表。
n 访问控制列表，只能过滤穿越路由器的流量，对应用访问控制列表的路由器本地产生的流量不生效。
关于在传统IOS版本中ACL条目的增加与删除问题
在传统的IOS版本中，对ACL条目的增加或者删除是一件非常痛苦的事情，因为当一个ACL的多条语句被配置在路由器之后，如果想要在ACL中增加一条过滤语句，那么这条增加的语句将出现在已存在的所有ACL语句之后，这样就会出现安全漏洞，为网络造成风险行为，为了更好的理解这一点，现在要举一个实例：
用户首次已经完成了一条ACL 101的编写：
ACL 101 的第一条语句 ：access-list 101 deny ip host
ACL 101 的第二条语句： access-list 101 permit ip any any
现在用户希望更改原有的ACL 101，希望在上述的两条语句之间加入如下所示的ACL语句：
access-list 101 deny ip host
但是当你完成加入后，这条被加入的语句将被放到ACL 101的最后，如下图所示，这样，它的匹配顺序也如图所示，最后加入的语句被放置到ACL列表的最后，而第二条语句是允许任何流量，所以根本不会给第三条语句匹配的机会，那么第三条语句将永远不生效，即便是您可能希望它于permit any any 之前生效，但事实上它不会，这类似于微机原理里面的堆栈原理，先进入。先调用。
所以在传统IOS中管理员对ACL的修改变得很头痛，通常，管理员会把现在的ACL复制到一个文本文件中进行增加或者删除语句的操作，然后把原本在路由器上配置的ACL通过no access-list 101全部清除，再将文本文件中修改完成的ACL复制到路由器上，无法做到逐条修改ACL语句的效果。
