- [Instructor] Access control lists, or ACLs,
are utilized to identify IP addresses
and ports for subnets or hosts.
So I can match subnet 100.64/24 going anywhere,
or I can match host 100.64.0.1
accessing anything on port 80,
or I can match 100.64.0.1 source from TCP port 5231
going to host 100.65.65.1 on TCP port 443.
I can get quite granular if I need to.
While they can be used for filtering traffic on interfaces,
they have many more uses.
They can be used for matching traffic for QoS,
or used for route filtering in dynamic protocols.
When using ACLs for interface filtering,
directionality is very important.
An ACL is applied to an interface
using either the keyword in or out.
The way I remember which is which
is to pretend I'm the router
with my hands be the interfaces.
For example, if my right hand
is the interface I want to do the filtering on,
I'll tell myself if I catch it in my hand, the interface,
then use the in keyword,
if the traffic is leaving through my right hand
away from me, then I use the out keyword.
ACLs are lists of one or more entries
processed from top to bottom.
Each entry has one of two actions, either permit or deny.
Permit means allow and deny means, well, deny.
ACLs come in several types, standard numbered,
extended numbered and named ACLs.
A numbered ACL is one that is referenced solely by a number,
whereas a named ACL
is one that is represented by an ASCII name.
I generally prefer named wherever possible
as their purpose is more apparent based on their name.
I'm going to start with the simplest and oldest form of ACL,
the standard numbered ACL.
When I hear standard,
I remember that only the source address is matched.
And when I hear numbered,
I remember that it is represented as a number
from one to 99, or 1300 to 1999.
Take this diagram, for example,
I want to block 100.64.0.0/24, allow host 100.64.0.2
and allow all other 100.64.0.0/16 devices
as they enter gig 01 of router 2.
That means I'll create the list as follows.
Allow 100.64.0.2 first, then block the slash 24 subnet
and last allow all other 100.64 subnets.
Keep in mind that ACLs are processed from the top down
and as soon as they match either a permit or deny,
processing stops.
So order of operation is extremely important.
Since these subnets will be coming into the interface,
I would add the ACL in direction on gig 01.
As host A sends a packet,
it will start processing in the filter ACL,
and as it hits line one,
it will be permitted and thus allowed.
Host B now sends and is denied by line two of the ACL,
last, hosts C sends
and is allowed via line three of the ACL.
Now what happens when host D sends a packet?
Since its IP address doesn't get matched
by any of the statements, it's dropped.
By default, at the end of all Cisco ACLs,
there's an implicit deny all.
I can't state how important this fact is.
If I want to deny a single user via an ACL,
and I only put that one deny statement in,
I'm effectively blocking all traffic
due to the implicit deny any at the end.
This can be changed
by adding an allow any at the end if desired.
Standard numbered ACLs format is pretty simple.
It starts with access list, the number to be used,
permit or deny, then the matching source subnet info.
I'll demonstrate adding the first rule
but I like to begin my ACLs with a description,
config t,
access-list 1 remark user subsfilter,
the remark keyword allows a text descriptor
which can be invaluable.
Matching a single host is done as,
access-list 1 permit host 100.64.0.2.
On newer systems, the host keyword can be omitted,
and in fact, if you add it while typing,
the command will simply remove it once entered.
ACLs have enormous power
and are used regularly throughout IOS,
so I'd expect to see several questions
about them on the test.