- [Instructor] Named ACLs are my go-to,
as their intended purpose is easy to understand
based on how I name them.
If it's for client filtering, I'll name it client filtering.
If it's for OSPF filtering inbound,
I'll call it OSPF filter inbound.
While the logic and capabilities are the same as standard
and extended ACL,
configuration is done a bit differently.
The quickest way to understand how they work
is through a demonstration.
I'll start with a standard named ACL,
fig T, IP,
access-list, standard.
And now I'm going to name it filter-dmz-in.
With named ACLs, all entries are done as sub commands,
not as global commands like standard and extended ACLs.
Now I'll add a couple of entries.
Permit host, 100.65.0.1
and permit 100.66.0.0 0.0.0.255.
Taking a look at how it's stored in the config,
makes it a little clearer.
Do show run, pipe begin,
standard filter-dmz.
I can see the ACL name, then the following sub commands.
But, standard ACLs are boring,
so let me do a demo on an extended.
IP, access-list, extended phone-filter-in.
Now, permit, TCP, any to any,
range 5060 to 5061.
And permit, UDP, any to any range 5060 to 5061.
Last, I'll add permit, UDP, any in the range of
16384 to 32767 to anyone.
Let's have a look at it.
Do, show, run, begin, phone-filter.
Again, the logic isn't unlike numbered ACLs.
Where it really starts to differ, is the ability
to add and remove individual lines in an ACL.
If I want to remove the middle line,
I'll issue a no statement.
No permit UDP any to any, range 5060 to 5061.
Now, I'll take a look at it.
It's pretty easily to see that it makes removal of rules
dead simple.
Cisco originally forced a user to completely remove
and re-add ACLs to edit individual lines.
That was a long time ago.
Now ACLs can be edited due to sequence numbers.
If the ACL configures with IP access-list
instead of just access-list,
then it's in the new format that's editable.
When I issue a show, run, pipe, begin access-list,
I see no evidence of sequence numbers.
If however, I issue a show access-lists,
IOS will list the ACL, followed by their individual lines.
Each line shows the sequence number
starting at 10 by default and incrementing by 10.
I can create an ACL quickly.
IP, access-list, extended 118,
permit ICMP, any to any,
permit UDP, any to any,
and why not permit, TCP, any to any.
Now I'll do a do, show, access-list.
I can see the sequence numbers 10, 20, and 30.
If I'd like to remove sequence 20,
I can do so with no 20.
Now, I'll review it.
Now, if I'd like to add an entry at position 15,
I do so with 15, permit IP host 192.168.1.1,
to host 192.168.2.1
and review it.
Something else of note is that as new entries are added,
IOS will continue to just append into the end.
Permit, IP, any going to host, 192.168.2.2.
And then verification.
There are a few best practices
when it comes to implementing ACLs.
Not all are practical or possible in all situations.
But, at least it's a place to start.
When filtering, place an ACL as close to the source
of traffic being dropped,
as this can take packets off the network sooner.
Keep in mind the order of operation of ACLs.
It's usually preferable to put more specific routes
first in the list.
Something else that's a good rule of thumb,
is to remove a filtering ACL from an interface
before making modifications.
If I am modifying several lines in an ACL,
and I remove one of the lines that is granting me access
to the device,
I could lose access and the router will be stuck
until I gain local access again.
I could also cause unnecessary network disruptions
for customer traffic.
When I make modifications to ACLs,
I write everything in a text document,
then copy and paste.
This really cuts down on human error.
I will begin with removing the ACL from the interface,
make required ACL changes, then apply the ACL changes
all in one smooth motion.
Named ACLs while not necessary, can add a lot of clarity
when matching packets in IOS.