Access-List 101 - Part 1, the Standard ACL

Cisco IOS access-lists are well understood, well documented and well, just plain necessary. We use access-lists to secure devices and services as well as to manage routing protocols and much more in routers and switches.

Access-lists come in a number of flavours so lets mentioned some of them here:

Standard access-lists
Extended access-lists
VLAN access-lists
Context-Based access-lists
NBAR enhanced access-lists (not really an access-list but can be used within ACL's to augment the matching process)
Zone Based access-lists

In this techguide we're just concentrating on the standard ACL.

So how do we say it? Ay'see'el? or ACKLE? It doesn't matter how you pronounce the name but the majority of the discussions I attend use the phonetic Ay'See'El (like you were reciting the letters individually A, C, L) way. Hey, what do I know, I'm a Brit and we pronounce route like Route as in Route66 (see Chuck Berry) So lets move onto something more interesting.

In this first encounter we'll go through standard ACL's. Access-lists are lists of lines which are read by the parser one by one from top to bottom. The lines are 'sorted' using line numbers which are incremented by default in 10's (e.g. the first permit/deny access-list statement will be prefaced with a line number of 10, the next line by 20, the next by 30 and so on) although this can be overridden. By function a standard ACL can only describe the source and it has no idea about protocol.

This is the format as written out:

access-list {1-99 | 1300-1999} {permit | deny} source-address [wildcard mask]

Here is a screenshot using the Cisco IOS context sensitive help to show the format of the access-list. We see here that the keyword to begin defining the access-list is simply 'access-list' in configuration mode. The '?' after 'access-list' simply engages the help output to be displayed.



So we see looking down the list that standard ACL's can be defined using values between 1-99 and 1300-1999. We'll choose 1, it doesn't matter so long as it fits within those ranges described earlier. Using the help again we see the next choice is the action to take. Here we see we can 'deny', 'permit' or actually simply remark or comment on the access-list. Lets remark on the access-list as a first step to describe it's function "Test ACL for demo" It should perhaps be stated that the default action for any traffic which is NOT matched int eh access-list receives a 'deny' by default. You will not see this default action in any of your configuration but it is there.





Now we'll add to this ACL by permitting access from remote hosts on network 1.2.3.0/24.

Firstly lets see the options available to us to do this. OK so we use the permit keyword, thats required since we want to permit access. The ? reveals a few options now, hostname, any and host. What are we saying here? The easiest one to take on first is 'any'. By stating any we're saying basically permit (allow) any source.



Using the keyword 'host' is very powerful and allows us to permit or deny access from a single IP address. The IOS parser simply reads the 'host' keyword and replaces it with a /32 mask in runtime. Remember an all 1's subnet mask (255.255.255.255) denotes a host.

So what if we want to permit all hosts on network 1.2.3.0/24? Well of course a /24 netmask is written as 255.255.255.0 (first 24 bits are 1's). IOS however expects the netmask to be written as a wildcard mask. A wildcard mask is the inverse of a network mask where a '1' is written as a '0'. The 255.255.255.0 therefore becomes 0.0.0.255. So lets add this new line in:



Again we see we can add to this statement by using the 'log' keyword. Using 'log' allows us to see the number of matches this access-list receives.

So we now have an access-list in the configuration, we can see this here:



The access-list is useless however without applying it to something. The access-list is powerful because it can be added it interfaces, protocols, services and probably more. We'll test out access list by applying it to our VTY service which is used to access the router across the network using protocols like telnet and SSH.

Using this topology we have created a loopback interface Lo2 on R2 with IP address 1.2.3.4/24.



Lets assign the access-list 1 to the running configuration for the VTY interfaces on R1.



Note that the access-list command changes to the 'access-group' command when it is being applied to the interface. Notice also that we are now adding a 'direction' of 'in' for the access-list. This means we are asking the router to look at packet arriving 'into' the router. The other option would be 'out' or 'outbound'. OK so we'll drop out of configuration mode back into privileged EXEC mode and run a show command to describe the status of the access-list. Notice it is given the default line of '10'. When access-lists are created each new line is incremented by a value of '10'. If we were to add a new permit or deny statement to out access-list it would start with a '20'. Remember once more that there is a default 'deny' at the end of any access-list which will be matched if no other lines within the access-list are matched.



So lets telnet to the VTY interface running on IP address 10.1.12.1 (refer to diagram) and see what happens.

First we'll try to connect from the directly connected interface on R2 (from 10.1.12.2)



Ah, we're denied access. If you recall we permitted access from nodes in network 1.2.3.0/24 and remember too that anything not specifically matched in the ACL will hit the implicit 'deny' statement at the end...well we're denied because our source IP address is 10.1.12.2. So lets override the default IP address used for the telnet on R2 and make it use the loopback Lo2 interface...



OK, well that worked! So we should now see a hit in our access-list...



We can see the matches at the end of the access-list there - 2 ;-)

Thanks for reading, see you next time with Extended Access-lists