Auteur Sujet: Plus de net, encore (ORMOY 91) (Lu 8409 fois)

bolemo · « **Réponse #24 le:** 26 mars 2022 à 15:14:47 »

Citation de: Couin le 26 mars 2022 à 15:05:33

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

Couin · « **Réponse #25 le:** 26 mars 2022 à 15:25:54 »

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.

bolemo · « **Réponse #26 le:** 26 mars 2022 à 15:28:18 »

Citation de: pju91 le 26 mars 2022 à 15:06:21

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.

pju91 · « **Réponse #27 le:** 26 mars 2022 à 15:45:48 »

Citation de: bolemo le 26 mars 2022 à 15:28:18

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".

blarglibloup · « **Réponse #28 le:** 26 mars 2022 à 20:01:38 »

Citation de: bolemo le 26 mars 2022 à 14:25:09

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

bolemo · « **Réponse #29 le:** 26 mars 2022 à 21:06:16 »

Citation de: blarglibloup le 26 mars 2022 à 20:01:38

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 ?

blarglibloup · « **Réponse #30 le:** 26 mars 2022 à 21:14:55 »

Citation de: bolemo le 26 mars 2022 à 21:06:16

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.

bolemo · « **Réponse #31 le:** 26 mars 2022 à 22:25:18 »

Citation de: blarglibloup le 26 mars 2022 à 21:14:55

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.

blarglibloup · « **Réponse #32 le:** 27 mars 2022 à 11:56:29 »

Citation de: bolemo le 26 mars 2022 à 22:25:18

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é

Citer

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

pju91 · « **Réponse #33 le:** 27 mars 2022 à 12:07:45 »

Citation de: blarglibloup le 27 mars 2022 à 11:56:29

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é
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

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.

bolemo · « **Réponse #34 le:** 27 mars 2022 à 12:44:49 »

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.

Steph · « **Réponse #35 le:** 27 mars 2022 à 12:49:04 »

Citation de: bolemo le 26 mars 2022 à 14:08:28

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...