A10 AX fragmentation issue

[Paul Nicholson]

Just a quick note for those looking for this update, both the update and
release notes can be downloaded from these links:

2.6.1-sp2 Upgrade for <select for your model>:
https://www.a10support.com/support-axseries/downloads.php

Release note:
https://www.a10support.com/support-axseries/downloads/ax-relnotes-v2_6_1-SP2
-20110602.pdf 

If any customers have any queries please contact support on the standard
number 24/7: USA and Canada: +1-888-TACS-A10 (+1-888-822-7210) or
International: +1-408-325-8676.  

Also thanks to Jim and others for all the information they provided to our
support team last week, and those who confirmed it fixed the issue today.

Paul.



-----Original Message-----
From: ipv6-ops-bounces+pnicholson=a10networks.com at lists.cluenet.de
[mailto:ipv6-ops-bounces+pnicholson=a10networks.com at lists.cluenet.de] On
Behalf Of Jim Kirby
Sent: Friday, June 03, 2011 4:13 PM
To: George Bonser
Cc: ipv6-ops at lists.cluenet.de
Subject: Re: A10 AX fragmentation issue

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.
> 
>