Filtering IPX Traffic and SAPs

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.

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. Table 11-9 lists the configuration commands used for these filters; Table 11-10 lists the exec commands related to IPX filtering.

Table 11-9 IPX Access List Configuration Commands

Command

Configuration Mode and Purpose

access-list {800-899} {permit I deny} source-

Global command to create numbered standard

network [.source-node [source-node-mask]]

IPX access lists

[destination-network [.destination-node

[destination-node-mask]]]

access-list {900-999} {permit I deny} protocol Global command to create numbered extended

[source-network] [[[.source-node [source-node- IPX access lists mask]] I [.source-node source-network-

mask.source-node-mask]] [source-socket]

[destination-network] [[[.destination-node

[destination-node-mask] I [.destination-node destination-network-mask. destination-node-

mask]] [destination-socket] log access-list {900-999} {permit I deny} protocol Global command to create numbered extended

[source-network] [[[.source-node [source-node- IPX access lists mask]] I [.source-node source-network-

mask.source-node-mask]] [source-socket]

[destination-network] [[[.destination-node

[destination-node-mask] I [.destination-node destination-network-mask. destination-node-

mask]] [destination-socket] log

Table 11-9 IPX Access List Configuration Commands (Continued)

Command Configuration Mode and Purpose access-list {1000-1099} {permit I deny} network Global command to create numbered SAP access

[.node] [network-mask.node-mask] [service-type lists

[server-name]]

ipx access-list {standard I extended I sap } name Global command to begin creation of a named standard, extended, or SAP access list

{permit I deny} source-network [.source-node Named access list subcommand for standard [source-node-mask]] [destination-network access lists

[.destination-node [destination-node-mask]]]

{permit I deny} protocol [source-network] Named access list subcommand for extended

[[[.source-node [source-node-mask]] I [.source- access lists node source-network-mask.source-node-mask]]

[source-socket] [destination-network]

[[[.destination-node [destination-node-mask] I

[.destination-node destination-network-mask.

destination-node-mask]] [destination-socket] log

{permit 1 deny} network [.node] [network-

Named access list subcommand for SAP access

mask.node-mask] [service-type [server-name]]

lists

ipx access-group {number 1 name [in 1 out] }

Interface subcommand to enable a named or

numbered, standard or extended IPX access list

ipx output-sap-filter list-number

Interface subcommand to enable SAP access lists

used for outbound SAP packets

ipx input-sap-filter list-number

Interface subcommand to enable SAP access lists

used for inbound SAP packets

Table 11-10 IPX Access List EXEC Commands

Command

Function

show ipx interface

Includes a reference to the access lists enabled on

the interface

show access-list number

Shows details of all configured access lists for

all protocols

show ipx access-list

Shows details of all IPX access lists show ipx access-list

Shows details of all IPX access lists

Access lists for filtering packets are covered next; SAP filters are covered in the section "SAP Access Lists."

IPX Packet Filters (Access Lists)

Packet filters in the Cisco IOS use the same general logic for any Layer 3 protocol. Figure 11-12 outlines the path that 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 11-12 are as follows:

• Packets can be filtered as they enter an interface, before the routing decision.

• Packets can be filtered before they exit an interface, after the routing decision.

• "Deny" is the term used in IOS to imply that the packet will be filtered.

• "Permit" is the term used in IOS to imply that the packet will not be filtered.

• The filtering logic is configured in the access list.

The logic created by an access list, as shown in the diamond-shaped symbols in Figure 11-12, is best summarized by the following sequence of events:

Step 1 The matching parameters of the first access list statement are compared to the packet.

Step 2 If a match is made, the action defined in this access list statement (permit or deny) is performed, as shown in Figure 11-12.

Step 3 If a match is not made in Step 2, repeat steps 1 and 2 using the next sequential access list statement.

Step 4 If no match is made with an entry in the access list, the deny action is performed.

Figure 11-12 Locations Where Access List Logic Can Be Applied

Router

Figure 11-12 Locations Where Access List Logic Can Be Applied

Router

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.

Standard IPX 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 Interconnecting Cisco Network Devices.

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 they use a wildcard mask to examine the node part of the IPX addresses.

Figure 11-13 and Example 11-12 provide an example network and configuration.

Figure 11-13 IPX Standard Access List Example

2001

Figure 11-13 IPX Standard Access List Example

2001

Telefonanschluss

Example 11-12 R1 Configuration for Standard IPX Access Lists

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 i

interface ethernet 0

ip address 10.1.200.1 255.255.255.0

ipx network 200

ipx access-group 810 i

access-list 810 deny 101

access-list 810 permit -1 i

access-list 820 permit 302

R2#show access-list

IPX access list 810

deny 101

permit FFFFFFFF

IPX access list 820

permit 302

***Production, insert 2 pt rule here

R1#show ipx interface s 1

Serial1 is up, line protocol is up

IPX address is 1002.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 11-13 and Example 11-12:

1 Packets from network 101 are not allowed onto network 200.

2 Packets from network 102 are allowed onto network 200.

3 Packets from network 301 are not allowed onto network 200, 101, or 102.

4 Packets from network 302 are allowed to go anywhere.

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.

First, consider the logic in access-list 810, which is used to meet the first two criteria. The list denies access from source network 101 and permits all other source network numbers through 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, 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.

Next consider the logic in access-list 820. This permits only source network 302 and denies all other source networks because of 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 in Example 11-12. access-list 810 uses the keyword -1, which means any and all network numbers. No destination networks are checked with either access list, which is allowed with IPX standard access lists. Also, the optional node mask is not used and is not useful very often. For example, imagine that a requirement was added so that packets from clients 5 and 6 were 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 with 200.0200.1234, the following access-list command could match packets from these 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 that it is configured as a hexadecimal number. The final four f digits mean that the final four hex digits in the node part of the address automatically are considered to match, but 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 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 almost never will 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 11-12—or, more accurately, the criteria used for Example 11-12. Note that the criteria all mentioned network numbers but not servers. 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 Example 11-12, the effect is an interesting mental exercise. access-list 810, with the explicit "permit all," would permit the client/server traffic exiting R1's Ethernet0, while access-list 820, 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:

1 Packets from Server 1 are not allowed onto network 200.

2 Packets from Server 2 are allowed onto network 200.

3 Packets from Server 3 are not allowed onto networks 200, 101, or 102.

4 Packets from Server 4 are allowed to go anywhere.

5 All combinations not mentioned should be permitted.

The new configuration in Example 11-13 successfully focuses on the servers' network numbers, not the network numbers on the LAN segments.

Example 11-13 Configuration for Standard IPX Access Lists, Modified 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 !

Example 11-13 Configuration for Standard IPX Access Lists, Modified (Continued)

access-list 810 deny 2001 access-list 810 permit -1

access-list 820 deny 3001 access-list 820 permit -1

Extended IPX Access Lists

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 be matched using a standard or extended IPX access-list command. Table 11-11 summarizes those items, and Figure 11-14 shows the relative location of the fields in the headers.

Figure 11-14 Header Fields Matchable Using IPX Access Lists

IPX header

5

1

6

4

2

6

4

2

Miscellaneous header fields

Packet type

Destination node

Destination network

Destination socket

Source node

Source network

Source socket

RIP, SAP, NCP, SPX, NetBIOS

Defines what's over here

i

V

Table 11-11 IPX Standard and Extended Access Lists—Matching

Table 11-11 IPX Standard and Extended Access Lists—Matching

Type of Access List What Can Be Matched

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 type is a field that is not shown in many examples in other references, such as the Cisco IOS documentation CD. Figure 11-15 shows example packets that would be matched by the various protocol types.

Figure 11-15 Extended Access List Protocol Types

IPX

NetBIOS

IPX

SPX

IPX

SPX

NCP

Data

SPX+ NCP

IPX

RIP

IPX

SAP

The protocol names, particularly the SAP protocol type, can be misleading. Extended access lists can be used to filter entire SAP packets; the 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, but not the routing information in the RIP update. The most practical use of the protocol type parameter is for NetBIOS. If NetBIOS is not an issue, most sites use the any keyword for the protocol type.

The socket parameter is similar to a TCP or UDP port number. Novell assigns socket values to applications to create the equivalent of a TCP or UDP well-known port. Clients dynamically assign sockets in the range of 4000 to 7FFF, and Novell assigns sockets to applications in the range of 8000 to FFFF. As with IP, there is both a source and a destination socket, used for multiplexing.

NOTE Do not confuse SAP type with socket. A file server advertises SAP Type 4 but does not use 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 11-16 and Example 11-14 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:

1 Clients in networks 100 and 101 are allowed access to Server 3 and Server 4.

2 Clients in network 300 are not allowed to access Server 1 and Server 2.

Figure 11-16 IP Extended Access List Example

Figure 11-16 IP Extended Access List Example

Example Ipx
Example 11-14 Configuration for Extended IPX Access Lists

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 ipx network 100

255.0

interface ethernet 1 ip address 10.1.101.2 255.255 ipx network 101

255.0

access-list 910 deny any 1000 access-list 910 permit any -1

0000000F

access-list 910 actually checks for packets sourced from networks 1000 to 100F. The network 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.)

SAP Filters

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:

Step 1 A router or server decides that it is time to send a SAP broadcast on its attached network, based on the expiration of its SAP timer.

Step 2 That router or server creates enough SAP packets to advertise all its SAP information (up to seven services per packet, by default).

Step 3 That router or server sends the SAP packets out into the attached network.

Step 4 Other routers and servers are attached to the same medium; these routers and servers receive all the SAP packets.

Step 5 The receiving routers and servers examine the information inside the SAP packets and update their SAP tables as necessary.

Step 6 The receiving routers and servers discard the SAP packets.

Step 7 Every server and router uses a SAP timer, which is not 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 packets going through a router. Therefore, the IOS uses distribute lists (instead of packet filters) 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 11-17 outlines the process.

Figure 11-17 SAP Filter Flow Diagram

Router

Figure 11-17 SAP Filter Flow Diagram

Router

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 11-15.) SAP filters will be used to accomplish the same set of criteria that was mentioned with Example 11-14 and Figure 11-16. As a reminder, the criteria for that filter is as follows:

1 Clients in networks 100 and 101 are allowed to access Server 3 and Server 4.

2 Clients in network 300 are not allowed to access Server 1 and Server 2.

Example 11-15 R1 Configuration for SAP 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 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 filtered; the -1 keyword signifies all networks. (Extended IPX access lists can use the keyword any. SAP filters do not currently use that keyword.) So, there will never be an entry in R1's SAP 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 11-8 outlined the process earlier in the chapter.) 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 release; 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 both 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 clients can connect only to servers in the SAP table of their GNS server.

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 than IPX packet filters.

The following list shows the fields that can be matched for each service advertised, or to be advertised, in a SAP update:

• Source network

• Source IPX address (network and node)

• Portions of the source address, using a wildcard mask

• Destination network

• Destination IPX address (network and node)

• Portions of the destination address, using a wildcard mask

Was this article helpful?

0 0

Post a comment