The Ultimate CCNA Study Package - ICND 2

Chris Bryant, CCIE #12933 - www.thebryantadvantage.com Back To Index

ACLs And Route Summarization

Overview

Introduction To ACLs ACL Logic And The Implicit Deny ACL Numeric Ranges The Wildcard Mask Standard ACLs Adding Remarks To Your ACL Using "host" and "any" The Order Of The ACL Lines Extended ACLs Named ACLs Using An ACL To Block Telnet Access Where To Place An ACL How And When To Block Pings Dynamic And Time-Based ACLs Common Port Numbers To Block And Deny Sequence Numbers Intro To Route Summarization Route Summarization And RIP Route Summarization And EIGRP VLSM And CIDR

Using Summarization With ACLs "Hot Spots And Gotchas"

Introduction To Access Control Lists The basic purpose of Access Control Lists (ACLs)is to allow a router to permit or deny packets based on a variety of criteria. The ACL is configured in global mode, but is applied at the interface level. An ACL does not take effect until it is expressly applied to an interface with the ip access-group command. Packets can be filtered as they enter or exit an interface. Throughout your Cisco studies, you're going to find more and more uses for ACLs. Actually, you're going to find quite a few right here! We'll block traffic from entering an interface, exiting an interface, prevent Telnet access, allow Telnet access.... the list of uses for ACLs goes on and on. This is one skill you must master in order to work with today's Cisco devices... and I can guarantee ACL usage will come up more than once on your CCNA exam! We'll start our ACL discussion with the most common usage - to deny or allow trafficfrom entering or exiting an interface. There are some basic rules you must keep in mind in order to master ACLs, and I'll make special note of those as we go through some examples. I may get repetitive on some of this, but trust me - you'll be glad I did when these rules become second nature and help you to earn your CCNA. ACL Logic And The Implicit Deny Whena packet enters or exits an interface with an ACL applied, the packet is compared against the criteria of the ACL. If the packet matches the first line of the ACL, the appropriate permit or deny action is taken. If there is no match, the second lines criteria is examined. Again, if there is a match, the appropriate action is taken; if there is no match, the third line of the ACL is compared to the packet. This process continues until a match is found, at which time the ACL stops running. If no match is found, aimplicit deny is applied to the packet. If a packet is not expressly permitted by a line in the ACL, it will be subject to the implicit deny. Take special note of the implicit deny feature. Forgetting about this deny is the #1 reason for ACLs not giving you the desired results. The behavior described above concerning the line-by-line ACL matching process, along with the implicit deny, are default behaviors of all ACL types discussed in this section. Comparing Standard And Extended ACLs A standard ACL is concerned with only one factor, the source IP address

of the packet. The destination IP address is not considered. Extended ACLs consider both the source and destination IP address of the packet, and can consider the port number as well. You'll see some of those options later in this section. Standard and extended ACLs do not use the same numeric ranges, and you must watch out for these on the exam and in the real world. Standard ACLs use the ranges 1-99 and 1300-1999, extended lists use 100-199 and 2000 to 2699. On that subject, let's use IOS Help to view all of the numeric ranges for ACLs.
R1(config)#access-list ? <1-99> IP standard access list <100-199> IP extended access list <1100-1199> Extended 48-bit MAC 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) <700-799> 48-bit MAC address access list dynamic-extended Extend the dynamic ACL abolute timer rate-limit Simple rate-limit specific access list

The obvious question is "Why are the standard and extended list ranges broken up? Why aren't they just one big range?"Besides giving us something else to have to remember for the exam, there's a very good reason. When ACLs were first introduced, it was accepted that we'd never need more than 100 ACLs of any type on a single router. We also used to think we'd never need a home data storage device bigger than a floppy disk, and that certainly changed! As the number of different uses for ACLs expanded, the range of available ACLs on many routers began to shrink.That's when Cisco came up with the expanded ranges, and I'm sure you noticed that the expanded ranges are much larger in scope than the originals! You don't really need to know which ranges were original and which are expanded, but I'd know both of those ranges like the back of my hand before taking the CCNA exam. Also remember that any ACL usinga number from the 1 - 99 and 1300 - 1399 ranges is a standard ACL, and standard ACLs match only on the source IP address. On that topic, you also need to remember that ACLs use wildcard masks, not network or subnet masks. We can also use the words host or any in place of those masks. Let's take a look at how to write a wildcard mask and how to usehost and anyin an ACL. The Wildcard Mask ACLs use wildcard masks to determine what part of a network number should and should not be examined for matches against the ACL. Wildcard masks are written in binary, and then converted to dotted decimal for router configuration. Zeroes indicate to the router that this particular bit must match, and ones are used as I dont care bits the

ACL does not care if there is a match or not. In the following example, all packets that have a source IP address on the 196.17.100.0 /24 network should be allowed to enter the router's Ethernet0 interface. No other packets should be allowed to do so.

We need to write an ACL that allows packets in if the first 24 bits match 196.17.100.0 exactly,and does not allow any otherpackets regardless of source IP address.
1st Octet All bits must match. 00000000 2nd Octet All bits must match. 00000000 3rd Octet All bits must match. 00000000 4th Octet I dont care Resulting Wildcard Mask: 11111111
00000000 00000000 00000000 11111111

Use this binary math chart to convert from binary to dotted decimal:
1 2 3 4
st nd rd th

Octet:

128 64 32 16 8 4 2 1 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 1 0 0 0 0 0 0 0 0 1 1 1 1

Octet: 0 Octet: 0 1

Octet:

Converted to dotted decimal, the wildcard mask is 0.0.0.255.Watch that on your exam - don't choose a network mask of 255.0.0.0 for an ACL when you mean to have a wildcard mask of 0.0.0.255. Wildcard masks are also used with routing protocols OSPF and EIGRP. Consider a router with the following interfaces: serial0:172.12.12.12 /28 (or in dotted decimal, 255.255.255.240) serial1: 172.12.12.17 /28 The two interfaces are on different subnetworks. Serial0 is on the 172.12.12.0 /28 subnet, where Serial1 is on the 172.12.12.16 /28 subnet.If we wanted to run OSPF onserial0 but not serial1,using a wildcard mask makes this possible. The wildcard mask will require the first 28 bits to match 172.12.12.0; the mask doesnt care what the last 4 bits are.

1st Octet: All bits must match. 2nd Octet: All bits must match. 3rd Octet: All bits must match. 4 Octet: First four bits must match. Resulting Wildcard Mask:
th

00000000 00000000 00000000 00001111 00000000 00000000 00000000 00001111

Use this binary math chart to convert from binary to dotted decimal:
1 2
st nd

Octet: Octet:

128 64 32 16 8 4 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

3rd Octet: 4th Octet:

Converted to dotted decimal, the wildcard mask is 0.0.0.15. Configuring Standard Access Lists Let's go over the ACL theory we learned earlier in this section. I can't stress this enough - you've got to have this theory down cold.

Standard ACLs consider only the source IP address for matches. The ACL lines are run from top to bottom. If there is no match on the first line, the second is run; if no match on the second, the third is run, and so on until there is a match, or the end of the ACL is reached. This top-to-bottom process places special importance on the order of the lines. This theory is true of all ACLs. There is an implicit deny at the end of every ACL. If packets are not expressly permitted, they are implicitly denied.

If Router 3s Ethernet interface should only accept packets with a source network of 172.12.12.0, the ACL will be configured like this:
R3(config)#access-list 5 permit 172.12.12.0 0.0.0.255

That's actually all we need. The implicit deny will deny all packets not matching the first line. The ACL is then applied to the Ethernet0 interface with the ipaccessgroup command. I'll use IOS Help to show you one more important option.
R1(config)#interface e0 R1(config-if)#ip access-group 5 ? in inbound packets out outbound packets R1(config-if)#ip access-group 5 in

Overall, using an ACL to deny or permit traffic at the interface level is a two-step process:

Write the ACL with the access-list command Apply the ACL with the ip access-group command. You must specify the direction of the packets to which the ACL will be applied either in(bound) or out(bound).

Using the ACL we just wrote, traffic sourced from the 172.12.12.0 /24 network is accepted by the first and only line of the ACL. All other traffic is stopped by the implicit deny.

A great rule of thumb when determining the effect of an ACL: "If traffic isn'texplicitly permitted, it's implicitly denied." Adding Remarks Access lists can become quite large and intricate. If oneadmin writes an ACL and another admin comes in six months later to troubleshoot an issue, that secondadmin mayhave no ideawhat the ACL was trying to accomplish. Believe me, when you see a convoluted 70-line ACL that just doesn't make sense to you, you'll wish there was some kind of basic explanation! Itsprofessional courtesyto add a remark line or two to describe what an ACL was written for. To do so, use the remark ACL command:
R1(config)#access-list 5 ? deny Specify packets to reject permit Specify packets to forward remark Access list entry comment

R3#conf t R3(config)#access-list 5 permit 172.12.12.0 0.0.0.255 R3(config)#access-list 5 remark Permit network 172.12.12.0 only.

Using Host and Any for Wildcard Masks It is acceptable to configure a wildcard mask of all ones or all zeroes. A wildcard mask of 0.0.0.0 means the address specified in the ACL line must be matched exactly; a wildcard mask of 255.255.255.255 means that all addresses will match the line. Wildcard masks have the option of using the word host to represent a wildcard mask of 0.0.0.0. Consider a configuration where only packets

from IP source 10.1.1.1 should be allowed and all other packets denied. The following ACLs both do that.
R3#conf t R3(config)#access-list 6 permit 10.1.1.1 0.0.0.0 R3(config)#conf t R3(config)#access-list 7 permit host 10.1.1.1

The keyword any can be used to represent a wildcard mask of 255.255.255.255. Both of the following lines permit all traffic.
R3(config)#access-list 15 permit any R3(config)#access-list 15 permit 0.0.0.0 255.255.255.255

There's no "right" or "wrong" decision to make when you're configuring ACLs in the real world. For your exam, though, I'd be very familiar with the proper use of host and any. The Order Of The ACL Lines Is Vital There's definitely a "right" or "wrong" decision to make when it comes to the order of the ACL lines, though! Getting just two lines in the wrong order can wreck everything you're trying to do with the ACL. Here's a example of a short ACL where the intent is to deny traffic from 172.18.18.0 /24, but allow traffic sourced from any other subnet.

Pop quiz! Which of the following ACLs should we use?

R3(config)#access-list R3(config)#access-list R3(config)#access-list R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255 15 permit any 15 permit any 15 deny 172.18.18.0 0.0.0.255

R3(config)#access-list 15 deny 172.18.18.0 255.0.0.0 R3(config)#access-list 15 permit any R3(config)#access-list 15 permit any R3(config)#access-list 15 deny 172.18.18.0 255.0.0.0

We can eliminate the bottom two choices, because they have wildcard masks of 255.0.0.0. That would match only on the 2nd, 3rd, and 4th

octets, which isn't what we need. We're matching on the 1st, 2nd, and 3rd octets of 172.18.18.0, so the proper wildcard mask is 0.0.0.255.
Here are the two remaining possibilities:
R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255 R3(config)#access-list 15 permit any

R3(config)#access-list 15 permit any R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255

One of the basic ACL rules is that the ACL is matched against packets one line at a time, top to bottom. The top choice will deny all packets sourced from 172.18.18.0 first. Traffic that does not match that line drops to the second line, which permits all traffic. That's what we're trying to do! What about the second choice? The very first line is permit any, so it's impossible for any traffic not to match that line, including the traffic we're trying to block! The second line will never be run, since the first line matches all possible traffic. The permit any statement does negate the implicit deny, but watch where you put it in the ACL! If the permit any statement is at the top of any ACL, it doesn't matter how many deny statements follow it. They'll never be read.

Extended Access Control Lists Extended ACLs allow both the IP source and destination address to be matched. Actually, they require it. Even if you don't want to use either of those two criteria formatching, you still have to put any for the one you don't want to use. The source port, destination port, and protocol type can also be matched. These are truly optional options - you don't have to specify a value for any of those options if you're not using them to match traffic. In the next example,packets sourced from network 172.50.50.0 /24 should not be permitted if they are destined for network 172.50.100.0 /24.All other packets should be allowed.

Extended ACLs give us quite a few options where standard ACLs really don't give us any. Let's use IOS Help to take a look at these options in the access-list command.

R1(config)#access-list 150 ? deny Specify packets to reject dynamic Specify a DYNAMIC list of PERMITs or DENYs permit Specify packets to forward remark Access list entry comment

Along with the deny, permit, and remark choices we saw with the standard ACLs, we've got a dynamic option as well.We'll talk about that option later in this section.

R1(config)#access-list 150 deny ? <0-255> An IP protocol number ahp Authentication Header Protocol eigrp Cisco's EIGRP routing protocol esp Encapsulation Security Payload 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 pcp Payload Compression Protocol pim Protocol Independent Multicast tcp Transmission Control Protocol udp User Datagram Protocol

We can match by protocol name or by number. We'll keep it simple here and select IP. If we planned to use port numbers for matching, we'd need to specify TCP or UDP here. Now you know why you need to know those well-known port numbers you learned in the Intro section!

R1(config)#access-list 150 deny ip ? A.B.C.D Source address any Any source host host A single source host

We're going to specify the 172.50.50.0 /24 network as the source, but if we wanted any source to match on this line, we could use the any option. If we wanted to specify one and only one source IP address, we could use the host option followed by that one IP address.

R1(config)#access-list 150 deny ip 172.50.50.0 ? A.B.C.D Source wildcard bits R1(config)#access-list 150 deny ip 172.50.50.0 0.0.0.255

Just a reminder -- ACLs use wildcard bits!

R1(config)#access-list 150 deny ip 172.50.50.0 0.0.0.255 ? A.B.C.D Destination address any Any destination host host A single destination host

Now we'll define the destination address. We have the same any and host options here, but we'll define the 172.50.100.0 /24 network.
R1(config)#$ 150 deny ip 172.50.50.0 0.0.0.255 172.50.100.0 0.0.0.255

Notice the dollar sign next to the pound sign prompt? That's what you see when your command runs too long to be shown in its entirety on the screen! That does end the command, so I'll press Enter and go from there. The next and final line of the ACL will negate the implicit deny. Since this is an extended ACL, we have to enter any twice - once for the source and the second time for the destination. This line allows all traffic.

R1(config)#access-list 150 permit ip any any

To verify your ACLs and the order of the lines, run show access-list.
R1#show access-list Extended IP access list 150 deny ip 172.50.50.0 0.0.0.255 172.50.100.0 0.0.0.255 permit ip any any

Another rule of extended ACLs - both the source and destination must match the line for the action to be carried out. In this case, a packet sourced from 172.50.50.0 /24 is only denied IF the destination is on the 172.50.100.0 /24 subnet. If either the sourceor destination IP address does not match the line, there is no match.

Finally, the ACL is applied to the interface with the ip access-group command.
R1(config)#int e0 R1(config-if)#ip access-group 150 % Incomplete command. R1(config-if)#ip access-group 150 in

And yes, you do still have to define whether the ACL should be applied to incoming or outgoing traffic! Two rules regarding the direction of the ACL: A single interface can have two ACLs applied to it for each protocol - one for outbound traffic and the other for inbound traffic. To illustrate what happens when you configure two ACLs in the same direction and for the same protocol, I've created another extended ACL that matches any TCP traffic, regardless of source or destination IP address, as long as the destination port is port 80.

R1(config)#access-list 160 deny tcp any any eq 80 R1(config)#access-list 160 permit ip any any

I'll use the show ip interface command to verify that ACL 150 is currentlyconfigured on Ethernet0, both inbound and outbound.
R1#show ip interface eth0 Ethernet0 is up, line protocol isup Internet address is 172.23.23.2/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is 150 Inbound access list is 150 < output truncated for clarity >

Just to see what happens, I'll add ACL 160 to filter inbound traffic and see what happens when we have two ACLs applied to the same interface and in the same direction filtering the same protocol

R1(config)#int e0 R1(config-if)#ip access-group 160 in

No warning from the router -- what does show ip interface show?

R1#show ip interface ethernet0 Ethernet0 is up, line protocol isup Internet address is 172.23.23.2/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is 150 Inbound access list is 160

The latest ACL to be configured for inbound traffic, ACL 160, is the effective ACL for that interface. The running config also reflects this.
interface Ethernet0 ip address 172.23.23.2 255.255.255.0 ip access-group 160 in ip access-group 150 out

So now we know that we're limited to two ACLs per protocol on an interface - one inbound and one outbound - and what happens when we try to "bend" that rule!

I'm sure you'll be happy to know the second rule is much shorter. It's very rare that you'd want to apply the same ACL to inbound and outbound traffic, but you can do so, as shown here:

R1(config)#int e0 R1(config-if)#ip access-group 150 in R1(config-if)#ip access-group 150 out

Named Access Lists Named ACLs are just that rather than using a number to identify them, names are used. Consider a router with 75 ACLs. If the routers are given intuitive names, it can be much easier to see what the author of the list was trying to do - especially if they don't leave remarks with their numbered ACLs! The syntax of a named ACL is slightly different than the numbered type, but the operation is the same, as is the use of host and any. A router with a Serial interface that should allow no traffic from network 175.56.56.0 /24 to leave that interface regardless of destination, but should allow all other traffic, would be configured as follows. Note that for named ACLs, the command is ip access-list, not access-list.
R3#conf t R3#ip access-list extended NO_NETWORK56_OUT R3(config-ext-nacl)#deny ip 175.56.56.0 0.0.0.255 any R3(config-ext-nacl)#permit ip any any

A few details to note from that configuration:

Use the ip access-list command to create named ACLs The named ACL has to be defined as standard or extended

I personally like to put underscores in the named ACL's name to make the name easier to read, but that's certainly optional.

All ACL rules we've discussed to this point apply to named ACLs as well. Named ACLs are also applied to an interface in the same fashion as numbered ACLs - with the ip access-group command. As you'd expect, the direction of packets affected by the ACL must be defined as well.

R3#conf t R3(config)#interface serial0 R3(config-if)#ip access-group NO_NETWORK56_OUT out

Using An ACL To Limit Telnet Access In another section of the course, you learned how to configure a password on a router or switch's VTY lines to control access only to those who know the password. That might not be enough, though, as you may want to control Telnet access according to the IP address of the host attempting to connect. We can do that with an ACL and the access-class command. The ACLis used to indicate what host or hosts can telnet to a router. The syntax of the ACL is the same, but it is applied in a slightly different manner. The ACL is applied to the vty lines with the access-class command. Let's say that you want to restrict Telnet access to a host with the IP address 20.17.17.17, and that user must know that the password is ccna. Here's how we'd do that:
R3(config)#access-list 55 permit host 20.17.17.17 R3(config)# R3(config)#line vty 0 4 R3(config-line)#password ccna R3(config-line)#login R3(config-line)#access-class 55 in

Make sure to keep the access-class and ip access-group commands straight in your mind.access-class is used on the VTY lines, ip accessgroup is used on interfaces.
R1(config-line)#access-class ? <1-199> IP access list <1300-2699> IP expanded access list WORD Access-list name

Where Should An ACL Be Placed? The #1 rule of ACLs in the real world is to prevent traffic from traveling across a WAN when that traffic is going to be blocked from getting to its final destination in the first place. Lets take a look at such an example.

If we want to prevent that PC from accessing the server on the other side of the WAN, logic dictates thatwe'duse an extended ACL and place the ACL as close to that PC as possible. Using the extended ACL allows us to specify a source AND destination IP address, as opposed to a standard ACL, which only allows you to filter on the source IP address.

Placing the ACL as close to the source of the traffic prevents unnecessary traffic from going across the WAN in the first place. If the traffic is not going to be allowed to reach the email server, why let it go across the WAN to begin with? Using an extended ACL in this situation stops the unwanted traffic from crossing the WAN and unnecessarily using bandwidth and the remote router's resources. If youhave touse a standard ACL, put iton the interface closest to the destination. We can't put the standard ACL at the same point at which we could apply an extended ACL, because that would block all traffic sourced from that PC.

In the real world, theres no way you would ever use a standard ACL in this case. If you were out of numbered extended ACLs, which does happen, youd simply write a named extended ACL. But keep in mind that since you can only filter onsource IP addresses with a standard list, youd need to put it as close to the destination as possible. Placement can also be affected when you consider how inbound and outbound ACLs handle traffic.

Outbound ACLs are applied after packets have already been sent to the outbound interface by the routing engine, but before they're put in the transmissions queue. In contrast, inbound ACLs are applied before the routing engine handles them.

All things being equal, the router's better off by blocking traffic with an inbound ACL as opposed to an outbound ACL. However, sometimes like when you're stuck using a standard ACL to block traffic - theACL has to go on the outbound interface. To Block Or Not To Block - Pings, That Is Blocking pings is simple enough - just write an ACL that blocks ICMP echo packets and allows everything else. Here, we've got R2 and R3 on the same Ethernet segment, and R2 has no problem pinging R3.
R2#ping 172.23.23.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

To block pings coming in on R3's ethernet interface, we simply write an extended ACL specifying ICMP as the protocol and specifying echo at the end of the line. If we wanted to block ping responses, we'd configure echo-reply at the end of this line.
R3(config)#access-list 101 deny icmp any any ? <0-255> ICMP message type administratively-prohibited Administratively prohibited alternate-address Alternate address conversion-error Datagram conversion dod-host-prohibited Host prohibited dod-net-prohibited Net prohibited dscp Match packets with given dscp value echo Echo (ping) echo-reply Echo reply < readout truncated for clarity >

After applying the ACL to R3, R2 can no longer successfully ping R3.
R3(config)#access-list 101 deny icmp any any echo R3(config)#access-list 101 permit ip any any R3(config)#int e0 R3(config-if)#ip access-group 101 in R3#show access-list Extended IP access list 101 deny icmp any any echo permit ip any any R3#show ip access-list 101 Extended IP access list 101 deny icmp any any echo permit ip any any R2#ping 172.23.23.3

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

Interestingly enough, the show access-list and show ip access-list commands will show you how many matches each line of the ACL has had.
R3#show access-list Extended IP access list 101 deny icmp any any echo (5 matches) permit ip any any R3#show ip access-list Extended IP access list 101 deny icmp any any echo (5 matches) permit ip any any

So why do we even worry about blocking or allowing pings? Many networks block pings and / or ping replies on their border router's outside interface to prevent network attacks.

As others have said before me, don't go wild blocking pings on the inside of your network. As you've learned, pings are the first thing we use when network connectivity is compromised, and if pings are blocked that can lead to "false negatives" - that is, we think a device is down when it doesn't return pings, but it's actually up and the ACL is blocking the pings. Advanced ACL Types Standard and extended ACLs fit the bill perfectly in many situations, but when you come right down to it, they're hardcore when it comes to permitting and denying. Either you're permitted to do something or you're not - there's no grey area with these ACL types. This is networking, and we're always going to need some kind of exception to the rule. The following are more advanced ACLs than the standard and extended ones we generally use, and even if you don't see them on your CCNA exam, you'll definitely see them in production networks. And if you do see them on your CCNA exam, you'll be happy you knew about them! Commonly referred to as "lock-and-key", dynamic ACLs allow the creation of a dynamic extended access list. Certain Telnet users will be able toauthenticate as usual, but thisaccess to their intended destination is strictly temporary. Once their access time has elapsed, the access is terminated. It's just like giving someone a key to the lock on your front

door, and when they leave, you lock the door right behind them. Here are the basic steps for lock-and-key: The remote user telnets to the router, just as we've seen in earlier labs.

The router authenticates the user, and then creates an entry in the dynamic ACL that allows this particular host access to networks that we've previously defined.

The natural question is "How long does the remote host have access to the specified network?" That's up to us as the network admins, and there are two different kinds of timeouts we can set:

an absolute timeout, where the remote host has "x" minutes of access, and that's it an idle timeout, where the connection is terminated once no data is exchanged for "x" minutes

Finally, you may want to prevent or allow certain types of traffic according to the time. Time-based ACLs can be set to deny or permit traffic - you guessed it - on the basis of time. To write a time-based ACL, you must first define the times this ACL will be applied. You can do this on a perday basis or choose daily, weekdays, or weekend as shown by IOS Help.
R1(config)#time-range NOTELNET R1(config-time-range)#periodic ? Friday Friday Monday Monday Saturday Saturday Sunday Sunday Thursday Thursday Tuesday Tuesday Wednesday Wednesday daily Every day of the week weekdays Monday thru Friday weekend Saturday and Sunday

We'll choose weekend and then define an hourly time range.

R1(config-time-range)#periodic weekend 8:00 to 19:00

Then when you write the ACL, you specify the protocol and port number as you normally would, and then add the time-range option at the end of the command.
R1(config)#access-list 101 deny tcp any any eq telnet time-range NOTELNET R1(config)#access-list 101 permit ip any any R1#show access-list 101 Extended IP access list 101 10 deny tcp any any eq telnet time-range NOTELNET (inactive) 20 permit ip any any R1(config)#int s0/0 R1(config-if)#ip access-group 101 in

And you're all set! When the router's internal clock falls into the time range we configured, you'll see (active) in that show access-list output. Commonly Blocked And Allowed Port Numbers You know that IOS Help will show you a list of TCP and UDP port numbers, but the exam may not be as kind! It's a good idea for exam room and server room success to know the following port numbers. We went over these earlier in the course, but it never hurts to review! Some Common TCP Ports:

FTP - File Transfer Protocol - Uses TCP ports 20 and 21. SSH - Secure Shell - Uses TCP port 22. Telnet uses TCP port 23. SMTP - Simple Mail Transfer Protocol - uses TCP port 25. HTTP - HyperText Transfer Protocol - uses TCP port 80. POP3 - Post Office Protocol 3 - uses TCP port 110. SSL - Secure Socket Layer - uses TCP port 443.

Some Common UDP Ports:

DHCP - Dynamic Host Control Protocol - uses UDP ports 67 and 68. TFTP - Trivial File Transfer Protocol - uses UDP port 69. SNMP - Simple Network Management Protocol - uses UDP port 161.

Protocols Using Both TCP And UDP Ports

DNS - Domain Name Service - uses UDPand TCP port 53. The port number 24 is reserved in both UDP and TCP for private mail systems

We're going to step away from ACLs for a few minutes, and take a look at route summarization.Summarization is a vital skill for both the CCNA exam and working with real-world networks. When you have a structured approach, you'll find that summarization is actually one of the easiest things you'll ever do - but you must practice this skill to develop that approach! The examples in the next section show you how to apply route summarization to a network running OSPF, EIGRP, and RIP. While this is

a common way to apply your summarization skills, you'll also find summarization handy when you're configuring ACLs. ACL Sequence Numbers I do recommend that when you're writing an ACL, you first write it out in Notepad or your favorite word processing software and then check out the top-to-bottom logic. It's amazing how many headaches that can save you. Sooner or later, though, you'll write an ACL on the router and then realize you forgot a line. Take the following for example:
R1(config)#access-list R1(config)#access-list R1(config)#access-list R1(config)#access-list 45 45 45 45 deny 172.12.0.0 0.0.255.255 deny 172.14.0.0 0.0.255.255 deny 172.16.0.0 0.0.255.255 permit any

After writing the ACL, you realize you meant to deny the 172.12.13.0 /24 network as well. In the good old days, you'd have to delete that ACL and type it in all over again. The Cisco IOS now assigns each line in an ACL a sequence number, and you can use those sequence numbers to your advantage in this situation. Let's run show ip access-list 45.
R1#show ip access-list 45 Standard IP access list 45 10 deny 172.12.0.0, wildcard bits 0.0.255.255 20 deny 172.14.0.0, wildcard bits 0.0.255.255 30 deny 172.16.0.0, wildcard bits 0.0.255.255 40 permit any

Note the sequence numbers at the far left. We didn't enter those, the numbers were assigned to each statement by the IOS.Let's say we want to enter a line into this ACL that denies 172.13.0 /24, and we want it to be the very first line. We need to assign it a sequence number between 1 and 9, so we'll take the middle ground and assign it a sequence number of 5. We have to enter ACL config mode with the ip access-list command.
R1(config)#ip access-list standard 45 R1(config-std-nacl)#? Standard Access List configuration commands: <1-2147483647> Sequence Number 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 remark Access list entry comment R1(config-std-nacl)#5 deny 172.13.0.0 0.0.255.255

The change is verified with show access-list 45.

R1#show access-list 45 Standard IP access list 45 5 deny 172.13.0.0, wildcard bits 0.0.255.255 10 deny 172.12.0.0, wildcard bits 0.0.255.255 20 deny 172.14.0.0, wildcard bits 0.0.255.255 30 deny 172.16.0.0, wildcard bits 0.0.255.255 40 permit any

You can remove a line in this mode as well. If we decided not to block

access to 172.14.0.0 /16, we'd use the no option to do so.

R1(config)#ip access-list standard 45 R1(config-std-nacl)#no ? <1-2147483647> Sequence Number deny Specify packets to reject permit Specify packets to forward R1(config-std-nacl)#no 20 ? <cr> R1(config-std-nacl)#no 20 R1#show access-list 45 Standard IP access list 45 5 deny 172.13.0.0, wildcard bits 0.0.255.255 10 deny 172.12.0.0, wildcard bits 0.0.255.255 30 deny 172.16.0.0, wildcard bits 0.0.255.255 40 permit any

That really beats rewriting an entire ACL! This feature was introduced with IOS version 12.3, so there's a good chance you'll run into routers in the field that do not allow this line-by-line addition or removal.
Route Summarization

Route summarization is a technique used to keep routing tables as compact as possible while keeping an accurate picture of the network topology. Your ability to summarize routes will be tested on the CCNA exam, and when you practice this skill, you will solve every question regarding summarization that Cisco or anyone else asks you. When the router looks fora given destination in the routing table, it will look at all possible routes in search of the longest match for the destination in question. The larger the table, the more time this takes. Large routing tables are also a drain on router memory. RIP, EIGRP, and OSPF all use differentcommands to perform route summarization, but the concept is the same. We'll look at the RIP- and EIGRP-specific commands for route summarization later in this section, but first let's go through the actual summarization process. (OSPF route summarization techniques will be covered in your CCNP BSCI studies.) In the following example, R2 is sending a routing update to R3 for the networks 100.4.0.0 /16, 100.5.0.0 /16, 100.6.0.0 /16, and 100.7.0.0 /16. Without route summarization, R2 will send an update containing the four individual routes.

To configure a single route summary for these networks, write the network numbers out in binary.

 100.4.0.0 100.5.0.0 100.6.0.0 100.7.0.0

1st Octet 01100100 01100100 01100100 01100100

2nd Octet 00000100 00000101 00000110 00000111

3rd Octet 00000000 00000000 00000000 00000000

4th Octet 00000000 00000000 00000000 00000000

Moving left to right, determine what bits each network number have in common.
100.4.0.0 100.5.0.0 100.6.0.0 100.7.0.0 1st Octet 01100100 01100100 01100100 01100100 2nd Octet 00000100 00000101 00000110 00000111 3rd Octet 00000000 00000000 00000000 00000000 4th Octet 00000000 00000000 00000000 00000000

Each of the network has the first 14 bits in common. The resulting network number is the summary for the network. Here, the network summary address is 100.4.0.0. Simple, right? Right! But - we're not quite done! The subnet mask for the summary must now be determined. The mask isdetermined by putting 1 in for each of the common bits of the summary network number, and 0 for the dont care bits. In this example, the binary mask would be 11111111 11111100 00000000 00000000, resulting in a mask of 255.252.0.0. The final summary address is 100.4.0.0 255.252.0.0, or 100.4.0.0 /14. Watch that on both the exam and in network documentation - those two summaries are the same.

Route summarization may include networks that dont exist (yet). The previous example is a clean route summarization; it includes only the fourspecified networks and no others. What if the routes to be summarized were 100.1.0.0, 100.2.0.0, 100.3.0.0, and 100.4.0.0?
100.1.0.0 100.2.0.0 100.3.0.0 100.4.0.0 1st Octet 0110100 0110100 0110100 0110100 2nd Octet 00000001 00000010 00000011 00000100 3rd Octet 00000000 00000000 00000000 00000000 4th Octet 00000000 00000000 00000000 00000000

The four networks have their first 13 bits in common. The resulting

network number is the summary for the network, 100.0.0.0. The subnet mask is determined by putting 1 in for each common bit and 0 for the rest, resulting in a mask of 255.248.0.0. The final summary address is 100.0.0.0 255.248.0.0. This address and mask are accurate for the four networks given. A routing issue could arise because this summary also includes networks 100.5.0.0, 100.6.0.0, and 100.7.0.0:
1st Octet 100.1.0.0 0110100 100.2.0.0 0110100 100.3.0.0 0110100 100.4.0.0 0110100 100.5.0.0 0110100 100.6.0.0 0110100 100.7.0.0 0110111 2nd Octet 00000001 00000010 00000011 00000100 00000101 00000110 00000111 3rd Octet 00000000 00000000 00000000 00000000 00000000 00000000 00000000 4th Octet 00000000 00000000 00000000 00000000 00000000 00000000 00000000

This does not make the summary address wrong; it does allow for routing problems if these additional three networks were placed elsewhere on the network. Once the summary address and mask have been determined, write out the next consecutive network number to see if the summary address will also represent that address. If so, be aware of the potential routing issues of using that network number in another section of the network.
Route Summarization With RIP

RIP uses the interface-level command ip summary-address rip to configure summary addresses. In this example, R2 and R3 are running RIP version 2. R2 is advertising the following networks to R3: 172.16.8.0 /24, 172.16.9.0 /24, 172.16.10.0 /24, and 172.16.11.0 /24.

To summarize these networks, convert them from dotted decimal to binary, and determine the bits the networks have in common from left to right:
172.16.8.0 172.16.9.0 1st Octet 2nd Octet 3rd Octet 4th Octet 10101100 00010000 00001000 00000000 10101100 00010000 00001001 00000000

172.16.10.0 10101100 00010000 00001010 00000000 172.16.11.0 10101100 00010000 00001011 00000000

The networks have 22 bits in common. The resulting network number is 172.16.8.0. Using 1s for the in-common bits and 0s for the rest, the resulting subnet mask is 11111111 11111111 11111100 00000000, which in dotted decimal is 255.255.252.0. The summary address is 172.16.8.0 255.255.252.0. With RIP, advertise the summary address with the interface-level command ip summaryaddress rip. Here's the original RIP configuration on R2.
R2(config-if)#router rip R2(config-router)#version 2 R2(config-router)#no auto R2(config-router)#network 172.16.0.0

R3 has each individual route in its RIP routing table.

R3#show ip route rip 172.16.0.0/24 is subnetted, 4 subnets R 172.16.8.0 [120/1] via 172.23.23.2, 00:00:02, Ethernet0 R 172.16.9.0 [120/1] via 172.23.23.2, 00:00:02, Ethernet0 R 172.16.10.0 [120/1] via 172.23.23.2, 00:00:02, Ethernet0 R 172.16.11.0 [120/1] via 172.23.23.2, 00:00:02, Ethernet0

The ip summary-address rip command is configured on ethernet0. That's right - the summary address is configured on the interface that will be advertising the route, not the RIP routing process itself.
R2#conf t R2(config)#int ethernet0 R2(config-if)#ip summary-address rip 172.16.8.0 255.255.252.0

Instead of waiting for the next RIP update to see the changes on R3, I'll run the command clear ip route *. That clears the routing table of all dynamically learned routes, forcing the protocol to update immediately.R3 then has only one RIP route, and it's the summary route we just configured!

R3#clear ip route * R3#show ip route rip 172.16.0.0/22 is subnetted, 1 subnets R 172.16.8.0 [120/1] via 172.23.23.2, 00:01:24, Ethernet0


Route Summarization With EIGRP

EIGRP uses an interface-level command for route summarization as well. R2 is advertising four routes to R3 via EIGRP: 100.0.0.0 /8, 101.0.0.0 /8, 102.0.0.0 /8, and 103.0.0.0 /8.

To summarize the networks, convert them from dotted decimal to binary, and determine how many in-common bits exist from left to right.
100.1.0.0 101.1.0.0 102.1.0.0 103.1.0.0 1st Octet 01100100 01100101 01100110 01100111 2nd Octet 00000001 00000001 00000001 00000001 3rd Octet 00000000 00000000 00000000 00000000 4th Octet 00000000 00000000 00000000 00000000

The networks have six bits in common, resulting in the network number 100.0.0.0. The summary mask is determined by placing 1s in the mask for the in-common bits and 0s for the rest. The binary mask is 11111100 00000000 00000000 00000000, which in dotted decimal is 252.0.0.0 The summary address and maskis 100.0.0.0 252.0.0.0. The interfacelevel command ip summary-address eigrp will summarize the routes.
R2#conf t R2(config)#interface ethernet0 R2(config-if)#ip summary-address eigrp 100 100.0.0.0 252.0.0.0

R3#show ip route eigrp D 100.0.0.0/6 [90/2297856] via 172.23.23.2, 00:02:33, Ethernet0

 Determining and Configuring Variable-Length Subnet Masks

You are *not* going to have to do anything like the following on the CCNA exam. Obviously, this is a long exercise that takes a good deal of time. It does give you some excellent practice of your subnetting skills, and I've gotten quite a few emails from students who not only passed their CCNA exam, but could then go out and create VLSM schemes for their networks. Deciding on what VLSM schemeto use is simply a matter of determining how many host bits will be needed for the required number of hosts, and charting the VLSM configuration as this is done for each network. Consider a network given the network 192.168.56.0. There will be four subnets that require the following number of hosts:
Network Network Network Network A B C D Hosts Required 2 15 30 48

While many production networks use subnet zero, some do not. For this example, we will assume that we have been asked by the network manager not to use subnet zero. The subnet number must have a zero in every bit that the subnet mask does. These are the host bits. When configuring VLSM, the question to ask is, What is the smallest unused network number that can be created when all host bits are 0? The picture becomes much clearer when the subnet number and /30 mask are converted to binary:
1st Octet 2nd Octet 3rd Octet 4th Octet Network 192.168.56.0 11000000 10101000 00111000 00000000 /30 Subnet Mask 11111111 11111111 11111111 11111100

Only the last two bits of the subnet 192.168.56.0 have to be 0 in order to match the subnet mask. The question What is the smallest unused network number that can be created when all host bits are 0? is answered with the address 192.168.56.0. Its good practice to keep a chart of VLSMs as they are created to ensure overlapping does not take place.
Subnet Network Valid Broadcast Address Hosts Address < subnet zero, 192.168.56.0 / 30 56.0 56.1, 56.2 56.3 not in use > Network / Mask

Network A requires two hosts, so again two host bits will be needed. The same chart previously drawn is used again:
1st Octet 2nd Octet 3rd Octet 4th Octet Network 192.168.56.0 11000000 10101000 00111000 00000000 /30 Subnet Mask 11111111 11111111 11111111 11111100

Again, only the last two bits of the network number have to be zero. The question What is the smallest unused network number that can be created while keeping the host bits at 0? has a different answer, though, since 192.168.56.0 has already been used. By changing the last network bit (the 6th bit of the final octet) to1, it yields network number 192.168.56.4, and the last two bits of that network number are 0 as well:
1st Octet 2nd Octet 3rd Octet 4th Octet Network 192.168.56.4 11000000 10101000 00111000 00000100 /30 Subnet Mask 11111111 11111111 11111111 11111100

This is the network number and subnet mask to use for Network A, and is added to the VLSM table:
Subnet Network Valid Broadcast Address Hosts Address < subnet zero, 192.168.56.0 / 30 56.0 56.1, 56.2 56.3 not in use > Network A 192.168.56.4 / 30 56.4 56.5, 56.6 56.7 Network / Mask

Network B requires 15 host addresses, which requires five host bits. (2 to the 5th power is 32, yielding 30 host addresses. 2 to the 4th power is 16, but subtracting the network address and broadcast address only leaves 14 valid host addresses.) Convert the network number and a /27 mask to binary:
Network 192.168.56.0 /27 Subnet Mask 1st Octet 2nd Octet 3rd Octet 4th Octet 11000000 10101000 00111000 00000000 11111111 11111111 11111111 11100000

The question: What is the smallest unused network number that can be created while leaving the host bits at 0? The answer: The smallest value that can be created with the network portion of the 4th octet (the first three bits) is 000, but that would yield 192.168.56.0, which has already been used. A binary value of 001 would yield 192.168.56.32, which has not yet been used. Use this network and a /27 subnet mask for Network B.

Subnet < subnet zero, not in use > Network A Network B

Network / Mask 192.168.56.0 / 30 192.168.56.4 / 30 192.168.56.32 / 27

Network Valid Address Hosts 56.0 56.1, 56.2 56.4 56.32 56.5, 56.6 56.33 56.62

Broadcast Address 56.3 56.7 56.63

Network C requires 30 host addresses; a mask of /27 will result in exactly that many host addresses. Refer to the chart of the network number and the /27 bit subnet mask:
Network 192.168.56.0 /27 Subnet Mask 1st Octet 2nd Octet 3rd Octet 4th Octet 11000000 10101000 00111000 00000000 11111111 11111111 11111111 11100000

The question What is the smallest unused network number that can be created while leaving the host bits at 0? now has a different answer, since network 192.168.56.32 was just used. The next-smallest value that can be created with the network portion of the network number is 010 in binary, or 64 in decimal, yielding the network number 192.168.56.64. Use this network with a /27 bit mask for Network C.
Subnet < subnet zero, not in use > Network A Network B Network C Network / Mask 192.168.56.0 / 30 192.168.56.4 / 30 192.168.56.32 / 27 192.168.56.64 / 27 Network Valid Address Hosts 56.0 56.1, 56.2 56.4 56.32 56.64 56.5, 56.6 56.33 56.62 56.65 56.94 Broadcast Address 56.3 56.7 56.63 56.95

Network D requires 48 host addresses; six host bits will be needed. (Two to the sixth power is 64, leaving 62 valid host addresses.) Compare the network number to a subnet mask of /26.
Network 192.168.56.0 /26 Subnet Mask 1st Octet 2nd Octet 3rd Octet 4th Octet 11000000 10101000 00111000 00000000 11111111 11111111 11111111 11000000

The question: What is the smallest unused network number that can be created while leaving the host bits at zero? There are only two network bits in the 4th octet, representing 128 and 64 from left to right. The network number 64 is used by Network C; the next smallest possible value is 128. Use this network for Network D, along with a subnet mask of /26.

Subnet < subnet zero, not in use > Network A Network B Network C Network D

Network / Mask 192.168.56.0 / 30 192.168.56.4 / 30 192.168.56.32 / 27 192.168.56.64 / 27 192.168.56.128 / 26

Network Valid Address Hosts 56.0 56.1, 56.2 56.4 56.32 56.64 56.128 56.5, 56.6 56.33 56.62 56.65 56.94 56.129 56.190

Broadcast Address 56.3 56.7 56.63 56.95 56.191

The VLSM configuration is complete, and the single network 192.168.56.0 has been used to configure an entire networks IP addressing. Classless InterDomain Routing Classless InterDomain Routing (CIDR) is an IP address conservation methodology used by Internet Service Providers (ISP). Frankly, CIDR is simply subnetting and summarization performed at the ISP level. If you're "configuring CIDR", all you're doing is - you guessed it - subnetting and summarization. Using Summarization In ACLs Your summarization skills can really come in handy when you're writing ACLs as well. Let's say you need to deny packets sourced from the following four networks while permitting all other sources.

172.12.4.0 /24 172.12.5.0 /24 172.12.6.0 /24 172.12.7.0 /24

You could certainly write a five-line ACL, and there would be no problem:
access-list access-list access-list access-list access-list 23 23 23 23 23 deny 172.12.4.0 deny 172.12.5.0 deny 172.12.6.0 deny 172.12.7.0 permit any 0.0.0.255 0.0.0.255 0.0.0.255 0.0.0.255

But you can summarize that third octet and write this entire ACL with one line: 172.12.4.0 10101100 00001100 00000100 00000000 172.12.5.0 10101100 0000110000000101 00000000 172.12.6.0 10101100 00001100 00000110 00000000 172.12.7.0 10101100 00001100 00000111 00000000

Using the summarization skills you've developed, you'll quickly see that these four networks have their first 22 bits in common, resulting in a summary of 172.12.4.0. This is an ACL, so we need a wildcard mask. With the first 22 bits set to zero and the last ten set to one, we have a wildcard mask of 0.0.3.255. So while there's nothing technically wrong with the four-line ACL, we can write the following two-line ACL and it does the exact same thing - a little faster!
R1(config)#access-list 24 deny 172.12.4.0 0.0.3.255 R1(config)#access-list 24 permit any

Not only does this skill impress your friends, it just might impress Cisco! Hot Spots And Gotchas Know your numeric ACL ranges and watch 'em on the exam!
R1(config)#access-list ? <1-99> IP standard access list <100-199> IP extended access list <1100-1199> Extended 48-bit MAC 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) <700-799> 48-bit MAC address access list dynamic-extended Extend the dynamic ACL abolute timer rate-limit Simple rate-limit specific access list

Standard ACLs match on the source IP address only. Outbound ACLs are applied after the packets have been routed and sent to the outbound interface, but before they're queued. In contrast, inbound ACLs are applied before the packets get to the routing engine. If packets aren't going to be allowed out any interfaces on the receiving router, go ahead and block them with an inbound ACL. The ip access-list command is used to create named ACLs. Standard and extended ACLs are created with the access-list command. Both are applied to interfaces with theip access-group command and to VTY lines with the ip access-class command. Know your common port numbers for blocking and allowing traffic with ACLs. Explicit deny statements do not override the implicit deny. If an ACL contains only deny statements, that ACL is effectively denying all traffic. Standard ACLs should be placed as closely to the destination as possible. Extended ACLs should be placed as closely to the source as possible, especially when WANs are involved. To see all ACLs and the number of matches for each line, use show access-list. To view one specific list, follow that command with the ACL

number. The "per-per-per" rule of ACLs: You can configure one ACL per direction, per protocol, per interface. Extended ACLs offer the ability to match against protocols, port numbers, and/or source and destination IP addresses. Standard ACLs match only against source IP addresses. A popular use of ACLs is to block pings. To do so, specify ICMP as the protocol and either echo (ping) and/or echo-reply (ping reply) at the end of the ACL line. Dynamic ACLs ("lock-and-key ACLs") allow temporary access for a remote host to access certain networks. Time-based ACLs allow permit and deny statements to be in effect only at specified times.
Back To Index
Copyright 2011 The Bryant Advantage.All Rights Reserved.