Bonsoir,
Je suis toujours en mode intervention sur ma Fibre Optique où j'ai de plus en plus de pertes de paquets - jusqu'à 80% sur 1000 ping (1/seconde) en utilisant la commande "ping 1.1.1.1 -c 1000" ..
J'essaie d'avoir un truc génial "2 routeurs pour une connexion" en cas de problème - Le test est fait pour le réseau IPv4 (publique) ; depuis mes adresses LOCAL IPv4.
* routeur Livebox : 192.168.1.1 <--> 192.168.1.254 (gate.🇫🇷.◕‿◕.ST)
* routeur Airbox (ou smartphone) : 192.168.2.1 <--> 192.168.2.254 (gate.🇫🇷.◕‿◕.ST)
Sur ma "gateway : 192.168.1.254" qui est habituellement connectée à ma Livebox par l'interface "netbr0" ; j'ai configuré un bridge "usbbr0 avec l'adresse 192.168.2.254" et ai configuré des règles pour les 2 réseaux puis j'ai ajouté une passerelle en répartissant le trafic sortant entre les deux routeurs.
La doc est celle-ci :
https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.htmlJe vous donne le rendu :
⛔🔜 root@gate:~ # brctl show
bridge name bridge id STP enabled interfaces
lanbr0 8000.eaa1ead7899a no enp1s0f0
netbr0 8000.768478e541f1 no enp4s0
srvbr0 8000.7e18ddbb3f7d no enp1s0f1
usbbr0 8000.e6e2cf0bfdc7 no enx7e63e18e8a71
wlanbr0 8000.ea5168b1130e no enp5s0
⛔🔜 root@gate:~ # grc ip -4 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
7: netbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.1.254/24 brd 192.168.1.255 scope global netbr0
valid_lft forever preferred_lft forever
8: lanbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 172.16.0.254/24 brd 172.16.0.255 scope global lanbr0
valid_lft forever preferred_lft forever
9: srvbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.106.0.254/24 brd 10.106.0.255 scope global srvbr0
valid_lft forever preferred_lft forever
21: usbbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.2.254/24 brd 192.168.2.255 scope global usbbr0
valid_lft forever preferred_lft forever
⛔🔜 root@gate:~ # ip rule
0: from all lookup local
218: from 192.168.1.254 lookup 100
219: from 192.168.2.254 lookup 101
220: from all lookup strongswan
32766: from all lookup main
32767: from all lookup default
En plus de la doc du dessus ; j'ai ajouté 2 régles "NAT MASQUERADE" à la place "d'une seule comme habituellement".
⛔🔜 root@gate:~ # grc ip -4 route show table 100
default via 192.168.1.1 dev netbr0
192.168.1.0/24 dev netbr0 scope link src 192.168.1.254
⛔🔜 root@gate:~ # grc ip -4 route show table 101
default via 192.168.2.1 dev usbbr0
192.168.2.0/24 dev usbbr0 scope link src 192.168.2.254
⛔🔜 root@gate:~ # ip -4 route show
default
nexthop via 192.168.1.1 dev netbr0 weight 1
nexthop via 192.168.2.1 dev usbbr0 weight 1
10.6.42.0/24 via 10.106.0.252 dev srvbr0
10.106.0.0/24 dev srvbr0 proto kernel scope link src 10.106.0.254
10.116.0.0/24 via 10.106.0.252 dev srvbr0
10.116.42.0/24 via 10.106.0.252 dev srvbr0
10.126.0.0/24 via 10.106.0.252 dev srvbr0
10.126.42.0/24 via 10.106.0.252 dev srvbr0
172.16.0.0/24 dev lanbr0 proto kernel scope link src 172.16.0.254
192.168.1.0/24 dev netbr0 scope link
192.168.2.0/24 dev usbbr0 scope link
192.168.8.0/24 via 172.16.0.1 dev lanbr0
Mon poste en filaire RJ45 :
⛔🔜 root@gate:~ # iptables -L -vn -t nat | grep '172.16.0.142 '
6760 417K MASQUERADE 0 -- * netbr0 172.16.0.142 0.0.0.0/0
5188 416K MASQUERADE 0 -- * usbbr0 172.16.0.142 0.0.0.0/0
Mon sous-routeur Wi-Fi 6 sur MON LOCAL "
OpenWRT" qui donne la connexion à "Google Cast" ; mes smartphones etc.
⛔🔜 root@gate:~ # iptables -L -vn -t nat | grep '172.16.0.1 '
11488 1248K MASQUERADE 0 -- * usbbr0 172.16.0.1 0.0.0.0/0
11781 1088K MASQUERADE 0 -- * netbr0 172.16.0.1 0.0.0.0/0
Le nouveau
GL.iNet Beryl 7 (GL-MT3600BE) - OpenWRT ! WiFi 7 - 2.5g Ethernet ☺️ €144,19J'avoue que c'est bizarre pour le moment ; il faut que je vérifie quelques jours si çà fonctionne mieux ou pas (pour l'instant çà rame autant ; mais çà répond). Il faut que j'ajuste mes graphiques RRD.
Depuis ma "gate.fr" Linux avec la commande "iptraf-ng"
iptraf-ng multiple uplinks 2026-03-02
;-)
Romain.
---
Note at 03h40 - Pour le moment :
Sortie Fibre Optique (6.338 MS) :
⛔🔜 root@gate:~ # ip route get 1.1.1.1
1.1.1.1 dev netbr0 src 192.168.1.254 uid 0
cache
⛔🔜 root@gate:~ # ping 1.1.1.1 -c 4
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=7.12 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=6.12 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=6.02 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=6.09 ms
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 6.022/6.338/7.124/0.455 ms
Sortie 4G (58.117 MS) :
⛔🔜 root@gate:~ # ip route get 8.8.8.8
8.8.8.8 dev usbbr0 src 192.168.2.254 uid 0
cache
⛔🔜 root@gate:~ # ping 8.8.8.8 -c 4
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=110 time=63.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=110 time=62.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=60.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=110 time=46.0 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 46.020/58.117/63.470/7.043 ms
Depuis le réseau local ; j'ai encore des problèmes ; çà marche plus ou moins ; j'ai des adresses IPv4 qui sortent et d'autres non ; je ne comprend pas.
- Du et sur le smartphone "Netflix, "Amazon prime" et "Disney" fonctionne mais j'ai (mon Google Cast) seulement réussis à avoir "Netflix" sur ma Télévision ; mon smartphone est connecté à l'OpenWRT sur sa prise WAN "172.16.0.1"
- De mon PC Win11 "172.16.0.142" rien ne sort en IPv4 (sauf google.com).
Pourtant je vois du trafic NAT Masqué depuis cette machine.
⛔🔜 root@gate:~ # iptables -L -vn -t nat | grep '172.16.0.142 '
381 27660 MASQUERADE 0 -- * netbr0 172.16.0.142 0.0.0.0/0
98 24081 MASQUERADE 0 -- * usbbr0 172.16.0.142 0.0.0.0/0
@+
CF :
C:\Users\ORJ>ping -4 google.com
Envoi d’une requête 'ping' sur google.com [172.217.18.110] avec 32 octets de données :
Réponse de 172.217.18.110 : octets=32 temps=233 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=166 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=58 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=53 ms TTL=109
Statistiques Ping pour 172.217.18.110:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 53ms, Maximum = 233ms, Moyenne = 127ms
C:\Users\ORJ>ping -4 yahoo.com
Envoi d’une requête 'ping' sur yahoo.com [98.137.11.163] avec 32 octets de données :
Réponse de 98.137.11.163 : octets=32 temps=513 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=248 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=207 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=218 ms TTL=41
Statistiques Ping pour 98.137.11.163:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 207ms, Maximum = 513ms, Moyenne = 296ms
C:\Users\ORJ>ping -4 zw3b.fr
Envoi d’une requête 'ping' sur zw3b.fr [147.79.115.130] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 147.79.115.130:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
C:\Users\ORJ>ping -4 zw3b.tv
Envoi d’une requête 'ping' sur zw3b.tv [158.69.126.137] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 158.69.126.137:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
C:\Users\ORJ>ping -4 lafibre.info
Envoi d’une requête 'ping' sur lafibre.info [80.67.167.77] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 80.67.167.77:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
EXTRA-ORDINAIRE - Et ce ne sont pas les mêmes adresses IPv4 de destination :
C:\Users\ORJ>ping -4 google.com
Envoi d’une requête 'ping' sur google.com [142.251.142.78] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 142.251.142.78:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
C:\Users\ORJ>ping -4 yahoo.com
Envoi d’une requête 'ping' sur yahoo.com [98.137.11.164] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 98.137.11.164:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
humm..
Envoi d’une requête 'ping' sur google.com [142.251.142.78]
C:\Users\ORJ>ping 142.251.142.78
Envoi d’une requête 'Ping' 142.251.142.78 avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 142.251.142.78:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
⛔🔜 root@gate:~ # ip r g 142.251.142.78
142.251.142.78 dev usbbr0 src 192.168.2.254 uid 0
cache
Envoi d’une requête 'ping' sur google.com [172.217.18.110]
C:\Users\ORJ>ping 172.217.18.110
Envoi d’une requête 'Ping' 172.217.18.110 avec 32 octets de données :
Réponse de 172.217.18.110 : octets=32 temps=571 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=58 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=51 ms TTL=109
Réponse de 172.217.18.110 : octets=32 temps=160 ms TTL=109
Statistiques Ping pour 172.217.18.110:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 51ms, Maximum = 571ms, Moyenne = 210ms
⛔🔜 root@gate:~ # ip r g 172.217.18.110
172.217.18.110 dev netbr0 src 192.168.1.254 uid 0
cache
# --------------------------------
Envoi d’une requête 'ping' sur yahoo.com [98.137.11.163]
C:\Users\ORJ>ping 98.137.11.163
Envoi d’une requête 'Ping' 98.137.11.163 avec 32 octets de données :
Réponse de 98.137.11.163 : octets=32 temps=901 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=217 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=251 ms TTL=41
Réponse de 98.137.11.163 : octets=32 temps=295 ms TTL=41
Statistiques Ping pour 98.137.11.163:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 217ms, Maximum = 901ms, Moyenne = 416ms
⛔🔜 root@gate:~ # ip r g 98.137.11.163
98.137.11.163 dev netbr0 src 192.168.1.254 uid 0
cache
Envoi d’une requête 'ping' sur yahoo.com [98.137.11.164]
C:\Users\ORJ>ping 98.137.11.164
Envoi d’une requête 'Ping' 98.137.11.164 avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 98.137.11.164:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
⛔🔜 root@gate:~ # ip r g 98.137.11.164
98.137.11.164 dev usbbr0 src 192.168.2.254 uid 0
cache
hé hé hé ...
c'est un BUG de routage dans la AIRBOX ou DANS le SATELLITE DANS L'ESPACE !!Je vote pour le satellite dans l'espace - Analyse technique entre 00h38 et 04h36Vraiment bizarre parce que depuis la passerelle elle-même tout fonctionne.
----
Alors là c'est la meilleur :
Propriétaire en mon nom sur ma ligne Orange_FR (France Télécom) et propriétaire en mon nom sur mon serveur OVH au Canada.
⛔🔜 root@gate:~ # ping 158.69.126.137 -I netbr0 -c 10
PING 158.69.126.137 (158.69.126.137) from 192.168.1.254 netbr0: 56(84) bytes of data.
--- 158.69.126.137 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9193ms
⛔🔜 root@gate:~ # ping 158.69.126.137 -I usbbr0 -c 10
PING 158.69.126.137 (158.69.126.137) from 192.168.2.254 usbbr0: 56(84) bytes of data.
64 bytes from 158.69.126.137: icmp_seq=1 ttl=40 time=144 ms
64 bytes from 158.69.126.137: icmp_seq=3 ttl=40 time=236 ms
64 bytes from 158.69.126.137: icmp_seq=4 ttl=40 time=280 ms
64 bytes from 158.69.126.137: icmp_seq=5 ttl=40 time=209 ms
64 bytes from 158.69.126.137: icmp_seq=7 ttl=40 time=130 ms
64 bytes from 158.69.126.137: icmp_seq=8 ttl=40 time=138 ms
64 bytes from 158.69.126.137: icmp_seq=10 ttl=40 time=127 ms
--- 158.69.126.137 ping statistics ---
10 packets transmitted, 7 received, 30% packet loss, time 9013ms
rtt min/avg/max/mdev = 126.537/180.517/280.005/56.499 ms
C'est fou.. Ils sont vraiment dingue ces tech.OS d'Orange ... çà doit être pour me faire hié... (je suis en période "Intervention"). C'est pas sympat ; il faut remettre la ligne de routage "de moi à moi" le soir avant de partir du taf ; faut pas oublier demain.
En plus je les chauffe au "3900" en donnant mon pseudo de "lafibre.info" ; ils ne connaissent pas me disent-ils ... Faut-essayer les gars, mesdames, messieurs.
:-)
Merci.