Novell Internetwork Packet Exchange (Novell IPX)

Understanding and Troubleshooting Common Novell IP and IPX Issues

Document ID: 10564

Updated: Oct 05, 2005




This document provides some miscellaneous information related to the IPX protocol. Our idea is not to fully document Novell, but rather create a minimal list of frequent questions classified by themes.



There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.


Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

Understanding IPX Network Numbers

As with other network addresses, Novell IPX network addresses must be unique. These addresses are represented in hexadecimal format and consist of two parts: a network number and a node number. The IPX network number, which is assigned by the network administrator, is 32 bits long. The node number,which usually is the Media Access Control (MAC) address for one of the system's Network Interface Cards (NICs), is 48 bits long.

  • Network

    • 32 bit number represented in Hex

    • Administratively assigned

    • Range: 0x00000001 - 0xFFFFFFFE

    • 0xFFFFFFFF = Broadcast

    • 0xFFFFFFFE = Default route

  • Node:

    • 48 bit number represented in Hex

    • MAC address of NIC card (can be administratively assigned )

IPX's use of a MAC address for the node number enables the system to send nodes to predict what MAC address to use on a data link. (In contrast, because the host portion of an IP network address has no correlation to the MAC address, IP nodes must use the Address-Resolution Protocol (ARP) to determine the destination MAC address.)

The addressing scheme originally allowed 0xFFFFFFFE to be used as an address. Following the introduction of NLSP, network -2 is used to represent default route. Cisco routers will treat 0xFFFFFFFE as a default route, although it is adjustable.

Examples of Network.Node Addresses



Understanding Internal and External Network Numbers on Novell Servers

Since the introduction of NetWare 3.x, the server architecture has been modularly constructed and each process (gateway, routing, file, print) communicates with the multitasking core OS engine. The core OS engines are assigned an IPX network address known as the internal network number, and that node ID is always 0000.0000.0001. Therefore, each Novell 3.x/4.x Server has an internal network number with an external network number bound to the network adapter. The network adapter may be bound to multiple network addresses each with an unique frame type. In addition, Novell Servers may contain multiple network adapters and route between the separate network segments. A Microsoft NT Server running IPX will not appear with node ID of 0000.0000.0001 and does not use the concept of internal and external network number by default.


Novell Encapsulation

There are many different Novell encapsulations. For Ethernet only, there are as many as four. The encapsulation type is very important as two devices using different encapsulation methods on the same medium will not be able to communicate. Novell clients are generally able to adapt to the encapsulation available on their links, but IPX servers must have a consistent encapsulation type hardcoded.

Encapsulation names are different in Novell or Cisco terminology. The following table provides a summary of the IPX encapsulations available for different types of media.

IPX Encapsulation Naming Conventions

Cisco IOS Naming Convention Cisco Catalyst Switch Naming Convention * Novell Software Naming Convention LSAP Description
Ethernet Novell-Ether 8023RAW Ethernet_802.3 (raw) FFFF Ethernet with no LLC or SNAP
ARPA Ethernet II (EII) Ethernet_II 8137 Ethernet II s/ type 8137
SAP 8023 Ethernet_802.2 E0E0 Ethernet with 802.2 envelope
SNAP SNAP Ethernet_SNAP AAAA Ethernet s/ 802.2 envelope + SNAP
SAP SAP FDDI_802.2 E0E0 FDDI using 802.2 envelope
Token Ring SAP n/a Token Ring E0E0 Token Ring w/ 802.2
SNAP n/a Token Ring_SNAP AAAA Token Ring w/ 802.2 + SNAP

  • Frame Type ETHERNET_802.3 is Novell's proprietary encapsulation. They put SPX/IPX packets directly within 802.3 frames and do not use 802.2 LLC or SNAP. This is Novell Encapsulation NOVELL-ETHER in Cisco's terminology.

  • Frame Type ETHERNET_II is "standard" Ethernet II framing. The SPX/IPX packets are stuffed into Ethernet II frames, using type code 8137. These frames differ from the NOVELL frames only in the two-octet type code/frame length field; otherwise, they are identical. This is Novell Encapsulation ARPA in Cisco's terminology.

  • Frame Type ETHERNET_802.2 is Novell's preferred encapsulation for Netware 3.12, Netware 4.X servers: it is Ethernet with 802.2 envelope. This is Novell Encapsulation SAP for 9.21 in Cisco's terminology.

  • Frame Type ETHERNET_SNAP is Ethernet with 802.2 envelope + SNAP. This is generally not used. This is Novell Encapsulation SNAP in Cisco's terminology.

* IPX configurations on Catalyst Series Switches apply only for Ethernet to FDDI bridging configurations.

IPX Routing Protocols

Using the protocols listed below, the routes and services an IPX router knows of can be defined and managed dynamically:

  • SAP (Service Advertisement Protocol): An IPX protocol that allows network resources such as servers and routers to become known to network clients. SAP is required for determining where individual network services reside on the internetwork.

  • RIP (Routing Information Protocol): An Interior Gateway Protocol (IGP) that uses hop count and ticks as routing metrics. Hop count measures the distance between a source and destination. The round-trip response time between the source and destination is measured in ticks, or 1/18 second intervals. RIP learns, selects, and maintains the routing table. RIP is a distance vector protocol used to exchange routing information within an independent system.

    • RIP and SAP work together as a team to help clients, servers, and routers find network services, and routes to each service. They are also used for client-to-server communications as well as router-to-router communications.

  • IPX EIGRP: IGRP is Cisco's Interior Gateway Routing Protocol used in TCP/IP and OSI internets. IGRP uses distance vector routing technology so that each router need not know all the router/link relationships for the entire network. Each router advertises destinations with a corresponding distance. Each router hearing the information adjusts the distance and propagates it to neighboring routers.

    • The distance information in IGRP is represented as a composite of available bandwidth, delay, load utilization, and link reliability. This allows fine tuning of link characteristics to achieve optimal paths EIGRP is an enhanced version of IGRP. The same distance vector technology found in IGRP is also used in EIGRP, and the underlying distance information remains unchanged. The convergence properties and the operating efficiency of this protocol have improved significantly. This allows for an improved architecture while retaining existing investment in IGRP. For details on the EIGRP, please see the following document:

      Introduction to Enhanced IGRP (EIGRP)

      The protocol dependent modules are responsible for network layer protocol specific requirements. For example, the IPX-EIGRP module is responsible for sending and receiving EIGRP packets that are encapsulated in IPX. IPX-EIGRP is responsible for parsing EIGRP packets and informing Diffusing Update Algorithm (DUAL) of the new information received. IPX-EIGRP asks DUAL to make routing decisions the results of which are stored in the IPX routing table. IPX-EIGRP provides the following features.

    • Automatic Redistribution - IPX RIP routes are automatically redistributed into EIGRP and IPX-EIGRP routes are automatically redistributed into RIP without any commands being entered by the user. Redistribution can be turned off with the use of the no redistribute protocol router subcommand. Both IPX-RIP and IPX-EIGRP can be turned off completely on the router.

    • Increased network width - With IPX RIP, the largest possible width of your network is 15 hops. When IPX-EIGRP is enabled the largest possible width is 224 hops. Since the EIGRP metric is sufficiently large enough to support thousands of hops, the only barrier to expanding the network is the transport layer hop counter. Cisco works around this problem by only incrementing the transport control field when an IPX packet has traversed 15 routers and the next hop to the destination was learned via EIGRP. When a RIP route is being used as the next hop to the destination, the transport control field is incremented as usual.

    • Incremental SAP updates - Complete SAP updates are sent periodically until an EIGRP neighbor is found and thereafter only when there are changes to the SAP table. This works by taking advantage of EIGRP's reliable transport mechanism so an IPX-EIGRP peer must be present for incremental SAPs to be sent. If no peer exists on a particular interface, then periodic SAPs will be sent on that interface until a peer is found. This functionality is automatic on serial interfaces and may be configured on LAN media if desired.

  • NLSP (NetWare Link Services Protocol): This routing protocol can be used in conjunction with, or instead of SAP and RIP. It addresses the limitations of RIP and SAP when they are implemented in large, complex internetworks. Typically, NLSP uses less bandwidth, is quicker at updating its routing table, and is more scaleable to large internetworks than RIP and SAP. NLSP is not a commonly used IPX Routing Protocol.

Novell IPX Network Case Studies

Case Study #1: Cisco to 3Com Interoperability on WAN Interfaces

By default, Cisco routers are configured for Periodic SAP Updates that occur every 60 seconds on all interfaces. However, on Enterprise 3Com routers, the WAN interface is configured for Non-Periodic SAP Updates by default. Non-Periodic Updates are SAP Updates that occur only when a link comes up, when the link is downed administratively, or when service information changes instead of a periodic interval. This parameter is supported for SAP updates only. When connecting a Cisco router with a 3Com router running IPX over a WAN interface with a default IPX configuration, the IPX server entries in the Cisco router will only appear for 240 seconds after linkup or topology change due to the default configuration of the 3Com router being set for Non-Periodic SAP Updates. To correct this issue, a configuration change is required on either the Cisco or 3Com router.

To change the 3Com router to Periodic SAP Updates on a WAN interface, issue the following steps:

  1. Verify the IPX configuration on the WAN interface on the 3Com router by issuing the command: show [!<port]|!*] -sap control

    Example: SH -SAP CONT

  2. If the 3Com router is configured for "noperiodic" on the WAN Interface, the configuration will need to be changed to "periodic" using the command: setdefault !<port> -sap control=periodic

    To change the Cisco router to Non-Periodic IPX SAP Updates on a interface, issue the following interface command:

    ipx update interval sap changes-only

Case Study #2: Frame Relay Broadcast Queue and Loss of IPX Connectivity Across Frame Relay Networks

A Cisco router that is configured for IPX and placed as the hub of a Frame Relay cloud may need to have configuration changes associated with the Frame Relay broadcast queue. This is a result of the Frame Relay broadcast queue defaulting to a size of only a single interface while in fact the interface may be serving multiple sites. The Frame Relay broadcast default queue size is 64 and needs to be configured as 64 times the number of sub-interfaces. The queue size being configured too small may result in loss of IPX RIP/SAP updates across the WAN. The loss of IPX RIP/SAP updates will cause loss of connectivity between hub and remote sites.

Example: Frame Relay broadcast queue configured too small:

lt-3810b#show int s0
Serial0 is up, line protocol is up
Encapsulation FRAME-RELAY, crc 16, loopback not set
  Broadcast queue 61/64, broadcasts sent/dropped 17423/14021, interfacebroadcasts 42032
  Last input 3d19h, output 3d19h, output hang never
  Last clearing of "show interface" counters 00:00:07
  Input queue: 74/75/0 (size/max/drops); Total output drops: 14453
  Queueing strategy: weighted fair
  Output queue: 25/1000/64/1578 (size/max total/threshold/drops)

Configuration Guidelines for Configuring Frame Relay Broadcast Queue

Frame Relay Broadcast Queue

  • To create a special queue for a specified interface to hold broadcast traffic that has been replicated for transmission on multiple Data-Link connection identifiers (DLCIs), use the Frame Relay Broadcast Queue interface configuration command:

  • frame-relay broadcast-queue size byte-rate packet-rate

Syntax Description

  • size - Number of packets to hold in the broadcast queue. Recommendation for IPX RIP/SAP Network is to have 64 packets times the number of remote sites. For example, if there are 7 remote sites, configure the queue depth as 448.

  • byte-rate - Maximum number of bytes to be sent per second. The recommendation is use the default configuration of 256000 bytes per second

  • packet-rate - Maximum number of packets to be sent per second. The recommendation is use the default of 36 packets per second.

Case Study #3: IPX SAP Inconsistency When Using IPX EIGRP as the IPX Routing Protocol

Ocassionally, there may be a sudden loss of connectivity to a specific Novell Server or IPX Service. Novell Servers or IPX Services may disappear randomly from IPX SAP tables. This may also cause SAP table sizes to vary by a few SAPs across the network.

If you are experiencing these problems, view these software bugs and upgrade to a software version that does not experience these issues.

Review these release notes:

CSCdp13795 - IPX SAP Inconsistency with IPX EIGRP

If you are using IPX Enhanced Interior Gateway Routing Protocol (EIGRP), you might experience an inconsistency in Service Advertising Protocol (SAP) updates on a remote router, if the serial interface is brought down for a brief time and then brought up again. To verify the issue, enter the command clear ip eigrp neighbors EXEC, or enter the no ipx linkup-request sap command for the serial interfaces and verify that the problem does not reoccur.

CSCdk13645 - IPX SAP Table May Become Inconsistent After Multiple Servers are Removed from the Table

When using IPX EIGRP incremental SAP updates (RSUP), the server tables between two or more EIGRP neighbors may become inconsistent. Specifically, the problem may occur when as few as three dozen servers go away at the same time, while the routes to those services remain in the routing table if there are multiple EIGRP neighbors or paths to a neighbor. The down Flash update for some of the recently downed servers isn't being sent out to all interfaces, so some devices have the servers removed and others do not. The workaround is to clear the IPX EIGRP neighbors on the unit which shows these servers remaining in the table.

A Flash update is an immediate announcement of any changes in the network, and the appearance of new services or the disappearance of existing services. As the following sample lab debug output shows, the Flash update is sent out to all interfaces that are running IPX:

5d10h: IPXSAP: positing update to 1.ffff.ffff.ffff via Serial1 ( 
broadcast) (flash) 
5d10h: IPXSAP: positing update to 2.ffff.ffff.ffff via Serial0 ( 
broadcast) (flash) 
5d10h: IPXSAP: positing update to 100.ffff.ffff.ffff via Etherne 
t0 (broadcast) (flash)

CSCdm23488 - Missing SAPs After Linkup/down

In network configurations with IPX interface(s) interconnecting a local router and remote router(s) configured with IPX EIGRP SAP-incremental (the default mode on non-LAN interfaces when IPX EIGRP is used), the remote router(s) can lose some SAPs if the local router's interface (the interface where IPX services are heard from but not connected to the remote router) undergo a quick down/up transition. The work around is to re-establish the IPX-EIGRP adjacency by issuing the clear ipx eigrp neighbors command at the remote router(s).

The root cause of CSCdm23488 is a timing issue with the software processes that are called by IPX following link down and link up sequences. When a large number of IPX services are involved, the interface comes up while poison SAPs are being sent. As a result, the poison SAPs override the new adverts and effectively prevent some services from being advertised.

CSCdx73624 - Missing IPX SAPs

In a hub and spoke Frame Relay topology, two spokes may not receive each other's SAPs if the WAN cloud is running both IPX RIP and IPX EIGRP. The result is an inconsistent SAP table. As a workaround, disable IPX RIP.

Troubleshooting Steps

If you observe a problem with missing SAPs, use the following troubleshooting steps:

  • If the SAPs are learned via another Frame Relay spoke, is the hub router also missing the SAPs or only the local spoke router?

  • Are you using incremental or periodic SAP updates?

  • If you have enabled periodic updates, determine whether the router is receiving refreshed SAP updates. View the SAP counters by issuing the show ipx traffic command.

System Traffic for 0.0000.0000.0001 System-Name: SAMPLE 
 Time since last clear: 00:01:47 
 Rcvd: 733 total, 0 format errors, 0 checksum errors, 0 bad hop count, 
 4 packets pitched, 733 local destination, 0 multicast 
 Bcast: 732 received, 507 sent 
 Sent: 529 generated, 456 forwarded 
 0 encapsulation failed, 0 no route 
 SAP: 0 Total SAP requests, 0 Total SAP replies, 0 servers
  • Are you losing all SAPs from a particular server?

  • Is there a relationship between a link failure and the missing SAPs? If the SAPs are lost after a link change, use the following steps:

    1. Disable console logging and enable buffer logging by issuing the logging buffered command.

    2. Issue the debug ipx eigrg events and debug ipx eigrp neighbor {neighbor ID} commands.

    3. Transition the link state of the interface.

    4. If you detect missing SAPs, wait at least five minutes to verify that the SAPs are indeed missing. Capture the output of the show ipx server and show ipx routecommands at both the hub and spoke routers.

    5. Issue the clear ipx route command at the spoke end.

    6. Issue the show ipx server and show ipx route commands to verify whether all the SAPs have been learned.

If you cannot resolve the problem with the above steps, you may need to issue the debug ipx sap activity command. Example debug messages are provided below.

3d21h: IPXSAP pv03 from net C4545 rejected, route C0324002 not in table 

Oct 19 18:21:05 CDT: IPXEIGRP: SAP from FF16 rejected, route 2200 in table via different interface

Note: Ensure you understand the impact of this debug command before enabling it, since it may generate a large amount of output. To minimize the impact of debugs to the router, we recommend disabling console logging and enabling buffer logging with a sufficient buffer size.

Case Study #4: The command show IPX traffic Indicates Numerous Format Errors

For Example: The command is configured as lt-4500-3a#show ipx traffic. The output is as follows:

System Traffic for 0.0000.0000.0001 System-Name: dc_gw
Rcvd: 49847808 total, 1974563 format errors, 0 checksum errors,150 bad hop count, 
310999 packets pitched, 1067549 local destination, 0 multicast
Bcast: 1072701 received, 1005206 sent
Sent: 2209133 generated, 48465603 forwarded
0 encapsulation failed, 3240 no route
SAP: 2174 SAP requests, 8 SAP replies, 1330 servers
899357 SAP advertisements received, 990129 sent
0 SAP flash updates sent, 535 SAP format errors, last seen from 0.0000.0000.0000
RIP: 91556 RIP requests, 22723 RIP replies, 152 routes
73769 RIP advertisements received, 20433 sent
1475 RIP flash updates sent, 0 RIP format errors
Echo: Rcvd 0 requests, 0 replies
Sent 0 requests, 0 replies
76 unknown: 76 no socket, 0 filtered, 0 no helper
0 SAPs throttled, freed NDB len 0
0 packets received, 0 replies spoofed
Queue lengths:
IPX input: 0, SAP 0, RIP 0, GNS 0
SAP throttling length: 0/(no limit), 0 nets pending lost route reply
Delayed process creation: 0
EIGRP: Total received 0, sent 0
Updates received 0, sent 0
Queries received 0, sent 0
Replies received 0, sent 0
SAPs received 0, sent 0
Trace: Rcvd 0 requests, 0 replies
Sent 0 requests, 0 replies

The format errors in a show ipx traffic command are the number of bad packets discarded (for example, packets with a corrupted header). This counter includes IPX packets received for an encapsulation that the router is not configured.

Most PCs on a network auto-detect the frame type of IPX on either a Token Ring or Ethernet network by sending GNS requests of all four possible frame types. The interface on the router is hard coded to a specific frame type. If the interface on the router receives an IPX packet with a different frame type than what is configured, the packet is dropped and the "format field" is incremented. Therefore, PCs configured for the default frame type will always record at least three format errors on the adjoining Cisco router upon startup.

Refer to Novell IPX Commands for more information on the show ipx traffic command.

Case Study #5: IPX SAPs Are Not Appearing In the IPX Server Table Across WAN Clouds

Cisco routers across a WAN cloud will show all IPX routes in the IPX routing table. However, none of the IPX SAPs are appearing in the IPX Server Table. AMI line encoding does not support packets with a high zeros density. The line encoding should be B8ZS encoding which will, when sensing a high zeros density, invert the data stream to break up the zeros. IPX SAP packets can include a data pattern of 11 consecutive zeroes. For example, a type 4 file server has a IPX address of ABCDEF.0000.0000.0001, which will be corrupted if the WAN Cloud does not support high zero density. If the packet reaches a remote router corrupted, it will be dropped. As a result, IPX RIP Updates will reach remote routers, but IPX SAP packets will not, due to the high zero density.

The solution is to have the WAN service provider correctly set the line encoding to B8zs across the WAN.

To verify your configuration, initiate an IP ping with a pattern of all zeros across the WAN cloud at 500, 1000 and 1500 bytes. If the IP Ping is successful, the line encoding is not an issue since the high density zero pattern pings are successful.

Protocol [ip]: 
Target IP address:
Repeat count [5]: 
Datagram size [100]: 500
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: 
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 0x0000 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 5, 500-byte ICMP Echoes to, timeout is 2 seconds:
Packet has data pattern 0x0000
Success rate is 100 percent (5/5)

Case Study #6: Workstations Are Not Able to Connect to One of the Servers Via Network Neighborhood

In some cases, workstations are able to see all Novell Servers in a Network Neighborhood, but unable to connect to any of the servers through network neighborhood. In order to attach to servers in Network Neighborhood across VLANs or across multiple networks, client workstations must have the Novell Client 32 installed or enable IPX type-20-propogation on corresponding routers. In addition, each network number in the campus must be unique across the entire network. Use the IPX PING tool on the Novell Servers and PING IPX tool on the Cisco Routers to verify connectivity across the WAN.

Case Study #7: Unable to Access Citrix Winframe Resources Using IPX Across Cisco Routers

If the command output of show ipx servers shows that there is more than one Winframe server with the same hop/tick count away, then, by default only the SAP of the first entry will be sent to the client.

This is not a problem for a Novell server, since the client will accept the first SAP, go to the first server, and then get redirected to the server of the client's choice if there is a preferred server. Winframe does not have that functionality. If the client is set up for server name "x", but gets the SAP for server name "y," since "y" is first in the SAP table, then the client will never connect.

The solution is to add the command ipx gns-round-robin as a global command on the router with the multiple winframe SAP's of the same distance. The router will round robin through the SAP responses and the client will get the SAP for the correct server, even if it is not the first SAP in the SAP table of the router.

Case Study #8: Slow Novell IPX Login

The most common cause for slow Novell login is an issue known as tree walking. When a client agent submits a request to NDS, the request is not always received by a name server that is qualified to fulfill the request. The name server receiving the request must find a name server that can fulfill the request. Several name servers may need to be contacted before a qualified server is located. To find the information, a name server initiates a search until a replica is found that contains the desired information. This process is called tree walking. As long as the replica information can be accessed quickly, tree walking is not a problem. However, if replica information is only available across a slow link, such as a WAN link, delays can occur. Any application that uses NDS can cause tree walking, but tree walking can be minimized with good NDS tree design.

Common Slow Login Problems and Resolutions Per Novell Website:

TID 10051665    Troubleshooting Slow Novell Login Problems

TID 10014302    NW5 client slow logging into IPX server

TID 2950722     Slow NT Login in Pure IP Environment

TID 10020376    The clients are getting a Slow Network Login

TID 10024740    Troubleshooting IP Login Issues

TID 10016768    Login is very slow from specific machines

TID 10021852    Slow login over a WAN link due to Contextless Login

General Troubleshooting

To identify what is potentially causing the slow login problem, obtain a packet trace of the problem occurring, capturing all packets sent to and from the workstation. Two packet traces will be necessary to determine the problem exactly: one packet trace of the server port and another packet trace of the workstation. By obtaining two packet traces, it will be very easy to determine if the problem is related to the network dropping packets.

Case Study #9: Troubleshooting Corrupt IPX SAP Table Entries

IPX SAP entries that display invalid characters, phantom networks, or bit-shifted/bit-swapped characters are most likely corrupted SAP entries. Sample invalid characters include (@!~^)). Since there is no Layer 3 (L3) Checksum in the IPX SAP frame, data corruption can occur with IPX SAP updates. This corruption cannot be caused by Layer 2 (L2) corruption because the CRC on the L2 frame would be invalid and the router would drop the frame. Corrupted IPX SAPs are always caused by faulty hardware. Finding the source of IPX corrupt SAPs is fairly simple when using IPX RIP exclusive; Simply use Hop Count to find the source. With IPX EIGRP, the troubleshooting is more difficult, however.

With redundant paths and a looped topology using IPX EIGRP, a corrupt SAP entry can stay forever, not timing out even when the original device has been turned off. The reason that SAPs will not disappear from a mixed EIGRP and RIP environment is due to the fact that when you have parallel paths through a network, RIP and EIGRP will pass the SAP entries back and forth. This behavior will prevent the SAPs from ever timing out. When EIGRP receives updates from two or more different routers from SAP updates, EIGRP will pass the updates back into RIP from EIGRP if the RIP entry goes away. EIGRP will also preserve the RIP hop count, which makes locating the source more difficult.

The looping condition described above only effects SAP, not routes. This is because SAP will always point to the shortest route and doesn't notice routing loops. SAP is not a routing protocol. Removing EIGRP in the entire path will allow the corrupt SAPs to age out.

Due the behavior of IPX EIGRP and troubleshooting corrupt IPX SAP table entries, use the following troubleshooting procedures in isolating IPX corrupt SAPs when using IPX EIGRP:

  1. During a network outage window, disable IPX EIGRP and use RIP to accurately locate the source of corrupt SAP entries. Since RIP uses hop count in the network path, determining the source or origin should be fairly simple. Troubleshooting in this manner assumes that the corrupt fames must be generated during the downtime window. Since IPX SAP corruption is due to hardware, the problem may not occur frequently and only occur at random periods of time. Without the corrupt SAPs currently being generated into the network, there will be no way to determine the source. All corrupt SAPs stuck in the EIGRP table will go away once EIGRP is removed.

  2. Find a common source or origin of the corrupt SAPs. If there a common origin to the SAPs, it may be simple to isolate the issue and not have to perform as intrusive troubleshooting as in step 1.

    All corrupt SAPs are being caused by faulty hardware somewhere in the network. This includes any router, L3 switches, servers running IPX (not just Novell servers), and workstations running IPX. To date, Cisco has never had an IOS software issue contribute to corrupt IPX SAPs.

  3. To work-around corrupt IPX SAPs affecting network connectivity, configure IPX filters including GNS filters, GGS filters, and SAP filters to pass only valid servers in the network. In addition, adding the command ipx sap follow-route-path will minimize the number of corrupt SAPs. This is because when the ipx sap follow-route-path command is used, the router screens individual services (SAPs) in SAP updates. The router looks at the destination network number of each SAP entry's. If the receiving interface is one of the best interfaces to reach the destination network of the SAP, that SAP entry is accepted. Otherwise, the SAP entry is discarded. If a router is receiving corrupt SAPs, it is likely the route may be corrupt as well.

Case Study #10: Server Listing From show IPX servers unsorted Command May Show Servers Out of Order

In certain cases, when IPX GNS Round Robin is configured, the router may experience an issue which may cause a low metric service to be moved in the table beyond the lowest metric group of services. This will cause the SAP table to appear out of order. This is known behavior, and any side effect of this behavior can be solved by using GNS output filters to only allow specific servers to reply to GNS.

If you are experiencing these problems, view the following software bug and upgrade to a software version that does not experience these issues.

CSCds54733 - show ipx servers unsorted Ouput Is Not In Order

The output of the show ipx server unsorted command displays a SAP table that is not in order. While the table is in this state, GNS SAP replies may not provide the nearest service as they should. The misordered table results from enabling GNS round robin. As a workaround, disable GNS round robin by issuing the no ipx gns-round-robin command.

Novell 5.X IP Case Studies

Case Study #1: Basic Cisco Router Configuration Needed for Clients to Login to Novell IP Network Across Network Boundaries

By default, Novell IP clients discover IP services via multicast. Unless another method is configured, IP clients will attempt to discover the server by Service Location Protocol (SLP) which uses IGMP (multicasting). By default, IOS Routers will not forward multicast packets.

The basic router solution is to enable the ip multicast-routing command globally and enable the ip pim dense-mode command under each respective VLAN or physical interface.

Sample Configuration:

Current configuration:
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
hostname Router
boot system bootflash:c6msfc-js-mz.120-7.XE1.bin
boot bootldr bootflash:c6msfc-boot-mz.120-7.XE1
ip subnet-zero
no ip domain-lookup
ip multicast-routing
ip dvmrp route-limit 20000
ip cef
cns event-service server
interface Vlan1
ip address
no ip directed-broadcast
ip pim dense-mode
interface Vlan11
ip address
no ip directed-broadcast
ip pim dense-mode
interface Vlan12
ip address
no ip directed-broadcast
ip pim dense-mode
ip classless
no ip http server
line con 0
transport input none
line vty 0 4
transport input lat pad mop telnet rlogin udptn nasi

There are two other methods by which client workstations can access Novell 5.0 resources across network boundaries without the need to enable mutlicast-routing.

Novell Configuration #1 (Novell Documenet: 2944038)

Add the server name and IP address entries in the NWHost file on the workstation. The NWHOST file is located on the workstation in the Novell\Client32 directory on Win95 and Win98 workstations. It has samples that are easy to follow.

On an NT Workstation, instead of NWHost, the client uses the standard MicroSoft TCP/IP host file. Edit the host file to add the server name and address. The path to this file is Winnt/System32/Drivers/Etc/Hosts.

Novell Configuration #2 (From Novell Document 2944038)

Load SLPDA.NLM on the NetWare 5 Server. This defines the server as a Directory Agent. Add the IP Address of the server running the SLPDA.NLM under properties of the client, Service Location Tab, Directory Agent list. Click on the box next to the Directory Agent box labeled "Static." With a static directoy agent defined, the client will not multicast for a directory agent, but will send a unicast to the specified directory agent.

For an overview of SLP (Service Location Protocol) and a discussion of Directory Agents, see tid 2943614 at

Case Study #2: Enabling IP Multicast Within Production Network Brings Down Existing IPX Networks

Networks may experiennce a sudden and complete loss of IPX connectivity for client PC.

This may happen because the Novell Netware Client Software 3.x will prefer IP for the Network Layer Protocol over IPX by default. Therefore, if a Novell 5.X IP-only server not configured correctly for Novell Netware login and IP multicasting within the network is enabled, all client machines will prefer connection to the Novell 5.X server. If the Novell 5.X server is not correctly aware of existing network resources, the clients will not be able to gain access to existing resources.

To resolve this issue, configure IP Multicast routing to exclude SLP or configure the Novell Netware 5.X Servers correctly.

Case Study #3: Why Does Novell IP Not Work Through a Cisco Router Running NAT?

NAT implementations translate IP addresses in packet headers and special circumstances search the data portion of the packet and translate embedded IP addresses references. However, the current Cisco NAT software does not translate embedded Novell IP references for NDS or SLP in data portions of the IP packet. As a result, devices in the public network will try to contact resources via non-translated private addresses. Since public networks will not be able to private networks, the connections will fail. The alternative solution for creating Novell IP connections through NAT is to use a VPN solution.

For more information, see TID 2948010 at

Case Study #4: Slow Novell IP Login

Slow Novell IP login troubleshooting is the same as Slow IPX login. See Case Study #8 under Novell IPX Case Studies.

Common Configuration Questions

Why Can't I Configure More Than 200 IPX Networks on My Router?

A Cisco router can handle more than 200 IPX networks in its routing table, for instance, but you cannot configure more than 200 IPX interfaces on a router (using the ipx network command). The limit has only been reached recently now that we have Layer 3 switches that can provide this number of interfaces. This number is hardcoded in the IOS and will probably not be changed. Layer 3 switches can implement more than 200 interfaces because most of the switching functions are handled by some specialized ASICs that offload the main processor as far as IP traffic is concerned. IPX interfaces need a lot more CPU power to handle the RIP/SAP process, and even getting close to the current limit can be critical.

Why Can't I Ping a Novell Host From My Router?

A Cisco router implements two types of IPX ping:

  • Cisco IPX ping: this is the default Cisco proprietary protocol a router will use when you attempt to ping an IPX address.

  • Novell IPX ping: this is the only one that Novell servers can run, and it is not compatible with Cisco's implementation.

You can use Cisco IPX ping to test connectivity between Cisco devices configured for IPX. If you want to ping a Novell server, you have to configure the router to send Novell IPX ping, using the global configuration command ipx ping-default novell

You can also issue an extended ipx ping command and select the Novell Standard Echo option.

The Novell server must have responder loaded to answer a Novell echo (ping). To ping from a Novell server, one must also load IPXPING.NLM on the server. We have observed, in casual testing, that:

  • Netware 3.x servers, Netware 4.0x servers, NETX clients, VLM Clients (v.1.20a), and MS Client for Netware DO NOT respond to Novell pings.

  • Netware 4.10 servers, Netware MPR v3.x, Client 32, and MS Client DOS/Win95 DO respond to Novell pings.

Of course, ping can also fail for other reasons than a mismatch in the ping protocol type. The success of ping is also dependent on the IPX routing table (there must be a route to the destination address), the link integrity (packet losses), filtering, and so on. Guidelines to remember when using ping:

  • When pinging a server is possible, ensure that all IPX connectivity issues have been addressed.

  • When ping is failing, on the top of all possible connectivity issues (from a complex IPX routing problem to a link functionality problem), remember that there may be a simple problem with the server not implementing the IPX ping functionality. It means that, unfortunately, there is often nothing much to conclude when an IPX ping to a server is failing.


In this example, we have two routers directly connected via their Ethernet interface on IPX network BABA. From router1, if we ping router2's interface, the router first uses by default, Cisco proprietary protocol:

router1#ping ipx baba.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte IPX cisco Echoes to BABA.0000.0000.0002, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

We can force Novell ping protocol using the extended ping command:

router1#ping ipx
Target IPX address: baba.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Novell Standard Echo [n]: y
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to BABA.0000.0000.0002, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

The other possibility is to set the default ping protocol to be Novell's one:

router1#conf t

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

router1(config)#ipx ping-default novell 


2w1d: %SYS-5-CONFIG_I: Configured from console by console

router1#ping ipx baba.0.0.2

Type escape sequence to abort.

Sending 5, 100-byte IPX Novell Echoes to BABA.0000.0000.0002, timeout is 2 seconds:


Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 ms


Changing the ping type to Novell's is only important when you attempt to ping a host running Novell protocol. Failing to ping a Novell host does not necessarily mean that connectivity to this host is broken (not all Novell hosts respond to Novell ping). Pinging a router is a good way of testing IPX connectivity to it.

Why Can't I Configure IPX Routing?

You must have the correct IOS software to configure IPX routing.

Very often, a router is delivered with a default software in Flash and this default software may not support IPX (even if you paid a licence for IPX support). You then have to upgrade your router to the software you are licenced for. IPX support is generally part of the desktop feature set, which is often identified with a "d" in the image name:


See this desktop feature set as a minimal feature set including IPX support. An "enterprise" feature set (identified with a "j" in place of the "d" above), which includes the desktop feature set will, of course, also support IPX. Check the IOS release notes for the exact features available in the IOS that you are running.

What is the ipx pad-process-switched-packets Command?

This command is used for controlling whether odd-length packets are padded, so to be sent as even-length packets on an interface. The ipx pad-process-switched-packets command affects process-switched packets only, so you must disable fast switching before the ipx pad-process-switched-packets command has any effect. The command was necessary due to some IPX hosts that rejected Ethernet packets that are not padded. Certain topologies can result in such packets being forwarded onto a remote Ethernet network. Under specific conditions, padding on intermediate media can be used as a temporary workaround for this problem.

This command is enabled by default. However, the Novell Ethernet driver specification says IPX packets should be "evenized" by the sending device. This is due to legacy devices which had problems with odd length packets and should not be an issue these days, but the requirement persists.

A device not following the legacy Novell requirement might produce odd length packets. Odd packets might also result when routing from one IPX encapsulation to another different IPX encapsulation. Some encapsulations have different length and a change in encapsulation may produce an odd length packet.

Do Cisco Routers Support the IPX Packet Extension Feature to Curve Network Congestion by Sending Larger RIP/SAP Update Packets?

This is a supported feature. By default, a IPX RIP Packet contains 25 routes and a IPX SAP Packet contains 7 SAPs. The number of routes and SAPs per RIP and SAP packet can be changed by changing the respective update packet size. See documentation on ipx sap-max-packetsize and ipx rip-max-packetsize in the IOS command reference for more details.

Despite Configuring all Novell Servers and Routers for IP Only, I am Still Seeing IPX Frames on Sniffer Traces. Why is this?

Novell Client Software 3.x by default will send frames for IP and IPX upon bootup in an attempt to login to the Novell Network regardless of network configuration. The solution is to manually disable all IPX protocols on client PCs.

Why Does Enabling IPX EIGRP on a VLAN Interface Disable IPX MLS for That Respective Interface?

MLS IPX is disabled with EIGRP IPX since forwarding between RIP and EIGRP domains requires translations of the specific fields in the data portion (transmit control) of route packets. An IPX router interface when enabled for RIP/NLSP, will have the maximum hop count of 16. When a router is on the boundary of an NLSP/RIP and EIGRP routing domain, the interface is configured with both EIGRP and NLSP/RIP. It is necessary to remove MLS support for that interface if the maximum hop is configured to be 16 or less because in this case, the Transmit Control (TC) value will be translated instead of being incremented by 1 when a packet traverses from one routing domain to another. The MLS-SE does not have knowledge about the routing protocol being used and the MLS hardware will not be able to rewrite the Transmit Control (TC) field properly.

"IPX mls will be disabled on Vlan <vlan_id> due to eigrp usage" message appears only if the IPX maximum-hops is set to 16 when IPX EIGRP is configured. For all other values (17-254) no such warning message is displayed. IPX MLS works fine for hop value of 16 though there is a warning.

The command to increase the Transmit Control (TC) value above 16 is IPX MAXIMUM-HOPS <max_hops value>

There is no specific disadvantage/advantage in increasing the hop count.

Common Connectivity Issues

Understanding the IPX Client Login Process

How Does a Client Connect to a Novell Network?

If a client needs to locate a server in a specific nearest directory server (NDS) tree, the client will broadcast a SAP type 3 for service type 0278 Get Nearest Directory Service (GNDS) request. Any NDS server (configured to respond to GNS and GNDS requests) located on the same routed segment as the client will respond with the name of the NDS tree that it belongs to and its internal IPX number. The client will check the tree name in the reply against the tree name that it needs (according to what the client has set as its Preferred Tree). If it is the correct tree the client will broadcast a RIP request for a route to the internal IPX number provided in the reply. The server will respond saying that it is the route to that internal IPX number. The client will unicast a request to establish a connection to that server and begin the authentication process. If the server on the local segment is not an NDS server it will not respond to the initial GNDS request because it can only provide Service type 0004, not 0278. Any NDS servers that do not hold NDS replicas will not respond to the request. If none of the replies contain the correct NDS tree name, the client will issue a SAP type 1 for service type 0278 (GGDS) request. All NDS Servers located on the same routed segment will respond with a list of services, regardless of the REPLY TO GET NEAREST SERVER setting. The client will read all the replies to the GGDS looking for the correct NDS Tree name. Once it finds an entry for the correct tree, it will attempt to establish a connection to that server. The client will attempt to establish a connection to the first entry that contains the correct Tree Name, not the nearest since this a general service query, not nearest service query. If the client is requesting a Bindery server (or the client has only a Preferred Server set in his Client Configuration) the same process will take place, only the service type of the request will be 0004 instead of 0278. Additionally, If the server has REPLY TO GET NEAREST SERVER set to OFF then the server will not respond to GNS (service type 0004) or GNDS (service type 0278) requests

FlowChart for Novell Client Login

NDS (Novell 4.11)

  1. Upon bootup, the client will send a GNDS request. If the client is configured to auto detect the frame type, the client will send four GNDSs, one for each frame type.

  2. All local servers (or Cisco Routers if serverless segment) will reply with a GNDS response.

    The client will use the first GNDS response if multiple servers or routers reply to the GNDS request. The GNDS response will contain the respective server's internal network number and tree name.

  3. If the GNDS response has the correct tree, the client will issue a RIP request for the internal IPX number provided in the GNDS response.

How Does a Cisco Router Pick the Server to Include in a GetNearestServer (GNS) Response?

The command show ipx server unsorted will show in first position the name of the server that will be used to answer the next GNS request. In software release 9.21 or later, use the command ipx gns-round-robin to enable load balancing of answers to GNS requests among Services of equal metric. The way the servers are ordered is described in the following document: How Are Servers Sorted?

What is the Client Connection Sequence With and/or Without Preferred Server?

For connection sequence without preferred server, issue the following steps:

  1. Find service (GNS query & reply)

  2. Find route to service (RIP query & reply)

  3. Make connection to Nearest server

  4. Get file server information

  5. Negotiate the buffer size

  6. Clear previous connection

  7. Get file server date and time

For connection sequence with preferred server, issue the following steps:

  1. Find service (GNS query & reply)

  2. Find route to service (RIP query & reply)

  3. Make connection to Nearest server

  4. Get file server information

  5. Negotiate the buffer size

  6. Read property value of "preferred server" stored in the Nearest server

  7. Find route to preferred server

  8. Create connection to the preferred server

  9. Get preferred server's file server info

  10. Negotiate the buffer size

  11. Clear service connection with the Nearest server

  12. Clear previous connection with preferred server

  13. Get filer server date and time

This still requires GNS query/reply from the nearest server, but it does not complete the connection sequence with the nearest server. It uses the nearest server to learn how to get to the preferred server. Once the route to the preferred server is learned, it destroys the connection with the nearest server and repeats the connection sequence with the preferred server.

How Do You Filter Answers to GNS or GGS Requests?

It is useful to control the mechanism a router uses to answer a client GNS request. In order to answer a client, the IOS selects one of the servers known by the router. The IOS provides a way of preventing some servers in this list from being used, using the IOS command:

ipx output-gns-filter {access-list-number|name}

This command, once applied to an interface, will ensure that the router is only providing to clients a nearest server matching the specified access-list.

Connecting Clients to the Network

Why Can't I Connect My Client When Directly Attached to a Switch?

The issues that can result from this configuration are fully described in the following document Using Portfast and Other Commands to Fix Workstation Startup Connectivity Delays.

Basically, if you have a PC connected directly to a port on the Catalyst switch, make sure that you have the portfast feature enabled. To set it with the CatOS, use the command:

set spantree portfast enable <module/port>

Additionally, if you have trunking and channeling capable modules (for example, WS-X5225R on the Catalyst 5000 and all Catalyst 6000 modules are trunking/channeling capable) you have to make sure that you have turned them off manually, using the following commands:

set trunk <module/port> off set port channel <module/port-range> off

From software 5.2 on the Catalyst 4000/5000 family and from 5.4 on the Catalyst 6000 family, these three commands can be bundled in a single macro command:

set port host <module/port>

Are There Any License or Server Issues That Will Affect Connection?

The first thing a connecting Novell client does is to send a GNS (get nearest server) request. This request is answered by a server or a router. The client then tries to connect using the server specified in the reply. There are two common issues that can lead to a failure of the connection:

  • The server contacted does not reply to GNS. If the internal network number of the nearest server is not 0000.0000.0001, then it is probably a NT server that will ignore GNS.

  • The server contacted is running short of licenses. Only a limited number of clients could connect, additional attempts are failing.

In both cases, if a Cisco router is involved, check what server is given to the client using the command show ipx server unsort . You can then use the ipx output-gns-filter command to filter the servers that should not be given as a response.

Will There Be Problems Connecting Due to Duplicate IPX or MAC Addresses?

Normally, all IPX addresses in the network should be different, as a MAC address is part of them. However, there are many cases where the user can hardcode a MAC address, In this case, pay close attention to the uniqueness of this address. Also, be very careful not to duplicate an IPX address when cutting and pasting configuration from one router to another for instance. This is extremely important for WAN interfaces that use the MAC address defined in the ipx routing command. In the following example, router A and B configurations have been duplicated. The network administrator changed the IPX network on every interfaces but forgot to update the ipx routing line, which is the same in both configurations.


A serial interface does not have its own MAC address. The router will use the MAC address specified in the ipx routing command to build the IPX address of its serial interfaces. In this case, router A and router B will have the exact same IPX address AAA.0000.0C14.11E1. Of course, there are a lot of other ways to fall into the duplicate address problem. The TAC sees a lot of connectivity issues caused by duplicate addressing, so be very careful when assigning an IPX network or a MAC address.

On a given link:

  • All servers and routers must be configured with unique IPX network numbers for a given encapsulation.

  • All MAC addresses must be unique.

Viewing Servers and Services

Why Can't I Access a Specific Server/Service?

If a client is trying to access a server through a Cisco router, use the show ipx server command on the router:

If the server/service you are looking for is among those listed when you issue the command show ipx server, and there is no access-list in the configuration that would break the connectivity, then the router most likely not the cause of the problem. If you don't see the service on the router, make sure that the IPX network of the server appears in the routing table. Issue a show ipx route command to show the IPX routing table. A service will not be advertised if the router does not have a route to the corresponding network.

If the server is directly attached to the router but still does not appear when the show ipx server is issued, be sure that you have configured the same IPX network with the same IPX encapsulation on the server and on the router.


In this example, be sure that the Novell server is configured with encapsulation SNAP and that the IPX address is BABE. If the encapsulation is wrong, packets sent by the server will be discarded by the router. If the IPX networks don't match, the server will display an error message pointing to that mismatch.

On the router, the command show ipx traffic will give some useful information, unfortunately for the whole device, not for a specific interface. Pay attention to the "format error" field. It will be incremented each time the router receives a packet with the wrong encapsulation. If this counter is increasing, you are very likely to have an encapsulation mismatch.

The command show ipx interface [<interface>] gives IPX related details for a specific interface. It summarizes the encapsulation type, IPX address, and access-list configured for the interface. When troubleshooting server/service visibility, it is useful to check that a specific interface is receiving RIP and SAP updates from a neighbor. This is possible using this command.

Why Can't I Access an IPX Server Through RConsole?

While RIP and EIGRP carry network information, SAP carries service information. Each IPX SAP packet generated by a Cisco router can carry up to seven 64-byte SAP entries plus 32 bytes of IPX overhead (for a total of 480 bytes), in addition to the media encapsulation overhead. When they are carried inside EIGRP packets, IPX SAP packets consist of a standard EIGRP header with an Opcode value of 6, followed by the standard payload of a standard IPX SAP packet without the original IPX header.

In a typical SAP packet exchange, a Netware client will broadcast a SAP query to locate a directory server, as indicated by the SAP server type field (see Novell SAP Service List). The SAP reply packets contain the internal IPX address of the servers that offer directory services. The client then sends a RIP broadcast to locate the path to the server's internal IPX address.

The following steps establish an RCONSOLE connection:

  1. The RConsole client broadcasts a SAP request looking for a server. Specifically, RConsole sends out a General Services Query for type 0x107 servers. The Cisco router must be permitted to announce type 0x107 servers for RConsole to work on the PC. The client sends a server lookup SAP request even though it is currently logged into a server.

    • If there is a server on the segment, it responds to the client.

    • If the IPX clients are on a serverless segment, the router picks the first SAP entry in its unsorted list to reply to the GNS request from the IPX clients. In some cases, the first SAP entry in the router is the wrong server. Issue the show ipx server unsorted command to capture this. As a workaround, create a SAP access list to block that server and apply it as GNS filter.

  2. The client sends a RIP request for the internal IPX address of the first server that responded.

  3. Once the client learns the fastest way to get to the server, it sends an SPX connection request packet to it.

If you are unable to make an RConsole connection to a particular Netware server, use the following steps to determine whether the cause is a network issue or a server issue:

  • Can you see any servers? Some servers? Servers that are local? Servers that are across the WAN?

  • Is other IPX traffic affected?

  • What does the IPX server table look like in the nearest router?

  • Do you see the internal network ID of the server in the router's IPX routing table?

  • Indicate the IPX network that you are coming from and the server that you are trying to RConsole into:

    • show version

    • show run

    • show ipx server

    • show ipx route

  • Are you using Netware 4.11 or Netware 5? Is it Novell IP? Can you ping the Netware 5 server? In other words, try to connect by IP versus by name. If so, DNS is not resolved.

In some cases, a corrupted database on one server causes SPX connection problems, particularly as the corrupted database is forwarded to other servers. Often, you can fix this problem by running the DS repair utility. However, if DS repair fails to restore the database, a reboot of the server may be required. If you can not make an RConsole connection using the internal network number, the problem is with the Netware server.

Novell also publishes technical tips online in a knowledgebase. The following tip may be helpful to troubleshooting RConsole issues from the perspective of the IPX servers. This tip is provided as a resource for Cisco customers.

"RCONSOLE -4.10-112 SPX Establish Connection failed to establish a connection to the desired server."

  1. Is the REMOTE.NLM loaded on the server? Is RSPX.NLM loaded?

  2. Have you checked DS and made sure it is healthy and that everything is synchronizing?

  3. Errors can be caused by a router that is filtering out the RConsole SAP. SAP type 0107 is the RConsole SAP, and must not be filtered out if RConsole is to work properly.

  4. A bad NIC card can prohibit the client from establishing the SPX connection.

  5. Make absolute certain that all of your IPX Network Numbers are unique. This is the number one reason why RConsole fails, but sometimes the hardest to troubleshoot.

  6. Force the frame type on the client instead of Auto-detecting the frame type.


At the RConsole screen, press INS and enter the IPX internal network number of the target server. The IPX internal network number of the server can be found by typing CONFIG at the server console. If manually entering the IPX internal network number allows RConsole to work, it could mean that the IPX socket table on that server has been exceeded. Increase the maximum IPX socket table size: INETCFG -> Protocols -> IPX ->IPX/SPX Parameters ->Maximum IPX socket table size. The default is 1200. Increase this value to 2400 initially. The server needs to be rebooted in order to reset this table size.

Why Don't I See All my Servers In a Hub and Spoke Topology?


In the above diagram, we have a hub router connected via a point-to-multipoint interface to several others. This is a typical Frame Relay hub and spoke networks. All routers are connected in the same IPX Network A. Spoke routers advertise their local network X and Y to the hub, but you don't see network Y in the Router X routing table (and similarly you don't see X in router Y table). This problem is directly related to split-horizon. RIP doesn't advertise a route on the interface where it learned of it. Basically, the hub router learned about Network X on its WAN interface serial0, connected to network A, and it will never advertise X back on serial0. Router Y, also connected via serial0 to the hub router, will never hear about network X.

Novell specifications don't allow split-horizon to be disabled for RIP, so there are two main workarounds available with Cisco routers:

  • Replace the point-to-multipoint interface with several point-to-point interfaces. This can be done by creating several sub-interfaces on the hub router serial0. The problem is that you need to assign a different network number for each point-to-point link created, which means a change in the addressing scheme and an increase of the routing table size.

  • Replace RIP with IPX EIGRP. This latter routing protocol allows the removal of split-horizon (using the command no ipx split-horizon eigrp ) and performs better on slow WAN links (incremental updates, and so on). The only disadvantage is that all routers must be Cisco on the WAN.

Why is NetBios Over IPX Not Going Through My Router?

This occurs because NetBios over IPX relies on broadcast type 20 IPX packets, that are not to be forwarded by a router. In order to have these specific packets forwarded by a router, configure the ipx type-20-propagation command on every interface that will propagate NetBios traffic:


Router 1 configuration Router 2 configuration
ipx routing 0000.0000.0001


interface Ethernet0

 ipx network A

 ipx type-20-propagation


interface Ethernet1

 ipx network C


interface Serial0

 ipx network 1

 ipx type-20-propagation

ipx routing 0000.0000.0002


interface Ethernet0

 ipx network B

 ipx type-20-propagation


interface Serial0

 ipx network 1

 ipx type-20-propagation


This configuration only includes the relevant IPX part. In this example, host A and host B are running NetBios over IPX. Router 1 and Router 2 have a very basic IPX configuration. The command ipx type-20-propagation has been added on every single interface that is supposed to relay NetBios over IPX traffic. In this regards, interface Ethernet 1 from Router 1 does not need it, as there is no Netbios host on the Ethernet segment.

Note that the type-20-propagation command, although mandatory, will have a performance impact on your network.

Performance Issues

Memory Usage for RIP Routes and SAPs

IOS 10.0, 10.2 10.3 and above
Route 180 bytes for each route, add 50 bytes for each additional path if maximum-path > 1 160 bytes for each route, add 70 bytes for each addition if maximum-path > 1
SAP 200 bytes for each SAP, add 4030 bytes for every SAP type 200 bytes for each SAP, add 4030 bytes for every SAP type, and add 50 bytes for each additional path

IPX Load Balancing on the Cisco Router


If Router Z is configured with the command ipx maximum-paths 2 and Routers A and B get you to the same destination network in the same number of hops, Router Z will then send each packet to the destination to Router A and B in a round-robin fashion, both with slow-switching and fast-switching.

Be careful that in this particular case, if you load balance over paths of unequal bandwidth and you have pburst enabled, out- of-order packets may result. Newer Netware versions should handle this better than older Netware versions, but it is worth trying to remove load-balancing or pburst when you are troubleshooting a performance issue in this configuration. Since IOS 11.1, you can also enable per-host load-sharing using the command ipx per-host-load-share . Per-host load-sharing transmits traffic across multiple, equal-cost paths while guaranteeing that packets for a given end host always takes the same path.

Poor Performance When type-20-propagation is Enabled

IP helpering on a router is not recommended in a network, but the ipx type-20-propagation command is also not recommended, as far as traffic load is concerned. With an IP helper command, the router takes a broadcast packet and turns it into a unicast packet (or directed broadcast) in order to forward it on the next segment. With the ipx type-20-propagation command, the router takes a broadcast and forwards it as broadcast. The type-20 packet contains a list of all the networks already gone through and the router will never forward it back on a network appearing in this list.


Let's assume the command ipx type-20-propagation is enabled on every interface, with three segments between router 1 and 2 (a common configuration with Catalyst 5000 and RSM connected together by a trunkof 20 VLANs, for example).

  1. PC1 issues a type-20 broadcast.

  2. Router 1 gets it and forwards one copy on each segment A B and C (with segment list D).

  3. Router 2 gets three copies and forwards each of them (segment list is DA for the first DB for the second DC for the third) to the two other segments making 6 more copies of the packet (DA is send to B and C, DB to A and C, DC to A and B).

  4. Router 1 gets these six copies (DAB , DAC, DBA, DBC , DCA, DCB) and forward all of them to the last segment which has not seen it.

  5. Router 1 gets the six packets (DABC , DACB ,DBAC ,DBCA, DCAB, DCBA) and drops them all as they have all crossed all segments.

With this example we can see that each broadcast will generate 15 more packets between the two routers. With four links (VLANs) between two routers you have 64 packets. With five links between two routers you have 325 packets, and so on. Therefore, using this command will cause an increased number of packets, which can slow or shut down your network.

To improve the situation, use the following commands:

When these are configured, we make sure the type 20 is coming in on an interface which is a primary route back to the source. If it isn't, we drop the packet. When we are going to send a packet, we check if the network/interface we are sending it to is not a route back to the source of this type 20 packet, or else we drop it. This is in addition to the eight hops checking for loops that the IPX router specification calls for us to do with type 20s.

Access List Configuration

Filtering a Range of IPX Networks

The IPX extended access list allows you to filter a range of networks. For example, you may have a large IPX network. All IPX networks begin with A43XXXXX and CBDXXXXX. Networks A43XXXXXX do not need to go to some routers, so I filtered each one using the following commands:

interface Serial0

     ipx output-network-filter 805


     access-list 805 deny  A43C0100

     access-list 805 deny  A43C0101

     access-list 805 deny  A43C0102




This access-list continues for 120 lines. How can I filter IPX networks that begin with A43?

Try using the following command:

access-list 905 deny any A4300000.0000.0000.0000 FFFFF.FFFF.FFFF.FFFF

Be sure include a line to permit the routes that you want. The any keyword will represent "all protocols" and is a required argument. The mask works on the same principle as the IP wildcard mask. The host bits must be specified, otherwise you won't have the mask option. You can use the IPX extended access list in all the same ways you can use the standard version. If you are using NetWare Link Services Protocol (NLSP) as your routing protocol, you will need to use multiple areas so you can filter routes on the area boundaries.


When Viewing the Output of a Debug IPX Packets Some Packets Are Marked as "Bad Pkt." Why Are These Packets Marked as "Bad Pkt?"


IPX: unable to forward, no helper A0000001.0000.0000.0001(455)to B0000001.ffff.ffff.ffff(455) typ 4
IPX: Fa0/0:A000000.0000.0000.0001->B00000001.ffff.ffff.ffff ln=173 tc=01, bad pkt

This may occur because Socket 455 is the NetBIOS socket number and the MAC layer destination address of the packet is broadcast. This packet will be dropped by the router by default unless ipx type-20-propogation or an ipx helper-address is configured. See documentation on enabling type-20-propogation for more details on forwarding these NetBIOS over IPX directed broadcasts.

Related Information

Updated: Oct 05, 2005
Document ID: 10564