Network status

[Jesse Breaker]

Okay I am at a loss. I do not have access perfview or measureware or even glance. I want to be able to query the network card for the number of bytes that have passed through it (in/out) in a given time period

I thought of using OIDs and came accross:
OID: 1.3.6.1.2.1.2.2.1.16

Description: The total number of octets transmitted out of the
interface, including framing characters.

and
OID: 1.3.6.1.2.1.2.2.1.10

Description: The total number of octets received on the
interface, including framing characters.


Now first I query the server before I send say a 10 MB file, to get the pre stat numbers, next I FTP the file to the server and then check the stats again, thinking that the numbers should add up to around 10MB, but what I am finding is that the value for sending a 10 MB file is really 20 MB. I am under the assumption that the number that comes back is in bytes so I divide by 1024 for kilobytes and then divide again for megabytes, and I end up with something close to 20 MB.

Any ideas? Not sure if this is clear or not. Just let me know.

PS, I am just using an SNMPUTIL.EXE under windows to query the hpux snmp again

[Stanimir]

Hi!
In HPUX you can use "netstat -i"
and "lanadmin" to test inp/output-packages
at first sight.
Regards.

[Ajit Natarajan · Accepted solution]

I will first attempt to explain what should be seen when transferring a 10MB file. I will then give you my recommendations on what to do next.

I am assuming the following:
1. You are transferring between two systems that are communicating via the standard FTP protocol (RFC 959).
2. One of the systems is running HP-UX 11.x and you have access to this system.
3. You are running over an Ethernet connection using an MTU of 1500 octets.
4. There is no other traffic.

When FTP is transferring files, it uses the TCP protocol. Under normal circumstances, it will be able to send the data as 1500 octet packets.

1500 refers to the Ethernet payload. The Ethernet frame looks like this:

Ethernet header (14 octets)
Ethernet payload (max 1500 octets)
Ethernet CRC (4 octets)

The Ethernet payload consists of:

IP header (20 octets)
TCP header (20 octets)
Data (max. 1460 octets)

where an octet is an 8 bit byte

A 10MB file has 10,485,760 octets. Divide by 1460 gives 7183 packets. Each packet has an overhead of 58 octets. Thus the total sent is 10,485,760 + 58*7183 octets which is 10.4MB.

However, the above is the ideal case. Your overhead may be considerably more under any of the following conditions:

1. The link/network is congested. TCP will greatly reduce the amount of data it sends under these conditions.

2. The receiver is overwhelmed. This will also cause TCP to greatly limit what it sends per packet.

3. The link/network is unreliable. It is either dropping packets or corrupting them resulting in bad checksums. TCP will have to retransmit in these cases.

4. The card/link is bad causing CRC errors. This will require TCP to retransmit.

5. Intervening links have a lower MTU resulting in a lower path MTU. This will mean more packets. For example, if the path MTU is 900 octets instead of 1500, 10.7MB will be sent.

You can determine if any of these are causing problems.

1. netstat -p tcp will give you TCP statistics. A large number of packet discards due to checksum errors on the receiver shows that the link/network is facing packet corruption problems.

2. netstat -I lan where is the PPA of the interface used for FTP will give you the number of octets sent and received at the IP level.

3. lanadmin menu mode (lanadmin -> lan -> ppa -> display) will give you interface level statistics. For Gigabit interfaces lanadmin -x stats drv will give you even more information at the interface level. You should be able to find if the receiver is discarding packets due to CRC errors (look for FCS errors in menu mode statistics).

4. Check the MTU of the link (lanadmin -m ). Note that this is not the same as path MTU. However, path MTU cannot be greater than link MTU.

5. Note that in a switched network, intermediate nodes (bridges in the case of layer 2, routers in the case of layer 3) may be dropping/corrupting packets. You may need to get statistics on these devices to get a complete picture.

In my opinion, 20MB traffic for a 10MB file is too much overhead. There seems to be some other problem. Let us know the results of the above experiments. That should guide us to further explanations or experiments.

Thanks.

Ajit
HP Gigabit Ethernet

[Ajit Natarajan]

If you are using copper Ethernet interfaces (10/100/1000 Base-T), you may want to check the duplexity of your interface against that of the switch it is connected to. If both are autonegotiating, that's fine. Otherwise, both should be either half duplex or full duplex. Allowing one side to autonegotiate may result in that side going half duplex while the link partner is full duplex. This can cause a lot of performance degradation.

On the HP-UX side, if you are using an interface controlled by btlan, gelan, or igelan, you can use:

lanadmin -x

where is the PPA of the interface to determine the speed, duplexity, and autonegotiation. Ensure that the link partner is also configured the same.

If you've connected the systems back to back, you need a crossover cable for 10 Mb/s and 100 Mb/s operation. You can use a straight through or crossover cable for Gigabit operation.

One other question for you: did you observe that the FTP session was taking too long or it seemed to be going at the regular speed but the statistics didn't match?

Thanks.

Ajit
HP Gigabit Ethernet

[Ron Kinner]

Give Ajit a 10. Very nice explanation.

Just wanted to point out that if the mtu is reduced the efficiency drops considerably tho it would take an awfully small packet to result in a 100% overhead.

Also note that there may be other processes involved which add to the total packets out. Did you take a baseline measurement for the same time period without the ftp?

Does the time vary considerably between and FTP PUT and a GET of the same file? Usually a good sign of a DUPLEX mismatch.

I've never used snmputil.exe so don't know what features it has. I use getif.exe which gives you quite a bit of visibility to the different MIBs that are available. It will also draw a cute graph which is handy for the sort of stuff you are doing. Very easy to set up and use. Freeware. Runs on NT or 2K and maybe others.

http://www.omnimind.org/omninuke/modules.php?name=Downloads&d_op=getit&lid=10



For long term monitoring of the network traffic I use MRTG. This is a bit trickier to set up but once it's running you get a webpage with a graph of the daily, weekly, monthly and yearly usage plus it can monitor any OID and not just the in and out. Freeware. Runs on about anything.

http://people.ee.ethz.ch/~oetiker/webtools/mrtg/

Ron

[Jesse Breaker]

Man you guys are the best!!! I swear, very cool. I am going to do some of the suggestions and at the same time, try some of the freeware stuff you all suggested. Will let you know..

=)

Thanks again!

[Sridhar Bhaskarla]

Hi Jesse,

Have a look at ethereal, my favourite tool for looking at the network traffic. It is available here

http://hpux.cs.utah.edu/hppd/hpux/Gtk/Applications/ethereal-0.9.8/

It is a pain to get this application running. But once you get it up, it is pretty cool with a nice GUI.

You can take samples of bandwidth utilization using it. I use it often if my users complain about network slowdowns.

-Sri