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://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 <[email protected] >> <mailto:[email protected]>> 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/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
