cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
17566
Views
0
Helpful
5
Replies

Don't Fragment bit ?

frederic.lens
Level 1
Level 1

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 5

Donald Nash
Level 3
Level 3

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.

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

Doc_ironport
Level 1
Level 1

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.

frederic.lens
Level 1
Level 1

Thanks for the info :)
Cheers,
Fred

Donald Nash
Level 3
Level 3

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: