Auteur Sujet: Parametrage liaison ppoe sur un debian récent  (Lu 1714 fois)

ylec, Paul et 15 Invités sur ce sujet

pcouderc

  • Abonné OVH
  • *
  • Messages: 5
Parametrage liaison ppoe sur un debian récent
« le: 21 février 2025 à 10:21:21 »
Je désire utiliser mon routeur maison à base debian (rpi4 et déjà configuré...) pour remplacer le routeur Zygel fourni par OVH en gardant l'ONT (Bouygues dans mon cas).

Quelqu'un a-t-il déjà fait cela (PPPoE...), y-a-t-il un tutoriel testé quelque part ?
Je n'en trouve pas qui fonctionne, ou plus exactement que je réussisse à adapter rapidement ...

ylec

  • Abonné OVH
  • *
  • Messages: 7
  • VAUDOY en BRIE
Parametrage liaison ppoe sur un debian récent
« Réponse #1 le: 25 novembre 2025 à 19:15:15 »
Bonjour
Personellement, j'ai acheté un pack OVH fibre Pro avec profil C, il y a presque un mois, donc VLAN 4001 et Class of Service 0 , et PPPoE
J'ai créé deux machines virtuelles sous Proxmox installé sur un mini-PC industriel 4 interface Ether Gbps,
une Debian et une Fedora

J'ai fait la configuration PPPoE sous Debian 13, kernel  6.12 avec l'interface graphique de MATE:
Systeme -> Centre de Controle -> Configuration  Réseau Avancé
  qui lance le programme   nm-connection-editor

J'ai fait également la config avec une Fedora 42 (avec  Kernel 6.17, pour être au même niveau de désignation des interfaces que sur Debian 13); où la désignation des interfaces ethernet a été simplifiée lors du passage de Kernel 6.16 à 6.17 sur Fedora 42: exemple enp6s18, remplacé par ens18) Sur Fedora on peut démarrer nm-connection-editor, via la nm-applet  (de la barre des taches à droite) --> Modifier les connexions

Ensuite sous Debian 13 ou Fedora 42 c'est la même procédure.
J'ai personnellement 3 interfaces Ethernet
ens18 (pour le WAN)
ens19 (pour un LAN1 général)
ens20 (pour un LAN2 dédié à la ToIP)
ens18 est désactivé en configuration IPV4 et IPV6, mais activé au boot pour être dans l'état running.
puis je crée un VLAN 4001, ens18.4001 qui a comme parent ens18, aussi désactivé en configuration IPV4 et IPV6, mais activé au boot
au final ifconfig -a doit faire voir:
             ens18:         flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
             ens18.4001: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Puis on crée un interface PPPoE toujours avec nm-connection-editor
Dans l'onglet génnéral cocher: se connecter automatiquement ...
Dans l'onglet DSL/PPPoE :
Interface parente:   ens18.4001  (et décocher "Réclamer l'interface"
        pour que dans le paramètre suivant, ppp0
        apparaisse automatiquement, et SURTOUT que NetworkManager l'active vraiment)
Interface PPP:       ppp0
Nom d'utilisateur:   <son credential OVH @byt.ovhcloud>
Service:             vide
Mot de passe:        <son password OVH>

Dans l'onglet suivant on peut laisser toutes les méthodes d'authentification cochées (elles sont négotiées avec le serveur PPPoE)
j'ai joué aussi avec les méthodes de décompression, pour essayer de faire disparaitre les anomalie que je vais dévrire après
Sur l'onglet Proxy, rien à faire
 sur celui IPV4 cocher Automatique (PPPoE) (qui permet  de récupérer l'adresse fixe alloué par OVH, la gateway par défaut et les @IP des DNS), et pareil pour IPV6 ou désactivé.
NOTE le MTU de ppp0 démarré par NetworkManager, sera automatiquement celui du parent (ens19.4001) - 8
= = = = =
On règle son firewall préféré pour faire du nat quand on sort par ppp0

Résultat: Dans un premier temps avec des tests simples tout semble fonctionner.
Les tests speedtest.net, avec les meilleurs serveurs proposés (exemple ORANGE), donne un débit environ symétrique > 900 Mbps
les pings vers 1.1.1.1 donne au mieux 8 à 9 ms, mais peut monter à plus de 160 ms en soirée, en tout cas pour le NRO du 77 où je suis raccordé.
Mais dès qu'on est sur des pages WEB complexe, exemple la pages "Order" sur aliexpress, les temporisations peuvent être entre 1 mn et 'infinie', si on ne fait pas de reload, et encore ça ne fonctionne pas toujours le reload.

J'ai une application bancaire de smartphone, qui ne permet même pas de passer l'étape de login car le clavier aléatoire qui permet d'entrer son code, reste indéfiniment en attente.
Sur netflix, les AndroidTV boxes, reste en attente de l'apparition de la page des profils.

Et encore j'ai expérimenté des différences selon les seveurs DNS utilisés, ceux fourni par OVH étant le cas pire, où le plus de site WEB sont inutilisables. C'est avec 1.1.1.1 et  celui de google 8.8.8.8, que j'ai les résultats les moins pires.
======
de guerre lasse, j'ai laissé tomber des heures d'essais, et ai "changer d'offre", pour avoir un model Zyxel avec leur config standard. La ça fonctionne en mettant mon routeur en DMZ de la boxe Zyxel, sur une de ses ports LAN. Donc une couche de NAT; et 4€80 TTC en plus par mois.

Le mode Bridge qui prend en charge le VLAN 4001, et laisse le routeur prendre en charge PPPoE ppp0, ayant cette fois ci ens18 en parent , et en désactivant l'interface ens18.4001, ne donne AUCUNE suppression des anomalies décrites ci dessus.

Je précise que ces routeurs fonctionnent the finger in the nose, sur le réseau Free avec une FreeBox Pop en Bridge IPv4 (on perd l'IPv6), ou sur le Réseau K-net pro (qui n'a pas d'IPv6). Ces deux réseaux n'utilisent ni VLAN, ni PPPoE.

Alors si quelqu'un passant par ici à réussi  faire fonctionner un routeur sur une fibre OVH/BouyguesTelecom; avec VLAN et PPPoE , profil C d'OVH, il serait intéressant de savoir comment ?

Je précise que dès qu'on utilise des VLAN sur le lien de départ, n'importe quelle CoS, peut être mise en ouvre au niveau 2 de l'OSI, basé sur des critères comme m'adresse MAC, .... Dans ce cas ci , @MAC n'est pas le critère car j'ai expérimenté en reportant l'adresse MAC WAN du Zyxel (vu sur wireshark) sur les interfaces fournis par proxmox



« Modifié: 25 novembre 2025 à 19:42:36 par ylec »

pcouderc

  • Abonné OVH
  • *
  • Messages: 5
Parametrage liaison ppoe sur un debian récent
« Réponse #2 le: 26 novembre 2025 à 08:45:18 »
Oui, depuis des mois j'utilise à ma grande satisfaction  un  raspberry pi IV à la sortie du boitier Bouygues; comme routeur à la place des outils (zygel) fournis par OVH. Je mets ici le principal parametrage, il faut ensuite gerer les iptables que je tiens à dispositition.


root@ovh:~# cat  /etc/network/interfaces
auto lo
iface lo inet loopback

# --- Bridge LAN (porte l'IP LAN)
auto br0
iface br0 inet static
    address 192.168.163.253
    netmask 255.255.255.0
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0
    dns-nameservers 192.168.163.30 1.1.1.1 8.8.8.8
    dns-search couderc.eu

# --- Eth0 en esclave du bridge
allow-hotplug eth0
iface eth0 inet manual

# --- WLAN (sera ajouté plus tard par hostapd sur br0)
allow-hotplug wlan0
iface wlan0 inet manual

# --- WAN PPPoE inchangé
auto eth1.4001
iface eth1.4001 inet static

auto dsl-provider
iface dsl-provider inet ppp
    pre-up /bin/ip link set eth1.4001 up # line maintained by pppoeconf
    provider dsl-provider

root@ovh:~#

ylec

  • Abonné OVH
  • *
  • Messages: 7
  • VAUDOY en BRIE
Parametrage liaison ppoe sur un debian récent
« Réponse #3 le: 26 novembre 2025 à 15:14:49 »
Bonjour,
et merci pour ces informations précieuses.
Il est important de connaitre les détails du contexte afin de pouvoir faire des extrapolations pertinente:

Je vois que tu parles du VLAN 4001, donc il s'agit du profil C d'OVH Fibre, comme mon contexte
Pour le boitier Bouygues je suppose que tu parles de l'ONT: s'agit-il d'un Nokia ou d'un Huawei ? Pour ma part j'ai un Nokia G010G-Q
Quelle version Debian pour ARM est sur le raspberry pi IV  ?
Dans mon contexte c'est une Debian 13 Kernel 6.12, sur une VM Proxmox tournant sur un mini-PC avec quad core Intel(R) Celeron(R) N5100.
Pour l'instant la même config sur un autre PC du même type, mais l'OS installé en natif donne les même anomalies que j'ai décrite.

===============
Je vais donc maintenant essayer la même configuration que celle que tu a mis en oeuvre, en désactivant sur la Debian le service NetworkManager, et en utilisant uniquement le service de base actif par défaut sur toute les Debians: networking.service qui exploite dès l'initialisation le fichier /etc/network/interfaces, qu'il y ait, ou pas, ensuite le service NetworkManager ou systemd-networkd qui tourne en plus.

Je donnerai ici plus tard ma configuration une fois essayée et testée hexaustivement.



pcouderc

  • Abonné OVH
  • *
  • Messages: 5
Parametrage liaison ppoe sur un debian récent
« Réponse #4 le: 26 novembre 2025 à 19:13:59 »
:


Pour le boitier Bouygues je suppose que tu parles de l'ONT:

NOKIA

Quelle version Debian pour ARM est sur le raspberry pi IV  ?

Linux ovh 6.12.34+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64


Oui ma config est vieille et classiques, mais elle fonctionne....

Apres tout le routage est de l'ordre des IPtables

jeremyp3

  • Abonné Orange Fibre
  • *
  • Messages: 805
  • Pau (64)
Parametrage liaison ppoe sur un debian récent
« Réponse #5 le: 26 novembre 2025 à 22:30:54 »
bonjour,

le problème décris ressemble drôlement à un problème de mtu.

l'interface ppp0 doit avoir une MTU de 1492. pas plus

pcouderc

  • Abonné OVH
  • *
  • Messages: 5
Parametrage liaison ppoe sur un debian récent
« Réponse #6 le: Hier à 07:36:34 »
Certainement :  mon mtu  est 1492...

ylec

  • Abonné OVH
  • *
  • Messages: 7
  • VAUDOY en BRIE
Parametrage liaison ppoe sur un debian récent
« Réponse #7 le: Aujourd'hui à 11:13:18 »
Bonjour,
A jeremyp3:
Hélas NON. Car dès le deuxième jour de la mise en service de mon lien Fibre OVH, et le constat des anomalie déclarées ici, c'est la première chose que j'ai essayé de tester; avec les 3 valeur possibles qu'OVH donnait dans sa procédure donné pour chaque profil A, B et C. Au début je les mettais sur l'interface VLAN 802.1Q (ens18.4001) car l'applet network manager et son configurateur nm-connection-editor, ne permet de rentrer un MTU qua dans ce type d'interface. Mais je me suis vite apperçu que l'interface ppp0 avec systématiquement un MTU de MTU de l'interface parent - 8 octet.
Don c à la fin je n'ai plus rien mis nulle part et j'avais systématiquement:

root@homedeb13fw2:~# ifconfig ppp0 | grep flags
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1492

Que ce soit avec la configuration pour  le service NetworkManager où le MTU n'est référencé nulle part dans la conf ppp0
ou              avec la configuration pour  neworking, utilisant /etc/ppp/peers/dsl-provider où le MTU n'est référencé nulle part dans la conf

Je vais donner dans la réponse suivante les détails de la seule configuration qui fonctionne, celle décrite par pcouderc
et qui a aussi fonctionné au premier essai sur ma VM en Debian 13.

Rien de tel que le retour d'expérience de quelqu'un qui a réellement fait fonctionner une configuration !
La dimension des trames a été corroboré, par mes capture wireshark, qui ont été faite entre le port WAN,
soit de mon routeur sous Linux
soit de la boxe Zyxel, et le port Ethernet de l'ONT :
j'utilise un portable avec deux adaptateurs USB3 - Ethernet Gigabit, qui font apparaître deux interfaces LAN dans la liste ifconfig -a, et relié par un bridge bridge0; ni le bridge , ni ces 2 interfaces Ethernet n'ont d'adresse IP; ils sont seulement à l'état RUNNING. Et je met wireshark en écoute sur bridge0, ou sur l'un de ses ports Ethernet.

pcouderc

  • Abonné OVH
  • *
  • Messages: 5
Parametrage liaison ppoe sur un debian récent
« Réponse #8 le: Aujourd'hui à 11:35:07 »
Heureux que mon retour d'expérience soit utile.
J'avais galéré avec les modems Zygel...
Et avant avec la freepro qui m'avait obligé à installer un routeur maison rpiIV.
J'ai quitté feeepro, parce qu'à une époque, ils ont mis 3 semaines pour répondre un un ticket : pas très pro..
Malgré tout, j'ai beaucoup plus de soucis avc ovh,  : ce qui m'irrrite au plus au point, c'est ma drogue https://www.bridgebase.com/ : je suis déconnecté toutes les 10 minutes environ...
La liaison est excellente, mais le réseau derriere ne suit pas toujours,ce que l'on appelle les accords de "peering"... Le service est variable, cela dépend de l'interlocuteur au premier niveau,le temps qu'il se décide à passer au niveau au dessus...

ylec

  • Abonné OVH
  • *
  • Messages: 7
  • VAUDOY en BRIE
Parametrage liaison ppoe sur un debian récent
« Réponse #9 le: Aujourd'hui à 11:42:49 »
Bonjour,

Merci encore à pcouderc, qui m'a permis de faire enfin
( après 3 semaines de galère; et une extension de mon abonnement pour disposer d'une boxe Zyxel, pour étude comparative)
de faire fonctionner mon routeur correctement avec disparition de toutes les anomalies que j'avais avec la solution ModemManager. ModemManager étant la seule que j'avais sous Fedora 40 puis 42, mon routeur de test initial.
Sous Fedora il n'y a pas de service legacy networking.service comme sous Debian.
Sous Debian ou sous Fedora, le process pppd lancé par Network manager, est visible avec une quirielle de paramètres en argument.

Avec networking service on a "simplement" :
root@homedeb13fw2:~# ps -ef | grep pppd
root        1004       1  0 nov.27 ?       00:00:00 /usr/sbin/pppd  call  dsl-provider

Le configuration /etc/ppp/peers/dsl-provider, construite par pppoeconfig contient la directive:
plugin rp-pppoe.so

Rien de tel dans la configuration:
/etc/NetworkManager/system-connections/ppp0.nmconnection
élaboré par  nm-connection-editor.

ylec

  • Abonné OVH
  • *
  • Messages: 7
  • VAUDOY en BRIE
Parametrage liaison ppoe sur un debian récent
« Réponse #10 le: Aujourd'hui à 12:00:16 »
Bonjour,

Je ferai ici plus tard mon retour d'expérience sur la fiabilité de la connexion OVH fibre, sur un NRO du 77,

mais il faut que je termine tout ce que j'avais en place sur ma conf Fedora 42, migré sur la Debian 13, avec le secours GSM sur Orange, et asterisk qui permet d'exploiter les fonctions téléphonie et SMS, associées à ma puce SOSH. Je l'utilise essentiellement pour m'envoyer un SMS à chaque fois que la fibre est indisponible. Un service failover.service de mon cru, fait la surveillance de la disponibilité du lien fibre et GSM, et m'envoi un SMS, quand la route utilisée par defaut (celle en tête de liste dans netstat -nr) doit être changée.
==============================


et enfin ma configuration:
root@homedeb13fw2:~# cat /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
# source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback

# pas d'interface WIFI sur mon routeur, donc pas besoin de pont, pour le LAN1
# LAN 1 : interface ens19
allow-hotplug ens19
iface ens19 inet static
    address 192.168.200.2
    netmask 255.255.255.0
    dns-nameservers 1.1.1.1 8.8.8.8

# LAN 2 : interface ens20
allow-hotplug ens20
iface ens20 inet static
    address 192.168.120.2
    netmask 255.255.255.0


# --- pas de WLAN sur le routeur
# mais un interface GSM avec un modem mini-PCIe
# ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem
# avec puce sosh data, Telephone, SMS
# la partie Data est pris en charge par le module cdc_ether
# ce qui nous donne automatiquement un interfce IP prêt à l'emploi:
# exemple: enx461cd4054703, autoconfiguré sans configuration nulle part
# mais qui hélas change d'adresse MAC à chaque extinction du PC supportant proxmox!
# Les interfaces ttyUSB0, ttyUSB1 , ttyUSB2, ttyUSB3
# restent libre (à condition que ModemManager soit disable)pour une exploitation du module chan_quectel.so d'asterisk
# pour la téléphonie mobile et les SMS

# --- WAN PPPoE
allow-hotplug ens18
iface ens18 inet manual

auto ens18.4001
iface ens18.4001 inet manual

auto dsl-provider
iface dsl-provider inet ppp
    pre-up /bin/ip link set ens18.4001 up # line maintained by pppoeconf
    provider dsl-provider

=================

root@homedeb13fw2:~# cat /etc/ppp/peers/dsl-provider
# Minimalistic default options file for DSL/PPPoE connections

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
#mtu 1492
#persist
#maxfail 0
#holdoff 20
plugin rp-pppoe.so
nic-ens18.4001
usepeerdns
nic-ens18.4001
user "xxxxxxxxxxx.@byt.ovhcloud"


==============
Donc on voit que même si on peut mettre ici, une taille de MTU, elle n'est pas obligatoire si celle par défaut: 1492
est utilisable