Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

Configuring IPX Routing Protocols

   

< Back Contents Next >

IPX Basics

  

 

IPX Addressing and Address Structure

  

 

Configuring IPX Addresses

  

 

IPX Routing Configuration

  

 

Configuring IPX Routing Protocols

  

 

Configuring IPX Filtering via Access Lists

  

 

Configuring Basic IPX Dialup Services

  

 

Verifying IPX Connectivity and Troubleshooting

  

 

Configuring IPX Type 20 Packet Forwarding

  

 

Summary

  

 

References

Save to MyCKS

 
Cisco Router Configuration

From: Cisco Router Configuration
Author: Bruce Pinsky; Allan Leinwand; Mark Culpepper
Publisher: Cisco Press (53)
More Information

Configuring IPX Routing Protocols

In Chapter 4 we discussed the following issues, which you need to consider when choosing a dynamic routing protocol:

  • Network topology

  • Address and route summarization

  • Convergence speed

  • Route selection criteria

  • Scalability

  • Ease of implementation

  • Security

In the Cisco IOS there are multiple dynamic IPX routing protocols. When choosing the optimal protocol for your network, you need to consider the preceding criteria.

Before delving into the individual dynamic routing protocols, however, we must consider SAP. SAP is a dynamic service protocol that is tightly coupled with dynamic IPX routing protocols. After explaining SAP, we discuss the IPX dynamic routing protocols IPX RIP, NLSP, and IPX EIGRP.

SAP

SAP (Service Advertisement Protocol) is a Novell proprietary protocol that advertises NetWare services on an IPX network. A service is a resource that IPX clients may want to use, such as a file service or print service. All services have a service type, which is denoted by a hexadecimal number. Some service types are defined by Novell, while others are proprietary to vendors that make services for NetWare. For example, SAP type 4 is the standard service type for NetWare file service.

By default, NetWare servers broadcast SAP packets every 60 seconds to advertise known services. Each NetWare server learns of SAP services in much the same way that it learns dynamic routing protocol information and builds a table of that information called a SAP table.

Cisco routers enable SAP by default for all interfaces configured for IPX. A router builds a SAP table from SAP information learned from NetWare servers and from other routers. To view the SAP table on a Cisco router, use the IOS EXEC command show ipx servers. The following example shows the output from show ipx servers on the ZIP network's SF-1 router:

SF-1#show ipx servers
Codes: S - Static, P - Periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail
2 Total IPX Servers
Table ordering is based on routing and server info
Type Name                Net  Address       Port    Route   Hops     Itf
P    4 SF-MAIN           100.0001.0002.0006:0451    2/01    1        Et0
P    4 SF-ENG            100.0809.0001.0002:0451    2/01    1        Et0

This output shows that the SF-1 router has learned of two IPX servers, each offering a file service (shown as the number four in the first part of the server name). For each IPX service, you can see the IPX address of the server offering the service, the IPX route metric for the service, and the interface where the router heard the service. Both of the services in this example are identified as periodic, which means that they were learned by SAP (which advertises services on a regular periodic interval). We explore other methods to learn about IPX services in the discussions of NLSP and EIGRP later in this chapter.

Just as you can have static IPX routes, you can have static SAP table entries. You can define static SAP table entries using the global configuration command ipx sap. Static SAP table entries may be useful in some network environments, such as those that utilize dialup or dial backup.

After a server or router has a SAP table, it can respond to NetWare clients that ask for services. NetWare clients send IPX Get Nearest Server (GNS) messages to look for a server that can provide the services they need. NetWare servers that know about the service can respond to the client, giving it the specific IPX address where the service resides. A Cisco router can also respond to clients with the IPX address of a service if the service is in the router's SAP table. If a Cisco router hears a GNS message on a LAN segment where the service is known to exist, the router does not answer the GNS message.

NOTE

The Nearest Server is defined as one that provides the service and has the shortest route in the SAP table. If multiple servers match this criteria, a Cisco router responds with the server most recently heard. This could result in multiple NetWare clients receiving GNS responses for the same server—not an optimal situation if the IPX network has multiple servers providing the same service for load balancing of client requests.

Use the ipx gns-round-robin global configuration command to tell the router to rotate in round-robin fashion through a set of eligible servers when it responds to GNS requests. See the “SAP Filters” section that follows for information on filtering GNS responses sent by a router on specific interfaces.

SAP Filters

The Cisco IOS permits a network administrator to filter on the basis of which SAP services a device sends from and receives into its SAP table. SAP filters are commonly used on an internetwork to limit the amount of SAP traffic sent and received by a router.

Many IPX networks use SAP filters to reduce the number of SAP messages sent over WAN interfaces, thereby reducing traffic load. Filtering received SAP advertisements can reduce the number of IPX services a router has in RAM and provide limited network security. The limited network security is accomplished by not allowing the IOS device to provide SAP table entries for services that want to remain somewhat hidden on an IPX network. For more information on filtering IPX packets, see “Configuring IPX Filtering via Access Lists” later in this chapter.

You can use the global configuration command access-listto make SAP filters based on IPX addresses or the SAP service type. SAP filters use access-list numbers 1000 through 1099. Like IP and AppleTalk access lists, these access lists allow for the use of wildcard or “don't care” masks. This capability enables a single IOS global configuration access list command to represent multiple IPX addresses.

In the following example on ZIP's San-Jose router, we make a SAP filter to only permit SAP services advertised by the single NetWare server 10.0000.0000.a0b0:

San-Jose#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
San-Jose(config)#access-list 1000 permit 10.0000.0000.a0b0
San-Jose(config)#access-list 1000 deny -1
San-Jose(config)#^Z

NOTE

When building SAP filters (and IPX access lists for packet filters, as discussed later in this chapter), the IPX network number -1 denotes all IPX networks. Thus, in the preceding example, the second line of access list 1000 denies all SAPs. Like access lists in IP, a final deny line is implicit in IPX access lists. The explicit configuration is shown here only to illustrate the use of the -1 IPX network number.

After configuring a SAP filter, you must apply it to a given interface on the IOS device. You can filter on SAP messages received or sent by the device on an interface basis using the ipx input-sap-filter and ipx output-sap-filter interface configuration subcommands. We apply a SAP filter using access list 1000 to all output SAP advertisements on interface Serial 0 of the San-Jose router:

San-Jose#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
San-Jose(config)#interface serial 0
San-Jose(config-if)#ipx output-sap-filter 1000
San-Jose(config-if)#^Z

As another example, you may want to build a SAP filter that permits, from all servers, only file and print services to be advertised over a WAN interface. In the following example, we build a SAP filter to only allow file service (SAP type 4) and print service (SAP type 7) from all servers. We apply this filter to the SAP output advertisements on interface Serial 0 of the San-Jose router on the ZIP network:

San-Jose#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
San-Jose(config)#access-list 1005 permit -1 4
San-Jose(config)#access-list 1005 permit -1 7
San-Jose(config)#interface serial 0
San-Jose(config-if)#ipx output-sap-filter 1005
San-Jose(config-if)#^Z

Another type of SAP filter permits or denies NetWare services based on the IPX address of a router. One application of this type of SAP filter is to hide all services originating from a given router. The IOS interface configuration command ipx router-sap-filter applies a router SAP filter to a given interface. In the following example, we apply a router SAP filter to interface Fddi 0/0 of the Zip network's SF-Core-1 router to hide all NetWare services from an engineering server:

SF-Core-1#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
SF-Core-1(config)#access-list 1001 permit aa.0207.0104.0874
SF-Core-1(config)#interface fddi 0/0
SF-Core-1(config-if)#ipx router-sap-filter 1001
SF-Core-1(config-if)#^Z

The Cisco IOS enables you to filter, on a per interface basis, which SAP table services are eligible as responses to GNS queries sent by NetWare clients. Using a GNS filter on the output of an interface is useful in preventing clients from ever identifying specific servers as the Nearest Server or in forcing all GNS queries to be handled by a specific server. In the following example on the SF-Core-1 router, we specify an IPX access list to permit a single NetWare server to be used as an answer to GNS queries. We apply this access list as an output GNS filter to the Fddi 0/0 interface of the SF-Core-1 router by using the IOS interface configuration subcommand ipx output-gns-filter:

SF-Core-1#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
SF-Core-1(config)#access-list 1010 permit aa.0207.0104.0874
SF-Core-1(config)#interface fddi 0/0
SF-Core-1(config-if)#ipx output-gns-filter 1010
SF-Core-1(config-if)#^Z

Configuring IPX RIP

IPX RIP is a NetWare dynamic routing protocol similar in function to IP RIP. IPX RIP is a distance vector routing protocol that establishes and maintains IPX routing tables between IPX routers and NetWare servers. We discussed IP RIP and the properties of distance vector routing protocols in Chapter 4. IPX RIP is an interior gateway protocol (IGP). There is no exterior gateway protocol (EGP) routing protocol in IPX because NetWare runs on intranets, not over the public Internet. IPX RIP is enabled on all IPX interfaces by default when you use the global configuration command ipx routing.

IPX RIP was the first dynamic routing protocol for IPX networks, so it lacks some advanced features of newer dynamic routing protocols in terms of address and route summarization, convergence speed, route selection criteria, and scalability. As you will see later in this section, NLSP and EIGRP—more modern dynamic routing protocols for IPX—solve some of these issues.

While IP RIP uses hop count as its routing metric, IPX RIP uses a different metric, known as clock ticks, to make routing decisions. A clock tick represents one-eighth of a second. The clock tick metric for a destination is measured by examining the bandwidth on the interface used to reach that destination. In the output of show ipx route from the SF-2 router, the route to IPX network 100 has a metric of two clock ticks and one hop, shown as “[02/01]” in the IPX routing table:

SF-2#show ipx route
Codes:     C - Connected primary network, c - Connected secondary network
S - Static, F - Floating static, L - Local (internal), W - IPXWAN
R - RIP, E - EIGRP, N - NLSP, X - External, A - Aggregate
s - seconds, u - uses

4 Total IPX routes. Up to 1 parallel paths and 16 hops allowed

No default route known.

C         10 (NOVELL-FDDI),  Fd0
C        150 (NOVELL-ETHER),  Et1
C        200 (NOVELL-ETHER),  Et0
R 100 [02/01] via 100.0000.1c2c.23bb, 19s, Fd0

If the number of clock ticks to reach a destination is equal for multiple routes in the IPX RIP routing table, the router uses the shortest number of router hops to break the tie. IPX RIP has a default maximum hop count of 16, just like IP RIP. Like all routed protocols in the IOS, the router load shares the traffic to the destination through all available equal-cost paths if the routing table has equal-cost paths (both clock ticks and router hops tie).

NOTE

By default, a router using the Cisco IOS does not learn about multiple IPX parallel equal-cost paths to a given destination. The router learns a single path to a destination and discards information about alternative parallel equal-cost paths, as indicated by the show ipx route phrase “Up to 1 parallel paths and 16 hops allowed.” This default behavior is based on the implementation of some NetWare clients and services that cannot handle IPX packets arriving out of order—which can happen when load sharing occurs over parallel equal-cost paths.

To enable a router to place equal-cost paths in its IPX routing table, use the global configuration command ipx maximum-paths. For example, the command ipx maximum-paths 2 allows the router to learn about two equal-cost paths for a given destination. The number of equal-cost paths you enable on your router depends on your IPX network topology.

The default behavior of a Cisco router is to load share on a per packet basis over all parallel equal-cost paths for a destination IPX address. For performance reasons, you may want all packets for each unique destination IPX address to take the same path even if multiple equal-cost paths exist. To enable this feature, use the IOS global configuration command ipx per-host-load-share.

Configuring NLSP

NLSP is a link state interior gateway protocol for IPX networks. NLSP, which is based on the OSI Intermediate System-to-Intermediate System (IS-IS) protocol, has features similar to those of other link state protocols, such as OSPF. Like other link state protocols, NLSP supports hierarchical addressing and fast convergence.

NLSP has the capability to use hierarchical routing techniques to aggregate and summarize IPX network numbers. Route aggregation and summarization are useful in large IP networks for the same reasons they are useful in large IPX networks.

The first level in NLSP routing is an area. A NLSP area is a logical group of IPX network addresses; it is conceptually similar to an OSPF area, which is a collection of IP networks and subnets. NLSP level 1 routing occurs within an area. NLSP communication between areas is called level 2 routing. You can group all areas with NLSP routers communicating with level 2 routing into a hierarchical collection called a routing domain. NLSP communication between routing domains is level 3 routing. Figure 6-3 shows an NLSP internetwork.

Figure 6-3. The hierarchical structure of a NLSP IPX network.

NLSP requires an internal IPX network number to be configured on a Cisco router. You can do so by using the IOS global configuration command ipx internal-network, as noted earlier in this chapter in the “IPX Addressing and Address Structure” section.

To enable NLSP, use the IOS global configuration command ipx router nlsp. This configuration command requires that a tag parameter be used to specify the NLSP process in the IOS. To define a set of network numbers as part of the current NLSP area, use the area-address IOS global configuration command. The area-address command takes two options, an IPX network address and a mask. The mask indicates how much of the area number identifies the area and how much of that number identifies individual networks in the area. Although we do not use NLSP in the ZIP network, the following example shows the enabling of NLSP on the Singapore router. The following use of the area-address command describes an area of 16 networks in the range of 4000 through 400F:

Singapore#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
Singapore(config)#ipx router nlsp 1
Singapore(config-ipx-router)#area-address 4000 FFF0
Singapore(config-ipx-router)#^Z

NLSP needs to be enabled on a per interface basis using the IOS interface subcommand ipx nlsp enable. This configuration command specifies the NLSP process tag to use when sending routing information on a given interface. We enable NLSP process 1 on the Singapore router's interface Ethernet 0 in the following example:

Singapore#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
Singapore(config)#interface ethernet 0
Singapore(config-if)#ipx nlsp 1 enable
Singapore(config-if)#^Z

Configuring IPX EIGRP

You can use EIGRP as an IPX dynamic routing protocol. As seen in earlier chapters, EIGRP offers features found in link state protocols, such as partial incremental updates and decreased convergence time. To enable EIGRP for IPX, use the major configuration command ipx router eigrp. This command requires an autonomous system number to identify the EIGRP process.

The subcommand network associates an IPX network number with EIGRP, instructing EIGRP to pass routing information about that IPX network number. In the following example, we enable EIGRP for IPX on the Singapore router using autonomous system number 25000. We tell EIGRP to pass routing information about IPX networks 4010 and 2902:

Singapore#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line. End with CNTL/Z.
Singapore(config)#ipx router eigrp 25000
Singapore(config)#network 4010
Singapore(config-ipx-router)#network 2902
Singapore(config-ipx-router)#^Z

TIP

You can enable EIGRP for all IPX networks on a router using the router subcommand network all.

When using IPX EIGRP, you can make the IOS send SAP messages periodically or only when a change occurs in the SAP table. EIGRP sends periodic SAP messages by default on LAN interfaces, allowing SAP advertisements to reach IPX servers and clients. Periodic SAP messages are also sent by default on any interface that does not have any EIGRP routers because the interface can connect to IPX servers and clients.

If an interface has only EIGRP routers, you can configure EIGRP to send SAP messages only when a change occurs in the SAP table. This feature can help reduce the traffic on WAN interfaces that interconnect IOS devices by eliminating periodic SAP messages that consume bandwidth. If an EIGRP router is present on a WAN interface, the default behavior of the IOS is to send SAP updates only when the SAP table changes.

To send SAP messages only when a change occurs in the SAP table, use the IOS interface configuration subcommand ipx sap-incremental-eigrp. This command requires as a parameter the autonomous system number for EIGRP. The output from the IOS EXEC command show ipx servers tells you whether an IPX service was learned from a periodic SAP update or from EIGRP.

   

< Back Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.