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: Krougher le 05 février 2022 à 22:19:05
-
Bonsoir je ne sais pas si je dois poster ca ici, mais voilà;
lorsque j'essaie de me connecter à https://fr.aliexpress.com/ j'ai un dépassement de temps, impossible de joindre le site, sur mon tel portable en data pas de problème.
J'ai essayé en wifi sur mon tel, même résultat 0 accès.
Sur d'autres PC eth/wifi pareil, inaccessible.
-
Hello,
Tracert 59.82.60.29 et 2.16.119.93 ?
-
Pour le deuxieme j'ai
Détermination de l’itinéraire vers a2-16-119-93.deploy.static.akamaitechnologies.com [2.16.119.93]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.1
2 1 ms 1 ms 1 ms 10.2.0.191
3 * * * Délai d’attente de la demande dépassé.
4 2 ms 2 ms 2 ms 10.2.0.5
5 15 ms 15 ms 15 ms 172.20.0.196
6 15 ms 14 ms 15 ms te0-0-1-6.rcr21.gva01.atlas.cogentco.com [149.6.54.249]
7 14 ms 14 ms 14 ms be3056.rcr21.lys01.atlas.cogentco.com [154.54.58.205]
8 15 ms 15 ms 14 ms be2471.ccr41.par01.atlas.cogentco.com [130.117.49.37]
9 15 ms 14 ms 15 ms be2102.ccr32.par04.atlas.cogentco.com [154.54.61.18]
10 14 ms 14 ms 14 ms be2151.agr21.par04.atlas.cogentco.com [154.54.61.34]
11 15 ms 15 ms 14 ms akamai.demarc.cogentco.com [149.11.114.234]
12 14 ms 15 ms 14 ms a2-16-119-93.deploy.static.akamaitechnologies.com [2.16.119.93]
Itinéraire déterminé.
Et pour le premiere
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Délai d’attente de la demande dépassé.
3 * * * Délai d’attente de la demande dépassé.
4 2 ms 2 ms 2 ms 10.2.0.5
5 15 ms 15 ms 15 ms 172.20.0.196
6 15 ms 14 ms 14 ms te0-0-1-6.rcr21.gva01.atlas.cogentco.com [149.6.54.249]
7 22 ms 22 ms 22 ms be3057.ccr51.zrh02.atlas.cogentco.com [154.54.58.209]
8 22 ms 22 ms 22 ms be3072.ccr21.muc03.atlas.cogentco.com [130.117.0.18]
9 22 ms 22 ms 22 ms be2959.ccr41.fra03.atlas.cogentco.com [154.54.36.53]
10 22 ms 22 ms 22 ms be3186.agr41.fra03.atlas.cogentco.com [130.117.0.2]
11 23 ms 22 ms 23 ms chinatelecom.demarc.cogentco.com [149.14.159.114]
12 252 ms 251 ms 252 ms 202.97.43.33
13 227 ms 227 ms 227 ms 202.97.12.49
14 246 ms 244 ms 244 ms 202.97.34.73
15 247 ms 244 ms 249 ms 36.110.248.118
16 247 ms 245 ms * 36.110.248.250
17 247 ms 248 ms 245 ms 106.38.196.30
18 * * * Délai d’attente de la demande dépassé.
19 250 ms 250 ms 252 ms 117.49.45.129
20 * * * Délai d’attente de la demande dépassé.
21 * * * Délai d’attente de la demande dépassé.
22 234 ms 237 ms 235 ms 59.82.60.29
Itinéraire déterminé.
-
J'ai meme essayé sur 3 DNS différents.
-
Aucune raison que ça ne fonctionne pas.
-
Et si j'utilise Brave en TOR, ca passe je peux y aller ...
-
Une capture Wireshark permettrait de voir l'IP retenue par ton système, de voir si elle est bonne et pourquoi la connections https ne s’établit pas.
=> Réaliser une capture Wireshark pas à pas (https://lafibre.info/tcpip/realiser-une-capture-wireshark-pas-a-pas/)
-
Merci messieurs, j'essaie de faire ca et je vous tiens au courant.
-
Hello,
Tracert 59.82.60.29 et 2.16.119.93 ?
Je n'ai pas çà comme ip pour fr.aliexpress.com
@Krougher, que donne la commande ping fr.aliexpress.com
-
Ca me donne
C:\WINDOWS\system32>ping fr.aliexpress.com
Envoi d’une requête 'ping' sur eu-aebridge.aliexpress.com.gds.alibabadns.com [47.254.143.107] avec 32 octets de données :
Réponse de 47.254.143.107 : octets=32 temps=35 ms TTL=91
Réponse de 47.254.143.107 : octets=32 temps=35 ms TTL=91
Réponse de 47.254.143.107 : octets=32 temps=35 ms TTL=91
Réponse de 47.254.143.107 : octets=32 temps=35 ms TTL=91
Statistiques Ping pour 47.254.143.107:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 35ms, Maximum = 35ms, Moyenne = 35ms
-
Bonjour à tous,
Depuis quelques jours, j'ai des problèmes de connectivité vers des sites hébergés chez Akamai, en particulier les domaines en *.akamaiedge.net.
Exemple de ce matin, dell.com est inaccessible. Ma résolution DNS me retourne un CNAME vers e19274.x.akamaiedge.net (104.108.55.15). Un traceroute vers cette IP me fait boucler entre 172.20.0.196 et 172.20.0.197 :
Détermination de l’itinéraire vers a104-108-55-152.deploy.static.akamaitechnologies.com [104.108.55.152]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.2.1
2 2 ms 2 ms 2 ms 10.2.0.219
3 * * * Délai d’attente de la demande dépassé.
4 4 ms 4 ms 4 ms 120.138.24.109.rev.sfr.net [109.24.138.120]
5 * * * Délai d’attente de la demande dépassé.
6 22 ms 21 ms 20 ms 10.2.0.5
7 17 ms 17 ms 17 ms 172.20.0.196
8 17 ms 17 ms 17 ms 172.20.0.197
9 31 ms 30 ms 30 ms 172.20.0.196
10 30 ms 30 ms 30 ms 172.20.0.197
11 44 ms 44 ms 43 ms 172.20.0.196
12 43 ms 43 ms 43 ms 172.20.0.197
Même constat pour les domaines *.list-manage.com (souvent utilisé dans les mailing-list), avec par exemple le domaine e13829.x.akamaiedge.net (104.108.60.184)
Détermination de l’itinéraire vers e13829.x.akamaiedge.net [104.108.60.184]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.2.1
2 2 ms 2 ms 2 ms 10.2.0.219
3 * * * Délai d’attente de la demande dépassé.
4 3 ms 4 ms 3 ms 120.138.24.109.rev.sfr.net [109.24.138.120]
5 * * * Délai d’attente de la demande dépassé.
6 4 ms 4 ms 4 ms 10.2.0.5
7 17 ms 17 ms 17 ms 172.20.0.196
8 17 ms 17 ms 17 ms 172.20.0.197
9 30 ms 30 ms 30 ms 172.20.0.196
10 30 ms 30 ms 30 ms 172.20.0.197
11 43 ms 43 ms 43 ms 172.20.0.196
Quelqu'un aurait des problèmes similaires ?
-
J'ai ouvert mon post avant de voir le tien, Krougher, mais je pense que ton problème est lié au mien, à savoir un souci de connectivité vers Akamai :
https://lafibre.info/k-net-internet/probleme-de-connectivite-vers-akamai/
-
Cette boucle folle de réseau chez K-net avait déjà été signalé sur CAPS par quelqu'un qui cherchait à joindre la Suisse.
tracert 104.108.55.15
Détermination de l’itinéraire vers a104-108-55-15.deploy.static.akamaitechnologies.com [104.108.55.15]
avec un maximum de 30 sauts :
1 3 ms 3 ms 3 ms k-box.home [192.168.1.1]
2 4 ms 4 ms 4 ms labalme.covage [10.2.0.178]
3 * * * Délai d’attente de la demande dépassé.
4 13 ms 13 ms 13 ms k-net.covage [10.2.0.5]
5 26 ms 26 ms 27 ms 172.20.0.196
6 26 ms 26 ms 26 ms 172.20.0.197
7 40 ms 39 ms 40 ms 172.20.0.196
8 40 ms 39 ms 40 ms 172.20.0.197
9 53 ms 53 ms 53 ms 172.20.0.196
10 55 ms 54 ms 53 ms 172.20.0.197
11 66 ms 65 ms 65 ms 172.20.0.196
12 66 ms 65 ms 65 ms 172.20.0.197
-
Quelqu'un aurait des problèmes similaires ?
Quelqu'un a des soucis vers Aliexpress
https://lafibre.info/k-net-internet/aliexpress-com-inaccessible-depuis-ma-co-knet/
Après c'est peut être encore un effet de bord des problèmes de routage que subit K-Net depuis décembre.
-
Même souci surement https://lafibre.info/k-net-internet/aliexpress-com-inaccessible-depuis-ma-co-knet/ avec aliexpress.
Beaucoup de souci de routage chez K-NET ...
-
Ah, c'est interessant je ne serais donc pas le seul.
-
Fort de ce constat, j'imagine qu'à part ouvrir un ticket chez K-Net, il n'y a pas de solution rapide à ce problème (excepté un VPN) ?
Je précise que je n'avais pas ce genre de soucis avant Le Grand Bordel De Janvier™ et les coupures liées au DHCP ::)
(Enfin je dis ça, les symptômes sont peut être juste apparus suite à la perte de l'IPv6, ce problème de routage était peut être déjà présent avant en IPv4, mais masqué par la connectivité IPv6...)
-
J'etais entrain de me tater pour passer sur Cyberghost ^^
-
Please email questions or comments to peering@kwaoo.net. or noc@kwaoo.net. Essayer :)
-
Message envoyé aux deux adresses, on verra la suite.
Merci à ceux qui ont essayé d'aider en tout cas :)
-
Message envoyé aux deux adresses, on verra la suite.
Merci à ceux qui ont essayé d'aider en tout cas :)
Si tu as twitter https://x.com/fbknet en + ça peut aider :P
-
Fort de ce constat, j'imagine qu'à part ouvrir un ticket chez K-Net, il n'y a pas de solution rapide à ce problème (excepté un VPN) ?
Effectivement si ça doit marcher aujourd’hui
VPN (soit un vrai service, soit passer par les VPNs intégré aux navigateurs - Opera ou TorBrowser qui fait transiter les infos sur le réseau Tor)
-
Quand j'utilise le VPN d'OPERA, connexion instantané au site.
-
Le problème vient bien de chez K-Net ce n'est pas un scoop en ce moment ...
-
Bon bah on verra, vivement qu'on recupere le téléphone fix et les connections vers la chine ...
-
C'est plus grave que la chine là c'est akamai.
-
Je ne connais pas Akamai du tout.
-
Si tu as twitter https://x.com/fbknet en + ça peut aider :P
Done !
Je ne connais pas Akamai du tout.
C'est un des plus gros CDN (Content Delivery Network) actuel, il héberge et protège un grand nombre de sites et de services (comme le montre l'exemple de Dell et AliExpress, qui font tous les deux appels aux service d'Akamai)
-
Merci là je comprend mieux, c'est donc effectivement plus problematique ^^
-
Voici 3 traceroutes effectués en succession… Akamai.com renvoie des IP différentes (donc problème de DNS ?), et donc des routes différentes…
root@HERMES:~$ traceroute -w1 -q1 -m10 akamai.com
traceroute to akamai.com (104.83.6.37), 10 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.468 ms
2 *
3 10.2.0.5 (10.2.0.5) 6.936 ms
4 et1-1-5.parigi52.par.seabone.net (213.144.168.182) 7.092 ms
5 cable-wireless.parigi52.par.seabone.net (213.144.183.30) 6.998 ms
6 ae2-xcr1.mat.cw.net (195.2.8.106) 25.679 ms
7 ae2-xcr1.max.cw.net (195.2.30.89) 25.273 ms
8 akamai-gw4.max.cw.net (195.2.23.14) 126.960 ms
9 *
10 *
root@HERMES:~$ traceroute -w1 -q1 -m10 akamai.com
traceroute to akamai.com (104.82.181.162), 10 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.530 ms
2 *
3 10.2.0.5 (10.2.0.5) 6.779 ms
4 et1-1-5.parigi52.par.seabone.net (213.144.168.182) 7.248 ms
5 89.221.43.233 (89.221.43.233) 22.837 ms
6 89.221.43.35 (89.221.43.35) 19.650 ms
7 ae1.r01.lon03.icn.netarch.akamai.com (23.210.50.34) 95.408 ms
8 ae10.r01.lon01.icn.netarch.akamai.com (95.100.192.238) 100.562 ms
9 ae1.r02.lon01.ien.netarch.akamai.com (23.210.48.37) 20.119 ms
10 ae5.intx-lon9.netarch.akamai.com (23.210.48.203) 23.743 ms
root@HERMES:~$ traceroute -w1 -q1 -m10 akamai.com
traceroute to akamai.com (104.82.181.162), 10 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.593 ms
2 *
3 10.2.0.5 (10.2.0.5) 6.905 ms
4 et1-1-5.parigi52.par.seabone.net (213.144.168.182) 6.905 ms
5 89.221.43.233 (89.221.43.233) 26.180 ms
6 89.221.43.35 (89.221.43.35) 16.182 ms
7 ae1.r01.lon03.icn.netarch.akamai.com (23.210.50.34) 99.625 ms
8 ae10.r01.lon01.icn.netarch.akamai.com (95.100.192.238) 97.282 ms
9 ae1.r02.lon01.ien.netarch.akamai.com (23.210.48.37) 19.275 ms
10 ae5.intx-lon9.netarch.akamai.com (23.210.48.203) 16.214 ms
root@HERMES:~$ traceroute -w1 -q1 -m10 akamai.com
traceroute to akamai.com (23.215.53.132), 10 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.530 ms
2 *
3 10.2.0.5 (10.2.0.5) 6.747 ms
4 178.250.208.173 (178.250.208.173) 17.557 ms
5 *
6 *
7 *
8 *
9 *
10 *
Ah tiens, celui-là est intéressant ;D :o :
root@HERMES:~$ traceroute -w1 -q1 -m10 akamai.com
traceroute to akamai.com (23.0.214.43), 10 hops max, 38 byte packets
1 10.2.0.211 (10.2.0.211) 2.530 ms
2 *
3 10.2.0.5 (10.2.0.5) 6.842 ms
4 *
5 amsix-ams9.netarch.akamai.com (80.249.208.168) 32.958 ms
6 *
7 *
8 *
9 10.2.0.211 (10.2.0.211) 339.551 ms
10 10.2.0.211 (10.2.0.211) 0.000 ms
-
Voici 3 traceroutes effectués en succession… Akamai.com renvoie des IP différentes (donc problème de DNS ?), et donc des routes différentes…
Si je peux me permettre : c'est un des principes des "CDN" d'utiliser intelligemment les TTL DNS pour orienter le trafic vers un endroit "proche" et "rapide" en équilibrant la charge. Le fait que les IP changent pour Akamai.com et pour tous les clients d'Akamai (idem pour ses concurrents) est donc parfaitement normal.
Illustration (20 secondes de TTL chez Akamai) :
while true; do dig akamai.com|grep "^akamai.com"; sleep 21; done
akamai.com. 20 IN A 104.71.52.47
akamai.com. 20 IN A 23.62.150.39
akamai.com. 20 IN A 23.215.53.132
akamai.com. 20 IN A 104.83.6.37
akamai.com. 20 IN A 2.16.78.101
akamai.com. 20 IN A 2.17.186.73
akamai.com. 20 IN A 23.0.214.43
akamai.com. 20 IN A 23.54.5.197
akamai.com. 20 IN A 104.83.6.37
akamai.com. 20 IN A 2.17.186.73
^C
-
Si je peux me permettre : c'est un des principes des "CDN" d'utiliser intelligemment les TTL DNS pour orienter le trafic vers un endroit "proche" et "rapide" en équilibrant la charge. Le fait que les IP changent pour Akamai.com et pour tous les clients d'Akamai (idem pour ses concurrents) est donc parfaitement normal.
Illustration (20 secondes de TTL chez Akamai) :
while true; do dig akamai.com|grep "^akamai.com"; sleep 21; done
akamai.com. 20 IN A 104.71.52.47
akamai.com. 20 IN A 23.62.150.39
akamai.com. 20 IN A 23.215.53.132
akamai.com. 20 IN A 104.83.6.37
akamai.com. 20 IN A 2.16.78.101
akamai.com. 20 IN A 2.17.186.73
akamai.com. 20 IN A 23.0.214.43
akamai.com. 20 IN A 23.54.5.197
akamai.com. 20 IN A 104.83.6.37
akamai.com. 20 IN A 2.17.186.73
^C
Merci, et tu peux absolument te permettre :)
Je cherchais s'il y avait un PNI ou peering Akamai sur l'infra Kwaoo pour y mettre une sonde.
-
Je cherchais s'il y avait un PNI ou peering Akamai sur l'infra Kwaoo pour y mettre une sonde.
Oui mais c'est à Akamai de l'utilise ou pas
-
Je cherchais s'il y avait un PNI ou peering Akamai sur l'infra Kwaoo pour y mettre une sonde.
A France-IX Paris par exemple selon https://www.peeringdb.com/ix/359
-
Je cherchais s'il y avait un PNI ou peering Akamai sur l'infra Kwaoo pour y mettre une sonde.
apparement çà passerait par Ielo Et Cogent à Genève
https://as24904.kwaoo.net/as-stats/top.php?numhours=24&n=20&link_link8=on&link_link10=on
puisque le peering appelé "Akamai" ne joue pas (ou alors tout est pété ... ce qui est possible)
-
apparement çà passerait par Ielo Et Cogent à Genève
https://as24904.kwaoo.net/as-stats/top.php?numhours=24&n=20&link_link8=on&link_link10=on
puisque le peering appelé "Akamai" ne joue pas (ou alors tout est pété ... ce qui est possible)
Les LOGS SNMP sont cassé à TH2 depuis 1/2 semaines
Donc AS-STATS est faux depuis 1/2 semaines
-
J'arrive un peu tard (anniversaire à fêter), mais voici la capture Wireshark réalisée par Krougher : L'IPv4 utilisée est bonne (le DNS utilisé était celui de Google dans la capture qu'il m'a fournit), mais la connexion n'arrive pas jusqu'au serveur.
On a "Time-to-live Exceeded" : Le paquet est détruit en route car il est passé par trop de routeurs. La cause est clairement due à une boucle : le trafic tourne en rond et fini par être détruit.
Le client envoi des [SYN] pour se connecter et tente des retransmission pendant 20 secondes avant de tenter une nouvelle connexion sur un autre port qui sera elle aussi en échec :
(https://lafibre.info/images/wireshark/202202_wireshark_time-to-live_exceeded_k-net.png)
Cette boucle folle de réseau chez K-net avait déjà été signalé sur CAPS par quelqu'un qui cherchait à joindre la Suisse.
tracert 104.108.55.15
Détermination de l’itinéraire vers a104-108-55-15.deploy.static.akamaitechnologies.com [104.108.55.15]
avec un maximum de 30 sauts :
1 3 ms 3 ms 3 ms k-box.home [192.168.1.1]
2 4 ms 4 ms 4 ms labalme.covage [10.2.0.178]
3 * * * Délai d’attente de la demande dépassé.
4 13 ms 13 ms 13 ms k-net.covage [10.2.0.5]
5 26 ms 26 ms 27 ms 172.20.0.196
6 26 ms 26 ms 26 ms 172.20.0.197
7 40 ms 39 ms 40 ms 172.20.0.196
8 40 ms 39 ms 40 ms 172.20.0.197
9 53 ms 53 ms 53 ms 172.20.0.196
10 55 ms 54 ms 53 ms 172.20.0.197
11 66 ms 65 ms 65 ms 172.20.0.196
12 66 ms 65 ms 65 ms 172.20.0.197
J'ai informé Frank Bisetti du problème.
-
Tu pourras dire aussi en même temps, que le routage de Ain est cassé. Tous les flux remonte à Paris depuis 2 mois.
-
J'essaye de voir quel canal de communication avec K-Net pour remonter intelligemment les problèmes.
Une boucle sur le réseau de ce type, c'est critique.
L'absence d'IPv6, le routage qui ne se fait pas au plus proche,... je ne lui en parlerais que quand les incidents critiques (Téléphonie, boucles,...) seront réglés.
J'ai suggéré un point d'information journalier complet (comme OVH suite à l'incendie (https://lafibre.info/ovh-datacenter/incendie-sur-un-site-ovh-a-strasbourg/msg850816/#msg850816)). OVH n'a pas été top pour gérer l'incendie (pas d'extinction automatique, plancher en bois, les pompiers qui ne peuvent pas intervenir car impossibilité de couper le 20 000 volts dans le bâtiment en feu,...) mais sur la communication ils ont bien géré, même si c'est toujours tourné de façon assez positive en oubliant de parler par exemple le dernier étage de SBG3, le plus impacté de ce datacentre.
Autre exemple, sur SBG1, au lieu de dire que les serveurs sont détruits et qu'il vont tenter de récupérer les disques en le mettant sur d'autres serveurs, la communication, c'est de dire que tout fonctionne bien, mais qu'il faut remplacer la carte mère (on ne ne dit pas qu'elle est détruite ou HS au passage)
(https://lafibre.info/images/ovh/202103_ovh_strabourg_changement_carte_mere.png)
Sur la communication du 19 mars, SBG1 semble pleinement opérationnel : https://lafibre.info/ovh-datacenter/incendie-sur-un-site-ovh-a-strasbourg/msg850816/#msg850816
Ils devrait dire opérationnel pour ce qui n'a pas brûlé, la communication est trompeuse, certains container de SBG1 ayant entièrement brûlés (y compris les disques).
Quelques heures après, il annonçait l’arrêt définitif de SBG1 (après avoir eu un peu de fumée dans un container inutilisé de SBG1, là aussi communication qui semble bien minimiser un second incendie)
La communication était juste "nous avons arrêté SBG1 et SBG4", avant que les pompiers laisse fuiter l'information que c'était plus grave :
(https://lafibre.info/images/ovh/202103_ovh_srasbourg_sbg1_feu_batteries.png) (https://lafibre.info/images/ovh/202103_ovh_srasbourg_sbg1_feu_batteries_2.png)
-
J'essaye de voir quel canal de communication avec K-Net pour remonter intelligemment les problèmes.
Je te confirme que les problèmes sont bien connus. Je vois régulièrement "K-Net" venir ici et écumer toutes les pages de tous les topics ;)
-
Tu pourras dire aussi en même temps, que le routage de Ain est cassé. Tous les flux remonte à Paris depuis 2 mois.
Coucou :) Est-ce lié, le ping moisi (selon ip pingued) le soir (par exemple 1.1.1.1 et d'autres sites : 200 ms ce soir mais 8.8.8.8 :4 ms) ?
-
Bonjour,
pour le coup avoir 200 ms de ping vers 1.1.1.1 et 4 ms 8.8.8.8 ce n'est pas un simple détour des paquets jusqu'à Paris (c'est 20 ms en + maximum - de Nice c'est 19 ms je pense qu'il est difficile de faire beaucoup plus loin que Nice de Paris), c'est signe d'une saturation sur un chemin/peering/transitaire. ..
-
Je te confirme que les problèmes sont bien connus. Je vois régulièrement "K-Net" venir ici et écumer toutes les pages de tous les topics ;)
Oh oui et cette boucle a déjà été signalé il y a plus d'un mois sur CAPS, sans résultats visibles!
-
Réponse de FB sur ce sujet : https://mobile.twitter.com/fbknet/status/1490411560724049923
-
Réponse de FB sur ce sujet : https://mobile.twitter.com/fbknet/status/1490411560724049923
10.2.0.219 IP africaine
172.20.0.197 IP africaine
(https://pix.milkywan.fr/s5GzKWh4.gif)
-
Petite explication si nécessaire, les IPs en question sont des IPs privées désignées dans la RFC1918.
Comme les IPs en 192.168.*.* que vous connaissez sans doute mieux.
-
(https://pix.milkywan.fr/s5GzKWh4.gif)
Et bien voilà la vérité…
Les infras TDF, Covage et K-Net sont en Afrique… ;D
Ping de 7,3 ms depuis chez moi vers 10.2.0.5, c'est une prouesse !
-
Réponse de FB sur ce sujet : https://mobile.twitter.com/fbknet/status/1490411560724049923
La vache!
Comme client amateur, je connais mieux le réseau K-net Covage et la RFC1918 que FB! :'(
C'est de l'humour encore non!?
Enfin j'espère...
Edit : j'avais référencé le tour de France des routeurs Covage K-net sur CAPS!
-
La vache!
Comme client amateur, je connais mieux le réseau K-net Covage et la RFC1918 que FB! :'(
C'est de l'humour encore non!?
Enfin j'espère...
Bah, le PDG, ça passe encore s'il n'y connaît pas grand chose en technique, mais si l'ingénieur réseau lui a répondu cela, on comprend pourquoi ça ne marche pas :o
Sinon, le coup de l'IP africaine… Ça va devenir un meme…
-
Et bien voilà la vérité…
Les infras TDF, Covage et K-Net sont en Afrique… ;D
Ping de 7,3 ms depuis chez moi vers 10.2.0.5, c'est une prouesse !
Bah non! Le Calvados est en Afrique... Non?
-
Bah non! Le Calvados est en Afrique... Non?
Pour les Anglais, l'Afrique commence à Calais… Donc oui ;D
-
Bah, le PDG, ça passe encore s'il n'y connaît pas grand chose en technique, mais si l'ingénieur réseau lui a répondu cela, on comprend pourquoi ça ne marche pas :o
Sinon, le coup de l'IP africaine… Ça va devenir un meme…
L'ingé réseau est un génie : C'est Aladin!
FB se targait dêtre passé à tous les postes de sa société. Il va falloir réviser si ce n'est pas de l'humour!
-
Franchement, lunaire est le fil sur twitter!
-
https://mobile.twitter.com/fbknet/status/1490662619979841538
Donc non seulement il n’y connaît rien, mais en plus il demande conseil sur son fil twitter?!? 😶
-
https://mobile.twitter.com/fbknet/status/1490662619979841538
Donc non seulement il n’y connaît rien, mais en plus il demande conseil sur son fil twitter?!? 😶
C'est un gérant ça me choque pas. Si c'était le CTO ou un Admin Réseau peut être ça me choque.
-
Franchement, lunaire est le fil sur twitter!
J’avoue, j’ai la mâchoire qui se décroche. Et là je commence sérieusement à me dire que rester chez K-net c’est potentiellement suicidaire :P
-
C'est un gérant ça me choque pas. Si c'était le CTO ou un Admin Réseau peut être ça me choque.
1) il se targuait d’être passé par tous les postes, 2) l’aveux d’incompétence totale sur twitter (et l’idée même de demander des conseil à Paul ou Jacques); si toi ça ne te choque pas, moi ça me fait dire « y-t’il un pilote dans l’avion, j’ai l’impression qu’on va se crasher » :P
-
Je ne pense pas que Patrick Drahi ou Xavier Niel soit en mesure de listes les plages d'IP privées :
- 10.0.0.0/8
- 100.64.0.0/10
- 172.16.0.0/12
- 192.168.0.0/16
- fd00::/8
=> https://lafibre.info/bgp/plage-ip-privee/
Il faut que Franck transmette l'incident à des gars du réseau pour la boucle soit supprimée.
-
https://mobile.twitter.com/fbknet/status/1490662619979841538
Donc non seulement il n’y connaît rien, mais en plus il demande conseil sur son fil twitter?!? 😶
Au moins, demander des avis, c'est pas dans l'arrogance. En tant que gérant, il essaye (on demande plus de transparence, moins d'arrogance et d'être un plus impliqués en tant que clients/investisseurs). Il interagit, demande… on ne peut pas lui reprocher cela. Pas choquant.
Encore une fois, comme le dit thedark, si c'était un ingé ou un admin, là ça serait très inquiétant…
-
Je ne pense pas que Patrick Drahi ou Xavier Niel soit en mesure de listes les plages d'IP privées :
Je pense pas que tu verras l'un ou l'autre l'admettre sur Twitter et demander des conseils par le même canal. Question sans doute de savoir communiquer les bons "signaux".
Au moins, demander des avis, c'est pas dans l'arrogance. En tant que gérant, il essaye (on demande plus de transparence, moins d'arrogance et d'être un plus impliqués en tant que clients/investisseurs). Il interagit, demande… on ne peut pas lui reprocher cela. Pas choquant.
Encore une fois, comme le dit thedark, si c'était un ingé ou un admin, là ça serait très inquiétant…
C'est une communication désastreuse compte tenu de la panade actuelle. Ça ne montre qu'une chose: que le patron navigue à vue et qu'il ne voit rien. Ils sont combien dans la boîte rappelle-moi? Que le PDG de SFR ne sache pas les détails techniques, c'est normal. Comme je disais il ne va pas non plus s'en vanter. Que le PDG d'un petit fournisseur n'y connaisse rien, c'est plus fâcheux car ça veut dire qu'il peut se faire mener en bateau par ses "équipes" (et vu le merdier, c'est probablement ce qu'il se passe).
Non vraiment, tout ça *est* très choquant.
-
L'incident est bien listé par Franck :
L'infrastructure historique était en IP publique, la nouvelle en IP privée.
Problèmes du jour :
- TDF (résolu à 15h)
- routage (en cours)
- VoIP (retardé)
https://x.com/fbknet/status/1490704081702293510
-
- VoIP (retardé)
Encore ???
-
Encore ???
Des vrais peintres. Moi si y'a pas un geste commercial à la fin de la blague, je pense que la résiliation suivra rapidement.
-
Encore ???
Ah, cette fois pas de date.
Et du coup l'IPV6 retardé aussi.
C'est parce que qu'internet et la TV fonctionnent encore, mais je pense aussi à la résiliation, support freebox pop posé à la place de l'ONT et câble téléphone du même emplacement vers le DTI posé aussi ce week-end, ça avance, ça avance...
-
- VoIP (retardé)[/color]
ça fait plus d'un mois que je suis sans téléphonie, là je perds patience, aucun Fai ne laisse traîner une panne plus d'un mois. >:(c'est pas sérieux.
-
- VoIP (retardé)[/color]
ça fait plus d'un mois que je suis sans téléphonie, là je perds patience, aucun Fai ne laisse traîner une panne plus d'un mois. >:(c'est pas sérieux.
https://jalerte.arcep.fr/ :P
-
Je ne pense pas que Patrick Drahi ou Xavier Niel soit en mesure de listes les plages d'IP privées :
C'est pour cela que je ne suis pas chez eux...
-
L'incident est bien listé par Franck :
L'infrastructure historique était en IP publique, la nouvelle en IP privée.
https://x.com/fbknet/status/1490704081702293510
J'ai tout le plan de l'ancienne infra dans ma supervision d'amateur et il n'y avait que des adresses privées sur les différents routeurs.
En 10.2.0.0/24 pour les collectes et livraison Covage
En 172.20.0.0 , 172.16.120.0, 172.16.100.0, 172.16.101.0, 172.16.104.0 pour les routeurs K-net
Donc je crois bien que c'est le contraire qui se passe. Privée devient publique.
Si c'est bien ce qui ce passe...
-
https://mobile.twitter.com/fbknet/status/1490662619979841538
Donc non seulement il n’y connaît rien, mais en plus il demande conseil sur son fil twitter?!? 😶
C'est très intéressant au contraire. C'est la première fois, à ma connaissance, qu'il demande un avis extérieur.
Peut-être que FB prend ses distances avec le CTO et qu'il a besoin d'un 2e avis pour le confronter...
Car encore aujourd'hui, il doit reporter le rétablissement de la téléphonie, sans donner de délai. Peut-être que lui-même commence à en avoir marre ?
-
https://jalerte.arcep.fr/ :P
C'est fait !
-
Il a tjs mon numéro, si besoin...
-
Il a tjs mon numéro, si besoin...
Appelle le. FB a l'air quand même bien perdu.
-
C'est très intéressant au contraire. C'est la première fois, à ma connaissance, qu'il demande un avis extérieur.
Peut-être que FB prend ses distances avec le CTO et qu'il a besoin d'un 2e avis pour le confronter...
Car encore aujourd'hui, il doit reporter le rétablissement de la téléphonie, sans donner de délai. Peut-être que lui-même commence à en avoir marre ?
S'il veut confronter son CTO il va lui falloir quelque chose d'un poil plus solide que l'opinion de $internet :P
-
En 10.2.0.0/24 pour les collectes et livraison Covage
En 172.20.0.0 , 172.16.120.0, 172.16.100.0, 172.16.101.0, 172.16.104.0 pour les routeurs K-net
Donc je crois bien que c'est le contraire qui se passe. Privée devient publique.
Si c'est bien ce qui ce passe...
Là comme ça, vu le traceroute posté, je pense qu'il ne s'est rien passé contrairement à ce que dit FB. Il a du être mal informé :(.
-
Toujours le même souci ?
Optix a remarqué un nouveau transitaire. Il y aussi un PNI avec twitch.
Ah tiens, K-Net sort via un nouveau transitaire : Sparkle (Telecom Italia).
-
Toujours le même traceroute que sur la première page, pour a104-108-55-152.deploy.static.akamaitechnologies.com [104.108.55.152]
-
Par contre, hasard ou pas, je n’ai pas eu ce soir les montées de ping habituelles qui étaient revenues depuis novembre, notamment vers CloudFlare ou OVH (exemples ci dessous).
Bon cela dit le ping vers OVH est passé de 8 à 23ms depuis hier soir minuit, semble t’il…
-
un tracert versleserveurovhdetonsmokeping ?
-
Vers OVH :
Détermination de l’itinéraire vers ns373340.ip-5-39-94.eu [5.39.94.25]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.2.1
2 3 ms 2 ms 2 ms 10.2.0.219
3 * * * Délai d’attente de la demande dépassé.
4 4 ms 4 ms 4 ms 120.138.24.109.rev.sfr.net [109.24.138.120]
5 * * * Délai d’attente de la demande dépassé.
6 5 ms 3 ms 4 ms 10.2.0.5
7 18 ms 17 ms 17 ms 172.20.0.196
8 * * * Délai d’attente de la demande dépassé.
9 25 ms 25 ms 24 ms be104.rbx-g2-nc5.fr.eu [94.23.122.242]
10 * * * Délai d’attente de la demande dépassé.
11 * * * Délai d’attente de la demande dépassé.
12 * * * Délai d’attente de la demande dépassé.
13 24 ms 23 ms 23 ms ns373340.ip-5-39-94.eu [5.39.94.25]
Dans le sens retour, ça n'aboutit pas, mais je pingue bien à 23 ms également :
traceroute to 185.219.204.173 (185.219.204.173), 30 hops max, 60 byte packets
1 vss-9a-6k.fr.eu (5.39.94.253) 0.495 ms 0.742 ms 0.726 ms
2 10.17.81.18 (10.17.81.18) 0.711 ms 10.17.81.16 (10.17.81.16) 0.696 ms 10.17.81.18 (10.17.81.18) 0.943 ms
3 10.73.16.110 (10.73.16.110) 0.393 ms 0.380 ms 10.73.16.98 (10.73.16.98) 0.366 ms
4 10.95.64.2 (10.95.64.2) 1.383 ms 10.95.64.136 (10.95.64.136) 0.613 ms 10.95.64.140 (10.95.64.140) 1.864 ms
5 par-th2-sbb1-nc5.fr.eu (54.36.50.226) 4.374 ms 4.611 ms par-gsw-sbb1-nc5.fr.eu (54.36.50.228) 4.347 ms
6 10.200.2.73 (10.200.2.73) 4.333 ms 4.175 ms 4.145 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
EDIT : à noter que c'était le ping "normal" avant la mi-décembre, comme le montre l'ensemble des mesures que j'ai depuis début septembre (date de début de la mesure)
-
https://x.com/fbknet/status/1490662619979841538?s=21
Tout juste, 10.0.0.0/8 me parle plus.
J'avais fais une requête au RIPE avec l'adresse IP et copié le résultat sans trop réfléchir...
Il vaut mieux des IP publiques ou privées pour l'infrastructure ?
Quand je découvre ce message je me dit (dans le désordre) :
- K-Net n’est plus vraiment K-Net
- Son CTO est en vacances ? Au ski ?
- Les pbs ne sont pas terminés…
- C’est triste mais je ne regrette pas mon départ de K-Net
- Que fait l’OI ?
- Combien de temps ça va durer ?
- Bon courage pour les clients…
-
- Que fait l’OI ?
Bonjour,
quel rapport avec l'OI ? une fois que K-NET récupère les paquets l'OI ne peut plus rien faire et le réseau fonctionne puisque pas de problèmes pour les autres FAI ...
-
Oui c’est juste rien à voir avec l’OI !
-
Vers OVH :
6 5 ms 3 ms 4 ms 10.2.0.5
7 18 ms 17 ms 17 ms 172.20.0.196
Ce saut est haut
-
Il se passe des trucs bizarres ce soir. De temps en temps mon brouteur me dit que je "ne suis pas connecté à Internet" (alors qu'un ping Google passe encore). Apparemment un souci aléatoire de resolv. Vu que j'utilise les DNS K-net (🤦♂️) j'imagine qu'on doit être en train de bricoler de l'autre côté du tuyau :P
-
Il se passe des trucs bizarres ce soir. De temps en temps mon brouteur me dit que je "ne suis pas connecté à Internet" (alors qu'un ping Google passe encore). Apparemment un souci aléatoire de resolv. Vu que j'utilise les DNS K-net (🤦♂️) j'imagine qu'on doit être en train de bricoler de l'autre côté du tuyau :P
Le 2eme DNS est tombé surement le premier dns prend très chère.
-
Alors résolu ?
-
Alors résolu ?
Pour moi oui: j'ai configuré mon routeur pour qu'il utilise Cloudflare ;D
-
Le 2eme DNS est tombé surement le premier dns prend très chère.
Oui, ça s'est bien vu : https://lafibre.info/k-net-incident/tv-et-m3u-hs/msg927242/#msg927242
Le second est tombé 15 minutes après la chute du premier.
-
Pour moi oui: j'ai configuré mon routeur pour qu'il utilise Cloudflare ;D
Je parle du problème de Akamai.
-
Alors résolu ?
Pas ici, toujours le ping pong vers 104.108.55.152 (Akamai Edge), et toujours pas accès aux sites mentionnés en première page (dell.com, login.aliexpress.com, ...)
-
Mouais, va falloir un gars qui s'y connait un peu en routage. Bon courage au nouveau communicant pour expliquer ce ping pong qui dure depuis...
tracert 104.108.55.152
Détermination de l’itinéraire vers a104-108-55-152.deploy.static.akamaitechnologies.com [104.108.55.152]
avec un maximum de 30 sauts :
1 3 ms 3 ms 3 ms k-box.home [192.168.1.1]
2 6 ms 6 ms 4 ms labalme.covage [10.2.0.178]
3 * * * Délai d’attente de la demande dépassé.
4 15 ms 14 ms 13 ms k-net.covage [10.2.0.5]
5 27 ms 27 ms 26 ms ping [172.20.0.196]
6 27 ms 26 ms 26 ms pong [172.20.0.197]
7 41 ms 40 ms 40 ms ping [172.20.0.196]
8 41 ms 40 ms 40 ms pong [172.20.0.197]
9 54 ms 53 ms 53 ms ping [172.20.0.196]
10 53 ms 52 ms 53 ms pong [172.20.0.197]
...
-
Mouais, va falloir un gars qui s'y connait un peu en routage. Bon courage au nouveau communicant pour expliquer ce ping pong qui dure depuis...
tracert 104.108.55.152
Détermination de l’itinéraire vers a104-108-55-152.deploy.static.akamaitechnologies.com [104.108.55.152]
avec un maximum de 30 sauts :
1 3 ms 3 ms 3 ms k-box.home [192.168.1.1]
2 6 ms 6 ms 4 ms labalme.covage [10.2.0.178]
3 * * * Délai d’attente de la demande dépassé.
4 15 ms 14 ms 13 ms k-net.covage [10.2.0.5]
5 27 ms 27 ms 26 ms ping [172.20.0.196]
6 27 ms 26 ms 26 ms pong [172.20.0.197]
7 41 ms 40 ms 40 ms ping [172.20.0.196]
8 41 ms 40 ms 40 ms pong [172.20.0.197]
9 54 ms 53 ms 53 ms ping [172.20.0.196]
10 53 ms 52 ms 53 ms pong [172.20.0.197]
...
Ben oui, ça serait bien que cela soit pris en compte, puis résolu…
Depuis ici, pas de route :
root@HERMES:~/$ mtr -w 104.108.55.152
Start: 2022-02-10T15:19:20+0100
HOST: HERMES Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.2.0.211 0.0% 10 2.6 2.7 2.5 2.9 0.1
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 10.2.0.5 0.0% 10 6.9 6.9 6.7 7.1 0.1
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
-
Est-ce que quelqu'un ici en sait suffisamment sur l'infrastructure pour nous expliquer si le problème de routage (ping-pong) est plutôt lié à un mauvais routage statique ou à une erreur de configuration d'un IGP ou EGP ?
-
Normalement pas de routage statique, moi je planche pour l'erreur de config I/EGP en effet. Vu les compétences du CTO en la matière, c'est pas surprenant.
-
Faut presque prendre un tunnel chez MilkyWan pour avoir un internet fiable...
Bon ça donne une opportunité business pour Hugues :D
-
Déjà que le patron est triste parce qu'on a des abonnés qui sont partis chez nous, si je me mets à faire de l'overlay, je risque de me faire blacklister mes IP ^^
-
Déjà que le patron est triste parce qu'on a des abonnés qui sont partis chez nous, si je me mets à faire de l'overlay, je risque de me faire blacklister mes IP ^^
(https://i0.wp.com/elrincon.tv/wp-content/uploads/2014/09/The-Blacklist-en-Espa%C3%B1a.jpg?ssl=1)
-
Déjà que le patron est triste parce qu'on a des abonnés qui sont partis chez nous, si je me mets à faire de l'overlay, je risque de me faire blacklister mes IP ^^
Ben quand on résout pas les problèmes il faut pas s'étonner, à titre perso si mon problème n'est pas résolu prochainement c'est ce qu'il va arriver ! Je vais pas continuer a débourser pour une fibre qui ne fonctionne pas !
-
C'est résolu selon bolemo
https://lafibre.info/k-net-incident/recapitulatif-des-problemes-en-cours-et-non-resolus/msg929508/#msg929508
-
Je confirme que ça fonctionne (et que ça ne fonctionnait pas hier)
-
Je test quand je récupère une fibre qui fonctionne, un jour...
-
Bonjour,
je pensais mon problème lié à ça, mais comme le sujet est résolu et que j'ai toujours mes problèmes, je ne sais plus trop.
Sur mes devices android (smartphone et mibox), les accès sont KO à des services comme Disney+, Molotov. Ou encore sur twitter, seuls les textes sont chargés mais pas les images.
Par contre, son mon ordi (connecté à internet avec la même connexion), pas de soucis particulier pour accéder à ces services ... autant sur ordi je peux trouver les outils du navigateur pour identifier quelles requêtes ne passent pas, mais sur android je suis démuni.
Vous pensez que c'est lié à cet incident ? ou rien à voir? vous voulez que je crée un topic séparé?
-
Bonjour,
je pensais mon problème lié à ça, mais comme le sujet est résolu et que j'ai toujours mes problèmes, je ne sais plus trop.
Sur mes devices android (smartphone et mibox), les accès sont KO à des services comme Disney+, Molotov. Ou encore sur twitter, seuls les textes sont chargés mais pas les images.
Par contre, son mon ordi (connecté à internet avec la même connexion), pas de soucis particulier pour accéder à ces services ... autant sur ordi je peux trouver les outils du navigateur pour identifier quelles requêtes ne passent pas, mais sur android je suis démuni.
Vous pensez que c'est lié à cet incident ? ou rien à voir? vous voulez que je crée un topic séparé?
Sur votre interface BOX. IPV6 est activé ? Si oui désactiver le .
-
Sur votre interface BOX. IPV6 est activé ? Si oui désactiver le .
Je viens de désactiver, mais il semble qu'il y a un problème lors de la prise en compte.
je retesterai à l'occasion.
-
Sur votre interface BOX. IPV6 est activé ? Si oui désactiver le .
du coup; c'était bien ça, merci encore!
-
du coup; c'était bien ça, merci encore!
Super bonne nouvelle. Pas de souci.
(https://pix.milkywan.fr/jzDQeWOp.jpg)