Operating System - HP-UX
1753519 Members
4944 Online
108795 Solutions
New Discussion юеВ

Re: Chaning the MTU value

 
SOLVED
Go to solution
Manuel Carbajal
Occasional Advisor

Chaning the MTU value

HI,
i have a hp-ux 11i machine, and all the routers and equipment in the net are configured for mtu as
120 bytes, i've tried to change the mtu whithin the hp-ux but the minimum value is 257.

Is there any way to low this value to the one needed?

Thanks in advance,
Regards,
Manuel
8 REPLIES 8
Jochen Heuer
Respected Contributor
Solution

Re: Chaning the MTU value

Hi Manuel,

one question: why do you want to use a MTU of 120? I see no real sense in this because then the overhead for tcp/ip headers takes away much more bandwidth ...

Regards,

Jochen
Well, yeah ... I suppose there's no point in getting greedy, is there?
Ron Kinner
Honored Contributor

Re: Chaning the MTU value

I agree with Jochen. Who told you that an MTU of 120 bytes was required? Using that small a packet size would really kill performance since the TCP/IP overhead would be about 50% on every packet. Add the Ethernet overhead and most of the packet is wasted on protocol info.

Ron
rick jones
Honored Contributor

Re: Chaning the MTU value

As others have pointed-out an MTU of 120 bytes is really very, very small. Unless you have some _really_ slow network links, I would have to guess that the MTU's are so constrained to kludge around some sor tof applicatoin bug/issue with the Nagle algorithm or something.

Anyhow, you don't say what command you used to set the MTU, but from my own experimentation I am guessing you used lanadmin.

Indeed, it seems to have a limit of 257 bytes.

There may be another way. It involves the route(1m) command - it offers a -p option to set the PathMTU for the route. You would delete your existing routes (from the console!) and add them back in with the -p option specifying 120. Then, even though the link had an MTU of 1500 bytes, any TCP connections going through those routes would use a PathMTU of 120 bytes.

Also, unless you disable PathMTU discovery, (ip_pmtu_strategy 0 with ndd) the first hop router should be sending a destination unreachable packet too large message back to the HP-UX system and it should be using the smaller PathMTU already.

This will not happen if the system is talking to a "local" system (not through the router) however, if the MTU on the other systems on the subnet is indeed set to 120 bytes, then their TCP stacks should be sending an MSS (maximum segment size) option in their SYN (tcp connection establishment) segments based on that MTU and so TCP should be sending smaller segments even without setting the MTU on the interface or via the route (however, that would not hold for UDP communication).

So, if you can elaborate on why your networks are running with a 120 byte MTU it would help figure-out what to do.

In the meantime, if you can, do contact the RC and have a defect filed against lanadmin - since the minimum IPv4 datagram size is 68 bytes, they should be allowing an MTU less than 257 bytes in lanadmin...
there is no rest for the wicked yet the virtuous have no pillows
Ajit Natarajan
Valued Contributor

Re: Chaning the MTU value

It would be helpful if you could tell us which link you're trying this on.

For 100BT adapters, i.e., those adapters controlled by the btlan driver, the MTU can be set as low as 257 bytes. Any lower than that is not supported.

For Gigabit Ethernet adapters, i.e., those controlled by gelan or igelan, the MTU can only be set to 1500 or 9000. Other values are not supported.

You can determine the adapter type by using ioscan(1M).

Also, note that lanadmin(1M) does not check for the minimum MTU size. The driver checks for it. So, filing a defect against lanadmin may not be effective.

I concur with the other people who have responded. You must be able to justify setting the MTU to such a low value. If you can, it would then be best if you use PMTU as Rick Jones suggested.

Thanks.

Ajit
HP Gigabit Ethernet

Manuel Carbajal
Occasional Advisor

Re: Chaning the MTU value

Thanks for all the responses..
well if was for a test, happens thata we have i the site two machines one hp and the other is aix. The routers that connects the main site (where the two machines are) to remote sites, is configured with 120 MTU, no one can tell me exactly why, we've just inherited this installation, i think is a QOS issue for Voice over IP. I agree thata 120 is a really low value, since the line is at 128kbps i think a minimum mtu for this class of line for optimal voice over ip communication is 160.
The problem comes when no remote machine can connect to the HP, via telnet, ftp or any other port.

The case is different for AIX, all the remote machines can connect.

I think the mtu discovery is configured in the aix, in the hp is configured at 120 to the default router via the -p option in the netconf file.

My main problem is why are not connecting to the HP but the can to AIX.

Thanks in advance.

Regards,
Manuel
avsrini
Trusted Contributor

Re: Chaning the MTU value

Hi Manuel,
Are you able to ping hp server from your remote clients?. If you can, try changing the packet size and try till you get the best size.

The PMTU setting through route -p command can be set only to a host. You cant set for a network. If you have a setting for network it will be ignored.

Can you see any messages on syslog regardint the tcp connection time-out or like that?. Also check netstat -s
for errors.

I'll try to get more info for you.

Srini.
Be on top.
Ron Kinner
Honored Contributor

Re: Chaning the MTU value

If I understand correctly the problem comes and goes? This does not sound like an MTU issue however it wouldn't hurt to see which stategy you are using:

ndd -get /dev/ip ip_pmtu_strategy

should tell you. Do

ndd -h ip_pmtu_strategy

to get a surprisingly detailed help message.

A more likely scenario is that there is a problem with the router responding to the dead gateway probe from hpux.

11.0 has dead gateway detection on by default. Don't know about 11i. Look and see:

ndd -get /dev/ip ip_ire_gw_probe

Check the help with ndd -h ip_ire_gw_probe

(I think that is right. My 11.0 system doesn't have the right patch to show it. Only shows ip_ire_gw_probe_interval)

What happens here is that the HP tests the gateway (router) every ip_ire_gw_probe_interval (usually 3 minutes) by sending a ping. If it gets a response then everything is good but if no response then it thinks the gateway is dead, removes it from the routing table and won't restore it for another 3 minutes when it tries a new ping. I'd try turning off the gw probe by setting it to 0 and see if the problem is resolved.

You might want to check for duplex mismatches or bad cables which would cause packets to get lost. Some switches will kill off a port if there are too many errors but then it wouldn't be just the remote sites which were unable to talk but the AIX and the router would not be able to ping the HP either.

On the HP you can check for ethernet errors with
lanadmin
lan
display

There are two pages. Most of the errors are on the second page. Hit Enter to see the second page.

(make sure you are looking at the correct NIC if you have more than one.)

Also a linkloop test (see the man) can be run to see if the Ethernet connection to the router is clean. The problem could be on the Router connection to the switch too.


Ron

Manuel Carbajal
Occasional Advisor

Re: Chaning the MTU value

Thanks for all the answers but, i still have some doubts.

Since the lanadmin can be set as minimum 257 bytes, that means that the mtu is the lowest supported by the nic, i've notices that my ip discovery mtu is enabled, and the probe gateway is set at 1 minute. i've set the route default with the -p 120 option to match the mtu in the default router. My question is, if all this is et to match the router and the packets that travels thru, could be possible that the 257 minimum frame value could affect to change the mtu effectively to 120?
Even when the remote machines are conected, the connection is refused or not completed in less than 2 seconds.


Thanks for everything.

Regards,

Manuel
Manuel