SENSS Passed

Just a short post for this week, as I've done recently.  This exam has completely consumed my time lately.  Because I had yesterday off, I scheduled my second attempt at the SENSS and nailed it this time with a score of 910.  Exams are a lot easier when you know what you need to know, aren't they?  This isn't a knock against Cisco's exam topics, I just didn't have a good idea of just how deep I needed to know certain things that didn't seem like they'd be covered as heavily which lead me to spend a lot of time on things that weren't really covered very much.  It was my first failed Cisco exam, and quite a humbling experience. Either way now I have a much better idea idea of what I need to do moving forward in the CCNP Security.

Next up, I don't know yet.  I plan to take a couple days to recover from that experience and give some thought to which exam I want to tackle next.  While the SIMOS looks like it'll be a lot more fun as it's very heavy in cryptography and VPNs, the SISAS may be more practical as ISE reared it's head multiple times already in the SENSS, and I doubt it won't be in the other exams as well. Besides that, the SISAS is the only exam with a certification guide, so getting to see a little bit of structure in exam preparation may be of use.

Either way, it's not going to be the SITCS this time.  There's no way I'll be able to knock out v1.0 before December 16, and I'd prefer to wait a little bit and let the community hash out exactly what v1.5 is before attempting it.  There was a lot of butt-hurt early on for all 4 of these exams from the early attempts and I'd hate to join the ranks.

Also in the near future will be the CISSP, which is the capstone of my Masters Degree, and the Upgrading Your Skills to MCSA Windows Server 2016 exam.  I haven't decided when I'll mix those two in yet either.  So for now I'll just be kicking the tires on Server 2016 and starting to tinker with ISE.  I've got a few SENSS related posts still in very rough form, so I'll probably get those presentable and post them here and there as well.

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.

FreeCCNAWorkbook.com in Packet Tracer, Part 3

In two previous blog posts, which can be found here and here, I started going through the labs on the Free CCNA Workbook website and attempting to perform the labs in Packet Tracer.  My focus lately has been more on my own studies with my first attempt at the SENSS exam scheduled for next month, but with Cisco finally releasing Packet Tracer to the world (you no longer need to be a Cisco Network Academy student to legally download a copy), I've been wanting to revisit this topic.  So in this post I'm going to move on to Section 5, Configuring Wide Area Network Links.

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.

TCL Scripting

According to it's man page, "tclsh is a shell-like application that reads TCL commands from its standard input or from a file and evaluates them. If invoked with no arguments then it runs interactively, reading TCL commands from standard input and printing command results and error messages to standard output. It runs until the exit command is invoked or until it reaches end-of-file on its standard input."  The TCL Developer Xchange describes the TCL language as  "a very powerful but easy to learn dynamic programming language, suitable for a very wide range of uses, including web and desktop applications, networking, administration, testing and many more. Open source and business-friendly, TCL is a mature yet evolving language that is truly cross platform, easily deployed and highly extensible. "

The language was created John Ousterhout at the University of California, Berkley.  It's either installed by default or available through the package repositories in nearly every Linux distribution and flavor of BSD.  ActiveState maintains an edition called ActiveTcl.  The community edition has precompiled binaries for Windows, Mac and Linux.  The Enterprise Edition adds binaries for HP-UX, Solaris and AIX.  ActiveState also the home of ActivePerl and ActivePython, which are solid editions of Perl and Python for the same platforms.

Tclsh was added to Cisco IOS in version 12.3(2)T and 12.2(25)S, and to Cisco NX-OS in Release 5.1(1) to provide scripting capability.  With it, you are able to run TCL commands directly from the Cisco IOS prompt, or to create and execute scripts written in the TCL language.  Just about anything you can do in tclsh on a Linux or BSD system can be done in tclsh on a Cisco router.  This of course assumes you're using straight TCL and not any add-on packages.

To use tclsh, simply type the command tclsh at the exec prompt.  To exit tclsh, type tclquit.  While within tclsh you can create scripts with the proc command, by typing proc script_name {, and then ending your script with a closing }.  A great example of the power of this scripting environment can be found in this post at INE, where Brian McGahan, along with an assist from reader Jason Cook, demonstrates a TCL script to generate a number of random IP addresses and subnet masks tied to Loopback interfaces.  I've used this script several times in the lab to quickly add routes into a routing protocol.  If you're feeling really adventurous, you can even get your router to Tweet.  And that's the beauty of scripting, you are able to quickly and easily automate the mundane tasks that aren't what you are working on and interested in, but still need accomplished.

And though it is not suggested, you can change your login shell on a Linux, BSD or Unix system to tclsh and do your day to day work in it as a means of learning the language and environment.  However, as noted, its not suggested as it's not really suited as being used a login script wasn't in the design goals.  See this article for more details.

I'll be getting more into TCL on IOS in the near future.

Some Good References to Get Started:

The official reference from Cisco:
Cisco IOS Scripting with TCL Command

The Cisco book:
Tcl Scripting for Cisco IOS

Some books that come recommended by the TCL Developer Exchange:

Practical Programming in Tcl and Tk, 4th ed.
Tcl/Tk, Second Edition: A Developer's Guide
Tcl and the Tk Toolkit, 2nd ed.
Tcl/Tk 8.5 Programming Cookbook

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

Shortening ACLs

There are two main ways of shortening ACLs and improving their readability or performance. As you know, ACLs can grow to include hundreds of ACEs and cover many pages when printed.  So any way of minimizing the number of ACEs present may be welcomed.   A shorter ACL will consume less flash memory in the form of the startup configuration, less RAM in the form of the running configuration, and less CPU utilization when a packet is eligible to be analyzed by the ACL.

The first method of shortening an ACL is by using CIDR to combine multiple ACEs into a single statement. This method is useful when combining multiple ACEs specifying networks. For example, if you have two statements in an ACL which allow 10.0.0.0/8 and 11.0.0.0/8 as such:

     access-list 1 permit 10.0.0.0 0.255.255.255
     access-list 1 permit 11.0.0.0 0.255.255.255

These two statements can be combined into the single statement 10.0.0.0/7 as such:

     access-list 1 permit 10.0.0.0 1.255.255.255

Anyone who has worked with routers and routing protocols will recognize this method as summarization.  In a properly designed network, multiple networks can be combined, or summarized, into a smaller number of networks for use in ACLs and other purposes such as routing protocols/routing tables. You ultimately strive to be able to summarize down to one network wherever you can.

The second method of reducing the size of ACLs falls into the category of what I would call stupid router tricks. It is accomplished by utilizing binary math to combine two statements into one. This method is useful when combining ACEs that specify individual hosts.  To use this method, first convert the two host addresses into binary.   Second, do a bitwise AND of these two binary numbers. The result of this AND operation will be used and the address of the combined ACE. Next, do a bitwise XOR of the original two binary numbers. This output of this operation will be used as the wildcard mask of the new combined ACE. For example, if an ACL contained the following statements:

     access-list 10 deny host 10.20.30.40
     access-list 10 deny host 40.30.20.10

The result of this operation would yield

     access-list 10 deny 8.20.20.8 34.0.10.34

While this operation results in ACLs whose meaning is not clear, reducing the number of deny or permit statements in half definitely helps in a routers memory, flash, and CPU utilization. 

Would you be interested in a long ACL with dozens of cryptic statements such as the above?

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.

ASA Liscense Woes

This evening I was tasked with installing a PAK on an ASA 5512-X for a client.  Sales forwarded me the eDelivery Order Notification without event, I grabbed the serial number from the output of the "show version" command, and with a click on "Register Claim Certificates (PAKs)" within the email.  I already had this handy guide from one of my favorite blogs loaded up in my browser and figured I would be done in no time.

So where does the woe come in?  On the Cisco licensing page.  After clicking the link and then logging into the Cisco site, I was brought to the licensing page.  I selected the only outstanding item showing (the recently purchased license upgrade for the 5512-X), and clicked Proceed.  On the next page, it asked for the serial number of the unit.  As I had that handy already, I copied it and pasted it into the box.  Proceed remained grayed out.

After rereading the email, the output of show version and Pete's guide a couple more times, I was starting to think maybe the client would have to log in and enter everything into the licensing page under their account. So I tried one more thing before throwing in the towel for the night.  After clicking towards the end of the serial number box to ensure there were no stray spaces at the end, I hit enter for no particular reason. And wouldn't you know, the Proceed button became available, and after one more page, Cisco emailed me the new PAK which the firewall took with no problem.

I still can't complain as the entire process took me about 20 minutes, although well over half of it was spent wondering why the Proceed button was still grayed out.  Moral of the story: if you want me to press enter after I'm done entering something into the box, say so.

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.