Courtefontaine : Free mobile ne veut pas prendre en charge le raccordement fibre (et la tranchée) de l'antenne relais.

Source : C'est à dire, novembre 2025

"une latence plus faible", visiblement le journaliste ne dispose pas des bases de physique niveau collège...

Oulalala, on a compris, Free, c'est de la 💩.

Si vous pouviez aller déverser votre haine ailleurs, ça nous ferait des vacances.

Tu t'auto-proclames porte parole des lecteurs du forum ?

Personnellement, ça ne me dérange pas.

"On" a tellement subi la propagande des fanboys depuis des années que ça équilibre un peu...

L’observatoire de novembre n’est pas encore sorti. Les 400 sites sont à faire sur 2 mois, pas sur le seul mois de décembre.

@ping_31660 :

Ta configuration semble avoir été réalisée sans réelle préparation ; elle manque de cohérence ou laisse penser à des lacunes techniques.

• Par quel média (ONU, convertisseur...) es-tu relié au réseau fibre Orange ?
• As-tu lu la page Wiki du Asus RT-AX89X ?

➪ Précise la référence de ton module optique. Vérifie que ton modèle est bien supporté.

asus,rt-ax89x)
ucidef_set_interfaces_lan_wan "10g-sfp 10g-copper lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8" "wan"

J'ai recherché ce modèle dans les sources OpenWrt. On peut constater qu'il n'y a pas de port eth0. Ta configuration est invalide. Remplacer
la box d'un FAI ne s'improvise pas. Cela peut s'avérer dangereux en cas d'erreur.

Je vais donner un exemple concret. J'exploitais la version nocturne d'OpenWrt (snapshot). Je me suis aperçu trop tard (quelques minutes seulement) que
mon pare-feu avait planté. J'étais connecté directement au réseau Orange lors des manips (pour gagner du temps bien que ce soit une mauvaise chose).
Mes règles de pare-feu définies automatiquement par des scripts uci-defaults étaient erroné car l'interface avait été renommé dans la version nocturne.

config device
option type '8021q'
option ifname '10g-sfp'
option vid '832'
option name 'eth0.832'
list egress_qos_mapping '1:0'
list egress_qos_mapping '0:6'
list egress_qos_mapping '6:6'
option macaddr 'MAC LIVEBOX'

config interface 'wan6'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option sendopts '11: [u]générée par le script[/u] 15:FSVDSL_livebox.Internet.softathome.Livebox6 16:0000040e0005736167656d 17:000005580006000e495056365f524551554553544544'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option clientid '00030001MAC LAVIBOX'
option norelease '1'
option device 'eth0.832'

config zone
option name 'wan6'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option family 'ipv6'
list device 'eth0.832'
list network 'wan6'


Les SSD pour ton cluster cepth c'est bien des SSD "enterprise" (avec Powel Loss Protection) ?

Parce que c'est carrément obligatoire, ceph fait beaucoup d'écritures et "tue" les SSD grand public à une vitesse impressionante. Si les disques ne supportent pas PLP alors impossible pour le SSD d'optimiser les écritures...

J'ai un cluster proxmox/ceph 3 noeuds chez moi, et j'ai testé avec:
- 3 SSD Crucial"grand public" neufs => wear out à 90% en 12 mois...
- 3 SSD Kingston DC600M neufs => wear out à 2% en 10 mois...

Et toujours impressioné par la résilience de ceph, même dans les conditions difficiles auquel il est soumis chez moi (avec des hosts qui crashent régulièrement avec pour cause probable cette catastrophique NIC I225-V).