Ping works once (sometimes) then fails

[Frank Fitch_1]

I'm stumped. I am having difficulty establishing connectivity between an HP9000 11i system (SysA) and a W2000 PC (SysB). Ping behavior is odd. Most ping attempts fail outright, but every once in awhile when pinging SysB from SysA, a packet will return successfully --- (actual cut/paste) 886 packets transmitted, 1 packets received, 99% packet loss

To set the stage:
SysA is a newly ignited HP9000 on the .26 subnet. The W2000, SysB has been around awhile and is on the .11 subnet. SysC has been around awhile and is another ignited HP9000 on the .26 subnet. Ditto for SysD, but it is on the .209 subnet. SysE and SysF are W2000 boxes on the .11 subnet. SysG is a W2000 box on the .26 subnet.

Ping and telnet Results (using both host name and IP addresses):
SysA to SysB, SysE or SysF --- fails nearly every time.
SysA to SysC or SysD -- pings/telnets successfully.
SysA to SysG -- pings successfully.
SysA to .26 router -- pings successfully.
SysA to .11 router -- pings successfully.
SysC or SysD to SysB -- pings successfully.
SysB to all systems, including SysA -- pings successfully. However, telnet is successful from SysB to SysC or SysD, but not to SysA.

The smoking gun seemingly points to the network setup on the new guy, SysA which was recently ignited. In an attempt to identify the misconfiguration on SysA, I NFS mounted SysA's /etc directory on to SysC and ran a "dircmp -s" of the /etc directory structures. After filtering out the extraneous stuff, I took a close look at the differences in network configuration related files. Nothing stood out as an obvious misconfiguration to me --- netconf, resolv.conf, hosts.

Any ideas on what I should look for? Thanks in advance..... Frank

[George_Dodds]

What do you get from a traceroute from sys A to the pc's on the .11 network and vice versa?

Then try the same from Sys C to the pc's

Ta


George

[Ron Kinner]

Since you can ping and telnet to stuff on your own LAN we can skip the layer two problems and look at network issues.

The fact that B can ping A but not the other way around is a strong indication of a filter on one of the routers blocking traffic. On A run
traceroute B
and on B run
traceroute A

Does the first traceroute stop (turn to stars) before arriving at the destination? If B goes through to A then try:

traceroute -p 23 A

and see if it gets blocked. I assume you have checked that
netstat -an |grep 23
shows that A is listening on the telnet port or that C or G can telnet to A so we don't have to worry about that.

IF there are no filters and the routes appear correct on the routers then check the routing tables on the .11 boxes to see if they are correct for the .26.

Ron

[Michael Steele_2]

Chances are your router is sending out "Do you Know SysA" messages and performance on your network is hell.

Since this is a new ignite why don't you rerun 'set_parms initial' and double check the network configuration? You'll need hastname, host ip, gateway ip, netmask, DNS and NIS ip's.

If this fails check your NIC status with lanscan, ifconfig and lanadmin and ioscan. Has to be CLAIMED in ioscan.

ioscan -fnkC lan

Copy down the MAC address from lanscan and check you cable. Look at the LED's on the NIC.

Layer two connectivity test uses 'arp -a and linkloop MAC'. MAC in this case is to your switch.

Match the switches speed and duplex with your NIC's.

lanadmin -x NMID/PPA (* current config *)
lanadmin -X 100FD 4 (* for example *)

Now ping.

[Frank Fitch_1]

Hi Guys, thanks for the response....

From SysA to SysB fails:
# SysA traceroute -i lan0 SysB
traceroute to SysB.goodyear.com (xxx.yyy.11.90), 30 hops max, 40 byte packets
1 cis-26.akd.goodyear.com (xxx.yyy.26.1) 1.882 ms 0.907 ms 0.856 ms
2 SysB.goodyear.com (xxx.yyy.11.90) 1.505 ms * *

From SysC to SysB is sucessful with sub millisec response.
SysC # traceroute -i lan0 SysB
traceroute to SysB.goodyear.com (xxx.yyy.11.90), 30 hops max, 40 byte packets
1 cis1.akd.goodyear.com (xxx.yyy.26.1) 1.074 ms 0.745 ms 0.687 ms
2 SysB.goodyear.com (xxx.yyy.11.90) 0.840 ms 0.726 ms 0.697 ms


From SysB to SysC is successful with sub millisec response. Does this imply that routing tables are correct between .11 and .26 or am I oversimplifying?

From SysB to SysA traceroute fails.

Both SysC and SysG can telnet to SysA sucessfully.
lanscan, ioscan, ifconfig output all look fine.

I tried resetting network configuration using set_parms. Everything looked okay, but i redid the settings anyway and rebooted --- same traceroute behavior.

Also, SysA has two lan adapters. I have tried both with the same results.

[Eugeny Brychkov]

All servers have LAN cards. All LAN cards have unique MAC addresses. Although with ignite it's possible to arrange more than one LAN card with the same MAC address: built-in MAC address can be overriden with one present in /etc/rc.config.d files
hpetherconf
hpbase100conf
(depends on LAN card type installed) in value HP_ETHER_STATION_ADDRESS. Please check with 'lanscan' all your suspicious hosts to see if some of their LAN cards are having idential MAC addresses
Eugeny

[Steven E. Protter]

Compare the /etc/rc.config.d/netconf on a working to a non-working server.

Look for extra dots or inconsistent network masks.

traceroute is a good idea.

Also, run dmesg and check for straight hardware problems.

lanscan

lanadmin -x 0

replace 0 with the actual numbers for the lan cards.

lan1 is 1
lan2 is 2

If the duplex settings are not what they should be, there is an avenue of investigation.

Make sure the switch settings for the HP boxes are all set explicitly, not auto-negotiate. Many HP NIC's have troulbe in auto negotiate settings. This remark excludes 1000 BaseT cards, they MUST be auto negotiate.

SEP

[John Collier]

Frank,

I???m of a mind to say that this will almost have to be a routing issue of some kind. I would suggest that you have the network gurus check the routing tables for the gateway for SysA to the rest of the world and make sure that they took your new system into consideration in the configs. Nine chances out of ten they are using static routing tables for the network and I have been witness to similar issues that were finally resolved by router config changes. The biggest problem can be (and usually is) getting the network gurus to admit that it may be their problem. Most of the ones I have dealt with in the past think that their stuff is always ???bullet proof??? ;-)

With so many boxes being able to make connections one way but not the other, I just don???t see any other logical explanation for this type of behavior.

[Ron Kinner]

Still looks like a network issue. I'm still leaning towards filters in the router. Have you checked with the router admin? A paranoid admin could have built a filter which only passed traffic to hosts which were present on the network at the time the filters were written.

Ron

[Frank Fitch_1]

Given the intermitency of the ping response, I had earlier thought that perhaps someone had pirated my IP address for SysA, so I shutdown SysA and tried to ping SysA's IP address from SysC --- ping did not respond. I drew the conclusion of no pirate.

In desperation, just now, I changed SysA's IP address to a different "unused" IP address, on the .26 subnet. I rebooted and guess what --- I can now talk to SysB from SysA just fine.

The old SysA IP address remains unpingable from (new IP)SysA, however SysB can successfully ping the old SysA IP address --- huh!!! I'm now curious as to why SysA can't ping the old IP address while SysB can, blocked at the router ?!?! Bottomline, I do in fact, have a pirate. In the 5+ years that I have used that old IP address, I never had a problem.

Well thanks everyone. Time to go keelhaul someone. Frank

[Ron Kinner]

If B on a different network can still ping oldA but newA can not ping oldA then it sounds like you have a whole pirate network hanging off one of the routers. I'd ask the .11 router where it thinks oldA is and see how it wants to get there.

The other possibility is that B thinks it has oldA assigned to an interface so it doesn't even send it out on the wire but then I would think that the traceroute would have worked. netstat -rn on B and see where it thinks oldA is.


Ron