RE: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
> Jérôme Fleury a écrit : > Une regle en accidentologie c'est que plus l'accident est important, plus > il y a de causes (root causes) qui s'additionnent pour l'expliquer. C'est > vrai en aviation, c'est vrai dans le nucleaire, etc. Ce leak n'echappe pas > a la regle. Il n'y a pas 1 root cause, ou 1 responsable, mais de multiples C'est vrai, mais tu oublies la notion de déclencheur (trigger). A brule un feu rouge et emboutit B. B ne portait pas sa ceinture et est éjecté de la voiture. C qui attendait sur le trottoir est blessé à la tête quand B le touche. Est-ce que si B avait porté sa ceinture C aurait été blessé ? Probablement pas. C'est quelle assurance qui va payer les frais médicaux de C ? Celle de A. Dans l'assurance et la justice, tu ne peux pas faire d'hypothèses du genre "qu'est ce qui se serait passé si". Pourquoi ton réseau est tombé ? Parce qu'il y a un con qui se pignolait avec un optimiseur BGP sans comprendre comment çà marchait et qui a injecté TES préfixes, et pire encore une version plus longue. T'as été blessé sans rien faire en étant sur le trottoir et çà ne serait pas arrivé si Verizon avait porté sa ceinture, mais "si" çà compte pour que couic. Le déclencheur (trigger) de l'accident, c'est l'optimiseur BGP. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
> Jérôme Fleury a écrit : > Ce qu'on n'excuse pas c'est d'etre injoignable. Pour çà je les mets tous dans le même bateau. C'est çà qui n'est pas bien passé : pareil pour tous les autres et on me dit dans l'oreillette que les gros FAI Français ils ne lavent pas trop blanc dans ce domaine non plus. Verizon c'est peut-être pas les plus futés mais c'est souvent pas trop crade. T'as appelé un Tier-1 et ils n'ont pas répondu ? Oh mon bon Monsieur, mais que fait la police ? Par curiosité, t'as essayé nanog ? > Je pense qu'on s'en prend a la bonne societe. Tu t'es fais des ennemis solides qui ont les dents longues. > Ca fait des annees que la communaute fait comme si ce probleme n'existait > pas. On aime bien dire qu'on est des architectes, mais la realite c'est > qu'on a construit un chateau de cartes, et que maintenant il faut > solidifier tout ca. Par habitude, depuis 20 ans, on cache ca sous le tapis. +1 > - On a signe tous nos prefixes, et on a deploye RPKI Origin Validation sur > nos 193+ PoPs. Là je dis bravo. > - On a open-sourced un cache et validateur RPKI: > https://blog.cloudflare.com/cloudflares-rpki-toolkit/, > https://blog.cloudflare.com/rpki-details/ Faut aller chercher le TAL ARIN séparément, je suppose ? Tu n'est pas aussi protégé que tu le crois, pour les préfixes chez ARIN. Il y a plein de gens qui regardent la clause de dédommagement dans le TAL et ça les fait hurler et ils ne valident pas les préfixes ARIN. > En exclu, on sort un portail RPKI public: https://rpki.cloudflare.com/ Sympa, mais j'ai juste eu plusieurs fois une erreur il y a quelques minutes. OK maintenant. > - En exclu, tu peux tester RPKI-RTR avec tes routeurs sur notre > service public: rtr.cloudflare.com (haters gonna hate) Sympa aussi. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
On Wed, Aug 28, 2019 at 7:56 PM Michel Py < mic...@arneill-py.sacramento.ca.us> wrote: > Bonjour Jérôme, > > > Jérôme Fleury a écrit : > > Est-ce qu'on frappe plus fort sur Verizon sur notre blog ? Oui. 2 > raisons a cela: > > - impossibilite totale de les joindre > > Pas pire que les autres. Essaie AT ou Cogent, çà peut prendre 1 semaine > entière et parler avec 30 personnes différentes pour _finalement_ en avoir > un qui comprenne le ba-ba du réseau. Si tu n'est pas un client direct ou un > autre T1, tu peux crever. > Au moins AT a deploye peerlock et RPKI Origin Validation. Resultat: 0 impact pour leurs clients suite au leak de Verizon/DQE https://twitter.com/JobSnijders/status/1144032070181593088 (les graphs viennent de chez nous) > > - c'est un Tier1, donc leur responsabilite envers la qualite des routes > > fournies sur Internet est bien plus importante que pour DQE > > Cà ne les excuse pas, mais en général ils ne sont pas si pire. Plus le > réseau est grand, plus il y a des trucs qui passent au travers des mailles > du filet. > Je suis d'accord avec cela. Ce qu'on n'excuse pas c'est d'etre injoignable. C'est un des 4 grands principes de MANRS: https://www.manrs.org/isps/guide/coordination/ Si on avait pu joindre quelqu'un, l'incident aurait dure 30 mins au lieu de 2h. > Tu t'en prends à la mauvaise société. Je ne cherche pas à défendre > Verizon, mais honnêtement ce n'est pas eux qui sont le mouton noir des > Tier-1. Tu avais (et toujours a) bien plus de chances que le même scénario > t'arrive avec un autre. > Je pense qu'on s'en prend a la bonne societe. > Si tu as envie de pousser un coup de gueule (c'est compréhensible), fais > que çà serve à quelque chose. Ce que Verizon a fait, c'est une erreur. Et > tu peux brailler tout ce que tu veux, çà continuera à arriver. Errare > humanum est, ce n'est pas facile d'être Tier-1. Le coup du "moi je lave > plus blanc", c'est un peu facile. > Ca fait des annees que la communaute fait comme si ce probleme n'existait pas. On aime bien dire qu'on est des architectes, mais la realite c'est qu'on a construit un chateau de cartes, et que maintenant il faut solidifier tout ca. Par habitude, depuis 20 ans, on cache ca sous le tapis. De notre cotre on a decide de communiquer dessus et d'etre transparents. Ca a plus de chances de faire avancer les choses que de faire l'autruche. On ne pretend pas etre meilleurs. Rien ne me terrifie plus que d'etre le prochain leaker. Avec des milliers de sessions eBGP partout dans le monde, ca peut arriver n'importe quand. Pour cela j'aime bien m'assurer que mes upstreams vont me filtrer. Ce que tu peux faire, c'est pousser à la roue sur les choses qui pourraient > réduire le risque (comme RPKI), et passer la bonne parole que ces > optimiseurs de daube, c'est de la poudre verte. > Ca tombe bien c'est exactement ce qu'on fait depuis plus d'un an: - On a signe tous nos prefixes, et on a deploye RPKI Origin Validation sur nos 193+ PoPs. - On a open-sourced un cache et validateur RPKI: https://blog.cloudflare.com/cloudflares-rpki-toolkit/, https://blog.cloudflare.com/rpki-details/ - En exclu, on sort un portail RPKI public: https://rpki.cloudflare.com/ - En exclu, tu peux tester RPKI-RTR avec tes routeurs sur notre service public: rtr.cloudflare.com (haters gonna hate) Et on presente partout dans le monde: LATAM: https://www.lacnic.net/innovaportal/file/3207/1/rpkideployment-at-scale-lacnog2flacnic-2018.pdf EU: https://ripe77.ripe.net/presentations/156-RPKI-deployment-at-scale-RIPE-1.pdf APAC: https://www.sgnog.net/SGNOG7/A.7%20Sgnog%20-%20Cloudflare_s%20RPKI%20validator%20Updated%20copy.pdf and https://www.slideshare.net/mynog/rpki-and-me Africa: https://www.afpif.org/wp-content/uploads/2019/08/Cloudflare.pdf --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Bonjour Jérôme, > Jérôme Fleury a écrit : > Est-ce qu'on frappe plus fort sur Verizon sur notre blog ? Oui. 2 raisons a > cela: > - impossibilite totale de les joindre Pas pire que les autres. Essaie AT ou Cogent, çà peut prendre 1 semaine entière et parler avec 30 personnes différentes pour _finalement_ en avoir un qui comprenne le ba-ba du réseau. Si tu n'est pas un client direct ou un autre T1, tu peux crever. > - c'est un Tier1, donc leur responsabilite envers la qualite des routes > fournies sur Internet est bien plus importante que pour DQE Cà ne les excuse pas, mais en général ils ne sont pas si pire. Plus le réseau est grand, plus il y a des trucs qui passent au travers des mailles du filet. Tu t'en prends à la mauvaise société. Je ne cherche pas à défendre Verizon, mais honnêtement ce n'est pas eux qui sont le mouton noir des Tier-1. Tu avais (et toujours a) bien plus de chances que le même scénario t'arrive avec un autre. > Je ne sais pas quoi repondre a ca. What the fuck ? Tom Strickx, de l'equipe > reseau de Cloudflare a Londres, qui a participe a la resolution de l'incident, > a ecrit ce blog entierement de sa plume. Je n'ai pas ecrit ce post. Merci de la précision. Fais attention aux peaux de banane, il y a eu des choses pas sympa dans la chaleur de l'action. Si tu as envie de pousser un coup de gueule (c'est compréhensible), fais que çà serve à quelque chose. Ce que Verizon a fait, c'est une erreur. Et tu peux brailler tout ce que tu veux, çà continuera à arriver. Errare humanum est, ce n'est pas facile d'être Tier-1. Le coup du "moi je lave plus blanc", c'est un peu facile. Ce que tu peux faire, c'est pousser à la roue sur les choses qui pourraient réduire le risque (comme RPKI), et passer la bonne parole que ces optimiseurs de daube, c'est de la poudre verte. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Desole pour le retard de la reponse dans ce thread. On Thu, Jun 27, 2019 at 5:50 AM Michel Py < mic...@arneill-py.sacramento.ca.us> wrote: > > Désolé de le dire, et sans excuser Verizon qui n'avaient pas les > précautions de base en place, c'est de la récupération politique. C'est pas > Verizon qui a merdé. Même si c'est vrai qu'en tant que T1 ils devraient > avoir filtré le bordel, le principe de la patate chaude et de la confiance > qu'on a quand on accepte une session eBGP avec quelqu'un d'autre sont > toujours la base du fonctionnement de la DFZ. Une regle en accidentologie c'est que plus l'accident est important, plus il y a de causes (root causes) qui s'additionnent pour l'expliquer. C'est vrai en aviation, c'est vrai dans le nucleaire, etc. Ce leak n'echappe pas a la regle. Il n'y a pas 1 root cause, ou 1 responsable, mais de multiples: - un BGP optimiseur, sans no-export - un ISP qui redistribue les routes "optimisees" a ses clients - un client qui redistribue a son upstream - un upstream qui accepte et redistribue - des Tier1 "complices" puisque la plupart on aussi accepte les routes de Verizon - felicitations a NTT et AT pour ne pas etre tombe dans le panneau Si on cumule tout ca, ca fait un incident global. Tu enleves une seule de ces root causes et l'incident soit ne se produit pas du tout, soit il est fortement reduit dans son impact. Est-ce qu'on frappe plus fort sur Verizon sur notre blog ? Oui. 2 raisons a cela: - impossibilite totale de les joindre - c'est un Tier1, donc leur responsabilite envers la qualite des routes fournies sur Internet est bien plus importante que pour DQE - DQE a repondu a notre appel telephonique, et a corrige en live. En passant, pour ceux qui en doutent, il n'y a pas que Cloudflare qui a ete impacte, loin de la. Voici des stats Cedexis pendant l'incident. Vous voyez AWS ? Jérome Fleury, j'ai lu ton blog. Le pire, c'est que tu as changé qui > l'avait écrit pour Tom Strickx. Tu crois qu'on avait pas vu çà venir ? > > C'est carrément craintos. Le lien au-dessus, c'était signé par Jérome > Fleury il y a 24 heures. > Je ne suis pas le seul à voir remarqué. C'est vraiment nul à chier. > Je ne sais pas quoi repondre a ca. What the fuck ? Tom Strickx, de l'equipe reseau de Cloudflare a Londres, qui a participe a la resolution de l'incident, a ecrit ce blog entierement de sa plume. Je n'ai pas ecrit ce post. Je peux confirmer que j'ai valide l'integralite de ce qu'il a ecrit avant sa publication. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
> Alexandre Bruyelles a écrit : > [...] Généralement je partage ton point de vue à propos des optimiseurs BGP, mais : > Au passage, n'oublions pas que l'AS qui n'a pas vocation de faire du > réseau n'est pas supposé avoir de T1 : il va plutôt avoir une paire de > T2 qui vont lui proposer un panel qualitatif de destination; Pourquoi ? Le client final (qui n'est pas en IX ou colo) n'a généralement pas tellement le choix de ses transitaires, en tout cas ici. Dans le cas récent, çà ne me surprends pas du tout qu'il ait acheté du transit d'un T1 et d'un T2. > Francois Devienne a écrit : > Par ailleurs l’Internet est une masse mouvante qui subit parfois des soucis, > y compris > sur des transitaires de très bonne qualité. Même chose sur les IX, même les > meilleurs. > Cela arrive qu’il y ait des dysfonctionnements que BGP ne voit pas. Certes, mais c'est du aux limitations inhérentes qui viennent du fait que BGP soit un protocole path-vector. Pour améliorer les chose, "yàkà" modifier BGP ou le remplacer, je que je ne vois pas arriver. Personne n'a l'expérience de faire du distance-vector ou du link-state à l'échelle de l'Internet, et depuis la nuit des temps toutes les tentatives qui ont essayé de changer le principe de la patate chaude ont échoué. Les optimiseurs BGP, je vois çà un peu comme QOS : sur son propre réseau dont on a le contrôle, oui. Sur l'Internet public dont on connait très peu, on s'y est tous cassé les dents et on en est presque tous arrivés à la même conclusion qui est que mettre un meilleur tuyau çà marche à chaque fois. Cà a l'air d'une solution qui cherche un problème. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
ReBonjour, Ce qui est dit ici me semble être plein de bon sens mais je mettrais un bémol. Ne serait-ce que pour disposer d’une réelle diversités des chemins, on recommande de prendre 2 ou 3 transits de Tiers 1 et autant d’IX que possible. Ainsi on a l’assurance de disposer de chemins différenciés dans les deux sens. Alors que si l’on a par exemple 1 seul Tier 1 et 2 transits Tier 2, il est possible, voire même probable que certaines destinations soient joignables par des chemins qui convergent quelque part. En cas de panne, il y a alors besoin de se reposer sur la résilience des Tiers 2 pour éventuellement récupérer un chemin acceptable. Et en cas de congestion, c’est pire on ne peut rien faire sauf espérer que le transitaire Tier 1 ait un moyen de détecter la panne …. C’est dommage car il n’y a pas réellement de Tiers 1 hexagonaux mais techniquement, c’est mieux et c’est pas vraiment plus cher. Autrement dit si on veut joindre uniquement des destinations bien identifiées et bien connectées à des tiers 2 locaux on peut faire le choix poétique et patriotique d’aller vers cette solution. Sinon non. Par ailleurs l’Internet est une masse mouvante qui subit parfois des soucis, y compris sur des transitaires de très bonne qualité. Même chose sur les IX, même les meilleurs. Cela arrive qu’il y ait des dysfonctionnements que BGP ne voit pas. Je ne veux incriminer personne donc je m’arrête là. Bonne soirée, François. > On 2 Jul 2019, at 16:13, Alexandre Bruyelles > wrote: > > Les optimiseurs bgp, ce sont de mauvaises solutions à un vrai problème > > Le vrai problème : quand tu as X liens pourris vers une destination X, > ta "qualité" n'est pas terrible (voir problématique) > > La fausse solution : faisont du vaudoo pour essayer de "choisir" le > meilleur des mauvais liens > > La bonne solution : mettre en production de bons liens > > > En effet, plusieurs possibilités: > - soit tu te moques de la destination X (c'est un vague AS en > biélorussie, OSEF). Dans ce cas, tu te moques aussi de la qualité que tu > as vers cet AS. > - soit la destination X est importante pour ton business, et du coup, au > choix: > - tu setup un PNI avec X > - tu te connectes à un IX pour joindre X > - tu te connectes à un transitaire qui est bon pour communiquer avec X > > > Si tu deploies l'algorithme, il n'y a pas de place saine pour les > "optimisateurs bgp" > > Au passage, n'oublions pas que l'AS qui n'a pas vocation de faire du > réseau n'est pas supposé avoir de T1 : il va plutôt avoir une paire de > T2 qui vont lui proposer un panel qualitatif de destination; > > Cordialement, > > On 7/2/19 3:25 PM, Francois Devienne wrote: >> Bonjour FRNOG, >> >> Je me permets d’apporter quelques précisions au sujet des optimiseurs BGP. >> >> En avant propos, la notion d’optimisation BGP ne revêt pas une forme unique. >> Elle était d’ailleurs souvent effectuée manuellement, de manière artisanale. >> Quel est l’objectif de ces optimisations en général ? —> Influencer les >> chemins entrant ou sortant afin : >> - d’éviter la saturation d’une interface IX/peer ou transit connecté à >> l’AS concerné, >> - d'empêcher ou limiter des dépassements de CDR, en sollicitant une >> capacité sous exploitée, >> - de contourner un chemin qui perd des paquets (une congestion >> franche), alors qu’un autre chemin, de meilleure qualité est disponible, >> - de contourner un blackhole involontaire, >> - d’améliorer les performances (RTD) avec une destination pour laquelle >> BGP a choisi un chemin sous-optimal. >> >> Pour ce faire, la manoeuvre d’optimisation s’appuie sur des mesures de >> performance et qualité des chemins ainsi que des collectes de données de >> trafic et de topologie (Flows, SNMP, BGP), éventuellement travaillées par >> des outils statistiques. >> Les décisions de routage sont obtenues par l’exécution d’une politique de >> routage, disons un algorithme dont la forme et les paramètres sont >> déterminés par l’utilisateur. >> Ensuite des configurations ou de nouvelles routes BGP sont envoyées aux >> routeurs BGP à l’edge. >> >> On pourrait alors argumenter que BGP suffit largement et que l’Internet >> marche très bien sans optimisation. Les statistiques montrent néanmoins que >> cela est faux. Sur un échantillon d’une dizaine d’AS en France, >> essentiellement connectées à des tiers 1 (deux transitaires au moins :-), >> plus de 50% des décisions de BGP sont sous-optimales. Parfois pour des >> différences négligeables, parfois pour quelques dizaines de millisecondes, >> ou encore pour 5% de perte de paquets. BGP ne voyant naturellement ni le RTD >> ni le packet loss end-to-end. Idem pour la gestion de capacité contractuelle >> ou physique. >> >> Décrire le ROI d’un optimiseur BGP de façon absolue est néanmoins >> impossible. Chaque AS écoule un trafic de typologie propre et exploite des >> connectivités qui acheminent ces flux particuliers selon des paramètres et
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Les optimiseurs bgp, ce sont de mauvaises solutions à un vrai problème Le vrai problème : quand tu as X liens pourris vers une destination X, ta "qualité" n'est pas terrible (voir problématique) La fausse solution : faisont du vaudoo pour essayer de "choisir" le meilleur des mauvais liens La bonne solution : mettre en production de bons liens En effet, plusieurs possibilités: - soit tu te moques de la destination X (c'est un vague AS en biélorussie, OSEF). Dans ce cas, tu te moques aussi de la qualité que tu as vers cet AS. - soit la destination X est importante pour ton business, et du coup, au choix: - tu setup un PNI avec X - tu te connectes à un IX pour joindre X - tu te connectes à un transitaire qui est bon pour communiquer avec X Si tu deploies l'algorithme, il n'y a pas de place saine pour les "optimisateurs bgp" Au passage, n'oublions pas que l'AS qui n'a pas vocation de faire du réseau n'est pas supposé avoir de T1 : il va plutôt avoir une paire de T2 qui vont lui proposer un panel qualitatif de destination; Cordialement, On 7/2/19 3:25 PM, Francois Devienne wrote: > Bonjour FRNOG, > > Je me permets d’apporter quelques précisions au sujet des optimiseurs BGP. > > En avant propos, la notion d’optimisation BGP ne revêt pas une forme unique. > Elle était d’ailleurs souvent effectuée manuellement, de manière artisanale. > Quel est l’objectif de ces optimisations en général ? —> Influencer les > chemins entrant ou sortant afin : > - d’éviter la saturation d’une interface IX/peer ou transit connecté à > l’AS concerné, > - d'empêcher ou limiter des dépassements de CDR, en sollicitant une > capacité sous exploitée, > - de contourner un chemin qui perd des paquets (une congestion > franche), alors qu’un autre chemin, de meilleure qualité est disponible, > - de contourner un blackhole involontaire, > - d’améliorer les performances (RTD) avec une destination pour laquelle > BGP a choisi un chemin sous-optimal. > > Pour ce faire, la manoeuvre d’optimisation s’appuie sur des mesures de > performance et qualité des chemins ainsi que des collectes de données de > trafic et de topologie (Flows, SNMP, BGP), éventuellement travaillées par des > outils statistiques. > Les décisions de routage sont obtenues par l’exécution d’une politique de > routage, disons un algorithme dont la forme et les paramètres sont déterminés > par l’utilisateur. > Ensuite des configurations ou de nouvelles routes BGP sont envoyées aux > routeurs BGP à l’edge. > > On pourrait alors argumenter que BGP suffit largement et que l’Internet > marche très bien sans optimisation. Les statistiques montrent néanmoins que > cela est faux. Sur un échantillon d’une dizaine d’AS en France, > essentiellement connectées à des tiers 1 (deux transitaires au moins :-), > plus de 50% des décisions de BGP sont sous-optimales. Parfois pour des > différences négligeables, parfois pour quelques dizaines de millisecondes, ou > encore pour 5% de perte de paquets. BGP ne voyant naturellement ni le RTD ni > le packet loss end-to-end. Idem pour la gestion de capacité contractuelle ou > physique. > > Décrire le ROI d’un optimiseur BGP de façon absolue est néanmoins impossible. > Chaque AS écoule un trafic de typologie propre et exploite des connectivités > qui acheminent ces flux particuliers selon des paramètres et événements non > déterministes. > Néanmoins, certains AS pensent avoir des performances et une qualité > convenables parce qu’ils n’ont aucun outil de mesures fiable. La “logique” > étant alors “Tant que je n’ai pas l’impression que ça déconne, c’est > certainement que ça marche très bien”. > > Il existe aujourd’hui deux grandes familles de solutions “d’optimiseurs”. > - Fait-maison : un certain nombre de grands producteurs de contenus, > d’hébergeurs, de CDN ou d’opérateurs ont développé leurs propres solutions de > mesure et d’automatisation du routage. Elles implémentent entièrement ou > partiellement ce que font les solutions commerciales. Il s’agit alors de code > propriétaire ou souvent d’agrégats de briques open source notamment pour la > collecte d’échantillons de trafic. > - Commerciaux : principalement trois solutions aujourd’hui : > - Internap MIRO / FCP = assez confidentiel > - Noction IRP = celui incriminé dans ce problème > - Border 6 NSI (Expereo XCA-Edge) = C’est nous, pour enlever > toute ambiguité. Technologie Française ! > Ainsi, il n’existe aucune norme / RFC ou définition communément admise de la > façon dont ces optimisations doivent être faites. > Chacun fait donc comme bon lui semble et certains apprennent de leurs erreurs. > > L’exemple du problème cité ici montre en effet que certains optimiseurs > découpent les subnets en deux pour les rendre “plus spécifiques” et qu’ils > deviennent ainsi préférés dans la table BGP et la table de routage. > Si 8.8.8.0/24 est routé via transit “A” avec
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
> À quoi ça sert d’optimiser le chemin de A vers B, quand on ne peut pas faire > en sorte d’utiliser le même chemin dans le sens B -> A ? Je m’auto-corrige: ou tout autre chemin optimal de B vers A, qui ne sera pas forcément le même que de A vers B. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Le 2 juil. 2019 à 15:25, Francois Devienne a écrit : > > Bonjour FRNOG, > > Je me permets d’apporter quelques précisions au sujet des optimiseurs BGP. > > > ...[long texte plein de choses très intéressantes, merci]… > > Bon appétit, > François. > François, Vous ne répondez pas avec précision à la question essentielle: À quoi ça sert d’optimiser le chemin de A vers B, quand on ne peut pas faire en sorte d’utiliser le même chemin dans le sens B -> A ? Evidemment, ça limite un peu la casse quand on évite de A vers B un chemin qui droppe, mais c’est tout. On devrait plutôt appeler ça un demi-optimiseur non ? Sauf si évidemment, A et B utilisent le même optimiseur. J’imagine la réaction du client à qui on a vendu une martingale le jour où il découvre que: -faut continuer à faire du fine-tuning de son BGP pour faire passer l’entrant par là où on voudrait (ce qui est très limité, on le sait tous) -s’il y a un chemin hors de son contrôle qui droppe des paquets à la pelle dans le sens Internet vers lui, l’optimiseur va rien voir/rien faire, et y a plus qu’à attendre les appels des clients mécontents J’espère que ça coûte pas trop cher ces trucs là. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Bonjour FRNOG, Je me permets d’apporter quelques précisions au sujet des optimiseurs BGP. En avant propos, la notion d’optimisation BGP ne revêt pas une forme unique. Elle était d’ailleurs souvent effectuée manuellement, de manière artisanale. Quel est l’objectif de ces optimisations en général ? —> Influencer les chemins entrant ou sortant afin : - d’éviter la saturation d’une interface IX/peer ou transit connecté à l’AS concerné, - d'empêcher ou limiter des dépassements de CDR, en sollicitant une capacité sous exploitée, - de contourner un chemin qui perd des paquets (une congestion franche), alors qu’un autre chemin, de meilleure qualité est disponible, - de contourner un blackhole involontaire, - d’améliorer les performances (RTD) avec une destination pour laquelle BGP a choisi un chemin sous-optimal. Pour ce faire, la manoeuvre d’optimisation s’appuie sur des mesures de performance et qualité des chemins ainsi que des collectes de données de trafic et de topologie (Flows, SNMP, BGP), éventuellement travaillées par des outils statistiques. Les décisions de routage sont obtenues par l’exécution d’une politique de routage, disons un algorithme dont la forme et les paramètres sont déterminés par l’utilisateur. Ensuite des configurations ou de nouvelles routes BGP sont envoyées aux routeurs BGP à l’edge. On pourrait alors argumenter que BGP suffit largement et que l’Internet marche très bien sans optimisation. Les statistiques montrent néanmoins que cela est faux. Sur un échantillon d’une dizaine d’AS en France, essentiellement connectées à des tiers 1 (deux transitaires au moins :-), plus de 50% des décisions de BGP sont sous-optimales. Parfois pour des différences négligeables, parfois pour quelques dizaines de millisecondes, ou encore pour 5% de perte de paquets. BGP ne voyant naturellement ni le RTD ni le packet loss end-to-end. Idem pour la gestion de capacité contractuelle ou physique. Décrire le ROI d’un optimiseur BGP de façon absolue est néanmoins impossible. Chaque AS écoule un trafic de typologie propre et exploite des connectivités qui acheminent ces flux particuliers selon des paramètres et événements non déterministes. Néanmoins, certains AS pensent avoir des performances et une qualité convenables parce qu’ils n’ont aucun outil de mesures fiable. La “logique” étant alors “Tant que je n’ai pas l’impression que ça déconne, c’est certainement que ça marche très bien”. Il existe aujourd’hui deux grandes familles de solutions “d’optimiseurs”. - Fait-maison : un certain nombre de grands producteurs de contenus, d’hébergeurs, de CDN ou d’opérateurs ont développé leurs propres solutions de mesure et d’automatisation du routage. Elles implémentent entièrement ou partiellement ce que font les solutions commerciales. Il s’agit alors de code propriétaire ou souvent d’agrégats de briques open source notamment pour la collecte d’échantillons de trafic. - Commerciaux : principalement trois solutions aujourd’hui : - Internap MIRO / FCP = assez confidentiel - Noction IRP = celui incriminé dans ce problème - Border 6 NSI (Expereo XCA-Edge) = C’est nous, pour enlever toute ambiguité. Technologie Française ! Ainsi, il n’existe aucune norme / RFC ou définition communément admise de la façon dont ces optimisations doivent être faites. Chacun fait donc comme bon lui semble et certains apprennent de leurs erreurs. L’exemple du problème cité ici montre en effet que certains optimiseurs découpent les subnets en deux pour les rendre “plus spécifiques” et qu’ils deviennent ainsi préférés dans la table BGP et la table de routage. Si 8.8.8.0/24 est routé via transit “A” avec 35ms de RTD mais que transit “B” montre un délai de 2ms, l’optimiseur envoie deux routes BGP 8.8.8.0/25 et 8.8.8.128/25 avec comme next-hop transit “B”. Ceci pose un sérieux problème car si vos filtres sortants sont (très) mal configurés et que vos transitaires ou peer d’IX acceptent n’importent quoi, vous pouvez hijacker une partie de l’Internet et aspirer du trafic d’autres notamment. Mais cela arrive quotidiennement à plus petite échelle avec des lascars qui font simplement n’importe quoi dans une configuration (sans optimiseur). D’ailleurs, pourquoi diable découper ces subnets ? En général un routeur BGP “A” ne renvoie pas à un routeur BGP “B” une best route qu’il a apprise de routeur “B”. Je dis "en général" car cela semble être une règle d’implémentation mais il y a débat sur l’origine et l’universalité de cette règle. L’optimiseur perd alors la visibilité sur les routes potentiellement disponibles s’il ne les a pas découpées en les annonçant. Il est dans tous les cas recommandé de tagger une communauté NO_EXPORT. Il est aussi possible de désactiver ce découpage des subnets (en tout cas chez nous) et en apprenant les routes BGP autrement que par la session BGP. Concernant les
RE: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
> Clement Cavadore a écrit : > Pour en avoir vu une chez un de mes clients (je vous rassure, j'ai fini > par arriver à le convaincre de l'éradiquer de son réseau Merci et +1 pour le reste de ta contrib. > et on ne sait *rien* du chemin retour. Et oui, le machin ne touche que le trafic sortant, donc à moins d'être un hébergeur çà ne sert à rien dès le départ. > Evidemment, a la fin de tout ca, elle te fait un beau dashboard te disant "on > a optimisé de 15% la latence > vers ce subnet, et baissé de 40% le loss, ton réseau il est tout beau tout > propre", avec des jolis camemberts, > et autres trucs qui font plaisir aux décideurs, qui du coup renouvellent la > licence de la shit. Et oui, les décideurs incompétents qui au lieu de comprendre comment leur réseau marche et de prendre les précautions de base du genre no-export achètent le produit miracle d'un vendeur de pompes usées. > La boiboite a un jour estimé que pour atteindre le /23 d'un client a lui (un > downstream, donc), c'était > mieux de passer par son transit T1, plutot que via le lien direct que le > client avait avec son réseau (!) > => Boum, deux /24 en interne, et un /23 en externe. Bilan: Le réseau > "optimisé" en BGP routait les deux > /24 via son transit, mais le transit ne connaissait que le /23, et le > renvoyait au réseau, qui du coup le > renvoyait a son transit, etc... et hop, boucle de routage. Merci > l'optimisation BGP ! C'est du SD-WAN, la boiboite connait tout mieux que toi. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
On Thu, 27 Jun 2019 08:06:50 +0200 Vivien Moreau wrote: > > Jérome Fleury, j'ai lu ton blog. Le pire, c'est que tu as changé > > qui l'avait écrit pour Tom Strickx. Tu crois qu'on avait pas vu çà > > venir ? > > > > C'est carrément craintos. Le lien au-dessus, c'était signé par > > Jérome Fleury il y a 24 heures. Je ne suis pas le seul à voir > > remarqué. C'est vraiment nul à chier. > > Pas sûr de comprendre ce qui a été "remarqué". Moi non plus. Et j'étais là. -- Étienne Labaume Network Engineer Cloudflare - AS13335 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
On Thu, 2019-06-27 at 08:47 +0200, Paul Rolland (ポール・ロラン) wrote: > Comme je n'ai pas fait mes devoirs sur des boites, qq'un peut > m'expliquer comme marchent ces optimiseurs ? J'ai la flemme non pas > de Googler ce matin, mais de faire le tri pour trouver un article qui > ne dise pas que des aneries marketo-commerciale ;) Pour en avoir vu une chez un de mes clients (je vous rassure, j'ai fini par arriver à le convaincre de l'éradiquer de son réseau), ca fonctionne de la sorte: 1- La boiboite dispose d'une sonde, qui peut utiliser plusieurs IP source. Cette sonde "teste" (je n'ai pas de détails sur les tests, mais il y a une histoire de latence/ping/loss a minima) plusieurs IP sur un pool défini 2- Il y a du PBR dans le réseau hébergeant la sonde, afin de faire sortir IP1 par Transit1, IP2 par transit2, etc... 3- Il y a un IBGP entre la boite diabolique, et les routeurs du réseau, qui permet d'influencer le routage: => Si la boiboite décide que "vers 2.2.0.0/16" c'est plus propre de passer par transit2 que transit1 (qui serait celui utilisé naturellement en BGP), alors elle peut désaggréger 2.2.0.0/16 en 2.2.0.0/17 + 2.2.128.0/17 en modifiant le next-hop, et envoyer ca dans le réseau en IBGP pour que ca sorte via transit2. Evidemment, a la fin de tout ca, elle te fait un beau dashboard te disant "on a optimisé de 15% la latence vers ce subnet, et baissé de 40% le loss, ton réseau il est tout beau tout propre", avec des jolis camemberts, et autres trucs qui font plaisir aux décideurs, qui du coup renouvellent la licence de la shit. Effectivement, ces junk routes, si elles existent, ne doivent absolument jamais sortir du réseau. Et c'est là que le bât blesse: parfois, y'a du fat-fingers, et des confs moisies chez les transitaires. De mon côté, j'estime que les "tests" faits par ces sondes ne peuvent pas etre concluants: Ca ping aléatoirement les IP d'un subnet, sans connaitre le contexte, savoir s'il s'agit d'anycast, de DSL saturées, etc, et on ne sait *rien* du chemin retour. Sans parler des problématiques rencontrées du genre: La boiboite a un jour estimé que pour atteindre le /23 d'un client a lui (un downstream, donc), c'était mieux de passer par son transit T1, plutot que via le lien direct que le client avait avec son réseau (!) => Boum, deux /24 en interne, et un /23 en externe. Bilan: Le réseau "optimisé" en BGP routait les deux /24 via son transit, mais le transit ne connaissait que le /23, et le renvoyait au réseau, qui du coup le renvoyait a son transit, etc... et hop, boucle de routage. Merci l'optimisation BGP ! https://www.youtube.com/watch?v=Tnod9vtB4xA -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Un article plus détaillé a été publié : https://blog.cloudflare.com/the-deep-dive-into-how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-monday/?utm_medium=email_source=blog_campaign=rss-feed Le jeu. 27 juin 2019 à 20:37, Michel Py a écrit : > > David Ponzone a écrit : > > Hmmm le client de Verizon et DQE a quand même dû faire une grosse > boulette > > aussi non ? C’est une sacré coïncidence avec une responsabilité triple > > (et heureusement, sinon ça arriverait beaucoup plus souvent). > > C'est un client, pas un FAI. > C'est même pas une boite d'info ou de réseau, ils sont dans la métallurgie. > AS récent, qui annonce 1 préfixe. > Je te parie qu'avant d'être multihomés ils n'avaient jamais touché BGP. > C'est un peu facile de dire que ce genre de débutant doit maitriser > prefix-list, route-map et communautés. > > Techniquement ils devraient avoir 2 route-maps, en sortie qui matche un > prefix-list ne contenant que leur préfixe, et en entrée qui fait un set > community no-export additive. > > Même si c'est vrai que çà ne serait pas arrivé si il y avait eu la bonne > config, faut pas compter sur le client final pour configurer leur partie en > prévoyant les boulettes que pourraient faire leurs transits. > > > > Pierre Emeriaud a écrit : > > Noction a sa part de responsabilité dans le merdier en n'activant pas > NO_EXPORT par défaut. > > Les gens qui utilisent une boite magique comme ça c'est qu'ils ne > maitrisent pas leur > > ingénierie bgp, sinon ils n'en auraient pas besoin. Et donc il faut les > prendre par la main > > en activant NO_EXPORT, ils ne le feront pas d'eux-même. > > Je plussoie. > > > >> Paul Rolland a écrit : > >> Comme je n'ai pas fait mes devoirs sur des boites, qq'un peut > m'expliquer comme marchent > >> ces optimiseurs ? J'ai la flemme non pas de Googler ce matin, mais de > faire le tri pour > >> trouver un article qui ne dise pas que des aneries marketo-commerciale > ;) > > > David Ponzone a écrit: > > J’ai pas regardé en détail, mais ça découpe en préfixe en sous-préfixe > > qui n’existe pas en réalité dans la full-table. > > Correct. Si tu annonces un /22, l'optimiseur va annoncer des /23 ou des > /24 pour être sur d'avoir la priorité. > > Et pour décider comment découper, ils ont des sondes partout et la recette > de la potion magique. > > Michel. > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
> David Ponzone a écrit : > Hmmm le client de Verizon et DQE a quand même dû faire une grosse boulette > aussi non ? C’est une sacré coïncidence avec une responsabilité triple > (et heureusement, sinon ça arriverait beaucoup plus souvent). C'est un client, pas un FAI. C'est même pas une boite d'info ou de réseau, ils sont dans la métallurgie. AS récent, qui annonce 1 préfixe. Je te parie qu'avant d'être multihomés ils n'avaient jamais touché BGP. C'est un peu facile de dire que ce genre de débutant doit maitriser prefix-list, route-map et communautés. Techniquement ils devraient avoir 2 route-maps, en sortie qui matche un prefix-list ne contenant que leur préfixe, et en entrée qui fait un set community no-export additive. Même si c'est vrai que çà ne serait pas arrivé si il y avait eu la bonne config, faut pas compter sur le client final pour configurer leur partie en prévoyant les boulettes que pourraient faire leurs transits. > Pierre Emeriaud a écrit : > Noction a sa part de responsabilité dans le merdier en n'activant pas > NO_EXPORT par défaut. > Les gens qui utilisent une boite magique comme ça c'est qu'ils ne maitrisent > pas leur > ingénierie bgp, sinon ils n'en auraient pas besoin. Et donc il faut les > prendre par la main > en activant NO_EXPORT, ils ne le feront pas d'eux-même. Je plussoie. >> Paul Rolland a écrit : >> Comme je n'ai pas fait mes devoirs sur des boites, qq'un peut m'expliquer >> comme marchent >> ces optimiseurs ? J'ai la flemme non pas de Googler ce matin, mais de faire >> le tri pour >> trouver un article qui ne dise pas que des aneries marketo-commerciale ;) > David Ponzone a écrit: > J’ai pas regardé en détail, mais ça découpe en préfixe en sous-préfixe > qui n’existe pas en réalité dans la full-table. Correct. Si tu annonces un /22, l'optimiseur va annoncer des /23 ou des /24 pour être sur d'avoir la priorité. Et pour décider comment découper, ils ont des sondes partout et la recette de la potion magique. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Le jeu. 27 juin 2019 à 12:11, David Ponzone a écrit : > > Le plus drôle c’est que le site de Noction t’explique que leur produit > automatise tout, évite les interventions manuelles. > Apparement, ils ont pas voulu forcer le respect des bonnes pratiques. > Ou DQE l’a désactivé. https://twitter.com/noction/status/1143177562191011840 "We do have no export community support and have done for many years. The use of more specifics is ALSO optional. Neither replaces the need for filters." https://www.noction.com/blog/do_route_optimizers_cause_fake_routes "In order to further reduce the likelihood of these problems occurring in the future, we will be adding a feature within Noction IRP to give an option to tag all the more specific prefixes that it generates with the BGP NO_EXPORT community. THIS WILL NOT BE ENABLE BY DEFAULT" Noction a sa part de responsabilité dans le merdier en n'activant pas NO_EXPORT par défaut. Les gens qui utilisent une boite magique comme ça c'est qu'ils ne maitrisent pas leur ingénierie bgp, sinon ils n'en auraient pas besoin. Et donc il faut les prendre par la main en activant NO_EXPORT, ils ne le feront pas d'eux-même. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
> > Alors OK, BGP, c'est qq chose qu'on etablit avec un partenaire de confiance > (normalement, meme si la confiance est "commerciale"), mais ca n'empeche > pas de faire attention, et de prendre des precautions (tiens, au fait, les > route-server des IX, a part RPKI de leur cote, je vois pas trop comment les > gerer efficacement en terme de securite). > > Bref, Michel, tu as raison, c'est pas (que) la faute de Verizon. Moi je > suis juste decu que quelque chose qui etait en place chez eux a une epoque, > et qui aurait surement limite la portee de l'incident, ait disparu au cours > du temps sans reel remplacement (et la, ne me dis pas RPKI, c'est le truc > qui me fait penser a ce qu'on attendait/esperer d'IPv6 pour remplacer IPv4). > Le plus drôle c’est que le site de Noction t’explique que leur produit automatise tout, évite les interventions manuelles. Apparement, ils ont pas voulu forcer le respect des bonnes pratiques. Ou DQE l’a désactivé. > Comme je n'ai pas fait mes devoirs sur des boites, qq'un peut m'expliquer > comme marchent ces optimiseurs ? J'ai la flemme non pas de Googler ce > matin, mais de faire le tri pour trouver un article qui ne dise pas que des > aneries marketo-commerciale ;) J’ai pas regardé en détail, mais ça découpe en préfixe en sous-préfixe qui n’existe pas en réalité dans la full-table. Je suppose qu’il se démmerde pour annoncer les routes à ton routeur ave des as-path et next-hop fake pour que ton routeur croit que les routes sont des vraies. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Hello, On Thu, 27 Jun 2019 03:48:41 + Michel Py wrote: > Le blog de CloudFlare qui dit que c'était la faute à Verizon, c'est du > gros bullshit. > https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ > > Désolé de le dire, et sans excuser Verizon qui n'avaient pas les > précautions de base en place, c'est de la récupération politique. C'est > pas Verizon qui a merdé. Même si c'est vrai qu'en tant que T1 ils > devraient avoir filtré le bordel, le principe de la patate chaude et de > la confiance qu'on a quand on accepte une session eBGP avec quelqu'un > d'autre sont toujours la base du fonctionnement de la DFZ. C'est un sujet chaud, mais c'est vrai que ca a merde a plein d'endroits. Le premier, c'est surement l'optimiseur. et j'ai encore du mal a comprendre comment un truc pareil peut se permettre de balancer des prefixes sans gros controle... OK, on va dire que c'est la faute a "fat fingers", mais il y a des limites. Ensuite, evidemment, les configs eBGP des upstreams, en cascade... On peut bien tapper sur Verizon, c'est facile, c'est le plus gros, donc il a : - plus d'impact, donc - plus de responsabilite mais aussi - plus de moyen donc - c'est plus sa faute... ;) Moi je dirai juste qu'il y a ... bcp d'annees, j'etais client de UUNet (oui, le meme AS701, mais la version originale, pas celle qui resulte des fusions), et a l'epoque, t'avais pas le choix pour que tes prefixes passent la session : - IRR a jour, - mail avec le filtre (ip access-list, pas as-path filter) a mettre sur la conf de ta session, - 24H de delai, le temps que ca soit matcher avec les DB, et probablement des max-pfx qui trainaient mais que je n'ai jamais vu ;) Aujourd'hui, on cache la complexite d'Internet et de BGP (oui, BGP, c'est complexe !) dans des boites auto-magiques (si 'magiques' ne vous va pas, proposez des remplacements... j'en ai bien un en tete... ;) et on espere que ca va "juste marcher". Mais rien ne "juste marche", "shit happens" ! Alors OK, BGP, c'est qq chose qu'on etablit avec un partenaire de confiance (normalement, meme si la confiance est "commerciale"), mais ca n'empeche pas de faire attention, et de prendre des precautions (tiens, au fait, les route-server des IX, a part RPKI de leur cote, je vois pas trop comment les gerer efficacement en terme de securite). Bref, Michel, tu as raison, c'est pas (que) la faute de Verizon. Moi je suis juste decu que quelque chose qui etait en place chez eux a une epoque, et qui aurait surement limite la portee de l'incident, ait disparu au cours du temps sans reel remplacement (et la, ne me dis pas RPKI, c'est le truc qui me fait penser a ce qu'on attendait/esperer d'IPv6 pour remplacer IPv4). > Les connards qui annoncent des préfixes plus longs que ceux que les > désignataires des préfixes en question le font, faut les éliminer. Dans > leur AS, ils font ce qu'ils veulent. Annoncer la merde que produit un > "optimiseur" BGP comme Noction aux clients, c'est des coups de pied au > cul qui se perdent. Comme je n'ai pas fait mes devoirs sur des boites, qq'un peut m'expliquer comme marchent ces optimiseurs ? J'ai la flemme non pas de Googler ce matin, mais de faire le tri pour trouver un article qui ne dise pas que des aneries marketo-commerciale ;) > Jérome Fleury, j'ai lu ton blog. Le pire, c'est que tu as changé qui > l'avait écrit pour Tom Strickx. Tu crois qu'on avait pas vu çà venir ? > > C'est carrément craintos. Le lien au-dessus, c'était signé par Jérome > Fleury il y a 24 heures. Je ne suis pas le seul à voir remarqué. C'est > vraiment nul à chier. Pas vu... pas regarde... comme je l'ai ecrit plus haut, le sujet est encore trop chaud en ce moment pour que j'aille chercher des infos chez qq'un qui est directement implique - surtout implique comme "victime". Tu le sais, dans ces cas-la, c'est CYA a tout va, et la charge sur VZN, en ne parlant pas (beaucoup) des autres acteurs, n'est probablement pas anodine. Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Bonjour, Le 27/06/2019 à 05:48, Michel Py a écrit : Jérome Fleury, j'ai lu ton blog. Le pire, c'est que tu as changé qui l'avait écrit pour Tom Strickx. Tu crois qu'on avait pas vu çà venir ? C'est carrément craintos. Le lien au-dessus, c'était signé par Jérome Fleury il y a 24 heures. Je ne suis pas le seul à voir remarqué. C'est vraiment nul à chier. Pas sûr de comprendre ce qui a été "remarqué". L'article, 24 heures plus tôt, signé par Tom Strickx : https://web.archive.org/web/20190626043938/https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ Et le 24, jour de sa publication, déjà signé par Tom Strickx : https://web.archive.org/web/20190624200106/https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
> Le 27 juin 2019 à 05:48, Michel Py a > écrit : > > > Les connards qui annoncent des préfixes plus longs que ceux que les > désignataires des préfixes en question le font, faut les éliminer. > Dans leur AS, ils font ce qu'ils veulent. Annoncer la merde que produit un > "optimiseur" BGP comme Noction aux clients, c'est des coups de pied au cul > qui se perdent. > > Hmmm le client de Verizon et DQE a quand même dû faire une grosse boulette aussi non ? C’est une sacré coïncidence avec une responsabilité triple (et heureusement, sinon ça arriverait beaucoup plus souvent). --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Bon il y a des fois ou être le troll de la liste du FRnOG demande de prendre un risque politique, et j'assume. Le blog de CloudFlare qui dit que c'était la faute à Verizon, c'est du gros bullshit. https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ Désolé de le dire, et sans excuser Verizon qui n'avaient pas les précautions de base en place, c'est de la récupération politique. C'est pas Verizon qui a merdé. Même si c'est vrai qu'en tant que T1 ils devraient avoir filtré le bordel, le principe de la patate chaude et de la confiance qu'on a quand on accepte une session eBGP avec quelqu'un d'autre sont toujours la base du fonctionnement de la DFZ. Les connards qui annoncent des préfixes plus longs que ceux que les désignataires des préfixes en question le font, faut les éliminer. Dans leur AS, ils font ce qu'ils veulent. Annoncer la merde que produit un "optimiseur" BGP comme Noction aux clients, c'est des coups de pied au cul qui se perdent. Jérome Fleury, j'ai lu ton blog. Le pire, c'est que tu as changé qui l'avait écrit pour Tom Strickx. Tu crois qu'on avait pas vu çà venir ? C'est carrément craintos. Le lien au-dessus, c'était signé par Jérome Fleury il y a 24 heures. Je ne suis pas le seul à voir remarqué. C'est vraiment nul à chier. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Hello de mon côté, j'ai des intercos entre OVH et Online, et j'ai été impacté (le trafic a été routé temporairement vers Newyork sans jamais revenir). Quelques clients qui utilisent cloudflare ont été impactés aussi, site down quelques heures. le tout en france donc. seeya Le 25/06/2019 à 08:13, Pierre Emeriaud a écrit : Le mar. 25 juin 2019 à 03:46, Michel Py a écrit : Est-ce que çà à touché la France ? https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ Pas regardé dans le détail de mon coté. Pas eu de bruit concernant un afflux de tickets toutefois. J'espère qu'il n'y a aucun lecteur qui utilise un optimiseur BGP et est assez con pour annoncer les routes plus spécifiques sans no-export. Et pourtant. Sur le site même de Noction dans les success story il y a des abonnés d'ici... Dont on a déjà parlé, ainsi que sur bgpmon.net (à ce propos - si vous avez des success-story a partager sur des alternatives comme rislive ou bgpalerter - feel free). NOCTION. MAKE NO_EXPORT DEFAULT KTHXBYE. "In order to further reduce the likelihood of these problems occurring in the future, we will be adding a feature within Noction IRP to give an option to tag all the more specific prefixes that it generates with the BGP NO_EXPORT community. This will not be enabled by default" cf https://www.noction.com/blog/do_route_optimizers_cause_fake_routes et https://twitter.com/noction/status/1143177562191011840 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
> Pierre-Elliott Bécue a écrit : > La logique de CF se défend. DQE est un small provider, surtout en comparaison > avec > Verizon qui fait juste N fois sa taille. Qu'une entreprise comme DQE ne > puisse pas > se payer des gens/des formations exaustives, c'est pas ouf mais ça passe. Je ne suis pas d'accord. C'est pas parce qu'ils sont plus petits que çà leur donner le droit de bidouiller avec un optimiseur BGP sans prendre les précautions de base et d'emmerder le monde entier. Ca n'excuse pas Verizon de ne pas avoir au moins un max-prefixes avec un AS qui n'annonce qu'un seul préfixe, mais c'est quand même DQE qui a originé la fuite. Opérateur, petit ou pas, faut avoir un minimum de compétences; donner des préfixes bidouillés sans la communauté no-export c'est l'origine du problème. > Pierre Emeriaud a écrit : > bgpmon.net (à ce propos - si vous avez des success-story a partager > sur des alternatives comme rislive ou bgpalerter - feel free). Oui je prends aussi va falloir remplacer bientôt, hélas. > Stephane Bortzmeyer a écrit : > Surtout qu'il n'y a que Verizon qui fait çà. Tous les autres opérateurs > français et étrangers répondent instantanément et réagissent avec promptitude. > (Et documentent publiquement, une fois le problème passé.) :-) Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Le mardi 25 juin 2019 à 01:43:42+, Michel Py a écrit : > Est-ce que çà à touché la France ? > https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ > > J'espère qu'il n'y a aucun lecteur qui utilise un optimiseur BGP et > est assez con pour annoncer les routes plus spécifiques sans > no-export. C'est bien beau d'écrire que c'est la faute à 701 parce > qu'ils auraient du avoir un max-prefix ou IRR ou RPKI (ce qui est > vrai), mais quand même sans le gros gland à DQE qui comprend pas > comment un optimiseur BGP marche çà ne serait pas arrivé. Le métier se > perd. La logique de CF se défend. DQE est un small provider, surtout en comparaison avec Verizon qui fait juste N fois sa taille. Qu'une entreprise comme DQE ne puisse pas se payer des gens/des formations exaustives, c'est pas ouf mais ça passe. Que Verizon n'ait pas des gens de ce niveau de qualité c'est inacceptable. Qu'ils n'aient personne de joignable H24 c'est inacceptable. Qu'ils ne répondent pas 8h après, c'est se moquer du monde. On peut taper aussi sur le petit, mais il ne faut pas oublier le contexte. Et le contexte c'est que Verizon c'est des branques. Et c'est à mon avis plus essentiel à souligner. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
On Tue, 25 Jun 2019 01:43:42 + Michel Py wrote: > Est-ce que çà à touché la France ? > https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ Oui. Je ne peux pas dire dans quelle mesure, et je n'ai malheureusement plus la sortie de MTR, mais pendant l'incident hier, depuis une Freebox, l'un des préfixes Cloudflare était routé via la côte Est des US (pour les paquets ICMP qui arrivaient à revenir à ma box), au lieu d'aller à Paris ou Marseille comme d'habitude. > Bon je suis quand même bien d'accord avec Jérome que 8 heures après > et pas de réponse de chez Verizon c'est craintos mais c'est la > tendance. Ca fait deux qui m'ont fait le coup dernièrement : > t'appelles pour quelque chose comme çà, t'es pas un client direct va > te faire empapaouter. Sans vouloir enfoncer des portes ouvertes, et si je peux me permettre un conseil, pensez à: - renseigner un e-mail et un numéro de téléphone distinct de votre support classique sur votre page PeeringDB. Ça vous permettra de faire la distinction entre un client et un opérateur. - traiter les requêtes reçues par ce canal avec l'importance adéquate. Ça devrait vous éviter de vous retrouver dans la situation de Verizon. -- Étienne Labaume Network Engineer Cloudflare - AS13335 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Le mar. 25 juin 2019 à 03:46, Michel Py a écrit : > > Est-ce que çà à touché la France ? > https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/ Pas regardé dans le détail de mon coté. Pas eu de bruit concernant un afflux de tickets toutefois. > J'espère qu'il n'y a aucun lecteur qui utilise un optimiseur BGP et est assez > con pour annoncer les routes plus spécifiques sans no-export. Et pourtant. Sur le site même de Noction dans les success story il y a des abonnés d'ici... Dont on a déjà parlé, ainsi que sur bgpmon.net (à ce propos - si vous avez des success-story a partager sur des alternatives comme rislive ou bgpalerter - feel free). NOCTION. MAKE NO_EXPORT DEFAULT KTHXBYE. "In order to further reduce the likelihood of these problems occurring in the future, we will be adding a feature within Noction IRP to give an option to tag all the more specific prefixes that it generates with the BGP NO_EXPORT community. This will not be enabled by default" cf https://www.noction.com/blog/do_route_optimizers_cause_fake_routes et https://twitter.com/noction/status/1143177562191011840 --- Liste de diffusion du FRnOG http://www.frnog.org/
