A10 AX fragmentation issue

[Jim Kirby]

I have been working with A10 since Mr. Roesen helpfully pointed out the fragmentation issue.  A10 have acknowledged a problem and promised a patch to 2.6.1 which is supposed to be released May 31 (as of this writing it has not yet been posted).  2.6 however is not yet production code.  From their site:  "Release 2.6.1 is a major release with extensive QA testing but has limited Beta testing. A10 recommends lab testing and field trial before deploying in wide-scale production."

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.
--
Jim Kirby
Director of Engineering
Dataware Services<http://datawareservices.com>
main: 605.336.0820 x368
fax:  605.336.0228

On May 29, 2011, at 1:35 AM, George Bonser wrote:

In other words, the A10 is simply passing the packets to the server.  The A10 isn’t doing anything with them other than translating the destination address of the packet from the VIP to the real server address.  It is the real server that is handling the packet (or not).  At least that has been my experience with the A10 devices to date.

So it (the A10) isn’t so much treating the packet incorrectly as the server is probably treating it incorrectly.  It could be that the A10 isn’t passing the ICMP packet to the server at all.  Do you have tcpdump of the traffic before and after the A10?

George


From: ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de<mailto:ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de> [mailto:ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de] On Behalf Of George Bonser
Sent: Saturday, May 28, 2011 6:49 PM
To: Cameron Byrne; ipv6-ops at lists.cluenet.de<mailto:ipv6-ops at lists.cluenet.de>
Subject: RE: A10 AX fragmentation issue

Ok, there is another thing to check.  If the ICMP packet is being generated from behind a NAT it may not be effective.

Is this a v4 ICMP packet or a V6 ICMP packet?  If it is v4 and if it is being generated from behind NAT,  it probably isn’t going to work (ICMP says packet to 10.1.2.3 is too big, balancer says “I don’t have a connection to 10.1.2.3, I have a connection to 123.45.67.89” )

But again, setting  that sysctl in the real servers if they are Linux will eliminate the need for ICMP to do PMTUD.  ICMP PMTUD should never be expected to work anyway which is why it is not the default mechanism anymore with Windows or Solaris.   Too many people block ICMP in their networks or the ICMP is being generated from behind a NAT and contains nonsensical information.




From: ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de<mailto:ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de> [mailto:ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de] On Behalf Of Cameron Byrne
Sent: Saturday, May 28, 2011 11:54 AM
To: ipv6-ops at lists.cluenet.de<mailto:ipv6-ops at lists.cluenet.de>
Subject: Re: A10 AX fragmentation issue


On May 28, 2011 11:14 AM, "Daniel Roesen" <dr at cluenet.de<mailto:dr at cluenet.de>> wrote:
>
> On Sat, May 28, 2011 at 10:07:02AM -0700, George Bonser wrote:
> > Is this an A10 issue or is this a problem with ICMP PMTU discovery in
> > general?
>
> The former. The AX doesn't react to the ICMP packet too big and
> continues sending packets unfragmented.
>

Any chance you have a bug filed with them and can share the bug Id?

Cb
> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: dr at cluenet.de<mailto:dr at cluenet.de> -- dr at IRCnet -- PGP: 0xA85C8AA0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20110531/1b63df6f/attachment.htm>