Auteur Sujet: Récapitulatif des problèmes EN COURS (et non résolus) (Lu 90610 fois)

bolemo · « **Réponse #336 le:** 11 mars 2022 à 23:38:48 »

Citation de: Hugues le 11 mars 2022 à 22:16:22

Heureusement que n'importe quel abonné ne peut pas lancer un serveur DHCP chez lui pour répondre à tout le monde surtout, on met des sécurités, DHCP Snooping et RA guard

Oui, chez le FAI,
Mais là, c’est un abonné qui envoie des trames DHCPv6 dans l’arbre GPON donc ça se passe chez Covage… Et je ne pense pas que ma réponse ait été bloquée par Covage… Car s’ils le peuvent, il pourraient alors bloquer ces trames qui polluent l’ensemble du GPON (du moins dans le VLAN dédié à K-Net, mais géré par Covage…)

Fyr · « **Réponse #337 le:** 11 mars 2022 à 23:45:09 »

Citation de: bolemo le 11 mars 2022 à 23:38:48

Oui, chez le FAI,
Mais là, c’est un abonné qui envoie des trames DHCPv6 dans l’arbre GPON donc ça se passe chez Covage… Et je ne pense pas que ma réponse ait été bloquée par Covage… Car s’ils le peuvent, il pourraient alors bloquer ces trames qui polluent l’ensemble du GPON (du moins dans le VLAN dédié à K-Net, mais géré par Covage…)

Je croyais :
- que le fe80::/10 traversait pas les routeurs,
- que les clients communiquaient pas entre sans remonter au FAI
- que le GPON avait de la sécu et de la crypto pour pas voir les trames des autres.

Donc pas de boucle, c'est pas dans le GPON, ça remonte bien dans une infra au dessus de l'isolation inter client, et que qqchose rebalance un trafic broadcast DHCP solicit pour toi et les copains dans le domaine de broadcast.

bolemo · « **Réponse #338 le:** 11 mars 2022 à 23:53:40 »

Citation de: Fyr le 11 mars 2022 à 23:45:09

Je croyais :
- que le fe80::/10 traversait pas les routeurs,
- que les clients communiquaient pas entre sans remonter au FAI
- que le GPON avait de la sécu et de la crypto pour pas voir les trames des autres.

Donc pas de boucle, c'est pas dans le GPON, ça remonte bien dans une infra au dessus de l'isolation inter client, et que qqchose rebalance un trafic broadcast DHCP solicit pour toi et les copains dans le domaine de broadcast.

Je peux voir toutes les requêtes et réponses DHCP (et DHCPv6) du VLAN K-Net de ma boucle de collecte.
Pas celle de tous les clients K-Net, ni celles de tous les clients fibre (tout FAI) de ma boucle.

Plus exactement tout ce que le relais Covage de ma boucle de collecte reçoit et envoie.
Avant je pouvais aussi voir et envoyer toutes les trames ARP qui y passaient, mais Covage a limité à mon sous-réseau (ce qui est mieux niveau protection).

bolemo · « **Réponse #339 le:** 12 mars 2022 à 01:14:23 »

Pour Gaille :

Nouvelle version du script : https://brigadoon.fr/shared/test-connexion.sh

Même procédure à suivre pour l'installer.

Nouveau : notifications quand le statut de la connexion change

Fyr · « **Réponse #340 le:** 12 mars 2022 à 03:13:52 »

Citation de: bolemo le 11 mars 2022 à 23:53:40

Je peux voir toutes les requêtes et réponses DHCP (et DHCPv6) du VLAN K-Net de ma boucle de collecte.
Pas celle de tous les clients K-Net, ni celles de tous les clients fibre (tout FAI) de ma boucle.

Plus exactement tout ce que le relais Covage de ma boucle de collecte reçoit et envoie.
Avant je pouvais aussi voir et envoyer toutes les trames ARP qui y passaient, mais Covage a limité à mon sous-réseau (ce qui est mieux niveau protection).

Y a des choses "normales" de voir. Surtout quand y a du "broadcast" en jeu. Y a les papotages de switchs , routeurs que tu peux difficilement supprimer. Un discover/solicit on devrait même pas le voir, la réponse oui. Y a un switch qui rejoue le broadcast du discover/solicit avant d'atteindre le proxy DHCP. Tant que tu vois pas le trafic utile des autres ça va.

thedark · « **Réponse #341 le:** 12 mars 2022 à 09:06:20 »

Citation de: thedark le 11 mars 2022 à 13:43:59

Sinon vu sur facebook

https://www.k-net.fr/etat-du-reseau-et-des-services/

Citer

FTTO - 11/03/2022

Incident général backbone - Fin 22H00

22h30 : L'incident générique est terminé. Le service est en mode nominal depuis 22H00. Nous vous invitons à vérifier la bonne remontée des services et de signaler de façon unitaire au travers des outils, tout impact résiduel constaté.
20h30 : Afin de pallier aux effets de bord, nous allons redémarrer un équipement d’ici 21H30.
19h30 : La nouvelle carte a été insérée dans le châssis avec succès. Nos équipes d'ingénierie investiguent en raison de quelques effets de bord subsistants.
17h30 : Les services sont maintenant stables suite au remplacement d’une carte sur notre équipement cœur de réseau. Nous vous invitons à vérifier la bonne remontée des services et de nous signaler de façon unitaire, tout impact constaté après 17h. Une nouvelle carte est en cours d’acheminement afin de rétablir le portail extranet.
16h30 : L’intervention se poursuit. Une des cartes livrée est défectueuse. Une nouvelle livraison est en cours.
15h30 : Nous rencontrons des difficultés à installer une partie du matériel de spare. Des investigations plus approfondies sont en cours.
14h30 : Toutes les collectes clients sur Equinix sont remontés. Les services IPT restent impactés par l’incident. L’accès au portail SAV est dégradé. L’intervention se poursuit.
13h30 : Les services remontent progressivement. Le portail SAV est de nouveau accessible. L’intervention se poursuit.
12h30 : L’intervention se poursuit. Une pièce défectueuse a été remplacée. Le technicien a donné la main à distance sur l’équipement à notre support niveau 3.
11h45 : Les matériels de spare sont arrivées sur site. L’intervention de remplacement est en cours.
11h00 : Arrivée du technicien sur le site d’Equinix. Début des investigations. Acheminement du spare en cours.
10h15 : Le technicien rencontre des difficultés de circulation. Arrivée estimée vers 10h45.
10h00 : L’hébergeur nous confirme un défaut de carte. Une solution provisoire est en cours d’étude en attendant la livraison du spare.
09h00 : ETA prévue aux alentours de 10h00.
08h30 : Le technicien se rend sur site. Le fournisseur est également déclenché pour investigations.
08h00 : Suspicion d’un défaut équipement cœur de réseau. Déclenchement du mainteneur équipement pour investigations sur site.
07h30 : Le support Niveau 3 est sollicité afin de venir en renfort au support Covage dans les investigations.
07h00 : Nombreuses signalisations clientes remontant la perte des services.
03h30 : Le manager de crise Covage est sollicité afin d’escalader le service informatique pour les premiers diagnostics.
01h30 : Le service informatique Covage est sollicité.
01h15 : Première signalisation cliente remontant la perte de services.
01h00 : Début des investigations par le support Covage.
00h50 : Perte d’accès de plusieurs outils Covage incluant les outils de supervision.

Je ne vois pas le rapport avec la panne K-NET.
https://old-espace-client.covage.com/index.php?lang=fr

gigi · « **Réponse #342 le:** 12 mars 2022 à 11:33:20 »

bonjour,

quelqu'un aurait-il la nouvelle procédure pour configurer l'adaptateur téléphonique SPA112, pour récupérer ma ligne fixe.
Comme j'ai un routeur perso, le personne du support hier m'a dit qu'elle m'envoyait ça........je n'ai rien reçu $:-\$

Merciii d'avance

bolemo · « **Réponse #343 le:** 12 mars 2022 à 11:36:50 »

Citation de: gigi le 12 mars 2022 à 11:33:20

bonjour,

quelqu'un aurait-il la nouvelle procédure pour configurer l'adaptateur téléphonique SPA112, pour récupérer ma ligne fixe.
Comme j'ai un routeur perso, le personne du support hier m'a dit qu'elle m'envoyait ça........je n'ai rien reçu $:-\$

Merciii d'avance

Je t'envoie ça bientôt

Gaille · « **Réponse #344 le:** 12 mars 2022 à 11:54:54 »

Citation de: bolemo le 12 mars 2022 à 01:14:23

Pour Gaille :
Nouvelle version du script : https://brigadoon.fr/shared/test-connexion.sh
Même procédure à suivre pour l'installer.
Nouveau : notifications quand le statut de la connexion change

👍 super

🙏

bolemo · « **Réponse #345 le:** 12 mars 2022 à 11:55:13 »

Citation de: gigi le 12 mars 2022 à 11:33:20

bonjour,

quelqu'un aurait-il la nouvelle procédure pour configurer l'adaptateur téléphonique SPA112, pour récupérer ma ligne fixe.
Comme j'ai un routeur perso, le personne du support hier m'a dit qu'elle m'envoyait ça........je n'ai rien reçu $:-\$

Merciii d'avance

Il te faut d'abord obtenir de K-Net un nouvel identifiant SIP (sur le nouveau domaine sipfr.k-net.fr), à demander au téléphone, et dans les minutes qui suivent, ils te l'envoient par courrier électronique.
Apparemment, ils ont oublié dans ton cas ?

Une fois que tu as le SIP, voici la procédure que K-Net m'avait transmise :

bolemo · « **Réponse #346 le:** 12 mars 2022 à 13:39:10 »

Citation de: Fyr le 12 mars 2022 à 03:13:52

Y a des choses "normales" de voir. Surtout quand y a du "broadcast" en jeu. Y a les papotages de switchs , routeurs que tu peux difficilement supprimer. Un discover/solicit on devrait même pas le voir, la réponse oui. Y a un switch qui rejoue le broadcast du discover/solicit avant d'atteindre le proxy DHCP. Tant que tu vois pas le trafic utile des autres ça va.

Oui, bien sûr…
Voir les paquets multicast/broadcast de la boucle de collecte, ça semble logique.
Et le SOLLICIT DHCPv6 est un paquet multicast (eth. 33:33:00:01:00:02 et ll. ff02:0000:0000:0000:0000:0000:0001:0002).
Cela dit, comme tu le précise, 0001 0002 en multicast, c'est seulement les agents DHCP, donc la passerelle Covage ne devrait router ces paquets que vers le relais DHCP et pas vers les autres clients…

Les réponses du relais ne devraient pas être visibles, car la réponse se fait en unicast sur le ll. du client ayant envoyé le SOLLICIT.

tiens j'ai pas essayé de répondre à la boucle folle sur ff02::1
Je vais essayer cela…

En tous cas, ces paquets sont toujours là… Et en montant le CPU de l'ONT à 30% (au lieu de 3%), ça augmente sa température de 1 à 2°C…
Depuis un peu plus de 58 heures que cela à commencé ça représente plus de 800 million de paquets envoyés partout, et 1,3 milliard de kilo-octets de pollution sur le GPON…

[EDIT] réponse sur ff02::1 ne donne rien… La boucle est sourde.

Steph · « **Réponse #347 le:** 12 mars 2022 à 13:47:31 »

Citation de: Steph le 11 mars 2022 à 16:49:43

Uptime robot me spam dur aussi!
Visiblement, il n'y a pas que le 14 et 91 qui est touché chez Covage!
Le 74 n'est pas terrible non plus!
Je vais regarder si j'ai les trames IPV6 toutes folldingo...

Pas de trame V6 bizarre sur Covage 74 donc rien à voir avec le 14 et 91.

Torts partagés entre K-net (Covage74?) et moi :
Mon routeur perso qui me sert de secours WAN et de point d'accès Wifi a obtenu de la part du relais DHCP Covage une adresse IP publique alors qu'il n'aurait pas du pour deux raisons :

- Désactivé en principe de mon coté (en ce moment, la K-box fait le job), et pas de spoof @MAC, ni de @MAC transmise au support. Je n'ai pas compris pourquoi l'interface est remontée toute seule...

- Apparemment, Il n'y a plus de contrôle de @MAC coté Covage-K-net?? Ou alors, la mac de mon routeur perso n'est pas si unique que cela et référencée chez K-net?

Du coup, j'avais deux IP publiques K-net, la normale sur la K-box et une autre sur mon routeur perso. J'imagine que c'est cela qui faisait sauter les ACL d'où le bagottage de 5 minutes.

J'ai rectifié le tir.