we have a unix box that receives ICMP fragmentation requests because
the MTU size is too large, but it continues to retransmit the packet
without changing the MTU size. I don't know Unix, how can I check if
there is a setting on this box that is preventing the packet from
fragmenting

roboftheblues wrote:
> we have a unix box that receives ICMP fragmentation requests because
> the MTU size is too large, but it continues to retransmit the packet
> without changing the MTU size. I don't know Unix, how can I check if
> there is a setting on this box that is preventing the packet from
> fragmenting
>

You cannot stop a packet fragmenting if it is too big. Try looking in
the documentation for Path MTU discovery and the commands "no -o
tcp_pmtu_discover" and "no -o udp_pmtu_discover".

Packet fragmentation should be happening but it isn't. The unix box is
ignoring the packet fragmentation request from ICMP. Any ideas??

roboftheblues <robwood894@hotmail.com> wrote:
> we have a unix box that receives ICMP fragmentation requests because
> the MTU size is too large, but it continues to retransmit the packet
> without changing the MTU size. I don't know Unix, how can I check
> if there is a setting on this box that is preventing the packet from
> fragmenting

picking nits perhaps, but your host is receiving ICMP Destination
Unreachable messages with a subcode of "fragmentation needed but Don't
Fragment set" (something like that) because the ip _datagram_ size is
larger than the MTU of the next hop link.

upon receipt of this message, your host is not altering the size of
the IP datagrams it is sending. it should never change the link-local
MTU in response to the ICMP message.

in other words, MTU is a function of a link, not a packet.

You either have to have the host stop setting the DF bit on the IP
datagrams it sends - that will be related to the aforementioned path
MTU discovery stuff. Under the AIX variant of Unix I _believe_ that
settings like that are controlled via the "no" (network options?)
command.

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Hi Rick,

Here is a copy of the TCPDump from the host, the IP addresses have been
changed to protect the client:

14:01:36.842730 I 10.***.2.3.20 > 10.25.***.106.1288: . 1:1461(1460)
ack 1 win 17520 [tos 0x8] (ttl 59, id 8523)
14:01:36.844298 O 10.***.34.5 > 10.***.2.3: icmp: 10.25.***.106
unreachable - need to frag (mtu 1464) (ttl 63, id 32972)
14:01:39.843190 I 10.***.2.3.20 > 10.25.***.106.1288: . 1:1461(1460)
ack 1 win 17520 [tos 0x8] (ttl 59, id 8545)
14:01:39.844795 O 10.***.34.5 > 10.***.2.3: icmp: 10.25.***.106
unreachable - need to frag (mtu 1464) (ttl 63, id 32973)
14:01:45.843923 I 10.***.2.3.20 > 10.25.***.106.1288: . 1:1461(1460)
ack 1 win 17520 [tos 0x8] (ttl 59, id 8583)
14:01:45.845486 O 10.***.34.5 > 10.***.2.3: icmp: 10.25.***.106
unreachable - need to frag (mtu 1464) (ttl 63, id 32974)
14:01:57.845672 I 10.***.2.3.20 > 10.25.***.106.1288: . 1:1461(1460)
ack 1 win 17520 [tos 0x8] (ttl 59, id 8664)
14:01:57.847290 O 10.***.34.5 > 10.***.2.3: icmp: 10.25.***.106
unreachable - need to frag (mtu 1464) (ttl 63, id 32975)

Can you make any sense of this and what to do to fix it on the AIX
boxes??

You might read:

http://groups.google.de/group/lists....ec4efdbd409f43

=============================
SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures ...
.... 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4192) 15:03:00.327688
204.29.161.41 >
198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006)
(DF ...
lists.nanog - 20 Nov. 1998 23:16 von Greg A. Woods - 8
==============================

So mybe its not an AIX issue but an router and/or firewall/vlan/load
balancer problem.

hth
Hajo

roboftheblues <robwood894@hotmail.com> wrote:
> Hi Rick,

> Here is a copy of the TCPDump from the host, the IP addresses have been
> changed to protect the client:

Given that a 10. address is one of the "private" ranges, there would
be no way for us to know who the client happened to be anyway...

Might be better to add a -v to tcpdump to have it explicity show that
the DF bit was set in the IP header.

> 14:01:36.842730 I 10.***.2.3.20 > 10.25.***.106.1288: . 1:1461(1460)
> ack 1 win 17520 [tos 0x8] (ttl 59, id 8523)
> 14:01:36.844298 O 10.***.34.5 > 10.***.2.3: icmp: 10.25.***.106
> unreachable - need to frag (mtu 1464) (ttl 63, id 32972)
> 14:01:39.843190 I 10.***.2.3.20 > 10.25.***.106.1288: . 1:1461(1460)
> ack 1 win 17520 [tos 0x8] (ttl 59, id 8545)
> 14:01:39.844795 O 10.***.34.5 > 10.***.2.3: icmp: 10.25.***.106
> unreachable - need to frag (mtu 1464) (ttl 63, id 32973)
> 14:01:45.843923 I 10.***.2.3.20 > 10.25.***.106.1288: . 1:1461(1460)
> ack 1 win 17520 [tos 0x8] (ttl 59, id 8583)
> 14:01:45.845486 O 10.***.34.5 > 10.***.2.3: icmp: 10.25.***.106
> unreachable - need to frag (mtu 1464) (ttl 63, id 32974)
> 14:01:57.845672 I 10.***.2.3.20 > 10.25.***.106.1288: . 1:1461(1460)
> ack 1 win 17520 [tos 0x8] (ttl 59, id 8664)
> 14:01:57.847290 O 10.***.34.5 > 10.***.2.3: icmp: 10.25.***.106
> unreachable - need to frag (mtu 1464) (ttl 63, id 32975)

1464 certainly seems like a very odd MTU.

> Can you make any sense of this and what to do to fix it on the AIX
> boxes??

Perhaps the AIX box is running firewall software which is filtering
all ICMP messages? Or something after your tracepoint but before the
AIX box.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

"roboftheblues" <robwood894@hotmail.com> wrote in
news:1128092043.514967.227440@g49g2000cwa.googlegr oups.com:

> Hi Rick,
>
> Here is a copy of the TCPDump from the host, the IP addresses have been
> changed to protect the client:
>
> 14:01:36.842730 I 10.***.2.3.20 > 10.25.***.106.1288: . 1:1461(1460)
> ack 1 win 17520 [tos 0x8] (ttl 59, id 8523)
> 14:01:36.844298 O 10.***.34.5 > 10.***.2.3: icmp: 10.25.***.106
> unreachable - need to frag (mtu 1464) (ttl 63, id 32972)


This is very strange, the sent packet is 1460 bytes long, the ICMP
complains that is should be smaller than 1464 (which it already is).

Either something is adding bytes to the packet in-transit OR the router at
10.***.34.5 doesn't know how to count.

> Can you make any sense of this and what to do to fix it on the AIX
> boxes??
This doesn't seem to be at the AIX level. You seem to have a real problem
on your network.


--
Doing AIX support was the most monty-pythonesque
activity available at the time.
Eagerly awaiting my thin chocolat mint.