ZyXEL NBG6515 IPv6 WLAN performance

Summary

I have 6rd tunneling on Linux server on the network, now the IPv6 traffic on the WLAN (WiFI) interface of the NBG6515 is incredibly slow. Around 3-4 kilobytes/s.

Short background:

1. There's no problem, if I'm using alternate WLAN (bridge) access point (AP) connected directly to the ZyXEL using Ethernet.

2. All other devices work perfectly on Ethernet with IPv6.

3. Even the same end devices on alternate AP on same network or Ethernet work perfectly using IPv6.

4. Link-local addresses (IPv6) and public IPv6 address traffic does work without problems to devices on LAN from WLAN.

5. This is just to make clear, that the problem is NOT my 6rd encapsulation, forwarding of firewalls.

Problematic network route:

1. IPv6 end device on WLAN (tablet, phone, laptop)

2. ZyXEL WLAN access point (IPv6 link-local address) -> Ethernet port (via switch)

3. Linux server on Ethernet port, doing 6rd (6in4) encapsulation

4. ZyXEL Ethernet port (IPv4, via NAT) -> WAN

Route 1-4 is reversed for return traffic. And if, 1 and 2 are connected using Ethernet, instead of WLAN, there's no problem. Or if I use alternate WLAN AP on ZyXEL's Ethernet port.

Assumed problem scenarios:

1. Packet routes from WLAN cause some kind of internal collision, buffer space or timing mess up on ZyXEL causing packet loss.

2. ZyXEL processes the traffic as multicast traffic same technically for WiFI as broadcast traffic for some strange reason, and rate limits it on WiFi due packing it in Beacon frames with Delivery Traffic Indication Messages (DTIM).

Only thing I still think I could test, is replicating the same packet flow using IPv4 alone. Where traffic is just bounced by the Linux server. It would tell me if the internal collision scenario is potentially true.

Any pro-tips? AFAIK, this is something I can't really solve without ZyXEL support. Another obvious solution would be just replacing the router with something better.

Posted to official ZyXEL support forum.

Random straddling before coming to conclusions of the summary part

I've configured and automatically scripted 6rd tunnel setup, using external ip fetch and automatic configuration of radvd using Linux (Ubuntu) router. I have earlier used 6to4, 6in4 and 6rd with ZyXEL USG 50. As well as ZyXEL has fixed a few bugs I've found in it's firmware earlier.

After all tuning everything's fine, except there's one really strange issue. I guess someone knows the answer instantly, and recognizes the problem. But I don't know what's causing it. Here's list of test and results I've done.

First of all, everything works perfectly when using wired interface, this also includes test devices which can be either wired or using wlan. So it's not about the end device it self.

1. LAN IPv6 traffic works perfectly with every device to every destination

2. WLAN IPv6 traffic works normally to link local addresses (including the router box !) as well as other on-link addresses (including global address scope)

3. Routed WLAN IPv6 traffic is slow as ... With extreme packet loss... Why? I really don't get it. With both 2.4 GHz and 5 GHz devices. Speed is less than 1% of normal operating speed.

4. MTU has been set to 1280 just to make sure this shoudln't be a MTU issue.

5. All IPv6 features are disabled on the box, except IPv6 link-local address, which can't be disabled. Anyway, this shouldn't matter.

Does anyone have idea what's causing this? Only thing I can quickly think of is some strange feature on the WLAN box?

I'm continuing to troubleshoot this by checking neighbour discovery messages and re-transmissions on protocol level. But still I'm baffled what the problem actually is.

Continued about two weeks later, because I had more pressing issues to deal with. This is just mentally very great annoyance, because I really want to know what's causing the problem.

Anyway, to make straddling easier, I've decided to try exactly same setup with alternate brand AP (without any IPv6 support) just to make sure, if this is about the ZyXEL or not.

Today I reminded myself about the problem. On LAN (same network as the WLAN) everything works perfectly IPv4 & IPv6. On WiFi, IPv6 Internet access is dead slow. FYI, Link link local sftp access to the router up / down, works normally (LAN & WLAN). So that's not the problem. I also tested local traffic with ULA instead of link-local addresses and everything works as expected, as long as there's no 6rd encapsulation and forwarding to Internet.

On top of that, I collected tcpdump data on the PC (router) which handles IPv6 encapsulation, radvd and routing (forwarding). I can see incoming IPv6 traffic on LAN and outgoing IPv4 traffic (encapsulated IPv6 protocol 41) and reversed of course. It does indicate the problem, I mentioned already, extreme packet loss, on tunneling, but I still don't know why.

I've published that detailed tcpdump data to selected experts. Yet as mentioned, it only confirmed the packet loss and almost never ending tcp re-transmissions -> slow progress, as I've mentioned.

I'll get back to this matter, when I'm done testing with alternate IPv4 router / WLAN AP and or mixing and matching the IPv4 routing / NAT and WLAN AP features, from different devices. It shouldn't make any difference of course, but this is already so strange, I really don't know what to expect.

Now I'm kind of surprised and happy. Because today I tested what I promised. I just connected old crappy D-Link WLAN box (bridged) to the Zyxel Ethernet port and guess what... IPv6 works over WLAN works totally flawlessly. So it's the ZyXEL after all.

I wasn't sure what to expect from this test, but this kind of proves the point that the Zyxel WLAN (WiFi) is somehow screwed up. Next question of course is, WHY? Maybe it processes the IPv6 traffic as broadcast flood or something like that?

Legacy stuff

One more point, sometimes when configuring the sit tunnels and network interfaces, I do get "no buffer space available". But that seems to be some generic error message, and nobody seems to know what it means. But maybe just maybe, the WLAN traffic is "bit more bursty" and requires buffer space, which the extremely stable LAN traffic does (?). I have had this kind of problems during the modem / UART times, when flow control failed. Without compression everything worked, but with compression came super slow, because compression caused bursts which caused data loss due lack of buffer space. - Yeah, totally off-topic legacy stuff. But I decided to mention this, if this would have something to do with the problem, even if it sounds unlikely.

2018-12-03