Packet filtering is used to control the flow of data across a network. By implementing it, you can limit network traffic and restrict network access to certain users or devices. Packet filtering is performed on Cisco routers through the use of access lists. Access lists can be used to control the transmission of packets across an interface, to restrict traffic across virtual terminal lines, or to restrict routing updates. You enter rules to permit or deny packets within each access list, and the access lists are identified by a number. All statements within a single list must have the same number. The number used is up to you, but it has to fall within the ranges listed in Table 9-1, depending on what service you are applying the access list to. The protocols marked with and asterisk (*) are the ones that are discussed in this chapter, and that will be covered on the test.

This chapter explains how to create access lists and how to apply them to interfaces and services.

You already know that in a subnet mask, a mask bit set to 1 means that the corresponding bit in the IP address belongs to the network part of the address. Conversely, the wildcard mask bit set to 1 in an access list means the corresponding bit in the IP address will match either a 1 or a 0. Sometimes you will see these 1 bits referred to as "don’t-care" bits, because the router doesn’t care about them as it tries to make a match. Mask bits set to 0 identify corresponding bits in the IP address that the router must match exactly.

Here are some sample address mask pairs as they might appear in an access list, so you can see how this concept works.

124.220.7.0 0.0.0.255

The last octet of the mask is all ones, so the router will allow any value for these bits. It will try to match the first three octets exactly. This pair identifies all the IP addresses between 124.220.7.0 and 124.220.7.255 as matches for this pair.

193.62.0.0 0.255.255

The last two octets of this mask are all ones, so the router will allow any value in the corresponding bits. That is, the last two octets of the IP address we are matching could be anything, as long as the first two octets are 193.62 exactly. This address mask pair matches every IP address between 193.62.0.0 and 193.62.255.255.

172.16.16.0 0.0.7.255

Not all masks have the boundary between "match-exactly" bits and "don’t-care" bits on the boundary between two octets. This sometimes makes it tough to figure out what matches and what doesn’t. It always helps to work out the binary on these, and if you do enough of them you will get very good at remembering the powers of two! Let’s look at the breakdown, in binary, of just the third octet of the last example.

You can see that if we don’t care about corresponding bits in the address where the mask bits are "ones," then this pair of numbers describes a range of eight possible numbers, 16 through 23. You can prove this by counting up from 16 through 24, in binary, as follows:

= 00010000

= 00010001

= 00010010

= 00010011

= 00010100

= 00010101

= 00010110

= 00010111

= 00011000

Notice that when we get to 24, the 2³ bit in the address changes from a 0 to a 1. The 2³ bit does not fall under the mask, so it is not within the range we are describing with this pair.

Looking at the entire address mask pair, you can see that the full range of IP addresses described is 172.16.16.0 through 172.16.23.255.

The matching process for an access list statement actually has three steps. In packet filtering, we are examining an IP packet header for its IP addresses in order to make a match. Let’s say our access list statement contains the address mask pair 172.16.0.0 0.0.255.255. A packet comes in with source IP address of 172.16.10.22. The router does the following:

1. Performs a "logical OR" against the address and mask in the access list statement. This means that any bit with a 1 in either the address or the mask will be a 1 in the result. The result of this operation is 172.16.255.255.
2. Performs a "logical OR" against the IP address in the packet header and the mask in the access list statement. The result is 172.16.255.255.
3. Subtracts the two results. If the two results are identical, the result of the subtraction is exactly zero, and we have a match, as we have in this example. If the result of the subtraction is not zero, there is no match and we go on and repeat these steps for the address mask pair in the next statement.

There are two keywords that can be used to save us some typing with the IP access list address mask pairs. The first is "any," which can be used in place of the address mask pair 0.0.0.0 255.255.255.255. As you can see from the address mask pair, this combination allows any combination of address bits to match. The other keyword is "host," which can be used in extended access lists only, to replace the 0.0.0.0 mask. In a standard access list, omitting the 0.0.0.0 mask is the same as specifying it. If you omit the mask, the address will be considered a host address.

All access lists are defined in global configuration mode. The basic format for adding a standard access list is as follows:

Access-list access-list-number {deny|permit} {source[source-wildcard]|any}

The access-list-number is a number within a specific range that signifies which list the command you are entering is to join. You then stipulate whether the entry permits or denies traffic from the specified address. SOURCE is just as it sounds, dictating the source IP address the access list rule applies to. If you add a subnet address you can change the source address from a specific host to a range of IP addresses. The source-wildcard basically identifies which bits in the address field are matched. If you add the argument ANY at the end, you are implying the addresses 0.0.0.0 with a subnet mask of 255.255.255.255, which of course matches any addresses. Here is an example of a standard IP access list that might be found in a network such as that depicted in Figure 9-1:

If we wanted to use an inbound packet filter on the interface to network 10.10.10.0, we could use the command ip access-group 101 in.

From this example we see that because of the explicit acceptance of Workstation 1, it is allowed to pass to Server A. The second server, however, falls under the next statement, where any system on the 10.10.10.0 network is denied. At first it would seem that Workstation 1 would fall under this rule also. This would be the case if the DENY statement were listed first. Remember, in IP access lists, the order of listing is very important.

After an access list is created, any additions to that list number are placed at the end. Unfortunately, what this means is that you can’t selectively add or remove items. The only removing that can be done is to remove the entire access list, which can obviously be a nuisance if you have extensive lists. To save time, you can cut and paste the list to a text document for editing.

Most of the arguments are self-explanatory. The access-list-number is the previously created access list number you want to apply. The in|out options specify whether this rule applies inbound or outbound. If you wish for the access list to apply in both directions, two statements need to be added, one for in and one for out. You can apply only one access list per protocol per interface per direction.

You can also set up access lists to restrict traffic on virtual terminal lines. This is accomplished with the access-class command:

Access-class access-list-number {in | out}

The following example of this shows that only those hosts in the 10.10.10.0 subnet are allowed to establish a connection with the router’s terminal port.

Config terminal

Access-list 1 permit 10.10.10.0 0.0.0.255

Access-class 1 in

When you’re planning an access list there are two different ways you can approach it. If you know exactly what traffic you want to permit, and can describe that traffic in only a few statements, you can permit that traffic explicitly and deny everything else. Conversely, if you can describe what you want to deny with only a few statements, you might want to explicitly deny that traffic and end the list with a PERMIT ANY. Neither method is more correct than any other, but the list with fewer statements will use fewer CPU cycles in your router.

Speaking of performance, you will want to have a look at your list after it has been in place for a few days to see if it needs tuning. Remember that the router stops processing the list with the first statement that matches a packet. That means that you will get better performance if the bulk of your traffic matches statements near the top of the list. Your router will keep track of how many packets match against each statement in the list, and you can often use this information to rearrange the statements so the ones with the most matches are at, or near, the top. Be careful, though, to keep more specific statements higher in the list than more general ones pertaining to the same networks or subnets.

Be careful when you create access lists on routers in a production network. If you have applied your list as a traffic filter on an interface before you start to configure the list statements, remember that the implicit DENY ANY takes effect as soon as you enter the first statement into the router’s configuration. It’s a better idea to get the statements configured, check them several times for sanity, then apply the list on the interface.

You can use the same list on any number of interfaces. If your router has 20 different interfaces, all of which require the same restrictions, re-use the same list as a traffic filter on all those interfaces.

And here’s a pitch for documentation. In the place where you keep the documentation for your network, document each list, statement by statement, telling exactly what each statement is intended to do. This exercise serves two purposes. If you can describe your list in this way, it is an indication that you have thought it through carefully. And, since most of us have enough to remember already, it will save your sanity some day by preventing your having to figure out why you are denying traffic from this particular network.

And remember the implicit DENY ANY!

Extended IP access lists allow you to control traffic at a more granular level. Extended IP uses both the source and destination address when it tries to match up packets to your list, and you can optionally use protocol type information for even finer control.

A lot of the rules you learned from standard IP are the same in Extended IP. A few of them are as follows:

• You cannot selectively add or remove from a list. Whenever you add an entry, it is placed at the bottom.
• The access list itself does not do anything. You must apply it to an interface for it to be used.
• At the end of the list, by default, there is an implicit DENY ALL statement.

Let’s break this command down. You first enter the access-list command, then the number of the list, followed by whether you want to permit or deny the specified traffic. You then need to specify what type of protocol you are going to be using, such as TCP, UDP, ICMP, or IP. You then tell the router the specific source and destination, or give it a wildcard such as any.

Here is an example of how you might use an extended IP access list. Figure 9-2 shows a network where we want to limit certain kinds of IP traffic.

He applies this access list as a traffic filter outbound on Ethernet 0 using the ip access-group command:

This list is extremely restrictive. The only traffic permitted on 172.17.1.0 is Telnet traffic from network 172.16.1.0, FTP traffic from network 172.16.2.0 destined for the host 172.17.1.1, and ICMP traffic to any destination. All other traffic is denied explicitly. If the deny ip any any line had not been configured, the list would operate in the same way, as any traffic that is not explicitly permitted is denied by implication. Notice the keywords for the IP protocols, and for the TCP applications Telnet and FTP.

Notice that with the list applied as a filter on Router 2’s Ethernet 0 interface, hosts on networks 172.16.1.0 and 172.16.2.0 can still access other networks through Router 1’s serial 1 interface. Consider the different effect if the same list were configured on Router 1 and applied using the ip access-group 102 out command on Router 1’s serial 0 interface. With this new configuration in place, hosts on networks 172.16.1.0 and 172.16.2.0 are only allowed to send ICMP traffic (ping, most likely) to other networks, as well as the previous allowances for Telnet and FTP traffic to host 172.17.1.1.

With the advent of IOS release 11.2, you can also use Named Access Lists. Since it is new in version 11.2, it is not backward compatible with older releases. With Named lists you can identify IP access lists, whether standard or extended, with an alphanumeric name instead of a number. This allows you to exceed the previous limit of 99 for standard and 100 for extended. You should not, however, assume that all access lists that use a number can also use a name. If you choose to use this method the mode and command syntax is a little different.

To use this type of access list, you first enter a command that puts you in a mode to enter named access lists: Ip access-list standard name or IP access-list exteneded name.

You then enter your commands as follows: {deny | permit} protocol source source-wildcard destination destination-wildcard.

You then exit the access list configuration mode by simply typing in Exit. One final thing to note is that, as of now, only packet and route filters can use a named list.

Once you have configured your IP access lists you will want to see if they are configured correctly. You can verify your IP access lists with the show access-lists command and the show IP interfaces command.

Router1#show access-lists

IPX access list 800

deny C011

permit FFFFFFFF

IPX access list 900

permit any

permit any any all AA11.00cf.b200.0000 0000.00ff.ffff all

permit any BB22 all AA11

IPX SAP access list 1009

deny FFFFFFFF 0 parallel

permit FFFFFFFF

deny 12.1.0.0, wildcard bits 0.0.255.255

permit any

deny 13.0.0.0, wildcard bits 0.255.255.255

permit 172.16.0.0, wildcard bits 0.0.255.255

permit ospf any any (452 matches)

permit icmp any any echo (63 matches)

permit icmp any any echo-reply (10 matches)

permit tcp any any eq ftp

permit tcp any any eq telnet (958 matches)

permit ospf any any (12 matches)

permit ip 136.25.16.0 0.0.7.255 any

permit tcp host 10.1.0.1 any

permit ospf any any

deny tcp any any eq telnet

permit ip any any

Router1#

We can see that show access-lists displays the configuration details for all sorts of access lists in the router, not just IP access lists. We could have specified an access list number on the command line to see an individual list in isolation from all others.

We can see the configurations of various IP access lists. List 40 is a standard IP access list, denying any packets from subnet 12.1.0.0, and permitting all others. List 130 is an Extended IP access list. We can see the various protocol keywords permitting any OSPF packets, any ping packets, any FTP packets, and any Telnet packets.

What is being denied here in list 130? Every other IP packet! Remember the implicit DENY ANY. This is an IP extended access list, not just TCP or ICMP. The DENY ANY applies to all of IP.

Notice the notations in parentheses, indicating matches for each line. The router keeps track of the number of times packets have come across the interface matching each of the IP access list statements. Here’s what we can see from the output for IP access list 130:

• 452 OSPF packets have been received on this interface since we applied this access list against the interface
• 63 responses to pings (responses to a neighboring router’s pings, since this list was applied as an input packet filter)
• 10 pings originated in this router
• 958 Telnet packets have come into this interface

We can also see three named IP access lists, list2 and list3. List1 is a standard IP access list. List2 has been applied, and has some matches. List3 has been defined in the router configuration, and has not been applied to any interface, so it is not being used for packet filtering. There are no matches against list3.

Show IP interfaces provides information on IP-specific aspects of your interface configuration. In this context, it is used specifically to see what packet filters are applied on the interface. It does not show the contents of the list, only the list number. You need to use show access-list <number> to see the filtering rules for the list. Packet filters are indicated in the lines "Inbound access list is" and "Outgoing access-list is." Here we see that we have applied list 130, an IP extended access list, as a packet filter inbound on interface serial 1.

Router1#show ip interface serial 1Serial1 is up, line protocol is up Internet address is 10.1.0.2/16 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes

Helper address is not set

Directed broadcast forwarding is enabled

Multicast reserved groups joined: 224.0.0.5 224.0.0.6

Proxy ARP is enabled

Security level is default

Split horizon is enabled

ICMP redirects are always sent

ICMP unreachables are always sent

ICMP mask replies are never sent

IP fast switching is enabled

IP fast switching on the same interface is enabled

IP multicast fast switching is enabled

Router Discovery is disabled

IP output packet accounting is disabled

IP access violation accounting is disabled

TCP/IP header compression is disabled

Probe proxy name replies are disabled

Gateway Discovery is disabled

Policy routing is disabled

Network address translation is disabled

You can break down IPX access list types into five main categories, as described in Table 9-2.

We will be concerning ourselves with standard access lists in this section and SAP’s version of access lists, better known as filters, in the next.

Standard access lists permit or deny traffic based on the source network number. You can also restrict by optionally specifying a destination address, and even by applying address masks on both. The access list number for Standard IPX can be anything between 800 and 899.

Access-list access-list-number {deny|permit} source-network[options]

The source-network variable is the eight-digit hexadecimal address, ranging from 1 to FFFFFFFD, of the network where the packet originated. You can also use 0 for the local network and –1 to specify all networks. Notice how I said it had to be an eight-digit hex number, yet I listed 1 as a valid entry. This is because leading zeros do not need to be stated => 1 equals 00000001.

Look at the example in Figure 9-3. Let’s say we want to stop the users on Network AA from using the services on Network BB, but we want the users on BB to be able to use the services on AA. If we apply an access list as a packet filter outbound on Ethernet 1, we can block the packets from Network AA. We do not, however, need an access list on Ethernet 0, since the lack of an access list implies PERMIT ALL. If we filter with a standard access list using only a network number, we would also filter out the response packets coming from servers on Network AA to the users on BB. In order to filter packets requesting services, and not filter responses coming back to users, we will need to know the node address of the server’s services. Let’s see how this would work:

Access-list 850 deny aa bb.072c.fa34.0075

Access-list 850 permit –1

We apply this list using the ipx access-group command as a packet filter on Ethernet 1.

The effect of this list is that all packets from Network AA destined for Server B will be blocked when they are forwarded to Router A’s Ethernet 1 interface. The response packets coming back from Server A to the users on Network BB will be permitted by the last statement. PERMIT –1 is the same in the IPX world as PERMIT ANY is in the world of IP.

If we want to configure a SAP filter for Router1 that would filter Server A’s advertisements, but allow advertisements from the other servers on the segment, we would enter the following commands, in global configuration mode:

Access-list 1001 deny 1a01.0000.0000.0001

Access-list 1001 permit –1

The first statement denies all services originating from IPX address 1a01.0000.0000.0001. In a real Novell network, the node address 0000.0000.0001 always refers to the internal IPX network number of a NetWare server, and this is the address for all of the server’s services. So the effect of this statement is to deny all services from the server whose internal IPX network number is 1a01. The second statement permits all other services. The –1 is the way to specify "all networks" in an IPX access list.

We can use this access list in one of two ways. If we don’t want Server A’s service entries accepted into Router1’s SAP table at all, we can apply the list as an input SAP filter using the command ipx input-sap-filter 1001 in interface configuration mode for Ethernet 0.

The number 1001, of course, refers to the list number of access list 1001. This command will cause Router 1 to examine all SAP packets it receives on its Ethernet 0 interface, and filter out only the entries whose service addresses specify 1a01.0000.0000.0001. Note that the router is examining the individual entries inside the SAP packet to find this address, not the source address in the SAP packet’s IPX header.

The second way to use this list is as an output SAP filter. Suppose we wanted the services from network 1a01 to be advertised on network 2a but not on network 3a. If we used an input SAP filter on Ethernet 0, we would block the advertisements altogether. But if we put an output SAP filter on Ethernet 1, we can cause the router to filter out the SAP entries with service addresses of 1a01.0000.0000.0001 as it constructs the SAP packets it will broadcast on that interface. The command we need to configure an output sap filter is ipx output-sap-filter 1001. This command, like the input-sap-filter, is an interface configuration command.

There are two other options available for filtering in the SAP access list. We can filter by service type and also by service name. If we wanted to filter Server A’s services by name, we could construct a statement like access-list 1001 deny –1 0 ServerA.

Again, "-1" means any network, "0" means all service types. Even though we are specifying ANY and ALL, these arguments are necessary to preserve the syntax of the statement. SERVERA, of course, is the string that the router will match when examining SAP entries for filtering. These strings are case sensitive, so always check the output of show ipx servers to see exactly how you need to configure this string.

Suppose we wanted to filter only file services, type 4, from Server A. There are two ways to do it. The first is to specify the internal IPX network number with service type 4: access-list 1001 deny 1a01 4.

1A01 is the IPX internal network number for Server A, the network address of its services. We didn’t really need the node address; if we are referring to the internal IPX network number, the node will always be 0000.0000.0001, and there are no other nodes on that network, so we could leave it out. "4" represents type 4 services. So only Server A’s file services will be denied.

We could also use the string SERVERA to filter type 4 services from Server A: access-list 1001 deny –1 4 ServerA.

We are specifying any network (-1), but instead of all services, this time we specify type 4, along with the character string SERVERA. Don’t forget: all access lists have an implicit DENY ANY at the end, so if you don’t permit some services in another statement in this list, all SAPs will be filtered out.

As was just stated, the local servers should be the first to respond. If this does not occur on your Novell IPX network, you can configure a GNS delay. The delay is measured in milliseconds, with the default being 0 (No Delay): Ipx gns-response-delay milliseconds.

If you wish to view the list of IPX servers on your network that have been discovered through SAP you would issue the command Show ipx servers {unsorted} | {sorted [name | net | type]} {regexp name}. By default, the output displayed will be listed numerically by SAP service type.

You can change this default with the optional UNSORTED and SORTED arguments listed above. UNSORTED does just as it says; it displays the IPX servers without any form of sorting. SORTED allows you to sort by server name (NAME), by network number (NET), or by the default SAP service type (TYPE). The regexp name allows you to display only IPX servers that match the name or expression you list.

Here is a sample output of show IPX servers.

east#show ipx serversCodes: S - Static, P - Periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail10 Total IPX ServersTable ordering is based on routing and server info

Type Name Net Address Port Route Hops Itf

S 4 EAST-D04 B00D.0000.0000.0001:0451 conn 2 Lo13

S 4 EAST-F04 B00F.0000.0000.0001:0451 conn 2 Lo15

P 4 DABNEY BBBB0002.0000.0000.0001:0451 2/01 1 Et0.2

P 4 DESTINY AAAA0001.0000.0000.0001:0451 2/01 1 Et0.2

N 4 WEST-D04 C00D.0000.0000.0001:0451 82/02 4 Se0

N 4 WEST-F04 C00F.0000.0000.0001:0451 82/02 4 Se0

P 47 PRINTSRV BBBB0002.0000.0000.0001:8060 2/01 2 Et0.2

P 107 DABNEY BBBB0002.0000.0000.0001:8104 2/01 2 Et0.2

P 26B UNIVERSE_1___________ AAAA0001.0000.0000.0001:0005 2/01 1 Et0.2

P 278 UNIVERSE_1___________ AAAA0001.0000.0000.0001:4006 2/01 1 Et0.2

Servers are displayed in numeric order by service type. Type 4 is file service, which is required for logon (known as "general service" in Novell terms). These are the servers that will be used in GNS responses by the router.

The "net.address" columns are where you would look if you wanted to construct a SAP filter for these services based on their address. Notice that the addresses are all 0000.0000.0001. This is because services are advertised with an address of the internal IPX network number of the server, not the physical address of the NIC on the wire. This internal IPX network number is the one you must filter on for your SAP filters to operate properly. You can see which services are located on which physical server by matching up their internal IPX network numbers.

Show IPX interfaces allows you to view all the various types of filters that can be set for IPX packets, routes, routers, SAPs and NetBIOS packets. The Cisco IOS is rich in commands that help you to manage IPX traffic on your network, and all these parameters are configurable.

east#show ipx interface ethernet 0.2

Ethernet0.2 is up, line protocol is up

IPX address is D.0000.0c47.6643, NOVELL-ETHER [up]

Delay of this IPX network, in ticks is 1 throughput 0 link delay 0

IPXWAN processing not enabled on this interface.

IPX SAP update interval is 1 minute

IPX type 20 propagation packet forwarding is disabled

Outgoing access list is not set

IPX helper access list is not set

SAP GNS processing disabled, delay 500 ms, output filter list is 1000

SAP Input filter list is not set

SAP Router filter list is not set

Input filter list is not set

Output filter list is not set

Router filter list is not set

Netbios Input host access list is not set

Netbios Input bytes access list is not set

Netbios Output host access list is not set

Netbios Output bytes access list is not set

Updates each 60 seconds, aging multiples RIP: 3 SAP: 3

SAP interpacket delay is 55 ms, maximum size is 480 bytes

RIP interpacket delay is 55 ms, maximum size is 432 bytes

IPX accounting is disabled

IPX fast switching is configured (enabled)

RIP packets received 294, RIP packets sent 152

SAP packets received 295, SAP packets sent 150

Notice the lines in boldface. "Incoming access list is 800" indicates a packet filter applied inbound to the router with the ipx access-group 800 in command. "SAP Output filter list is 1013" indicates that access list 1013 has been applied as an output SAP filter with the ipx output-sap-filter 1013 command.

Show access-lists will show all access lists, not just IP or IPX. In the following example, we have both IPX and IP access lists configured in the router. If you want to view a specific IPX access list in isolation, use the list number as an argument for the command.

Router1#sh access-listsIPX access list 800 deny C011 permit FFFFFFFFIPX access list 900 permit any permit any any all AA11.00cf.b200.0000 0000.00ff.ffff all permit any BB22 all AA11IPX SAP access list 1000

deny B00F 47

permit FFFFFFFF

IPX SAP access list 1009

deny FFFFFFFF 0 parallel

permit FFFFFFFF

IPX SAP access list 1013 deny C000.0000.0000.0000 F.ffff.ffff.ffff deny FFFFFFFF 47 E* permit FFFFFFFF

Standard IP access list 40

deny 12.1.0.0, wildcard bits 0.0.255.255

permit any

To set up an access list, you enter the following command when in configuration mode: ACCESS-LIST access-list-number {DENY | PERMIT} options.

The access-list-number is a number from 600 to 699, which is used to reference the list you are adding to or creating. PERMIT and DENY either allow or disallow the type of traffic specified.

To create an access list based upon zones, you would enter the following command in the configuration mode: ACCESS-LIST access-list-number {PERMIT | DENY} ZONE zonename.

You can define an access list for a specific NBP entity, such as a particular application, for a class of NBP entities like all printers, or for NBP entities that belong to a specific zone. To establish an access list for NBP named entity, use the following syntax while in configuration mode: ACCESS-LIST access-list-number {PERMIT | DENY} NBP seq {type|object|zone}STRING.

The seq argument references the sequence number, which allows you to associate two or three portions of an NBP name. Even if you aren’t going to associate portions to the name, you are still required to enter a sequence number here. This allows you to deny or permit packets down to the entity level. The sequence number can also allow you to keep track of the number of NBP entries you have made in your access list. STRING identifies the type, object, or zone of the entity named. The same two allowances for Macintosh characters and for having the lead character be a space apply here. You can do either with the same solutions listed earlier. Here is an example of forwarding all packets except those coming from the zone sales or from servers of type AFPServer.

Access-list 601 deny nbp 1 zone sales

Access-list 601 deny nbp 1 type AFPServer

Access-list 601 permit other-nbps

Access-list 601 permit other-access

Access-list 601 permit network 10

Access-list 601 deny network 10

If this example were entered in a router, a SHOW RUN command would only list the statements as Access-list 601 deny network 10.

If you have a multiple zone network, and you wish to deny access only to a few, you can explicitly define the ones to deny and apply the permit other-access at the end. If you wanted to permit access to all zones expect for Sales and Accounting, you could enter the following configuration:

Access-list 601 deny zone sales

Access-list 601 deny zone accounting

Access-list 601 permit additional-zones

You can configure IP-style access lists for both networks and cable ranges. To define an access list for a non-extended single network, enter the following command in configuration mode: ACCESS-LIST access-list-number {PERMIT | DENY} NETWORK network.

For example, if you have two networks, and you want to deny packets from network 1 but permit packets from network 2, you would enter the following access list.

Access-list 601 deny network 1

Access-list 601 permit network 2

If you want to set up an access list for a cable range in an extended network, you would enter the following command in configuration mode: ACCESS-LIST access-list-number {PERMIT | DENY} CABLE-RANGE cable-range.

For example, if you wanted to forward all packets from cable range 200 – 250, but deny packets from cable range 300 – 350, you would enter the following:

Access-list 601 permit cable-range 200 – 250

Access-list 601 deny cable-range 300 – 350

Cisco IOS provides the functionality to define an AppleTalk access list for an extended or a non-extended network that is completely contained within a specific cable-range:

ACCESS-LIST6 access-list-number {PERMIT | DENY} WITHIN cable-range

The following example allows access to any network or cable range that is completely included in the range of 200 – 250:

Access-list 601 permit within 200 – 250

You can change WITHIN to INCLUDES to allow more flexibility for overlapping networks—in the following example, for any network that overlaps any part of networks 200 – 250.

Access-list 601 permit includes 200 – 250

You can also permit or deny access for either extended or non-extended networks that overlap across a cable range or a range of network numbers:

ACCESS-LIST access-list-number {PERMIT | DENY} INCLUDES cable-range

Start Q&A

ACCESS-LIST access-list-number {DENY | PERMIT} {SOURCE[source-wildcard]|ANY}

IPX access lists permit or deny traffic based on either specified network nodes or messages sent using particular protocols and services. Just as in IP access lists, the order of rules applied in the access list is critical. The first matching entry, whether it is a PERMIT or a DENY, is followed. And also like IP lists, if you do not explicitly enter a PERMIT EVERYTHING at the end, an implicit DENY ALL is made. The syntax for a basic IPX access list is as follows:

ACCESS-LIST access-list-number {DENY | PERMIT} SOURCE-NETWORK[OPTIONS]

All servers on a NetWare type network can dynamically advertise their services and addresses using the Service Advertisement Protocol (SAP). The other components on a network besides the remainder servers, such as routers, keep a complete list of the services available across the network. These service advertisements synchronize the list of available services. You can deny SAP-type traffic with the command Access-list 1001 deny 1a01.0000.0000.0001.

AppleTalk access lists can be broken down into two basic types: AppleTalk-style and IP-style. AppleTalk-style access lists are based on AppleTalk zones and NBP named entities. NBP is what maps network names to AppleTalk addresses. It allows you to control network access at the network entity level. You can use these mapped names to permit or deny NBP packets from a specific NBP entity, or from all NBP entities within a given area. An NBP entity is also known as an NBP tuple. The correct syntax for establishing an AppleTalk access list is:

ACCESS-LIST access-list-number {DENY | PERMIT} options

• Packet filtering is performed on Cisco routers through the use of access lists. Access lists can be used to control the transmission of packets across an interface, to restrict traffic across virtual terminal lines, or to restrict routing updates.
• An IP access list is a collection of permit and deny rules that are applied to IP addresses.
• Cisco IOS Release 11.1 introduced significant changes in the syntax and implementation of access lists.
• There are three basic types of IP access lists: standard, extended, and dynamic extended.
• The basic format for adding a standard access list is:
• Access-list access-list-number {deny|permit} {source[source-wildcard]|any}
• Extended IP uses both the source and destination address when it tries to match up packets to your list, and you can optionally use protocol type information for even finer control.
• The syntax for adding and removing access lists is:
• {NO} access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard
• With Named lists you can identify IP access lists, whether standard or extended, with an alphanumeric name instead of a number.
• You can verify your IP access lists with the show access-lists command and the show IP interfaces command.
• IPX access lists permit or deny traffic across interfaces based on either specified network nodes or messages sent using particular protocols and services.
• All servers on a NetWare-type network can dynamically advertise their services and addresses using the Service Advertising Protocol (SAP).
• Show IPX interfaces allows you to view all the various types of filters that can be set for IPX packets, routes, routers, SAPs and NetBIOS packets.
• Show access-lists will show all access lists, not just IP or IPX.
• Access lists for AppleTalk networks are basically like IP and IPX lists.
• AppleTalk access lists can be broken down into two basic types: AppleTalk-style and IP-style.

1. Even though the statement explicitly refers to TCP and Telnet traffic, the implicit DENY ALL applies to all IP traffic.