Introduction to Access Lists
An access list is essentially a list of conditions that categorize packets. They can be really helpful when you need to exercise control over network traffic. An access list would be your tool of choice for decision-making in these situations.
One of the most common and easiest to understand uses of access lists is filtering unwanted packets when implementing security policies. For example, you can set them up to make very specific decisions about regulating traffic patterns so that they’ll only allow certain hosts to access WWW resources on the Internet while restricting others. With the right combination of access lists, network managers arm themselves with the power to enforce nearly any security policy they can invent.
Access lists can even be used in other situations that don’t necessarily involve blocking
packets too. For example, you can use them to control which networks will or won’t be
advertised by dynamic routing protocols. How you configure the access list is the same. The
difference here is simply how you apply it—to a routing protocol instead of an interface.
When you apply an access list in this way, it’s called a distribute list, and it doesn’t stop
routing advertisements, it just controls their content. You can also use access lists to cate-
gorize packets for queuing or QoS-type services, and for controlling which types of traffic
can activate a pricey ISDN link.
Creating access lists is really a lot like programming a series of if-then statements—if a
given condition is met, then a given action is taken. If the specific condition isn’t met, nothing
happens, and the next statement is evaluated. Access-list statements are basically packet filters that packets are compared against, categorized by, and acted upon accordingly. Once the list are built, they can be applied to either inbound or outbound traffic on any interface.Applying
an access list causes the router to analyze every packet crossing that interface in the specified direction and take the appropriate action.
There are a few important rules that a packet follows when it’s being compared with an
access list:
It’s always compared with each line of the access list in sequential order—i.e., it’ll always
start with the first line of the access list, then go to line 2, then line 3, and so on.
It’s compared with lines of the access list only until a match is made. Once the packet
matches the condition on a line of the access list, the packet is acted upon, and no further
comparisons take place.
There is an implicit “deny” at the end of each access list—this means that if a packet doesn’t
match the condition on any of the lines in the access list, the packet will be discarded.
Each of these rules has some powerful implications when filtering IP packets with access lists.
So keep in mind that creating effective access lists truly takes some practice.
There are two main types of access lists:Standard access lists These use only the source IP address in an IP packet as the condition test.
All decisions are made based on source IP address. This means that standard access lists basically permit or deny an entire suite of protocols. They don’t distinguish between any of the many types of IP traffic such as WWW, Telnet, UDP, etc.Extended access lists
There are a few important rules that a packet follows when it’s being compared with an
access list:
It’s always compared with each line of the access list in sequential order—i.e., it’ll always
start with the first line of the access list, then go to line 2, then line 3, and so on.
It’s compared with lines of the access list only until a match is made. Once the packet
matches the condition on a line of the access list, the packet is acted upon, and no further
comparisons take place.
There is an implicit “deny” at the end of each access list—this means that if a packet doesn’t
match the condition on any of the lines in the access list, the packet will be discarded.
Each of these rules has some powerful implications when filtering IP packets with access lists.
So keep in mind that creating effective access lists truly takes some practice.
There are two main types of access lists:Standard access lists These use only the source IP address in an IP packet as the condition test.
All decisions are made based on source IP address. This means that standard access lists basically permit or deny an entire suite of protocols. They don’t distinguish between any of the many types of IP traffic such as WWW, Telnet, UDP, etc.Extended access lists
Extended access lists can evaluate many of the other fields in the
layer 3 and layer 4 headers of an IP packet. They can evaluate source and destination IP
addresses, the protocol field in the Network layer header, and port number at the Transport
layer header. This gives extended access lists the ability to make much more granular deci-
sions when controlling traffic.
Named access lists Hey, wait a minute—I said two types of access lists but listed three! Well,
technically there really are only two since named access lists are either standard or extended and
not actually a new type. I’m just distinguishing them because they’re created and referred to differently than standard and extended access lists. But they’re functionally the same.
We will look at these types of access lists in more depth later in the chapter.
Once you create an access list, it’s not really going to do anything until you apply it. Yes, they’re there on the router, but they’re inactive until you tell that router what to do with them. To use an access list as a packet filter, you need to apply it to an interface on the router where you want the traffic filtered. And you’ve got to specify which direction of traffic you want the access list applied to. There’s a good reason for this—you may want different controls in place for traffic leaving your enterprise destined for the Internet than you’d want for traffic coming into your enterprise from the Internet. So, by specifying the direction of traffic, you can—and frequently, you’ll need to—use different access lists for inbound and outbound traffic on a single interface:
Inbound access lists When an access list is applied to inbound packets on an interface, those packets are processed through the access list before being routed to the outbound interface. Any packets that are denied won’t be routed because they’re discarded before the routing process is invoked.
Outbound access lists When an access list is applied to outbound packets on an interface,
those packets are routed to the outbound interface and then processed through the access list before being queued.
There are some general access-list guidelines that should be followed when creating and
implementing access lists on a router:
You can assign only one access list per interface per protocol per direction. This means that
when creating IP access lists, you can only have one inbound access list and one outbound
access list per interface.
When you consider the implications of the implicit deny at the end of any access list, it makes sense that you can’t have multiple access lists applied on the same interface in the same direction for the same protocol. That’s because any packets that don’t match some condition in the first access list would be denied, and there wouldn’t be any packets left over to compare against a second access list.
Organize your access lists so that the more specific tests are at the top of the access list.
Any time a new entry is added to the access list, it will be placed at the bottom of the list.
Using a text-editor for access lists is highly suggested.
You cannot remove one line from an access list. If you try to do this, you will remove the
entire list. It is best to copy the access list to a text editor before trying to edit the list. The
only exception is when using named access lists.
You can delete a single line from a named access list. I’ll show this to you shortly.
Unless your access list ends with a permit any command, all packets will be discarded if
they do not meet any of the list’s tests. Every list should have at least one permit statement,
or it will deny all traffic.Create access lists and then apply them to an interface. Any access list applied to an inter-
face without an access list present will not filter traffic.
Access lists are designed to filter traffic going through the router. They will not filter traffic
that has originated from the router.
Place IP standard access lists as close to the destination as possible. This is the reason we
don’t really want to use standard access lists in our networks. You cannot put a standard
access list close to the source host or network because you can only filter based on source
address and nothing would be forwarded.
Place IP extended access lists as close to the source as possible. Since extended access lists
can filter on very specific addresses and protocols, you don’t want your traffic to traverse
the entire network and then be denied. By placing this list as close to the source address as
possible, you can filter traffic before it uses up your precious bandwidth.Standard Access Lists
Standard IP access lists filter network traffic by examining the source IP address in a packet.
You create a standard IP access list by using the access-list numbers 1–99 or 1300–1999
(expanded range). Access-list types are generally differentiated using a number. Based on the number used when the access list is created, the router knows which type of syntax to expect as the list is entered. By using numbers 1–99 or 1300–1999, you’re telling the router that you want to create a standard IP access list, so the router will expect syntax specifying only the source IP address in the test lines.
Below is an example of the many access-list number ranges that you can use to filter traffic on your network (the protocols for which you can specify access lists depend on your IOS version):
layer 3 and layer 4 headers of an IP packet. They can evaluate source and destination IP
addresses, the protocol field in the Network layer header, and port number at the Transport
layer header. This gives extended access lists the ability to make much more granular deci-
sions when controlling traffic.
Named access lists Hey, wait a minute—I said two types of access lists but listed three! Well,
technically there really are only two since named access lists are either standard or extended and
not actually a new type. I’m just distinguishing them because they’re created and referred to differently than standard and extended access lists. But they’re functionally the same.
We will look at these types of access lists in more depth later in the chapter.
Once you create an access list, it’s not really going to do anything until you apply it. Yes, they’re there on the router, but they’re inactive until you tell that router what to do with them. To use an access list as a packet filter, you need to apply it to an interface on the router where you want the traffic filtered. And you’ve got to specify which direction of traffic you want the access list applied to. There’s a good reason for this—you may want different controls in place for traffic leaving your enterprise destined for the Internet than you’d want for traffic coming into your enterprise from the Internet. So, by specifying the direction of traffic, you can—and frequently, you’ll need to—use different access lists for inbound and outbound traffic on a single interface:
Inbound access lists When an access list is applied to inbound packets on an interface, those packets are processed through the access list before being routed to the outbound interface. Any packets that are denied won’t be routed because they’re discarded before the routing process is invoked.
Outbound access lists When an access list is applied to outbound packets on an interface,
those packets are routed to the outbound interface and then processed through the access list before being queued.
There are some general access-list guidelines that should be followed when creating and
implementing access lists on a router:
You can assign only one access list per interface per protocol per direction. This means that
when creating IP access lists, you can only have one inbound access list and one outbound
access list per interface.
When you consider the implications of the implicit deny at the end of any access list, it makes sense that you can’t have multiple access lists applied on the same interface in the same direction for the same protocol. That’s because any packets that don’t match some condition in the first access list would be denied, and there wouldn’t be any packets left over to compare against a second access list.
Organize your access lists so that the more specific tests are at the top of the access list.
Any time a new entry is added to the access list, it will be placed at the bottom of the list.
Using a text-editor for access lists is highly suggested.
You cannot remove one line from an access list. If you try to do this, you will remove the
entire list. It is best to copy the access list to a text editor before trying to edit the list. The
only exception is when using named access lists.
You can delete a single line from a named access list. I’ll show this to you shortly.
Unless your access list ends with a permit any command, all packets will be discarded if
they do not meet any of the list’s tests. Every list should have at least one permit statement,
or it will deny all traffic.Create access lists and then apply them to an interface. Any access list applied to an inter-
face without an access list present will not filter traffic.
Access lists are designed to filter traffic going through the router. They will not filter traffic
that has originated from the router.
Place IP standard access lists as close to the destination as possible. This is the reason we
don’t really want to use standard access lists in our networks. You cannot put a standard
access list close to the source host or network because you can only filter based on source
address and nothing would be forwarded.
Place IP extended access lists as close to the source as possible. Since extended access lists
can filter on very specific addresses and protocols, you don’t want your traffic to traverse
the entire network and then be denied. By placing this list as close to the source address as
possible, you can filter traffic before it uses up your precious bandwidth.Standard Access Lists
Standard IP access lists filter network traffic by examining the source IP address in a packet.
You create a standard IP access list by using the access-list numbers 1–99 or 1300–1999
(expanded range). Access-list types are generally differentiated using a number. Based on the number used when the access list is created, the router knows which type of syntax to expect as the list is entered. By using numbers 1–99 or 1300–1999, you’re telling the router that you want to create a standard IP access list, so the router will expect syntax specifying only the source IP address in the test lines.
Below is an example of the many access-list number ranges that you can use to filter traffic on your network (the protocols for which you can specify access lists depend on your IOS version):
Lab_A(config)#access-list ?
<1-99> IP standard access list
<100-199> IP extended access list
<1000-1099> IPX SAP access list
<1100-1199> Extended 48-bit MAC address access list
<1200-1299> IPX summary address access list
<1300-1999> IP standard access list (expanded range)
<200-299> Protocol type-code access list
<2000-2699> IP extended access list (expanded range)
<300-399> DECnet access list
<600-699> Appletalk access list
<700-799> 48-bit MAC address access list
<800-899> IPX standard access list
<900-999> IPX extended access list
As you can see, there’s a bunch of different types of access lists you can create.
But since we’re studying the CCNA objectives in this book, we’ll focus exclu-
sively on IP access lists.
Let’s take a look at the syntax used when creating a standard access list:
Lab_A(config)#access-list 10 ?
deny Specify packets to reject
permit Specify packets to forward
<1-99> IP standard access list
<100-199> IP extended access list
<1000-1099> IPX SAP access list
<1100-1199> Extended 48-bit MAC address access list
<1200-1299> IPX summary address access list
<1300-1999> IP standard access list (expanded range)
<200-299> Protocol type-code access list
<2000-2699> IP extended access list (expanded range)
<300-399> DECnet access list
<600-699> Appletalk access list
<700-799> 48-bit MAC address access list
<800-899> IPX standard access list
<900-999> IPX extended access list
As you can see, there’s a bunch of different types of access lists you can create.
But since we’re studying the CCNA objectives in this book, we’ll focus exclu-
sively on IP access lists.
Let’s take a look at the syntax used when creating a standard access list:
Lab_A(config)#access-list 10 ?
deny Specify packets to reject
permit Specify packets to forward
As I said, by using the access-list numbers between 1–99 or 1300–1999, you’re telling the
router that you want to create a standard IP access list.
After you choose the access-list number, you need to decide whether you’re creating a
permit or deny statement. For this example, you will create a deny statement:
Lab_A(config)#access-list 10 deny ?
Hostname or A.B.C.D Address to match
any Any source host
host A single host address
The next step requires a more detailed explanation. There are three options available. You
can use the any parameter to permit or deny any host or network; you can use an IP address to specify either a single host or a range of them; or you can use the host command to specify a specific host only. The any command is pretty obvious—any source address matches the statement, so every packet compared against this line will match. The host command is relatively
simple. Here’s an example using it:
Lab_A(config)#access-list 10 deny host 172.16.30.2
This tells the list to deny any packets from host 172.16.30.2. The default parameter is host. In
other words, if you type access-list 10 deny 172.16.30.2, the router assumes you mean
host 172.16.30.2.
But there’s another way to specify either a particular host or a range of hosts—you can use
wildcard masking. In fact, to specify any range of hosts, you have to use wildcard masking in
the access list.
What’s wildcard masking? You’ll learn all about it using a standard access list example, as
well as how to control access to a virtual terminal, in the following sections.
router that you want to create a standard IP access list.
After you choose the access-list number, you need to decide whether you’re creating a
permit or deny statement. For this example, you will create a deny statement:
Lab_A(config)#access-list 10 deny ?
Hostname or A.B.C.D Address to match
any Any source host
host A single host address
The next step requires a more detailed explanation. There are three options available. You
can use the any parameter to permit or deny any host or network; you can use an IP address to specify either a single host or a range of them; or you can use the host command to specify a specific host only. The any command is pretty obvious—any source address matches the statement, so every packet compared against this line will match. The host command is relatively
simple. Here’s an example using it:
Lab_A(config)#access-list 10 deny host 172.16.30.2
This tells the list to deny any packets from host 172.16.30.2. The default parameter is host. In
other words, if you type access-list 10 deny 172.16.30.2, the router assumes you mean
host 172.16.30.2.
But there’s another way to specify either a particular host or a range of hosts—you can use
wildcard masking. In fact, to specify any range of hosts, you have to use wildcard masking in
the access list.
What’s wildcard masking? You’ll learn all about it using a standard access list example, as
well as how to control access to a virtual terminal, in the following sections.
Wildcard Masking
Wildcards are used with access lists to specify an individual host, a network, or a certain range of a network or networks. To understand a wildcard, you need to understand what a block size is; it’s used to specify a range of addresses. Some of the different block sizes available are 64, 32, 16, 8, and 4.When you need to specify a range of addresses, you choose the next-largest block size for your needs. For example, if you need to specify 34 networks, you need a block size of 64. If you want to specify 18 hosts, you need a block size of 32. If you only specify two networks, then a block size of 4 would work.
Wildcards are used with the host or network address to tell the router a range of available
addresses to filter. To specify a host, the address would look like this: 172.16.30.5 0.0.0.0
The four zeros represent each octet of the address. Whenever a zero is present, it means that octet in the address must match exactly. To specify that an octet can be any value, the value of 255 is used. As an example, here’s how a /24 subnet is specified with a wildcard:172.16.30.0 0.0.0.255
Wildcards are used with access lists to specify an individual host, a network, or a certain range of a network or networks. To understand a wildcard, you need to understand what a block size is; it’s used to specify a range of addresses. Some of the different block sizes available are 64, 32, 16, 8, and 4.When you need to specify a range of addresses, you choose the next-largest block size for your needs. For example, if you need to specify 34 networks, you need a block size of 64. If you want to specify 18 hosts, you need a block size of 32. If you only specify two networks, then a block size of 4 would work.
Wildcards are used with the host or network address to tell the router a range of available
addresses to filter. To specify a host, the address would look like this: 172.16.30.5 0.0.0.0
The four zeros represent each octet of the address. Whenever a zero is present, it means that octet in the address must match exactly. To specify that an octet can be any value, the value of 255 is used. As an example, here’s how a /24 subnet is specified with a wildcard:172.16.30.0 0.0.0.255
This tells the router to match up the first three octets exactly, but the fourth octet can be
any value. Now, that was the easy part. What if you want to specify only a small range of subnets? This is where the block sizes come in. You have to specify the range of values in a block size. In other words, you can’t choose to specify 20 networks. You can only specify the exact amount as the block size value. For example, the range would have to be either 16 or 32, but not 20.Let’s say that you want to block access to part of network that is in the range from 172.16.8.0 through 172.16.15.0. That is a block size of 8. Your network number would be 172.16.8.0, and the wildcard would be 0.0.7.255. Whoa! What is that? The 7.255 is what the router uses to deter-mine the block size. The network and wildcard tell the router to start at 172.16.8.0 and go up a
block size of eight addresses to network 172.16.15.0.
Seriously—it really is easier than it looks—really! I could certainly go through the binary
math for you, but no one needs that. Because, actually, all you have to do is remember that
the wildcard is always one number less than the block size. So, in our example, the wildcard
would be 7 since our block size is 8. If you used a block size of 16, the wildcard would be 15.
Easy, huh?
But just in case, we’ll go through some examples to help you nail it. The following example
tells the router to match the first three octets exactly but that the fourth octet can be anything:
Lab_A(config)#access-list 10 deny 172.16.10.0 0.0.0.255
The next example tells the router to match the first two octets and that the last two octets can be any value:
Lab_A(config)#access-list 10 deny 172.16.0.0 0.0.255.255
Try to figure out this next line:
Lab_A(config)#access-list 10 deny 172.16.16.0 0.0.3.255
The above configuration tells the router to start at network 172.16.16.0 and use a block size
of 4. The range would then be 172.16.16.0 through 172.16.19.0.
The example below shows an access list starting at 172.16.16.0 and going up a block size of
8 to 172.16.23.0:
Lab_A(config)#access-list 10 deny 172.16.16.0 0.0.7.255
The next example starts at network 172.16.32.0 and goes up a block size of 16 to
172.16.47.0:
Lab_A(config)#access-list 10 deny 172.16.32.0 0.0.15.255
The next example starts at network 172.16.64.0 and goes up a block size of 64 to
172.16.127.0:
Lab_A(config)#access-list 10 deny 172.16.64.0 0.0.63.255
The last example starts at network 192.168.160.0 and goes up a block size of 32 to
192.168.191.255:
Lab_A(config)#access-list 10 deny 192.168.160.0 0.0.31.255
Here are two more things to keep in mind when working with block sizes and wildcards:
Each block size must start at 0 or a multiple of the block size. For example, you can’t say
that you want a block size of 8 and then start at 12. You must use 0–7, 8–15, 16–23, etc.
For a block size of 32, the ranges are 0–31, 32–63, 64–95, etc.
The command any is the same thing as writing out the wildcard 0.0.0.0 255.255.255.255.
Wildcard masking is a crucial skill to master when creating IP access lists. It’s
used identically when creating standard and extended IP access lists.Standard Access List Example
In this section, you’ll learn how to use a standard access list to stop specific users from gaining access to the Finance department LAN.
In Figure 10.1, a router has three LAN connections and one WAN connection to the Internet.
Users on the Sales LAN should not have access to the Finance LAN, but they should be able to access the Internet and the marketing department. The Marketing LAN needs to access the Finance LAN for application services.
FIGURE 10.1 IP access list example with three LANs and a WAN connection
any value. Now, that was the easy part. What if you want to specify only a small range of subnets? This is where the block sizes come in. You have to specify the range of values in a block size. In other words, you can’t choose to specify 20 networks. You can only specify the exact amount as the block size value. For example, the range would have to be either 16 or 32, but not 20.Let’s say that you want to block access to part of network that is in the range from 172.16.8.0 through 172.16.15.0. That is a block size of 8. Your network number would be 172.16.8.0, and the wildcard would be 0.0.7.255. Whoa! What is that? The 7.255 is what the router uses to deter-mine the block size. The network and wildcard tell the router to start at 172.16.8.0 and go up a
block size of eight addresses to network 172.16.15.0.
Seriously—it really is easier than it looks—really! I could certainly go through the binary
math for you, but no one needs that. Because, actually, all you have to do is remember that
the wildcard is always one number less than the block size. So, in our example, the wildcard
would be 7 since our block size is 8. If you used a block size of 16, the wildcard would be 15.
Easy, huh?
But just in case, we’ll go through some examples to help you nail it. The following example
tells the router to match the first three octets exactly but that the fourth octet can be anything:
Lab_A(config)#access-list 10 deny 172.16.10.0 0.0.0.255
The next example tells the router to match the first two octets and that the last two octets can be any value:
Lab_A(config)#access-list 10 deny 172.16.0.0 0.0.255.255
Try to figure out this next line:
Lab_A(config)#access-list 10 deny 172.16.16.0 0.0.3.255
The above configuration tells the router to start at network 172.16.16.0 and use a block size
of 4. The range would then be 172.16.16.0 through 172.16.19.0.
The example below shows an access list starting at 172.16.16.0 and going up a block size of
8 to 172.16.23.0:
Lab_A(config)#access-list 10 deny 172.16.16.0 0.0.7.255
The next example starts at network 172.16.32.0 and goes up a block size of 16 to
172.16.47.0:
Lab_A(config)#access-list 10 deny 172.16.32.0 0.0.15.255
The next example starts at network 172.16.64.0 and goes up a block size of 64 to
172.16.127.0:
Lab_A(config)#access-list 10 deny 172.16.64.0 0.0.63.255
The last example starts at network 192.168.160.0 and goes up a block size of 32 to
192.168.191.255:
Lab_A(config)#access-list 10 deny 192.168.160.0 0.0.31.255
Here are two more things to keep in mind when working with block sizes and wildcards:
Each block size must start at 0 or a multiple of the block size. For example, you can’t say
that you want a block size of 8 and then start at 12. You must use 0–7, 8–15, 16–23, etc.
For a block size of 32, the ranges are 0–31, 32–63, 64–95, etc.
The command any is the same thing as writing out the wildcard 0.0.0.0 255.255.255.255.
Wildcard masking is a crucial skill to master when creating IP access lists. It’s
used identically when creating standard and extended IP access lists.Standard Access List Example
In this section, you’ll learn how to use a standard access list to stop specific users from gaining access to the Finance department LAN.
In Figure 10.1, a router has three LAN connections and one WAN connection to the Internet.
Users on the Sales LAN should not have access to the Finance LAN, but they should be able to access the Internet and the marketing department. The Marketing LAN needs to access the Finance LAN for application services.
FIGURE 10.1 IP access list example with three LANs and a WAN connection
On the router in the figure, the following standard IP access list is configured:
Lab_A#config t
Lab_A(config)#access-list 10 deny 172.16.40.0 0.0.0.255
Lab_A(config)#access-list 10 permit any
It’s very important to know that the any command is the same thing as saying the following
using wildcard masking:
Lab_A(config)#access-list 10 permit 0.0.0.0 255.255.255.255
Since the wildcard mask says that none of the octets are to be evaluated, every address matches the test condition. So this is functionally the same as using the any keyword.
At this point, the access list is configured to deny source addresses from the Sales LAN access to the Finance LAN, and allow everyone else. But remember, no action will be taken until the access list is applied on an interface in a specific direction. But where should this access list be placed? If you place it as an incoming access list on E0, you might as well shut down the Ethernet interface because all of the Sales LAN devices will be denied access to all networks attached to the router. The best place to apply this access list is on the E1 interface as an outbound list:
Lab_A(config)#int e1
Lab_A(config-if)#ip access-group 10 out
This completely stops traffic from 172.16.40.0 from getting out Ethernet 1. It has no effect
on the hosts from the Sales LAN accessing the Marketing LAN and the Internet, since traffic to those destinations doesn’t go through interface E1. Any packet trying to exit out E1 will have to go through the access list first. If there were an inbound list placed on E0, then any packet trying to enter interface E0 would have to go through the access list before being routed to an exit interface.
Let’s take a look at another example of a standard access list. Figure 10.2 shows an inter-
network of two routers with three LANs and one serial WAN connection.
FIGURE 10.2 IP standard access list example 2
Lab_A#config t
Lab_A(config)#access-list 10 deny 172.16.40.0 0.0.0.255
Lab_A(config)#access-list 10 permit any
It’s very important to know that the any command is the same thing as saying the following
using wildcard masking:
Lab_A(config)#access-list 10 permit 0.0.0.0 255.255.255.255
Since the wildcard mask says that none of the octets are to be evaluated, every address matches the test condition. So this is functionally the same as using the any keyword.
At this point, the access list is configured to deny source addresses from the Sales LAN access to the Finance LAN, and allow everyone else. But remember, no action will be taken until the access list is applied on an interface in a specific direction. But where should this access list be placed? If you place it as an incoming access list on E0, you might as well shut down the Ethernet interface because all of the Sales LAN devices will be denied access to all networks attached to the router. The best place to apply this access list is on the E1 interface as an outbound list:
Lab_A(config)#int e1
Lab_A(config-if)#ip access-group 10 out
This completely stops traffic from 172.16.40.0 from getting out Ethernet 1. It has no effect
on the hosts from the Sales LAN accessing the Marketing LAN and the Internet, since traffic to those destinations doesn’t go through interface E1. Any packet trying to exit out E1 will have to go through the access list first. If there were an inbound list placed on E0, then any packet trying to enter interface E0 would have to go through the access list before being routed to an exit interface.
Let’s take a look at another example of a standard access list. Figure 10.2 shows an inter-
network of two routers with three LANs and one serial WAN connection.
FIGURE 10.2 IP standard access list example 2
You want to stop the Accounting users from accessing the Human Resources Server attached
to the Lab_B router, but allow all other users access to that LAN. What standard access list
would you create and where would you place it?
The real answer is that you should use an extended access list and place it closest to
the source, but the question specifies that you should use a standard access list. Standard
access lists, by rule of thumb, are placed closest to the destination—in this example, Ether-
net 0 outbound on the Lab_B router. Here is the access list that should be placed on the
Lab_B router:
Lab_B#config t
Lab_B(config)#access-list 10 deny 192.168.10.128 0.0.0.31
Lab_B(config)#access-list 10 permit any
Lab_B(config)#interface Ethernet 0
Lab_B(config-if)#ip access-group 10 out
Before we move on to restricting Telnet access on a router, let’s take a look at one more stan-
dard access list example, but it will require some thought. In Figure 10.3 you have a router with four LAN connections and one WAN connection to the Internet.
You need to write an access list that will stop access from each of the four LANs shown in
the diagram to the Internet. Each of the LANs shows a single host’s IP address, and from that
you need to determine the subnet and use wildcards to configure the access list.
FIGURE 10.3 IP standard access list example 3
to the Lab_B router, but allow all other users access to that LAN. What standard access list
would you create and where would you place it?
The real answer is that you should use an extended access list and place it closest to
the source, but the question specifies that you should use a standard access list. Standard
access lists, by rule of thumb, are placed closest to the destination—in this example, Ether-
net 0 outbound on the Lab_B router. Here is the access list that should be placed on the
Lab_B router:
Lab_B#config t
Lab_B(config)#access-list 10 deny 192.168.10.128 0.0.0.31
Lab_B(config)#access-list 10 permit any
Lab_B(config)#interface Ethernet 0
Lab_B(config-if)#ip access-group 10 out
Before we move on to restricting Telnet access on a router, let’s take a look at one more stan-
dard access list example, but it will require some thought. In Figure 10.3 you have a router with four LAN connections and one WAN connection to the Internet.
You need to write an access list that will stop access from each of the four LANs shown in
the diagram to the Internet. Each of the LANs shows a single host’s IP address, and from that
you need to determine the subnet and use wildcards to configure the access list.
FIGURE 10.3 IP standard access list example 3
Here is an example of what your answer should look like (starting with the network on E0
and working through to E3):
Router(config)#access-list 1 deny 172.16.128.0 0.0.31.255
Router(config)#access-list 1 deny 172.16.48.0 0.0.15.255
Router(config)#access-list 1 deny 172.16.192.0 0.0.63.255
Router(config)#access-list 1 deny 172.16.88.0 0.0.7.255
Router(config)#access-list 1 permit any
Router(config)#interface serial 0
Router(config-if)#ip access-group 1 out
Okay, what would be the purpose of creating this list? If you actually applied this access list
on the router, you’d effectively shut down access to the Internet, so what’s the purpose of even having an Internet connection? I wrote this exercise so you can practice how to use block sizes with access lists—which is critical for your success when studying the CCNA objectives. Controlling VTY (Telnet) Access
You’ll probably have a difficult time trying to stop users from telnetting to a large router
because any active interface on a router is fair game for VTY access. You could try to create an extended IP access list that limits Telnet access to every IP address on the router. But if you did that, you’d have to apply it inbound on every interface, and that really wouldn’t scale well to a large router with dozens, even hundreds, of interfaces, would it? Here’s a much better solution: Use a standard IP access list to control access to the VTY lines themselves.
Why does this work? Because when you apply an access list to the VTY lines, you don’t need
to specify the Telnet protocol, since access to the VTY implies terminal access. You also don’t
need to specify a destination address, since it really doesn’t matter which interface address the user used as a target for the Telnet session. You really only need to control where the user is coming from—their source IP address.
To perform this function, follow these steps:
1. Create a standard IP access list that permits only the host or hosts you want to be able to
telnet into the routers.
2. Apply the access list to the VTY line with the access-class command.
Here is an example of allowing only host 172.16.10.3 to telnet into a router:
Lab_A(config)#access-list 50 permit 172.16.10.3
Lab_A(config)#line vty 0 4
Lab_A(config-line)#access-class 50 in
Because of the implied deny any at the end of the list, the access list stops any host from tel-
netting into the router except the host 172.16.10.3, regardless of which individual IP address on the router is used as a target.Extended Access Lists
In the standard IP access list example above, notice how you had to block all access from the Sales LAN to the Finance department. What if you needed Sales to gain access to a certain server on the Finance LAN but not to other network services, for security reasons? With a standard IP access list, you can’t allow users to get to one network service and not another. Said another way, when you need to make decisions based on both source and destination addresses, a standard access list won’t allow you to do that since it only makes decisions based on source address.But an extended access list will hook you up. That’s because extended access lists allow you to specify source and destination address as well as the protocol and port number that identify the upper-layer protocol or application. By using extended access lists, you can effectively allow users access to a physical LAN and stop them from accessing specific hosts—or even specific services on those hosts.
Here’s an example of an extended IP access list:
Lab_A(config)#access-list ?
<1-99> IP standard access list
<100-199> IP extended access list
<1000-1099> IPX SAP access list
<1100-1199> Extended 48-bit MAC address access list
<1200-1299> IPX summary address access list
<1300-1999> IP standard access list (expanded range)
<200-299> Protocol type-code access list
<2000-2699> IP extended access list (expanded range)
<300-399> DECnet access list
<600-699> Appletalk access list
<700-799> 48-bit MAC address access list
<800-899> IPX standard access list
<900-999> IPX extended access list
The first command shows the access-list numbers available. You’ll use the extended access-
list range from 100 to 199. Be sure to notice that the range 2000–2699 is also available for
extended IP access lists.
At this point, you need to decide what type of list entry you are making. For this example,
you’ll choose a deny list entry.
Lab_A(config)#access-list 110 ?
deny Specify packet
dynamic Specify a DYNAMIC list of PERMITs or DENYs
permit Specify packets to forward
Once you choose the access-list type, you then need to select a protocol field entry.
Lab_A(config)#access-list 110 deny ?
<0-255> An IP protocol number
eigrp Cisco’s EIGRP routing protocol
gre Cisco’s GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
igrp Cisco’s IGRP routing protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
ospf OSPF routing protocol
tcp Transmission Control Protocol
udp User Datagram Protocol
If you want to filter by Application layer protocol, you have to choose the
appropriate layer 4 transport protocol here. For example, to filter Telnet or FTP,
you choose TCP since both Telnet and FTP use TCP at the Transport layer. If you
were to choose IP, you wouldn’t be allowed to specify a specific application
protocol later.
Here, you’ll choose to filter an Application layer protocol that uses TCP by selecting TCP
as the protocol. You’ll specify the specific TCP port later. Next, you will be prompted for
the source IP address of the host or network (you can choose the any command to allow any
source address):
Lab_A(config)#access-list 110 deny tcp ?
A.B.C.D Source address
any Any source host
host A single source host
After the source address is selected, the destination address is chosen:
Lab_A(config)#access-list 110 deny tcp any ?
A.B.C.D Destination address
any Any destination host
eq Match only packets on a given port number
gt Match only packets with a greater port number
host A single destination host
lt Match only packets with a lower port number
neq Match only packets not on a given port number
range Match only packets in the range of port numbers
In the example below, any source IP address that has a destination IP address of 172.16.30.2
has been denied.
Lab_A(config)#access-list 110 deny tcp any host 172.16.30.2 ?
eq Match only packets on a given port number
established Match established connections
fragments Check fragments
gt Match only packets with a greater port
number
log Log matches against this entry
log-input Log matches against this entry,including
input interface
lt Match only packets with a lower port
number
neq Match only packets not on a given port
number
precedence Match packets with given precedence value
range Match only packets in the range of port
numbers
tos Match packets with given TOS value
<cr>
and working through to E3):
Router(config)#access-list 1 deny 172.16.128.0 0.0.31.255
Router(config)#access-list 1 deny 172.16.48.0 0.0.15.255
Router(config)#access-list 1 deny 172.16.192.0 0.0.63.255
Router(config)#access-list 1 deny 172.16.88.0 0.0.7.255
Router(config)#access-list 1 permit any
Router(config)#interface serial 0
Router(config-if)#ip access-group 1 out
Okay, what would be the purpose of creating this list? If you actually applied this access list
on the router, you’d effectively shut down access to the Internet, so what’s the purpose of even having an Internet connection? I wrote this exercise so you can practice how to use block sizes with access lists—which is critical for your success when studying the CCNA objectives. Controlling VTY (Telnet) Access
You’ll probably have a difficult time trying to stop users from telnetting to a large router
because any active interface on a router is fair game for VTY access. You could try to create an extended IP access list that limits Telnet access to every IP address on the router. But if you did that, you’d have to apply it inbound on every interface, and that really wouldn’t scale well to a large router with dozens, even hundreds, of interfaces, would it? Here’s a much better solution: Use a standard IP access list to control access to the VTY lines themselves.
Why does this work? Because when you apply an access list to the VTY lines, you don’t need
to specify the Telnet protocol, since access to the VTY implies terminal access. You also don’t
need to specify a destination address, since it really doesn’t matter which interface address the user used as a target for the Telnet session. You really only need to control where the user is coming from—their source IP address.
To perform this function, follow these steps:
1. Create a standard IP access list that permits only the host or hosts you want to be able to
telnet into the routers.
2. Apply the access list to the VTY line with the access-class command.
Here is an example of allowing only host 172.16.10.3 to telnet into a router:
Lab_A(config)#access-list 50 permit 172.16.10.3
Lab_A(config)#line vty 0 4
Lab_A(config-line)#access-class 50 in
Because of the implied deny any at the end of the list, the access list stops any host from tel-
netting into the router except the host 172.16.10.3, regardless of which individual IP address on the router is used as a target.Extended Access Lists
In the standard IP access list example above, notice how you had to block all access from the Sales LAN to the Finance department. What if you needed Sales to gain access to a certain server on the Finance LAN but not to other network services, for security reasons? With a standard IP access list, you can’t allow users to get to one network service and not another. Said another way, when you need to make decisions based on both source and destination addresses, a standard access list won’t allow you to do that since it only makes decisions based on source address.But an extended access list will hook you up. That’s because extended access lists allow you to specify source and destination address as well as the protocol and port number that identify the upper-layer protocol or application. By using extended access lists, you can effectively allow users access to a physical LAN and stop them from accessing specific hosts—or even specific services on those hosts.
Here’s an example of an extended IP access list:
Lab_A(config)#access-list ?
<1-99> IP standard access list
<100-199> IP extended access list
<1000-1099> IPX SAP access list
<1100-1199> Extended 48-bit MAC address access list
<1200-1299> IPX summary address access list
<1300-1999> IP standard access list (expanded range)
<200-299> Protocol type-code access list
<2000-2699> IP extended access list (expanded range)
<300-399> DECnet access list
<600-699> Appletalk access list
<700-799> 48-bit MAC address access list
<800-899> IPX standard access list
<900-999> IPX extended access list
The first command shows the access-list numbers available. You’ll use the extended access-
list range from 100 to 199. Be sure to notice that the range 2000–2699 is also available for
extended IP access lists.
At this point, you need to decide what type of list entry you are making. For this example,
you’ll choose a deny list entry.
Lab_A(config)#access-list 110 ?
deny Specify packet
dynamic Specify a DYNAMIC list of PERMITs or DENYs
permit Specify packets to forward
Once you choose the access-list type, you then need to select a protocol field entry.
Lab_A(config)#access-list 110 deny ?
<0-255> An IP protocol number
eigrp Cisco’s EIGRP routing protocol
gre Cisco’s GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
igrp Cisco’s IGRP routing protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
ospf OSPF routing protocol
tcp Transmission Control Protocol
udp User Datagram Protocol
If you want to filter by Application layer protocol, you have to choose the
appropriate layer 4 transport protocol here. For example, to filter Telnet or FTP,
you choose TCP since both Telnet and FTP use TCP at the Transport layer. If you
were to choose IP, you wouldn’t be allowed to specify a specific application
protocol later.
Here, you’ll choose to filter an Application layer protocol that uses TCP by selecting TCP
as the protocol. You’ll specify the specific TCP port later. Next, you will be prompted for
the source IP address of the host or network (you can choose the any command to allow any
source address):
Lab_A(config)#access-list 110 deny tcp ?
A.B.C.D Source address
any Any source host
host A single source host
After the source address is selected, the destination address is chosen:
Lab_A(config)#access-list 110 deny tcp any ?
A.B.C.D Destination address
any Any destination host
eq Match only packets on a given port number
gt Match only packets with a greater port number
host A single destination host
lt Match only packets with a lower port number
neq Match only packets not on a given port number
range Match only packets in the range of port numbers
In the example below, any source IP address that has a destination IP address of 172.16.30.2
has been denied.
Lab_A(config)#access-list 110 deny tcp any host 172.16.30.2 ?
eq Match only packets on a given port number
established Match established connections
fragments Check fragments
gt Match only packets with a greater port
number
log Log matches against this entry
log-input Log matches against this entry,including
input interface
lt Match only packets with a lower port
number
neq Match only packets not on a given port
number
precedence Match packets with given precedence value
range Match only packets in the range of port
numbers
tos Match packets with given TOS value
<cr>
You can press Enter here and leave the access list as is. But if you do that, all TCP traffic to
host 172.16.30.2 will be denied, regardless of destination port. You can be even more specific: once you have the host addresses in place, just specify the type of service you are denying. The following help screen shows you the available options. You can choose a port number, or use the application or protocol name:
Lab_A(config)#access-list 110 deny tcp any host 172.16.30.2 eq ?
<0-65535> Port number
bgp Border Gateway Protocol (179)
chargen Character generator (19)
cmd Remote commands (rcmd, 514)
daytime Daytime (13)
discard Discard (9)
domain Domain Name Service (53)
echo Echo (7)
exec Exec (rsh, 512)
finger Finger (79)
ftp File Transfer Protocol (21)
ftp-data FTP data connections (20, 21)
gopher Gopher (70)
hostname NIC hostname server (101)
ident Ident Protocol (113)
irc Internet Relay Chat (194)
klogin Kerberos login (543)
kshell Kerberos shell (544)
login Login (rlogin, 513)
lpd Printer service (515)
nntp Network News Transport Protocol (119)
pim-auto-RP PIM Auto-RP
pop2 Post Office Protocol v2 (109)
pop3 Post Office Protocol v3 (110)
smtp Simple Mail Transport Protocol (25)
sunrpc Sun Remote Procedure Call (111)
syslog Syslog (514)
tacacs TAC Access Control System (49)
talk Talk (517)
telnet Telnet (23)
time Time (37)
uucp Unix-to-Unix Copy Program (540)
whois Nicname (43)
www World Wide Web (HTTP, 80)
host 172.16.30.2 will be denied, regardless of destination port. You can be even more specific: once you have the host addresses in place, just specify the type of service you are denying. The following help screen shows you the available options. You can choose a port number, or use the application or protocol name:
Lab_A(config)#access-list 110 deny tcp any host 172.16.30.2 eq ?
<0-65535> Port number
bgp Border Gateway Protocol (179)
chargen Character generator (19)
cmd Remote commands (rcmd, 514)
daytime Daytime (13)
discard Discard (9)
domain Domain Name Service (53)
echo Echo (7)
exec Exec (rsh, 512)
finger Finger (79)
ftp File Transfer Protocol (21)
ftp-data FTP data connections (20, 21)
gopher Gopher (70)
hostname NIC hostname server (101)
ident Ident Protocol (113)
irc Internet Relay Chat (194)
klogin Kerberos login (543)
kshell Kerberos shell (544)
login Login (rlogin, 513)
lpd Printer service (515)
nntp Network News Transport Protocol (119)
pim-auto-RP PIM Auto-RP
pop2 Post Office Protocol v2 (109)
pop3 Post Office Protocol v3 (110)
smtp Simple Mail Transport Protocol (25)
sunrpc Sun Remote Procedure Call (111)
syslog Syslog (514)
tacacs TAC Access Control System (49)
talk Talk (517)
telnet Telnet (23)
time Time (37)
uucp Unix-to-Unix Copy Program (540)
whois Nicname (43)
www World Wide Web (HTTP, 80)
At this point, let’s block Telnet (port 23) to host 172.16.30.2 only. If the users want to
FTP, fine, that’s allowed. The log command is used to log messages every time the access list
is hit. This can be an extremely cool way to monitor inappropriate access attempts. Here is
how to do this:
Lab_A(config)#access-list 110 deny tcp any host
172.16.30.2 eq 23 log
You need to keep in mind that the next line is an implicit deny any by default. If you apply
this access list to an interface, you might as well just shut the interface down, since by default there is an implicit deny all at the end of every access list. You’ve got to follow up the access list with the following command:
Lab_A(config)#access-list 110 permit ip any any
Remember, the 0.0.0.0 255.255.255.255 is the same command as any, so the command
could look like this:
Lab_A(config)#access-list 110 permit ip 0.0.0.0
255.255.255.255 0.0.0.0 255.255.255.255
Once the access list is created, you need to apply it to an interface (it’s the same command
as the IP standard list):
Lab_A(config-if)#ip access-group 110 in
or
Lab_A(config-if)#ip access-group 110 out
In the following section, we’ll look at an example of how to use an extended access list.Extended Access List Example 1
Using Figure 10.1 from the IP standard access list example above, let’s use the same network
and deny access to a host at 172.16.30.5 on the Finance department LAN for both Telnet and
FTP services. All other services on this and all other hosts are acceptable for the sales and marketing departments to access.
The following access list should be created:
Lab_A#config t
Lab_A(config)#access-list 110 deny tcp any host 172.16.30.5 eq 21
Lab_A(config)#access-list 110 deny tcp any host 172.16.30.5 eq 23
Lab_A(config)#access-list 110 permit ip any any
FTP, fine, that’s allowed. The log command is used to log messages every time the access list
is hit. This can be an extremely cool way to monitor inappropriate access attempts. Here is
how to do this:
Lab_A(config)#access-list 110 deny tcp any host
172.16.30.2 eq 23 log
You need to keep in mind that the next line is an implicit deny any by default. If you apply
this access list to an interface, you might as well just shut the interface down, since by default there is an implicit deny all at the end of every access list. You’ve got to follow up the access list with the following command:
Lab_A(config)#access-list 110 permit ip any any
Remember, the 0.0.0.0 255.255.255.255 is the same command as any, so the command
could look like this:
Lab_A(config)#access-list 110 permit ip 0.0.0.0
255.255.255.255 0.0.0.0 255.255.255.255
Once the access list is created, you need to apply it to an interface (it’s the same command
as the IP standard list):
Lab_A(config-if)#ip access-group 110 in
or
Lab_A(config-if)#ip access-group 110 out
In the following section, we’ll look at an example of how to use an extended access list.Extended Access List Example 1
Using Figure 10.1 from the IP standard access list example above, let’s use the same network
and deny access to a host at 172.16.30.5 on the Finance department LAN for both Telnet and
FTP services. All other services on this and all other hosts are acceptable for the sales and marketing departments to access.
The following access list should be created:
Lab_A#config t
Lab_A(config)#access-list 110 deny tcp any host 172.16.30.5 eq 21
Lab_A(config)#access-list 110 deny tcp any host 172.16.30.5 eq 23
Lab_A(config)#access-list 110 permit ip any any
The access-list 110 tells the router you are creating an extended IP access list. The tcp
is the protocol field in the Network layer header. If the list doesn’t say tcp here, you cannot
filter by port numbers 21 and 23 as shown in the example. (These are FTP and Telnet, and
they both use TCP for connection-oriented services.) The any command is the source, which
means any IP address, and the host is the destination IP address. Remember that instead of the host 172.16.30.5 command, we could have entered 172.16.30.5 0.0.0.0 instead and there would be no difference in the result.
After the list is created, it needs to be applied to the Ethernet 1 interface outbound. This
applies the policy we created to all hosts, and effectively blocks all FTP and Telnet access to
172.16.30.5 from outside the local LAN. If this list were created to only block access from the
Sales LAN, then we’d have put this list closer to the source, or on Ethernet interface 0. So, in
this situation, we’d apply the list to inbound traffic. Let’s go ahead and apply the list to interface
E1 and block all outside FTP and Telnet access to the host:
Lab_A(config-if)#ip access-group 110 outExtended Access List Example 2
In this example, we’ll again use Figure 10.3, which has four LANs and a serial connection. What we need to do is stop Telnet access to the networks attached to the Ethernet 1 and Ethernet 2 interfaces. If we only used one access list, this would not be a very effective access list because of the latency that will be caused on the Ethernet 1 and 2 interfaces (since every packet going out these interfaces must be looked at), but if we used two lists, the latency could be less on each interface if configured correctly. However, since we’re studying the CCNA objectives, we’re going to look at this with only one access list.
The configuration on the router would look something like this, although the answer can vary:
Router(config)#access-list 110 deny tcp any 172.16.48.0 0.0.15.255 eq 23
Router(config)#access-list 110 deny tcp any 172.16.192.0 0.0.63.255 eq 23
Router(config)#access-list 110 permit ip any any
Router(config)#interface Ethernet 1
Router(config-if)#ip access-group 110 out
Router(config-if)#interface Ethernet 2
Router(config-if)#ip access-group 110 out
The important information that you need to understand from this list is as follows: First, you
need to verify that the number range is correct for the type of access list you are creating—in this example it’s extended, so the range must be 100–199. Second, you need to verify that the protocol field matches the upper layer process or application—in this example, port 23 (Telnet). The protocol parameter must be TCP, since Telnet uses TCP. If the question stated to use TFTP, then the protocol parameter must be UDP, since TFTP uses UDP, for example. Third, verify that the destination port number matches the application you are filtering for—in this case, port 23 matches Telnet, which is correct. Finally, the test statement permit ip any any is important to have at the end of the list to enable all packets other than telnet packets destined for the LANs
is the protocol field in the Network layer header. If the list doesn’t say tcp here, you cannot
filter by port numbers 21 and 23 as shown in the example. (These are FTP and Telnet, and
they both use TCP for connection-oriented services.) The any command is the source, which
means any IP address, and the host is the destination IP address. Remember that instead of the host 172.16.30.5 command, we could have entered 172.16.30.5 0.0.0.0 instead and there would be no difference in the result.
After the list is created, it needs to be applied to the Ethernet 1 interface outbound. This
applies the policy we created to all hosts, and effectively blocks all FTP and Telnet access to
172.16.30.5 from outside the local LAN. If this list were created to only block access from the
Sales LAN, then we’d have put this list closer to the source, or on Ethernet interface 0. So, in
this situation, we’d apply the list to inbound traffic. Let’s go ahead and apply the list to interface
E1 and block all outside FTP and Telnet access to the host:
Lab_A(config-if)#ip access-group 110 outExtended Access List Example 2
In this example, we’ll again use Figure 10.3, which has four LANs and a serial connection. What we need to do is stop Telnet access to the networks attached to the Ethernet 1 and Ethernet 2 interfaces. If we only used one access list, this would not be a very effective access list because of the latency that will be caused on the Ethernet 1 and 2 interfaces (since every packet going out these interfaces must be looked at), but if we used two lists, the latency could be less on each interface if configured correctly. However, since we’re studying the CCNA objectives, we’re going to look at this with only one access list.
The configuration on the router would look something like this, although the answer can vary:
Router(config)#access-list 110 deny tcp any 172.16.48.0 0.0.15.255 eq 23
Router(config)#access-list 110 deny tcp any 172.16.192.0 0.0.63.255 eq 23
Router(config)#access-list 110 permit ip any any
Router(config)#interface Ethernet 1
Router(config-if)#ip access-group 110 out
Router(config-if)#interface Ethernet 2
Router(config-if)#ip access-group 110 out
The important information that you need to understand from this list is as follows: First, you
need to verify that the number range is correct for the type of access list you are creating—in this example it’s extended, so the range must be 100–199. Second, you need to verify that the protocol field matches the upper layer process or application—in this example, port 23 (Telnet). The protocol parameter must be TCP, since Telnet uses TCP. If the question stated to use TFTP, then the protocol parameter must be UDP, since TFTP uses UDP, for example. Third, verify that the destination port number matches the application you are filtering for—in this case, port 23 matches Telnet, which is correct. Finally, the test statement permit ip any any is important to have at the end of the list to enable all packets other than telnet packets destined for the LANs
connected to Ethernet 1 and Ethernet 2.Named Access Lists
As I said earlier, named access lists are just another way to create standard and extended access lists. In medium to large enterprises, management of access lists can become, well, a real hassle over time. For example, when you need to make a change to an access list, a frequent practice is to copy the access list to a text editor, change the number, edit the list, then paste the new list back into the router. With this done, you can simply change the access-list number on the interface from the old to the new access list, and there is never a time on the network where an access list isn’t in place.This would work pretty well if it weren’t for what I call “packrat” mentality. The question becomes What do I do with the old access list? Delete it? Or should I save it in case I find a problem with the new list and need to back out of the change? So what happens is that over time through this and countless other scenarios—you can end up with a whole bunch of unapplied access lists building up on a router. What were they for? Are they important? Do I need them?
All good questions, and named access lists could be your answer.
This can also apply to access lists that are up and running. Let’s say that you come into an
existing network and are looking at access lists on a router. Suppose you find an access list 177 (which is an extended access list) that is 33 lines long. This could cause you much needless existential questioning—What is it for? Why is it here? Instead, wouldn’t an access list called, say,
finance LAN be more descriptive than one that’s named 177?
Named access lists allow you to use names to both create and apply either standard or
extended access lists. There is nothing new or different about these access lists aside from being able to refer to them in a way that makes sense to humans. But there are some subtle changes to the syntax, so let’s re-create the standard access list we created earlier for our test network in Figure 10.1 using a named access list:
Lab_A#config t
Enter configuration commands, one per line. End with CNTL/Z.
Lab_A(config)#ip access-list ?
extended Extended Acc
logging Control access list logging
standard Standard Access List
Notice that I started by typing ip access-list, not access-list. This allows me to enter
a named access list. Next, I’ll need to specify that it’s to be a standard access list:
Lab_A(config)#ip access-list standard ?
<1-99> Standard IP access-list number
WORD Access-list name
As I said earlier, named access lists are just another way to create standard and extended access lists. In medium to large enterprises, management of access lists can become, well, a real hassle over time. For example, when you need to make a change to an access list, a frequent practice is to copy the access list to a text editor, change the number, edit the list, then paste the new list back into the router. With this done, you can simply change the access-list number on the interface from the old to the new access list, and there is never a time on the network where an access list isn’t in place.This would work pretty well if it weren’t for what I call “packrat” mentality. The question becomes What do I do with the old access list? Delete it? Or should I save it in case I find a problem with the new list and need to back out of the change? So what happens is that over time through this and countless other scenarios—you can end up with a whole bunch of unapplied access lists building up on a router. What were they for? Are they important? Do I need them?
All good questions, and named access lists could be your answer.
This can also apply to access lists that are up and running. Let’s say that you come into an
existing network and are looking at access lists on a router. Suppose you find an access list 177 (which is an extended access list) that is 33 lines long. This could cause you much needless existential questioning—What is it for? Why is it here? Instead, wouldn’t an access list called, say,
finance LAN be more descriptive than one that’s named 177?
Named access lists allow you to use names to both create and apply either standard or
extended access lists. There is nothing new or different about these access lists aside from being able to refer to them in a way that makes sense to humans. But there are some subtle changes to the syntax, so let’s re-create the standard access list we created earlier for our test network in Figure 10.1 using a named access list:
Lab_A#config t
Enter configuration commands, one per line. End with CNTL/Z.
Lab_A(config)#ip access-list ?
extended Extended Acc
logging Control access list logging
standard Standard Access List
Notice that I started by typing ip access-list, not access-list. This allows me to enter
a named access list. Next, I’ll need to specify that it’s to be a standard access list:
Lab_A(config)#ip access-list standard ?
<1-99> Standard IP access-list number
WORD Access-list name
Lab_A(config)#ip access-list standard BlockSales
Lab_A(config-std-nacl)#
I’ve specified a standard access list, then added a name: BlockSales. Notice that I could’ve used a number for a standard access list, but instead, I chose to use a descriptive name. Also, notice that after entering the name, I hit Enter, and the router prompt changed. I’m now in named access list configuration mode, and am entering the named access list:
Lab_A(config-std-nacl)#?
Standard Access List configuration commands:
default Set a command to its defaults
deny Specify packets to reject
exit Exit from access-list configuration mode
no Negate a command or set its defaults
permit Specify packets to forward
Lab_A(config-std-nacl)#deny 172.16.40.0 0.0.0.255
Lab_A(config-std-nacl)#permit any
Lab_A(config-std-nacl)#exit
Lab_A(config)#^Z
Lab_A#
I enter the access list, and then exit out of configuration mode. Next, I’ll take a look at the run-
ning configuration to verify that the access list is indeed in the router:
Lab_A#show running-config
!
ip access-list standard BlockSales
deny 172.16.40.0 0.0.0.255
permit any
!
The BlockSales access list has truly been created and is in the running-config of the router. Next,
I’ll need to apply the access list to an interface:
Lab_A#config t
Enter configuration commands, one per line. End with CNTL/Z.
Lab_A(config)#int e1
Lab_A(config-if)#ip access-group BlockSales out
Lab_A(config-if)#^Z
Lab_A#
All right! At this point, we’ve re-created the work done earlier using named access lists.Monitoring Access Lists
It’s important to be able to verify the configuration on a router. Table 10.1 lists the commands
that can be used to verify the configuration.
We’ve already used the show running-config command to verify that a named access list
was in the router. So now let’s take a look at the output from some of the other commands.
The show access-list command will list all access lists on the router, whether they’re
applied to an interface or not:
Lab_A#show access-list
Standard IP access list 10
deny 172.16.40.0, wildcard bits 0.0.0.255
permit any
Standard IP access list BlockSales
deny 172.16.40.0, wildcard bits 0.0.0.255
permit any
Extended IP access list 110
deny tcp any host 172.16.30.5 eq ftp
deny tcp any host 172.16.30.5 eq telnet
permit ip any any
Lab_A#
First, notice that both access list 10 and our named access list appear on this list. Second, notice that even though I entered actual numbers for TCP ports in access list 110, the showcommand
Lab_A(config-std-nacl)#
I’ve specified a standard access list, then added a name: BlockSales. Notice that I could’ve used a number for a standard access list, but instead, I chose to use a descriptive name. Also, notice that after entering the name, I hit Enter, and the router prompt changed. I’m now in named access list configuration mode, and am entering the named access list:
Lab_A(config-std-nacl)#?
Standard Access List configuration commands:
default Set a command to its defaults
deny Specify packets to reject
exit Exit from access-list configuration mode
no Negate a command or set its defaults
permit Specify packets to forward
Lab_A(config-std-nacl)#deny 172.16.40.0 0.0.0.255
Lab_A(config-std-nacl)#permit any
Lab_A(config-std-nacl)#exit
Lab_A(config)#^Z
Lab_A#
I enter the access list, and then exit out of configuration mode. Next, I’ll take a look at the run-
ning configuration to verify that the access list is indeed in the router:
Lab_A#show running-config
!
ip access-list standard BlockSales
deny 172.16.40.0 0.0.0.255
permit any
!
The BlockSales access list has truly been created and is in the running-config of the router. Next,
I’ll need to apply the access list to an interface:
Lab_A#config t
Enter configuration commands, one per line. End with CNTL/Z.
Lab_A(config)#int e1
Lab_A(config-if)#ip access-group BlockSales out
Lab_A(config-if)#^Z
Lab_A#
All right! At this point, we’ve re-created the work done earlier using named access lists.Monitoring Access Lists
It’s important to be able to verify the configuration on a router. Table 10.1 lists the commands
that can be used to verify the configuration.
We’ve already used the show running-config command to verify that a named access list
was in the router. So now let’s take a look at the output from some of the other commands.
The show access-list command will list all access lists on the router, whether they’re
applied to an interface or not:
Lab_A#show access-list
Standard IP access list 10
deny 172.16.40.0, wildcard bits 0.0.0.255
permit any
Standard IP access list BlockSales
deny 172.16.40.0, wildcard bits 0.0.0.255
permit any
Extended IP access list 110
deny tcp any host 172.16.30.5 eq ftp
deny tcp any host 172.16.30.5 eq telnet
permit ip any any
Lab_A#
First, notice that both access list 10 and our named access list appear on this list. Second, notice that even though I entered actual numbers for TCP ports in access list 110, the showcommand
TABLE 10.1 Commands Used to Verify Access List Configuration
Command Effect
—————————————————————————————————————————–show access-list Displays all access lists and their parameters configured on the router.
This command does not show you which interface the list is set on.
show access-list 110 Shows only the parameters for the access list 110. This command does not show you the interface the list is set on.
Command Effect
—————————————————————————————————————————–show access-list Displays all access lists and their parameters configured on the router.
This command does not show you which interface the list is set on.
show access-list 110 Shows only the parameters for the access list 110. This command does not show you the interface the list is set on.
show ip access-list Shows only the IP access lists configured on the router.
show ip interface Shows which interfaces have access lists set.
show running-config Shows the access lists and which interfaces have access lists set.
gives us the protocol names rather than TCP ports for readability (hey, not everyone has them all memorized!).
Okay—here’s the output of the show ip interface command:
Lab_A#show ip interface e1
Ethernet1 is up, line protocol is up
Internet address is 172.16.30.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is BlockSales
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is disabled
IP fast switching on the same interface is disabled
IP Null turbo vector
IP multicast fast switching is disabled
IP multicast distributed fast switching is disabled
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
Web Cache Redirect is disabled
BGP Policy Mapping is disabled
Lab_A#
Be sure to notice the bold line indicating that the outgoing list on this interface is BlockSales, but the inbound access list isn’t set.
show ip interface Shows which interfaces have access lists set.
show running-config Shows the access lists and which interfaces have access lists set.
gives us the protocol names rather than TCP ports for readability (hey, not everyone has them all memorized!).
Okay—here’s the output of the show ip interface command:
Lab_A#show ip interface e1
Ethernet1 is up, line protocol is up
Internet address is 172.16.30.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is BlockSales
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is disabled
IP fast switching on the same interface is disabled
IP Null turbo vector
IP multicast fast switching is disabled
IP multicast distributed fast switching is disabled
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
Web Cache Redirect is disabled
BGP Policy Mapping is disabled
Lab_A#
Be sure to notice the bold line indicating that the outgoing list on this interface is BlockSales, but the inbound access list isn’t set.
No comments:
Post a Comment