La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => 
K-Net => Opérateurs grand public alternatifs => Incidents collectifs => Discussion démarrée par: Couin le 25 mars 2022 à 23:06:11
-
Bonjour ,
Boule verte clignotante sur la box, pas de net. Même constat chez d'autres ?
Et ENCORE juste avant le week end, donc bon pour minimum retour lundi ! Je commence là à en avoir marre.
Edit complément :
Avec routeur perso, IP WAN et DNS reçus, un tracert vers 1.1.1.1, seul 10.2.0.220 répond et après, vide intersidéral...
Bon WE
-
Depuis ici, 10.2.0.220 ne montre aucun signe de faiblesse…
Curieux, car si tu vois 10.2.0.220, c’est que ton IP est autorisée. Un problème de route ? Covage ou K-Net ?
À suivre…
Si tu me MP ton IP, je peux y placer une sonde.
-
Yop Bolemo,
Je t'ai envoyé un MP.
Oui peut etrepas de signe de faiblesse mais peut être l'équipement suivant qui est dans les choux ?
-
La sonde est là : https://smokeping.brigadoon.fr/?target=Divers.CapsCouin
Et 10.2.0.220 : https://smokeping.brigadoon.fr/?target=Divers.Covage91_ipv4
Pour l'instant, perte totale des paquets sur ton IP.
Ce qui est curieux, c'est que je suis de l'autre côté de 10.2.0.220 que toi, et que je l'atteins sans souci. Et toi tu l'atteins aussi… Mais 10.2.0.220 ne me route pas vers chez toi, et il ne te route pas vers le portail national Covage 10.2.0.4 puis le reste d'internet…
À priori problème de routage chez Covage donc.
-
Merci pour la sondery :)
bon ca va encore être un cirque à faire réparer ça ... :(
Je verrais demain si mon voisin est aussi impacté.
-
Merci pour la sondery :)
bon ca va encore être un cirque à faire réparer ça ... :(
Je verrais demain si mon voisin est aussi impacté.
Oui, plusieurs choses à vérifier :
– Voisinage, chez K-Net ou non.
– De manière plus générale, les autres clients K-Net ou non passant par 10.2.0.220 (donc offres actives Covage 91).
– Autres IP dans la même plage Je viens de faire un ping sur ton IP - 1 (l'IP juste avant la tienne sur la même plage), et ça fonctionne, donc pas un problème généralisé sur le subnet…
Ce n'est pas une rupture de ta fibre (tu as un signal), ni un problème DHCP ou d'ACL (tu as une IP et atteint 10.2.0.220).
-
Mon voisin (parrainé par le canard) est chez K-net.
Sur le SRO on est que 4 sur le bandeau covage, je ne sais pas qui sont les 2 autres abonnés.
Je ne connais pas d'autres abonnés en offre active covage, encore moins passant par 10.2.0.220 (d'où l'ouverture du sujet ici :P ) .
Pas de rupture fibre en effet, puisque PON vert fixe (du coup je n'ai même pas sorti le photomètre).
J'aurais préféré ne pas être seul impacté, j’aurais peut être plus de chance que ça bouge plus vite, mais là si c’est que moi qui me retrouve le bec dans l'eau :(
-
POC !
Voisin knet non impacté...
En file d'attente au support knet le canard.
-
POC !
Voisin knet non impacté...
En file d'attente au support knet le canard.
Donc du coup, pas de problème général Covage… Ce n'est à priori que toi.
Symptômes très curieux. Ta MAC est reconnue, tu obtiens IP et ACL sur la passerelle Covage 91 (10.2.0.220), mais la passerelle (toujours Covage 91) ne route pas ce qui vient de ton IP.
Et si je fais un traceroute vers ton IP, ça cherche à passer par 10.2.0.191 (un autre routeur Covage dans le 91)
traceroute to 185.4.XX.XX (185.4.XX.XX), 30 hops max, 60 byte packets
1 HERMES (192.168.0.1) 0.497 ms 0.431 ms 0.408 ms
2 tca.covage (10.2.0.211) 3.486 ms 3.468 ms 3.449 ms
3 * * *
4 collecte.k-net (10.2.0.5) 7.639 ms 8.108 ms 7.604 ms
5 collecte.covage (10.2.0.4) 8.413 ms 8.396 ms 8.380 ms
6 10.2.0.191 (10.2.0.191) 9.830 ms 8.844 ms 8.793 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
-
Faut toujours que ça tombe sur moi de toute façon ce genre de délire :(
Et le support noyé sous les appels , 6 places passés en 43 minutes, étant en position 6, même pas la peine d'attendre...
Ca commence à m'chauffer sévère... autant prendre un sosh a 15 balles ...
-
10.2.0.191 C'est Europ'Essonne je crois.
Donc c'est comme si Covage pensait que ton adresse se trouve plus à l'ouest et dépend du NRO Europ'Essone, puisque chercher à joindre ton IP va vers le routeur national Covage (10.2.0.4), qui lui route vers 10.2.0.191 au lieu de 10.2.0.220.
En gros, j'ai l'impression que pour une raison obscure, Covage a attribué ton IP sur le mauvais NRO en ce qui concerne les tables de routage.
Du coup, je pense que 10.2.0.220 fonctionne bien et route possiblement correctement ce que tu envoie… mais absolument rien ne revient vers toi car 10.2.0.4 envoie ce qui t'est destiné sur le mauvais NRO, donc par exemple ton ping vers 1.1.1.1 atteint peut-être bien 1.1.1.1, qui répond, mais la réponse est envoyée à 10.2.0.191 (au lieu de 10.2.0.220) qui lui ne sait plus ou router ensuite car tu n'est pas à Sarclay, mais Ormoy…
-
Mais qui fait des changements comme ça, un vendredi soir entre, quoi, 21h30 et 22h45 ? :-\
-
Bonjour,
Je pense avoir le même problème depuis vendredi soir tout les voyants au vert mais impossible d’avoir une connexion
-
Mais qui fait des changements comme ça, un vendredi soir entre, quoi, 21h30 et 22h45 ? :-\
J'ai l'impression par observation que les mises-à-jour de Covage, maintenances et modifications sont implémentés en soirée, dans ces heures là.
Donc pour je ne sais quelle raison, leur base de données pour le routage a été modifiée dans la journée (corruption de donnée, erreur humaine, que sais-je ?), et cela a pris effet lorsqu'un script de maintenance a appliqué ces modifications en soirée.
-
Bonjour,
Je pense avoir le même problème depuis vendredi soir tout les voyants au vert mais impossible d’avoir une connexion
Tout à fait possible.
Peux-tu faire un ping vers 10.2.0.211 (Covage 14) ?
Puis vers 10.2.0.4 (Covage global) ?
Et vers 1.1.1.1 ?
Si le premier fonctionne, et pas les autres, tu as le même symptôme que Couin, et donc probablement un problème issu de la même cause (routage Covage).
Si tu me MP ton IP, je peux faire un traceroute et voir sur quel NRO Covage pense que tu as déménagé ;D
Je peux aussi mettre une sonde si tu le souhaites (pour monitorer à l'avenir)
-
Si c'est ça, quelle idée de faire des maintenances le vendredi soir juste avant le WE où il n'y a plus personne, tout le contraire de ce qu'on doit faire en maintenance.
Bonjour,
Je pense avoir le même problème depuis vendredi soir tout les voyants au vert mais impossible d’avoir une connexion
Bonjour, sur votre box, le globe terrestre est vert fixe ou clignotant ? (Après redémarrage box)
Edit : Pas de ping vers 211 et 4, ni 1.1.1.1 de mon coté.
-
Sur ma box le globe est vert fixe.
Quand je Ping les adresses 75% de perte de paquets
-
Si c'est ça, quelle idée de faire des maintenances le vendredi soir juste avant le WE où il n'y a plus personne, tout le contraire de ce qu'on doit faire en maintenance.
Je pense que tous les soirs, un script implémente les modifications apportées dans les bdd de Covage. J'ai remarqué que beaucoup de pannes et de résolutions se déroulaient dans ces plages horaires.
Après, l'idée de ne pas faire de modification vendredi soir n'est pas bête… Les modification effectuées dans la journée de vendredi devraient être implémentés dimanche soir.
Et tant qu'à faire, au lieu d'une plage horaire autour de 22h (où les gens utilisent encore internet, la TV…), 3h ou 4h du matin serait plus discret.
Edit : Pas de ping vers 211 et 4, ni 1.1.1.1 de mon coté.
Logique, car depuis chez toi, tout cela se trouve après 220, le dernier routeur qui sait où tu es. Au delà, ça part chez 191.
-
Sur ma box le globe est vert fixe.
Quand je Ping les adresses 75% de perte de paquets
C'est à priori un tout autre problème ici…
La route vers chez toi est correcte (on est voisin en sous-réseau d'ailleurs), ça cherche bien à passer par 211, donc ça c'est bon :
traceroute to 2.59.XX.XX (2.59.XX.XX), 30 hops max, 60 byte packets
1 HERMES (192.168.0.1) 0.587 ms 0.519 ms 0.493 ms
2 tca.covage (10.2.0.211) 5.790 ms 5.773 ms 5.756 ms
3 * * *
4 collecte.k-net (10.2.0.5) 9.904 ms 9.885 ms 9.870 ms
5 collecte.covage (10.2.0.4) 10.089 ms 10.071 ms 10.249 ms
6 tca.covage (10.2.0.211) 9.793 ms 7.196 ms 7.167 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Après, as-tu activé les réponses ICMP sur ta box ? Sans cela tout ping vers chez toi sera sans succès.
Maintenant tu as bien une connexion, car des paquets passent…
La raison des pertes des ¾ des paquets reste à déterminer et cela est bien entendu totalement anormal.
-
D’accord merci, on va attendre que sa revienne alors.
Pour les réponses ICMP je ne sais pas je n’ai pas accès à ma box vu que ma connexion est ko
-
Après, l'idée de ne pas faire de modification vendredi soir n'est pas bête… Les modification effectuées dans la journée de vendredi devraient être implémentés dimanche soir.
Et tant qu'à faire, au lieu d'une plage horaire autour de 22h (où les gens utilisent encore internet, la TV…), 3h ou 4h du matin serait plus discret.
Oui, la nuit ça impacte moins de monde et les retours peuvent être fait le lundi matin.
J'ai enfin réussi à avoir le support, "problème transmis à l'ingénieur pour qu'il regarde en début de semaine car il se peut que ça vienne de chez nous".
Soit, encore un WE planté, et cuitos pour le live de demain soir, ça va etre quoi la prochaine panne ? :(
-
Oui, la nuit ça impacte moins de monde et les retours peuvent être fait le lundi matin.
J'ai enfin réussi à avoir le support, "problème transmis à l'ingénieur pour qu'il regarde en début de semaine car il se peut que ça vienne de chez nous".
Soit, encore un WE planté, et cuitos pour le live de demain soir, ça va etre quoi la prochaine panne ? :(
Fibre ne rime pas avec fiable… :(
Pas de 4G de secours pour le live ?
D’accord merci, on va attendre que sa revienne alors.
Pour les réponses ICMP je ne sais pas je n’ai pas accès à ma box vu que ma connexion est ko
Peut-être, avec un peu de courage et de patience, signaler le problème au support par téléphone ? Histoire d'être sûr qu'ils sont quand mème au courant si ça vient de K-Net ? Et qu'ils remontent au moins à Covage…
-
D’accord merci, on va attendre que sa revienne alors.
Pour les réponses ICMP je ne sais pas je n’ai pas accès à ma box vu que ma connexion est ko
Ce serait peut être mieux de signaler le problème car sinon ça risque de prendre un moment si personne leur dit.
Edit : Oui sauf que là ce n'est même pas un problème physique (fibre coupée) comme on rencontrait avec l'ADSL (oxydation/mauvais contact/atténuation énorme/désynchro) mais du mauvais paramétrage, ça fait assez amateur :(
4G, là je suis avec partage de connexion sur mon pc on dira internet, et ça passe super mal, débit moisi et surtout prise USB miniature aux contacts douteux (si je bouge le portable hop, liaison usb qui cafouille), alors le live étant fait depuis un sous sol en prime, c’est mort .
-
Et tant qu'à faire, au lieu d'une plage horaire autour de 22h (où les gens utilisent encore internet, la TV…), 3h ou 4h du matin serait plus discret.
Il faudrait surtout qu'après la "mise en production" d'un changement, un plan de tests soit exécuté, et qu'un rollback soit effectué en cas de tests en échec.
Pour moi, ça fait partie du B-A-BA de la gestion des changements ... et évidemment, quelle que soit l'heure à laquelle le changement est mis en production, il faut qu'il y ait un spécialiste de l'OI (ou de l'OC) pour le valider.
-
Ce serait peut être mieux de signaler le problème car sinon ça risque de prendre un moment si personne leur dit.
Edit : Oui sauf que là ce n'est même pas un problème physique (fibre coupée) comme on rencontrait avec l'ADSL (oxydation/mauvais contact/atténuation énorme/désynchro) mais du mauvais paramétrage, ça fait assez amateur :(
4G, là je suis avec partage de connexion sur mon pc on dira internet, et ça passe super mal, débit moisi et surtout prise USB miniature aux contacts douteux (si je bouge le portable hop, liaison usb qui cafouille), alors le live étant fait depuis un sous sol en prime, c’est mort .
Et partage via WiFi ?
--(4G)--> téléphone bien placé dans la maison --(WiFi)--> ordinateur
-
Ah bah pas mieux, mon point d'accès wifi ne permet pas d’être "client" d'un réseau wifi (qui serait du portable) donc pas possible de récupérer sur le pc en bas (qui n'est pas wifi, comem d'ailleurs rien à part un vieux petit pc portable (qui est encore en XP lol) et le téléphone portable.
-
Il faudrait surtout qu'après la "mise en production" d'un changement, un plan de tests soit exécuté, et qu'un rollback soit effectué en cas de tests en échec.
Pour moi, ça fait partie du B-A-BA de la gestion des changements ... et évidemment, quelle que soit l'heure à laquelle le changement est mis en production, il faut qu'il y ait un spécialiste de l'OI (ou de l'OC) pour le valider.
Oui, évidemment… Tester des dizaine de millier d'IP cependant n'est pas évident. Si une bourde s'est glissée dans une base de donnée sur une IP, comment la détecter en amont et valider que c'est une erreur (bug, typo) et non intentionnel ? Avec les clients qui partent, viennent, change de FAI… J'imagine que tous les jours la base de donnée est modifiée… Tous les clients n'ont pas leur matériel allumé, tous ne répondent pas aux pings ni même aux arpings si la box est éteinte.
Mais idéalement oui, vérifier ce qui change avant validation serait bien.
-
Oui, évidemment… Tester des dizaine de millier d'IP cependant n'est pas évident. Si une bourde s'est glissée dans une base de donnée sur une IP, comment la détecter en amont et valider que c'est une erreur (bug, typo) et non intentionnel ? Avec les clients qui partent, viennent, change de FAI… J'imagine que tous les jours la base de donnée est modifiée… Tous les clients n'ont pas leur matériel allumé, tous ne répondent pas aux pings ni même aux arpings si la box est éteinte.
Ce que j'avais en tête dans mon post précédent concerne surtout la détection d'incidents "collectifs" auto-infligés par un changement mal maîtrisé (ça c'est vu chez Covage - j'ai en tête un rollback qu'ils avaient dû faire suite à une tentative d'augmentation de bande passante ratée). C'est bien sûr impossible pour détecter des incidents "individuels".
-
Peux-tu faire un ping vers 10.2.0.211 (Covage 14) ?
Puis vers 10.2.0.4 (Covage global) ?
J'ai une question idiote mais depuis quand on peut pinger des IP privées (10/8) qui ne sont pas dans le réseau local ? C'est une joyeuseté propre à Covage, cette atrocité ? ;P
-
J'ai une question idiote mais depuis quand on peut pinger des IP privées (10/8) qui ne sont pas dans le réseau local ? C'est une joyeuseté propre à Covage, cette atrocité ? ;P
Pas particulièrement, c’est normal et courant en fait.
Les adresse privées sont faites pour cela, on est sur la partie privée du réseau Covage.
La boucle locale est un gros réseau local, et Covage peut ou non décider que ses routeurs soient visibles ou pas, et s’ils ont une IP publique ou privée, mais pourquoi réserveraient-ils des IP publiques pour des routeurs internes ?
-
Pas particulièrement, c’est normal et courant en fait.
Les adresse privées sont faites pour cela, on est sur la partie privée du réseau Covage.
La boucle locale est un gros réseau local, et Covage peut ou non décider que ses routeurs soient visibles ou pas, et s’ils ont une IP publique ou privée, mais pourquoi réserveraient-ils des IP publiques pour des routeurs internes ?
heu, je te suis pas là. Soit on parle pas de la même chose (la réponse à un traceroute, où là en effet les IP privées des routeurs sont légitimes; vs la réponse à un ping, où je ne vois pas comment tu pourrais pinger une IP privée qui _par définition_ n'est pas routée), soit y'a un truc sérieusement chelou qui m'échappe.
Sinon si je suis ton raisonnement ça voudrait dire que chez Covage, si tu décides d'adresser ton LAN perso en 10.2.0.0/24 tu te retrouves avec les routeurs covage qui s'intercalent sur ton LAN, ce qui est bien entendu parfaitement impossible.
-
heu, je te suis pas là. Soit on parle pas de la même chose (la réponse à un traceroute, où là en effet les IP privées des routeurs sont légitimes; vs la réponse à un ping, où je ne vois pas comment tu pourrais pinger une IP privée qui _par définition_ n'est pas routée), soit y'a un truc sérieusement chelou qui m'échappe.
Sinon si je suis ton raisonnement ça voudrait dire que chez Covage, si tu décides d'adresser ton LAN perso en 10.2.0.0/24 tu te retrouves avec les routeurs covage qui s'intercalent sur ton LAN, ce qui est bien entendu parfaitement impossible.
Si si, l’IP privée peut parfaitement répondre au ping (au même titre que sur ton LAN) et elle est bien routée.
Avec un LAN perso en 10.2.0.0/24, ton routeur doit en principe router depuis le LAN 10.2.0.0/24 vers le LAN et autres IP sur le WAN.
Depuis le routeur, tout dépend du metric qui devrait aussi donner priorité au LAN.
Après, il faut préciser l’interface.
-
Si si, l’IP privée peut parfaitement répondre au ping (au même titre que sur ton LAN) et elle est bien routée.
Avec un LAN perso en 10.2.0.0/24, ton routeur doit en principe router depuis le LAN 10.2.0.0/24 vers le LAN et autres IP sur le WAN.
Depuis le routeur, tout dépend du metric qui devrait aussi donner priorité au LAN.
Après, il faut préciser l’interface.
Je regrette mais ce que tu dis remets en cause Internet, la question dont la réponse est 42 et l'existence du Père Noël.
https://fr.wikipedia.org/wiki/Réseau_privé (https://fr.wikipedia.org/wiki/Réseau_privé)
Un réseau privé est un réseau qui utilise les plages d'adressage IP définies par la RFC 1918 « Address Allocation for Private Internets ». Ces adresses ne sont pas routées sur Internet.
Ajoutons également que la RFC précise même que ces IP sont tellement pas routable, que si un routeur voit en voit passer une il a le droit de l'exterminer.
Si Covage route des IP RFC1918, je comprends mieux pourquoi ce RIP semble être de loin le pire du pays :P
-
Je regrette mais ce que tu dis remets en cause Internet, la question dont la réponse est 42 et l'existence du Père Noël.
https://fr.wikipedia.org/wiki/Réseau_privé (https://fr.wikipedia.org/wiki/Réseau_privé)
Ajoutons également que la RFC précise même que ces IP sont tellement pas routable, que si un routeur voit en voit passer une il a le droit de l'exterminer.
Si Covage route des IP RFC1918, je comprends mieux pourquoi ce RIP semble être de loin le pire du pays :P
A mon avis, il ne faut pas regarder la question de cette manière :
ce que les clients (nous) et les opérateurs (OC) demandent à un opérateur d'infrastructure (Covage), c'est de router au travers leur réseau de collecte les flux IP vers l'infrastructure de l'OC, qui ELLE dispose du routage vers le reste d'Internet - ainsi que le trafic retour évidemment.
La manière dont l'OI s'arrange pour ce faire, c'est leur problème : leurs routeurs pourraient ne répondre ni à ping ni à traceroute, on ne saurait même pas quel plan d'adressage (public ou privé) ils ont mis en place.
Ici, ils ont choisi un schéma d'adressage privé, ça "économise" des adresses IPv4 en grave pénurie.
-
Et rappelons aussi que le réseau de collecte de Covage n'est pas encore internet... Internet commence plus loin, à la sortie du réseau K-Net.
Donc les adresses privées sont parfaitement légales et ne posent aucun problème technique ou irrespectueuse des bonnes pratiques réseau et internet.
Aucun problème non plus à ce que les routeurs répondent aux pings et traceroute. C'est un choix, pas mieux ou mauvais que de les rendre silencieux.
Et d'ailleurs, c'est ce qui nous permet, nous clients empruntant ce réseau d'y faire du monitoring, donc je ne m'en plains pas, au contraire, c'est une forme de transparence.
PS : preuve d'ailleurs que c'est privé et pas sur internet, si tu ping ces adresses depuis un autre FAI (ou même depuis K-Net mais sur un autre OI), tu ne tomberas pas dessus, car elle sont bien en effet non routées sur internet ;)
On les voit car on est dans le réseau privé Covage, tout comme tu peux voir ton LAN localement, mais pas depuis internet.
-
10.2.0.191 C'est Europ'Essonne je crois.
Donc c'est comme si Covage pensait que ton adresse se trouve plus à l'ouest et dépend du NRO Europ'Essone, puisque chercher à joindre ton IP va vers le routeur national Covage (10.2.0.4), qui lui route vers 10.2.0.191 au lieu de 10.2.0.220.
En gros, j'ai l'impression que pour une raison obscure, Covage a attribué ton IP sur le mauvais NRO en ce qui concerne les tables de routage.
Du coup, je pense que 10.2.0.220 fonctionne bien et route possiblement correctement ce que tu envoie… mais absolument rien ne revient vers toi car 10.2.0.4 envoie ce qui t'est destiné sur le mauvais NRO, donc par exemple ton ping vers 1.1.1.1 atteint peut-être bien 1.1.1.1, qui répond, mais la réponse est envoyée à 10.2.0.191 (au lieu de 10.2.0.220) qui lui ne sait plus ou router ensuite car tu n'est pas à Sarclay, mais Ormoy…
C'est mignon : On dirait que Covage 91 comprend son réseau (ou ex réseau) aussi bien que moi!
Ce qui n'est pas bon signe...
-
C'est mignon : On dirait que Covage 91 comprend son réseau (ou ex réseau) aussi bien que moi!
Ce qui n'est pas bon signe...
Bah, il y a la fibre en France, puis... le 91.
-
Ici, ils ont choisi un schéma d'adressage privé, ça "économise" des adresses IPv4 en grave pénurie.
Comme à peu près tous les ISP sérieux. C'est pas le sujet. Le sujet c'est que si, depuis ton IP publique tu peux pinger une IP privée RFC1918 et qu'elle te répond, il y a un gros, gros problème :P
Maintenant je relis le message de bolemo:
La boucle locale est un gros réseau local
et j'ai peur de comprendre :P
-
Comme à peu près tous les ISP sérieux. C'est pas le sujet. Le sujet c'est que si, depuis ton IP publique tu peux pinger une IP privée RFC1918 et qu'elle te répond, il y a un gros, gros problème :P
L'IP publique en question est aussi sur le réseau local de l'OI. Je ne vois donc pas en quoi c'est un problème.
https://lafibre.info/tcpip/traceroute-reseau-prive-hors-lan/msg866551/#msg866551
https://lafibre.info/tcpip/tracert-passerelle-qui-napparait-pas-dans-le-premier-hop/
Maintenant je relis le message de bolemo:et j'ai peur de comprendre :P
Peur de comprendre quoi?
-
L'IP publique en question est aussi sur le réseau local de l'OI. Je ne vois donc pas en quoi c'est un problème.
https://lafibre.info/tcpip/traceroute-reseau-prive-hors-lan/msg866551/#msg866551
https://lafibre.info/tcpip/tracert-passerelle-qui-napparait-pas-dans-le-premier-hop/
Peur de comprendre quoi?
En effet, depuis l'interface WAN de ton routeur (qui a une IP publique), tu peux bien faire un ping vers ton LAN.
Il n'y a aucun problème. il faut vraiment comprendre que nous sommes à l'intérieur du réseau de collecte de l'OI, et ce réseau utilise des IP privées visibles depuis l'intérieur, mais elles ne le sont pas depuis l'extérieur. K-Net ne peut pas les voir de leur côté par exemple, sauf peut-être depuis leur routeur de collecte relié à Covage.
Il y a aussi un cloisonnement entre les diff"rents FAI au sein de l'OI. Donc un TCP dump ne me permet de voir que des paquets liées aux clients K-Net de ma boucle, et encore seulement ceux qui sont en broadcast ou les réponses à des requêtes DHCP. Je ne peux pas voir le traffic d'un autre client ni parler directement à un autre client (à moins d'utiliser des messages broadcast).
Donc le réseau de Covage n'est pas mal foutu à ce niveau là. Et encore une fois, c'est cool de pouvoir faire un ping et des traceroutes sur leurs routeurs. Sans ce monitoring, on en saurait encore moins sur ce qui se passe quand il y a des pannes ou autre.
-
Donc le réseau de Covage n'est pas mal foutu à ce niveau là. Et encore une fois, c'est cool de pouvoir faire un ping et des traceroutes sur leurs routeurs. Sans ce monitoring, on en saurait encore moins sur ce qui se passe quand il y a des pannes ou autre.
Je partage complètement l'avis de bolemo, et je préfère cette configuration Covage + K-Net (avec adresse IPv4 publique attribuée) à d'autres solutions comme :
- Orange (mobile) qui m'affecte une adresse IP en 192.0.0.0/27 => Ce n'est pas une adresse privée au sens RFC 1918.
- les FAI en CG-NAT (ex : Videofutur également disponible sur les réseaux de Covage).
-
En effet, depuis l'interface WAN de ton routeur (qui a une IP publique), tu peux bien faire un ping vers ton LAN.
Non. Si tu peux, soit l'ARP filtering est désactivé et ton routeur envoie le paquet via la bonne interface (LAN) sans que tu t'en aperçoives, soit ton routeur est (très) mal configuré.
Il n'y a aucun problème.
Oh que si.
Sinon il faut que je remette en cause tout ce qu'on m'a appris quand j'étais petit à l'école et que je sacrifie un poulet ou deux pour disperser le mauvais sort ;D
Il faut vraiment comprendre que nous sommes à l'intérieur du réseau de collecte de l'OI, et ce réseau utilise des IP privées visibles depuis l'intérieur, mais elles ne le sont pas depuis l'extérieur. K-Net ne peut pas les voir de leur côté par exemple, sauf peut-être depuis leur routeur de collecte relié à Covage.
Il y a aussi un cloisonnement entre les diff"rents FAI au sein de l'OI. Donc un TCP dump ne me permet de voir que des paquets liées aux clients K-Net de ma boucle, et encore seulement ceux qui sont en broadcast ou les réponses à des requêtes DHCP. Je ne peux pas voir le traffic d'un autre client ni parler directement à un autre client (à moins d'utiliser des messages broadcast).
Rien que ça me donne des frissons dans le dos, c'est juste immonde.
Donc le réseau de Covage n'est pas mal foutu à ce niveau là. Et encore une fois, c'est cool de pouvoir faire un ping et des traceroutes sur leurs routeurs. Sans ce monitoring, on en saurait encore moins sur ce qui se passe quand il y a des pannes ou autre.
Non c'est totalement aberrant. Un gros ISP qui ferait se genre de choses se ferait sérieusement savater, c'est pire qu'un LAN de résidence universitaire :P
Au risque de me répéter: si sur ta box/ton routeur tu obtiens une IP publique, et depuis cette IP publique tu peux pinger une IP en réseau privé propre à Covage (comme les interfaces internes des routeurs de Covage), c'est une aberration totale, et ça contrevient à toutes les RFC, puisque ça revient à dire que ces IP privées sont routées, ce qui est explicitement interdit. Et donc si tel est bien le cas, le réseau Covage est une abomination et je comprends beaucoup mieux les problèmes récurrents dont il semble souffrir :P
Mais bon, j'en reste là, et je note de fuir ce RIP comme la peste noire :o
-
Au risque de me répéter: si sur ta box/ton routeur tu obtiens une IP publique, et depuis cette IP publique tu peux pinger une IP en réseau privé propre à Covage (comme les interfaces internes des routeurs de Covage), c'est une aberration totale, et ça contrevient à toutes les RFC, puisque ça revient à dire que ces IP privées sont routées, ce qui est explicitement interdit. Et donc si tel est bien le cas, le réseau Covage est une abomination et je comprends beaucoup mieux les problèmes récurrents dont il semble souffrir :P
As-tu lu les liens que j'ai donné avant?
Avec mon IP public K-net, non seulement je peux voir les routeurs Covage en 10.2.0.0/24, mais aussi les routeurs de K-net et le relais DHCP en 172.16.0.0/10.
En quoi ce serait mal?
Et du coup, je me pose une question sans doute bête : Il se passe quoi pour mon routeur si je configure mon lan en 10.2.0.0/24 comme les routeurs de Covage?
-
Ce n'est pas abrérant au contraire. Les IP privées n'ont pas à être routés dans la DFZ ça oui (donc accessible depuis un _autre_ opérateur), mais peuvent être parfaitement utilisée au sein d'un FAI pour de la supervision/monitoring, pour des serveurs de mises à jour et le provisioning des boxs, cgnat, etc. Je ne vais pas claquer des IPv4 publiques pour ces usages qui peuvent rester en interne.
Et c'est même mieux, car vu qu'inaccessibles depuis d'autres opérateurs, ça évite bien des merdes.
-
Non. Si tu peux, soit l'ARP filtering est désactivé et ton routeur envoie le paquet via la bonne interface (LAN) sans que tu t'en aperçoives, soit ton routeur est (très) mal configuré.
Je ne pense pas qu'il y ait de l'ARP filtering sur les KBOX.
Oh que si.
Sinon il faut que je remette en cause tout ce qu'on m'a appris quand j'étais petit à l'école et que je sacrifie un poulet ou deux pour disperser le mauvais sort ;D
Rien que ça me donne des frissons dans le dos, c'est juste immonde.
Non c'est totalement aberrant. Un gros ISP qui ferait se genre de choses se ferait sérieusement savater, c'est pire qu'un LAN de résidence universitaire :P
Relis bien les différentes contributions en réponse à ton post (y compris les miennes), j'ai l'impression que nous ne sommes pas choqués comme toi de cette situation.
Au risque de me répéter: si sur ta box/ton routeur tu obtiens une IP publique, et depuis cette IP publique tu peux pinger une IP en réseau privé propre à Covage (comme les interfaces internes des routeurs de Covage), c'est une aberration totale, et ça contrevient à toutes les RFC, puisque ça revient à dire que ces IP privées sont routées, ce qui est explicitement interdit. Et donc si tel est bien le cas, le réseau Covage est une abomination et je comprends beaucoup mieux les problèmes récurrents dont il semble souffrir :P
Ces adresses IP (en 10/8) ne sortent pas du réseau de l'OI, elles ne sont pas routées au delà du réseau de collecte ... même si tu as l'impression d'être déjà sur Internet par ton adresse IP publique.
Mais bon, j'en reste là, et je note de fuir ce RIP comme la peste noire :o
Avant de fuir, renseigne toi bien sur la manière dont procèdent les autres, tu pourrais avoir des surprises.
-
En quoi ce serait mal?
La réponse à cette question se trouve ci-dessous:
Et du coup, je me pose une question sans doute bête : Il se passe quoi pour mon routeur si je configure mon lan en 10.2.0.0/24 comme les routeurs de Covage?
-
Cela voudrait donc dire qu'un client K-net doit connaitre l'infra Covage pour configurer son LAN?
Cela me parait gros et j'en déduis qu'il y a encore un truc qui m'échappe.
-
Il n'y a rien de mal.
Je peux très bien mettre mon LAN en 10.2.0.0/24 si je veux.
Du coup mon routeur aurait par exemple mon IP publique sur l'interface WAN 1.2.3.128 (en supposant que c'est mon IP publique).
Il aurait par exemple 10.2.0.1 sur l'interface LAN.
Les tables de routage du routeur seraient :
default via 1.2.3.254 dev WAN (la passerelle de mon sous-réseau publique)
1.2.3.0/24 dev WAN scope link src 1.2.3.128
10.2.0.0/24 dev LAN scope link src 10.2.0.1
Donc depuis mon LAN et mon routeur, toute adresse en 10.2.0.0/24 sera routée vers le LAN, sans souci.
Et toute adresse internet sera routée vers la passerelle Covage, sans souci.
Seul inconvénient : les adresses 10.2.0.0/24 Covage ne seraient plus accessibles depuis mon LAN, donc je ne pourrais plus faire de monitoring.
Mais tout mon traffic internet ne serait absolument pas affecté, puis qu'il se fiche de l'IP des routeurs Covage, il dépend de l'IP de la passerelle qui est ici 1.2.3.254.
Résumé : le premier routeur Covage possède deux IP, celle de la passerelle publique 1.2.3.254 et une IP privée 10.2.0.211 (qui n'a pas besoin d'être accessible pour le fonctionnement d'internet. Elle est utile seulement pour du monitoring et les traceroute).
À noter : 1.2.3.254 ne répond pas aux pings, seulement aux arpings.
En espérant avoir clarifié la compréhension de l'infra :)
-
En espérant avoir clarifié la compréhension de l'infra :)
Et je pense que par la même occasion, tu as répondu aux questionnements de blarglibloup : les routeurs de l'OI répondent (par exemple au traceroute) à partir de leur adresse primaire configurée sur le réseau de l'OI (10/8) mais ils disposent d'une adresse IP publique sur le même réseau que ta box ou que ton routeur (réseau en /22 chez moi, bolemo a donné un exemple en /24).
-
Et je pense que par la même occasion, tu as répondu aux questionnements de blarglibloup : les routeurs de l'OI répondent (par exemple au traceroute) à partir de leur adresse primaire configurée sur le réseau de l'OI (10/8) mais ils disposent d'une adresse IP publique sur le même réseau que ta box ou que ton routeur (réseau en /22 chez moi, bolemo a donné un exemple en /24).
Oui, mon sous-réseau est aussi en /22, mais un exemple en /24 est plus simple ;)
La clef de l'histoire est qu'un routeur peut avoir plusieurs adresses. Par exemple 10.2.0.5 est chez K-Net et possède un très grand nombre d'IP (puisqu'il doit être visible par tous les OI et en interne chez K-Net).
-
Ah oui.
On ne perd donc que l'accessibilité du sous réseau coté WAN car masqué par celui coté LAN si on met le même range.
J'avais aussi sur les conseils de Hugues commencer à lire l'IP unnumbered.
https://networklessons.com/cisco/ccie-routing-switching/ip-unnumbered-explained
https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/13786-20.html
et le ARP proxy.
Il faudrait que je reprenne un peu le truc! ;)
-
Cette histoire 10.0.0.0/8 ça me rappelle une veille histoire avec la plage 5.0.0.0/8 qu'Ovh avait racheté mais un logiciel qui s'appelle Hamachi l'utilise pour faire un réseau Lan entre plusieurs Pc sur internet. Quand tu avais ce logiciel tous les sites ou serveur de jeux qui avait cette IP était off.
https://forum.ovh.com/showthread.php/83994-Nouveau-Kimsufi-ne-repond-pas-au-ping
https://web.archive.org/web/20140208105022/http://b.logme.in/2012/11/07/changes-to-hamachi-on-november-19th
-
Pouet !
Rappel ce jour pour avoir des nouvelles et suggéré au prie de me changer d'IP , ce qui a été fait en direct par l'ingé réseau. Du coup nouvelle IP et net ok.
A ploutch' !
Couiiinnn
-
Pouet !
Rappel ce jour pour avoir des nouvelles et suggéré au prie de me changer d'IP , ce qui a été fait en direct par l'ingé réseau. Du coup nouvelle IP et net ok.
A ploutch' !
Couiiinnn
Génial, et effectivement, changer d'IP c'est radical mais très efficace (ça zappe complètement la recherche du problème chez Covage et tout ça…)
-
bah ouais mais si ça prend 3 semaines à trouver le problème ? :-\
Après ça ne les empêche pas de chercher en OFF mais mon but c'est d'avoir une connexion internet qui fonctionne et non être client de test (ou alors ok avec abo gratos à vie).
-
bah ouais mais si ça prend 3 semaines à trouver le problème ? :-\
Après ça ne les empêche pas de chercher en OFF mais mon but c'est d'avoir une connexion internet qui fonctionne et non être client de test (ou alors ok avec abo gratos à vie).
Justement, c'était la bonne décision :)
Ultra efficace et permet d'éviter de perdre du temps avec un ping/pong OI/FAI.
Donc bravo pour cette solution !
-
ah oui , je pensais que ton message précédent était dans le sens "bah comme ça on ne saura jamais" lol
Oui du coup j'ai eu cette idée subitement et pour le coup ça a été rapide et l’hôtesse que j'ai eu au tel vraiment très gentille aussi :)
-
Peut-être une note d'espoir sur https://www.k-net.fr/etat-du-reseau-et-des-services/, ça semble avancer
-
Peut-être une note d'espoir sur https://www.k-net.fr/etat-du-reseau-et-des-services/, ça semble avancer
;)