Bonjour,
J'aurais besoin de votre aide.
Je remplace actuellement ma box Bouygues Telecom par un routeur UniFi Cloud Gateway Fiber, auquel j'ajouterai un AP Wifi dès réception.
Mon installation actuelle :
FTTH == fibre ==> PTO/ONT == ethernet ==> UCGF (port 5 10GbE)
Lors de l'installation, la connexion automatique échoue. Je me dis que cela peut être normal et que le routeur ne dispose simplement pas de profils dédiés aux spécificités de chaque opérateur existant au niveau mondial. J'ai donc réalisé la connexion après saisie des informations manuellement :
Advanced- VLAN ID 100
- MAC address Clone avec la MAC de la BBox
- IGMP Proxy
IPv4- Connection DHCP
- DHCP Client Option 60 avec la valeur BYGTELIAD
- DHCP CoS avec tag 6
- Auto DNS Server
IPv6La connexion a d'abord échouée avant de réussir. Le routeur a lui même détecté que le FAI sur le port 5 (WAN1) était Bouygues Telecom après configuration manuelle.
Ce que je constate pour le moment :
- énormément de déconnexions/reconnexions enregistrées dans les logs (WAN1 (Bouygues Telecom) on port 5 went down multiple times in the last 24 hours)
- la plupart des sites Internet se chargent sur mes appareils connectés mais avec parfois des erreurs de connexion et donc des services/sites inaccessibles
- pas flux d'accès aux flux IPTV sur ma TV connectée (ni via SamsungTV, ni via les applications Canal, Molotov, etc), seul YouTube semble échapper à cette règle
- certains services liés aux IoT sont quasi inutilisables (Alexa fonctionne par intermittence par exemple)
- latences élevées et beaucoup de paquets perdus (d'après le graphique présent sur le dashboard de la console UCGF)
Si vous avez des indices ou conseils pour la configuration de mon UCGF, je suis preneur.
Merci et bon dimanche à tous.
Edit 1 :Après avoir réalisés plusieurs tests, j'ai pu découvrir qu'il y a avait un problème dans la configuration de mon AP (Asus XT8). Ce problème engendrait des problèmes divers en WiFi (déconnexions/reconnexions, pertes temporaires de connexion, pertes de paquets, etc.
Une fois la bonne configuration effectuée côté AP, j'ai pu stabiliser la connexion pour les appareils en WiFi.
J'ai ainsi pu récupérer l'accès à certains sites et services MAIS... Pas tous, pas tout le temps, et toujours avec des messages "Multiple Internet Disconnections".
Edit 2 :En effectuant plusieurs captures de trames sur le WAN et le LAN et en observant le comportement de mes appareils connectés, je n'arrivais pas forcément à trouver de traces de déconnexions / reconnexions du WAN.
A côté de ça, j'avais toujours des problèmes d'accès à certains sites ou services. J'ai donc multiplié les tests et découvert un problème de DNS sur mes appareils.
nslookup google.com --> timeout
nslookup google.com 8.8.8.8 --> OK
Donc, en forçant l'utilisation du DNS, ça passe.
En y regardant de plus prêt, j'ai vu que le routeur était utilisé comme serveur DNS (paramètre Auto DNS Server dans les paramètres du LAN). Normalement, ça devrait fonctionner car le routeur devrait relayer les requêtes DNS vers un vrai serveur DNS (celui du FAI en auto, ceux spécifiés si Auto DNS Server est désactivé dans les paramètres du WAN). Sauf que je ne voyais pas les requêtes passer sur le WAN.
Je suppose donc que la logique DNS de l'UCG Fiber est cassée. Le routeur ne relaie pas les résolutions DNS provenant des appareils du LAN comme il le devrait.
Après désactivation de Auto DNS Server sur le LAN et utilisation des DNS 1.1.1.1 et 8.8.8.8, le routeur ne fait plus office de serveur DNS et transmet donc les adresses des serveurs DNS à utiliser directement aux appareils connectés sur le LAN.
Avec ça, je n'ai plus de problèmes de sites ou services inaccessibles.
Par contre, les logs indiquent toujours de multiples déconnexions et déconnexions temporaires, et des pertes de paquets. J'ai aussi quelques sites, souvent les sites nouvellement visités, qui d'abord tombent en erreur avant de fonctionner correctement. Donc tout n'est pas résolu.
Edit 3 :En analysant les logs du routeur via SSH, j'ai pu trouver des traces des pseudo déconnections/reconnections du WAN. A priori, cela se produit lorsque les tests effectués par le routeur pour vérifier l'état de la connexion WAN échouent. J'ai pu constater que le routeur enregistrait parfois des échecs lors des tentatives de résolutions DNS, provoquant un WAN failover (passage automatique sur un WAN de secours).
Sauf qu'en tant que particulier je n'ai pas de WAN2... Je n'ai que mon FAI avec une arrivée fibre sur WAN1. Le routeur essayait donc de passer sur un WAN2 qui n'existe pas, coupant ainsi lui même la connexion à Internet, avant de voir que le WAN2 était inexistant et de revenir à WAN1.
Dans la configuration par défaut des ports du routeur, j'avais le le second port SFP+ effectivement affecté au WAN2, qui n'existait pas. J'ai donc passé ce port à "undefined", corrigeant ainsi le problème de WAN failover.
J'ai également créé une règle SLA personnalisée, légèrement plus permissive que celle par défaut, que j'ai affecté au WAN1. Depuis, je n'ai plus de messages de déconnexions/reconnexion.
Reste un problème avec la résolution DNS qui parfois ne fonctionne pas instantanément ou échoue carrément. Pour la navigation sur Internet ce n'est pas très gênant puisqu'il suffit de rester sur une page, d'attendre 1 ou 2 secondes et la résolution fini par se faire et tout rentre dans l'ordre. Pour les jeux en lignes ou l'IPTV où les adresses de serveurs changent régulièrement c'est problématique car cela provoque au mieux un léger freeze, au pire une perte du service.
Edit 4 :Trouvé !
Il se trouve que le DNS 1.1.1.1 était enregistré comme DNS statique injecté et utilisé par l'interface de loopback.
Vérifiable via la commande "cat /run/resolv.conf.d/main" en SSHLes DNS 1.1.1.1 et 8.8.8.8 semblent fonctionner de façon instable. La plupart des résolutions DNS ne sont même pas transmises à ces serveurs (on reçoit un retour RST - Refus). Ces refus provoquaient les problèmes de connexion lors de la navigation Internet ou l'utilisation de services liés à Internet.
Le problème, c'est que dnsmasq était configuré pour utilisé tous les DNS enregistrés en conf.
Du coup, même en passant sur Auto DNS Server, le DNS 1.1.1.1 était systématiquement interrogé, en plus des DNS de Bouygues, provoquant donc des erreurs du fait des refus réguliers.
Après nettoyage des données persistantes UDAPI, fini les problème de connexion.
Ca n'explique toujours pas pourquoi le dashboard enregistre encore de nombreuses pertes de paquets... Je vais peut être continuer à chercher un peu
