This chapter covers the following topics that you will need to master as a CCNA:

•

This section covers the concepts and configuration needed to

filter IP traffic. Both standard and extended access-lists, as well as numbered and

named access-lists, are included.

•

IPX filtering can be used to filter packets as well

as SAP updates. This section covers configuration of both and concentrates on the

advantages gained by using SAP filtering.

When deciding on the name of this chapter, the first title chosen was “Understanding

Network Security.” Then I thought to myself (that’s what you do when you spend weeks on

end in your home office writing), “You could easily write a whole book just on this topic!”

So, I changed the title to better reflect the scope of this topic in this book, which of course

reflects Cisco’s expectations of CCNA candidates.

(By the way, someone already wrote the book I imagined—it’s called

, by Merike Kaeo, ISBN: 1-57870-043-4.)

Cisco expects CCNAs to understand security from the perspective of filtering traffic using

access-lists. Cisco also expects CCNAs to master the ideas and configuration behind the

Telnet, auxiliary, console, and enable passwords as well; these topics are covered in Chapter

2, “Cisco Internetwork Operating System (IOS) Fundamentals.”

The reason that access lists are so important to CCNA candidates is that practically every

network uses them; to do more than basic filtering, access lists can be very tricky. In fact,

back in 1993, when I was getting certified to teach Cisco classes, the Cisco Worldwide

Training folks said that the TAC’s most frequent question topic area was how to configure

access lists. Access lists are likely to remain a core-competency issue for router support

personnel for a long time. Also, several other IOS features call on access list logic to

perform packet-matching features.

When studying about access lists in this book or others, keep in mind that there are usually

many ways to configure an access list to achieve the same result. Focus on the syntax of the

commands and the nuances of the logic. If a particular example (given a set of criteria) is

configured differently than you would have configured it, do not be concerned. In this book,

I have attempted to point out in the text when a particular list could have been written a

different way.

By taking the following steps, you can make better use of your study time:

•

Keep your notes and the answers for all your work with this book in one place, for

easy reference.

Chapter 7: Understanding Access List Security

•

Take the “Do I Know This Already?” quiz, and write down your answers. Studies show

that retention is significantly increased through writing down facts and concepts, even if

you never look at the information again.

•

Use the diagram in Figure 7-1 to guide you to the next step.

The purpose of the “Do I Know This Already?” quiz is to help you decide what parts of this

chapter to use. If you already intend to read the entire chapter, you do not necessarily need to

answer these questions now.

This 12-question quiz helps you determine how to spend your limited study time. The quiz is

sectioned into two smaller six-question “quizlets,” which correspond to the three major topic

headings in the chapter. Figure 7-1 outlines suggestions on how to spend your time in this

chapter based on your quiz score. Use Table 7-1 to record your scores.

1 Filtering IP Traffic 1 to 6

2 Filtering IPX Traffic and SAPs 7 to 12

All questions 1 to 12

“Do I Know This Already?” Quiz

Configure a numbered IP access list that would stop packets from subnet 134.141.7.0,

255.255.255.0, from exiting serial 0 on some router. Allow all other packets.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

How would a user who does not have the enable password find out what access lists have

been configured and where they are enabled?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

How many IP extended

commands are required to check a particular port

number on all IP packets?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

True or false: If all IP or IPX access list statements in a particular list define the deny

action, then the default action is to permit all other packets.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

How many IP access lists of either type can be active on an interface at the same time?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

In a standard named IP access list with three statements, a

version of the first statement

is issued in configuration mode. Immediately following, another access list configuration

command is added for the same access list. How many statements are in the list now, and

in what position is the newly added statement?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Chapter 7: Understanding Access List Security

In an IPX access list with five statements, a

version of the third statement is issued in

configuration mode. Immediately following, another access list configuration command

is added for the same access list. How many statements are in the list now, and in what

position is the newly added statement?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Name all the items that a SAP access list can examine to make a match.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Name all the items that a standard IPX access list can examine to make a match.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Name all the items that a named extended IPX access list can examine to make a match.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Configure a SAP numbered access list so that SAPs 4-7 are matched, in network BEEF,

with a single command.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

What command could someone who has only the Telnet password, not the enable

password, use to find out what IPX access lists are enabled on which interfaces?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

“Do I Know This Already?” Quiz

The answers to the “Do I Know This Already?” quiz are found in Appendix A, “Answers to the

‘Do I Know This Already?’ Quizzes and Q&A Sections,” on page 754. The suggested choices

for your next step are as follows:

•

—Read the entire chapter. This includes the “Foundation Topics”

and “Foundation Summary” sections, the Q&A section, and the scenarios at the end of the

chapter.

•

—Review the subsection(s) of the “Foundation Topics” part of

this chapter, based on Table 7-1. Then move into the “Foundation Summary” section, the

Q&A section, and the scenarios at the end of the chapter.

•

—Begin with the “Foundation Summary” section, and then go to

the Q&A and the scenarios at the end of the chapter.

•

—If you want more review on these topics, skip to the

“Foundation Summary” section and then go to the Q&A section and the scenarios at the

end of the chapter. Otherwise, move to the next chapter.

Chapter 7: Understanding Access List Security

IP access lists perform a variety of functions in a Cisco router. The CCNA exam requires that

you know only how to use access lists for filtering; however, access lists can be used to filter

routing updates, to match packets for prioritization, and to filter packets. Filtering often is used

to make a network more secure, hence the name of this chapter. Table 7-2 and Table 7-3 list the

more popular configuration commands and EXEC commands about access lists.

The logic used for access lists can best be summarized by Figure 7-2.

{

} {

|

}

[

]

Global command for standard numbered access

lists

{

} {

|

}

[

] [

]

[

] [

] [

]

Global command for extended numbered access

lists

{

|

[

|

] } Interface subcommand to enable access lists

{

|

}

Global command for standard and extended

named access lists

{

[

] |

}[

] Standard named access list subcommand

{

|

}

[

] [

]

[

] [

]

[

]

Extended named access list subcommand

|

[

|

] Line subcommand for standard or extended

access lists

Includes reference to the access lists enabled on

the interface

Shows details of configured access lists for all

protocols

[

] Shows IP access lists

Filtering IP Traffic

Features of the process described in Figure 7-2 are as follows:

packet does not match any of your access list statements, the packet will be blocked.

The two diamond-shaped symbols in Figure 7-2 represent the application of the logic of an

access-list. That logic can be summarized as follows:

compared to the packet.

(permit or deny) is performed, as shown in Figure 7-2.

using the next sequential access list statement.

is performed.

The logic for access lists is true whether using standard or extended access lists; the only

difference between the two types is in what constitutes a match. The following sections on

standard IP access lists, extended IP access lists, and named IP access lists outline these

differences.

Standard access lists can match only by examining the source IP address field in the packet’s IP

header. Any bit positions in the 32-bit source IP address can be compared to the access list

statements; for example, a subnet number can be checked. However, the matching is flexible

and does not consider the subnet mask in use; it is just a math problem!

A wildcard mask defines the subset of the 32 bits in the IP address that must be matched. As a

CCNA, you will be required to fully understand the use of the wildcard mask to match a subset

parameter and the packet’s source IP address. Mask bits of value binary 0 imply that the same

bit positions must be compared in the two IP addresses. Mask bits of value binary 1 are

wildcards; the corresponding bit positions in the addresses are considered to match, regardless

of values. In other words, binary 1s mean that these bit positions already match—hence the

commands.

0.0.0.0 1.55.88.111 0000 0001

0011 0111

0101 1000

0110 1111

1.55.88.4 0000 0001

0011 0111

0101 1000

0000 0100

All bits must

match, and they do

not.

0.0.0.255 1.55.88.111 0000 0001

0011 0111

0101 1000

0110 1111

1.55.88.0 0000 0001

0011 0111

0101 1000

0000 0000

The first 24 bits

must match, and

they do.

0.0.255.255 1.55.56.7 0000 0001

0011 0111

0011 1000

0000 0111

1.55.0.0 0000 0001

0011 0111

0000 0000

0000 0000

The first 16 bits

must match, and

they do.

255.255.255.255 5.88.22.5 0000 0101

0101 1000

0001 0110

0000 0101

0.0.0.0 0000 0000

0000 0000

0000 0000

0000 0000

All bits match,

regardless of the IP

address in the

packet.

32.48.0.255 33.1.1.1 0010 0001

0000 0001

0000 0001

0000 0001

1.1.1.0 0000 0001

0000 0001

0000 0001

0000 0000

All bits except the

3rd, 11th, 12th,

and last 8 must

match. The two

numbers match in

this case. (This is a

rather impractical

choice of wildcard

mask and is used

only to make the

point that it is

flexible!)

The following example, illustrated by Figure 7-3, Example 7-1, and Example 7-2, shows a basic

use of standard IP access lists, with two typical oversights in the first attempt at a complete

answer. The criteria for the access list(s) is as follows:

interface serial 0

ip access-group 3

!

access-list 3 deny host 10.1.2.1

access-list 3 permit any

At first glance, these two access lists seem to perform the desired function. In Yosemite, the

packets from Sam are filtered before leaving s0; likewise, in Seville, packets from 10.1.3.0/24

are filtered before leaving s1 toward Yosemite. However, if either link into Albuquerque fails,

the new route would leave an opening. For example, if the link from Albuquerque to Yosemite

fails, Yosemite would learn a route to 10.1.1.0/24 through Seville. Packets from Sam destined

for hosts in Albuquerque would leave Yosemite’s s1 without being filtered.

An alternative answer to the stated problem is illustrated in Example 7-3. The access list has

been removed from Seville, and all filtering is performed on Yosemite.

Example 7-3 denies all traffic that should be denied based on the criteria; however, it denies

more traffic than the first of the three criteria says it should! In many cases, the meaning of the

criteria for the access lists greatly affects your configuration choices. For example, Example

7-3 solved some of the problems of Example 7-2 by filtering packets from 10.1.2.1 (Sam) and

preventing them from exiting both of Yosemite’s serial interfaces, keeping Sam from getting to

Albuquerque. However, that also prevents Sam from communicating with anyone outside

access-list on Albuquerque’s serial interfaces.

criteria, however. Because the goal was to stop Seville hosts from communicating with

Yosemite’s hosts, and because the only LAN hosts off Yosemite are the ones on the local

Ethernet, the access list is effective in stopping packets from exiting Ethernet 0.

interface serial 1

ip access-group 4

!

access-list 4 deny 10.1.3.0 0.0.0.255

access-list 4 permit any

interface serial 0

ip access-group 3

!

interface serial 1

ip access-group 3

!

interface ethernet 0

ip access-group 4

!

access-list 3 deny host 10.1.2.1

access-list 3 permit any

!

access-list 4 deny 10.1.3.0 0.0.0.255

access-list 4 permit any

Extended IP access lists are almost identical to standard IP access lists in their use. The key

difference between the two types is the variety of fields in the packet that can be compared for

matching by extended access lists. To pass the CCNA exam, you must remember all the items

that an extended IP access list can check to make a match. As with standard lists, extended

access lists are enabled for packets entering or exiting an interface. The list is searched

sequentially; the first statement matched stops the search through the list and defines the action

to be taken. All these features are true of standard access lists as well. The matching logic,

however, is different than that used with standard access lists and makes extended access lists

much more complex.

Figure 7-4 shows several of the fields in the packet headers that can be matched. The top set of

headers shows the IP protocol type, which identifies what header follows the IP header. The

source and destination IP addresses are also shown. In the second set of headers in the figure,

an example with a TCP header following the IP header is shown. The TCP source and

destination port numbers are listed in the abbreviated TCP header shown in the figure. Table

7-5 provides the complete list of items that can be matched with an IP extended access list.

IP Standard Source IP address

Portions of the source IP address, using a wildcard mask

A statement is considered to match if all options in the statement match. If one option does not

match, the statement is skipped, and the next entry in the list is examined. Table 7-6 provides

several example access list statements.

IP Extended Source IP address

Portions of the source IP address, using a wildcard mask

Destination IP address

Portions of the destination IP address, using a wildcard mask

Protocol type (TCP, UDP, ICMP, IGRP, IGMP, and others)

Source port

Destination port

Established—matches all TCP flows except first flow

IP TOS

IP precedence

be 10.1.1.1, with a TCP header, with destination

port 23.

used instead of port 23.

Packet with source in network 1.0.0.0 to any

destination, using UDP with source port less than

1023.

Packet with source in network 1.0.0.0 to

destinations beginning 44.1, using UDP with

source port less than 1023.

Packet with source in 33.1.2.0/24 to destinations

beginning 44.1.

Packet with source in 33.1.2.0/24 to destinations

beginning 44.1, which are ICMP Echo Requests

and Replies.

logic like a wildcard mask of 0.0.0.0.

The sequence of the parameters is very important—and very tricky, in some cases. When

source port number when placed immediately after the check of the source IP address.

Likewise, if the port parameter follows the check of the destination address, the logic matches

matches all packets that use TCP and whose source TCP port is 23 (Telnet). Likewise, the

destination TCP port is 23 (Telnet).

Extended IP Access Lists, Example 1

The following example, based on the network in Figure 7-3 and configured as in Example 7-4,

shows the use of extended IP access lists. The criteria for this first example use the same criteria

as in the standard access list example:

Two important side effects occur with the configuration shown in Example 7-4, compared to

the standard access list configuration in Examples 7-1 and 7-2. The issue of having packets

routed around the access list is already taken care of because the access lists are enabled for

output packets on both serial interfaces. Also, most of the packets are filtered at the router

nearest the source of the packets, which reduces network overhead. Access lists could have been

added at Seville as well, to deny the packets originating from Seville’s Ethernet.

interface serial 0

ip access-group 110

!

interface serial 1

ip access-group 110

!

access-list 110 deny ip host 10.1.2.1 10.1.1.0 0.0.0.255

access-list 110 deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255

access-list 110 permit ip any any

Extended IP Access Lists, Example 2

Figure 7-5 presents the network diagram for another example on extended IP access lists.

The filtering criteria for this extended access list example is more complicated:

in the upper half of the valid IP addresses in each subnet. (Note: The subnet mask used is

255.255.255.0.)

if packets are routed across the direct serial link.

Example 7-5, Example 7-6, and Example 7-7 show one solution to this second extended access

list example.

interface serial 0

ip access-group 110

!

interface serial 1

ip access-group 111

!

! Criterion 1 met with next statement

access-list 110 permit tcp any host 10.1.1.2 eq www

! Criterion 2 met with next statement

access-list 110 deny udp 0.0.0.128 255.255.255.127 host 10.1.1.1

! Criterion 3 met with next statement

access-list 110 deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255

! Criterion 5 met with next statement

access-list 110 permit ip any any

!

! Criterion 1 met with next statement

access-list 111 permit tcp any host 10.1.1.2 eq www

! Criterion 2 met with next statement

access-list 111 deny udp 0.0.0.128 255.255.255.127 host 10.1.1.1

! Criterion 5 met with next statement

access-list 111 permit ip any any

interface serial 0

ip access-group 110

!

interface serial 1

ip access-group 111

!

! Criterion 1 met with next statement

access-list 110 permit tcp any host 10.1.1.2 eq www

! Criterion 2 met with next statement

access-list 110 deny udp 0.0.0.128 255.255.255.127 host 10.1.1.1

! Criterion 3 met with next statement

access-list 110 deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255

! Criterion 5 met with next statement

access-list 110 permit ip any any

!

! Criterion 1 met with next statement

access-list 111 permit tcp any host 10.1.1.2 eq www

! Criterion 2 met with next statement

access-list 111 deny udp 0.0.0.128 255.255.255.127 host 10.1.1.1

! Criterion 5 met with next statement

access-list 111 permit ip any any

The access lists on Yosemite and Seville are almost identical; each is focused on the first three

criteria. List 110 is used as outbound access-lists on the Yosemite and Seville links connected

to Albuquerque. The first three statements in list 110 in each router complete the first three

criteria for this example; the only difference is in the source and destination addresses used in

the third statement, which checks for the respective subnet numbers at each site.

Both Yosemite and Seville have a list 111 that is used on the link between the two. Each list 111

on Yosemite and Seville is identical to list 110, respectively, except that list 111 is missing one

statement. This missing statement (relative to list 110) is the one that meets criterion 3, which

states to not filter this traffic from going across the direct serial link; because list 111 is used on

that link, there is no need for the extra statement. The final statement in lists 110 and 111 in

Seville and Yosemite provide coverage for the fifth point of criteria for this example, allowing

all other packets to flow.

The second access list statement in each list 110 and 111 on Seville and Yosemite is trickier than

you will see on the CCNA exam. This example is indicative of the types of nuances that you

might see on the CCNP and CCIE exams. The mask has only one binary 0 in it, in bit 25 (the

first bit in the last byte). The corresponding bit in the address has value 1; in decimal, the

address and mask imply addresses whose fourth byte is between 128 and 255, inclusive.

Regardless of subnet number, hosts in the upper half of the assignable addresses in each subnet

are matched with this combination. (Note: Because the subnet mask is 255.255.255.0, all host

addresses in the upper half of the address range are between 128–254 in the last octet.)

Three major problems exist when using extensive detailed criteria for access lists. First, the

criteria is open to interpretation. Many people tend to create the lists to match the order in which

each point of the criteria are written; no attempt at optimization is made. Finally, the lists are

easy to create in such a way that the criteria is not actually accomplished, as in extended IP

access list example 2.

interface serial 0

ip access-group 112

!

interface serial 1

ip access-group 112

!

! Criterion 4 met with next four statements

access-list 112 deny ip host 10.1.1.130 host 10.1.3.2

access-list 112 deny ip host 10.1.1.28 host 10.1.3.2

access-list 112 permit ip host 10.1.1.130 any

access-list 112 permit ip host 10.1.1.28 any

! Criterion 5 met with next statement

access-list 112 permit ip any any

Example 7-8 shows an alternative solution to the extended access list example 2 solution, as

was shown in Example 7-5, Example 7-6, and Example 7-7. All access lists have been removed

from Seville and Yosemite, as compared with that earlier solution.

Several differences exist between the first solution in Examples 7-5, 7-6, and 7-7, and the

second solution in Example 7-8. First, all the filtering is performed in Albuquerque. Criterion

Petunia to talk to other hosts besides Red. Packets are sent by Yosemite and Seville to

Albuquerque hosts, as well as packets sent back from servers in Albuquerque to the

Albuquerque router, before being filtered. However, the number of these packets will be small

because the filter prevents the client from sending more than the first packet used to connect to

the service.

Named IP access lists allow the same logic to be configured as with numbered standard and

extended access lists. As a CCNA, you will need to remember the differences in syntax of the

configuration commands and also be able to create both numbered and named lists with the

same logic. The key differences between numbered and named IP access lists are listed here:

restriction using numbered access lists.

interface serial 0

ip access-group 112

!

interface serial 1

ip access-group 112

!

! Next statement meets objective 1

access-list 112 permit tcp host 10.1.1.2 eq www any

! Next statement meets objective 2

access-list 112 deny udp host 10.1.1.1 0.0.0.128 255.255.255.127

! Next statements meet objective 3

access-list 112 deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255

access-list 112 deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255

! Next statement meets objective 4

access-list 112 deny ip host 10.1.1.130 host 10.1.3.2

access-list 112 deny ip host 10.1.1.28 host 10.1.3.2

! Next statement meets objective 5

access-list 112 permit ip any any

deletion only of the entire list. Insertion of the new statement into a named list requires

deletion and re-addition of all statements that should be later in the list than the newly

added statement.

types on an individual router. Names can be duplicated on different routers.

The configuration syntax is very similar between named and numbered IP access lists. The

items that can be matched with a numbered standard IP access list are identical to the items that

can be matched with a named standard IP access list. Likewise, the items are identical with both

numbered and named extended IP access lists.

Two important differences exist between numbered and named access-lists. One key difference

is that named access lists use a global command, which moves the user into a named IP access

list submode, under which the matching and permit/deny logic is configured. The other key

difference is that when a named matching statement is deleted, only that one statement is

deleted. With numbered lists, the deletion of any statement in the list deletes all the statements

in the list. (This feature will be demonstrated in more detail in an upcoming example.)

Table 7-7 lists the key configuration commands and shows their differences and similarities.

* These commands are subcommands of the previous command.

among all named access lists of all types in this router. Also, note that because the named list

does not imply standard or extended by the value of the number of the list, the command

explicitly states the type of access list. Also, the . . . represents all the matching parameters,

which are identical in meaning and syntax when comparing the respective numbered and named

IP access lists. Also note that the same command is used to enable the list on an interface for

both numbered and named lists.

Commands for matching

packets: standard IP ACLs

Commands for matching

packets: extended IP ACLs

One difference between the two types of lists is that individual matching statements can be

removed from the named lists. Example 7-9 shows the configuration mode output when

entering the access list used on Albuquerque in access list 112 of Example 7-8, but this time as

a named access list instead of a numbered access list. One typo is shown in the original creation

of the access list in Example 7-9, with changes made to delete and add the statement shown later

instead.)

conf t

Enter configuration commands, one per line. End with Ctrl-Z.

! The next statement is purposefully wrong so that the process of changing the list

can be seen.

Router(config-ext-nacl)#^Z

Building configuration...

Current configuration:

.

. (unimportant statements omitted)

.

!

ip access-list extended barney

permit tcp host 10.1.1.2 eq www any

deny udp host 10.1.1.1 0.0.0.128 255.255.255.127

deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255

deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255

deny ip host 10.1.1.130 host 10.1.3.2

deny ip host 10.1.1.28 host 10.1.3.2

permit ip any any

Enter configuration commands, one per line. End with Ctrl-Z.

Extended IP access list barney

permit tcp host 10.1.1.2 eq www any

deny udp host 10.1.1.1 0.0.0.128 255.255.255.127

first command is configured, the IOS implements the access list’s logic. This is true of IP

standard access lists as well as extended and named access lists. Access lists that filter other

types of packets follow this same logic.

Access into and out of the virtual terminal line (vty) ports of the IOS can be controlled by IP

access lists. (vty is used for Telnet access to and from the IOS.) The inbound case is the more

obvious case. For instance, imagine that only hosts in subnet 10.1.1.0/24 were supposed to be

capable of telnetting into any of the Cisco routers in a network. In such a case, the configuration

in Example 7-10 could be used on each router to deny access from IP addresses not in that one

subnet.

deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255

deny ip host 10.1.1.130 host 10.1.3.2

deny ip host 10.1.1.28 host 10.1.3.2

permit ip any any

Enter configuration commands, one per line. End with Ctrl-Z.

Extended IP access list barney

permit tcp host 10.1.1.2 eq www any

deny udp host 10.1.1.1 0.0.0.128 255.255.255.127

deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255

deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255

deny ip host 10.1.1.130 host 10.1.3.2

deny ip host 10.1.1.28 host 10.1.3.2

permit ip any any

to packets that are entering the router when you are trying to Telnet to that router’s vtys. The

Telnet feature of the IOS (which is unlikely to be on the exam). The out keyword implies that

the packets originated by the Telnet client in the router are checked using the destination

address of the packets.

To pass the CCNA exam, you must be proficient in using IP access lists. The most important

details to recall are as follows:

The philosophy of choosing the location for access lists is covered in more depth in the CCNP

exam than in the CCNA exam. However, filtering packets closer to the source of the packet

generally is better because the soon-to-be discarded packets will waste less bandwidth than if

the packets were allowed to flow over additional links before being denied.

Be particularly careful of questions relating to existing lists. In particular, if the question

will place the statement at the end of the list, but the statement might need to be earlier in the

list to accomplish the goal described in the question. Also focus on the differences between

named and numbered IP access lists.

IPX access lists can be used to filter IPX packets sent by clients and servers, just as IP access

lists are used to filter IP packets. However, similar functions can be performed by using Service

Advertising Protocol (SAP) filters, which filter SAP updates sent by servers and routers. SAP

filters are more common because they can be used to prevent clients and servers from trying to

send packets, as well as to reduce the overhead of SAP updates.

line vty 0 4

login

password cisco

access-class 3 in

!

! Next command is a global command

access-list 3 permit 10.1.1.0 0.0.0.255

CCNAs deal with SAPs and SAP filtering on a regular basis and with IPX packet filtering a little

less often. Both numbered and named IPX access lists are available. The configuration

commands used for these filters are listed in Table 7-8; the EXEC commands related to IPX

filtering are shown in Table 7-9.

Global command to create numbered standard

IPX access lists

Global command to create numbered extended

IPX access lists

Global command to create numbered SAP access

lists

standard, extended, or SAP access list

Named access list subcommand for standard

access lists

Named access list subcommand for extended

access lists

Named access list subcommand for SAP access

lists

numbered, standard or extended IPX access list

used for outbound SAP packets

used for inbound SAP packets

Access lists for filtering packets are covered next; SAP filters are covered in the section “SAP

Access Lists.”

Packet filters in the Cisco IOS use the same general logic for any Layer 3 protocol. Figure 7-6

outlines the path an IPX packet can take through a router. The comments following the figure

describe the basic logic behind IPX access lists.

Features of the process described in Figure 7-6 are as follows:

The logic created by an access list, as shown in the diamond-shaped symbols in Figure 7-6, is

best summarized by the following sequence of events:

compared to the packet.

(permit or deny) is performed, as shown in Figure 7-6.

next sequential access list statement.

is performed.

the interface

protocols

The logic for access lists is true whether using standard or extended access lists. The only

difference is that extended access lists include more comparisons to determine a match. These

differences are outlined in the next few sections on standard IPX access lists, extended IPX

access lists, and SAP access lists.

When deciding what this book should really try to accomplish, I decided that the text of the

book should cover the topics in two ways. First, the voluminous details should be summarized

in tables and lists whenever possible, to allow easy review for a reader who already knows the

topic pretty well. The explanations then should focus on topics that are less obvious from

reading the manual; these are the types of tidbits that you get from the instructor in a well-taught

class. When discussing IPX packet filters, I will be focusing on these tidbits. If you are new to

IPX access lists, you probably will want to read the IOS documentation or the Cisco Press book

Standard IPX access lists can check the source and destination network number. They also can

check the node part of the source and destination addresses, and use a wildcard mask to examine

the node part of the IPX addresses.

Figure 7-7 and Example 7-11 provide an example network and configuration.

ipx routing 0200.1111.1111

!

interface serial0

ip address 10.1.1.1 255.255.255.0

ipx network 1001

!

interface serial1

ip address 10.1.2.1 255.255.255.0

ipx network 1002

ipx access-group 820 in

!

interface ethernet 0

ip address 10.1.200.1 255.255.255.0

ipx network 200

ipx access-group 810

!

access-list 810 deny 101

access-list 810 permit -1

!

access-list 820 permit 302

IPX access list 810

deny 101

permit FFFFFFFF

IPX access list 820

permit 302

Serial1 is up, line protocol is up

IPX address is 1001.0200.1111.1111 [up]

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

IPXWAN processing not enabled on this interface.

IPX SAP update interval is 1 minute(s)

IPX type 20 propagation packet forwarding is disabled

Incoming access list is 820

Outgoing access list is not set

IPX helper access list is not set

SAP GNS processing enabled, delay 0 ms, output filter list is not set

SAP Input filter list is not set

SAP Output 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

The following criteria will be used in this IPX standard access list example established in Figure

7-7 and Example 7-11:

The example shows one way to accomplish the goals, but other alternatives exist. Access list

810 implements the first two criteria for the example by filtering packets exiting Ethernet 0 on

R1. Access list 820 implements the last two criteria for the example by filtering packets entering

serial1 on R1.

denies access from source network 101 and permits all other source network numbers via the

explicitly defined “permit all else” as the second statement in the list. If the list had been used

as an inbound access-list on serial0 of R1, then packets from network 101 would not be capable

of entering R1 for forwarding on to R3. By placing the filter on Ethernet0 as an outbound filter,

R1 could forward packets from 101 and 102 on to R3, but only packets from network 102 would

make it to network 200.

other source networks due to the implied “deny all else” at the end of the list. By applying the

list as an inbound list on R1’s serial 1, criterion 3 will be met by the default “deny all,” and

criterion 4 will be met by the explicit “permit” of source network 302.

Several nuances of access list operation are seen (or implied, by omission) in the syntax shown

numbers. No destination networks were checked with either access list, which is allowed with

IPX standard access lists. Also, the optional node mask was not used and is not useful very

often. For example, imagine that a requirement was added so that packets from Clients 5 and 6

are not allowed to be sent to network 302. If the IPX addresses for Clients 5 and 6 were

200.0200.1234.0000 and 200.0200.1234.0001, and if no other client’s IPX addresses began

two clients:

access-list 830 deny 200.0200.1234.0000 0000.0000.ffff

The wildcard mask works like the wildcard mask used in IP access lists; the only difference is

digits in the node part of the address are automatically considered to match, but that the first

eight digits do need to be checked. However, because almost everyone who uses IPX uses the

burned-in MAC address for the node part of the IPX address, the IPX addresses on these clients

will almost never have a convenient number to allow packets from both to be matched in the

same access list statement. Even if the numbers were convenient for using a wildcard mask, the

IPX address would change if the LAN adapter ever was replaced, giving undesired results from

the access list. So, unless you are using locally administered MAC addresses on your IPX

nodes, the node mask will almost never be useful.

Cisco expects CCNAs to be familiar enough with TCP/IP and IPX protocols to recognize

oversights in an access list design before the access-lists are deployed. Such an oversight is true

of Example 7-11—or, more accurately, the criteria used for Example 7-11. Note that the criteria

all mentioned network numbers, but no servers were mentioned. The oversight is that when

clients connect to servers whose code level is NetWare 3.11 and beyond, the address used by

the server to communicate with the client uses the server’s internal network number. So, in

with the implied “deny all” would prevent all client-server traffic from entering R1’s serial1

interface.

Now thinking in terms of client/server flows with NetWare, consider the following changes in

the criteria for these access lists:

The new configuration in Example 7-12 successfully focuses on the servers’ network numbers,

not the network numbers on the LAN segments.

ipx routing 0200.1111.1111

!

interface serial0

ip address 10.1.1.1 255.255.255.0

ipx network 1001

!

interface serial1

ip address 10.1.2.1 255.255.255.0

ipx network 1002

ipx access-group 820 in

!

interface ethernet 0

ip address 10.1.200.1 255.255.255.0

ipx network 200

ipx access-group 810

!

access-list 810 deny 2001

access-list 810 permit -1

!

access-list 820 deny 3001

access-list 820 permit -1

Extended access lists for IPX can check several additional fields in the IPX packet header, as

compared to standard IPX access lists. Cisco expects CCNAs to remember all the items that can

those items, and Figure 7-8 shows the relative location of the fields in the headers.

The protocol type is a field that is not shown in many examples in other references, such as the

Cisco IOS documentation CD. Figure 7-9 shows example packets that would be matched by the

various protocol types.

IPX Standard Source network

Source IPX address (network and node)

Source network and portions of the node address, using a node mask

Destination network

Destination IPX address (network and node)

Destination network and portions of the node address, using a node mask

IPX Extended Same points as with an IPX standard access list in addition to items in the

rows that follow

Portions of entire source IPX address, using a wildcard mask

Portions of entire destination IPX address, using a wildcard mask

Protocol type

Source socket

Destination socket

The protocol names can be misleading, particularly the SAP protocol type. Extended access

lists can be used to filter entire SAP packets; protocol type SAP would be useful to match those

packets. For filtering the content of the SAP updates, which is a hugely popular function, access

lists for filtering SAP information would be used. The SAP filters, which use list numbers

between 1000 and 1099, are covered in the section “SAP Filters,” later in this chapter. SAP

filtering does not use extended IPX access lists with a SAP protocol type.

Similarly, extended IPX access lists with protocol type RIP can allow matching of RIP packets,

protocol type.

applications to create the equivalent of a TCP or UDP well-known port. Clients dynamically

assign sockets in the range of 4000–7FFF, and Novell assigns sockets to applications in the

range of 8000–FFFF. As with IP, there is both a source and destination socket, which is used for

multiplexing.

socket number 4 for file services.

The most useful extended access list feature that is not supported by standard access lists is the

network wildcard mask. Figure 7-10 and Example 7-13 provide a sample to show when this

mask is useful. The access list is configured in R2. The criteria for this packet filter is as follows:

hostname R2

!

ipx routing 0200.2222.2222

!

interface serial0

ip address 10.1.1.2 255.255.255.0

ipx network 200

ipx access-group 910

!

interface ethernet 0

ip address 10.1.100.2 255.255.255.0

ipx network 100

!

interface ethernet 1

ip address 10.1.101.2 255.255.255.0

ipx network 101

!

access-list 910 deny any 1000 0000000F

access-list 910 permit any -1

number is eight hex digits long; the leading 0s are not shown. For the network wildcard mask,

all digits are shown in the book, but the leading zeroes are omitted in an actual router

configuration. The mask 0000000F means that the first seven hex digits must match 0000100,

which are the first seven hex digits of the network number in this case, with leading 0s shown.

The last hex digit can be any value. Therefore, networks 1000, 1001, and 14 others are matched.

To exactly match the two networks 1000 and 1001, the mask 00000001 could be used. This

mask implies that all bits are checked except the one low-order bit. (Feel free to convert hex

1000 and 1001 to binary to see that only the last bit is different in the two numbers.)

The key to understanding SAP filters is to understand where SAP packets flow and where they

do not. This process is fundamental to the job function of a typical CCNA. The SAP process is

very similar to routing updates with a distance vector routing protocol. In fact, SAP uses a split

horizon concept as well. The following sequence outlines a day in the life of a SAP packet:

attached network, based on the expiration of its SAP timer.

its SAP information (up to seven services per packet, by default).

network.

routers and servers receive all the SAP packets.

the SAP packets and update their SAP tables as necessary.

synchronized with the other servers and routers. When the timer

expires, each server and router performs Steps 1 through 3, and

their neighboring servers and routers react and perform Steps 4

through 6.

In other words, the SAP packets are never forwarded by a router or server. This process is

effectively the same process used by distance vector routing protocols. So, packet filters filter

to filter routing information. Likewise, IOS uses SAP filters to filter SAP information.

SAP filtering provides two functions: filtering the services listed in outgoing SAP updates, and

filtering services listed in received SAP updates. The first function reduces the information sent

to the router’s neighboring IPX servers and routers. The second function limits what a router

adds to its SAP table when an update is received. Unlike packet filters, SAP filters examine the

data inside the packet as well. Figure 7-11 outlines the process.

Two main reasons exist for using SAP filters. First, SAP updates can consume a large amount

of bandwidth, particularly in nonbroadcast multiaccess (NBMA) networks. If clients in one

division never need services from servers in another division, there is no need to waste

bandwidth advertising the services. The second reason for SAP filters is that they can

accomplish the same task as most IPX packet filters, but with less overhead. (This second

reason will be outlined in the SAP filtering sample in Example 7-14.) SAP filters will be used

to accomplish the same set of criteria that was mentioned with Example 7-13 and Figure 7-10.

As a reminder, the criteria for that filter is as follows:

The effect of the SAP filter on R1 is somewhat obvious. How the filter stops clients in network

300 from reaching Server 1 and Server 2 is not as obvious. The filter examines inbound SAP

updates from R2. Services in networks 1000 to 100F are filtered. All other services are not

table for networks 1000 to 100F.

The key to understanding what stops clients from reaching Server 1 and Server 2 is to recall the

GNS process and its purpose. (Figure 6-14, in Chapter 6, “Routing,” outlined the process.)

Either Server 3 or Server 4 will be used as the GNS server for clients in network 300. (The

router will not reply to GNS requests if a real server exists on the LAN at some later IOS

releases; before that, the router delayed replying so that any local servers would send the first

reply.) Neither Server 3 nor Server 4 will know of Server 1 or Server 2 because they are relying

on R1 to advertise SAP information, and R1 has filtered SAPs about networks 1000 to 100F.

Therefore, network 300 clients will not be capable of logging in to Server 1 or Server 2 because

SAP filtering to disallow certain clients from using certain servers is more efficient than IPX

packet filters. SAPs are sent once every 60 seconds, whereas packet filters cause the IOS to

examine every IPX packet, a much more frequent task. So, you are more likely to use SAP filers

in real networks, and you also are more likely to see SAP filters on the exam, as compared with

IPX packet filters.

Hostname R1

!

ipx routing 0200.1111.111

!

interface serial0

ip address 10.1.1.1 255.255.255.0

ipx network 200

ipx input-sap-filter 1005

!

interface ethernet 0

ip address 10.1.30.1 255.255.255.0

ipx network 300

!

access-list 1005 deny 1000 0000000F

access-list 1005 permit -1

The following list shows the fields that can be matched for each service advertised, or to be

advertised, in a SAP update.

Named IPX access lists allow the same logic to be configured as with numbered standard,

extended, and SAP access lists. As a CCNA, you will need to remember the differences in

syntax of the configuration commands and be able to create both numbered and named lists

with the same logic. The key differences between numbered and named IP access lists are listed

here:

is the restriction using numbered access lists.

deletion only of the entire list. Insertion of the new statement into a named list requires

deletion and re-addition of all statements that should follow the newly added statement.

types on an individual router. Names can be duplicated on different routers.

The configuration syntax is very similar between named and numbered IPX access lists. The

items that can be matched with a numbered standard IPX access list are identical to the items

that can be matched with a named standard IPX access list. Likewise, the items are identical

with both numbered and named extended IPX access lists, as well as with numbered and named

SAP access lists.

One key difference is that named access lists use a global command, which moves the user into

a named IPX access list submode, under which the matching and permit/deny logic is

configured. The other key difference is that when a named matching statement is deleted, only

that specific statement is deleted. With numbered lists, the deletion of any statement in the list

deletes all the statements in the list. (This feature will be demonstrated in more detail in an

upcoming example.)

Table 7-11 lists the key IPX access list configuration commands and shows their differences and

similarities.

among all named access lists of all types in this router. Also, note that because the named list

does not imply standard, extended, or SAP by the value of the number of the list, the command

explicitly states the type of access list. Also, the . . . represent all the matching parameters,

which are identical in meaning and syntax when comparing the respective numbered and named

IPX access lists. Also note that the same command is used to enable the list on an interface for

both numbered and named lists.

One difference between the two types of lists is that individual matching statements can be

removed from the named lists. Example 7-15 shows the configuration mode output when

entering a named SAP access list on R1. The key to this example is to notice the changes. One

statement is deleted and then re-added to the list, but this changes the order of the list. Example

7-15 shows the details.

Standard access list enabling

command

Extended access list enabling

command

configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

IPX sap access list fred

deny 2 7

deny 3

deny 4 7

permit FFFFFFFF

Enter configuration commands, one per line. End with CNTL/Z.

IPX sap access list fred

deny 2 7

deny 3

permit FFFFFFFF

Enter configuration commands, one per line. End with CNTL/Z.

IPX sap access list fred

deny 2 7

deny 3

permit FFFFFFFF

deny 4 7

Enter configuration commands, one per line. End with CNTL/Z.

IPX sap access list fred

deny 2 7

deny 3

deny 4 7

permit FFFFFFFF

Enter configuration commands, one per line. End with CNTL/Z.

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname R1

!

enable secret 5 $1$chuM$zon5bAnWNCu38hzCmAr.k.

!

ip subnet-zero

no ip domain-lookup

ipx routing 0000.3089.b170

!

!

!

interface Serial0

no ip address

no ip directed-broadcast

encapsulation frame-relay IETF

clockrate 56000

frame-relay lmi-type cisco

!

interface Serial0.1 multipoint

ip address 168.13.100.1 255.255.255.0

no ip directed-broadcast

ipx network 100

ipx output-sap-filter fred

frame-relay interface-dlci 902

frame-relay interface-dlci 903

!

! Additional configuration not shown...

The Foundation Summary is a collection of tables and figures that provide a convenient review

of many key concepts in this chapter. For those of you who already feel comfortable with the

topics in this chapter, this summary could help you recall a few details. For those of you who

just read this chapter, this review should help solidify some key facts. For any of you doing your

final prep before the exam, these tables and figures will be a convenient way to review the day

before the exam.

Table 7-12 and Table 7-13 list the more popular configuration commands and EXEC commands

about access lists.

Global command for standard numbered

access lists

Global command for extended numbered

access lists

named access lists

Extended named access list subcommand

access lists

the interface

protocols

Table 7-14 provides the complete list of items that can be matched with an IP extended access

list.

IP Standard Source IP address

Portions of the source IP address, using a wildcard mask

IP Extended Source IP address

Portions of the source IP address, using a wildcard mask

Destination IP address

Portions of the destination IP address, using a wildcard mask

Protocol type (TCP, UDP, ICMP, IGRP, IGMP, and others)

Source port

Destination port

Established—matches all TCP flows except the first flow

IP TOS

IP precedence

Packet with any source address; destination must

be 10.1.1.1, with a TCP header, with destination

port 23.

used instead of port 23.

Packet with source in network 1.0.0.0 to any

destination, using UDP with source port less than

1023.

Packet with source in network 1.0.0.0 to

destinations beginning 44.1, using UDP with

source port less than 1023.

Packet with source in 33.1.2.0/24 to destinations

beginning 44.1.

Packet with source in 33.1.2.0/24 to destinations

beginning 44.1, which are ICMP Echo Requests

and Replies.

The configuration commands used for IPX-related filters are listed in Table 7-16; the EXEC

commands related to IPX filtering are shown in Table 7-17.

Global command to create numbered standard

IPX access lists

Global command to create numbered extended

IPX access lists

Global command to create numbered SAP access

lists

Global command to begin creation of a named

standard, extended, or SAP access list

Named access list subcommand for standard

access lists

Named access list subcommand for extended

access lists

Named access list subcommand for SAP access

lists

numbered, standard or extended IPX access list

used for outbound SAP packets

used for inbound SAP packets

Table 7-18 summarizes the items that can be matched by extended and standard IPX access

lists.

the interface

protocols

IPX Standard Source network

Source IPX address (network and node)

Source network and portions of the node address,

using a node mask

Destination network

Destination IPX address (network and node)

Destination network and portions of the node

address, using a node mask

IPX Extended Same points as with an IPX standard access list,

as well as the following points

Portions of source IPX address, using a wildcard

mask

Portions of destination IPX address, using a

wildcard mask

Protocol type

Source socket

Destination socket

The following list shows the fields that can be matched for each service advertised, or to be

advertised, in a SAP update.

As mentioned in Chapter 1, “All About the Cisco Certified Network Associate Certification,”

the questions and scenarios in this book are more difficult than what you should experience on

the actual exam. The questions do not attempt to cover more breadth or depth than the exam;

however, they are designed to make sure that you know the answer. Rather than allowing you

to derive the answer from clues hidden inside the question itself, the questions challenge your

understanding and recall of the subject. Questions from the “Do I Know This Already?” quiz

from the beginning of the chapter are repeated here to ensure that you have mastered the

chapter’s topic areas. Hopefully, these questions will help limit the number of exam questions

on which you narrow your choices to two options and then guess.

The answers to these questions can be found in Appendix A, on page 754.

255.255.255.0, from exiting serial 0 on some router. Allow all other packets.

going to hosts in network 128.1.0.0 and using a Web server in 128.1.0.0, to enter serial 0

on some router.

been configured and where they are enabled?

from getting out serial interface S0 and that would stop packets from 134.141.5.4 from

entering S0. Permit all other traffic.

to any Web server, to get out serial interface S0. Also, allow packets from 134.141.5.4

going to all TCP-based servers using a well-known port to enter serial 0. Deny all other

traffic.

from address 500.0000.0000.0001 destined for any node in network 4.

being advertised out a router’s serial 0 and serial1 interfaces.

number on all IP packets?

action, then the default action is to permit all other packets.

configuration mode. Immediately following, another access list configuration command

is added for the same access list. How many statements are in the list now, and in what

position is the newly added statement?

For questions 16 through 18, assume that all parts of the network in Figure 7-12 are up and

working. IGRP is the IP routing protocol in use. Answer the questions following Example

7-16, which contains an additional configuration in the Mayberry router.

would be discarded.

Why or why not?

Governor is allowed from hosts at any site, but so that no other access to hosts in Raleigh

is allowed.

logic is a best match of the list, rather than a first match in the list.

statement is issued in configuration mode. Immediately following, another access list

configuration command is added for the same access list. How many statements are in the

list now, and in what position is the newly added statement?

is issued in configuration mode. Immediately following, another access list configuration

command is added for the same access list. How many statements are in the list now, and

in what position is the newly added statement?

statement is issued in configuration mode. Immediately following, another access list

configuration command is added for the same access list. How many statements are in the

list now, and in what position is the newly added statement?

access-list 44 permit 180.3.5.13 0.0.0.0

!

interface serial 0

ip access-group 44

BEEF with a single command.

255.255.255.0, from exiting serial 0 on some router. Allow all other packets.

255.255.255.0, going to hosts in network 128.1.0.0 and using a Web server in 128.1.0.0,

to enter serial 0 on some router.

named extended) that can be enabled to prevent Telnet access into a router. What

configured to match the right packets?

password, use to find out what IPX access lists were enabled on which interfaces?

alone?

other interfaces?

Scenarios 7-1 through 7-3 all use Figure 7-13, each with a different set of requirements for

filtering. In each case, configure a correct access list for the routers and enable the access list.

Place the access list in the router that filters the unneeded packets as quickly as possible—that

is, before the packets have been sent far away from the originator.

The filtering criteria for Scenario 7-1 is as follows:

Again using the network diagram in Figure 7-13, create and enable access lists for a totally

different set of requirements. Place the access list in the routers to filter the unneeded packets

as quickly as possible—that is, before the packets have been sent far away from the originator.

The filtering criteria for Scenario 7-2 is as follows:

Again using the network diagram in Figure 7-13, create and enable access lists for a totally

different set of requirements. Place the access list in the router that filters the unneeded packets

as quickly as possible—that is, before the packets have been sent far away from the originator.

The filtering criteria for Scenario 7-3 is as follows:

specifically mentioned elsewhere in these criteria.

IPX packet and SAP filtering concepts and configuration are reviewed in this scenario. Sample

configurations are supplied first. Your job is to interpret the current access lists and then create

new packet access lists and SAP access lists to meet some additional criteria. The details are

listed after Figure 7-14 and Examples 7-17 through 7-20.

ipx routing 0200.1111.1111

!

interface serial0

encapsulation frame-relay

!

interface serial 0.1 point-to-point

ip address 168.10.12.1 255.255.255.0

ipx network 12

ipx access-group 801 in

frame-relay interface-dlci 52

!

interface serial 0.2 point-to-point

ip address 168.10.13.1 255.255.255.0

ipx network 13

ipx access-group 903 in

frame-relay interface-dlci 53

!

interface serial 0.3 point-to-point

ip address 168.10.14.1 255.255.255.0

ipx network 14

ipx access-group 903 in

frame-relay interface-dlci 54

!

interface ethernet 0

ip address 168.10.100.1 255.255.255.0

ipx network 100

!

access-list 903 deny any 102.0000.0000.0000 1.ffff.ffff.ffff all 100

access-list 903 permit any any

access-list 801 deny 101 100.0200.bbbb.bbbb

access-list 801 permit -1

ipx routing 0200.2222.2222

!

interface serial0

encapsulation frame-relay

!

interface serial 0.1 point-to-point

ip address 168.10.12.2 255.255.255.0

ipx network 12

frame-relay interface-dlci 51

!

interface ethernet 0

ip address 168.10.101.2 255.255.255.0

ipx network 101

Given the network in Figure 7-14 and the configurations in Example 7-17 through 7-20, answer

the questions and perform the tasks that follow.

in the remote sites access the servers in Atlanta?

ipx routing 0200.3333.3333

!

interface serial0

encapsulation frame-relay

!

interface serial 0.2 point-to-point

ip address 168.10.13.3 255.255.255.0

ipx network 13

frame-relay interface-dlci 51

!

interface ethernet 0

ip address 168.10.102.3 255.255.255.0

ipx network 102

ipx routing 0200.4444.4444

!

interface serial0

encapsulation frame-relay

!

interface serial 0.3 point-to-point

ip address 168.10.14.4 255.255.255.0

ipx network 14

frame-relay interface-dlci 51

!

interface ethernet 0

ip address 168.10.103.4 255.255.255.0

ipx network 103

The solution to fulfilling the criteria stipulated for this access list is straightforward. Simply

matching Grigory to permit his traffic and denying packets from 210.1.1.0 is all that is needed

for the first two criteria. A “permit all” needs to be explicitly configured at the end of the list.

Example 7-21 provides the solution for this scenario. The access list will be enabled on Nova.

The problem with list 43 is that if the link from Barnaul to Gorno goes down, and if Gorno

learns a route to Barnaul’s subnets via Nova, Nova will be filtering all inbound packets from

(non-Grigory) Gorno hosts. A better list would be to use an extended access-list, matching both

Many solutions could fulfill the criteria stipulated for this scenario. The solutions provided in

Examples 7-22 and 7-23 attempt to filter packets as close to the source of the packet as possible.

It is impossible to determine whether your correct solution is better than the one given here, or

vice versa, without more information about traffic loads and business needs in the network.

Comments shown inside the configurations in Example 7-22 and Example 7-23 provide most

of the detailed commentary.

access-list 43 permit host 210.1.1.1

access-list 43 deny 210.1.1.0 0.0.0.255

access-list 43 permit any

!

access-list 143 permit ip host 210.1.1.1 198.1.1.0 0.0.0.255

access-list 143 deny ip 210.1.1.0 0.0.0.255 198.1.1.0 0.0.0.255

access-list 143 permit ip any any

!

interface serial 0

ip access-group 43 in

!

interface serial 1

ip access-group 43 in

! Next statement meets Criterion 1

access-list 101 deny ip 10.1.4.0 0.0.0.255 210.1.1.0 0.0.0.255

! next statement meets criteria 4

access-list 101 deny ip host 10.1.4.98 any

! Criterion 5 met in the next statement

access-list 101 permit ip any any

Many solutions could fulfill the criteria stipulated for this scenario. The solutions provided in

Examples 7-24 and 7-25 attempt to filter packets as close to the source of the packet as possible.

It is impossible to determine whether your correct solution is better than the one given here, or

vice versa, without more information about traffic loads and business needs in the network.

Comments shown inside the configurations in Example 7-24 and Example 7-25 provide most

of the detailed commentary.

interface serial 0

ip access-group 101

!

interface serial 1

ip access-group 101

! Next statements meet Criterion 2

access-list 101 deny ip host 210.1.1.1 198.1.1.0 0.0.0.255

access-list 101 deny ip host 210.1.1.2 198.1.1.0 0.0.0.255

! Next statement meets Criterion 3, but it’s not required, due to the final

statement

access-list 101 permit ip 210.1.1.0 0.0.0.255 198.1.1.0 0.0.0.255

access-list 101 permit ip any any

!

interface serial 0

ip access-group 101

!

interface serial 1

ip access-group 101

! Next statements meet Criterion 3

access-list 101 permit tcp host 10.1.4.98 198.1.1.0 0.0.0.255 eq www

access-list 101 deny tcp host 10.1.4.98 198.1.1.0.0.0.0.25 lt 1023

! Next statement meets Criterion 5, but it’s not really needed

access-list 101 deny ip 10.1.4.0 0.0.0.255 198.1.1.0 0.0.0.255 eq www

! Criterion 6 is met in the default

!

interface serial 0

ip access-group 101

!

interface serial 1

ip access-group 101

The default action can be used to shorten the list. For example, in Example 7-24 the commands

because the default is to deny these anyway. So, list 101 would perform the same function if it

Refer to the network illustrated in Figure 7-14 and Examples 7-17 through 7-20 to establish the

Scenario 7-4 design details and the context of the answers to the three tasks for this scenario.

Task 1 for Scenario 7-4 asks you to characterize the traffic that is discarded due to the access

lists used on Atlanta. Furthermore, you need to determine whether clients in the remote sites

can access the servers in Atlanta. The answer is not obvious in this case. The extended access

list is particularly confusing, given all the options. The parameters coded in the first entry in list

903 in Example 7-17 are as follows:

so all 0s are coded in the node part of the address. The node part of the address must be

configured; otherwise, the syntax does not allow the right to use the network wildcard

mask.

! Next statements meet Criterion 1

access-list 101 permit tcp host 210.1.1.1 198.1.1.0 0.0.0.255 eq www

access-list 101 permit tcp host 210.1.1.2 198.1.1.0 0.0.0.255 eq www

! Next statements meet Criterion 2

access-list 101 deny tcp host 210.1.1.1 198.1.1.0 0.0.0.255 lt 1023

access-list 101 deny tcp host 210.1.1.2 198.1.1.0 0.0.0.255 lt 1023

! Next statement meets criterion 4

access-list 101 permit ip 210.1.1.0 0.0.0.255 198.1.1.0 0.0.0.255

!Default meets Criterion 6

!

interface serial 0

ip access-group 101

!

interface serial 1

ip access-group 101

the mask would be 00000001.ffff.ffff.ffff. This mask matches networks 102 and 103,

which are identical except for the final bit in the network part of the address. The mask

means, “all bits in the network must match network 102, except for the last bit in the

network number.” (All Fs for the node mean that any node number will match.)

So, the first entry in list 903 matches packets from network 102 and 103, destined for network

100, any protocol, any socket. These packets are denied. The second entry in 903 permits all

protocols, all source networks, and, by implication, all destination networks; in other words,

this statement changes the default to be “permit all else.”

By enabling list 903 for inbound packets on Atlanta’s serial 0.2 and serial 0.3 interfaces, clients

in Nashville and Boston cannot reach network 100.

Access list 801 stops all packets from network 101 from reaching Server 2’s Ethernet IPX

address. It also has a “permit everything else” statement at the end of the list, but because

Neither list stops access to Server 1 or Server 2 because the destination of packets to these

servers will be the internal IPX addresses (1000.0000.0000.0001 and 1001.0000.0000.0001).

Packets sent to networks 1000 and 1001 will not be matched until the “permit all” at the end of

the lists.

Task 2 for Scenario 7-4 asks you to create IPX packet filters to meet the following criteria:

This can be accomplished by configuring standard IPX access lists. Because the goal is to filter

packets close to the source, and because the client initiates the process of connecting to a server,

the filters all were placed at the remote routers and not in Atlanta. Each filter matches packets

sourced in their local IPX networks and destined for network 1000 (if filtering packets destined

for Server 1), or destined for network 1001 (if filtering packets destined for Server 2). Examples

7-26 through 7-28 show the configurations necessary to create IPX packet filters to satisfy the

criteria.

Task 3 for Scenario 7-4 asks you to create SAP filters that perform the same function as

described in Task 2. Task 3 suggests a very simple solution, but the simple solution works only

because there are local servers in Charlotte, Nashville, and Boston. First, take a look at the

solution; then read over some comments.

Because the local server in each case will be the GNS server for the local clients, respectively,

all that is needed is to stop Server 1 and Server 2 SAP information from being advertised into

the remote sites. In an effort to reduce overhead, the SAP filters will be placed in Atlanta

because SAP information originates in the servers. Example 7-29 provides the solution.

access-list 800 deny 101 1001

access-list 800 permit -1

!

interface serial 0.1 point-to-point

ipx access-group 800

access-list 800 deny 102 1000

access-list 800 permit -1

!

interface serial 0.2 point-to-point

ipx access-group 800

access-list 800 deny 103 1000

access-list 800 permit -1

!

interface serial 0.3 point-to-point

ipx access-group 800

access-list 1050 deny 1000

access-list 1050 permit -1

!

access-list 1051 deny 1001

access-list 1051 permit -1

!

interface serial 0.1 point-to-point

ipx output-sap-filter 1051

!

interface serial 0.2 point-to-point

ipx output-sap-filter 1050

!

interface serial 0.3 point-to-point

ipx output-sap-filter 1050

SAPs about Server 1 (network 1000) are filtered from being sent out serial 0.2 and serial 0.3 to

Nashville and Boston, respectively. Likewise, SAPs about Server 2 (network 1001) are filtered

from being sent out serial 0.1 to Charlotte. Server 3 will not know about Server 2, so it cannot

tell Charlotte clients about Server 2. Likewise, Server 4 and Server 5 will not know about Server

1, so they cannot tell Nashville clients and Boston clients about Server 1.

SAP filters are also great for reducing traffic, of course. However, when using them for stopping

particular clients and servers from communicating, there are some caveats. If no servers were

in place in Charlotte, Nashville, or Boston, the remote clients would have used Server 1 or

Server 2 as their GNS server. Server 1 and Server 2 have full knowledge of each other’s SAP

information because they are on the same Ethernet. Therefore, clients would be capable of

connecting to the servers, in spite of efforts to prevent the connections using SAP filtering.