Packet Dropped

[Hai Nguyen_1]

Hi folks,

I have two NT 4.0 boxes running OmniBack II clients and an HP 11.00 box running OmniBack II server. They are on the same LAN and communicate through a switch. Their network interface cards operate at 100 Mbps full duplex. The switch' ports handle 100Mbps/full duplex as well. When there is no backup going on, there will be NO packet loss among the three hosts mentioned above. But as soon as a backup starts, the icmp packet drops among them will vary between 10% and 15%. And this packet loss rate is consistent. I suspect that the problem lies in the switch.
What can I do to exactly identify the root cause of the packet drop? Thanks.

Hai

[Darrell Allen]

First I'd verify each NIC and switch port are really in 100FDX. For some reason auto-negiotiation often fails to set both sides to full duplex. Problems generally aren't apparant until a network backup or large file transfer happens.

Darrell

[Hai Nguyen_1]

Thanks Darrell.

I did manually set all the NICs at 100Mb full duplex. The autonegotiation is turned off.
I dif verify that they are set as expected.

Hai

[rick jones]

you need to examine the statistics on the switch. i would guess that you will find that when both the NT systems are being backed-up at the same time, they are at times trying to send > 100 Mbps to the backup server. as the backup server has only a 100 Mbps connection to the switch, something has to give... hence the switch may be forced to drop packets.

i've no idea how one checks link-level stats under NT. to check the link-level stats on a UX box you would use lanadmin.

i have no data to suggest that switches do this "backpressure" idea, but if you were instead running half-duplex, it is possible that when the two NT systems tried to send into the same UX box that thee switch could assert carrier on those ports to basically "flow-control" the NT boxes.

you would get that same behaviour if you replaced the switch between the three systems with a hub (plain basic half-duplex no-switching hub).

switches work great with lots of pairwise connections between lots of machines. however, there can be issues with many systems trying to send to just the one.

the other option I suppose is to get a second 100BT interface into the backup server and trunk them with APA, or split the two NT systems into separate subnets (separate IP subnets can run on the same switch). you could in theory also simply assign each NIC in the UX an IP in the same subnet, but that will only work well ifyou are on HP-UX 11 and set ip_strong_es_model to a value of 1.

or you could upgrade the backup server with a gigabit interface :)

[Christopher Caldwell]

I recall reading that because of bus architecure most Wintel boxen can't drive their NIC cards anywhere near theoretical performance numbers (i.e. 100Mbps).

I wonder if OmniBack essentially saturates the connection from Wintel's perspective. I don't think Microsoft has the most well behaved TCP/IP stack ...

[Anthony deRito]

Why do you refer specifically to icmp packets and how are you measuring packet loss?

[Hai Nguyen_1]

Anthony,

I used the following command to measure the
packet loss percentage:
# ping REMOTEHOST -n 100

Ping uses icmp.

Hai

[Anthony deRito]

OK... was not sure which tool you were using... the ping stats are fairly accurate. It is possible you may have some chatty broadcasting going on with OmniBack. It is true that your switch ports are separate collision domains however the entire switch or VLAN (if you configured VLANs) are one large broadcast domain. You may be getting pounded by broadcasts which the switch will send out all ports (or those in the VLAN) which in turn will consume bandwidth. You can check to see what the broadcast stats look like on your switch.

Here are some sample stats on my Catalyst switch:

380607195 packets input, 3427489649 bytes, 0 no buffer
Received 5148325 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
292599337 packets output, 4100615826 bytes, 0 underruns
0 output errors, 1 interface resets
0 output buffer failures, 0 output buffers swapped out

Notice the broadcasts are high but relative to the input packets they are low. It may be helpful to find out from your OmniBack people if this is a typical issue.

Hope this helps.

Tony