T'as vu Optix, on est tellement forts qu'on a réussi à empêcher les OCEN qui brassent des millions de déployer un réseau à quelques millions
Puis bizarrement la force nous a perdu d'un coup, et Orange a réussi à déjouer notre plan diabolique :'(, la suite au prochain épisode

Je pense que ornemonopol tiens un truc, il devrait le proposer à Netflix !

l'accès aux chaines TV TNT n'est pas toujours sur le réseau câblé de la ville quand il existe, il est souvent sur une antenne collective indépendante même si elle est couplée au réseau câblé ...

Intéressant ... quelles sont vos sources?

Et il faut surtout bien comprendre que les OCEN ne viennent pas tout de suite dans les coins perdus qui restent alors en VDSL, voir ADSL pendant des plombes...
Merci aux offres activées et force aux régies locales. 

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.html

Je 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,19

J'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 04h36

Vraiment 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.

Il y a aussi les contrats du droit à l'antenne dans les immeubles, dont certains courent jusqu'à 2030 et plus, qui font qu'il ne peut pas fermer le réseau câble comme cela, sauf à payer de grosses pénalités. Et se faire une mauvaise publicité.

l'accès aux chaines TV TNT n'est pas toujours sur le réseau câblé de la ville quand il existe, il est souvent sur une antenne collective indépendante même si elle est couplée au réseau câblé dans l'immeuble, dans ce cas c'est indépendant de SFR aussi, c'est juste de la cohabitation, d'autant plus quand c'est un logement individuel, souvent le câblage coaxial est à part, c'est probablement le cas à l'origine de cette discussion.