A10 AX fragmentation issue

[Jim Kirby]

For those following this thread, this morning A10 Network posted version 2.6.1-sp2 which addresses this issue.  Caveat emptor.
-- 
Jim Kirby
Director of Engineering
Dataware Services
main: 605.336.0820 x368  
fax:  605.336.0228

On Jun 2, 2011, at 4:00 AM, George Bonser wrote:

> 
>> My understanding is that when the AX receives an ICMP6 Type 2 (packet too big) under SLB-PT that the AX is responsible for packet fragmentation which is what appears to be not happening.  George's questions make me wonder, what is the appropriate behavior.  Should the load balancer fragment or should it send an ICMP Type 3 Code 4 (fragmentation needed) message back to the server?  Would the second option even work?
> 
>> I captured packets on both sides of the AX; I saw the ICMP6 Type 2 packet and saw that full frames continued to be sent toward the client.  I did not see any ICMP packets forwarded to the real server but I was capturing only IPv6 so would not have caught the Type 3 Code 4 packet if one was generated.
> 
> Just to understand here,  this is SLB-PT with IPv6 on the Internet and IPv4 on the real server, correct?
> 
> 
> Well, it is going to be difficult to translate the packet.  Because in addition to translating the header addresses, the balancer is going to have to translate the contents of the packet because otherwise it won't make any sense to the server.
> 
> For example.  Imagine the server at 10.1.1.1 and the balancer is source-nating packets to 10.1.1.200.  The load balancer sees a connection from 2620:0:5100::13 the server sees a connection from 10.1.1.200.  Now the balancer gets a packet too big and inside that icmp message it says a packet from (ipv6 VIP ip) to 2620:0:5100::13 is too big.  It can't just forward that to the real server even if it changes the header addresses on the packet to v4 because the real sever isn't going to understand what a 2620:0:5100::13 is.  That doesn't look like an IP address to the server, the server says "I don't have any connections to 2620:0:5100::13" and ignores the packet".  That is, if it is even getting to the real server.
> 
> So not only do the packet headers need to be translated, so does the information carried by the packet and most devices don't mess with that which is why (well, another reason) relying on SNMP for PMTUD doesn't work.  It doesn't even work in v4 when the ICMP is generated from behind a NAT someplace in the path.  That is why the more modern PMTUD should be used.  PMTUD compliant with RFC 4821 such as turning on Linux MTU probing ... set /proc/sys/net/ipv4/tcp_mtu_probing=2 (is an ipv4 sysctl but is effective for both v4 and v6) might fix the problem.
> 
>