CCNA And CCENT Lab And Tutorial: Extended Access Lists
Comments or questions? Email me at ccie12933@gmail.com, tweet me @ccie12933, or message me on Facebook!
In our standard ACL tutorial and lab, it became apparent that standard ACLs have one huge drawback — they only match on the source IP address of packets, which can make them unsuitable for a WAN such as the one illustrated here. If we try to block traffic from 3.3.3.3 /24 that is destined for 11.11.11.0 /24 on R1, a standard ACL would have the effect of blocking all traffic from 3.3.3.0 /24.
For this and many other real-world situations, we’ll need an extended ACL. Extended ACLs consider both the source and destination IP address of a packet. Even if you don’t care about the source and just want to match on destination, you’ll have to put any in for the source.
I’ve bolded the extended ACL ranges for you here. Know these just as well as you know the standard ACL ranges.
R1(config)#access-list ? <1-99> IP standard access list <100-199> IP extended access list <1000-1099> IPX SAP access list <1100-1199> Extended 48-bit MAC address access list <1200-1299> IPX summary address access list <1300-1999> IP standard access list (expanded range) <200-299> Protocol type-code access list <2000-2699> IP extended access list (expanded range) <300-399> DECnet access list <600-699> Appletalk access list <700-799> 48-bit MAC address access list <800-899> IPX standard access list <900-999> IPX extended access list dynamic-extended Extend the dynamic ACL absolute timer rate-limit Simple rate-limit specific access list
Let’s write an extended ACL that will meet the requirements previously stated.
R1(config)#access-list 111 ? deny Specify packets to reject dynamic Specify a DYNAMIC list of PERMITs or DENYs permit Specify packets to forward remark Access list entry comment
As a fortune cookie once told me, when it comes to denial, we have many choices. That’s especially true of extended ACLs, as IOS Help is about to tell us.
R1(config)#access-list 111 deny ? <0-255> An IP protocol number ahp Authentication Header Protocol eigrp Cisco's EIGRP routing protocol esp Encapsulation Security Payload gre Cisco's GRE tunneling icmp Internet Control Message Protocol igmp Internet Gateway Message Protocol ip Any Internet Protocol ipinip IP in IP tunneling nos KA9Q NOS compatible IP over IP tunneling object-group Service object group ospf OSPF routing protocol pcp Payload Compression Protocol pim Protocol Independent Multicast tcp Transmission Control Protocol udp User Datagram Protocol
We’re blocking IP traffic, so we’ll go with ip. Next up – the source address and mask.
R1(config)#access-list 111 deny ip ? A.B.C.D Source address any Any source host host A single source host object-group Source network object group R1(config)#access-list 111 deny ip 3.3.3.0 ? A.B.C.D Source wildcard bits R1(config)#access-list 111 deny ip 3.3.3.0 0.0.0.255
Now for the destination information.
R1(config)#access-list 111 deny ip 3.3.3.0 0.0.0.255 ? A.B.C.D Destination address any Any destination host host A single destination host object-group Destination network object group R1(config)#access-list 111 deny ip 3.3.3.0 0.0.0.255 11.11.11.0 ? A.B.C.D Destination wildcard bits R1(config)#access-list 111 deny ip 3.3.3.0 0.0.0.255 11.11.11.0 0.0.0.255
Let’s have a look at the remaining options.
R1(config)#access-list 111 deny ip 3.3.3.0 0.0.0.255 11.11.11.0 0.0.0.255 ? dscp Match packets with given dscp value fragments Check non-initial fragments log Log matches against this entry log-input Log matches against this entry, including input interface option Match packets with given IP Options value precedence Match packets with given precedence value time-range Specify a time-range tos Match packets with given TOS value <cr>
We’ll put some of those options to use later, but for now, we’re good. This is the first time we’ve seen <cr> in this lab, because extended ACLs require you to enter information for both the source and destination IP addresses Our one and only ACL line to date:
R1(config)#access-list 111 deny ip 3.3.3.0 0.0.0.255 11.11.11.0 0.0.0.255
By the way, what is the net effect of this ACL?
R1#show ip access-list Extended IP access list 111 10 deny ip 3.3.3.0 0.0.0.255 11.11.11.0 0.0.0.255
The first line denies the traffic we wanted to deny. The implicit deny denies everything else. If traffic is not expressly permitted, it’s implicitly denied. Right now, ACL 111 denies everything! Note that show ip access-list does not remind you of the implicit deny.
To negate the implicit deny in an extended ACL, add a permit any any line. (“any” is needed twice here – once for the source, once for the destination.)
R1(config)#access-list 111 permit ip any any
Verify with show ip access-list and we’re good. (More on that “10” and “20” very soon. One thing at a time!)
R1#show ip access-list Extended IP access list 111 10 deny ip 3.3.3.0 0.0.0.255 11.11.11.0 0.0.0.255 20 permit ip any any
Regardless of type, ACLs are applied to Cisco router interfaces with the ip access-group command.
R1(config)#int serial 0/1/0 R1(config-if)#ip access-group ? <1-199> IP access list (standard or extended) <1300-2699> IP expanded access list (standard or extended) WORD Access-list name R1(config-if)#ip access-group 111 ? in inbound packets out outbound packets
You must specify whether inbound or outbound packets should be checked by this particular ACL. The command is incomplete until you do so. Verify with show ip access-list, show access-list, and / or show ip interface (a handy and often overlooked command) and you’re all set to test. We haven’t seen show ip interface in action yet, so let’s do so now.
R1#show ip interface serial 0/1/0 Serial0/1/0 is up, line protocol is up Internet address is 172.12.123.1/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is 101 (output truncated for clarity)
We have our ACL in place, and I trust that it’s fine, but there’s something we really need to do….
Verify it. Trust, but verify! We’ll test our ACL with extended ping in the next tutorial, which I’ll post on July 26, 2018. In the meantime, check out these other CCNA and CCENT tutorials, along with my YouTube CCNA / CCNP / CCENT channel!
CCNA Tutorial: Access List Fundamentals