Proxy MSS

As a followup question to your MSS-question...

 

 

F5 market the LTM as a "full-proxy", wouldnt this mean that a F5 virtually never fragment any packets because all flows is proxied through the LTM "full-proxy" engine?

 

 

I mean a regular router, lets say Cisco, would (if it have MTU1500 on inside and MTU1200 on outside) fragment packets (if the client send lets say 1500 byte packets without DF bit set) on the outside into 1200 + 300'ish per every 1500 byte packet who arrives on the inside. This also gives that in this case a client who sends 100kpps 1500bytes packets on the inside the router must forward 200kpps 1200+300 byte packets on the outside.

 

 

If you use a true proxy the proxy will instead buffer in between so that there are no fragments on the outside. In this case the proxy would send one packet on the outside per every packet that arrives on the inside with an additional extra packet on the outside once the buffer contains a remain that can fit in a full outside packet. If we take the packets per second example a client who sends 100kpps 1500bytes packets on the inside would result in approx 125kpps 1200 bytes packets on the outside if a proxy is being used.

F5 market the LTM as a "full-proxy", wouldnt this mean that a F5 virtually never fragment any packets because all flows is proxied through the LTM "full-proxy" engine?i do not think so. i understand full-proxy means two separate connection between client-f5 and f5-server.

 

 

for proxy mss, i do not have experience about it. leave it to another guy. :-)

I agree with nitass that it's two seperate connections. 1 client and 1 server. If it were to buffer like you suggest mikand I would think it would introduce to much latency and buffer size would need to be large.

 

 

My question was more about the posible negative side effects of enabling proxy mss.

 

 

Most network devices have both receiving and send buffers, otherwise you would end up with heavy packetloss during burst situations.

 

 

Also a buffer is needed otherwise the F5 couldnt perform any analysis on the packet itself.

 

 

So im pretty sure there is already a buffers in the design of the F5 :-)

 

 

The buffersize in this case would only need to be twice the MTU size, the packet to be sent + remain (FIFO-buffer).

 

 

But again, F5 perhaps isnt a true proxy?

 

 

According to http://www.f5.com/pdf/white-papers/tcpexpress-wp.pdf the F5 will do what I asked about, maintain one mss towards client and one towards mss and buffer in between. I suppose this also means that the default value of "proxy mss" (disabled?) means that this feature is in action (because its described as default behaviour in this document) and if you change the value of "proxy mss" (into enabled?) the F5 will start to behave like a regular router (creating fragments as worst case) - or did I misunderstand what this document tries to tell me? ;-)

if you change the value of "proxy mss" (into enabled?) the F5 will start to behave like a regular routeri do not think so. mss is only one parameter of tcp.

I know this is an old post, but this might be really important to someone seeing ssl flows breaking on the first large inbound packet and does not see it show up outbound.

 

Say you have a TCP peer on one side of the LTM proxy negotiating mss to 1200 bytes and the on the other side, the a TCP peer is negotiating to 1500 bytes. I believe that without proxy-mss, the mss negotiated on one side (important when it is lower mss), is not considered when negotiating the mms value on the other side of the proxy. This is problem if the sender is on the large mms side of the proxy and the DF bit is set (like we see with HTTPS) and is sending to the smaller mss side of the proxy.

 

What you should see is an ICMP warning message being sent in the direction of the sender (larger mss side). The router/firewall may block the feedback and you end up with dropped packets due to packets exceeding the mss on the smaller mss side.