- [Narrator] Now that we've looked at several
configuration examples for ACLs,
let's wrap up this topic by discussing
some design considerations for those.
First, let's review some of what we've
already discussed earlier in this module.
Access Control Lists as general
definition are lists of rules that perform
packet filtering, which control the
movement of packets through our network.
The rules themselves are called
Access Control Entries or ACEs for short.
These rules are sequential lists
which are processed from the top down.
When a packet arrives and matches an ACE
in an ACL processing of the ACL stops right there.
That means that we want to place our
more specific ACEs near the top of our
Access Control List and the more
general rules at the bottom.
If we have more general rules near the top,
unwanted traffic might slip through,
because it matches a more general catch all ACE.
At the end of every ACL
there is an implicit deny any statement.
This means that if we aren't
specifically allowing traffic in the ACL,
it will be dropped as an implicit action.
Certainly something to be aware of when
you're troubleshooting and designing ACLs.
We also looked at the difference
in standard and extended ACLs.
Standard ACLs are less extensive
and the less flexible variant,
because they match traffic based on
the entire protocol suite.
That is to say that they
cannot distinguish between
specific traffic protocol types such as HTTP,
HTTPS or Telnet as an example.
They also match traffic based
on the source IP address,
so the best practice is to place standard ACLs
as close to the destination as possible.
Extended ACLs or more
powerful and flexible and they
have the ability to filter traffic more specifically.
They do have the ability to differentiate
between different traffic protocols
such as the example we previously
examined for allowing traffic except for
Telnet traffic, overwhelmed known port TCP 23.
We looked at that in a previous video.
Also extended ACLs are able to match
traffic based on source and destination addressing.
For this reason, the best practice recommendation is
to place extended ACLs as close to the
source as possible and that's so that
unwanted traffic is stopped early on,
rather than allowing the traffic to
traverse our network and the consumer bandwidth.
We also looked at creating
both numbered and named ACLs.
Both standard and extended ACLs
can be created as a named ACL or a numbered ACL.
The advantages of creating a named ACL
include the fact that you can give the ACL
a very easy to identify and intuitive name
that helps when you're looking
over your running configuration later
and trying to determine exactly
what the ACL is designed to do.
Also named ACLs allow for editing
by providing a sequence number.
This sequence number allows you to place
new ACEs anywhere in the existing ACL
that you need to,
whereas with numbered ACLs,
if you added a new ACE that would simply
be upended at the very bottom of the ACL,
which might not be ideal in many circumstances.
You also want to be mindful when applying
an ACL to an interface that you choose
the right direction.
Remember that we can choose to apply
that either inbound or outbound depending
on the traffic flow direction.
If you're trying to protect device resources
an inbound access list applies the
filter conditions before the
routing table lookup happens.
While an outbound access list will
apply the filter after the routing table lookup happens.
A few final hints for creating your Access Control List,
you want to create the entire list
before you apply it to an interface.
If you apply a nonexistent ACL
to an interface before you can figure ACEs,
remember that implicit deny any statement
is at the end of every ACL,
so you might experience immediate network
problems if you do it in that order.
If you want to allow all other packets
that are not denied by your ACL,
you can use the permit any command
to bypass the implicit deny command that's found at the end.
Be sure you don't place this at the top
of your ACL or all traffic is going to
be allowed through without any filtering.
All of your traffic is going to match
that top catch all entry and none of your
denies statements are going to work.
You can use the remark keyword
to make comments with your ACEs.
This is another helpful way to identify
specific purposes of the rules
that you're putting in place.
If you want to deny a specific host or network
and also if you want to have a knowledge
of anyone who's trying to gain access
from this restricted source,
you could include the log key word
with your deny statement
and that's going to create a condition
where packets denied from your specific
source will be logged for your review.
So that's a look at some of the main
considerations and best practices when
creating and applying an Access Control List.