Forum Discussion
kridsana
Cirrocumulus
CirrocumulusHow to clear Don't Fragment (DF) bit
there is some virtual server that have a problem that
packet segment lost when MTU = 1500
so i want to clear DF bit to fix this problem , and how to clear it?
thank you
HamishMSS won't help.
How many hops away is this client? Is the path across a private network? Or internet? Does the echo-request make it all the way to your firewalls?
H
kridsanaBefore that , I need to know why F5 set DF bit in first place ?
and what the meaning of this bit ? ....and... what adverse affect when this bit is set ?
What_Lies_Bene1Cirrostratus
This is a pretty good article on the subject despite it being Cisco focussed: http://blog.ine.com/2008/11/05/deal.../more-327
- HamishPosted By teepan123 on 01/01/2013 10:28 PM
Before that , I need to know why F5 set DF bit in first place ?
and what the meaning of this bit ? ....and... what adverse affect when this bit is set ?
A quick summaryDF bit is to tell routers NOT to fragment packets. This means that if a packet is too lareg to pass across a link with a different MTU, the packet muct be dropped and a message (ICMP host unreachable) must be sent back to the source to tell them to lower their MTU (Path MTU) to the remote host.
Having DF set is usually the default. And a good thing. Without it, you have to make the assumption that the path MTU to a remote host is 512 Bytes. That means many more packets for the same amount of data. WHich lowers throughput as the overheads go up.
So why not just fragment? Because it's bad. The target host has to buffer all thise fragments for an amount of time so it can rebuild the whole packet. This takes recources. Send enough fragmented packets to a host and it's a great DOS attack. Most hosts/firewalls will/should be configured to DROP fragmented packets. So that's another downside to removing the DF flag.
Dropping your local MTU to make a remote host work is also bad. ALL the MTU's on a local subnet MUST be the same size. (OK. MOst modern hosts will actually accept inbound packets larger than the configured MTU, but there's no guarantee. And performance will suffer too).
H
- HamishActually that might be a good idea to raise an RFE to allow iRules to alter the path-mtu on the fly to a particular host...
H - What_Lies_Bene1
Hamish, forgive me if it seems I'm being argumentative but this is a lot like the conversations I have with people about Virtual Addresses not needing to be in the same subnet as any Self IP; the understanding that an apparent restriction or 'rule' doesn't exist can completely change a design or approach. I post this only for the benefit of others, not to annoy you ;-) I'm happy to discuss this privately if you'd like.
The MTUs on a local subnet don't need to be the same. The layer two MTU (it's a VLAN setting on BIG-IP) will dictate the layer three MSS and therefore MTU. As long as the device with the different MTU is acting as an IP endpoint it'll inform the other endpoint of what its MSS is and things will work just fine. Where the F5 is concerned Content Spooling will smooth out any differences between client-side and server-side MTUs. The only situation where this might break things is where a layer two VS is used. Some may consider this a hack but considering that Cisco routers offer commands to clear the DF bit in packets or overwrite the MSS setting (or both) there's clearly a need here and tweaking and changing things at the network level is surely what BIG-IP is all about. Also, anything outside of the base TCP/IP specification could be considered a hack, from NAT to SACK.
Of course, as with anything, lowering the MTU should be considered carefully and the benefits and drawbacks thought through. If you have a great deal of Internet or VPN sourced clients, lowering the MTU on your external VLAN will probably be useful (and you could also create a dedicated VLAN to target things more specifically). If you don't, it's probably best not to touch it..
Best I don't mention using static ARP entries on a VLAN without Self IPs to direct traffic to the BIG-IP. :-) - HamishI'll be blunt. You need to read the IP and ethernet standards before making statements about MTU's. Also don't call the MSS a layer-3 MTU. It's not. It's the MSS. Am i being pedantic? Yes. Most assuredly. Not to be an ***. But simply because THAT IS THE STANDARDS. It's why things appear to magically work so well across the whole internet. Because the standards are well written, easy to understand and precise. Yes, violating some of them DOES appear to work. Mostly. Until you discover the edge situations and learn the hard way that violating the standards is a little like dropping litter in Singapore... Just substitute $500 fine for damn thing isn't working... The lack of IMCP unreachable coming back (WHich is the whole cause of this thread) is a Case in point. Sure, not passing them APPEARS to work. But this in itself is one of the edge situations where it breaks. SOMEWHERE in the path between the two endpoints has a lower MTU. It works for SOME people because they're doing stuff correctly. SOMEONE has done something WRONG, which VIOLATES the STANDARDS in the first place. Putting ANOTHER VIOLATION in place to fix them is NOT the right way to do it.
Of course I can't stop you from violating the standards and you should feel free to do so. After all, it's what keeps me useful to people with deep pockets
regards
hamish - HamishOh. And VS addresses DON"T need to be in the same vlan as a self IP. In fact you don't need ANY selfip on the VS VLAN. You just have to ensure the traffic routes THROUGH the BigIP. I'm not sure you'll find anyone who can successfully argue the other way round.
And there's not a lot wrong with static ARP entries. Used them myself lots of times in the past. Along with proxy-arp and other ways to get traffic to flow where you want it to (I even re-write nexthop MAC's on my bigip's to selectively direct traffic via transparent devices.
H - What_Lies_Bene1I'm feeling the heat now! I've edited my post to correct the MSS/MTU 'order'. As stated here: http://en.wikipedia.org/wiki/Transmission_Control_ProtocolMaximum_segment_size:
"...typically the MSS is announced by each side using the MSS option when the TCP connection is established, in which case it is derived from the maximum transmission unit (MTU) size of the data link layer of the networks to which the sender and receiver are directly attached..."
Regarding the Ethernet standard of a minimum MTU of 1500 I would generally agree with you but in this case, considering the local significance, the fact lower MTUs are very likely to exist outside of the local network, the fact PMTUD effectively does the same thing at layer three and the lack of any ability to manually modify the IP MSS (which is available on most hosts) on the BIG-IP I would make an exception. I've done this in many live and busy environments without ever facing an issue. - HamishYou're quoting wikipedia at me for standards? Shame on you... It's worth exactly what you paid for it (For references see some amusing tales regarding new organisations who use it for references and them get found out because the info is just plain suspect).
:)
And who said (Or implied?) anything about minimum MTU of 1500 for ethernet? 1500 is THE MTU for ethernet. Apart from obvious extensions like Jumbo frames on Gb+ networks. You know one of the BIGGEST things to go wrong with token-ring networks in the days when TR and Enet were fighting it out? Variable MTU's. Caused way too many problems. The last big issue I had with a VMS admin... Wrong MTU's... Yes, it might solve/work-around THIS issue. Yes it will more than likely raise aNOTHER issue somewhere else. Much better to fix it properly at source.
Like I said... The admin who configured the ICMP messages to be dropped probably thought he was doing something harmless too..
H