How to clear Don't Fragment (DF) bit

I don't think you can change this behavior directly. Your only option is to lower the MTU on the 'external' VLAN to a suitable value.

let's see this article http://support.f5.com/kb/en-us/solutions/public/6000/000/sol6064.html

 

 

what about adverse effects when disable Path MTU Discovery enforcement?

The adverse effects are what you are seeing, packets being dropped as they can't be fragmented. PMTU most likely doesn't work through most networks these days because of firewalls and other security measures so I wouldn't be too concerned about turning it off, however, I don't believe it will help either.

PMTU discovery SHOULD work though most networks. If they're installed and maintained by professionals who know what they're doing, and care about not being woken by callouts about strange issues with established connections timing out and dropping.

 

 

With IPv6 PMTU discovery is pretty much mandatory, or you set your remote MTU to 1280 (?) which is the minimum MTU for IPv6.

 

 

A better fix would be to find out where the ICMP host unreachables are being dropped and fix it.

 

 

H

Unfortunately that's not been my experience, particularly where firewalls and router ACLs are concerned. Even where you can control and 'fix' these internally, external and internet sourced connections still present a problem. I've always found it simpler and to be blunt, more reassuring to just drop the VLAN MTU by 160 or so (no great loss).

 

 

BTW, do you know if disabling PMTU would also stop use of the DF bit? What I've read suggests that may be the case.

Well... I do network design. And 3rd level network support. Wherever my clients have PMTU problems, it's always solved by a little education in the direction of the admin who is blocking ICMP.

 

 

Disabling PMTU will not necessarily disable the DF bit. A better scheme is to just drop the remote MTU to the end-point. With most decent OS's (e.g. Linux) that can be done with an entry in the routing table.

 

 

Dropping the local MTU is a horrible hack, and liable to issues (Performance is a particular one. A lower MTU means lower throughput). The specs say all local MTU's should be identical for a reason.

 

 

H

Oh. A better work-around for a VS is to drop in a custom iRule that lowers the MSS negotiated for the particular client that's broken. That way it won't affect anyone else.

 

 

G

The wiki page for TCP::mss is pretty bare but unfortunately it appears to only be able to return the MSS, not set it which is a shame.

 

 

I understand your POV but I'd rather reduce the maximum packet payload by 11% than try to 'fix' someone else's multinational and administratively segregated network and security infrastructure again and again. If MTU was that important we'd all be using Jumbo Frames.

This problem is client can't ping to virtual server with MTU 1500. it has only one problem virtual server.

 

So fix MTU at interface is not an option. (iRule is a better way to solve this but how??)

 

now i check to see Is it caused by firewall (checkpoint). but problem is occur just one virtual server, so it's hard to find cause.

 

 

thank you

And you are using the same client to PING all the other Virtual Servers? Are they in the same IP range? Is the route from client to server the same?

 

What's the maximum packet size you've been able to use successfully?

 

 

I don't see an iRule working here unless Hamish can come up with something.