Jeff-

Thanks for your response.  You have provided additional possibilities to
which investigation is needed.

Just to answer a few of the questions.

1. NO..Simple "PING" commands do NOT work when the problem is occurring.
Either from the GUI
or from the command line.

2.  The Netview Server is a SUN Solaris (multi-homed interfaces) hme0 & hme1
(the hme1 is not used internal network)

3. The IP'S that can not be reached are on five different subnets.
Three networks are 24 bit masks, two others have 23 bit masks.

4.  I suspect the problem is at the host site, not with the Netview Server.

The DNS problem seems suspect, but we are not having any symptoms with DNS.
Had I not setup a weekly backup of Netview with shutting down the daemons,
we would have never seen this problem.

In any event unless Support comes back with a better solution, I plan on
going through you suggestsions.

Thanks again for your tips.









Hi John.

First it does sound like an ARP issue but more information is needed.
Can you get a simple command line ping to work?
Does the Netview server have multiple interfaces and what are they?
What are the IPs of the devices you can't reach?
What are the masks of the devices?
Where is the problem the server or the host?
Check the obvious first.  Default routes and masks on each end and
routers in between.
It could be a DNS lookup issue.  Always an issue with multiple
interfaces if not done right.

Understand it could involve the server mask, RIP version (1 or 2),
default route or node mask or route or is it multi-homed.

The first thing the server will do when pinging a host, is resolve the
name, either by /etc/hosts or by DNS.
Second it looks at the IP dest. and looks in the routing table for the
longest match.

1.  If if finds it is on one of the servers interfaces (exact net match
or host route) it looks in the arp table for a match of the IP dest.
If a match occurs, it sends ping to that mac address.

If not, it arps on that interface for dest IP. Remember since the arp
request is broadcast anybody can respond and even multiple responses,
but the last arp response received will change it.

The host hears the arp request (it better) and should respond to the
source. It can also glean the source mac of the arp request so it
doesn't have to arp for it.

It will now send an arp response back to the source (In this case the
netview server).  This also involves masks and routing tables to
determine where to send it.  It may be going back out the wrong
interface or using default route.



2.  The other possibility it is the next hop is a router because the
exact match of net didn't occur, so the default is used.

There are lots of things to look at for a simple ping to work even more
than what I have mentioned here.

But basically both ends must know what mac to send the packet too, ping
or any other.

When it doesn't work understand what the path should be and gather all
the IP and mac info.  Is it right for both directions?

Hope this might help.

Jeff Fitzwater
CIT Systems & Networking
Princeton University
__________________