La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: cyayon le 20 septembre 2022 à 09:24:07
-
Salut à tous,
J'ai une config qui fonctionne parfaitement avec des ports Gigabits et mon firewall (archlinux). J'utilise le dernier kernel stable 5.19.9.
Pour préparer l'installation de mon nouveau LEOX LXT-010H-D, j'ai acheté une nouvelle carte réseau QNAP QXG-2G2T-I225 (chipset intel i225).
Je configure tout comme il faut, et curieusement, imossible de faire fonctionner dhclient avec la nouvelle carte. dhclient semble fonctionner normalement, le VLAN semble correctement configurer, simplement, impossible d'obtenir une IPv4 et ipv6 d'orange.
Sur cette interface, j'ai également des paquets non taggués, aucun problème de ce coté là. Cela confirme que l'interface fonctionne correctement, au moins pour la partie non vlan.
en démarrant, dhclient ne retourne aucune erreur, pas plus que mon script de création du VLAN 832.
J'ai bien tenté de débrancher l'ONT Orange (par encore installé le LEOX), pendant 1 minute, mais rien n'y fait. Je n'obtiens pas d'IP d'Orange.
J'arrête tout et je rebranche ma carte Gigabit, je relance systemd-networkd et dhclient et tout fonctionne normalement.
Ai-je raté un truc d'après vous ?
Dois-je libérer le bail manuellement avec dhclient ? Est-ce une histoire de duid ?
bref, merci pour vos lumières ...
-
Est-ce que tu as besoin du CoS6 ? Si oui, il faut bien que la priorité 6 soit mappée : "ip link set xxxx.832 type vlan egress 6:6", ou via le paramètre EgressQOSMaps de systemd-networkd.
-
Oui bien sûr.
Je lance le même script qui fait tout.
Sans la COS cela ne fonctionne pas.
Si ça se trouve c’est un pb de driver de carte réseau…
-
Si la priorité est aussi configurée sur la nouvelle interface, c'est bizarre que ça ne fonctionne pas.
Pour voir si les VLAN fonctionnent, tu peux manuellement mettre l'adresse MAC de l'autre carte et l'IP qui avait été affectée.
Ensuite, pour vérifier que la priorité fonctionne sur les VLAN, il faut faire une capture externe, ou relier ta nouvelle carte réseau à l'ancienne et faire une capture sur cette dernière.
J'espère que la carte utilise bien des i225v3 (le bug connu provoque des pertes de trames en 2.5Gbps, à priori rien de relatif aux VLAN).
-
merci pour ta réponse.
comment on vérifie que le chipset est bien i225v3 stp ?
En pièce jointe j'ai ajouté l'output de mon script qui configure tout.
J'ai anonymiser 2 ou 3 trucs avec des xxxxxx.
Pas le moindre message d'erreur.
-
Avec lspci, "Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)".
Certains ont toujours des problèmes de stabilité avec, ce n'est pas très clair, et il y a des i226 maintenant.
-
je suis bien en v3
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-LM (rev 03)
07:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-LM (rev 03)
je vais retenter et sniffer la priorité
merci !
-
Bon, ben j'ai encore appris un truc...
visiblement le kernel linux (dans sa version 5.19 du moins), n'active pas certaines capabilities pour les cartes réseaux Intel i225.
Je précise que j'utilise la commande tc pour définir la COS 6 sur les requetes DHCP (obligatoires chez moi).
Avec mon ancienne carte réseau Intel X553 (v11), tx-vlan-offload et rx-vlan-offload sont à ON par défaut.
Sur la nouvelle carte réseau I225 (v3) ces valeurs étaient à OFF par défaut.
La conséquence directe est que la COS définit avec la commande tc n'était pas prise en compte. Je n'avais pourtant aucun message d'erreur. Je m'en suis rendu compte en sniffant mon traffic DHCP.
J'ai forcé la création du vlan 832 avec un egress "0:6 6:6", du coup, les requetes DHCP sont passées immédiatement.
Mais forcement ma bande passante était merdique (20Mb/s).
J'ai activé les 2 capabilities tx-vlan-offload et rx-vlan-offload avec ethtool, et relancer mon script avec ma COS définit par la commande tc. Et tout fonctionne sans problème.
c'est traitre comme problème...
-
Les deux offloads (qui sont synchronisés, la carte ne supporte pas l'un sans l'autre) sont effectivement désactivés par défaut depuis qu'ils sont implémenté dans le driver "igc" : https://github.com/torvalds/linux/commit/8d7449630e3450bc0546dc0cb692fbb57d1852c0.
C'est effectivement bizarre que le bon fonctionnement dépende d'une accélération.
Je vois vlan_dev_hard_header, qui est dédiée au cas où il n'y a pas d'accélération, mais qui ne le VID et skb->priority que s'il n'y a pas VLAN_FLAG_REORDER_HDR.
A l'inverse, dans vlan_dev_hard_start_xmit, il y a un code avec un commentaire évoquant le DHCP : quand il y a VLAN_FLAG_REORDER_HDR, il appelle __vlan_hwaccel_put_tag.
Mais je ne vois pas où c'est traité quand on a VLAN_FLAG_REORDER_HDR sans accélération : on sait que le VID et la priorité sont appliqués, sinon le "egress 0:6" ne fonctionnerait pas. Mais peut-être que dans ce cas skb->priority est lue trop tôt, avant que les règles tc s'appliquent.
-
A l’occasion je testerais mon ancienne interface réseau en désactivant explicitement les paramètres ethtool.
Si cela ne fonctionne pas, alors ce sera bien à cause de cela.
J’avoue que j’hésite fortement à me prendre un petit Mikrotik crs305 ou crs310 pour gérer la COS dhcp.
Avec un peu de chance Orange va retirer ce prerequis…
Merci en tout cas.
-
Pour le DHCP, il faudrait patcher le client de systemd-networkd.
Ils ont accepté pour le EgressQOSMaps, peut-être qu'ils seraient plus ouverts que le dhclient.
C'est plus propre d'agir à la source que de devoir filtrer tout le trafic.
A terme quand il y aura du XGS-PON, cette charge pourrait ne pas être si négligeable que ça, même pour un PC.
-
Je viens de patcher dhclient pour faire de la COS6, je vais l’essayer.
1. En lieu et place du dhclient standard
2. Sans mon script tc
3. Avec les options ethtool par défaut
Si tout fonctionne, J’avoue que j’hésite entre dhclient-standard+tc ou dhclient-patche …
-
Avec lspci, "Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)".
Certains ont toujours des problèmes de stabilité avec, ce n'est pas très clair, et il y a des i226 maintenant.
La situation semble particulièrement emmêlée.
Pour ce qui concerne ce fil, à ma connaissance, le traitement HW des vlans n'a jamais fait partie des éléments dont Intel fait publicité pour cette puce.
Il faut avouer que c'est un vrai labyrinthe, même les flyers changent au cours du temps, y compris après le stepping 3.
Une curiosité majeure est qu'Intel a fourni le driver igc pour Linux mais actuellement Intel ne liste pas l'OS comme étant supporté pour cette puce. On pourrait croire à une banale erreur mais la carte pcie de la gamme Intel ignore également Linux (et autres unix-like). Carte dont Intel vient d'ailleurs de signifier la fin de la livraison en "bulk" (comme bcp de cartes)
Du côté des dysfonctions, je connais deux problèmes
-Le non-support de EEE contrairement à ce qui a été publié pendant longtemps. Désormais c'est clair Intel ne le mentionne que pour les i226 qui arrivent. Plus généralement il semble que des gens aient des soucis en gestion d'énergie.
-L'initialisation de la carte/ports. Le problème est masqué par les OS qui font désormais une réinitialisation hw ce qui permet à l'ensemble des ports d'être détectés. Par contre à l'étage simplement EFI c'est toujours visible. Au passage j'ai eu un dialogue de sourd avec QNAP à ce sujet. Il semble aussi que iPXE ne puisse fonctionner avec ces puces.
La situation globale sur le front du 2.5G overclock est loin d'être idéale.
-
Du coup je ne sais pas si je la garder…
Mais trouver une carte dual ports qui accepte le 2.5G pour mon ONT Leox c’est pas gagné …
Qqun a une idée ?
-
En fait vous n'avez pas trop le choix si vous voulez strictement du 2.5G. En attendant la i226 qui est globalement ce que la i225 aurait du être, il n'y a que les realtek comme alternative et ce sont des puces minimalistes bien que fonctionnelles.
A votre place je continuerais pour le moment avec cette carte puisque vous la possédez (vous pouvez au moins vous dire qu'avec cette carte de chez QNAP vous avez une excellente qualité de fabrication) et je regarderais les alternatives un peu plus tard.
-
Je peux encore rendre la carte (Amazon)…
J’ai bien pensé à mettre un switch avec des SFP compatible 10G-2.5G et prendre une carte dual port 10G, mais ça fait de suite bcp plus cher…
-
Désolé de vous avoir perturbé, je pense que vous devriez aller jusqu'au bout des tests envisagés avec hwti avant d'éventuellement décider d'un changement de stratégie.
-
aucun problème, au contraire, merci pour bcp pour ces infos !
-
En fait vous n'avez pas trop le choix si vous voulez strictement du 2.5G. En attendant la i226 qui est globalement ce que la i225 aurait du être, il n'y a que les realtek comme alternative et ce sont des puces minimalistes bien que fonctionnelles.
Les Realtek étaient à priori assez buggées au départ aussi, et ensuite RTL8125B (PCIe) / RTL8156B (USB) sont arrivées avant que les drivers Linux les supportent.
Je ne sais pas si c'est 100% stable ou pas maintenant.
Il y a aussi les Aquantia (Marvell) :
- 1ère génération : ACQ107 (10Gbps), AQC108 (5Gbps), AQC109 (2.5Gbps)
- 2ème génération : AQC113 (10Gbps), AQC114 (5Gbps), AQC115 (2.5Gbps)
Au moins sous Windows, la première génération ne semblait pas toujours très stable.
La seconde génération est probablement trop récente pour avoir des retours.
Le non-support de EEE contrairement à ce qui a été publié pendant longtemps. Désormais c'est clair Intel ne le mentionne que pour les i226 qui arrivent. Plus généralement il semble que des gens aient des soucis en gestion d'énergie.
Quand le EEE n'est pas buggé, il y a quand même souvent des problèmes d'interopérabilité avec les switchs, donc c'est difficile à déterminer.
Mais à part sur un laptop, le EEE ça ne sert pas à grand chose.
Je peux encore rendre la carte (Amazon)…
J’ai bien pensé à mettre un switch avec des SFP compatible 10G-2.5G et prendre une carte dual port 10G, mais ça fait de suite bcp plus cher…
Si c'est stable avec le LEOX (pas de perte de liens, pas de pertes de paquets à fort débit), pas de raison de changer.
-
Ok merci pour ces infos.
Je vais patienter et tester pendant qques jours.
J
-
Les Realtek étaient à priori assez buggées au départ aussi, et ensuite RTL8125B (PCIe) / RTL8156B (USB) sont arrivées avant que les drivers Linux les supportent.
Je ne sais pas si c'est 100% stable ou pas maintenant.
Il y a aussi les Aquantia (Marvell) :
- 1ère génération : ACQ107 (10Gbps), AQC108 (5Gbps), AQC109 (2.5Gbps)
- 2ème génération : AQC113 (10Gbps), AQC114 (5Gbps), AQC115 (2.5Gbps)
Au moins sous Windows, la première génération ne semblait pas toujours très stable.
La seconde génération est probablement trop récente pour avoir des retours.
Quand le EEE n'est pas buggé, il y a quand même souvent des problèmes d'interopérabilité avec les switchs, donc c'est difficile à déterminer.
Mais à part sur un laptop, le EEE ça ne sert pas à grand chose.
Si c'est stable avec le LEOX (pas de perte de liens, pas de pertes de paquets à fort débit), pas de raison de changer.
Les realtek n'ont pas eu de pilote pendant un moment, comme souvent, mais c'est quand même différent d'une défaillance d'ingénierie de la puce comme chez Intel.
Pour la partie 4ème gen Aquantia, pas la même norme, il y a déjà de l'expérience mais l'inquiétude, de mon point de vue, c'est ce que vont en faire les intégrateurs sur les cartes pcie grand public.
EEE est présent même sur des cartes 100G, conceptuellement son centre n'est pas vraiment les portables. Intel ne semble pas doué avec, ils nous avaient déjà fait le coup avec les cartes serveur cuivre x550 en l'annonçant sans avoir une implémentation fonctionnelle.
Invariablement vous avez raison, si ça roule avec le LEOX et le reste de l'implémentation, pas de quoi tout chambouler.
J'ai cette même carte, actuellement non utilisée, je vais la ré-installer et vous dirai si je vois un souci.