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://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>> 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> > > > -- > Clément Cavadore > > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ <http://www.frnog.org/> --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/