How to strip DF bit on an access port on a 3750?

MATT HILL · ‎02-08-2006

Hi there...

A client of our has a custom DB application running on Windows 2003 server which sends out 1512 byte packets with the DF bit set. As you can imagine this is bad as the network will just drop all the >1500 byte packets.

Now, we have tried a few things here with no luck:

Reducing MTU on the NIC in the registry doesnt help. I am guessing that the Application sends out the 1512/DF packets and by the time it gets to the network layer the NIC itself drops them.

We cant do Jumbo frames because some other switches(2900s) and PCs are not Jumbo aware.

The customer claims the application cant be modified to remove the DF bit prior to sending the frame.

The customer doesnt want to buy brand new 6500s/3750s, much to the account managers chagrin.

Now... I would like to apply a policy-map or similar to remove the DF bit inbound on the switchport, but of course its an L2 access port so this wont work, also, the network is one L2 vlan so putting a route-map on the vlan interface wont do anything because nothing is happening at L3.

Any ideas would be appreciated, because all of us here cant think of anything right now!

Cheers

pkhatri · ‎02-08-2006

Hey Matt, how are you ? (remember me ?)

Just had a thought. Why don't you insert a low-end router (17xx/26xx will do the job) between the server and the switch. You will, of course, need to give the server a new IP address and a new default gateway. Configure an inbound service-policy on the router interface to the server to clear the DF bit.

Then, configure a static nat mapping between the new address and its original address. You won't need to change anything on the clients. When they ARP for the server's original address, the router will respond with its own address. When they send packets destinated to this MAC address, the router will perform NAT and send the packet to the server. In the server->client direction, the server will simply send all client-bound traffic to the router which will NAT the source address and take care of it.

Of course, this assumes that the application is NAT-friendly...

That should work but maybe I've overlooked something basic that could break this solution :-(

Regards,

Paresh

scottmac · ‎02-08-2006

Stripping the DF bit will probably not help.

If the application uses some form of encryption (the usualy reason for DF these days), then fragging the traffic will (usually) break the encryption, and the traffic will be dropped at the destination when the FCS and/or CRC fail.

So, all you'd accomplish is moving the point at which the traffic is discarded ... and in that case, you're just wasting bandwidth.

If you're using a Windows-based server, you might be able to use something like "Dr TCP" which is available from DSLReports.com. Dr TCP permits you to edit the parameters (like MTU) in the OS, regardless of the NIC drivers.

If you're using a *nix server, you should be able to set MTU with the ifconfig command.

There are more details to be known, for sure ... but so far it sems to boil down to "I can only do it this way, but I don't want to spend the money to do it that way" (like, I'd like to buy a Boeing 747 for US$10.00 (with a 24X7 crew).... but I don't think I'll ever be able to).

Is the traffic encrypted? Or is it just the developers refusing to "reduce the efficiency of their application?" Did they mention why the traffic can't be fragged? Did some developer set the DF and they don't want to / can't find someone to change the code? (COBOL???? OH NO!!!! ;-})

Let us know

Thanks,

Scott