Fragmented packets being dropped.

[seabass1]

Hi Guys,

Just wondering if anybody has seen this before. If I try to ping an external address such as

http://www.yahoo.com

with a lot of data (ping

http://www.yahoo.com

-l 5000) it will not respond. At first I thought it was an mtu limit. So I sniffed it and found that I can use the command
ping

http://www.yahoo.com

-l 1472
and it goes through the frame size shows as 1514 but if I ping it with anything higher then 1472 it sends the first frame out with the size 1514 and then it has the more_fragmented bit set and right behind it will be the rest of the fragmented packets.

But they do not get a reply.

The only diffirence that I can see is that the more_fragment bit is set.

Has anybody heard of a router dropping fragmented packets?

Local large pings work fine.
I am using Comcast cable modem

Any Ideas or suggestions?

 

[markharr]

Is the 'do not fragment' flag set on in the IP header?

Are you receiving any ICMP unreachable replies?

This might require a trace to resolve. If you haven't already, you might want to take a look at Ethereal (

http://www.ethereal.com)

and capture a trace. Ethereal is quite good.

 

[seabass1]

Thanks for the reply.

The do not fragment bit is not set. Yeah I like ethereal a lot that is what I used to sniff it.

I've found that I can send a ping with 1472 bytes and it will create a frame at 1514 without fragmenting it however if I send it with larger than 1472 it will fragment the packet but the frame will never be larger than 1514. So my thoughts are that something is dropping the packet because it is fragmented.

Not sure though

 

[markharr]

Are there any ICMP unreachable replies?

 

[bcastner]

On the ping command the numeric value defines the datagram size, not the packet size.

So with the default MTU of 1500, the maximum non-framented value that can be used with the ping command is 1472 (1500 - 38 overhead). 1500 is the proper MTU for your cable connection.

In order to get the larger packets to succeed you would need to disable MTU discovery (PMTUD). (Decidedly not advised except as an experiment).


PMTUD is implemented by having an IP sender set the "Don't Fragment" (DF) flag in the IP header. If an IP packet with this flag set reaches a router whose next-hop link has too small an MTU to send the packet without fragmentation, that router discards that packet and sends an ICMP "Fragmentation needed but DF set" error to the IP sender. When the IP sender receives this Internet Control Message Protocol (ICMP) message, it should learn to use a smaller IP MTU for packets sent to this destination, and subsequent packets should be able to get through.
Various problems can cause the PMTUD algorithm to fail, so that the IP sender will never learn the smaller path MTU but will continue unsuccessfully to retransmit the too-large packet, until the retransmissions time out. Some problems include the following:

i. The router with the too-small next hop path fails to generate the necessary ICMP error message.
ii. Some router in the reverse path between the small-MTU router and the IP sender discards the ICMP error message before it can reach the IP sender.
iii. Confusion in the IP sender's stack in which it ignores the received ICMP error messages.

With the above problems, a workaround is to configure the IP sender to disable PMTUD. This causes the IP sender to send their datagrams with the DF flag clear. When the large packets reach the small-MTU router, that router fragments the packets into multiple smaller ones. The smaller, fragmented data reaches the destination where it is reassembled into the original large packet.

Sometimes a router will have a link with a large (1500 byte) MTU, but the router is unable to deliver a datagram of that size over that link. That router will not return a "Fragmentation needed but DF set" ICMP error to the sender, because the link does not actually have a small MTU. However, large datagrams will be unable to pass through the link. Therefore, PMTUD will not help, and all large-packet transmission attempts through this link will fail

Disable PMTUD:
PMTU discovery is enabled by default, but can be controlled by adding the following value to the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery

PMTU Discovery: 0 or 1 (Default = 1)

Data Type: DWORD

A "1" enables discovery while a "0" disables it. When PMTU discovery is disabled, a MTU of 1500 bytes is used for all non-local destination IP addresses. The TCP MSS=1460.
Setting this parameter to 1 (True) causes TCP to attempt to discover the Maximum Transmission Unit (MTU or largest packet size) over the path to a remote host. By discovering the Path MTU and limiting TCP segments to this size, TCP can eliminate fragmentation at routers along the path that connect networks with different MTUs. Fragmentation adversely affects TCP throughput and network congestion.

 

[seabass1]

Hi Guys,

The message is a "request timed out"

Also concerining the PMTU- That was my initial thought was I was sending packets that were to big. So I tried that enabling the PMTU Black Hole detect but with no luck. That's when I put a sniffer on and found that I can send packets that get through as long as they were not fragmented.

For example:

the command "ping

http://www.yahoo.com

-l 1472" Will get a response and a sniff shows that the it sends a frame at 1514
now if I do a "ping

http://www.yahoo.com

-l 1473"
I will not get a response but if I look at the sniff I can see that the first frame does not exceed that of the one that came from the first command (1472) The only diffirence is that the packet is fragmented and I can see a frame behind it with the data size set to 1.

So my thoughts are that I never exceed the MTU size since it is fragmenting them correctly. It's almost like something along the path is reassembling the packet and then sending it. Would a Proxy Server do that? I'm not sure if they have me using one or not.

 

[bcastner]

It is not Black Hole discovery at issue, it is MTU discovery.

 

[baghel2000]

Its a MTU problem,
You need to configure the below command on your outgoing interface:

IP MTU 1400

Whenever the packet is larger than 1400, packets will fragmented into smaller packets.

 

[technome]

Two cents...
Be careful in choosing the site for your testing for MTU. Yahoo is clean, their routers are not fragmenting packets. If you try

http://www.google.com,

once you hit their routers fragmentation occurs. You do not want to lower the MTU lower than necessary just because a particular site's routers are restrictive (like

http://www.google.com).

The pathping command will show the routers responsible for packet drops.


........................................
Chernobyl disaster..a must see pictorial

http://www.kiddofspeed.com/default.htm

 

[seabass1]

I've had this exact problem before. The problem turned out to be the router (linksys) - I tried changing the registry settings and manually setting the MTU but it didn't help. Once I put in a new router/firewall it fixed the problem -(just if your wondering I used a pix 501-)