traceroute

[Van Caeyzeele Wout]

We have 2 HP-UX machines (HP-UX 11.11)
The 2 machines are in a different subnet mask.
When sending large files from machine A to machine B, speed is OK.
But when sending the same files from B to A, the speed is very slow.
Also when doing a traceroute from B to A I get the following :

traceroute to A (10.25.39.2), 30 hops max, 40 byte packets
1 * * *
2 10.25.100.113 0.506 ms 0.285 ms 0.275 ms
3 10.25.100.66 6.265 ms 12.448 ms 7.270 ms
4 10.25.39.2 0.351 ms 0.271 ms 0.268 ms

netstat -rn

Routing tables
Destination Gateway Flags Refs Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 lo0 4136
10.25.1.180 10.25.1.180 UH 0 lan0 4136
10.25.1.0 10.25.1.180 U 2 lan0 1500
127.0.0.0 127.0.0.1 U 0 lo0 0
default 10.25.1.1 UG 0 lan0 0

What can we do about this ?

[U.SivaKumar_2]

Hi,

What is the ping response between the hosts ?
What is the speed setting of the switches , fixed or auto-negotiate ?

Does this problem there in both upload and download tests ?

regards,
U.SivaKumar

[Van Caeyzeele Wout]

The Ping response is good. No problem when doing a ping

[Van Caeyzeele Wout]

The speed setting is auto-negotiate.
The speed problem only occurs from machine B to A.
It does not matter if we upload from A or download from B

[U.SivaKumar_2]

Hi,

you are sending file thru which application ?

FTP ?


regards,
U.SivaKumar

[Van Caeyzeele Wout]

The file transfer is done by scp or ftp. Both are very slow.

[Christian Gebhardt]

Hi
Is the way from A to B the same as from B to A ?

Chris

[U.SivaKumar_2]

Hi,

Give this command in the server B and try the same files ftp again and come back with results.

/usr/bin/ndd -set /dev/ip ip_pmtu_strategy 1


regards,
U.SivaKumar

[Van Caeyzeele Wout]

A to B and B to A is not the same, they use differen routes.
traceroute to B (10.25.1.180), 30 hops max, 40 byte packets
1 10.25.38.251 (10.25.38.251) 11.779 ms 8.681 ms 7.807 ms
2 10.25.100.65 (10.25.100.65) 0.260 ms 0.247 ms 0.247 ms
3 10.25.100.114 (10.25.100.114) 0.514 ms 0.479 ms 0.484 ms
4 B (10.25.1.180) 0.335 ms 0.262 ms 0.268 ms

[U.SivaKumar_2]

That means host A has different default gateway and host B has diffrent default gateway But both networks are reachable.

Is the servers A and B are across WAN network ?

[Van Caeyzeele Wout]

/usr/bin/ndd -get /dev/ip ip_pmtu_strategy is already set to 1

[U.SivaKumar_2]

Then try setting it to 0

[Van Caeyzeele Wout]

Servers A and B are in a LAN not a WAN, but they are in different segments.

[U.SivaKumar_2]

Hi,

do this in both host A and host B

/usr/bin/ndd -set /dev/ip ip_pmtu_strategy 0

and come back with results

regards,
U.SivaKumar

[Ron Kinner]

Generally when you have a difference in speed on an FTP transfer in different directions the problem is almost always caused by a difference in duplex settings somewhere along the way.

Autonegotiate can not be trusted to work. Also there is an odd quirk to the standard that says if one side is manually set to Full Duplex that Autonegotiate should set itself to Half even tho it is fully aware that the other side is set to Full. Go figure.

Anyway I assume we are talking HPUX so your first move is to do

lanadmin
lan
display

and check what it says for duplex in the description and also look for large numbers of errors and discarded input packets which usually indicate the other end is set to Half Duplex. Collisions (seen on the second page) are normal on a half duplex circuit but if the percentage of collisions to packets sent is too high or you see a lot of multiple collisions and deferred transmisions then you probably have the other end set to Full Duplex.

Safest is to manually set each to the Full if both support it otherwise lock them both to Half.

Note that this error can occur anywhere along the path so if you don't find anything wrong at the ends then check the links in the middle.

(Make sure if you have multiple NICs that you are looking at the correct one. ppa x+1 or nmid x+1 will usually show you the next one if you are currently looking at ppa/nmid x).

The other common problem is a WAN link clogged in one direction. This results in a lot of discarded packets. You can see this easily with a fat ping. Do

ping hostname 1400

and see if you see any getting lost.

(1400 is the number of bytes in the packet and should be a little smaller than your MTU on the route. FTP will normally be using a full packet during a data exchange where you might notice a time difference so it is best to use a ping of the same approximate size. You can't use 1500 with an MTU of 1500 because you have to allow room for the Ethernet header which is tacked on afterwards.)

Ron

PS the *** in your traceroute probably just indicates that the device is not allowed to generate ICMP TTL expired messages for security reasons.

[rick jones]

PMTU strategy would/should only affect a transfer once (or rather once every PTMU IRE update interval, and would be accompanied by specific PMTU < link-locak MTU (Maximum Transmission Unit) host routes in the routing tables as seen with netstat -rn.

I'm not sure if I would call it a quirk the way autoneg works or not. basically, hardcoding a duplex setting means the interface is not supposed to autonegotiate. If one side of the wire is not supposed to autoneg, autoneg is supposed to "fail." When autoneg "fails" it is supposed to imply that the non-negotiating side is something that does not understnadn autoneg, and if something does not understand autoneg, it is probably old enough that it does not do full-duplex, thus autoneg failure is supposed to leave the autoneg side in half-duplex.

I've not had the same level of trouble with autoneg myself. If one does go the hardcode route, make sure that everything, everywhere is set to the same value. All it takes is one helpful tech to rearrange the cables in the wiring closet to ruin your network otherwise.

If there is a duplex mismatch somewhere between A and B (it could be anywhere along that traceroute) then there would be TCP retransmissions recorded in the netstat -p tcp output on the sending side, and probably out-of-order segments reported on the receiving side. Howevery, while duplex mismatch will imply TCP retrans, TCP retrans do not necessarily imply duplex mismatch - only lack of TCP retrans implies lack of mismatch.

If there is a duplex mismatch on one of the HP-UX NICs, it will appear in the output of lanadmin -g mibstats . A full-duplex link talking to a half will show FCS errors. The half-duplex link talking to a full will show "late collisions"