Ce n'était qu'une question de temps, mais Free aurait-il basculé du mauvais côté en succombant à la mise en place "d'optimiseurs BGP" comme nos amis les CDN !? :)
Le 10/01/2020 à 15:53, Guillaume Gildas a écrit : > Voici ce que j'ai observé depuis une IP Free (cf. traceroute plus bas) : > La route vers l'avant-dernier routeur (et même le précédent) se fait en 4 à > 5 sauts alors que la route vers l'IP finale se voit ajouter des > intermédiaires via Cogent en 12 sauts. > La route vers chacun des routeurs intermédiaires ping correctement sans > jamais d'interruption. Chacun de ces routeurs sont identifiés chez Proxad > ou Cogent. > Le dernier routeur serait identifié chez Proxad. La cible aurait un peering > chez Proxad ? > Seule la route vers l'IP finale s'interrompt 20-35 secondes toutes les 5-25 > minutes. > > Voici un traceroute entre le 3ème saut et la cible : > > Route vers l'IP finale avec incident dès le 5ème saut inclus : > 3 - 213.228.13.62 > 4 - 194.149.163.189 - p11-crs16-1-be1125.intf.routers.proxad.net > 5 - 194.149.166.38 > 6 - 149.11.115.13 - be4204.ccr32.par04.atlas.cogentco.com > 7 - 154.54.61.21 - be2103.ccr42.par01.atlas.cogentco.com > 8 - 154.54.78.98 - be2381.rcr21.lux01.atlas.cogentco.com > 9 - 154.25.0.234 - te0-0-2-0.nr11.b038963-0.lux01.atlas.cogentco.com > 10 - 212.27.56.30 - francfort-6k-1-po100.intf.routers.proxad.net > 11 - 194.149.160.198 - strasbourg-crs8-1-1007.intf.routers.proxad.net > 12 - 92.223.24.93 > > Route vers le routeur précédent (11ème saut) en seulement 4 sauts, jamais > d'incident : > 3 - 213.228.13.62 > 4 - 194.149.160.198 - strasbourg-crs8-1-1007.intf.routers.proxad.net > > Route vers le 10ème saut en 5 sauts, jamais d'incident : > 3 - 213.228.13.62 > 4 - 194.149.163.185 - strasbourg-crs8-1-be1011.intf.routers.proxad.net > 5 - 212.27.56.30 - francfort-6k-1-po100.intf.routers.proxad.net > > J'ai constaté qu'après le retour à la normale suivant chaque incident, les > routeurs aux sauts 10 et 11 changent systématiquement. > > J'ai du mal à interpréter les constatations... De plus, je ne comprends pas > la route avec un détour via Cogent. > > On Fri, Jan 10, 2020 at 12:39 PM David Ponzone <david.ponz...@gmail.com> > wrote: > >> J’ai été un peu médisant, mais un vendredi, ça passe. >> >> Le ping vers Cogent a l’air clean. >> La route est pas symétrique, ça revient par CORE BACKBONE (ISP DE) puis >> LEVEL3. >> >> J’essaie de voir si ça merde aussi entre Free et un de ces 2 là, mais pour >> le moment je vois rien. >> >> Donc ça serait quand même un problème sur le réseau cible, peut-être au >> niveau de son transit CORE BACKBONE. >> >>> Le 10 janv. 2020 à 11:38, Oliver varenne <o.vare...@ipconnect.fr> a >> écrit : >>> Si ça peut aider: >>> Ping depuis fibre free grand public vers 185.12.240.61 : le probleme >> vient de se produire (11h37) >>> Réponse de 185.12.240.61 : octets=32 temps=27 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=26 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=26 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=26 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=26 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=26 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=26 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=27 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=27 ms TTL=48 >>> Délai d’attente de la demande dépassé. >>> Délai d’attente de la demande dépassé. >>> Délai d’attente de la demande dépassé. >>> Délai d’attente de la demande dépassé. >>> Délai d’attente de la demande dépassé. >>> Délai d’attente de la demande dépassé. >>> Réponse de 185.12.240.61 : octets=32 temps=26 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=26 ms TTL=48 >>> Réponse de 185.12.240.61 : octets=32 temps=26 ms TTL=48 >>> >>> Statistiques Ping pour 185.12.240.61: >>> Paquets : envoyés = 45, reçus = 39, perdus = 6 (perte 13%), >>> Durée approximative des boucles en millisecondes : >>> Minimum = 26ms, Maximum = 29ms, Moyenne = 26ms >>> >>> >>> >>> >>> >>> Cordialement, >>> >>> >>> >>> Olivier Varenne >>> Co-gérant, Commercial & Développeur >>> T +33 (0)4 27 04 40 00 | ipconnect.fr >>> >>> Suivez-nous ! >>> >>> >>> >>> >>>> -----Message d'origine----- >>>> De : frnog-requ...@frnog.org <frnog-requ...@frnog.org> De la part de >>>> David Ponzone >>>> Envoyé : vendredi 10 janvier 2020 11:29 >>>> À : Guillaume Gildas <guillaume.gilda...@gmail.com> >>>> Cc : frnog-t...@frnog.org >>>> Objet : Re: [FRnOG] [TECH] Problème cyclique de routage >>>> >>>> J’ai mis un ping continu en place depuis un ADSL Free vers >>>> 185.12.240.61, on va voir si j’ai la même chose que toi. >>>> En tout cas, 20 à 35 secondes, ça pourrait bien être un délai de >>>> reconvergence BGP. >>>> >>>>> Le 10 janv. 2020 à 10:26, Guillaume Gildas >>>> <guillaume.gilda...@gmail.com> a écrit : >>>>> L'incident se produit environ 100 à 150 fois sur 24 heures et il dure >>>> environ 20 à 35 secondes à chaque occurrence. >>>>> Je pense que les divers incidents peuvent contribuer à pousser les >>>>> clients à choisir des FAI pro, mais ils trouvent toujours qu'en >>>>> moyenne ils y gagnent... :( >>>>> >>>>> Guillaume >>>>> >>>>> >>>>> On Fri, Jan 10, 2020 at 9:54 AM David Ponzone >>>> <david.ponz...@gmail.com <mailto:david.ponz...@gmail.com>> wrote: >>>>> Tu sais dire combien de temps ça dure à chaque fois et combien de fois >>>> par jour ? >>>>> Ca pourrait nous indiquer si ça vient d’un flap de peering quelque part >>>> et du temps de reconvergence BGP. >>>>> Sinon pour moi, c’est surtout les clients qui doivent impliquer Free. >> Mais >>>> ça va pas être simple. >>>>> Quand on dit aux gens de rester chez les fournisseurs Pro, c’est pas >>>> pour rien. >>>>>> Le 10 janv. 2020 à 08:26, Guillaume Gildas >>>> <guillaume.gilda...@gmail.com >>>> <mailto:guillaume.gilda...@gmail.com>> a écrit : >>>>>> Merci pour ta réponse David. >>>>>> >>>>>> J'ai un peu plus d'infos : >>>>>> >>>>>> Le problème est constaté chez tous les clients utilisant Free comme >> FAI >>>> et est totalement résolu lorsqu'ils utilisent un VPN hébergé à >> l'extérieur de >>>> l'infra de leur FAI. >>>>>> Les autres clients ne semblent pas impactés. >>>>>> Uptimerobot ne détecte pas de problème. >>>>>> >>>>>> La route passe en temps normal via Cogent, mais le premier routeur >>>> injoignable au moment du problème se situe en amont : 194.149.166.38. >>>>>> Qui contacter ? >>>>>> Qui doit initier la conversation : les clients vers leur FAI ; ou le >>>> fournisseur de contenu au Luxembourg vers Cogent ou Free ? >>>>>> >>>>>> Cordialement, >>>>>> -- >>>>>> Guillaume GILDAS >>>>>> >>>>>> >>>>>> On Thu, Jan 9, 2020 at 10:20 PM David Ponzone >>>> <david.ponz...@gmail.com <mailto:david.ponz...@gmail.com>> wrote: >>>>>> J’oubliais: si quand l’incident se produit, tu ne peux plus pinger les >>>> cibles, tu peux éventuellement monitorer les 3 cibles depuis un site >>>> externe (type uptimerobot) pour voir si eux aussi voient l’incident. >>>>>> Si oui, ça prouve que ça vient probablement de l’AS cible. >>>>>> Si non, ça prouve pas grand chose (ça prouve en tout cas pas que >>>> c’est la faute du backbone Free). >>>>>> Y a des gens de Free sur la liste donc ils vont peut-être quand même >>>> vérifier. >>>>>> C’est le double-effet FRnOG. >>>>>> >>>>>>> Le 9 janv. 2020 à 20:05, Guillaume Gildas >>>> <guillaume.gilda...@gmail.com >>>> <mailto:guillaume.gilda...@gmail.com>> a écrit : >>>>>>> Bonjour, >>>>>>> >>>>>>> Je rencontre un problème cyclique de routage pour joindre ces trois >>>>>>> serveurs portant l'IP : >>>>>>> 92.223.24.96 >>>>>>> 185.12.240.61 >>>>>>> 92.223.24.242 >>>>>>> >>>>>>> Ma route passe notamment par les routeurs 194.149.163.189 puis >>>> par >>>>>>> 194.149.166.38. >>>>>>> Toutes les 5 à 10 minutes et durant une trentaine de secondes, le >>>>>>> routeur >>>>>>> 194.149.166.38 disparaît du traceroute et le trafic est envoyé sur >>>>>>> le routeur 194.149.163.130. >>>>>>> Ensuite, le trafic revient à sa route d'origine. >>>>>>> >>>>>>> Or, durant le laps de temps où la route d'origine n'est plus >>>>>>> joignable, les destinations ne sont pas joignables (ce qui pose un >>>>>>> problème pour de la VOIP etc). >>>>>>> >>>>>>> Ce problème est apparu dans la journée du samedi 4 janvier et >>>>>>> persiste à ce jour, quelle que soit la période de la journée. >>>>>>> >>>>>>> Je cherche : >>>>>>> - Qui contacter pour résoudre ce problème, >>>>>>> - Qui doit prendre l'initiative de cet échange (les clients >>>>>>> derrière leur FAI ou bien le fournisseur de contenu hébergeant les >>>> serveurs ?). >>>>>>> Et par curiosité, quel est votre avis technique (ou commercial ?) >>>>>>> sur ce type de problème ? >>>>>>> >>>>>>> Merci pour votre aide, >>>>>>> >>>>>>> Cordialement, >>>>>>> -- >>>>>>> Guillaume GILDAS >>>>>>> >>>>>>> --------------------------- >>>>>>> Liste de diffusion du FRnOG >>>>>>> http://www.frnog.org/ <http://www.frnog.org/> >>>> >>>> --------------------------- >>>> Liste de diffusion du FRnOG >>>> http://www.frnog.org/ >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Jérôme Marteaux 06.16.21.32.34 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
