Auteur Sujet: [SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6  (Lu 41000 fois)

0 Membres et 1 Invité sur ce sujet

patrick_01

  • Abonné MilkyWan
  • *
  • Messages: 327
  • 01
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #228 le: 29 mai 2022 à 15:30:21 »
ok je sors...

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 625
  • Grandcamp Maisy (14)
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #229 le: 30 mai 2022 à 14:59:03 »
Bon, pour le spam DHCPv6, j'ai fait un tweet…

Sinon, par curiosité, j'ai enregistré tous les paquets ARP qui sont passé sur la collecte sur une durée de 24 heures.
Surtout des ARP Request, quelques Reply.

J'ai obtenu un peu plus d'une centaine de paires MAC/IP publiques.
Toutes ces IP sont sur 10.2.0.211 (confirmé par traceroute).

Une de ces IP est un 100.64.0.X avec un MAC Icotera
Après j'ai :
17 185.4.76.X dont une qui a pour nom de domaine agence.dea.kwaoo.net (l'agence K-Net de Deauville ?)
1 185.66.X.X
2 185.219.X.X
13 185.238.X.X
2 185.251.X.X
60 2.59.X.X (c'est mon sous-réseau)
1 45.15.61.X avec une MAC Icotera qui ne passe pas par 10.2.0.211, mais après la collecte K-Net va directement sur 178.250.208.166
20 45.83.X.X
2 92.118.99.X

Je ne pense pas voir tous les clients K-Net du Calvados (je ne vois pas par exemples de requêtes ARP venant de la K-Box qui spam en DHCPv6 en ce moment, ou de certains appareils qui fuient en mDNS/NetBIOS).

Pareil pour les requêtes DHCP(v4), j'en vois beaucoup moins.
Il y a donc un filtrage partiel (selon les switches ?), dejà par le fait que je ne vois pas la plupart des ARP Reply, et que pour des Reply que je vois, je ne vois pas forcement les Request.
Les fuites mDNS, APIPA, NetBIOS et DHCPv6 passent au travers de ce filtrage cependant.

Bref…

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 625
  • Grandcamp Maisy (14)
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #230 le: 31 mai 2022 à 14:01:52 »
Spam toujours en cours…

On peut voir en situation de spam les fuites APIPA K-Box qui reviennent, et la lutte entre le paquet magique et le retour de ces fuites.
Dès que le spam DHCPv6 aura cessé, le paquet magique vaincra à nouveau  ;D


bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 625
  • Grandcamp Maisy (14)
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #231 le: 01 juin 2022 à 11:45:15 »
Toujours là… FB ne doit pas trop avoir le temps de faire du service avec sa campagne électorale…

Mail envoyé au NOC, on verra bien.

Je ne vois pas beaucoup de personnes du 14 se plaindre de micro-coupures ou d'instabilités… La plupart de ceux qui sont sur le forum ont du matériel perso, donc en principe pas ou peu affectés, mais ceux avec des K-Box devraient l'être.

Steph

  • Abonné K-Net
  • *
  • Messages: 7 714
  • La Balme de Sillingy 74
    • Uptime K-net
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #232 le: 01 juin 2022 à 12:07:50 »
Sur Covage 74 (ex tutor), j'ai la chance de ne voir aucun paquet qui ne m'est pas destiné!
0 ARP
0 DHCP4
0 en broadcast.

J'en suis presque à me demander si je regarde comme il faut avec Wireshark et le port mirroring!

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 625
  • Grandcamp Maisy (14)
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #233 le: 01 juin 2022 à 12:56:52 »
Sur Covage 74 (ex tutor), j'ai la chance de ne voir aucun paquet qui ne m'est pas destiné!
0 ARP
0 DHCP4
0 en broadcast.

J'en suis presque à me demander si je regarde comme il faut avec Wireshark et le port mirroring!

Je pense que ta collecte est propre… Comme celle de pju91 et une majorité de collectes en fait.
Ta connexion L2 et L3 se fait strictement entre toi et ta passerelle, et uniquement pour les paquets qui te concernent. Bref, un paquet venant d'un client n'est envoyé que vers la passerelle, puis le routeur de collecte, mais jamais vers les autres clients. Idem, le message (réponse ARP par exemple) de la passerelle n'est envoyé qu'au client concerné. Bref, du switch bien managé.

C'est vraiment quelques collectes qui ont ce problème.
Dans le 14, je vois certains ARP, mais pas tous, je vois des Reply mais pas les Request, ou l'inverse… Bref, c'est pas homogène donc je pense que c'est des réglages de switches qui ici où là laissent passer. Depuis 2018, il y a eu des progrès, puisqu'avant je pouvais faire un arping (recherche active) sur tous les clients du 14 et du 91 et obtenir leur IP/MAC ! Plus récemment, le 91 n'est plus visible dans la collecte du 14, donc petit à petit, certains appareils sont configurés correctement.

Il faudrait que Covage passe en revue tous les switches et leurs configs dans les PM et NRO du 14 et du 91…
Hugues ou autres experts pointus réseaux pourraient probablement nous donner des détails techniques.

Dans le 14, ça semble affecter un peu moins (moins de monde ou moins de plaintes ici), mais dans le 91 qui a déjà de nombreux problèmes OI (far west des sous-maltraitants), ce manque d'étanchéité est très malvenu et rends les choses encore plus compliquées (et frustrantes pour les clients).

Le problème est que Covage et K-Net sont tous deux fautifs (K-Net portant la responsabilité des Icotera défectueuses, et Covage portant la responsabilité du manque d'étanchéité de la collecte).
Résultat, pendant longtemps (et encore aujourd'hui), ils se rejettent la balle, disant que si l'autre résout sa part du problème, alors la totalité du problème est résolue (si K-Net n'a plus de problème de K-Box, alors plus de problème [visible] pour les clients ; si Covage résout son manque d'étanchéité, alors peu importe si les K-Box fuient, cela n'aura plus de conséquence…).

Mais en réalité, les deux doivent arranger leur part du problème !
Une box qui a ces problèmes n'est pas une bonne chose, et une collecte qui n'est pas étanche n'en est pas une non plus (même en mettant de côté les K-Box, je vois plein de paquets mDNS, NetBIOS et autres venant de routeurs perso, etc…)

K-Net va à priori remplacer les K-Box petit à petit (rien de clair ni d'officiel cependant).

Covage lui, est silencieux, comme à son habitude depuis le début (depuis que j'ai essayé de les contacter sur le sujet dès 2020, je n'ai pas eu un seul contact ou retour de leur part…). Je comprends qu'ils n'ont pas normalement à entrer en contact avec les clients des FAI, mais ici mon approche n'est pas celle d'un client lambda, et mon attitude a toujours été purement constructive et dans le but de les aider (gratuitement en plus).

Bref…

pju91

  • Abonné Free fibre
  • *
  • Messages: 878
  • 91
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #234 le: 01 juin 2022 à 14:05:48 »
Je pense que ta collecte est propre… Comme celle de pju91 et une majorité de collectes en fait.
Ou bien ton port mirroring n'a pas fonctionné. En ce qui me concerne, je n'avais pas réussi sur ma K-Box (OK dans le panel, mais rien sur le port LAN supposé miroir du port WAN). J'avais dû brancher l'analyseur directement sur l'ONT pour vérifier que c'était "propre".
Dans le 14, je vois certains ARP, mais pas tous, je vois des Reply mais pas les Request, ou l'inverse…
La logique voudrait que tu voies tous les ARP requests (en broadcast) mais que tu ne voies pas les replies (en unicast), sauf les "gratuitous ARP" (en broadcast), facilement reconnaissables (même IP source et dest).
Le problème est que Covage et K-Net sont tous deux fautifs (K-Net portant la responsabilité des Icotera défectueuses, et Covage portant la responsabilité du manque d'étanchéité de la collecte).
Résultat, pendant longtemps (et encore aujourd'hui), ils se rejettent la balle, disant que si l'autre résout sa part du problème, alors la totalité du problème est résolue (si K-Net n'a plus de problème de K-Box, alors plus de problème [visible] pour les clients ; si Covage résout son manque d'étanchéité, alors peu importe si les K-Box fuient, cela n'aura plus de conséquence…).
L'absence de réaction de Covage est assez incompréhensible, d'autant plus qu'ils font maintenant l'objet d'une plainte par Paris-Saclay.
Mais en réalité, les deux doivent arranger leur part du problème !
Une box qui a ces problèmes n'est pas une bonne chose, et une collecte qui n'est pas étanche n'en est pas une non plus (même en mettant de côté les K-Box, je vois plein de paquets mDNS, NetBIOS et autres venant de routeurs perso, etc…)
C'est en priorité le problème de la collecte qu'il faudrait régler, puisque tu constates que des équipements autres que K-Box se comportent mal.

Celà dit, la "loi de Postel" (Be conservative in what you do, be liberal in what you accept from others) qui est un des principes de la robustesse des protocoles, et du protocole IP en particulier, puisque ça figure dans le RFC 760 n'est plus franchement respectée par les fournisseurs d'équipements. Je ne ferai pas d'autre commentaire type ancien combattant sur le thème c'était mieux avant ...
K-Net va à priori remplacer les K-Box petit à petit (rien de clair ni d'officiel cependant).
Mouais ... Si c'est uniquement source = FB, ça reste à voir.

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 625
  • Grandcamp Maisy (14)
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #235 le: 01 juin 2022 à 15:33:47 »
La logique voudrait que tu voies tous les ARP requests (en broadcast) mais que tu ne voies pas les replies (en unicast), sauf les "gratuitous ARP" (en broadcast), facilement reconnaissables (même IP source et dest).
Oui et non…

Non, car je vois un paquet ARP non broadcast (oui, un seul) dans cette période de 24h, répété plein de fois évidemment (une des fuites APIPA) :
root@HERMES:/tmp/mnt/sda1$ tcpdump -tnnevvv -r merged.pcap not broadcast | sort | uniq
reading from file merged.pcap, link-type EN10MB (Ethernet)
00:11:33:55:77:cc > 00:11:33:55:77:bb, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 169.254.1.2 is-at 00:11:33:55:77:cc, length 46
Cela signifie que tous les autres paquets ARP (Request and Reply) que j'ai vu sont en broadcast.

Oui aussi, parce que si je vois des Request sans forcément voir les Reply, et des reply sans forcément voir les Request, ça peut s'expliquer sur les Reply son spontanés (gratuitous) sans répondre à un Request.

Peu de Reply différents en 24 heures :
root@HERMES:/tmp/mnt/sda1$ tcpdump -tnnevvv -r merged.pcap arp[6:2] == 2 | sort | uniq
reading from file merged.pcap, link-type EN10MB (Ethernet)
00:11:33:55:77:cc > 00:11:33:55:77:bb, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 169.254.1.2 is-at 00:11:33:55:77:cc, length 46
00:90:7f:a6:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 185.4.76.xx is-at 00:90:7f:a6:xx:xx, length 46
04:d5:90:49:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 2.59.237.xx is-at 04:d5:90:49:xx:xx, length 46
90:6c:ac:84:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 2.59.238.xx is-at 90:6c:ac:84:xx:xx, length 46
e0:23:ff:6d:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 185.238.4.xx is-at e0:23:ff:6d:xx:xx, length 46
e8:1c:ba:36:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 2.59.238.xx is-at e8:1c:ba:36:xx:xx, length 46
e8:ed:d6:3b:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 45.83.230.xx is-at e8:ed:d6:3b:xx:xx, length 46
Donc peut-être des clients assez proches physiquement (sur un même switch au NRO par exemple), ou simplement peu de Reply gratuitous en broadcast si ce que je vois en sont.
Ce qui est étonnant, c'est que je vois au moins un ARP Reply en unicast (cf plus haut), donc pourquoi je ne vois aucun autres Reply ARP unicast ?

Pour les Request :
root@HERMES:/tmp/mnt/sda1$ tcpdump -tnneq -r merged.pcap arp[6:2] == 1 | sort | uniq | wc -l
reading from file merged.pcap, link-type EN10MB (Ethernet)
143

Enfin non, surtout, car je ne vois ni ARP Reply ou Request venant de la plupart des MAC des appareils qui fuient en mDNS ou NetBIOS (donc depuis certains endroits, l'ARP est bloqué entre clients mais pas mDNS ou NetBIOS…), or ils doivent bien envoyer des ARP en broadcast… Je sais qu'on peut envoyer des Request en unicast (je le fais bien avec mon programme spécial pour les ACL DHCP), mais c'est rare quand même, car très spécifique (en général, le but d'un Request est d'être large pour trouver la cible)…

Sinon, sur une période de 24h, je ne vois que 150 types de paquets ARP différents :
root@HERMES:/tmp/mnt/sda1$ tcpdump -tnneq -r merged.pcap | sort | uniq | wc -l       
reading from file merged.pcap, link-type EN10MB (Ethernet)
150

Mais beaucoup sont répétés sur cette période :
root@HERMES:/tmp/mnt/sda1$ tcpdump -tnneq -r merged.pcap | wc -l             
reading from file merged.pcap, link-type EN10MB (Ethernet)
59132

Je dois aussi préciser que c'est en fait sur 23h, car j'ai effacé par erreur un des 24 pcap horaire de ma capture, mais ça ne change pas grand chose.

L'absence de réaction de Covage est assez incompréhensible, d'autant plus qu'ils font maintenant l'objet d'une plainte par Paris-Saclay.C'est en priorité le problème de la collecte qu'il faudrait régler, puisque tu constates que des équipements autres que K-Box se comportent mal.

Le silence de Covage est vraiment étonnant, mais constant.

ClemCR16

  • Abonné K-Net
  • *
  • Messages: 13
  • Val d'Arry 14
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #236 le: 01 juin 2022 à 15:35:43 »
Je suis toujours affecté par cette panne désormais récurrente, bientôt ce sera 2 jours de coupure par semaine, pour une fibre pro c'est le top franchement ... Avec bien évidemment aucun suivi, aucune communication ni rien !
Personnellement, je les supporte jusqu'à début Juillet car pas d'autre choix suite à un soucis d'adresses, mais après la résolution du soucis d'adresse, c'est ciao !

Et oui du coup Bolemo tu disais qu'il y avait moins de plaintes dans le 14, je pense juste que les gens sont fatigués de la situation tout comme moi..
En revanche, merci pour ton suivi des incidents a chaque fois c'est vraiment gentil de nous tenir informer !

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 625
  • Grandcamp Maisy (14)
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #237 le: 01 juin 2022 à 15:46:08 »
Je suis toujours affecté par cette panne désormais récurrente, bientôt ce sera 2 jours de coupure par semaine, pour une fibre pro c'est le top franchement ... Avec bien évidemment aucun suivi, aucune communication ni rien !
Personnellement, je les supporte jusqu'à début Juillet car pas d'autre choix suite à un soucis d'adresses, mais après la résolution du soucis d'adresse, c'est ciao !

Et oui du coup Bolemo tu disais qu'il y avait moins de plaintes dans le 14, je pense juste que les gens sont fatigués de la situation tout comme moi..
En revanche, merci pour ton suivi des incidents a chaque fois c'est vraiment gentil de nous tenir informer !

Ou les Calvadosiens sont plus patients et râlent moins  ;) ;D

De rien, ça fait plaisir de voir que c'est utile et que ça aide. Maintenant, contrairement aux fuites APIPA K-Box, je ne peux rien faire pour arrêter moi-même ces spams quand ils se produisent (j'ai essayé…)

pju91

  • Abonné Free fibre
  • *
  • Messages: 878
  • 91
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #238 le: 01 juin 2022 à 15:56:29 »
Oui aussi, parce que si je vois des Request sans forcément voir les Reply, et des reply sans forcément voir les Request, ça peut s'expliquer sur les Reply son spontanés (gratuitous) sans répondre à un Request.
Les ARP replies en broadcast qualifiés de "gratuits" (non sollicités) sont a priori utilisés pour la prévention de la duplication d'adresse IP, voir RFC 5227. Ils doivent avoir la même IP en source et en destination, ce qu'on ne peut pas voir sur ton tcpdump.

De même les "requests" que tu vois sont peut-être des "ARP announcements", plutôt que des vraies "requests". Dans ce cas, ils doivent également avoir la même adresse IP source et destination.

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 625
  • Grandcamp Maisy (14)
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #239 le: 01 juin 2022 à 16:20:17 »
Les ARP replies en broadcast qualifiés de "gratuits" (non sollicités) sont a priori utilisés pour la prévention de la duplication d'adresse IP, voir RFC 5227. Ils doivent avoir la même IP en source et en destination, ce qu'on ne peut pas voir sur ton tcpdump.

De même les "requests" que tu vois sont peut-être des "ARP announcements", plutôt que des vraies "requests". Dans ce cas, ils doivent également avoir la même adresse IP source et destination.

En ce cas, je ne vois pas de paquets gratuitous Reply.
Et je vois bien quelques announcements who-has AA:BB:CC:DD tell AA:BB:CC:DD, mais c'est une minorité, la plupart sont des Request.