This section contains IP troubleshooting information that is divided into three categories:

• Troubleshooting tools
• Troubleshooting checkpoints
• Common problems

If a problem that is general in nature occurs, the procedure described in "Troubleshooting Checkpoints” will help you isolate and resolve the problem. If a problem with a specific symptom occurs, refer to "Common Problems.”

Troubleshooting Tools

TCPCON is an NLM utility that provides access to statistics and information about the status of various components of the TCP/IP protocol suite. It uses SNMP to access this information from any local or remote system on the network. TCPCON operates over TCP/IP and IPX networks. Use TCPCON to monitor and test a remote system (parameter path: Select SNMP Access Configuration > Transport Protocol > TCP/IP). Set the Host option to the IP address of the remote host you want to test. If details from that remote host are displayed, the remote host is functioning.

You can use TCPCON to perform the following tasks:

• Monitor activity in the TCP/IP network segments of your internetwork
• Display configuration information and statistics about the following TCP/IP protocols: IP, ICMP, UDP, TCP, OSPF, and EGP
• Display the IP routes currently known to a TCP/IP node
• Display the network interfaces supported by a TCP/IP node
• Access the trap log maintained by SNMPLOG (for local systems only)
• Access TCP/IP information in any remote protocol stack supporting the TCP/IP Management Information Base (MIB)

NOTE: TCPCON requires SNMP to be loaded on the remote host; otherwise, you receive an error message that the host is unavailable. Another cause of the error message might be a routing error. To check for errors in the routing table on a Novell Internet Access Server 4.1 machine, accept the default value of 127.0.0.1 in the Host option under SNMP Access Configuration. Select Routing Table to view the routing information table that the routing software has received from routing protocols (RIP and OSPF) or static routes. Compare this to the address topology of the network.

Troubleshooting Checkpoints

To isolate and resolve TCP/IP problems, complete the following steps:

1. Load TCPCON to verify that IP is bound to the desired interfaces with the correct addresses and masks for your internetwork (parameter path: Select Protocol Information > IP > IP Addresses).

   Use NIASCFG to make any required corrections.

2. Load TCPCON to check the routing table for routes to the required network (parameter path: Select IP Routing Table > Proceed and press Enter).

   If routes are missing, verify that the required routing protocols have been enabled and bound to the correct interfaces in NIASCFG. Also verify that the routing protocol in use on an interface is correctly configured on other routers that are accessible through that interface. Finally, use FILTCFG to check for filters that would interfere with the propagation of routes.

3. Load NIASCFG to verify that static routing is configured if other third-party routers that do not use RIP or OSPF are connected on the network (parameter path: Select Configure NIAS > Protocols and Routing > Protocols > TCP/IP > Static Routing).

4. Load NIASCFG to verify that the IP Packet Forwarding statistic is set to Enabled (parameter path: Select Configure NIAS > Protocols and Routing > Protocols > TCP/IP > IP Packet Forwarding).

   Use NIASCFG to make any required corrections and then reinitialize the system.

5. Use PING or TPING to test connectivity.

   Perform Step 1 through Step 4 on any routers that cannot be reached. Start with the router that is closest to the local node.

6. Use CALLMGR to determine the state of WAN connections (Retry, Out-Queued, or Disconnected).

   If the WAN connection is in the wrong state, perform the corrective action described in "WAN Connectivity Problems.”

7. Verify that all client software has the Default Router parameter configured to match the IP address of the network board inside the router that is connected to the local segment.

   If you are using the Novell LAN WorkPlace^® for DOS product, the IP_ROUTER option in the NET.CFG file sets this parameter.

8. Load TCPCON for the following IP statistics:

   • Local errors (memory error)

     If a problem exists, see Appendix A, "Resolving Memory Problems.”

   • IP errors (unexpected protocol errors)

     If a problem exists, check the configuration of other IP nodes on the network. Reduce IP traffic or use a network analyzer to identify the source of invalid packets.

   • IP address errors (misdirected packets)

     If a problem exists, check the Address Translation tables on other IP nodes to determine the source of the errors.

   • Unknown protocol errors (unsupported IP clients)

     If a problem exists, load the required applications.

   • No route found (router failure)

     If a problem exists, check the configuration of the routing protocols.

9. Load TCPCON for the following ICMP statistics:

   • Destination unreachable (network failure)

     If a problem exists, use a network analyzer to determine the unreachable destination. Check that the routers on the path to the destination advertise the route.

   • Time exceeded (network failure)

     If a problem exists, reduce the excessive delays by reducing the size of the internetwork or increasing the speed of WAN links.

   • Redirects (router failure)

     If a problem exists, check that all routers on the network are properly configured and advertising routes. Verify that the correct Default Router is configured on the clients.

10. Load NIASCFG to verify that all configuration options are set correctly (parameter path: Select Configure NIAS > Protocols and Routing > View Configuration).

Common Problems

This section discusses various symptoms of common problems and their potential solutions.

A Dial-In Router is Losing Connectivity

If multiple remote routers are dialing into a PPP group interface with WAN Network Mode set to Multiaccess, each router must have a unique IP address. If a duplicate address exists, one of the dial-in routers will lose connectivity, but no error message is issued.

Router Cannot Ping a Remote Router or the Internet

Load TCPCON and verify that there is a destination that is specified as the default route (parameter path: Select IP Routing Table). If there is no default route you must configure it. Load NIASCFG to permanently configure the default route.

To create a default route, complete the following steps:

1. Load NIASCFG and select Configure NIAS > Protocols and Routing > Bindings > TCP/IP.

2. Select the Interface Group for your WAN card.

3. Select WAN Call Destination.

   The Configured WAN Call Destinations menu appears.

4. Press Ins on the WAN Call Destination option and select the WAN card defined earlier.

5. Press Ins on the Static Routing Table option.

   The Static Routing entry sets up the default route that points to the Internet Service Provider (ISP).

6. Select Route to Network or Host and select Default Route.

7. Press Esc to save your changes and exit the menus.

WAN Link Comes Up, but Ping Receives No Reply

Load CALLMGR.NLM and initiate the call. If the link comes up and PPP and IP are negotiated, CALLMGR will show the calls as being Out-Connected. However, unless the routing tables on both sides are properly configured, IP packets will not be routed correctly.

Load PING.NLM on the server and ping the ISP's IP address. You should receive a reply. If you do not receive a reply, ensure that the default route appears in the routing table by loading TCPCON.NLM at the server console. Select IP Routing Table and press Enter. You should see an entry with the Default selected for Destination, Unspecified selected for Next Hop, and Remote selected for Type.

NOTE: For a permanent link, the line must be up for the default route to be visible through TCPCON. If the default entry does not show up, ensure that it is properly defined in the Binding for the WAN card.

For an unnumbered link, make sure that your network information card (NIC) is bound to the IP address assigned to you by the ISP.

If you can ping the ISP, but not beyond, check your IP addresses. For an unnumbered link, you must bind the local IP address the ISP gave you to the NIC in your system. Also, check with your ISP to make sure that it has a static route that points back to your network. The ISP must have a routing table entry that specifies that your destination network/host is reachable through the local IP address you have been assigned. This entry ensures that packets are properly routed back to your network.

LAN Connectivity Problems

• The router does not forward IP packets.

  Verify that the IP Packet Forwarding statistic is set to Router (Router indicates that it is enabled) in TCPCON (parameter path: Protocol Information > IP). If routing is not enabled, enable IP Packet Forwarding under Protocols in NIASCFG, then issue the REINITIALIZE SYSTEM command.

• A TCP/IP host cannot reach the router on the local network.
  • Verify that the router and host use the same frame type.

  • Verify that the network portion of the IP address and the subnet mask are the same on the router and the host.

  • Use PING from the router to verify connectivity to the
    TCP/IP host and verify that the IP Address Translation table has an entry for the host.

    If there is no entry, use MONITOR to check the status of the LAN driver.

  • Use PING from the router to verify connectivity to the
    TCP/IP host and check for Echo Requests in TCPCON (parameter path: Select Statistics > ICMP).

    If the value of the Echo Requests statistic is not incrementing, check the IP statistics for errors and perform Step 8 in "Troubleshooting Checkpoints.”

  • Use PING from the router to verify connectivity to the
    TCP/IP host and check for Echo Replies in TCPCON (parameter path: Select Statistics > ICMP).

    If the value of the Echo Replies statistic is not incrementing, verify that IP is bound to the host's interface with the correct address and mask. Also, verify that the interface driver is loaded with the correct frame type. If required, check the IP statistics for errors and perform Step 8 in "Troubleshooting Checkpoints.”

• A TCP/IP host cannot reach a remote host.
  • Verify that the local TCP/IP host has the local router listed as the default router.
  • Using PING, verify that the local TCP/IP host can reach each router on the path to the remote host.
  • Verify that each router has a routing protocol enabled and that it has not been disabled on the interface.
  • Starting at the local router, verify that each router has a route to the remote host's network.
  • Verify that there are no filters capable of blocking IP traffic configured on any routers along the path.
  • Verify that the remote host has a route to the local host's network.
  • Using PING, verify that the remote host can reach each router on the path to the local TCP/IP host.
  • Starting at the router closest to the remote host, verify that each router has a route to the local TCP/IP host's network.

• The router cannot initiate IP traffic to a remote router through a LAN interface.
  • Verify that IP is bound to the right interface with the correct address and mask.
  • Check whether the interface driver is loaded with the correct frame type.
  • Check whether a route exists to the network on which the destination router resides. This can be done through the IP Routing Table window of TCPCON. If the destination router is accessible, also verify that it has a route to the source router's network.

WAN Connectivity Problems

• A permanent WAN call destination is defined in the WAN Call Directory window of NIASCFG, but the call is not initiated through the interface when IP is bound to that interface.

  The permanent WAN call destination defined must be specified when configuring the binding (parameter path: Select Configure NIAS > Protocols and Routing > Bindings > a specific binding > Permanent WAN Call Destination).

• An on-demand WAN call destination to a remote router that is on the same LAN is defined in the WAN Call Directory window of NIASCFG. When an attempt is made to initiate IP traffic to this remote router, the WAN connection does not come up.

  Although the remote router is on the same network as the local router, a static route must be configured to the remote router address with the next hop as the on-demand WAN call destination.

• An X.25 WAN connection does not come up between two routers, and IP traffic cannot be initiated, even when one of the routers has a permanent WAN call destination configured to access the other router.

  To bring up a WAN connection through IP on an X.25 link in multiaccess mode, both routers must have WAN Call Destination/Remote IP Address Map configured for the link to the other router (parameter path: Select Bindings).

• The router cannot reach a remote WAN call destination.
  • Check the Boards, Network Interfaces, and WAN Call Directory configurations in NIASCFG.
  • Verify that the Remote System ID option and other authentication options are properly configured.
  • Verify that IP is bound to the interface.
  • For on-demand WAN connections, numbered point-to-point and unnumbered point-to-point links must have a static route with at least one IP address. Multiaccess links must have a static route or WAN mapping configured.
  • For permanent WAN connections, a permanent WAN call destination must be configured. X.25 multiaccess links must have WAN mapping configured in addition to a permanent WAN call destination.

• A remote WAN call destination cannot reach the router.
  • Check the Boards, Network Interfaces, and WAN Call Directory configurations in NIASCFG.
  • If a static route has been configured, verify that Remote System ID is properly configured.
  • For on-demand WAN connections (incoming), numbered point-to-point and unnumbered point-to-point links must have a static route configured, and the routing protocol must be enabled. When X.25 is being used, multiaccess links must have WAN mapping configured or the remote node will not support Internet Protocol Control Protocol (IPCP) or Address Resolution Protocol (ARP).

• An on-demand WAN connection is connected continually.
  • The routing protocol or router discovery is enabled on the interface.
  • TCPCON or PING to the remote host was left running.
  • Applications using IP or other protocols tunneled through IP might be generating IP traffic.

• An on-demand WAN connection connects and disconnects continually.

  Traffic is being generated by TCPCON, PING, router discovery, a routing protocol, or an application using IP or other protocols tunneled through IP, and the Idle Connection Timeout option is set to a value that is too low (10 minutes or less).

• Router software can ping the Internet, but clients cannot.

  Ensure that the client has a default route that points to the IP address of the NIC in the routing software. Also, verify that the IP address on the workstations are correct and belong to the same network to which the NIC is bound. On the server, verify that IP Packet Forwarding is set to Enabled.

  If you are using a numbered WAN link, the IP address bound to the NIC must be assigned to you by the ISP, and the local IP address bound to the NIC must be on a network different from the one that the remote IP address of the ISP is on.

  If you are using an unnumbered link, ensure that the IP address bound to the NIC is the correct address assigned by the ISP.

Routing Table Maintenance Problems

• Route updates are not sent to other routers on the frame relay cloud, even though IP and the routing protocol are enabled over the multiaccess WAN interface.

  Configure the Neighbor List option by specifying the IP address of routers to which route updates must be sent (parameter path: Select Configure NIAS > Protocols and Routing > Bindings > a specific binding > RIP (or OSPF) Bind Options).

• Routes are not exchanged on a LAN or WAN.
  • Use NIASCFG to verify that the IP Packet Forwarding option is enabled.

  • Use NIASCFG to verify that a routing protocol has been enabled.

  • Use NIASCFG to verify that the routing protocol has not been disabled on an interface.

  • Use TCPCON to examine the routing table and determine which routes are missing.

  • Check TCPCON for IP errors.

  • Check TCPCON for ICMP errors.

  • If you are using RIP, then in NIASCFG under Bindings, verify that the RIP Mode option is not set to Send Only or Receive Only.

  • If the RIP Version option is set to RIPII, verify that the other routers also support RIP II.

  • Verify that no route filters are configured that would block route information packets for that interface.

  • If you are using OSPF, verify that the following conditions have been met:

    Routers in the area have the same Authentication Type configured.

    All routers on the same network have the same Authentication Password configured for the interface to the network.

    All routers on the same network have the same Hello Intervals configured for the interface to the network.

    The state of each neighbor is either two-way or full in TCPCON (parameter path: Select Protocol Information > OSPF > Neighbors). If it is not, one of the two conditions described next will occur. Refer to the next two paragraphs for an explanation of the corrective actions required.

    In TCPCON, there is a router link state advertisement for each router in your area (parameter path: Select Protocol Information > OSPF > Link State Advertisements). If these advertisements are not present, verify that the missing router is active and the correct area ID is configured for the network interface.

    In TCPCON, the number of link state advertisements, Area Boundary Routers, and Autonomous System Boundary Routers are the same for each router in your area (parameter path: Select Protocol Information > OSPF > Areas). Verify that the problem routers are active. Bring down any router whose routing database is not synchronized with the databases of its routing neighbors. If the problem persists, reduce the size of your network or add more memory to the router.

• Routes are not exchanged on a LAN.

  Verify that the broadcast address is correct.

• Routes are not exchanged across a WAN connection.
  • Verify that the routing protocol is enabled on the WAN connection.
  • If you are using OSPF and the WAN Mode option is set to Multi-Access, verify that the correct routing neighbors are defined and that the address mappings are defined.

• RIP routes are not accessible to hosts on OSPF networks.
  • Check the status of the Autonomous System Boundary Router statistic in TCPCON (parameter path: Select Protocol Information > OSPF).
  • Verify that no filters are configured that would block access to the network.