This chapter presents protocol-related troubleshooting information for Novell IPX connectivity problems. The emphasis here is on symptoms and problems associated with IPX network connectivity.
This chapter consists of the following sections:
- Diagnostic tools and techniques used for isolating Novell internetworking problems
- Overview of symptom list
- Symptom/problem/action modules
The problem/solution modules consist of the following sections:
- Symptom statement--A specific symptom, associated with the technology/media/protocol in which this module appears.
- Possible causes and suggested actions--For each symptom, a table containing possible causes for the symptom and suggested actions for resolving each cause.
The following tools (all available via the router's basic management interface) form the core of the administrator's internetwork toolkit:
- ping command--The ping command is essential in determining where failures are occurring. However, this tool is only useful for determining connectivity between routers, because it is not supported by Novell servers.
- show commands--The show commands provide information about interface conditions, protocol status, neighbor reachability, router configuration and status, level of traffic, errors and drops, and other network data. In particular, show novell servers and show novell route can be used to help build a topology map and determine connectivity among network entities.
- In addition, the show interfaces [ethernet|fddi|serial|token] number command provides essential information concerning interface and media status. Remember to include the interface number when using this form of show interfaces.
-
- debug commands--The debug commands provide clues about the status of both routers and other network entities. Use debug commands with great care. Using the wrong debug at the wrong time can exacerbate problems in poorly performing networks. Of particular usefulness is the debug novell-packet command.
 | Caution Throughout this publication, the use of debug commands is suggested for obtaining information about network traffic and router status. Use these commands with great care. In general, it is recommended that these commands only be used under the direction of your router technical support representative when troubleshooting specific problems. Enabling debugging can disrupt operation of the router when internets are experiencing high load conditions. When you finish using a debug command, remember to disable it with its specific undebug command or with the undebug all command. |
When specific diagnostic commands are considered particularly useful for troubleshooting symptoms, they are listed with the specific symptom discussion in this chapter.
Refer to "Using Cisco Diagnostic Tools" in Chapter 1 and to Chapter 10, "Debug Command Reference," for more information about using these tools. In addition, details about other specific commands are provided in the Router Products Configuration and Reference publication.
One important consideration to remember when troubleshooting broken interconnections is that normally everything does not break at the same time. As a result, you can typically work out from an operational node to the point of failure. The following basic steps will help when trying to isolate the source of connection disruption:
Step 1: First, determine whether your local host is properly configured.
Step 2: Next, use the ping EXEC command to determine whether the routers through which you must communicate can respond. Start with the most local router and progressively "ping out" through the internet.
Step 3: If you cannot get through a particular node, examine the node's configuration if possible and use the various show commands to determine the router's state. In particular, show novell traffic and show novell interface can provide useful information.
Step 4: If you can get to all the routers in the path, check the host configuration at the remote host (or get someone's help to do so) and check its configuration.
Step 5: Check the routers' routing tables (show novell route) and table of servers (show novell servers) for any anomalies (such as duplicate network numbers) and to see whether the host(s) in question are appearing.
The symptom modules that follow pertain to Novell internetwork problems. Unless otherwise indicated, each module is presented as a set of general problems. Where there are special considerations associated with a situation, notes are included.
The following Novell internetworking connectivity symptoms are discussed in this section:
- Clients cannot communicate with NetWare servers over routers.
- SAP updates are not getting through router.
- Novell NetBIOS packets cannot get through router.
- Clients cannot access server over packet-switched network.
Note For the puposes of this document, symptoms, problems, and actions associated with
Novell NetWare 2.15 apply equally to NetWare 2.2, unless NetWare 2.2 is specifically excluded.
Symptom: Clients may or may not be able to connect to servers on their directly connected networks. In either case, no connections can be made to servers on the other side of the router.
Table 5-1 outlines possible causes of blocked access to servers over routers.
Causes and Actions for Blocked NetWare Connectivity over Router
| Possible Cause
| Suggested Actions
|
|---|
| Clients or servers are not attached to network
| Step 1: Connect both clients and servers to the same network and verify that they can communicate.
|
|
| Step 2: If they cannot communicate, check configuration of the client and server. Refer to host software documentation for troubleshooting information.
|
|
| Step 3: Attach a network analyzer to the network to which clients and servers are temporarily connected. Look for source addresses of both.
|
|
| Step 4: If you find the source addresses, end stations are operating properly. If you do not find their addresses, check the configuration of the clients and servers (consult your client/server documentation for more information).
|
| Router interface is not functioning
| Step 1: Check operation of router using show interfaces command. Look for interface and line protocol as "up" in status line.
|
|
| Step 2: If the interface is "administratively down," specify the no shutdown command on the interface.
|
|
| Step 3: If either the interface or protocol is down, check cable connections from the router. If necessary, replace the cable.
|
|
| Step 4: If after replacing the cable, you still cannot get the interface to come up (interface and line protocol shown as "up" in show interfaces output), contact your router technical support representative.
|
|
|
|
| Router network number specification is misconfigured for NetWare 2.15, causing problems for RIP
| Step 1: Check router configuration to see whether Novell routing is enabled. If not, add the novell routing global configuration command and other commands as necessary (refer to Router Products Configuration and Reference publication).
|
|
| Step 2: Get the network number from target network server.
|
|
| Step 3: Compare with network number specified on router (using write terminal or show novell interface commands).
|
|
| Step 4: If network numbers do not match, reconfigure router with correct network numbers.
|
|
| Step 5: If network numbers do match, check the router interface on the client side and make sure that the network number assigned is unique with respect to all network numbers in your Novell internetwork. On the server side of the router, make sure that the network number assigned to the router interface matches the network number for the server.
|
| Router network number specification is misconfigured for NetWare 3.11, causing problems for RIP
| Step 1: Check router configuration to see whether Novell routing is enabled. If not, add the novell routing global configuration command and other commands as necessary (refer to Router Products Configuration and Reference publication).
|
|
| Step 2: Get the external network number of the server's interface attached to the network to which the router is also attached. Do not use the 3.11 server's internal network number.
|
|
| Step 3: Compare the external network number with network number specified on router (write terminal or show novell interface commands).
|
|
| Step 4: If network numbers do not match, reconfigure the router with correct network numbers.
|
|
| Step 5: If network numbers do match, check the router interface on the client side and make sure that the network number assigned is unique with respect to all network numbers in your Novell internetwork.
|
| NetWare 2.15 and 3.11 network number mismatch on same network or backbone. This causes problems for RIP, which relies on network numbers to route traffic
| Step 1: If NetWare 2.15 servers are on the same physical cable with NetWare 3.11 servers, the network number for the connected interface of any 2.15 server and the external network number for the connected inteface of any 3.11 server must match.
Step 2: If these numbers do not match, reconfigure the servers to make them match. Refer to the server documentation for information concerning these modifications.
|
|
|
|
| Bad access list
| Step 1: Remove novell access-group specifications on all relevant interfaces.
|
|
| Step 2: See whether traffic can get through by testing the connection function from the client to the target server.
|
|
| Step 3: If connection now works, access list needs modification.
|
|
| Step 4: Apply one access list statement at a time until you can no longer create connections to isolate the location of the bad access list specification.
|
|
| Step 5: Make sure that access lists are applied to the correct interface. Filters must be applied to the outgoing interfaces for normal (standard) traffic filters.
|
| Backdoor bridge between segments
| Step 1: Use the show novell traffic command and determine whether the "bad hop count" field is incrementing.
|
|
| Step 2: If this counter is increasing, use a network analyzer to look for packet loops on suspect segments. Look for routing and SAP updates. If a backdoor bridge exists, you are likely to see hop counts incrementing up to 16; the route will disappear and can reappear unpredictably.
|
|
| Step 3: Also look for known remote network numbers that show up on the local network. That is, look for remote network numbers that are not being handled by the router (source address is not the router's).
|
|
| Step 4: Isolate the local Ethernet into smaller segments (using a fanout or similar device).
|
|
| Step 5: Examine the traffic on each segment with a protocol analyzer. If a packet appears from a known remote node (has a remote source address) the back door is located on that segment.
|
| Duplicate network numbers on Novell servers
| Step 1: Use the show novell servers command to look for duplicate network numbers.
|
|
| |
|
| Step 2: If duplicates are found, modify server configurations so no duplicates exist on your internet.
|
|
|
|
| Nonfunctional FDDI ring
| Step 1: Use the show interfaces fddi command to determine status of interface.
|
|
| Step 2: If show interfaces fddi indicates interface up/line protocol up, use the ping novell command between routers to test connectivity to routers.
|
|
| Step 3: If interface is up and line protocol is up, make sure the MAC addresses of upstream and downstream neighbors is as expected.
|
|
| |
|
| Step 4: In this case, (or if status line does not indicate interface up/line protocol up), check connections at patch panel or connectivity between routers using an optical TDR or light meter. Ensure that signal strength is within specification.
|
| Nonfunctional serial link
| Step 1: Use show interfaces serial command to determine status of interface.
|
|
| Step 2: If show interfaces serial indicates interface up/line protocol up, use the ping novell command between routers to test connectivity to routers.
|
|
| Step 3: If routers do not respond to ping test, follow troubleshooting techniques as discussed in Chapter 7, "Troubleshooting WAN Connectivity."
|
| Nonfunctional Ethernet backbone
| Step 1: Use the show interfaces ethernet command to determine status of the interface. Determine whether status indicates interface up/line protocol up.
|
|
| Step 2: If the status line does not indicate interface up/line protocol up, check the router's physical attachment to Ethernet backbone.
|
|
| Step 3: If show interfaces ethernet indicates interface up/line protocol up, use the ping novell command between routers to test connectivity to routers.
|
|
| Step 4: Obtain analyzer traces and look for packets from target servers, clients and routers.
|
|
| Step 5: Any known nodes that do not appear as expected are suspects for being problem nodes. Locate and determine whether entity and attached cables are functional. If not, replace or reconfigure as needed.
|
| Mismatched Ethernet encapsulation methods
| Step 1: Check encapsulation types for clients and servers.
Step 2: Compare with router encapsulation type assigned.
|
|
| |
|
| Step 3: If servers and client are using what Novell refers to as "Frame Type Ethernet _II," make sure that the router is also using this form--assigned using the novell encapsulation arpa interface subcommand.
|
|
| |
|
| Step 4: If clients and servers are using SNAP or Ethernet_802.2 encapsulation, change client/server encapsulation type to either Frame Type Ethernet_802.3 or Ethernet_II.
|
|
| Step 5: As a last resort, disable Novell routing and enable bridging.
|
|
| |
| Nonfunctional Token Ring backbone
| Step 1: Use show interfaces token command to determine status of interface.
|
|
| Step 2: If status line indicates that the interface and line protocol are not up, check cable from router to the MAU. Make sure that the cable is good; replace if necessary.
|
|
| Step 3: If show interfaces token indicates interface up/line protocol up, use the ping novell command between routers to test connectivity to them.
|
|
| Step 4: If the remote router does not respond, check the ring specification on all nodes attached to the Token Ring backbone. Ring speed for all must be the same.
|
|
| Step 5: If necessary, modify ring speed specifications for clients, servers, and routers.
|
|
| Step 6: Use the ring speed command to modify ring speed configuration for IGS/TR. Change jumpers as needed for modular router platforms. Refer to your system's hardware installation and maintenance manual for more information about ring speed specification.
|
Symptom: Service Advertisement Protocol (SAP) packets generated by servers broadcast the specific Novell services offered by a particular server. Here, the SAP updates appear to be unable to get through from one side of a router to the other.
Table 5-2 outlines possible causes of SAP updates not getting broadcast on the other side of a router.
Causes and Actions for SAP Updates Not Being Broadcast
| Possible Cause
| Suggested Actions
|
|---|
| Novell server is not sending SAP updates
| Step 1: Use protocol analyzer to look for SAP updates from the server.
Step 2: If the server is not sending SAP updates, make sure the server is attached to the networks and that it is configured to send SAP updates (not configured to withhold SAP updates).
|
|
| Step 3: In an Ethernet-based environment, if the server is sending SAP updates, check the encapsulation type in the router configuration; it must match the Novell server encapsulation specification (Frame Type Ethernet_802.3 or Frame Type Ethernet_II).
|
| Ring speed specification discrepancy
| Step 1: Check ring speed specifications on Novell servers and routers (4 or 16 Mbps).
|
|
| Step 2: If they do not match, for IGS/TR, use ring speed command to make the router configuration match server specifications. For modular systems, refer to the appropriate installation and maintenance manual for proper 4- or 16-Mbps jumper settings.
|
| Bad access lists
| Step 1: Disable any SAP-specific access lists by removing novell input-sap-filter and novell output-sap-filter commands as appropriate.
|
|
| Step 2: If you have a Novell client on other side of router, use the client's slist command to verify that services are being advertised for the server. The display servers command can also be used from the server console.
|
|
| Step 3: As an alternative, run debug novell-sap command on the router. Look for server name, network number, and MAC address.
|
|
| Step 4: If the Novell server's SAP information is included in the router's updates, the access list is causing SAP updates to be dropped at the router.
|
|
| Step 5: Revise access lists or filter statements as necessary and apply individually to ensure that updates are being distributed appropriately.
|
| Misconfigured network number on router or Novell server. This causes problems for RIP, which relies on network numbers to route traffic.
| Step 1: Verify that there are no duplicate network numbers. Each Novell network must be unique.
Step 2: Use show novell route and/or show novell servers to determine whether any network number is duplicated on your network.
|
|
| Step 3: Ensure that all network numbers are unique. If not, modify server configurations or router's novell network specification as appropriate.
|
| Novell servers unable to handle the rate at which routers generate SAP updates
| Step 1: Compare output of show novell servers from the router with output of slist command from Novell clients.
Step 2: If the slist output on Novell server shows a partial listing of SAP entries, this is the likely problem.
|
|
| Step 3: To remedy, use the novell output-sap-delay command to specify the delay between packets in a multipacket SAP update. Use the lowest possible delay that corrects the problem. An initial value of 5 msec is recommended.
|
| Server configured to withhold SAP updates
| Step 1: Examine the specific server's configuration. Consult with the server's documentation to determine how to find this information.
|
|
| Step 2: If server is set to withhold SAP updates, change configuration to allow SAP updates.
|
|
| Step 3: Check for connectivity between file server and router, using the show novell server command.
|
| Limited-user version of NetWare software
| Step 1: Check the copy of software running on the server. If it is a limited-user version, you must upgrade the version to support more users.
|
| Nonunique MAC address on routers
| Step 1: Use the write terminal command to examine the current configuration of each router in the path.
|
|
| Step 2: Check the hardware address specified in the novell routing global configuration command.
|
|
| Step 3: If this system-generated number matches for both routers, reinitialize one of the routers and see whether connectivity over the link is re-established.
|
|
| Step 4: If the numbers still match, then get a real MAC address from one of the interfaces using the show interfaces command and assign that address to the router using the novell routing command (example: novell routing 0000.3080.09a7).
|
|
| |
Symptom: Clients are unable to get response from servers running Novell NetBIOS when connections are attempted over a router.
Table 5-3 outlines possible causes of clients' inability to connect to Novell NetBIOS servers over a router.
Causes and Actions for Blocked NetBIOS Traffic
| Possible Cause
| Suggested Actions
|
|---|
| Missing novell helper-address command
| Step 1: Run the debug novell-packet command. Look for Novell packets with unknown type 20 specification.
|
|
| Step 2: Use write terminal command to check router configuration for novell helper-address interface subcommand configured for incoming interface (for Novell NetBIOS traffic from stations).
|
|
| Step 3: If the novell helper-address command is not present, add it as appropriate.
|
|
| |
|
| |
| Misconfigured novell helper-address specification
| Step 1: Check router interface configuration on client side for novell helper-address specification.
Step 2: Make sure the MAC address field specified in this command is a type of broadcast.
|
|
|
|
| Bad access list
| Step 1: Remove novell helper-list specifications on all relevant interfaces.
|
|
| Step 2: See whether traffic can get through by testing the connection function from the client to the target server.
|
|
| Step 3: If connection now works, access list needs modification.
|
|
| Step 4: Apply one access list statement at a time until you can no longer create connections to isolate the location of the bad access list specification.
|
|
| Step 5: Make sure that access lists are applied to the correct interface. Helper lists are applied to incoming interfaces.
|
Your Router Products Configuration and Reference publication provides details about configuration commands associated with helper address assignment. Refer to "Routing Novell IPX" in that publication for more information. The following illustrations and accompanying text discuss some of the implications of Novell helper address assignment, some potential pitfalls, and general behavioral characteristics.
Basic Helper Address Assignment
Consider the simple configuration illustrated in Figure 5-1. In this case, a router (Router-A) separates two Ethernet segments (Ethernet-2a and Ethernet-1d). Clients on Ethernet-2a must be able to access services from Server-1 and Server-2 on Ethernet-1d.
Figure 5-1: Basic Helper Address Network
The helper address specification would be as follows:
interface ethernet 0
novell network 2a
novell helper address -1.ffff.ffff.ffff
Here, -1 is used to specify flooding to all nets.
As an alternative, you also can specify a specific network number. In this case, you would specify Novell network 1d as follows:
interface ethernet 0
novell network 2a
novell helper address 1d.ffff.ffff.ffff
Helper Address Configuration over Single Serial Interconnection
The configuration illustrated in Figure 5-2 is nearly identical to the configuration illustrated in the preceding illustration, except that here Ethernet-2a and Ethernet-1d are separated by a serial network and two routers (Router-A and Router-B). As before, clients on Ethernet-2a must be able to access services from Server-1 and Server-2 on Ethernet-1d.
Figure 5-2: Single Serial Interconnection Helper Address Network
Assuming the use of the all nets broadcast address, the helper address specifications for the two routers would be as follows:
!Router-A helper address specification:
!
interface ethernet 0
novell network 2a
novell helper-address -1.ffff.ffff.ffff
!
!Router-B helper address specification:
!
interface serial 0
novell network 3e
novell helper-address -1.ffff.ffff.ffff
As in the prior example, -1 is used to specify flooding to all nets. Note that the helper address specification is required on Router-B because of the use of the all nets (-1) network specification (on Router-A). You can specify a specific network number as an alternative. In this case, you would specify Novell network 1d as follows on Router-A only:
!Router-A helper address specification:
!
interface ethernet 0
novell network 2a
novell helper-address 1d.ffff.ffff.ffff
Helper Address Configuration over Multiple Serial Interconnections
The key difference between the following example and prior examples is that Server-1 and Server-2 are now on separate Ethernet segments and are accessed by clients via separate routers (Router-B and Router-C.). Refer to Figure 5-3
There are two ways to propagate broadcasts: by using the all nets broadcast option or by using multiple, directed-broadcast helper address commands. If you use the all nets specification, all three routers must include helper address specifications.
Figure 5-3: All Nets Multiple Serial Line Helper Address Specification
The all nets broadcast configurations for the router would be as follows:
!Router-A helper address specification:
!
interface ethernet 0
novell network 2a
novell helper-address -1.ffff.ffff.ffff
!
!Router-B helper address specification:
!
interface serial 0
novell network 3e
novell helper-address -1.ffff.ffff.ffff
!
!Router-C helper address specification:
!
interface serial 2
novell network 5f
novell helper-address -1.ffff.ffff.ffff
Note that the helper address specification is required on both Router-B and Router-C because of the use of the all nets (-1) network specification. on Router-A.
With Software Release 9.1, you can direct broadcasts to more than one network using multiple network number specifications on the same interface. Figure 5-4 illustrates an example where this multiple helper address command specification is applied.
Note Prior to Software Release 9.1, Cisco routers only supported the assignment of a
single helper address per interface. To allow clients to access servers on multiple segments required specifying the all nets broadcast (ffffffff or -1) in a helper address. However, as of Software Release 9.1, multiple, directed broadcasts can be specified (on a per interface basis).
Figure 5-4: Directed Broadcast Helper Address Specification
The corresponding multiple helper address configuration would be modified as outlined in the following listing.
!Router-A helper address specification:
!
interface ethernet 0
novell network 2a
novell helper-address 1d.ffff.ffff.ffff
novell helper-address 4c.ffff.ffff.ffff
!
!Router-B helper address specification:
!
interface serial 0
novell network 3e
!
!Router-C helper address specification:
!
interface serial 2
novell network 5f
In some cases, a NetBIOS server returns a broadcast response to client queries. This reverse broadcast must be handled similarly to normal helper address specifications for client queries.
Figure 5-5 illustrates a situation in which three sets of clients on three separate segments all must access a common file server (Server-X) on Ethernet-3F. In this case, the server supports a version of Novell NetBIOS in which the server broadcasts its response to the client queries. In this situation, Router-Hub must be configured with helper addresses on all four Ethernet interfaces illustrated in Figure 5-5.
Figure 5-5: Reverse Broadcast Helper Address Network
The Novell helper address configuration for the Router-Hub interfaces would be as follows:
!Router-Hub helper address specifications:
!
interface ethernet 0
novell network 3f
novell helper-address -1.ffff.ffff.ffff
!Required for reverse broadcast response from Server-X
!
interface ethernet 1
novell network 2a
novell helper-address -1.ffff.ffff.ffff
!Normal client broadcast specification
!
interface ethernet 2
novell network 4b
novell helper-address -1.ffff.ffff.ffff
!Normal client broadcast specification
!
interface ethernet 3
novell network 5c
novell helper-address -1.ffff.ffff.ffff
!Normal client broadcast specification
Note Not all Novell NetBIOS servers require configuration of a helper address on the server interface. Consult with your host documentation to determine whether it generates a broadcast response (reverse broadcast) to client queries.
Helper Behavior with Parallel Routers
Use care in assigning broadcast-type helper addresses when Novell networks are interconnected over multiple routers and when file servers are using Novell NetBIOS. Although traffic will not permanently loop, local client queries can leak out through a router, resulting in a certain amount of excess traffic. Consider the situation illustrated in Figure 5-6.
Figure 5-6: Novell Helper Address Handling with Parallel Routers
In this example, helper addresses are assigned to the Ethernet interfaces on Router-A and Router-B. The interface configurations might be as follows:
!Router-B helper address specifications:
!
interface ethernet 0
novell network 1a
novell helper-address -1.ffff.ffff.ffff
!
interface ethernet 1
novell network 2b
novell helper-address -1.ffff.ffff.ffff
!
!Router-A helper address specifications:
!
interface ethernet 2
novell network 1a
novell helper-address -1.ffff.ffff.ffff
!
interface ethernet 3
novell network 2b
novell helper-address -1.ffff.ffff.ffff
Consider what happens to Packet-Y from Client-A that is destined for Server-Y on Novell network 2b. Assuming that no access lists are in place, say that Router-B is the first to get a query from Client-A. Since the query is intended for an offnet host, Router-B broadcasts the query out Ethernet interface E1 and onto Novell network 2b. The broadcast finds its way to Server-Y (hopefully causing a response, assuming Server-Y is operational) and also lands at Ethernet interface E3 on Router-A. There the packet is dropped. This is the expected behavior.
Note Server-Y actually receives two copies of Packet-Y, one via Router-A and one via Router-B. The serve'rs response depends on its application implementation.
Now consider Packet-X, a client query from Client-B also intended for Server-Y. In this case, the broadcast packet finds its server on the same wire to which it is connected. However, Router-A forwards this broadcast, because the source address is local--which puts the locally targeted packet onto Novell network 1a. This packet will continue to propagate outward through the network until the internet terminates (or until the packet has traversed 15 routers), but it will not leak back into Novell network 2b because the routers see that the source network in the packet is 2b. In no case is the packet sent back along the path to the source network of the packet. In the preceding example, the packet would be dropped when it reaches Ethernet interface E0 on Router-B.
This situation is a type of partial loop. True routing loops are prevented, but some excess traffic is created.
Note To prevent this from happening, you can use network-specific broadcasts. However, you may not be able to do so if many clients and servers must access each other on segments separated by parallel routers. Depending on your configuration, increasing the number of paths the router can store for each destination may reduce the amount of excess traffic. Use the
novell maximum-paths command to do this.
Symptom: Local servers are responding, but servers on the other side of a packet-switching network that interconnects routers do not respond. Router appears to block IPX over the packet-switched network.
Table 5-4 outlines possible causes of blocked access to a Novell servers over packet-switched networks.
Causes and Actions for Blocked Novell Traffic over PSNs
| Possible Cause
| Suggested Actions
|
|---|
| X.25 address mapping error
| Step 1: Using write terminal command, examine configuration of router.
|
|
| Step 2: Make sure that the MAC addresses and X.121 addresses specified in any x25 map novell interface subcommands match the addresses associated with the respective destination routers.
|
|
| |
| Frame Relay address mapping error
| Step 1: Using write terminal command, examine configuration of router.
Step 2: Make sure that the MAC addresses and DLCI addresses specified in any frame-relay map novell interface subcommands match the addresses associated with the respective destination routers.
|
|
| |
| Misconfigured network number specification on servers or on routers
| Step 1: Refer to Table 5-1 and the symptom discussion for "Clients Cannot Communicate with NetWare Servers over Router" for a discussion about diagnosing and resolving this problem.
|
| Encapsulation error
| Step 1: Use write terminal or show interfaces command to determine encapsulation type.
|
|
| Step 2: Look for relevant packet-switching encapsulation type (such as x25 encapsulation or frame-relay encapsulation).
|
|
| Step 3: If an encapsulation command is not present, the default is HDLC encapsulation.
|
|
| Step 4: For PSN interconnection, you must explicitly specify an encapsulation type.
|
When routing Novell IPX (or any protocol) over a packet-switched network, you must specify mapping between Novell and packet-switched network addresses. Consider the two examples illustrated in Figure 5-7 and Figure 5-8. Figure 5-7 illustrates an address map specification when routing Novell IPX over an X.25 PSN, while Figure 5-8 illustrates an address map specification when routing Novell IPX over a Frame Relay network. Relevant configurations and a brief explanation of command variables are provided in the following discussions. Refer to the Router Products Configuration and Reference publication for more information about address map specifications.
Address Mapping for Novell-to-X.25 Interconnection
As illustrated in Figure 5-7, Novell-to-X.25 address map specifications would be required for both Router-A and Router-B.
Figure 5-7: Example Network Diagram Illustrating Novell-to-X.25 Mapping
The specific interface specifications would be as follows:
!
interface serial 0
x25 map novell 3c.0200.0c00.5552 15552223334 broadcast
! Above specifies Novell-to-X.121 address map configuration for Router-A
interface serial 1
x25 map novell 3c.0800.0c00.4321 15551231234 broadcast
! Above specifies Novell-to-X.121 address map configuration for Router-B
In the preceding configurations, the MAC address is obtained using the write terminal command on the target router. Look for the novell routing command in the configuration listing. It is displayed with the auto-generated MAC address appended to the command. For example, for Router-A in Figure 5-7, you would see the following listing:
novell routing 0800.0c00.4321
Address Mapping for Novell-to-Frame Relay Interconnection
Figure 5-8 illustrates essentially the same interconnection arrangement as illustrated for the preceding X.25 example address mapping configuration, except that the PSN used is a Frame Relay network. In an analogous manner, Novell-to-Frame Relay address map specifications would be required for both Router-A and Router-B.
Figure 5-8: Example Network Diagram Illustrating Novell-to-Frame Relay Mapping
The specific interface configurations would be as follows:
!
interface serial 0
frame-relay map novell 3c.0800.0c00.5552 20 broadcast
! Above specifies Novell-to-DLCI address map configuration for Router-A
interface serial 1
frame-relay map novell 3c.0800.0c00.4321 30 broadcast
! Above specifies Novell-to-DLCI address map configuration for Router-B
In these example configurations, the MAC address is obtained in the same manner as described in the X.25 example: use the write terminal command on the target router and look for the novell routing command in the configuration listing.
