USG3 geen offloading met KPN glasvezel voor IPv6

[lenwar]

Mijn vraag
Ik zit al enige tijd te rommelen met IPv6 van KPN glasvezel. Op een één of andere manier wil mijn USG3 geen hardware offloading doen voor IPv6.

Er is heel veel te vinden op internet, die dit onderwerp al dan niet deels raken, maar ik kom er maar niet uit.

Edit: Wat ik dus probeer te bereiken, is dat ik via IPv6 een ongeveer gelijke snelheid haal als met IPv4.

...

Relevante software en hardware die ik gebruik
- Ik heb mijn USG dus direct op de mediaconverter van KPN aangesloten. (ik gebruik dus niet de KPN router). De router zet dus een PPPoE-verbinding richting KPN en gebruikt VLAN 6.
- Ik gebruik geen IPTV
- Ik heb IPS/IDS / DPI / Smart queueing allemaal uitgeschakeld
- Ik heb in m'n LAN een x-aantal vlans/subnets (netwerksegmenten of 'Networks' in de Unifi UI)
Edit:
- Ik heb alle netwerksegmenten dual-stack gemaakt. Ik probeer dus niet IPv4 over IPv6 of andersom te doen. Gewoon dual-stack over m'n hele netwerk heen.

code:

show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down

Interface    IP Address                        S/L  Description
---------    ----------                        ---  -----------
eth0         -                                 u/u  WAN
eth0.6       -                                 u/u  WAN
eth1         192.168.xxx.1/24                  u/u  LAN
             2a02:xxxx:xxxx:1::/64
eth1.20      192.168.xxx.1/24                  u/u
             2a02:xxxx:xxxx:ff::/64
eth1.25      192.168.xxx.1/24                  u/u
             2a02:xxxx:xxxx:aa::/64
eth1.600     192.168.xxx.1/29                  u/u
             2a02:xxxx:xxxx:ac::/64
eth1.608     192.168.xxx.9/29                  u/u
             2a02:xxxx:xxxx:ae::/64
eth1.616     192.168.xxx.17/29                 u/u
             2a02:xxxx:xxxx:ab::/64
eth1.624     192.168.xxx.25/29                 u/u
             2a02:xxxx:xxxx:ad::/64
eth1.632     192.168.xxx.33/27                 u/u
             2a02:xxxx:xxxx:af::/64
eth1.4000    10.40.xxx.1/24                    u/u
eth2         -                                 A/D
lo           127.0.0.1/8                       u/u
             ::1/128
pppoe2       77.xxx.xxx.205                    u/u
wg0          10.xxx.xxx.1/24                   u/u

Ik heb offloading op verschillende manieren geprobeerd: (tussendoor ook de boel herstart). Op het moment staat hij als volgt:

code:

admin@Router# show system offload
 ipsec enable
 ipv4 {
     forwarding enable
     gre enable
     pppoe enable
     vlan enable
 }
 ipv6 {
     forwarding enable
     pppoe disable
     vlan enable
 }

Wat ik ondervind is dat als ik via IPv4 iets download gaat alles 'normaal', maar als ik hetzelfde download via IPv6 dan raakt de CPU overbelast en stagneert de doorvoersnelheid dus ook op ongeveer 100Mbit.

code:

pi@unificontroller:~ $ curl -4 -L http://speedtest.tele2.net/1GB.zip -O /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 69 1024M   69  709M    0     0  36.2M      0  0:00:28  0:00:19  0:00:09 39.4M^C
pi@unificontroller:~ $ curl -6 -L http://speedtest.tele2.net/1GB.zip -O /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 16 1024M   16  173M    0     0  12.6M      0  0:01:20  0:00:13  0:01:07 12.2M^C

Op de USG ziet dat er zo uit met IPv6 (je ziet dus dat de soft SoftIRQ en Kernel worker kernel processen m'n CPU-cycles opeten. Een totaal van 98.1% software interrupts waar hij dus 'wacht' op m'n CPU). Met IPv4 is dit niet het geval. Als ik dan de 1Gbit 'voltrek' dan heeft hij een belasting van ongeveer 30% zo uit m'n hoofd, en dan is de Avahi-daemon erg druk bezig. Dit lijkt het normale gedrag te zijn:

code:

top - 09:28:10 up 16:08,  2 users,  load average: 2.67, 0.70, 0.42
Tasks: 111 total,   5 running, 106 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.8 us,  1.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi, 98.1 si,  0.0 st
KiB Mem:    495520 total,   411108 used,    84412 free,    29964 buffers
KiB Swap:        0 total,        0 used,        0 free,   230828 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 8673 root      20   0     0    0    0 S  15.3  0.0   0:01.14 kworker/0:3
   13 root      20   0     0    0    0 R  14.9  0.0   2:26.83 rcuc/1
    3 root      20   0     0    0    0 R  14.4  0.0   8:26.33 ksoftirqd/0
   15 root      20   0     0    0    0 S  13.1  0.0   6:48.33 ksoftirqd/1
11359 root      20   0     0    0    0 S  12.0  0.0   0:01.01 kworker/1:1
  673 root      20   0  134m  16m 3564 S  11.3  3.4   9:03.90 ubnt-util
   10 root      20   0     0    0    0 R  10.9  0.0   3:02.45 rcuc/0
10420 root      20   0     0    0    0 S   9.5  0.0   0:00.74 kworker/0:4
  643 root      20   0  1952  280  220 S   9.1  0.1   1:30.47 rngd
    9 root      20   0     0    0    0 R   8.0  0.0   2:25.49 rcu_sched
 6370 root      20   0     0    0    0 S   8.0  0.0   0:18.48 kworker/1:2
 8494 root      20   0     0    0    0 S   8.0  0.0   0:01.67 kworker/1:4
11198 root      20   0     0    0    0 S   7.3  0.0   0:00.86 kworker/0:0
 4429 admin     20   0 11636 1444  884 S   6.0  0.3   0:04.14 sshd
18805 www-data  20   0  6252 1412  768 S   5.1  0.3   0:16.61 lighttpd
11358 root      20   0  3788 1460 1008 R   4.7  0.3   0:01.14 top

...

Wat ik al gevonden of geprobeerd heb
...
Bovenstaande geeft al redelijk aan wat ik allemaal heb geprobeerd. Ik heb hardware offloading voor IPv6 ook op pppoe enabled en vlan disabled (schijnbaar kunnen ze niet allebei enabled staan). Ik heb ook IPSec offloading uitgezet gehad (ik gebruik het niet, maar het werd ergens gesuggereerd)


Iedere suggestie is welkom

Edit. Ik heb m'n vraag/probleem verder verduidelijkt naar aanleiding van de eerste reacties.

[ Voor 6% gewijzigd door lenwar op 28-12-2021 13:26 . Reden: Typos in IPv6 adressen en vraag verder verduidelijkt ]

[Frogmen]

Ik denk dat je eerst iets duidelijker moet omschrijven wat je wilt bereiken, volgens wil je in IP6 geen VLAN's meer (kan het wel?).

[pboelhouwer]

Frogmen schreef op dinsdag 28 december 2021 @ 09:48:
in IP6 geen VLAN's meer (kan het wel?).

https://datatracker.ietf.org/doc/html/rfc4554

[Frogmen]

@pboelhouwer Interessante link maar als ik het kort door de bocht lees kent IP6 geen VLAN. Het document legt alleen uit hoe en wat in een gemixte enterprise environment waarin niet alle apparaten IP6 kunnen gebruiken. Krijg hier sterk het idee dat de TS IP4 naar IP6 wil routeren, maar is niet echt helder.

[lenwar]

Excuus dat het niet duidelijk was.
Wat ik wil bereiken is dat ik offloading kan gebruiken voor IPv6.

Ik heb mijn ipv6 /48 netwerk in losse /64 ‘stukjes’ gesegmenteerd en die gekoppeld aan m’n ‘networks’ zoals gedefinieerd in de UniFi controller.

Het doel hiervan is, is dat de individuele netwerken gescheiden zijn (middels firewalls - bijvoorbeeld iot netwerken en het primair netwerk)

Zoals je kan zien in m’n op heeft bijvoorbeeld de virtuele nic eth1.25:
IPv4: 192.168.xxx.1/24
IPv6: 2a02:xxxx:xxxx:aa::/64

(Waar t/m xxxx m’n /48 netwerk is en :aa: het ipv6 segment)

Als ik vanuit een node via IPv4 een bestand download gaat alles goed, en vanaf diezelfde node via IPv6 hetzelfde bestand download, wilt offloading niet.
(Zie de curl-commando’s in de op)

[jvanhambelgium]

Ik kan tientallen postings vinden van USG3 + IPv6 + "slow"
Ik denk dat dit kastje gewoon geen offloading zal doen op IPv6, ever.

https://evanmccann.net/blog/unifi-routers-overview#fnr2

USG HARDWARE OFFLOADING

Ubiquiti Unifi Security Gateway (USG)

If you google for USG throughput issues, a lot of them refer to features that can’t be offloaded, or hardware-accelerated. Hardware offloading is used to execute functions using hardware instead of software, which makes the general purpose CPU do all the work. The benefit of offloading is increased speed and throughput, by not depending on the CPU for forwarding decisions. The problem is that not all features can be offloaded. This EdgeRouter help page explains this in more detail.

A lot of networking gear, including the USG, has specialized chips that accelerate basic network processes like routing decisions. The USG can handle routing gigabit connections with hardware offload enabled. The USG and USG-Pro have IPv4 forwarding, NAT, VLAN, GRE, PPPOE and limited IPSec offloading. Unfortunately, they lack QoS or IDS/IPS acceleration hardware. Because of that, hardware offloading must be disabled to enable those features.

Typically, routers can quickly look at a packet header and make a routing decision based on that. Enabling QoS and IPS/IDS complicates that. IPS is computationally intensive because the router has to inspect the contents of every packet for arbitrary patterns, not just the packet headers. To do this with hardware you need an expensive proprietary ASIC, like those made by Fortinet. Ubiquiti's bread and butter is making the most with their software on commodity hardware, and selling it for a good price. If you are looking for multi-gigabit IPS firewall performance, there are other vendors for that.

With offloading turned off, the general purpose CPU in the USG has to do extra calculations, bringing performance down to around 300 Mbps. If you also turn on QoS, the routing becomes more complicated, and performance suffers further. When you turn on IPS/IDS the USG has to inspect and process every packet, which brings throughput down to around 85 Mbps. Enabling these features will affect all processes on the USG, including inter-VLAN routing speed, unless you have a separate layer 3 switch. The USG doesn’t have a built-in switching ASIC, but some EdgeRouter models do.

[lenwar]

jvanhambelgium schreef op dinsdag 28 december 2021 @ 14:08:
Ik kan tientallen postings vinden van USG3 + IPv6 + "slow"
Ik denk dat dit kastje gewoon geen offloading zal doen op IPv6, ever.

Zoals ik inderdaad al in m'n op schreef is er heel veel te vinden, en er zijn zat mensen die het voor elkaar (zeggen te) hebben.

Nou ben ik uiteraard zelf ook nog verder gegaan, en het lijkt er inderdaad op dat het een hardwarebeperking is, en dat ik niet voor elkaar ga krijgen wat ik wil/nodig heb.

Ik heb bij wijze van test een losse pi geïnstalleerd en die in m'n 'native lan' gezet. (dus die is gekoppeld aan eth1). Als ik dan de offloading aan zet voor IPv6-pppoe, dan doet hij precies wat hij moet doen. Ik heb echter m'n netwerk gesegmenteerd, en dan moet hij dus offloading van 'vlan' doen voor verkeer binnen m'n netwerk, maar ook richting internet (want hij gaat van netwerksegment 'eth1.25' naar 'eth1' aan de LAN-kant)

Die twee kan de USG3 helaas niet combineren voor IPv6. (wel voor IPv4).
Het is voor IPv6 dus, of offloaden tussen netwerksegmenten, of offloaden naar/van pppoe. Hij ondersteund niet beiden tegelijk:

admin@Router# set system offload ipv6 vlan enable
IPv6 pppoe must be disabled for vlan offload

Ik vermoed dat de mensen die het dus voor elkaar hebben een andere ISP hebben (die dus niet met pppoe werken op een bepaald netwerksegment/VLAN, en/of zelf in hun eigen netwerk geen netwerksegementen/VLANs gebruiken)


Ik zie dat ik nu dus eindelijk een usecase heb om m'n USG3 te vervangen met een UDM-Pro (SE). Maar tot die tijd gaat IPv6 dus uit.


Bedankt voor het meedenken in elk geval!!