Problem with new 100BT card

[Dan Rosen]

Hi - I hope experts here can assist. Points up for grabs...

Scenario: upgraded a D/390 machine running HPUX 10.20 from the built-in 10baseT to a J3515A card. Followed one of the other threads in the forums for the proper steps - verified both card and switch are 100FD, changed /etc/r.config.d/netconf and changed what the Interface name[0] from lan0 to lan1. Everything else stayed the same. lan0 is disconnected. lan1 assumes lan0's IP address.

Well, everything is running, kinda. There are three indications that something is not right, but I can't put my finger on it. When you start a telnet session to the server, it takes 15 seconds before the login prompt is returned. Then you type in your password, and there is another 15 second delay before the rest of the login process continues. Once you are in the system, everything is snappy and fast. I confirmed the new speed by transfering a sizable file, and noted the sustained transfer speed.

The only other place I have noticed a slowdown is when I attempt to run network tools (ping, traceroute, etc.) I see the same ~15 second delay, then the program runs quickly. Here is my traceroute output:

# /etc/rc.config.d: traceroute www.yahoo.com
[ * 15 second delay occurs here * ]
traceroute to www.yahoo.akadns.net (68.142.197.76), 30 hops max, 20 byte packets
1 tsirtr (192.168.109.246) 2 ms 2 ms 3 ms
2 host1.techservintl.com (63.168.92.1) 5 ms
sl-gw32-pen-5-1-0-TS3.sprintlink.net (144.228.118.133) 44 ms 19 ms
3 sl-bb22-pen-0-0.sprintlink.net (144.232.16.243) 6 ms 7 ms 6 ms
4 sl-bb21-fw-15-0.sprintlink.net (144.232.9.31) 47 ms 46 ms 47 ms
5 sl-bb20-fw-14-0.sprintlink.net (144.232.11.217) 61 ms 46 ms 46 ms
6 sl-st21-dal-1-0.sprintlink.net (144.232.20.17) 47 ms 47 ms 57 ms
7 sl-yahoo3-23-0.sprintlink.net (144.228.250.78) 48 ms 48 ms 48 ms
8 v3.bas1.mud.yahoo.com (68.142.193.5) 48 ms
UNKNOWN-68-142-193-17.yahoo.com (68.142.193.17) 113 ms
UNKNOWN-68-142-193-19.yahoo.com (68.142.193.19) 48 ms
9 p13.www.mud.yahoo.com (68.142.197.76) 48 ms 87 ms 48 ms

From all appearances, I think the _card_ is working correctly, but something in the system is misconfigured.

Here is my lanscan output:

Hardware Station Crd Hardware Net-Interface NM MAC HP DLPI Mjr
Path Address In# State NameUnit State ID Type Support Num
8/16/6 0x080009AEA891 0 UP lan0 DOWN 4 ETHER Yes 52
10/12/1/0 0x0060B0A682FA 1 UP lan1 UP 5 ETHER Yes 119


Any assistance would be greatly appreciated.

[Steven E. Protter]

You can't just renumber the instances in netconf. You need to go through a procedure for that.

Here is the link you need. Take and Ignite backup before you start.

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&admit=-682735245+1112705941121+28353475&docId=200000067424466

there can be problems on older machines because there can be switches on the card that preven renumbering. I do not believe that is the case with your situation.

SEP

[Pete Randall]

Dan,

It sounds like a delay in name resolution. Try running a nslookup command, a ping command, etc. and see what kind of timings you get.


Pete

[Dan Rosen]

I think I am unclear. I left the designator 10/12/1/0 alone.

In the netconf file, I changed the INTERFACE_NAME[0] from lan0 to lan1. Since I am not using lan0, the only interface is lan1.

So, are you suggesting that I remove the all of the references to [0] in netconf, and change them all to [1]?

[Pete Randall]

Dan,

No - the [0], [1], etc. simply reference an array and it has to start with [0].


Pete

[Dan Rosen]

Pete - nslookup was instantanous. Ping has a delay before the first packet is sent out:

# /tsi/home/rosendm: ping www.yahoo.com
[15 second delay]
PING www.yahoo.akadns.net: 64 byte packets
64 bytes from 68.142.197.66: icmp_seq=0. time=53. ms
64 bytes from 68.142.197.66: icmp_seq=1. time=57. ms
64 bytes from 68.142.197.66: icmp_seq=2. time=160. ms
64 bytes from 68.142.197.66: icmp_seq=3. time=51. ms

When we first set up this system, we notice a LONG time to login, which was due to the hosts file not configured properly. But, that was not changed when I installed the new card.

What I am really confused on, I did the same upgrade on our reporting server (except it runs 11.0), and do not have this problem. I have compared the netconf files and they are virtually the same.

[Pete Randall]

Dan,

Take a look at the /etc/resolv.conf files on the two machines, and at the /etc/nsswitch.conf files, as well.


Pete

[Dan Rosen]

The nsswitch.conf files are the same. In the reolv.conf, the server that is not working has a line : domain techservintl.com.

I had see this in SAM before, but could not remove it.

This machine does not do DNS, and the host file has every local IP address (yeah, that was fun.) We do not have a local DNS server, it is provided by the nameservers listed here.

Can I remove the domain line? After that, I just run an inetd -c to source the file, correct?

[Pete Randall]

The server that is working does not have a domain identified in /etc/resolv.conf? I would have thought that would be the other way around. Try removing the domain line on the non-working server.


Pete

[Dan Rosen]

Do I have to do a /sbin/init.d/net stop and start, or should the inetd -c source the file.

Also, I have seen this holy war before: does /sbin/init.d/net stop kill active connections? I only ask because I am in the middle of the day on a production server ;-)

If active sessions stay up, then I can try it now, otherwise, it has to wait.

[Patrick Wallek]

When editing the resolv.conf file, I have never done anything with inetd (no inetd -c or stop/start the network).

You should just be able to edit it and try a test again.

[Pete Randall]

Dan,

I'm just not sure. I wouldn't think you'd need to restart inetd at all. We're just trying to affect how host names are resolved. I'm searching for further info.


Pete

[Dan Rosen]

OK, I wasn't sure when the resolv.conf file is read - sounds like it is read constantly.

Did a new test - no change.

But I do sincerely appreciate all of the help!

[Pete Randall]

Dan,

I would have expected to find a difference in the two resolv.conf files. My theory is that the machine that is experiencing the delays is tring to resolv with a particular DNS server that is not working and your delay comes from waiting for that server to time out. Once it does time out and moves on to the next, things get resolved and you're OK. The fact that the working machine has no domain set puzzles me.

The only other thing I can think of is that the nsswitch search order is different on the two machines but you indicate that's not the case.


Pete

[Patrick Wallek]

What is the search order for hosts in the nsswitch.conf file? Is files first or is DNS?

If dns is first, modify it and put files first just to see what happens.

hosts: files dns

[Dan Rosen]

You both got to the same solution for our previous problem we had a few years ago - no DNS server, and a very small host file.

We updated the host file with a line for every local IP address, and the nsswitch.conf file does reference files first:

hosts: files[NOTFOUND=continue UNAVAIL=continue] dns [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]

But, I will return to the original change - switching which card we use to connect to on the server. This problem did not exist on the 10baseT internal card.

I agree by all indications it seems like a name resolution issue. It seems like login, the process to verify passwords, ping, and traceroute are hunting for the right protocol/physical connection/path, etc to do their jobs. I just can't figure out what is causing that.

So far, I have placated the users by the benefits - slightly longer signon time, but better performance once you are connected. But, like all users, that will only last for so long.

[Pete Randall]

Dan,

Can you post the contents of the resolv.conf and nsswitch.conf files?


Pete

[Dan Rosen]

Here is resolv.conf. We do not have a complex setup, by any stretch of the imagination.

Also, remember this is 10.20.

[Dan Rosen]

nsswitch.conf file...

[Pete Randall]

Dan,

Try pinging your primary name server: 204.117.214.10. I would think that it would fail.


Pete

[Dan Rosen]

Nope - this is one of Sprint's business DNS servers. I wouldn't think that it would fail:

output of ping:

# /etc: ping 204.117.214.10
[ insert my friend, the 15 second delay]
PING 204.117.214.10: 64 byte packets
64 bytes from 204.117.214.10: icmp_seq=0. time=10. ms
64 bytes from 204.117.214.10: icmp_seq=1. time=7. ms
64 bytes from 204.117.214.10: icmp_seq=2. time=9. ms
64 bytes from 204.117.214.10: icmp_seq=3. time=16. ms
64 bytes from 204.117.214.10: icmp_seq=4. time=16. ms
64 bytes from 204.117.214.10: icmp_seq=5. time=9. ms

[Dan Rosen]

OK, so I checked netstat -rn (reading other threads). I am smart enough to see something differnt, but not smart enough to see if that would cause the problem...

# netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface Pmtu PmtuTime
12.151.134.163 192.168.109.247 UGHD 0 13 lan1 1500
32.82.107.27 192.168.109.248 UGHD 0 0 lan1 1500
32.83.153.187 192.168.109.248 UGHD 1 441 lan1 1500
63.161.60.2 192.168.109.247 UGHD 0 714 lan1 1500
63.161.60.34 192.168.109.247 UGHD 0 121 lan1 1500
68.142.197.66 192.168.109.247 UGHD 0 0 lan1 1500
68.142.197.76 192.168.109.247 UGHD 0 23 lan1 1500
127.0.0.1 127.0.0.1 UH 0 45182 lo0 4608
128.118.25.3 192.168.109.247 UGHD 0 19 lan1 1500
128.118.25.5 192.168.109.247 UGHD 0 19 lan1 1500
138.39.23.13 192.168.109.247 UGHD 0 19 lan1 1500
192.168.109.4 127.0.0.1 UH 0 20289 lo0 4608
192.168.200.2 192.168.109.247 UGHD 0 795 lan1 1500
193.132.242.56 192.168.109.247 UGHD 0 895 lan1 1500
198.41.0.6 192.168.109.247 UGHD 0 7 lan1 1500
199.2.252.10 192.168.109.247 UGHD 0 8 lan1 1500
204.97.212.10 192.168.109.247 UGHD 0 1 lan1 1500
204.117.214.10 192.168.109.247 UGHD 0 559 lan1 1500
204.146.55.140 192.168.109.247 UGHD 0 109 lan1 1500
206.16.192.227 192.168.109.247 UGHD 0 137 lan1 1500
206.183.140.66 192.168.109.247 UGHD 0 383 lan1 1500
213.206.137.198 192.168.109.247 UGHD 0 19 lan1 1500
216.148.222.35 192.168.109.247 UGHD 0 77 lan1 1500
216.168.224.70 192.168.109.247 UGHD 0 39 lan1 1500
default 192.168.109.246 UG 38 294388 lan1 1500
192.168.109 192.168.109.4 U 103 1290973 lan1 1500

lan1 is correct. That the new network card. But, see the references for lo0? Could those still be trying to reach the lan0 designator? Can I see what lo0 is attached to?

[Pete Randall]

What about routing? What does netstat -rn look like? Can you get to your default route OK?

It sounds like it can't find it's way to your DNS server. Curious.


Pete

[Pete Randall]

The lo0 is your loopback address - that's normal.

Pete

[Pete Randall]

Your default route is set to 192.168.109.246, yet most of your traffic seems to be going through 192.168.109.247 or 192.168.109.248. How does that compare to the working machine?


Pete