La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la Bbox par un routeur => Discussion démarrée par: wobble le 19 février 2025 à 03:22:35
-
Hello tout le monde,
Après avoir beaucoup cherché comment remplacer la box, voici mon retour d'expérience.
Je suis client Bbox Pure Fibre avec option Débit+ (8G/1G). Tout d'abord, j'ai demandé l'ONT externe au support, ça s'est fait très simplement sans facturation supplémentaire.
Ensuite, j'ai cherché un routeur 10G à un prix raisonnable (https://lafibre.info/routeur/routeur-10gbps-a-moins-de-500/). J'ai choisi un iKOOLCORE R2 Max (https://www.ikoolcore.com/products/ikoolcore-r2-max) dont on peut retrouver des tests sur ServeTheHome (https://www.servethehome.com/ikoolcore-r2-max-dual-10gbase-t-2-5gbe-mini-pc-intel-marvell-hands-on/) et ici (https://www.cnx-software.com/2024/12/17/ikoolcore-r2-max-review-10gbe-on-an-intel-n100-mini-pc-with-openwrt-qwrt-proxmox-ve-ubuntu-24-04-and-pfsense-2-7-2/). J'ai pris la version avec CPU Intel N100 et refroidissement passif, le tout avec 8 Go de RAM et SSD de 128 Go, le minimum. J'en ai eu pour environ 340 €. La particularité de ce mini-PC (ou l'inconvénient diront certains) est qu'il n'a pas de SFP mais directement du RJ45, ce qui me convenait bien. Les interfaces 10G sont des Marvell Aquantia AQC113C qui ne sont pour l'instant pas supportées sous FreeBSD (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282805) donc pas d'OPNsense ou de pfSense possible sans passer par de la virtualisation (beurk).
Ce n'était pas un problème dans mon cas puisque je voulais une machine Linux pour bien comprendre ce que je faisais. J'ai installé Debian 13 Trixie qui n'est pas encore stable mais je voulais éviter un upgrade dans quelques mois.
Presque toute la configuration réseau est faite avec SystemD Networkd (sauf le DNS et le DHCPv4 qui sont gérés par Dnsmasq, bien que systemd-networkd puisse aussi faire serveur DHCPv4 (https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#%5BDHCPServer%5D%20Section%20Options)). Je ne détaille pas la configuration Dnsmasq, elle n'a pas grand intérêt.
Merci à kgersen pour son aide sur ce topic (https://lafibre.info/remplacer-bbox/ipv6-sur-debian/). Le fait que l'adresse IPv6 globale du routeur soit portée par la patte LAN était un peu déstabilisant pour moi au début mais ça fonctionne très bien comme ça :)
Voici la configuration présente dans /etc/systemd/network. À noter que Debian 13 utilise SystemD version 257.
=== 10-lan0.link ===
[Match]
MACAddress=xx:xx:xx:xx:xx:xx
[Link]
Name=lan0
=== 10-lan0.network ===
[Match]
Name=lan0
[Network]
Bridge=lan
=== 10-lan1.link ===
[Match]
MACAddress=xx:xx:xx:xx:xx:xx
[Link]
Name=lan1
=== 10-lan1.network ===
[Match]
Name=lan1
[Network]
Bridge=lan
=== 10-lan2.link ===
[Match]
MACAddress=xx:xx:xx:xx:xx:xx
[Link]
Name=lan2
=== 10-lan2.network ===
[Match]
Name=lan2
[Network]
Bridge=lan
=== 10-lan.netdev ===
[NetDev]
Name=lan
Kind=bridge
=== 10-lan.network ===
[Match]
Name=lan
[Network]
Address=192.168.1.254/24
IPv4Forwarding=yes
# Voir aussi https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#IPv6Forwarding=
# "To ensure IPv6 packets forwarded, the global setting in networkd.conf(5) needs to be enabled."
IPv6Forwarding=yes
DHCPPrefixDelegation=yes
IPv6SendRA=yes
[DHCPPrefixDelegation]
UplinkInterface=wan
# Détermine les derniers octets de l'IP de l'interface
Token=::ffff
# Détermine les premiers octets de l'IP de l'interface
SubnetId=0xf
=== 10-wan0.link ===
[Match]
MACAddress=xx:xx:xx:xx:xx:xx
[Link]
Name=wan0
=== 10-wan0.network ===
[Match]
Name=wan0
[Network]
VLAN=wan
# Désactivation de l'autoconfiguration IPv6 de l'interface physique WAN, sinon
# elle reste en état "configuring" et bloque systemd-networkd-wait-online
LinkLocalAddressing=no
=== 10-wan.netdev ===
[NetDev]
Name=wan
Kind=vlan
# Ici, je clone la MAC de la Bbox, même si ça ne semble pas strictement nécessaire
MACAddress=xx:xx:xx:xx:xx:xx
[VLAN]
Id=100
=== 10-wan.network ===
[Match]
Name=wan
[Network]
IPv4Forwarding=yes
IPv6Forwarding=yes
IPv6AcceptRA=yes
DHCP=yes
[DHCPv6]
# Ne pas envoyer IA_NA
UseAddress=no
WithoutRA=solicit
DUIDType=link-layer
PrefixDelegationHint=::/64
IAID=1
Pour que la machine reçoive un préfixe en DHCPv6, il semble qu'il faille parfois attendre plusieurs dizaines de minutes voire plusieurs heures après le débranchement de la Bbox, même en clonant sa MAC. Le routeur Bouygues répond quelque chose comme "no prefixes available" pendant un bon moment (ça se voit avec tcpdump -vvv -ni wan ip6 and udp and port 546). Une fois que ça fonctionne, on est tranquille et ça ne retombe pas (enfin tant qu'on ne remet pas la Bbox, j'imagine). Il ne faut pas hésiter à tester avec https://github.com/kgersen/testdhcpv6pd/ aussi, ça dépanne bien.
J'ai renommé les 4 interfaces physiques en lan0 à lan2 et wan0 pour rendre les choses plus lisibles. À noter qu'il semble nécessaire de rebooter pour que le renommage prenne effet.
On a donc 6 interfaces au total. 4 côté LAN : lan0 à lan2 font partie du bridge lan :
# brctl show
bridge name bridge id STP enabled interfaces
lan 8000.xxxxxxxxxxxx no lan0
lan1
lan2
Et, côté WAN, on a l'interface physique wan0 sur laquelle repose l'interface VLAN wan.
Côté pare-feu, la configuration minimale à mettre dans /etc/nftables.conf est la suivante :
#!/usr/sbin/nft -f
flush ruleset
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related accept
ip protocol icmp accept
iifname lan accept
iifname lo accept
}
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
iifname lan oifname wan accept comment "trafic du LAN vers le WAN"
}
chain output {
type filter hook output priority filter; policy accept;
}
}
table ip nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
iifname lan oifname wan masquerade comment "source NAT en sortie sur le WAN"
}
}
table ip6 filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related accept
iifname wan ip6 daddr fe80::/64 udp sport 547 udp dport 546 ct state new accept comment "DHCPv6"
meta l4proto ipv6-icmp accept
iifname lan accept
iifname lo accept
}
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
iifname lan oifname wan accept comment "trafic du LAN vers le WAN"
}
}
Attention à bien ajouter cette directive dans /etc/systemd/networkd.conf pour que le forwarding fonctionne en IPv6 !
[Network]
# Nécessaire seulement pour l'IPv6, voir
# https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#IPv6Forwarding=
IPv6Forwarding=yes
Et voilà, c'est tout ! Je n'ai mis aucun sysctl à la main, j'ai laissé SystemD Networkd les gérer, ça permet d'avoir toute la configuration à un seul endroit.
Je suis très content du résultat, notamment car le routeur reboote en moins de 30 secondes. J'ai fait des tests de débit derrière le routeur en IPv4 (donc avec NAT) et le CPU et les cartes réseau semblent tenir la route et être en permanence autour de 50 °C, même quand j'atteins 6 ou 7 Gbit/s.
Le seul cas où un cœur du CPU sature est quand je dépasse les 6 Gbit/s sur une seule session TCP (quand Bouygues ne décide pas de me couper l'IPv4 (https://lafibre.info/bbox-les-news/erreur-c1-sur-bbox-bouygues-offre-bbox-pure/msg1106690/#msg1106690)). Mais, dès que je multiplie les sessions, par exemple dès iperf3 -P3, les 4 cœurs se répartissent la charge et il n'y a plus de saturation. Même quand un des cœurs est à fond, il ne chauffe pas plus que d'habitude. Par contre on voit le compteur dropped de wan0 augmenter, j'imagine que ce n'est pas idéal. Quand je bride avec iperf3, je vois que les dropped commencent à arriver autour de -b 5.98G (rien à 5.9G). Dans tous les cas, je pense que ça ne se remarquera pas à l'usage.
N'hésitez pas si vous avez des questions ou des remarques sur la config !
EDIT du 20 février 2025 : j'ai enlevé la règle pour autoriser le DHCPv4, elle ne matche pas, le client utilisant des raw sockets, voir https://kb.isc.org/docs/aa-00378 pour un autre client DHCP.
On peut voir ça dans les logs de debug de NetworkD :
# systemctl service-log-level systemd-networkd.service debug
# networkctl reload
# networkctl reconfigure wan
# journalctl -u systemd-networkd -S -10min --grep raw
Feb 20 18:46:37 localhost systemd-networkd[464]: wan: DHCPv4 client: Received message from RAW socket, processing.
Feb 20 18:46:37 localhost systemd-networkd[464]: wan: DHCPv4 client: Received message from RAW socket, processing.
On peut capturer le trafic avec une règles de firewall de ce genre-là mais le drop n'a aucun effet :
table inet raw {
chain prerouting {
type filter hook prerouting priority raw; policy accept;
iifname wan udp sport 67 udp dport 68 nftrace set 1
iifname wan udp sport 67 udp dport 68 drop
}
}
Voici la sortie de nft monitor qui montre bien un drop (mais NetworkD reçoit quand même le trafic) :
trace id 8a51b000 inet raw prerouting packet: iif "wan" ether saddr xx:xx:xx:xx:xx:xx ether daddr xx:xx:xx:xx:xx:xx ip saddr xx.xx.xx.xx ip daddr xx.xx.xx.xx.xx ip dscp cs6 ip ecn not-ect ip ttl 64 ip id 35120 ip protocol udp ip length 362 udp sport 67 udp dport 68 udp length 342 udp checksum 63469
trace id 8a51b000 inet raw prerouting rule iifname "wan" udp sport 67 udp dport 68 meta nftrace set 1 (verdict continue)
trace id 8a51b000 inet raw prerouting rule iifname "wan" udp sport 67 udp dport 68 drop (verdict drop)
Edit du 17 avril 2025 : on peut ajouter de l'offload logiciel (https://lafibre.info/remplacer-bbox/retour-dexperience-ont-externe-debian-sur-ikoolcore-r2-max-2x10g-2x2-5g/msg1107289/#msg1107289) pour les sessions déjà établies à nftables.conf, mais je déconseille de le faire. Lorsqu'on atteint un gros débit sur une seule connexion, ça sature systématiquement un seul cœur (https://lafibre.info/remplacer-bbox/retour-dexperience-ont-externe-debian-sur-ikoolcore-r2-max-2x10g-2x2-5g/msg1107437/#msg1107437), chose qui semble se produire légèrement moins souvent quand l'offload est désactivé.
Ça pourrait être intéressant avec XDP mais xdp ne supporte pas encore les VLAN (https://github.com/xdp-project/xdp-tools/issues/488).
-
merci du tuto.
as-tu tenté avec openwrt ? il a peut-etre des opti "fastpath" avec les cartes Marvell Aquantia AQC113C (je n'ai pas chercher) ? bon après 6Gbps mono session pour 350€ c'est bien deja.
-
Je croyais qu'OpenWRT de base ne contenait pas le module kernel atlantic utilisé par les cartes 10G donc je n'avais pas testé.
# lspci -nnkd ::200
01:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
Subsystem: Intel Corporation Device [8086:0000]
Kernel driver in use: igc
Kernel modules: igc
02:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
Subsystem: Intel Corporation Device [8086:0000]
Kernel driver in use: igc
Kernel modules: igc
07:00.0 Ethernet controller [0200]: Aquantia Corp. AQC113C NBase-T/IEEE 802.3an Ethernet Controller [Marvell Scalable mGig] [1d6a:14c0] (rev 03)
Subsystem: Aquantia Corp. Device [1d6a:0001]
Kernel driver in use: atlantic
Kernel modules: atlantic
08:00.0 Ethernet controller [0200]: Aquantia Corp. AQC113C NBase-T/IEEE 802.3an Ethernet Controller [Marvell Scalable mGig] [1d6a:14c0] (rev 03)
Subsystem: Aquantia Corp. Device [1d6a:0001]
Kernel driver in use: atlantic
Kernel modules: atlantic
On dirait que ça a changé depuis la dernière fois que j'ai vérifié puisque https://github.com/openwrt/openwrt/issues/8727#issuecomment-2632376623 a été fermée. En creusant un peu, on dirait que c'était déjà supporté depuis v23.05.0 : https://github.com/openwrt/openwrt/commit/d02e887d7ceb25008fa70c42174207dfeb65b5f0 (voir aussi https://github.com/openwrt/openwrt/pull/10522). On retrouve bien le driver sur https://archive.openwrt.org/releases/24.10.0/targets/x86/64/kmods/6.6.73-1-a21259e4f338051d27a6443a3a7f7f1f/kmod-atlantic_6.6.73-r1_x86_64.ipk aussi.
Sur https://dl.ikoolcore.com/OpenWrt%20Firmware/R2Max, il y a aussi des images d'un fork chinois qui s'appelle QWRT. C'est ce que le testeur a installé pour https://www.cnx-software.com/2024/12/17/ikoolcore-r2-max-review-10gbe-on-an-intel-n100-mini-pc-with-openwrt-qwrt-proxmox-ve-ubuntu-24-04-and-pfsense-2-7-2/
C'est bien comme OS, OpenWRT ? Je n'ai jamais utilisé. Tu sais où on pourrait trouver l'info sur cette histoire de fastpath ? Il y a une chance que ça arrive un jour dans Linux ?
Avec le recul, je me dis que j'aurais pu prendre le CPU N150 ou N355, mais j'avais peur que le refroidissement passif ne suffise pas. Dans tous les cas, en utilisation réelle, je ne dépasse que rarement 2 Gbit/s donc je pense que je peux vivre avec les limites de ce routeur.
-
C'est bien comme OS, OpenWRT ? Je n'ai jamais utilisé. Tu sais où on pourrait trouver l'info sur cette histoire de fastpath ? Il y a une chance que ça arrive un jour dans Linux ?
openwrt c'est du Linux (minimalist) avec une couche interface web(appelé Luci) et une couche interface ligne de commande (appelé uci) au dessus.
"en gros", uci est un peu comme systemd sur une distrib classique.
le gros avantage c'est son interface web (luci donc) pour le configurer et le fait de pouvoir sauvegarder la config via un ensemble de fichiers uci.
en jargon openwrt on parle d'offload' (hardware ou software) plutot que fastpath (c'est a peu pres la meme chose). je n'ai jamais pris le temps de regarder en detail comment c'était mis en oeuvre:
le software offload marche sur tous les appareils (il me semble que c'est du "Netfilter flowtable (https://docs.kernel.org/networking/nf_flowtable.html)" donc faisable sur n'importe quel Linux)
le hardware offload requiert un matériel compatible.
je n'ai jamais regardé cela pour une distrib Linux standard , mais y'a sans doute des trucs possibles à faire avec Netfilter, en s'inspirant peut-être de ce que fait OpenWrt.
-
Du coup, ça serait Netfilter qui sature le CPU à cause des règles de NAT ou de forward ? Donc, en théorie, si je mets une machine en IPv6 pour ne pas avoir de NAT et que je vire nftables, je n'aurais pas de problèmes de performance ? Ça se teste facilement.
Je pensais que c'était juste le routage des paquets qui créait la saturation.
-
Tout d'abord, j'ai demandé l'ONT externe au support, ça s'est fait très simplement sans facturation supplémentaire.
Salut wobble,
Qu'est-ce que bouygues t'a donné comme ONT externe ?
-
Salut wobble,
Qu'est-ce que bouygues t'a donné comme ONT externe ?
Hello, c'est un Nokia XS-010X-Q, j'ai mis des photos là (https://lafibre.info/bbox-les-news/bouygues-telecom-lance-une-offre-fibre-8-gbs-a-23-99-par-mois/msg1103540/?topicseen#msg1103540).
-
"en gros", uci est un peu comme systemd sur une distrib classique.
Je pense que la comparaison est mal choisie. Il me semble que UCI (https://openwrt.org/docs/techref/uci) est essentiellement un utilitaire permettant de manipuler la configuration.
Voir aussi : OpenWrt – operating system architecture (https://openwrt.org/docs/techref/architecture).
[17:10]
Et les utilisateurs peuvent aussi modifier si nécessaire les sources des composants du système (correctifs + extensions). Ce n'est sûrement pas ce qu'on fait dans une distribution classique.
-
Du coup, ça serait Netfilter qui sature le CPU à cause des règles de NAT ou de forward ? Donc, en théorie, si je mets une machine en IPv6 pour ne pas avoir de NAT et que je vire nftables, je n'aurais pas de problèmes de performance ? Ça se teste facilement.
Je pensais que c'était juste le routage des paquets qui créait la saturation.
Les 2: routage (forwarding) et NAT consomment du cpu. NAT un plus que le routage vu que NAT inclut aussi du forwarding.
NAT a besoin de nftable/iptables, le routing c'est directement dans le kernel.
Tu peux tenter de virer nftables/iptables pour voir. si t'avais pas de regles je ne suis pas certain que ca impactera plus.
-
Je pense que la comparaison est mal choisie. Il me semble que UCI (https://openwrt.org/docs/techref/uci) est essentiellement un utilitaire permettant de manipuler la configuration.
Voir aussi : OpenWrt – operating system architecture (https://openwrt.org/docs/techref/architecture).
[17:10]
Et les utilisateurs peuvent aussi modifier si nécessaire les sources des composants du système (correctifs + extensions). Ce n'est sûrement pas ce qu'on fait dans une distribution classique.
d'ou le "un peu comme" ;)
"sans regarder de trop pres", les 2 (uci et systemd) sont des systèmes pour configurer l'OS en utilisant des fichiers textes de configuration (les fichiers de config d'openwrt, dans /etc/config sont des UCI files, uci ce n'est pas que l'utilitaire mais aussi les fichiers). mais systemd est plus complexe et va plus loin.
Un auteur de paquet ou d'un logiciel peut le rendre compatible avec uci pour sa configuration. mais tous ne le font pas.
Tout comme un auteur de logiciel peux fournir les elements pour l'installer avec systemd ou pas.
apres c'est sur que la comparaison s'arrete assez vite.
-
Comme indiqué dans la page du wiki d'OpenWRT (https://openwrt.org/docs/guide-user/perf_and_log/flow_offloading), cela n'est pas compatible avec la modification de la priorité des paquets IGMP qui est nécessaire pour la TV et donc activer l'option revient à faire une croix sur la TV.
En outre, sans l'avoir testé, le module atlantic est bien disponible (https://downloads.openwrt.org/releases/24.10.0/targets/x86/64/kmods/6.6.73-1-a21259e4f338051d27a6443a3a7f7f1f/).
-
En outre, sans l'avoir testé, le module atlantic est bien disponible (https://downloads.openwrt.org/releases/24.10.0/targets/x86/64/kmods/6.6.73-1-a21259e4f338051d27a6443a3a7f7f1f/).
Oui, j'avais dû mal chercher la première fois. J'avais bien retrouvé le module finalement.
Comme indiqué dans la page du wiki d'OpenWRT (https://openwrt.org/docs/guide-user/perf_and_log/flow_offloading), cela n'est pas compatible avec la modification de la priorité des paquets IGMP qui est nécessaire pour la TV et donc activer l'option revient à faire une croix sur la TV.
Merci, j'ai suivi https://wiki.nftables.org/wiki-nftables/index.php/Flowtables et ajouté ça à ma conf nftables (table inet pour faire IPv4 et IPv6 d'un coup et matcher au plus tôt) :
table inet filter {
flowtable f {
hook ingress priority filter
devices = { lan0, lan1, lan2, wan0 } # Ne pas mettre devices = { lan, wan }, il faut indiquer les interfaces physiques
}
chain forward {
type filter hook forward priority filter; policy accept;
ct state established,related flow add @f comment "activation de l'offload sur les connexions établies"
}
}
À noter que flow offload fait la même chose, mais cette syntaxe est dépréciée en faveur de flow add (https://git.netfilter.org/nftables/commit/?id=4795a994e2810c63d8da19b5f75854db470e4a6c).
Dans /proc/net/nf_conntrack, au lieu de voir ça (on dirait qu'iperf3 ouvre deux ports pour chaque test) :
ipv4 2 tcp 6 431999 ESTABLISHED src=192.168.1.2 dst=x.x.x.x sport=58568 dport=5201 src=x.x.x.x dst=x.x.x.x sport=5201 dport=58568 [ASSURED] mark=0 zone=0 use=2
ipv4 2 tcp 6 300 ESTABLISHED src=192.168.1.2 dst=x.x.x.x sport=58584 dport=5201 src=x.x.x.x dst=x.x.x.x sport=5201 dport=58584 [ASSURED] mark=0 zone=0 use=7
J'ai maintenant ça :
ipv4 2 tcp 6 src=192.168.1.2 dst=x.x.x.x sport=58600 dport=5201 src=x.x.x.x dst=x.x.x.x sport=5201 dport=58600 [OFFLOAD] mark=0 zone=0 use=3
ipv4 2 tcp 6 src=192.168.1.2 dst=x.x.x.x sport=58596 dport=5201 src=x.x.x.x dst=x.x.x.x sport=5201 dport=58596 [OFFLOAD] mark=0 zone=0 use=3
Comme il n'est pas indiqué HW_OFFLOAD, c'est que l'offload n'est que logiciel. Pour activer l'offload matériel, il faut ajouter flags offload comme indiqué ici (https://docs.kernel.org/networking/nf_flowtable.html#hardware-offload).
Sans surprise, ça ne fonctionne pas chez moi, ça me renvoie Error: Could not process rule: Operation not supported. Apparemment seuls les drivers implémentant TC_SETUP_FT (https://lore.kernel.org/all/ZsOQCgbMuwsEo3zj@calendula/) supportent l'offload matériel. Ça ne semble donc être supporté que par les drivers Mellanox et MediaTek (https://github.com/search?q=repo%3Atorvalds%2Flinux%20TC_SETUP_FT&type=code)
Je pense que ça améliore légèrement les performances mais c'est difficile à mesurer.
J'ai aussi remarqué un truc intéressant : lors des tests, j'ai parfois un cœur à 100 % et les autres qui ne font rien. D'autres fois, j'ai un cœur à 80 % et l'autre à 30 ou 40 %. Ce comportement est le même avec et sans offload. J'imagine qu'il y a deux opérations lourdes à gérer et que, parfois, elles ne sont pas traitées par des cœurs différents.
Quand c'est réparti sur deux cœurs, je n'ai pas du tout de dropped à 7 Gbit/s, par exemple ici :
0[| 0.7% 700MHz 55°C] Tasks: 40, 35 thr, 94 kthr; 1 running
1[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||91.9%|3096MHz 55°C] Load average: 0.20 0.17 0.13
2[|||||||||||||||||||||||||||||||||| 34.5% 3099MHz 55°C] Uptime: 01:33:42
3[||||||| 6.3% 3099MHz 55°C]
Ou ici :
0[|| 2.0% 700MHz 59°C] Tasks: 42, 35 thr, 94 kthr; 1 running
1[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||82.0% 3394MHz 59°C] Load average: 0.42 0.29 0.18
2[||||||||||||||||||||||||||||||||||||||||| 41.1% 3385MHz 59°C] Uptime: 01:35:49
3[ 0.0% 700MHz 59°C]
Mais, d'autres fois, ça ressemble plus à ça, et là, il y a du dropped :
0[|| 1.3% 700MHz 57°C] Tasks: 39, 35 thr, 94 kthr; 2 running
1[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%|3092MHz|57°C] Load average: 0.21 0.30 0.22
2[||| 2.0% 3098MHz 57°C] Uptime: 01:40:43
3[||| 2.1% 3097MHz 57°C]
Je pense que le cpufreq governor powersave n'est pas forcément idéal non plus pour avoir le maximum de performance (en même temps, c'est dans le nom). On voit que les cœurs ne montent pas toujours à 3.4 Ghz.
Dans tous les cas, je vais garder la flowtable, je pense que ça ne peut pas faire de mal.
EDIT : même avec cpupower frequency-set -g performance, le comportement semble rester le même, les cœurs ne sont pas à fond (c'est le seul autre governor supporté : "available cpufreq governors: performance powersave").
-
J'ai fait tourner ça pour comparer les débits avec et sans offload :
for i in {1..4}; do
iperf3 -c serveur -R -t 30
sleep 10
done
sleep 30
ssh routeur nft delete table inet filter
for i in {1..4}; do
iperf3 -c serveur -R -t 30
sleep 10
done
On a donc 4 tests avec offload séparés de 10 secondes, 30 secondes de pause puis 4 tests sans.
Je joins les graphes d'utilisation de chaque cœur, fréquence de chaque cœur et débit + dropped. Franchement, je ne suis pas certain que ça soit pertinent de conserver l'offload.
-
effectivement si ca n'apporte rien autant ne pas l'activer...
mais 2 points:
ton "lan" est un bridge on dirait dans ce cas il faut ajouter les interfaces physiques dans ta flowtable ( https://docs.kernel.org/networking/nf_flowtable.html#bridge-and-ip-forwarding )
If you would like that your flowtable defines a fastpath between your bridge ports and your IP forwarding path, you have to add your bridge ports (as represented by the real netdevice) to your flowtable definition.
as tu essayer d'activer l'offload hardware ? (flags offload : https://docs.kernel.org/networking/nf_flowtable.html#hardware-offload )
-
ton "lan" est un bridge on dirait dans ce cas il faut ajouter les interfaces physiques dans ta flowtable ( https://docs.kernel.org/networking/nf_flowtable.html#bridge-and-ip-forwarding )
as tu essayer d'activer l'offload hardware ? (flags offload : https://docs.kernel.org/networking/nf_flowtable.html#hardware-offload )
Tu as raison, même pour wan qui est une interface VLAN, on dirait que je me suis planté :
You do not need to add the PPPoE and the VLAN devices to your flowtable, instead the real device is sufficient for the flowtable to track your flows.
J'ai mis les vrais devices dans la flowtable : devices = { lan0, lan1, lan2, wan0 }, je vais relancer mes tests.
as tu essayer d'activer l'offload hardware ? (flags offload : https://docs.kernel.org/networking/nf_flowtable.html#hardware-offload )
Oui, ça n'est pas supporté. Hier, j'ai édité https://lafibre.info/remplacer-bbox/retour-dexperience-ont-externe-debian-sur-ikoolcore-r2-max-2x10g-2x2-5g/msg1107289/#msg1107289 pour ajouter des précisions là-dessus : on dirait que seuls MediaTek et Mellanox le supportent.
-
J'ai relancé le même script qu'hier : 4 iperf avec offload puis 4 sans offload. En mettant l'offload sur les interfaces physiques, on voit déjà que le compteur de bytes de wan0 n'augmente plus, c'est marrant :)
Par contre, toujours autant de dropped avec offload, presque même plus que sans. C'est fou, est-ce j'interprète mal les métriques ? On dirait que même le débit est meilleur sans offload qu'avec.
-
pour les compteurs c'est dans la doc: https://docs.kernel.org/networking/nf_flowtable.html#counters
As tu essayé sans bridge ? (pourquoi as tu besoin d'un bridge ?)
les buffers sont-ils bien réglés ?
notamment:
sudo sysctl net.core | grep mem_max
sinon regardes les stats des interfaces (y'a les méthodes ici: https://docs.kernel.org/networking/statistics.html)
est-ce pareil en ipv6/ipv4 ? (le NAT n'est pas offload , c'est que le forwarding donc un flux IPv4 reste peut-etre "cpu bound" a cause du NAT meme si le forwarding va plus vite).
-
pour les compteurs c'est dans la doc: https://docs.kernel.org/networking/nf_flowtable.html#counters
Ça ne change rien aux compteurs rx/tx bytes de l'interface VLAN mais de toute façon ce n'est pas un problème, ça permet au moins de voir que l'offload fonctionne.
As tu essayé sans bridge ? (pourquoi as tu besoin d'un bridge ?)
J'ai un LAN en 2.5G avec du PoE et un serveur en 10G. Trouver un switch avec à la fois 2 ports 10G et du PoE en 2.5G me semblait compliqué et très cher, c'était l'une des raisons de l'achat du routeur : mettre le LAN en 2.5G sur un des ports 2.5G du bridge et le serveur en 10G sur le port 10G du bridge. Je pense que, si la box avait eu des ports 2.5G comme la Freebox Ultra, je n'aurais jamais réfléchi à la remplacer :D
Je n'ai pas essayé sans le bridge, tu crois vraiment que ça joue ? Les compteurs de bytes du bridge LAN ne bougent pas quand l'offload est actif, même principe que le VLAN du WAN. Ça serait un peu compliqué de tester sans et je ne suis pas sûr que ça vaille la peine car l'offload semble déjà faire son travail.
les buffers sont-ils bien réglés ?
notamment:
sudo sysctl net.core | grep mem_max
Je n'ai pas du tout touché aux sysctl, peut-être qu'il y a des choses à améliorer ici, en effet :
net.core.optmem_max = 131072
net.core.rmem_max = 212992
net.core.wmem_max = 212992
Tu as une doc en tête pour optimiser ça au mieux ?
sinon regardes les stats des interfaces (y'a les méthodes ici: https://docs.kernel.org/networking/statistics.html)
Je vais lire ça, merci.
est-ce pareil en ipv6/ipv4 ? (le NAT n'est pas offload , c'est que le forwarding donc un flux IPv4 reste peut-etre "cpu bound" a cause du NAT meme si le forwarding va plus vite).
Je n'ai toujours pas testé en IPv6, je te dirai quand ça sera fait :)
-
Pas de différence en IPv6. Je remarque qu'à chaque fois que l'offload est actif, les pics de débit se font avec un pic de CPU sur un seul cœur. Quand l'offload n'est pas actif, parfois (dommage que ça ne soit pas tout le temps), 2 cœurs se répartissent la charge.
C'est vraiment dommage que cet offload n'aide pas, surtout que l'auteur disait dans https://lwn.net/Articles/738214/ :
I'm measuring here that the software flow table forwarding path is 2.5 faster than the classic forwarding path in my testbed.
est-ce pareil en ipv6/ipv4 ? (le NAT n'est pas offload , c'est que le forwarding donc un flux IPv4 reste peut-etre "cpu bound" a cause du NAT meme si le forwarding va plus vite).
De ce que je comprends de https://docs.kernel.org/networking/nf_flowtable.html#overview, la NAT est aussi offload :
The flowtable entry also stores the NAT configuration, so all packets are mangled according to the NAT policy that is specified from the classic IP forwarding path.
Vu le diagramme, l'offload prend le paquet bien avant tout ce qui est postrouting où la NAT se ferait.
Pour les optimisations sysctl, je vais un peu chercher de mon côté mais n'hésite pas si tu as des ressources sur le sujet.
-
ah bien pour le NAT je n'avais pas vu ce point. dommage pour IPv6.
sinon c'est peut-etre un souci/bug de ta version du kernel ? uname -a ca donne quoi ? (apres j'en doute un peu, flowtable n'est pas si récent que cela).
éventuellement faire un dual boot sur ton R2 pour tester d'autre distro / réglages ?
pour les opti sysctl je n'ai pas grand chose pour un linux qui fait "routeur". il faut chercher y'a sans doute des infos quelque part (regarde peut-etre les valeurs par défaut dans openwrt par exemple?).
-
Les valeurs par défaut d'OpenWRT sont clairement bien pour du gigabit mais insuffisantes pour du 10G.
net.core.rmem_default = 212992
net.core.rmem_max = 212992
net.core.rps_sock_flow_entries = 0
net.core.somaxconn = 4096
net.core.tstamp_allow_data = 1
net.core.warnings = 0
net.core.wmem_default = 212992
net.core.wmem_max = 212992
A minima, il faudra augmenter les valeurs rmem et wmem sans compter sur les options de la carte réseau.
On trouve des ressources utiles, par exemple:
https://fasterdata.es.net/host-tuning/linux/
https://cdrdv2.intel.com/v1/dl/getcontent/334019
https://people.ucsc.edu/~warner/buffer.html
https://wiki.archlinux.org/title/Sysctl#Improving_performance
-
Les valeurs par défaut d'OpenWRT sont clairement bien pour du gigabit mais insuffisantes pour du 10G.
net.core.rmem_default = 212992
net.core.rmem_max = 212992
net.core.rps_sock_flow_entries = 0
net.core.somaxconn = 4096
net.core.tstamp_allow_data = 1
net.core.warnings = 0
net.core.wmem_default = 212992
net.core.wmem_max = 212992
A minima, il faudra augmenter les valeurs rmem et wmem sans compter sur les options de la carte réseau.
On trouve des ressources utiles, par exemple:
https://fasterdata.es.net/host-tuning/linux/
https://cdrdv2.intel.com/v1/dl/getcontent/334019
https://people.ucsc.edu/~warner/buffer.html
https://wiki.archlinux.org/title/Sysctl#Improving_performance
les réglages pour un serveur ou un client (qui terminent/commencent une connexion tcp ou udp via un socket (https://man7.org/linux/man-pages/man2/socket.2.html)(2)) et pour un routeur(qui n'est que traversé par la connexion) ne sont pas forcement les mêmes.
je ne suis pas sur que rmem et wmem influent autant sur un routeur (chaine forward surtout avec le fastpath, rien en userspace) comme sur un serveur/poste (chaines input et output et un utilisation socket en userspace donc utilisation des valeurs net.core.. et)
a mon avis c'est plus coté option carte réseau que ca doit jouer.
a creuser. c'est ce qu'on cherche.
-
Perso j'utilise un i7-6700 avec une carte X520-DA2 est c'est juste pour passer les 7.65G en download depuis un SFP was-110. dès que j'active la QOS cake sur openwrt, on sent que je suis au maximum de ce que peut faire ce CPU, l'off load ne joue pas, ni les paramètre sysctl d'openwrt. Du coup avec un N100 ca risque d'être compliqué de faire mieux... Est-ce que t'as regardé si la carte Marvell utilisait bien toute sa bande passante pci ? Le souci du N100 c'est qu'il n'a que 9 ligne pci gen3 en tout donc selon les cas les fabricants de mini pc doivent parfois sacrifier les perfs ... que dit lspci -vvv sur le nombre de ligne PCI et la vitesse total allouée à la carte réseau marvel ? Aussi vu que tu n'as que 4 coeurs est-ce que les interruptions sont bien répartis entre les coeur ? (cat /proc/interrupts)
B.
-
Est-ce que t'as regardé si la carte Marvell utilisait bien toute sa bande passante pci ? Le souci du N100 c'est qu'il n'a que 9 ligne pci gen3 en tout donc selon les cas les fabricants de mini pc doivent parfois sacrifier les perfs ... que dit lspci -vvv sur le nombre de ligne PCI et la vitesse total allouée à la carte réseau marvel ?
Les tests que j'avais lus indiquaient bien que ce n'était pas un problème. Je viens de vérifier :
$ lspci -nnvvs 07:00.0
07:00.0 Ethernet controller [0200]: Aquantia Corp. AQC113C NBase-T/IEEE 802.3an Ethernet Controller [Marvell Scalable mGig] [1d6a:14c0] (rev 03)
Subsystem: Aquantia Corp. Device [1d6a:0001]
[…]
LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM not supported
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x2
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
En PCIe Gen 3 (https://en.wikipedia.org/wiki/PCI_Express#Comparison_table), x2 nous donne 1.969 GB/s donc > 10 Gb/s sans problème.
Aussi vu que tu n'as que 4 coeurs est-ce que les interruptions sont bien répartis entre les coeur ? (cat /proc/interrupts)
J'ai l'impression que sur une seule connexion TCP, ça n'est pas le cas, je n'ai que 2 compteurs sur 4 qui augmentent fortement.
Every 0.1s: grep lan0 /proc/interrupts router: Sun Mar 16 14:34:2[0/31]
134: 365285436 0 0 0 IR-PCI-MSIX-0000:07:00.0 0-edge lan0
135: 0 50637034 0 0 IR-PCI-MSIX-0000:07:00.0 1-edge lan0
136: 0 0 419998770 0 IR-PCI-MSIX-0000:07:00.0 2-edge lan0
137: 0 0 0 10079144 IR-PCI-MSIX-0000:07:00.0 3-edge lan0
138: 0 0 0 0 IR-PCI-MSIX-0000:07:00.0 4-edge lan0
Si je mets 8 connexions TCP par contre, les 4 compteurs augmentent bien simultanément. Le dernier reste à 0, je ne sais pas ce qu'il représente.
En tout cas, ça confirme ce que je vois sur les graphes de CPU : seuls 1 ou 2 cœurs prennent le trafic quand je suis en mono-connexion.
Il faudrait aussi que je m'amuse à grapher les inpackets/outpackets des 4 queues de chaque NIC :
Every 0.1s: ethtool -S lan0 | grep -Pi '(inpackets|outpackets):' router: Sun Mar 16 14:38:1[0/35]
InPackets: 3266062976
OutPackets: 1316155604
Queue[0] InPackets: 21093433
Queue[0] OutPackets: 1127948050
Queue[1] InPackets: 181200073
Queue[1] OutPackets: 83390005
Queue[2] InPackets: 3016562247
Queue[2] OutPackets: 11937344
Queue[3] InPackets: 47249083
Queue[3] OutPackets: 11259373
Il me semble que ce sont parfois des queues différentes qui prennent les paquets en entrée et en sortie (par exemple Queue[3] InPackets semble augmenter proportionnellement à Queue[0] OutPackets), mais il me faudra un graphique pour mieux visualiser.
Ma dernière piste pour gagner en performance serait d'utiliser la flowtable avec XDP (xdp-forward). Mais pour ça, il faut patcher le kernel car les VLAN ne sont pas supportés pour le moment : https://github.com/xdp-project/xdp-tools/issues/488.