Connectivity issues

[TWBSupport]

Hi all -
Just this week, I've started having some very odd issues come up. I have a workstation at another location that, all of a sudden in the middle of the day, lost connectivity with our HP9000 server. The workstation could ping & traceroute to any other server, including other HPUX servers, on our network BUT this specific one. The server could ping the workstation but will not resolve a traceroute. The server will resolve a traceroute to any other workstation, but this one.
All of a sudden, later in the afternoon, after pulling my hair out trying to see what is going on, it starts working again.
Today I have a different workstation that is having the same exact problem. I have tried everything that I did before & nothing works. Has anyone ever seen anything like this before? It's HPUX 10.20. Thanks in advance.

[Ian Dennison_1]

Have you got an NT Administrator stealing your IP Address (A popular pastime of theirs)? Check with your network bods and co-workers if any new servers have been appearing recently!

Share and Enjoy! Ian

[TWBSupport]

nah, nothing like that is happening. Thanks anyways, though.

[Steven E. Protter]

If the HP server is on a different subnet these things can happen.

lanadmin -x #

replace # with the number of the lan card in question, if its lan0, then

lanadmin -x 0

If you get unexpected results from this command, there is a networking issue on the HP-UX box.

This can be an intermittant problem, caused by cable, bad NIC card or lots of things.

HP NIC's like hard coded explicit configurations. Any router the HP box is on should be set manual by the switch admin.

If its only one user:

Try

tracert ip_of_hp_box



There could be a router out there hanging things up.

Sure sounds like an IP address sharing issue.

Try running netstat -rn and netstat -an on the HP box when it happens. If you spot that IP address from the client, there may be a DHCP issue on a Microsoft DHCP server.

SEP

[TWBSupport]

Thanks for the troubleshooting methods. It's talking again to the server. I have not done a thing, except clear the router cache, but that was 3 hours ago. It really does sound like a DHCP issue, but everything is checking A-OK on that end. I'll do the troubleshooting methods you gave me next time right away & see what I find. Thanks for your help.

[Tim D Fulford]

If you are getting duplicate IP addresses then check out

netfmt -t 10 -f /var/adm/nettl.LOG00

I usually find a line similar to "mac xxxx has duplicate IP address"

Regards

Tim

[Caesar_3]

Hello!

Check your phisical connection with
linkloop -i
see if the line is ok.
Try to restart the dhcp, also check
if you have same ip or mac in the net.

Caesar

[Michael Steele_2]

Yep. You need to be tracking with 'arp -a', 'netstat -rn', 'linkloop', 'netfmt' and 'tcpdump'.

tcpdump ip (* probably what you really need since it will determine sending node *)

tcpdump:
http://hpux.cs.utah.edu/hppd/hpux/Networking/Admin/tcpdump-3.7.1/

arp -a (* provides mac to ip table *)

linkloop MAC (* verifies connectivity at level two of network *)

netfmt -LN -f /var/adm/nettl.LOG* > /tmp/file

vi /tmp/file
search for error, disaster, etc.

(* cross reference any discoveries on ITRC *)

netstat -rn (* route table - see if they change *)

traceroute ip (* isolate the path of transfer *)

[Ron Kinner]

If the workstation can ping to other servers then obviously the card is good.

netstat -rn
and
netstat -r

on the workstation and see where it would send a packet to the server. Also

nslookup servername

and verify that it gets the right IP address.

arp -a

and verify that the mac address of the nexthop router is correct.

Can you ping the router? If not use linkloop to chack the connection to the MAC address.

Where does traceroute (not tracert which is a windows command) stop? Does it get to the router or start off with *'s? If it gets all the way to the last stop before the server and then *'s on you, then the server has forgotten how to get back to you and the problem's on the server's end. Repeat the same commands as above on the server end.

If it is working now run traceroutes to your different networks and save them so you will know what to expect and will be able to tell if one of the routers changes its routing table.

Ron

[W.C. Epperson]

You can also get intermittent connectivity with busted PMTU. If a NF return packet for a DF PMTU probe gets dropped by something, like a firewall/packet filter, the HP can decide that the route's busted and send stuff to the default router. Generally that router will issue a redirect, but if it's a firewall it may silently drop. Ask your router/firewall admins what they see in their logs.