Coupures intempestives !

[K-net TEAM - D.M.]

Bonsoir,

Les propos de Steph01 sont précis...pas mieux ! sans filtrer en mode on prend tout et on filtrera ça peut le faire.
La capture sera plus grosse mais bon.

si on se base sur un fonctionnement normal DHCP
Quand votre routeur dispose d'une IP attribuée par un serveur DHCP, le serveur DHCP fixe un temps pour le LEASE.
Selon les plaques et les O.I. nous réglons entre 1h00 et 4h00 le temps du LEASE.

Tout bon client DHCP qui se respecte fait une requête DHCP pour renouveler son lease à 50% du temps du lease.
Il est prudent il anticipe...

Il fut un temps....j'adore employer le passé pour les problèmes merdiques que j'ai trouvé en arrivant chez K-nt où la jeune machine qui hébergeait les DHCP plantait les machines virtuelles lors des sauvegardes...

Bref, dans ce cas les lease expiraient car il n'y avait plus de serveur pour répondre et Plop les clients de ce serveur DHCP n'avaient plus de services et demandaient tous une IP toutes les 3-4 secondes jusqu'au retour du service.

En tout état de cause, le problème n'est de mon point de vue pas réseau. Peut être juste un manque de CPU, le routeur se protège en cas de grosse sollicitation et lâche l'ip WAN. Si encore il disposait d'un port console, c'est pas sexy mais au moins au saurait ce qu'il se passe. Il est peut être caché le port console... parfois il est banalisé.

Est ce que le routeur dispose d'une fonction anti DDOS ou des services cyber embarqués.

Essayez de faire un ping en continu côté lan tout en répétant un gros transfert. si le ping derive ou que le routeur ne répond plus c'est qu'il est trop occupé et qu'il n'arrive plus a fournir donc il ne traite plus les demandes non prioritaires comme le ping.

Est ce qu'il dispose des derniers firmware.

Le phénomène est peut être documenté chez le fabriquant.

Je peux également vous faire parvenir une box histoire de comparer. Peut être avec vous un autre routeur ?

Le test ultime c'est de faire sans le routeur juste un PC en direct sur l'ONT...
fixons un rendez vous et cherchons ensemble en live.

On va bien finir par trouver une méthode permettant de reproduire le phénomène et faire émerger des éléments pour statuer de façon pertinente sur le problème.

D.M.

[sebdepringy]

Bonjour DM,

Désolé du retour tardif, pour les routeurs en 3ans, j'en ai essayés :

Asus RT-AC66U
Asus RT-AC68U
Asus RT-AX56U
Netgear R6400
J'ai essayé aussi pfsense sur un pc fixe
Asus TUF-AX4200


Au travail, avec ces routeurs sur ligne Foliateam avec IP Fixe les routeurs ne posent aucuns problèmes, la différence c'est qu'ils ne sont pas en DHCP, je rentre manuellement les ip fixes.

En gros si je ne bride par mes Synology a 450/500Mb il y a décrochage du routeur/ligne, la même chose entre site je n'ai aucun décrochage

Pour répondre a la question du PING, ras tout va bien, d'ailleur j'ai bien la main sur mon routeur quoi qu'il arrive, sauf que le dhcp distant est hs

[sebdepringy]

Bon visiblement knet clos plus vite les tickets plutôt que de les résoudre

[K-net TEAM - D.M.]

Bonsoir oui on clôture les tickets.
Dans le volume des tickets traités, malheureusement sur le segment FTTH plus de 90% sont des problèmes de coupure physique de la liaison une fois le problème signalé, le client est réparé. On pourrait presque clôturer après signalement.
Rarement les clients appellent pour dire c'est réparé, bisous !

S'agissant de ce dossier, une capture de paquets couvrant une période où le problème se présente permettra de suivre les demandes DHCP du routeur et les réponses du serveur DHCP. Normalement, on devrait voir le routeur dire, s'il a une réponse, je ne veux pas de cette réponse parce que !
S'il n'a pas de réponse on devrait le voir demander encore et encore.
Avec le Pfsense évoqué plus haut, vous pouvez faire cette capture, avec les autres je ne sais pas !


Idéalement faut tout capturer et filtrer ensuite.

Sur le segment FTTH nous utilisons le DHCP, sur d'autres segments on peut vous fournir un bloc IP dédié du /30 au /22, une passerelle dédiée...

Voici le conseil de "CHAT GPT" pour une capture ciblée :

Pour diagnostiquer un problème DHCP avec tcpdump, l'objectif est de capturer les échanges entre le client et le serveur DHCP, qui utilisent UDP ports 67 (serveur) et 68 (client).

Commande de base (recommandée)
sudo tcpdump -i eth0 -n -vvv -s 0 -w dhcp_debug.pcap port 67 or port 68

Explication des options
-i eth0 : interface réseau (remplacer par la bonne interface, ex. ens192, wlan0)
-n : pas de résolution DNS (plus lisible, plus rapide)
-vvv : niveau de verbosité élevé (utile pour DHCP)
-s 0 : capture complète des paquets (important pour DHCP options)
-w dhcp_debug.pcap : écriture dans un fichier lisible avec Wireshark
port 67 or port 68 : filtre DHCP

Capture en clair (sans fichier)

Si tu veux simplement voir les échanges en temps réel :

sudo tcpdump -i eth0 -n -vvv port 67 or port 68
Capture côté client uniquement

Pour vérifier si le client envoie bien ses requêtes :
sudo tcpdump -i eth0 -n -vvv udp and src port 68

Capture côté serveur uniquement

Pour vérifier les réponses du serveur :

Sudo tcpdump -i eth0 -n -vvv udp and src port 67

Points clés à observer

Lors de l'analyse, tu dois voir la séquence DHCP classique :
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK

Si un message manque, cela oriente directement le diagnostic (pare-feu, relais DHCP, VLAN, etc.).


Dans la commande il y a le filtre, si pas d'anomalie DHCP, alors il suffit d'enlever le filtre Sans supplément, on peut même faire ça !

Oui. Si tu me fournis une capture non filtrée (pcap), je peux analyser le flux et identifier toutes les anomalies susceptibles d'entraîner la perte d'une adresse IP DHCP, de manière structurée et exhaustive.

Ce que je peux analyser précisément dans un pcap DHCP
1. Cycle DHCP complet

Vérification de la conformité et de l'ordre des messages :

DHCPDISCOVER

DHCPOFFER

DHCPREQUEST

DHCPACK / DHCPNAK
Détection de :

ACK manquant

OFFER multiples (serveurs concurrents)

NAK tardif ou inattendu

2. Durée de bail et renouvellement

Valeurs T1 / T2 / Lease Time

Tentatives de renouvellement (unicast vs broadcast)

Absence de réponse serveur lors du renew

Expiration du bail sans fallback valide

3. Conflits DHCP
Plusieurs serveurs DHCP répondant
Incohérence des Server Identifier
Changements d'IP serveur entre OFFER et ACK

4. Problèmes réseau sous-jacents
Pertes de paquets DHCP (DISCOVER sans OFFER)
Fragmentation ou MTU anormal
Réémissions excessives
Latence anormale entre messages

5. Relais DHCP / Option 82
Présence et cohérence de l'Option 82
Modification ou suppression par un équipement intermédiaire
Réponses rejetées par le serveur à cause de l'Option 82

6. Anomalies client
Reboot ou reset stack réseau
Envoi de DHCPDECLINE
Changement de MAC / Client-ID
Passage en APIPA (169.254.0.0/16)

7. Sécurité / filtrage
DHCP Snooping (ACK bloqués)
Firewall bloquant UDP 67/68
Réécritures de broadcast → unicast

8. Comportements non standards
ACK sans OFFER préalable
REQUEST pour une IP hors pool
Renouvellement vers un serveur incorrect
Incohérences dans les options DHCP (router, subnet, DNS)

Format attendu

Idéalement :
Fichier .pcap ou .pcapng

Indication du contexte :
Client OS (Linux, Windows, embedded, VM, etc.)
IP perdue immédiatement ou après un certain temps
Présence de VLAN, firewall, relais DHCP
Moment exact du symptôme si connu

Limites à connaître
Je détecte les anomalies visibles dans le trafic
Je ne peux pas inférer :
un bug interne du client sans manifestation réseau
une action locale hors réseau (script, agent, etc.)

Pourquoi se priver d'une capture ? la capture c'est la prise de sang du flux réseau !

A dispo pour trouver !
D.M.