Novell is now a part of Micro Focus

My Favorites

Close

Please to see your favorites.

Troubleshooting IP Routing Issues

(Last modified: 23Aug2005)

This document (10011169) is provided subject to the disclaimer at the end of this document.

goal

TROUBLESHOOTING IP ROUTING ISSUES

fact

Novell Operating Systems

Novell Suites

Novell BorderManager

Novell Connectivity Products

Novell GroupWare/Collaboration

3rd Party Operating Systems and Products

Novell Printing Services

Novell Clients

Novell eDirectory

Novell NIAS/BMAS

symptom

Cannot ping past NetWare server 

Cannot ping past Internet Router 

Cannot ping router on same segment

Workstation can ping both cards on server but not the router on other segment

Cannot ping Workstation

Cannot ping UNIX Server

fix

The following scenarios will reference Figure 1: The most common solutions will be given.  It is not a comprehensive list of solutions, but they will cover most of the routing issues.

For all TCPIP routing, when pinging, keep in mind that there are two separate transactions, first the ICMP Echo Request is sent from the original source to the original destination, then the ICMP Echo Reply is sent from the reply from source to the reply to destination (or original source). Both packets will follow their own TCPIP Routing.  To explain that concept in simple terms, imagine that you are the TCPIP stack on Workstation 1. You receive a TCPIP packet, so the first thing you do is look at the destination address.  The TCPIP stack "asks" itself a series of questions:

QUESTION 1: First, it asks, "is this packet destined for one of my local networks" (A device ALWAYS knows about the networks that it is bound to), if the packet is destined for a local network then all it needs to do is look in its ARP (Address Resolution Protocol) cache, if it finds the IP/MAC pair, then it just sends the packet to the MAC address of the destination, if the IP/MAC pair is missing then it sends out and ARP packet which basically says, "Hey! Does anyone out there have the TCPIP Binding for x.x.x.x" [in this case 192.168.43.x], the corresponding device, if any, then responds with its IP address and MAC address (IP/MAC pair), the Workstation adds the IP/MAC pair to the ARP table and sends the packet to the MAC address of the destination.

QUESTION 2: IF the IP Packet is NOT destined for the local network, THEN it asks, "Do I have a network route or host route for the network that this packet is destined for", if it does have a network route or host route then the next hop for the network route will be on the local segment and the workstation goes through question 1 and sends the packet to the next hop (then that router starts the process over again)

QUESTION 3: IF the IP packet is NOT destined for the local network, AND the workstation has NO NETWORK routes for the destination network, THEN it asks, "Do I have a default route", if it has a default route then the default gateway will be on the local segment and the workstation goes through question 1 and send the packet the the default gateway (then that router starts the process over again).
--------------------------------------------------------------------------------

symptom

Symptom
1. SCENARIO 1 - Workstation 1 Cannot ping past NetWare server.
From workstation 1, 192.168.43.2, I can ping to the local segment side of the NetWare server, 192.168.43.1. I Cannot ping from workstation 1 to the other side of the NetWare server, 192.168.1.1.
--------------------------------------------------------------------------------

fix

Possible Solutions:

1. Check the workstation.  Workstations need to know what router to send IP packets to when the destination is on a different segment.  Each tcpip stack configuration has a parameter for a default router or gateway.  In this scenario the workstation would need to configure its default router with the IP address of the LAN card in the server local to the workstation.  The address in this scenario would be 192.168.43.1.  The workstation may then need to be re-booted (depending on the operating system).

2. Check the server.  The server also needs to be configured as an IP router.  Ensure that TCPIP has been loaded with the parameter "forward=yes" (In INETCFG, go to Protocols, TCPIP, set IP Packet Forwarding: ENABLED "ROUTER", then try "REINITIALIZE SYSTEM, or reboot to make sure.).  The best way to verify that TCPIP has been loaded as such is to use the TCPCON.NLM utility.  Load TCPCON.  In the top window, lower left hand corner is the statistic "IP forwards" If this has a number after it, even if it is 0, then it is in an IP router mode.  If it has DISABLED after the statistic then it is not in gateway mode.

If the workstation was not able to ping anything, then possible causes could be, the NIC card, cabling, the Switch/Hub, Speed/Duplex of the NIC card, or possibly filtering on the server (try UNLOAD IPFLT to disable IP Filters on the NetWare Server)
--------------------------------------------------------------------------------

symptom

2. SCENARIO 2 - Workstation 1 can ping both cards on server but not the router on other segment.
From workstation 1, 192.168.43.2, can ping both cards in the NetWare server, 192.168.43.1 and 192.168.1.1. Cannot ping the Internet Router, 192.168.1.4.
--------------------------------------------------------------------------------

fix

Possible Solutions

1. The Internet Router most likely does not have a route back to the 192.168.43.0 segment.  Either a static route must be added to the Internet Router, telling it in order to get to segment 192.168.43.0 it must go through the gateway of 192.168.1.1, (the IP address of the NetWare server for the segment local to the Internet Router).  One way of testing is to see if Workstation 1 can ping Workstation 2 (ASSUMING that Workstation 2's Default Gateway is 192.168.1.4), It will not be able to.  CHANGE Workstation 2's Default gateway to 192.168.1.1, THEN the two workstations should be able to ping eachother, [NOTE: This is not the solution, just a test to show you that Workstation 2's original default gateway, the router 192.168.1.4, has a problem sending packets to the network 192.168.43.0]

A quick note on Routers (or devices acting as routers), unless you have a dynamic routing protocol (RIP, OSPF, etc) properly setup and working correctly, then you will need to setup static routes on your routers.  The easiest way of describing what routes you need to setup is this, for ANY network where the destination is on ANY of the routers interfaces OTHER than the default gateway, INCLUDING REMOTE NETWORKS, this router will need to be setup with Network routes to the next hop router (remember this address is ALWAYS local to the server), so an example:

Network 3 subnet 192.168.15.0
Router between 3 and 2 with ip addresses of: 192.168.10.1 and 192.168.15.254
Network 2 subnet 192.168.10.0
Router between 2 and 1 with ip addresses of: 192.168.1.1 and 192.168.10.254
Network 1 subnet 192.168.1.0
Router between 1 and the internet with ip addresses of: 137.65.1.1 and 192.168.1.254
ISP Router 137.65.1.254
Internet

So the Router between 1 and the internet needs to have the following routes:
Default Route 0.0.0.0 mask 0.0.0.0 gateway 137.65.1.254
Network Route 192.168.10.0 mask 255.255.255.0 gateway 192.168.1.1
Network Route 192.168.15.0 mask 255.255.255.0 gateway 192.168.1.1

the router between 2 and 1 needs the following routes:
Default Route 0.0.0.0 mask 0.0.0.0 gateway 192.168.1.254
Network Route 192.168.15.0 mask 255.255.255.0 gateway 192.168.10.1

the router between 3 and 2 needs the following route:
Default Route 0.0.0.0 mask 255.255.255.0 gateway 192.168.10.254

So a packet from the internet destined for the address 192.168.15.12 would first hit the router 137.65.1.1 (assuming the ISP's routes are all good, and realizing that in reality a packet destined for 192.168.anything will not be routed on the internet, but this is just for demonstration), then that router will see in its routing table that if it needs to send a packet to 192.168.15.12 it needs to send it to the next hop of 192.168.1.1, then that router looks in its routing table and sees that it needs to send the packet to 192.168.10.1, and since 192.168.10.1 is BOUND to 192.168.15.254 it can just send the packet to the destination 192.168.15.12.

To re-emphasize, a router needs to know about all networks that cannot be reached by sending a packet to its default route, whether through dynamic routing protocols, or through static route configuration.
--------------------------------------------------------------------------------

symptom

Symptom
3. SCENARIO 3 - Workstation 1 cannot ping Workstation 2
From workstation 1, 192.168.43.2, I can ping both cards in the NetWare Server, 192.168.43.1 and 192.168.1.1, I can ping the Internet Router, 192.168.1.4 but I cannot ping workstation 2, 192.168.1.2.
--------------------------------------------------------------------------------

fix

Fix
Possible Solutions:

The logical question that you would then have to ask is, "What CAN workstation 2 ping?". For this example we test Workstation 2 and see that it can ping itself, The Server at 192.168.1.1, the Linux box, the Server at 192.168.1.4, but nothing else.  We check the Linux box and see that it can ping everything, including internet addresses, so we must conclude that the problem is with Workstation 2.

As in scenario 1, the workstation must have its default router or gateway set in order to reply or send packets to segments other then its local segment.  Configure the default gateway on workstation 2, in this scenario, to the IP address of either the Internet Router, 192.168.1.4 or the LAN card in the NetWare server local to work 2's segment which would be 192.168.1.1 (It's best that you configure it to point towards the internet since that is where the most diverse traffic will go, an exception to this is where workstation 2 would be sending more than 90% of it's TOTAL IP traffic to a device on a network OTHER than in the direction of the internet).  You may need to reboot the workstation for the IP Routing changes to take effect.
--------------------------------------------------------------------------------

symptom

Symptom
4. SCENARIO 4 - Workstation 1 cannot ping Linux box
From workstation 1, 192.168.43.2, I can ping both cards in the NetWare Server, 192.168.43.1 and 192.168.1.1, I can ping the Internet Router, 192.168.1.4 but I cannot ping Linux box, 192.168.1.3.
--------------------------------------------------------------------------------

fix

Possible Solution

Same as in Scenario 3, add a default route.
--------------------------------------------------------------------------------

symptom

Symptom
5. SCENARIO 5 - Workstation 1 cannot ping past Internet Router
From workstation 1, 192.168.43.2, I can ping both cards in the NetWare Server, 192.168.43.1 and 192.168.1.1, I can ping the Internet Router, 192.168.1.4. I can ping both workstation 2, 192.168.1.2 and the UNIX box 192.168.1.3,  but I cannot ping past the Internet Router.

--------------------------------------------------------------------------------

fix

Possible Solution

In this scenario the NetWare server knows about both the 192.168.43.0, and the 192.168.1.0 segments, but does not know where to route the packet to next if the destination is neither one of these segments.  A default route must be added to the NetWare server. 
--------------------------------------------------------------------------------

symptom

6. SCENARIO 6 - Cannot receive internet mail
The NW Server that is acting as a BorderManager, Email Server, and Router, is running an email program, (ie receives SMTP traffic on port 25), The port is shown as listening, the server is running NAT, and the internet device that is trying to send mail to 137.65.1.1 IS able to ping the public address.  The internet device is NOT able to telnet to port 25 on the email server.
--------------------------------------------------------------------------------

fix

Possible Solution

In this scenario Workstation 1 and Workstation 2 CAN telnet to 192.168.1.4 port 25.  The problem is NAT, when NAT loads then the server (by default) will not listen on ANY PUBLIC PORT (In TCPCON it SHOWS that the port is in a listen state, but the TCPIP stack never hands off the packet to the application, it hands ALL Packets to NAT).  IF you either SET NAT DYNAMIC MODE TO PASS THRU=ON, or (the correct way is to) load INETCFG, TCPIP, NAT Implicit Filtering: DISABLED, REINITIALIZE SYSTEM, if reinitialize system doesn't work, reboot the server, it will then receive traffic destined for the public IP address (ie, SMTP, DNS, VPN, WEBSERVER, etc).

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.

  • Document ID:
  • 10011169
  • Solution ID: 4.0.1203129.2199501
  • Creation Date: 22Jun1999
  • Modified Date: 23Aug2005
    • NovellConnectivity Products

      End of Life

      Groupware

      NetWare

      BorderManager Services

      eDirectory

      Novonyx

      Volera Excelerator

Did this document solve your problem? Provide Feedback