- [Instructor] Access Control Lists are one
of the most commonly used features in iOS,
we can use those for traffic filtering
for route redistribution, packet identification
for policy based routing, and much more.
So it's important to be able to interpret
and troubleshoot those.
That's what we're going to examine here.
Specifically, look at troubleshooting
IP version 4 access control lists
used for traffic filtering.
A few key things you want to remember about ACLs
when troubleshooting are first ACLs are processed
in a top down manner, they are made up
of multiple access control entries, or ACEs
and the order of these ACEs does matter.
Entries are processed in order from top to bottom.
Also, remember that when a packet arrives,
the first ACE that matches the packet values
which are being examined, will be applied,
and the processing will stop.
So if a packet matches multiple entries in the ACL,
the only action that's going to be taken
is whatever the first match in that access control list is,
once a matching entry is found ACL packet processing stops.
So if you're seeing an action that you don't expect,
or maybe you're not getting the results you expect,
that's the first place you would probably look
make sure the order of your ACEs is correct.
And remember that there is an implicit deny any command
at the end of every ACL.
And that is to say, if a packet arrives,
that is not explicitly allowed by an entry in the ACL,
that packet will be dropped.
Let's connect to a live interface
and take a look at some examples.
If I say show access-lists,
and I'm going to call up access list number one
on my router, and this is going to bring up
my standard IP access list that I've created.
Now standard access lists only examine
the source IP address for packets.
So they are the less powerful variant.
Here you can see a very simple ACL that I created,
we have just a few deny statements,
we have two deny statements online 10, and 30.
And we have to permit statements sequence 20, and 40.
So let's go down this list and take a look
at exactly what's happening here.
And for troubleshooting, it's very important
to be able to read and correctly interpret
what's happening within our ACL.
Remember, we said ACLs are processed from the top down.
So we want the more specific entries at the top.
And we want the less specific entries at the bottom.
With newer iOS versions, if you create an ACL entry
that is more specific than one you already have listed,
you are going to get an error message.
So these days, that's not as big a concern as it used to be.
But in older iOS versions,
it would allow you to do that without any warning.
Now here obviously, at the top,
I have my most specific entry,
I'm denying the IP address 192.168.1.50.
Now right underneath that, we have a permit statement.
And you'll notice that this permit statement
allows the entire range of addresses of 192.168.1.0,
all the way through .63.
So even though that 192.68.1.50 does fall
within the range that is permitted in sequence number 20,
it's going to be denied because the more specific entry
is found above that.
So again, remember, the first matching
ACE is going to be processed and processing will stop.
So this would effectively deny the host 192.168.1.50
even though there is a following entry,
which would allow that.
We have something similar happening in the next two lines,
we have a deny statement here
blocking IP addresses of .64 through .127.
And underneath that we have our most general statement
of all allowing everything within the 192.168.1.0/24 subnet.
And so of course, at the end of that
we will have an implicit deny at the end
as we do with all of our ACLs.
So anything outside of these networks will be dropped.
Let's take a look at an extended access control list.
So let's look at I'm going to say show access-lists
and I'm going to say access list 100.
And extended access lists are a little more tricky
to interpret and troubleshoot
because they do have a more granular control.
And so they have more options inside.
They can filter based on source
and destination IP addresses,
source and destination ports, protocols and more.
And so here in this example,
we see again the more detailed entries at the top.
Our first entry sequence number 10,
that denies the IP address 192.168.1.50
from reaching our host, which may be a server at 10.1.1.50.
And you'll notice at the end of that, we have the eq ftp.
So this is specifically blocking Port 21, FTP access.
Underneath that we have a more general entry.
This is permitting everything
in the address range 192.168.10 through 63.
So that sequence number 20 ACE,
is allowing access to the same host over telnet,
you see that we've identified the telnet protocol
at the end of that.
And so again, we will see the most general of all
at the bottom sequence number 30,
allowing the entire 192.168.1.0/24 subnet
using any protocol.
So again, very important to be able to interpret
what your ACL is doing when you're troubleshooting.
If you're not seeing what you would expect,
it's very likely that you have something misconfigured.
One more place to examine when troubleshooting
is the direction in which the ACL is applied.
So in order to filter packets,
we have to apply an ACL to an interface.
So I'm going to say, show IP interface, gig 0/0.
And we're going to get a really long output.
The relevant section that I'll point out
is here near the top, we see that our outgoing
and inbound access lists are identified here,
we have access list number one,
our standard access list applied
in the outgoing direction of this interface.
And our extended ACL number 100
is applied in the inbound direction.
So not only should you examine the ACL itself,
to make sure that's configured correctly,
but you also want to make sure
that it's applied to the correct interface,
and that it's also applied in the correct direction
either inbound or outbound.
One more consideration to look at,
let me break out of this output is a time-based ACL.
By default, when you apply an access control list,
it is immediately active,
and it will remain active until you remove that.
However, we do have something called time-based ACLs
that allow you to choose certain hours
during which the ACL would be enforced.
If you're not expecting this,
or if you've set your hours incorrectly,
then you're not going to get the correct results
or correct filtering that you're looking for.
And also, it's very important that
when we're using time-based ACLs,
that you use NTP to set your device clocks correctly,
because you want your clock to be synchronized,
let's say show IP access-lists,
and I'm going to say access list 101.
And here, we essentially see the same access control list
as list number 100.
But we also see appended at the end of that
we see a time range.
See the command time-range.
And the name of the time range
that I have configured is AFTER-WORK.
So if you see that you have a specific time
based ACL applied one way that we can see exactly
what the time ranges are on those,
we can do another show command.
So we can say, show time-range,
and then we'll call out the name of that,
which is AFTER-WORK.
And here we can see that we have a periodic ACL
and that means this is not working around the clock,
we have specific times that this is working,
you can see that this is enforced during weekdays,
and that is from 6p.m. to 6a.m..
Now one interesting thing to note
is that you can't cross over a day,
when you're configuring periodic time-based ACLs
you have to go, you notice I've gone from midnight to 6a.m..
And then I've also gone from 6p.m. right up until 11:59p.m..
So you couldn't go from 1800 all the way to six,
because it won't let you cross over into the next day.
So that may be a little bit confusing.
If you're working with time-based ACLs
that's certainly a place to be aware of.
And we also see that on the weekends
it is blocked through the entire weekend
from midnight up to 11:59p.m..
And you'll notice that currently, this is set to active.
Now if you were within the time range
that is being blocked here this is going to say active.
In our case, I've actually manually set the router time
to be within this range so that you can see
that this is in the active state.
If we were outside of this range,
then this would say inactive.
So, again, when you're troubleshooting a time-based ACL,
that's a good place to look to,
if you're expecting it to be active,
but you're seeing inactive there,
then that indicates either you've configured the times wrong
when you set up your ACL,
or that you've configured your router clock wrong,
maybe the NTP isn't working correctly.
So just a few more places to double check
when you're using time-based ACLs.
So that's a look at troubleshooting standard, extended
and time-based IP version 4 ACLs.