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 <alexandre.bruyel...@m6.fr> > 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 >> é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 tentatives de présentation : >> >> Je cite "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.” >> —> Même sur une plateforme où le trafic est, en volume, majoritairement >> entrant, les communications contemporaines ne sont pas unidirectionnelles. >> Il y a entre autres acquittements, requête-réponse…. ? >> —> D’autre part on peut tenter d’influencer le trafic entrant avec les >> techniques habituelles de preprending, remote prepending via customer >> communities, à minima pour désaturer. Dans ce genre de situations les >> rapports (e.g. camemberts de répartition de trafic pas AS ou préfix distant >> IN/OUT) sont bien utiles - mais un peu de PMACCT et quelques travaux >> d’affichage font aussi l’affaire. >> >> Je cite "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” >> A nouveau tous les optimiseurs ne fonctionnent probablement pas de la même >> manière mais dans notre cas: >> —> On ne génère pas des tests ICMP mais plutôt TCP, UDP-SIP ou UDP-DNS qui >> sont notamment plus fiables. >> —> On utilise pas une IP source par peer/next-hop sinon il faudrait bcp d’IP >> pour pouvoir sonder tous les chemins, notamment sur un IX plein de peers. Et >> c’est aussi une des raisons pour lesquelles on préfère TCP/UDP à ICMP - on >> dispose de plein de ports source pour multiplexer et appliquer du PBR (au >> mieux via Flowspec) afin de contraindre les tests par un chemin ou un autre. >> —> Les tests sont destinés à des IPs (serveurs TCP) qui sont identifiées >> automatiquement dans le trafic de l’AS utilisateur ou par le biais d’autres >> mécanismes que je détaillerais avec plaisir à l'occasion. >> >> Je cite "3- Il y a un IBGP entre la boite diabolique, et les routeurs du >> réseau, qui permet d'influencer le routage:” >> —> Pire encore la boîte peut même faire du CLI en automatique pour (tenter >> d’) influencer le trafic entrant dans certaines circonstances ou pour >> demander aux opérateurs des traitements contre les DDoS (blackhole, >> déclenchement de mitigation,…). Car certains optimiseurs, sur la base des >> statistiques de trafic, ont des fonctions de détection et de qualification >> de DDoS : quelle(s) IP sont attaquées, sur quel(s) protocole(s) et sur >> quel(s) port éventuellement. >> >> Je cite "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.” >> —> Je ne suis pas sur de comprendre à quoi sert de “connaître le contexte” >> - Si c’est anycast, autant aller vers le plus proche au niveau RTD >> - Une transformée de Fourrier ou un simple calcul de variance >> permettent de connaître la fiabilité d’un serveur destination. Un DSL saturé >> montrera une densité spectrale élevée sur les hautes fréquences. Et cela se >> confirme si on utilise deux sondes par préfix BGP distant et qu’on les >> corrèle. On peut alors aisément éliminer des IP de test foireuses. En >> pratique nous avons des résultats très satisfaisants et nous trouvons bcp de >> serveurs de qualité y compris sur des subnets d’ISP. En toute transparence, >> c’est plus compliqué pour certains opérateurs mobiles. >> —> Peu importe le chemin retour puisque l’on compare des chemins sortants >> qui ont le même chemin retour. S’il y a une différence de mesures des >> chemins sortants, c’est bien qu’il existe une différence entre les chemins >> sortants. Et de toute façon il est difficile voire impossible d’influencer >> le chemin retour de manière autoritaire, surtout si votre interlocuteur a >> aussi implémenté des règles qui contraignent le BGP “naturel". Dans le cadre >> du projet LISP-Lab présenté au FRNOG il y a 3 ans, nous avions néanmoins >> fait une proposition pour que des contrôleurs BGP puissent se parler et >> influencer le trafic sortant d’une plateforme en fonction des préférences de >> la plateforme destinataire du trafic : >> https://www.expereo.com/the-routing-preference-protocol/?r=1 >> <https://www.expereo.com/the-routing-preference-protocol/?r=1><https://www.expereo.com/the-routing-preference-protocol/?r=1 >> <https://www.expereo.com/the-routing-preference-protocol/?r=1>> & >> https://github.com/border6/rpp <https://github.com/border6/rpp> >> <https://github.com/border6/rpp <https://github.com/border6/rpp>> >> —> A nouveau on n’utilise pas ICMP >> >> Je cite "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." >> —> Si ces dashboards sont honnêtes, je pense que l’objet de mérite pas >> l’appellation de “shit”. Ces dashboards sont assez utiles en fait et aident >> le client sur de multiples aspects. >> >> Je cite "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 dommage que ce opérateur considère que la boîte est sensée >> comprendre l’architecture du réseau toute seule. Cela demande un peu de >> configuration. Et si le RTD vers un client est plus petit via un >> transitaire, je recommanderais au client de changer d'opérateur…. >> >> Bon appétit, >> François. >> >> >>> On 28 Jun 2019, at 08:21, Clement Cavadore <clem...@cavadore.net >>> <mailto:clem...@cavadore.net> <mailto:clem...@cavadore.net >>> <mailto:clem...@cavadore.net>>> wrote: >>> >>> 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 >>> <https://www.youtube.com/watch?v=Tnod9vtB4xA> >>> <https://www.youtube.com/watch?v=Tnod9vtB4xA >>> <https://www.youtube.com/watch?v=Tnod9vtB4xA>> >>> >>> >>> -- >>> Clément Cavadore >>> >>> >>> >>> >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ <http://www.frnog.org/> <http://www.frnog.org/ >>> <http://www.frnog.org/>> >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ <http://www.frnog.org/> >> > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ <http://www.frnog.org/> --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
