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/
