無論是在思科路由器還是思科交換機等網絡設備上，標準ACL訪問控制列表始終無法同時匹配通信源地址與目標地址的特性，也不無法滿足現今網絡世界“粒度化”控制的要求，比如：允許訪問某一服務器的某項服務功能，但是不允許Ping通該服務器。那么，就需要使用擴展的ACL來替代標準的ACL的應用，在實際的應用控制中，擴展的ACL較標準ACL而言，似乎更受管理員的喜愛。
演示目標： 配置擴展ACL為網絡應用提供更“粒度化”的控制。
演示環境： 使用演示標準ACL的配置部分的如下圖 ACL的演示環境所示。
演示背景： 要求主機A(192.168.1.2)可以訪問服務器A的WEB服務;但是不允許主機A ping通服務器A所在的子網;允許主機A ping通服務器B和服務器C所在的子網。請使用擴展ACL完成上述的控制要求，并思考應用ACL的位置。
演示步驟：
***步： 保持上一個實驗的所有基礎配置，但是請刪除原本的所有標準ACL的配置，然后根據演示背景需求，完成如下擴展ACL的配置，這一配置建議在路由器R1上完成，因為擴展的ACL可以同時匹配通信源地址與目標地址，可以將其應到距離通信源較近的位置。
R1(config)#access-list 101 permit tcp 192.168.1.0 0.0.0.255 host 192.168.5.2 eq www
* 定義擴展ACL列表101(基于IP的擴展ACL編號的取值范圍是100-199);permit tcp 192.168.1.0 0.0.0.255host 192.168.5.2 eq www 指示允許源子網192.168.1.0對目標地址192.168.5.2的TCP端口80進行訪問，注意，語句中的***個IP子網和反碼指示通信的源子網與對應的反碼;第二個IP地址192.168.5.2被host申明為是一臺具體的主機。
R1(config)#access-list 101 deny icmp 192.168.1.0 0.0.0.255 host 192.168.5.2
* 定義擴展ACL列表101的第二條語句拒絕源子網192.168.1.0通過ICMP協議訪問目標主機192.168.5.2。
R1(config)#access-list 101 permit icmp 192.168.1.0 0.0.0.255 host 192.168.4.2
* 定義擴展ACL列表101的第三條語句允許源子網192.168.1.0通過ICMP協議訪問目標主機192.168.4.2。
R1(config)#access-list 101 permit icmp 192.168.1.0 0.0.0.255 host 192.168.3.2
* 定義擴展ACL列表101的第四條語句允許源子網192.168.1.0通過ICMP協議訪問目標主機192.168.3.2。
R1(config)#interface e1/0
R1(config-if)#ip access-group 101 in
R1(config-if)#exit
建議：將ACL 101應用到路由器R1的E1/0接口，也就是距離源子網最近的位置，這樣做可以讓ACL的利用率更高，流量更合理，因為擴展ACL能同時匹配源地址與目標地址，所以從理論上講，只要能達到控制標準，在流量經過的任何設備上都可以做應用，但是建議在距離源子網最近的位置應用它，因為沒有必要將最終被過濾流量轉發到目標或者中途才丟棄，這對于寶貴的帶寬利用率不科學。
第二步： 當完成上述配置后，在主機A(192.168.1.2)上去訪問服務器A的WEB服務，然后去Ping服務器A、B、C，如果配置無誤，應得到如下圖所示的狀態，這與背景說明中的控制要求一致。
第三步： 為了查看路由器R1上的過濾狀態，可以通過在R1上執行show ip access-lists指令查看ACL的匹配狀態如下圖10.13所示，可以看出有5個WWW的數據包被允許;8個到服務器A的ICMP的數據包被拒絕;分別有4個到服務器B和C的ICMP數據包被允許。
#FormatImgID_2#
關于ACL的其它輸寫形式與應用注意事項
在前面的幾個小節中描述了關于標準與擴展ACL的應用，并演示了具體的配置過程，在本節主要對ACL的應用事項進行一下總結，其中包括ACL的輸寫形式、ACL的應用位置、ACL條目的增加與刪除，具體如下：
關于ACL語句的輸寫形式：
access-list 1permit host 192.168.100.1等于access-list 1 permit 192.168.100.1 0.0.0.0的功能，語句中的host是申明配置的地址是一個主機地址，它等于反碼的全匹配(0.0.0.0),以全匹配形式出現的反碼，表示匹配的IP地址是一個主機IP地址。
access-list 102permit tcp 0.0.0.0 255.255.255.255 0.0.0.0255.255.255.255 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 192.168.1.2 host 192.168.2.2 等于access-list 102 permit ip 192.168.1.20.0.0.0 192.168.2.2 0.0.0.0;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 192.168.1.2 host192.168.2.1
ACL 101 的第二條語句： access-list 101 permit ip any any
現在用戶希望更改原有的ACL 101，希望在上述的兩條語句之間加入如下所示的ACL語句：
access-list 101 deny ip host192.168.3.1 host 192.168.4.1
但是當你完成加入后，這條被加入的語句將被放到ACL 101的***，如下圖所示，這樣，它的匹配順序也如圖所示，***加入的語句被放置到ACL列表的***，而第二條語句是允許任何流量，所以根本不會給第三條語句匹配的機會，那么第三條語句將永遠不生效，即便是您可能希望它于permit any any 之前生效，但事實上它不會，這類似于微機原理里面的堆棧原理，先進入。先調用。
所以在傳統IOS中管理員對ACL的修改變得很頭痛，通常，管理員會把現在的ACL復制到一個文本文件中進行增加或者刪除語句的操作，然后把原本在路由器上配置的ACL通過no access-list 101全部清除，再將文本文件中修改完成的ACL復制到路由器上，無法做到逐條修改ACL語句的效果。
使用ACL的增強編輯功能來增加與刪除ACL條目
新的IOS將打破傳統IOS對ACL條目修改的限制，如下圖所示，它為每條ACL語句增加了序列號，比如***條ACL語句的序列號是10，第二條ACL語句的序列號是20，以10作為輸寫***條ACL的基數數字序列號，然后，輸寫一條新的ACL語句就遞增10，所以此時如果需要在序列號為10和20之間增加一條ACL語句，那么，只需要增加一條屬于10-20之間的序列號，新增的ACL語句就會存在于10和20之間。
比如，現在，在10和20之間增加一條序列號是15的ACL語句，具體配置如下所示，在，在配置語句中的15是指示即將插入的ACL語句的序列號， 完成配置后，可以在路由器上使用show ip access-lists來查看各條ACL的語句如下圖10.16所示，可看出在序列號10和20之間出現了一條序例號是15的ACL語句，這就突破了傳統IOS對ACL編輯的困難，它增強了對ACL的編輯能力。
在兩條ACL語句之間插入一條序列號是15的配置：
R1(config)#ip access-list extended 101
R1(config-ext-nacl)#15 deny ip host 192.168.3.1 host192.168.4.1
#FormatImgID_5#
IOS 的版本如此眾多，在使用時，怎么知道，哪些IOS版本支持ACL的增強編輯功能，哪些IOS版本不支持ACL的增強編輯功能?很簡單，用戶不需要去記IOS的版本號，因為這確實是一件很難記住的事情，可以直接通過show ip access-lists來查看ACL列表，如果在顯示結果中，每條ACL的語句前都有一個序列號，那么該設備就支持ACL的增強編輯功能，反之則不能。
提問：為什么IOS系統自動為ACL語句插入序列號時會以10作為基數(***條ACL語句的序列號);并以10作為遞增數來插入隨后的ACL序列號 ?
事實上，這也是為了編輯ACL的方便，為***條ACL語句產生時就將序列號基數設置為10，是為了給原始的***條ACL語句之前再插入ACL預留了空間，至少用戶還可以插入1-9條ACL語句，后繼的ACL以10作為遞增數也是同理，當然，用戶可以根據自已的需求改變***條ACL自動插入時的基數和后繼ACL產生的遞增數，但是本人建議保持默認的配置。
