Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Don't Fragment bit ?

Hi all !

Doing some TCP captures, I noticed that all packets originating from the Ironport's have the "Don't Fragment" Bit set...

Is this normal / wanted ? Can this be disabled ? (I suspect this is causing problems in some situations...)

Could these two topics also be affected by the DF bit :
- https://www.ironportnation.com/forums/viewtopic.php?t=1009&highlight=tcp+settings
- https://www.ironportnation.com/forums/viewtopic.php?t=898&highlight=tcp+settings

Thanks and regards,
Fred

5 REPLIES
New Member

Re: Don't Fragment bit ?

That's probably part of path MTU discovery. Setting DF is pretty innocuous. All it can do is cause a packet to be dropped if it is too big, and that causes an ICMP notification to be sent back to the originator so it can adjust its packet size.

New Member

Late update -In most

Late update -

In most environments the aforementioned is good practice and PMTU will sort things out but it's beyond me why it's not at least a tuneable parameter in AsyncOS. In some ubersecure environments it's not at all possible to get PMTU enabled - and we witnessed packets getting dropped by the IPSec ingress interface - which normally would perform fragmentation. With WCCP the ICMP type 3 , code 4 informational data from the device not able to cope with it whilst instructed to "not fragment"  won't be redirected to the proxies (in our case wccp on ASA so just dropped). This is a real bummer  - not even the "pmtu disable" at CLI changed that behavior as I would expect. We had to apply a PBR policy on one of the downstream routers to overwrite DF bit as a workaround. I would expect default behaviour to be to not change the original DF value.

 

Rik

New Member

Re: Don't Fragment bit ?

Welcome to the world of MTU Path Discovery.

By setting the DF bit the IronPort - like most modern OSes (ie, anything beyond about 1995!) - will attempt to determine the optimum MTU (Maximum Transfer Unit - basically the maximum packet size) allowed for the complete path between the sending and receiving hosts.

Determining the MTU is a good thing, and means that packets don't need to be fragmented by an intermediary host, which in turn gives the best possible performance.

The problem with MTU Path Discovery is that some admins get over zealous about security, and do silly things. The most common "silly thing" that admins do in this respect is that they drop all ICMP traffic, on the basis that all ICMP traffic is bad.

In fact this couldn't be further from the truth. ICMP is critical to the correct operation of TCP (and other protocols), and by blocking certain ICMP packets admins often end up breaking other protocols, such as TCP.

Whilst there may be valid reasons to block certain type of ICMP messages (eg, ping packets, redirects, etc) there are some types of ICMP which should never be blocked. The most obvious of these is ICMP Type 3, code 4 which is "Fragmentation required but DF bit set", which is the one that breaks MTU Path Discovery if it's turned off. Most of the rest of Type 3 are also good to allow.

New Member

Re: Don't Fragment bit ?

Thanks for the info :)
Cheers,
Fred

New Member

Re: Don't Fragment bit ?

The problem with MTU Path Discovery is that some admins get over zealous about security, and do silly things.  The most common "silly thing" that admins do in this respect is that they drop all ICMP traffic, on the basis that all ICMP traffic is bad.

That's not a problem with path MTU discovery, that's a problem with sysadmins who don't know what they're doing.

1920
Views
0
Helpful
5
Replies
CreatePlease to create content