Hi,

The server was not able to connect to the network. When arp -a was issued, 
the response from the server was very slow and initially the Mac address of 
the gateway was blank. When arp -a re-issued, the gateway entry was not 
listed. After I did a reboot of the server, the gateway entry is back in the 
arp table.

Is there a way to investigate why the arp table lost its data so as to 
prevent future occurrence?

Server: E4500
OS: Solaris 8


Thanks in advance. 

"Dolphin" <Dolphin@yahoo.com> writes:
> The server was not able to connect to the network. When arp -a was issued, 
> the response from the server was very slow and initially the Mac address of 

That usually indicates problems with the name service (DNS), not ARP.

Try using "arp -an".

> the gateway was blank. When arp -a re-issued, the gateway entry was not 
> listed. After I did a reboot of the server, the gateway entry is back in the 
> arp table.

Reboot shouldn't be necessary.

> Is there a way to investigate why the arp table lost its data so as to 
> prevent future occurrence?

Snoop _might_ give more information about this, but it's not
necessarily the case that having an ARP entry missing is actually a
problem.  ARP is dynamic; the system queries when it needs to, and
discards entries that aren't used.

If the system is actually in a state where it needs an ARP entry and
can't get it, then that sounds like something that snoop could help
resolve.  Perhaps that gateway refuses to respond to ARP queries at
times.

It's also worth noting that Solaris 8 is growing pretty old, and you
might want to consider upgrading to something newer.

-- 
James Carlson, KISS Network                    <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Dolphin wrote:
> Hi,
> 
> The server was not able to connect to the network. When arp -a was issued, 
> the response from the server was very slow and initially the Mac address of 
> the gateway was blank. When arp -a re-issued, the gateway entry was not 
> listed. After I did a reboot of the server, the gateway entry is back in the 
> arp table.
> 
> Is there a way to investigate why the arp table lost its data so as to 
> prevent future occurrence?
> 
> Server: E4500
> OS: Solaris 8
> 
> 
> Thanks in advance. 
> 
> 
"arp -a" just displays entries in the cache, it doesn't do anything
to "populate" the cache.  Entries in the arp cache time-out so before
being concerned about a "missing" entry you should try to "populate"
the cache, say by first "pinging" the hosts (on your subnet) in question,
or possibly transmitting a "broadcast ping". (Hosts may be configured
to not reply to a broadcast ping, or may filter ICMP echo requests,
so this may not help).

For example if your net is 192.168.0.0/24 you could ping the broadcast
address by:
	% ping -s 192.168.0.255
	^c
	% arp -a

If you are experiencing a delay, its probably due to a name resolution
problem.  Try "arp -an" to skip the reverse lookups.

Bob

Hi,

Appreciate you can advice the alternate way if reboot shouldn't be
necessary.

I got the following when I run snoop and direct to a file (ie snoop >
/tmp/mylog):

<dns> -> <my_server_name> DNS R  Error: 3(Name Error)

Am I right to say that there is problem getting respond from dns?

PS: This is my first time using snoop


Thanks in advance.

"Dolphin" <yc282004@yahoo.com.sg> writes:
> I got the following when I run snoop and direct to a file (ie snoop >
> /tmp/mylog):
> 
> <dns> -> <my_server_name> DNS R  Error: 3(Name Error)

That doesn't sound good.

> Am I right to say that there is problem getting respond from dns?

Yes, it sounds like it.  At a guess, you're missing IN PTR records for
in-addr.arpa (reverse name resolution).

> PS: This is my first time using snoop

You might find ethereal easier to use, but I don't want to force
another tool on you while you're in the middle of troubleshooting ...

-- 
James Carlson, KISS Network                    <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

James Carlson wrote:
> "Dolphin" <yc282004@yahoo.com.sg> writes:
> > I got the following when I run snoop and direct to a file (ie snoop >
> > /tmp/mylog):
> >
> > <dns> -> <my_server_name> DNS R  Error: 3(Name Error)
>
> That doesn't sound good.
>
> > Am I right to say that there is problem getting respond from dns?
>
> Yes, it sounds like it.  At a guess, you're missing IN PTR records for
> in-addr.arpa (reverse name resolution).
>

Is there a way to show that the server submitted a request but failed
to get reply from DNS? The reason why I need this is becuase the
servers (more than one) next to this don't have this problem.

> > PS: This is my first time using snoop
>
> You might find ethereal easier to use, but I don't want to force
> another tool on you while you're in the middle of troubleshooting ...

Is it easy to use?

>
> --
> James Carlson, KISS Network                    <james.d.carlson@sun.com>
> Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

On 31/5/06 6:32, in article
1149053522.143011.266570@f6g2000cwb.googlegroups.com, "Dolphin"
<yc282004@yahoo.com.sg> wrote:

> 
> James Carlson wrote:
>> "Dolphin" <yc282004@yahoo.com.sg> writes:
>>> I got the following when I run snoop and direct to a file (ie snoop >
>>> /tmp/mylog):
>>> 
>>> <dns> -> <my_server_name> DNS R  Error: 3(Name Error)
>> 
>> That doesn't sound good.
>> 
>>> Am I right to say that there is problem getting respond from dns?
>> 
>> Yes, it sounds like it.  At a guess, you're missing IN PTR records for
>> in-addr.arpa (reverse name resolution).
>> 
> 
> Is there a way to show that the server submitted a request but failed
> to get reply from DNS? The reason why I need this is becuase the
> servers (more than one) next to this don't have this problem.

Only (easily) by watching the network traffic from your machine using
something like snoop. For example in one window, type "dig www.eg.com" and
then run snoop in a different window before pressing return in the first.
You'll get something like:

# snoop -r udp and port 53
Using device /dev/e1000g0 (promiscuous mode)
172.16.0.138 -> 172.16.0.2   DNS C www.eg.com. Internet Addr ?
  172.16.0.2 -> 172.16.0.138 DNS R www.eg.com. Internet Addr 62.3.217.251

The output should be pretty self-explanatory ;-)

Note the "-r" to stop snoop from trying to resolve any IP addresses during
output, which would confuse any attempts to diagnose name resolution
problems...

>> PS: This is my first time using snoop
>> 
>> You might find ethereal easier to use, but I don't want to force
>> another tool on you while you're in the middle of troubleshooting ...
> 
> Is it easy to use?

Yes, though it uses X and needs root, and is perhaps a bit of a
sledgehammer. It /is/ a great tool to know how to use, but like James said
it might be a distraction at this point for you.

Cheers,

Chris

Chris Ridd wrote:
> On 31/5/06 6:32, in article
> 1149053522.143011.266570@f6g2000cwb.googlegroups.com, "Dolphin"
> <yc282004@yahoo.com.sg> wrote:
>
> >
> > James Carlson wrote:
> >> "Dolphin" <yc282004@yahoo.com.sg> writes:
> >>> I got the following when I run snoop and direct to a file (ie snoop >
> >>> /tmp/mylog):
> >>>
> >>> <dns> -> <my_server_name> DNS R  Error: 3(Name Error)
> >>
> >> That doesn't sound good.
> >>
> >>> Am I right to say that there is problem getting respond from dns?
> >>
> >> Yes, it sounds like it.  At a guess, you're missing IN PTR records for
> >> in-addr.arpa (reverse name resolution).
> >>
> >
> > Is there a way to show that the server submitted a request but failed
> > to get reply from DNS? The reason why I need this is becuase the
> > servers (more than one) next to this don't have this problem.
>
> Only (easily) by watching the network traffic from your machine using
> something like snoop. For example in one window, type "dig www.eg.com" and
> then run snoop in a different window before pressing return in the first.
> You'll get something like:
>
> # snoop -r udp and port 53
> Using device /dev/e1000g0 (promiscuous mode)
> 172.16.0.138 -> 172.16.0.2   DNS C www.eg.com. Internet Addr ?
>   172.16.0.2 -> 172.16.0.138 DNS R www.eg.com. Internet Addr 62.3.217.251
>
> The output should be pretty self-explanatory ;-)
>
> Note the "-r" to stop snoop from trying to resolve any IP addresses during
> output, which would confuse any attempts to diagnose name resolution
> problems...
>

When I ping an unknown site (eg: www.123.com). In the other session, I
did the following:

$snoop host <dns>
Using device /dev/ge (promiscuous mode)
<server> -> <dns> DNS C www.123.com. Internet Addr ?
<dns> -> <server> DNS R www.123.com. Internet CNAME
portal-web.entelchile.net.
<server> -> <dns> DNS C 255.255.255.255.in-addr.arpa. Internet PTR ?
<dns> -> <server> DNS R  Error: 3(Name Error)

The happens to other servers as well, hence, should the Error genuine?

Since the problem gone after server reboot, there must be scripts to
restart the network interface. Where are the scripts doing this? I was
thinking just to run (stop / start) these scripts when the problem
recurr (it happened again yesterday) rather rebooting.


> >> PS: This is my first time using snoop
> >>
> >> You might find ethereal easier to use, but I don't want to force
> >> another tool on you while you're in the middle of troubleshooting ...
> >
> > Is it easy to use?
>
> Yes, though it uses X and needs root, and is perhaps a bit of a
> sledgehammer. It /is/ a great tool to know how to use, but like James said
> it might be a distraction at this point for you.
> 
> Cheers,
> 
> Chris

"Dolphin" <yc282004@yahoo.com.sg> writes:
> <server> -> <dns> DNS C 255.255.255.255.in-addr.arpa. Internet PTR ?
> <dns> -> <server> DNS R  Error: 3(Name Error)

Yikes.  That doesn't look happy to me.

> The happens to other servers as well, hence, should the Error genuine?
> 
> Since the problem gone after server reboot, there must be scripts to
> restart the network interface. Where are the scripts doing this? I was
> thinking just to run (stop / start) these scripts when the problem
> recurr (it happened again yesterday) rather rebooting.

It's really unclear to me where the problem is coming from.  I _doubt_
that it really has anything to do with the network interfaces, but
ifconfig(1M) can be used to shut them down and restart them.

This sounds like a name services or application problem of some sort.

-- 
James Carlson, KISS Network                    <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677