diagnosing hpux 11i network queue trouble?

[Bob Brown_1]

I have an RP8400 split into 4 vpars. One of the vpar's seems to be having some network trouble.
perfview shows "gbl_network_subsystem_queue" at around .3 ALL of the time (I don't see this on any of the other vpars).

I also have fbackup running on this vpar going to a different vpar. It runs LONG....much longer than a different vpar that backs up to the same tape-drive-owning vpar.

This makes me suspect some kind of network issue.

Where should I look? What would contribute to the steady network queue that I see?

thanks.

-Bob

[Patrick Wallek]

I would first check and make sure your speed / duplex settings on the NIC match the switch.

If one end is set at 100HD and the other at 100FD, then you will see some strange issues.

[Bob Brown_1]

How do I see what the speed & duplex settings on the card are actually set to?
(not what I told the system to set them to but what they are actually running at now)?

-Bob

[Patrick Wallek]

Use lanscan to get the NMID/PPID of the card.

Then use 'lanadmin -x ?' where ? is the NMID/PPID of the card.

See the man pages of each for more info.

[Mel Burslan]

Bob,

Unles you are the network administrator at the same time, it would be beneficial to talk to those guys as well. I have seen my fair share of wrongly set network ports because somebody decided to hawk the cisco switch from ebay instead of buying a new one and slapped it in with the previous owner's settings.

So, as much as what you will see at the output of 'lanadmin -x NMID#' output, it is equally important what it was set to on the switch. Mismatch of the two is the prescription from a sluggish network connection.

my 2 cents.

[V.Manoharan]

Hi BOB,
1. use lanadmin command to see the inbound outbount packet errors.
2. check the network related issues with below command ouput

#netfm -f /var/adm/nettl.LOG00
or
#netfm -f /var/adm/nettl.LOG000

regards
V.Manoharan

[rick jones]

How 100Base-T Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full-duplex if both sides can do
full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.

So, the following table shows what will happen given various settings
on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly :) Sorrow means that there _will_ be a duplex
mis-match.

When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of _LATE_ collisions
("normal" collisions don't count here). On the side running
full-duplex you will see things like FCS errors. Note that those
errors are not necessarily conclusive, they are simply indicators.

Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.


If you find that the lanadmin stats are clean, you will want to move-up to the netstat (presumably netstat -p tcp) statistics and/or the statistics on the switch(es) involved.

[Bob Brown_1]

Thanks for the ideas. Everything appeared to be set properly.

The problem resolved itself when I had to reboot the entire RP8400 complex (to have a cell board replaced). Upon coming back online, this vpar with the constant network queue which was apparently causing fbackups accross the network to run VERY long is all better now (network queue now almost non-existant).

-Bob