Messages

La maintenance est terminée.

Le mauvais temps ne favorisant pas la maintenance, l'opération est prolongée quelques minutes.
Merci de votre compréhension.
D.M.

https://forum.caps.services/index.php/topic,9317.0.html

Début des travaux.

Bonjour,
les factures sont éditées vers le 22 du mois pour le mois suivant.
En cas de résiliation un prorata est calculé et les jours suivant la date de résiliation non consommés sont déduits des frais de résiliation éventuels.

idem au moment de la souscription, la première facture prend en compte la période entre la date d'activation et le 1er du 1er mois complet facturé.
D.M.

L'Edge du CIXP sera remplacé fin janvier début février.
Avez vous noté des changements au niveau des routes depuis le changement de l'edge de paris ?
D.M.

Bonne et heureuse année à toute et à tous.
D.M.

Bonjour,
Nous sommes contraints de couper un grand nombre de chaines cette APM pour mettre en sécurité notre site de captation principal à cause de la Tempête actuellement en cours.
La maintenance est prévue de 14h00 à 16H00.
Veuillez nous excuser pour la gêne occasionnée.

D.M.

Petit retour à chaud de cette opération dont les objectifs fixés sont atteints.

Cela se traduit par une meilleur utilisation des ressources. On mesure une augmentation significative des volumes échangés aux heures de pointe et une utilisation bien plus qualitative des ressources dont nous disposons.

Il s'agit de l'analyse de notre point de vue, n'hésitez pas à partager vos retours.

On suspend nos travaux sur l'infra jusqu'au 12 janvier 2026.
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.

Bonsoir,
je comprends votre agacement, c'est tout a fait normal.
Pour compléter, il y a eu deux doubles prélèvements :
En novembre 2023 suite au remplacement à la migration du S.I.
En Mai 2024 suite à une erreur de l'intermédiaire bancaire dont les API renvoyaient des données incohérentes et non documentées.
La relance automatique se base sur des données d'état du compte client après synchronisation des flux de banque.
Un algo fait le rapprochement des flux.
La brique de relance a fait ce pour quoi elle est faite, relancer les impayés sur la base des données dont elle dispose.
Données incomplètes dans votre cas. Comme évoqué juste au dessus, nous travaillons sur la qualité et la fiabilisation de la donnée.
Merci de votre confiance.

Bonjour,
L'équipe ADV et comptable travaille ardûment à la qualité des chiffres dans nos outils.
Plusieurs abonnés ont sollicité le support concernant des relances.
Expertise en cours.
La piste retenue serait un problème d'import du flux bancaire vers le 24 novembre 2025.
D.M. (de la part de comptabilité)
Joyeux noël à toutes et à tous.

Cher Vivien,
La suite du chantier V6 c'est de rétablir la majorité des services en IPv6. Comme ce forum par exemple.
Après je peux juste te dire que l'on va le faire porte de collecte par porte de collecte, mais que l'ordre n'a pas encore été choisi ? On avancera O.I. par O.I. en fonction des obstacles et des dispos des uns et des autres ça ira plus ou moins vite.
En tout cas nos sessions BGP V6 sont opérationnelles sur nos transitaires, nos IXPs et même K-SYS.

D.M.

Bonsoir,
Les derniers IPX ont été migrés ce jour, dans l'après midi.
Normalement, les routes vers autres AS doivent être plus précises donc les chemins plus optimisés.
Prochaine étape le retour de l'IPV6.
N'hésitez pas à faire des retours.
D.M.

Merci Steph