CCNA Question of the Week 2

In the following image, you'll see a network topology.  In this topology, the routers are running the RIP routing protocol.  As is traditional with these questions, I'm going to strip out all the irrelevant information.  We're not going to see any router configuration, IP addressing, or anything else that would distract from the question at hand.  The key thing we're going to focus on here is that there are 20 routers.  First, we'll start with a couple assumptions:

• The RIP routing protocol is configured correctly on every router.  
• Nothing in the routers configurations differ except for IP addresses and networks in the routing protocol.
• The IP addressing scheme is correctly subnetted, and the routers are addressed correctly on every interface.

So this week's question is, can the RIP protocol function correctly in this topology?  And for a couple follow up questions:  Why or why not?  Does it make a difference if we're running RIPv1 or RIPv2?

The first thing that probably comes to mind is that the RIP protocol has a maximum hop count.  Most CCNA students go here first when something of this nature comes up.   Now let's consider the difference between hop count, and the number of routers in the topology.  The hop count refers to the number of hops between two routers.  It says nothing about the number of routers in the topology.  

So Let's look at the two routers that are furthest apart, R1 and R20.  In this particular topology, there is no path from R1 to R20 that is more than 7 hops.  And if there a path that exceeded the maximum hop count, it would be ignored by the routing protocol, not having any effect on a different route that didn't exceed 15 hops.  

So the answer to the question is yes, this is a valid RIP topology.  Now two routers exceed 15 hops apart, so there is no part of the topology that is unreachable by any other portion of the topology.  PC1 can reach PC2.

And for the final follow up question, it doesn't matter if we're running RIPv1 or RIPv2.  Neither version of RIP will balk at a hop count of 7.

Netflow Collectors

One of the big topics currently in Cisco's security track is Netflow.  According to Cisco, "NetFlow provides valuable information about network users and applications, peak usage times, and traffic routing."  With all of it's known, and yet to be discovered uses, it's no doubt that NetFlow will continue to be a big part of Cisco's security exams for the foreseeable future, as well as potentially finding it's way into other tracks if it's not already there.

Symmetric Traffic and IPS

A well known problem for network and security professionals in the enterprise is asymmetric routing.  At it's simplest, this is where traffic flows outbound through Router A, while the return traffic returns through Router B, or through both Routers A and B.   If you're using a reflexive ACL, for example, this will lead to some, if not all of the return traffic being blocked as it attempts to return through Router B.  This is due to Router A having a record of the outbound traffic while Router B does not.  Riverbed breaks this down into several sub-categories such as complete asymmetry, server-side asymmetry, client-side asymmetry, and multi-SYN retransmit.  But for our purposes here, it's all asymmetric, and it's all a bad thing.  While some firewalls are able to share state to avoid this situation, not all do.  And Cisco Routers running IOS do not.

While asymmetric routing is known to be a problem at the network edge, it can be a problem for security professionals internally as well.  And the larger the network is, the more likely asymmetric traffic is to occur at some level.  When you deploy an IPS sensor in the network, it must be able to see all traffic in both directions for maximum effectiveness.  When an IPS sensor is able to see all the traffic involved in a particular session, you get better threat detection, reduced susceptibility to IPS evasion techniques, and less susceptibility to false-positives and false-negatives. 

While it cannot be completely avoided at the enterprise edge, the good news is that internally, steps can be taken to reduce if not eliminate the effects of asymmetric routing.  So good network design is a must to get the maximum effectiveness of an IPS deployment, particularly if there are going to be multiple sensors along a given traffic flow.

There's a few options to ensure symmetric traffic flows, or to mitigate the effect of asymmetric traffic flows including:

• Duplicate traffic across multiple IPS sensors to ensure each sensor can see all applicable data.  In addition to the challenges presented in getting all the relevant data to each IPS, we also have a greater likelihood of overloading IPS sensors with traffic, which will result in packets being dropped.
• Integration of an IPS switch.  This is reducing traffic down to a single switch.  While it is better from an IPS standpoint, it's introducing a single point of failure into the network.
• Correctly configuring spanning tree parameters to ensure symmetrical paths across Layer 2 areas.
• Routing manipulation with techniques such as PBR. This is a cost effective solution as it involves only configuration changes rather than additional hardware.  But it adds complexity to the network in addition to requiring cooperation between security and networking. 
• Sticky load-balancing utilizing technology such Cisco's ACE module or Riverbed's Asymmetric Routing Detection to better reduce the chances of asymmetric routing.
• In cases of HSRP induced asymmetry, utilize EEM and EOT in order to change the paths of HSRP related routes dynamically.
• Configuring firewalls as active/standby pairs rather than active/active pairs.

But as you can see, many of these techniques involve taking redundant data paths out of the equation, and therefore reducing the amount of overall usable bandwidth across the network.  Others involve sending more data to or through each IPS unit, increasing the burden on each unit and increasing the likelihood of dropped packets.  So there is obviously a balancing act between performance and visibility.

The Accuracy of Sampled Netflow

To alleviate the fear of overburdening the CPU due to the collection of NetFlow statistics, Cisco gives us the option of using Sampled NetFlow. Sampled NetFlow allows you to sample 1 out of 10 packets, 1 out of 100 packets, or however much of a subset of the total number of packets. The theory is that with a good sample, the traffic will still be indicative of what is flowing through the router. If 10% of the total amount of packets following through the router is DNS queries, for example, then approximately 10% of the total amount of packets in the sample will also be DNS queries, and so on.

The reason that this is necessary is because of the way that a router handles traffic when collecting NetFlow statistics. In order to process a packet in order to collect NetFlow statistics, that packet has to be processed by the CPU. When sampling is enabled, the packets that are not part of the sample are switched faster because they will not require the additional processing required.

NetFlow sampling is enabled on supported IOS platforms with just a few commands.

ip route-cache flow sampled

ip flow-sampling-mode packet-interval 100

NetFlow sampling can be monitored with the show ip flow sampling command.

So as you can see, NetFlow sampling is simple to configure and monitor. It only takes a couple commands. But the question now needs to be asked, how indicative of the total network traffic is the sample? In other words, if I’m seeing 10% of all traffic being DNS queries in my sample, is 10% of the total traffic flowing through this router really DNS queries? Or is there some significant level of error in the sampling? In Cisco documentation and Certification Exam Guides, it is admitted that the sample will never be 100% accurate, but that it should usually be pretty close. They’ll also mention that you should obviously check the accuracy periodically.

Recently, I came across an academic article talking about the accuracy of NetFlow sampling. In the article, they collect data over time with a 1 in 250 packet NetFlow sample and compared it to a raw traffic sniff utilizing tcpdump. Shown below is Figure 8 from the article, which summarizes their findings. The red dotted line shows real time data of traffic flowing through the router, while the solid blue line shows real time data of their 1 in 250 NetFlow sample.

The article states that "In Figure 8 the cumulative empirical probability is plotted with its relative error. It indicates that the performance of systematic and static random sampling is not distinguishable in practice. We believe it is true in most of backbone links where the degree of multiplexing of flows is high."  In other words, the sample is really indistinguishable from the full data set.  Equally of importance, they found that the processing overhead of NetFlow sampling to be insignificant.  Further accuracy of their collection methodologies is demonstrated by SNMP byte count data strongly correlating with NetFlow byte count data.  There's a lot of statistics and graphs in the article if you're into that sort of thing.

Conversely, in another academic article, the researchers found their sampling to be significantly less accurate.  They stated that "Our experimental results allow us to come to the conclusion that: (i) our traffic classification method can achieve similar accuracy than previous packet-based techniques, but using only the limited set of features provided by NetFlow, and (ii) the impact of packet sampling on the classification accuracy of supervised learning methods is severe."  They discuss a training process which gets their accuracy to 85% for a 1/100 sampling.  Good enough for most use cases, but still too manual and still still a far cry from the results of the first study.

So where do we stand with Sampled NetFlow accuracy?  One study says it's pretty accurate, and the other says not so much.  So the jury is still out, and we're back to Cisco's recommendation that you should be testing the accuracy to determine if it is good enough for your use case.  Like the team in the first article, you can easily use a network tap or SPAN port to compare what is actually coming out of a router interface with the NetFlow sample estimating what is coming out of that router interface.  Don't just assume.

IOS Zone Based Firewall

One of the most commonly covered security features when it comes to Cisco security is the ZBF.  It wouldn't be much of a network security blog without at least one post on this topic, so here's my take.

With IOS version 12.4(6)T, Cisco introduced the Zone Based Firewall (ZBF), sometimes referred to as the Zone Policy Based Firewall.  With this, the Classic IOS Firewall or Context-Based Access Control (CBAC), available since IOS version 11.2, is now deprecated. Nearly all of the features of the Classic IOS Firewall are implemented in ZBF as well as wide range of new features. In addition to the new features available in ZBF, it is also said to improve firewall performance over CBAC for most inspection activities.  I've seen it stated in some places that if you attempt to inter-mingle CBAC configuration commands with your ZBF, it MIGHT work, however most documentation states that it wont.  So I wouldn't risk it.  Choose one or the other.

ACLs by Country

Have you ever wanted to create an ACL by country?  There's a number of different ways you can go about it.  Certain models of firewalls have this functionality built in.  IOS based routers and ASA firewalls have no such capability, so we'll have to do this a bit more manually.  I'll present two methods.

The first method is detailed here.  In this post, wget goes out to the Internet and grabs the necessary data from the applicable RIR.  Some custom Perl code pulls out the subnets associated with that country and then builds the ACL.  This one is probably not for the faint of heart nor someone not very fluent in Unix command lines.

A simpler way is through a website called Country IP Blocks.  Navigate to The Create Country ACL page on their site and you can select one or more countries to build an ACL for.  Then pick which format you want the results in.  Cisco ACL is just one of 12 options here, and then click "Create ACL" and you're done.  Other sites such as ipdeny.com and countryacl.tools.uebi.net provide similar functionality.

These lists get pretty long. Want one that that will permit or deny United States based addresses?  That'll be 55,348 lines.  Want to create an ACL that will block Russia and China?  That's 27,386 lines.  Hope your router is maxed out on RAM.

Resequencing an ACL

Here's a quick post on a very useful command when working with ACLs.  I first heard about it while watching a CBT Nugget video, and I can say that it was definitely not covered in the NetAcad curriculum when I went through the classes, because I remember bringing it up to the instructor and it was news to him.

So let's begin by setting the scenerio.  You have the following ACL:

show ip access-list EXAMPLE

Extended IP access list EXAMPLE
    1 permit ip host 10.10.10.28 any
    2 permit ip host 10.10.10.10 any
    3 permit ip host 10.10.10.11 any
    4 permit ip host 10.10.10.45 any
    5 deny ip 10.10.10.0 0.0.0.255 any
    10 permit tcp any host 192.168.10.4 eq smtp

And let's say that we now need to allow one additional host out.  We could rewrite the ACL, but that could be a lot of work if its a long ACL.  Any other options?

Yes, the resequence command can help.  This command was introduced in IOS 12.2(14)S, and allows you to easily resequence an entire ACL.

ip access-list resequence EXAMPLE 10 10

This will renumber every line in the ACL starting with 10, and with an increment of 10 between each line.  This is the default sequencing for an access-list where no sequence numbers are entered.  The end result would be:

Extended IP access list EXAMPLE
    10 permit ip host 10.10.10.28 any
    20 permit ip host 10.10.10.10 any
    30 permit ip host 10.10.10.11 any
    40 permit ip host 10.10.10.45 any
    50 deny ip 10.10.10.0 0.0.0.255 any
    60 permit tcp any host 192.168.10.4 eq smtp

Old documenation will tell you that you can't edit a numbered ACL, but that's actually not true anymore.  

Reflexive ACLs on IOS Routers

In a nutshell, reflexive ACLs allow packets to be evaluated based on upper layer session information. You use reflexive ACLs in order to permit the return traffic from an established session, but deny all other traffic in that direction.  For example, you open up a browser and establish an HTTPS session with www.awesomewebsite.com.  Now obviously, you want the return traffic from the server hosting awesomewebsite.com to make it back to you so you can see this awesome website.  But you also do not want malicious traffic trying to reach your workstation to come in with it.  A standard or extended ACL does not allow this, it's all or nothing.  But a reflexive ACL allows you to do exactly that, allow the return traffic from your session with awesomewebsite.com, but deny all other incoming traffic.  I've heard reflexive ACLs described as "a poor man's stateful firewall."

Cisco documentation points out that you can also configure it in the other direction.  You can, for example, allow all incoming traffic to a server in your DMZ, but only allow return traffic from that server to go back out to the Internet. In this example, external users would be able to view the content on your DMZ server, but it would mitigate the risk of your server becoming part of a botnet and eat up your upload bandwidth participating in a DDoS attack.  While possible, I doubt it's used very often.  So in the configuration example, we'll focus on the more common scenario.

So lets configure a reflexive ACL.  We'll start out with a basic ACL in the outbound direction which will allow all outbound traffic.  As typical, I'll use upper case letters for words and names I've created so they stand out as such when viewing show statements. 

ip access-list extended OUTBOUND
  permit ip any any reflect REFLECTED

And that's it.  In this ACL, we are allowing all outbound traffic. The difference here between this ACL and no ACL at all is the keyword reflect.  This tells the router to remember all traffic matched by the permit ip any any, and create a dynamic ACL for the return traffic that will be allowed.  But we're not limited to this single permit in the OUTBOUND ACL, we can combine that with any combination of permit and deny statements as needed.  Note that reflexive ACLs can only be used as part of extended named ACLs.   But other than that, you're pretty much only limited by your imagination.

ip access-list extended OUTBOUND
  permit tcp host 10.10.10.10 any eq smtp REFLECTED
  deny tcp any any eq smtp
  permit ip any any reflect REFLECTED

Here, we're denying outbound smtp except from a single host (the company email server), and then allowing all other traffic to go out reflected. Next, we'll create a basic ACL for the inbound direction.

ip access-list extended INBOUND
  evaluate REFLECTED

Again, we're not limited to just a single evaultate statement in this ACL either, we can add in any other needed statements allowed by a named ACL.

ip acess-list extended INBOUND
  evaluate REFLECTED
  permit any host 10.10.10.10 eq smtp
  permit any host 10.10.10.10 eq http

Now we just need to apply those lists to the outward facing interface of the router.

interface Ethernet 1/0
  ip access-group INBOUND in
  ip access-group OUTBOUND out

If you have multiple outward facing interfaces, you can apply these same ACLs to multiple interfaces and the same REFLECTED dynamic list will be maintained between them, shielding you from the side effects of asymmetric routing.  Now if Cisco would only give us a way to share the state of reflexive ACL's between different routers (one pointed at ISP1 and one pointed at ISP2 for example), then we'd be all set.

interface Ethernet 1/0
  ip access-group INBOUND in
  ip access-group OUTBOUND out
!
interface Ethernet 1/1
  ip access-group INBOUND in
  ip access-group OUTBOUND out

Setting up the 2511 Part 2

There is one more feature of the Cisco access servers that I do not see mentioned very often. Maybe it's been talked to death and I just missed it. But either way, I think is hugely important. That is the ability to telnet through it to the connected devices without ever actually appearing to touch the access server itself. In this post, I'll go over that briefly.

To recap, in the previous post, which can be found here, I set up the 2511 on my network with an address of 192.168.10.10/24 on the Ethernet interface and 192.168.254.1/24 on Loopback0. Connected to line 1 is a 2611 router with no connection to the local network. There is a serial connection between term1 and r1, but I have not really done anything with it.

To prepare for this setup, the local network needs to know how to reach the loopback interface of the terminal server. There are a couple of ways you can do this. You can set up a routing protocol between the terminal server and your home router (we are studying Cisco networking here right? So why not?), you can put a static route into you computer

route add 192.168.254.0 mask 255.255.255.0 192.168.10.10 /p

or you can put a static route into your home router. I have done all three of these at one time or another, and they all work fine. This time around, I elected to put a static route into my SonicWall (counting down the days until I can replace this piece) because it is the simplest way to achieve network connectivity from my entire network. With this static route in place, I can see from the output of a ping to 192.168.254.1 on my computer, it receives a ICMP redirect from the SonicWall, and then the pings are successful.

Now that the loopback on the terminal server is reachable from your PC, lets experiment and see how things work. First, I'll telnet directly into the terminal server as usual, and it still works as expected.

linux1> telnet 192.168.10.10 Trying 192.168.10.10... Connected to 192.168.10.10. Escape character is '^]'. User Access Verification Password: term1>

So what happens when we telnet to the IP address of the loopback interface?

linux1> telnet 192.168.254.1 Trying 192.168.254.1... Connected to 192.168.254.1. Escape character is '^]'. User Access Verification Password: term1>

Again, this is what I expected to happen. So now let's acutally use this terminal server for what it is. Let's telnet into it on a different port and see what happens.

linux1> telnet 192.168.254.1 2001 Trying 192.168.254.1... Connected to 192.168.254.1. Escape character is '^]'. r1>

Notice how this time we essentially connected to the console port of r1. The one thing to take note of is when you hit exit, you are not returned to the command prompt of your host OS, instead, it shows console port behavior.

r1 con0 is now available Press RETURN to get started.

And of course, hitting enter at this point drops you back at the r1> prompt. I'm not quite sure how I feel about this behavior yet, it's going to take a little getting used to.

Setting up the Cisco 2511

Racked up in my lab, I have more routers, switches, firewalls and access points than I care to count.  These devices are all in the basement, which is a place I don't necessarily want to set up shop when I'm labbing due do a number of reasons such as the temperature and the constant hum of the dehumidifier.  So when I'm upstairs, any oopsie that causes loss of connectivity would require another trip down the stairs.

So what to do?  That's where my trusty Cisco 2511 comes in. This device, like many other devices in my rack, was rescued from the recycling pile at work and is becoming one of my favorite items. The only complaint that I have so far is the slow speed of the device. It's a 2500, so everything from the boot time to even just logging in is way slower than a modern router. Since I'll be using a number of these devices shortly, I'm going to set up the 2511 now.

The Cisco 2509/2511/2512 router is what is known as a terminal server. This 2511 that I have has what appear to be two 68 pin SCSI connectors that are used to plug in Cisco's proprietary octal cables. These octal cables give you 8 RJ45 connectors to plug into the console ports of your other devices, making these console ports all accessible from the 2511, and therefore from anywhere that the 2511 can be reached. This would include my laptop while I sit on the couch in my living room, or anywhere else in the house that isn't the basement. The 2509 is the same as the 2511 except for the fact that it only has one 68 pin connector so it can therefore only connect to 8 devices. And then there is the 2509-RJ and 2511-RJ, which do not have the connectors for the octal cables, but instead have RJ45 jacks for use with rollover cables. Finally, there is the 2512, which is the same as a 2511 except for the fact that it has a DB9 Token Ring interface in place of the AUI Ethernet interface. If you don't want to put your faith into something as old as a 2500 series router (they were introduced in 1994 after all), there is also the NM-32A which contains 4 of these connectors and can be used in pretty much any router with an NM port.

So let's get started with the 2511. I've powered up the 2511 and an additional router connected to the first port of the octal cable. The AUI Port has an Ethernet transceiver connected to it ($5 or so on eBay), and this transceiver is connected to my switch with a standard Ethernet cable. This gives me a staggering 10Mbps half-duplex connection over the network. On my octal cables, there is a yellow plastic band near the RJ45 jack with numbers from 1 - 8, indicating which one is which. Since these two octal cables that I have are the only two that I've seen, I cannot confirm whether or not this is standard. The second router, a 2611, doesn't really have any configuration on it except for setting a host name for convenience in identification when it comes time to switch back and forth between the two devices.
The first thing we want to figure out is the line numbers that will be used by the connections. The command show line will give you this information.

term1#show line Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 0 CTY - - - - - 0 0 0/0 - * 1 TTY 9600/9600 - - - - - 1 0 0/0 - 2 TTY 9600/9600 - - - - - 0 0 0/0 - 3 TTY 9600/9600 - - - - - 0 0 0/0 - 4 TTY 9600/9600 - - - - - 0 0 0/0 - 5 TTY 9600/9600 - - - - - 0 0 0/0 - 6 TTY 9600/9600 - - - - - 0 0 0/0 - 7 TTY 9600/9600 - - - - - 0 0 0/0 - 8 TTY 9600/9600 - - - - - 0 0 0/0 - 9 TTY 9600/9600 - - - - - 0 0 0/0 - 10 TTY 9600/9600 - - - - - 0 0 0/0 - 11 TTY 9600/9600 - - - - - 0 0 0/0 - 12 TTY 9600/9600 - - - - - 0 0 0/0 - 13 TTY 9600/9600 - - - - - 0 0 0/0 - 14 TTY 9600/9600 - - - - - 0 0 0/0 - 15 TTY 9600/9600 - - - - - 0 0 0/0 - 16 TTY 9600/9600 - - - - - 0 0 0/0 - 17 AUX 9600/9600 - - - - - 0 1 0/0 - * 18 VTY - - - - - 2 0 0/0 - * 19 VTY - - - - - 1 0 0/0 - 20 VTY - - - - - 0 0 0/0 - 21 VTY - - - - - 0 0 0/0 - 22 VTY - - - - - 0 0 0/0 -

Please excuse the formatting, I'm a networking guy not a web developer.

The TTY lines are what we're looking for here, and you'll see that on my router, they're conveniently numbered 1 - 16. Your mileage may vary if you're using an NM-32A and depending on which NM slot it's installed into. Note that in the column "Uses" you'll see a 1 for the first TTY line rather than a 0 as every other line has. The first TTY line is the one connected to my 2611 router.

Next I'll put a basic configuration on the device. I want it accessable on the network, and easily distinguished from the other router. And since this is my lab and not a production network, I'm looking for convenience rather than security here. Don't forget to set an enable password, otherwise it'll squawk that no password is set when you type enable. The IOS I have installed doesn't support SSH at all, so that will need to be addressed at some point.

Router(config)hostname term1 term1(config)enable secret 123 term1(config)interface Ethernet0 term1(config-if)ip address 192.168.10.10 255.255.255.0 term1(config-if)no keepalive term1(config-if)exit term1(config)line vty 0 4 term1(config-line) exec-timeout 0 0 term1(config-line)password 123 term1(config-line)login

Next, let's configure the the lines for reverse telnet. Cisco says "Reverse Telnet allows you to establish a Telnet connection out on the same device you telnet from, but on a different interface. For more information on Reverse Telnet refer to Managing Telnet Sessions.

term1(config)#line 1 16 term1(config-line)#transport input telnet term1(config-line)#no exec term1(config-line)#exec-timeout 0 0

We'll need a loopback interface with a usable IP address for reverse telnet purposes, and then we'll set up our devices. Starting with port 2001, the port numbers indicate which line that device is connected to. Where you see r1, r2, etc. are just the names I'll be using for these devices, name them as you wish though I highly suggest the names here match the hostnames of the devices. And finally, the IP address of the loopback.

term1(config)#int lo0 term1(config-if) ip add 192.168.254.1 255.255.255.0 term1(config-if) exit term1(config)host r1 2001 192.168.254.1 term1(config)host r2 2002 192.168.254.1 term1(config)host r3 2003 192.168.254.1 term1(config)host r4 2004 192.168.254.1 term1(config)host r5 2005 192.168.254.1 term1(config)host r6 2006 192.168.254.1 term1(config)host sw1 2007 192.168.254.1 term1(config)host sw2 2008 192.168.254.1

Now that this is all set up, we can attempt to connect to r1. Simply type in the host name you've assigned to the device and it should connect momentarily.

term1#r1 Trying r1 (192.168.254.1, 2001)... Open r1>

Note the prompt showing that we are indeed connected to r1. At any time, you can press the escape sequence of Ctrl + Shift + 6 and then X in order to return back to the terminal server.

Once back at the terminal server, you can use the command show sessions to see the open sessions.

term1#show sessions Conn Host Address Byte Idle Conn Name * 1 r1 192.168.254.1 0 0 r1

You can type 1 to return to the open session for r1, or you can type clear line 1 or disconnect session 1 in order to close the session.

term1#clear line 1 [confirm] [OK] term1# [Resuming connection 1 to r1 ... ] [Connection to r1 closed by foreign host] term1#

Also note that besides the otcal cables, the 25xx access server is otherwise a functional 2500 series router, running up to IOS 12.3. The 2511 and 2512 have 2 syncronous serial ports, and the 2509 has one. They support all the same routing protocols and features as any other 2500 series router, so they can pull double duty as a backbone router in your topology. A lot of rack rentals do exactly this. So all in all, a rather useful device.

Should I exceed the 16 devices that I can manage through the 2511 (which I'm sure that I will eventually), I also have a couple Digi PortServer II 16-port terminal servers which I'll probably do a post on in the future.

Building an ACL

The different types of ACLs are first identified by the line number used. Standard IP ACLs use numbers in the range of 1 – 99 and 1300 – 1999. Extended ACLs use numbers in the range 100 - 199 and 2000 – 2699. Other types of ACLs which filter traffic utilizing other protocols such as Appletalk, DECNet, IPX, and XNS use other number ranges, however those are rarely used today. Named ACLs of course do not use numbers, but instead text names as identifiers. Other than ensuring that an ACL number falls into the correct range, the numbers have no meaning and can be used as you see fit.

There are two steps in defining an ACL. First, you enter the series of ACEs that define the ACL. Finally, you apply the ACL to an interface. For a standard ACL, the syntax is as follows:

access-list 10 permit 192.168.1.0 0.0.0.255
access-list 10 permit 192.168.2.0 0.0.0.255
access-list 20 deny 10.0.0.0 0.255.255.255

This simple ACL allows all traffic from hosts with IP addresses in the 192.168.1.0/24 or 192.168.2.0/24 network. The “access-list 10” statement signifies that each of these statements belongs to the ACL designated as 10. An extended ACL looks as such:

access-list 100 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq www

This extended ACL permits tcp traffic originating from the 192.168.1.0/24 network with a destination in the 192.168.2.0/24 network utilizing port 80 (“eq www” means “equals www” or port 80). In addition to ‘eq’ for equals, we can also use “lt” for less than, “gt” for greater than, or “range” to specify a range of ports. To apply an ACL, simply enter the configuration of that interface and specify which ACL as such:

interface Serial0/1
access-group 10 out
line con 0
access-group 15 in

This applies ACL 10 to the Serial0/0 interface, and inspects traffic moving in the outbound direction through that interface. An important thing to note here is that ACLs use wild card masks rather than the more traditional subnet masks used elsewhere when configuring a router. An ACL can be applied to any interface, or to any line (console, aux, or vty).

There are a number of mnemonics used by Cisco IOS to specify ports. You can use the actual port number when configuring the router, however the mnemonic will still be shown in the running configuration and startup configuration. Some mnemonics that you will often see include:

• bootpc
• ftp
• isakmp
• lpd
• ntp
• rip
• ssh
• telnet
• www

or “any” to specify any protocol.

A router can have one ACL per interface, per direction and per protocol. What this means is that each interface may have one ACL in each direction for each protocol that the router supports. For example, in a router that supports IP, IPX and Appletalk, each interface may have an ACL for inbound IP, outbound IP, inbound IPX, outbound IPX, inbound Appletalk, and outbound Appletalk. For a router that supports those three protocols and has 3 interfaces, that router can have 18 active and applied ACLs. An administrator can have as many ACLs defined as memory permits, however only the previously specified 18 may be applied and active.