Le protocole BGP et le routage Equal-cost multi-path (ECMP)

Le fait que la bande passante nécessaire augmente de façon constante est une chose certaine dans le monde des réseaux. Ainsi, un lien Gigabit Ethernet qui offrait une bande passante satisfaisante il y a 1 an risque d’être insuffisant aujourd’hui. La solution essentielle donc, consiste à passer à un lien plus rapide, ce qui, dans le monde Ethernet, signifierait un saut de 1 Gbit/s à 10 Gbit/s, une mise à niveau qui peut être bien coûteuse. Mais lorsqu’un routeur Gigabit Ethernet a un deuxième port GE pas utilisé, il est possible d’utiliser deux liens GE en parallèle, et ainsi éviter la mise à niveau 10GE à très court terme.

L’utilisation des liens parallèles afin d’augmenter la bande passante est actuellement une méthode souvent utilisée. Ce mécanisme est souvent appelé equal-cost multipath (ECMP). L’ECMP fonctionne généralement bien, mais il y a cependant quelques mises en garde à prendre en compte. Mais avant d’aborder le problème de l’exécution de BGP sur des liens parallèles, il est important d’examiner comment le trafic est réparti sur ces liens.

La façon la plus simple de le faire est de transmettre le paquet 1 sur le lien A, le paquet 2 sur le lien B, le paquet 3 sur le lien A à nouveau, le paquet 4 sur le lien B, et ainsi de suite. Ici s’agit d’un équilibrage de charge par paquet. Le problème avec ce rééquilibrage apparaît lorsque les paquets 1, 3 et 4 sont des paquets de données de 1500 octets appartenant à la même session TCP, mais que le paquet 2 est un petit paquet TCP ACK. Le paquet 3 doit attendre que le paquet 1 soit transmis, mais le paquet 4 n’a pas à attendre aussi longtemps derrière le paquet 2 qui est beaucoup plus léger. Le paquet 4 fini alors par être transmis avant le paquet 3.

L’équilibrage de charge par paquet entraîne donc une réorganisation. En théorie, ce n’est pas un problème, car TCP mettra simplement en mémoire tampon les paquets réordonnés et livrera les données à l’intérieur de l’application réceptrice dans le bon ordre. Pourtant, la réception de paquets dans un désordre fait penser à TCP qu’il y a eu une perte de paquets: il retransmet donc les paquets et ralentit sa vitesse de transmission. Afin d’éviter de tels problèmes, les routeurs et les commutateurs s’efforcent de s’assurer que tous les paquets appartenant à la même session TCP (ou flux UDP) sont transmis sur le même lien. Cela a évidemment un inconvénient : une seule session TCP ne peut utiliser qu’un seul lien; et par conséquent, ECMP n’est utile que si le trafic consiste en plusieurs sessions TCP.

Les routeurs et les switchs ne sont généralement pas en mesure de suivre les sessions TCP individuelles afin que leurs paquets puissent être transmis sur le même lien. Au lieu de cela, ils examinent quelques champs dans l’en-tête IP/TCP/UDP/ICMP et regroupent les paquets selon le contenu de ces champs. Certains switchs ne peuvent même pas regarder à l’intérieur de l’en-tête IP et par conséquent effectuent un équilibrage de charge basé sur les adresses MAC Ethernet. Cela ne fonctionne pas très bien, car de cette façon, tout le trafic de même type entre deux swichs est transmis sur le même lien.

Une manière plus granulaire d’effectuer l’équilibrage de charge est basée sur une liste à 3 critères: le numéro de protocole dans l’en-tête IP (c’est-à-dire TCP, UDP, ICMP, …) et les adresses IP source et de destination. Cela fonctionne mieux que d’utiliser simplement les adresses MAC pour déterminer quels paquets doivent être transmis sur le même lien. La meilleure façon d’exécuter ECMP est d’utiliser une liste à 5 critères: le numéro de protocole, les adresses IP et les numéros de port source et de destination TCP ou UDP. Les routeurs et les switchs implémentant ECMP calculent une fonction d’hachage sur ces champs, et utilisent ensuite une partie de la valeur de hachage résultante afin de sélectionner le lien sur lequel on doit transmettre le paquet.(Voir RFC 2992). Lorsque les champs de la liste à 5 critères sont les mêmes pour tous les paquets appartenant à la même session, le hachage est le même, et ainsi tous les paquets appartenant à la même session finissent par utiliser le même lien. Cela fonctionne bien, mais en pratique, cela peut encore prendre jusqu’à un millier de sessions TCP avant que tous les liens soient utilisés de manière égale.

Cependant, on est allé trop loin ici. Avant que l’algorithme ECMP puisse distribuer les paquets sur des liens parallèles, il faut d’abord convaincre les protocoles de routage tels que BGP d’utiliser plusieurs liens en parallèle. Et il existe trois manières pour BGP et ECMP de fonctionner ensemble:

1. Regrouper les liens au niveau Ethernet, en utilisant IEEE 802.3ad ou EtherChannel
2. Avec une session BGP sur plusieurs liens utilisant des adresses loopback
3. Avec une session BGP séparée sur chacun des liens parallèles

EtherChannel est un mécanisme propriétaire de Cisco. Depuis les années 1990, il permet d’utiliser plusieurs ports Ethernet comme s’il s’agissait d’un seul port à bande passante plus élevée. En 2000, l’IEEE a standardisé un mécanisme très similaire sous le nom de 802.3ad. 802.3ad va de paire avec le Link Aggregation Control Protocol (LACP), qui négocie le regroupement des ports Ethernet. En renonçant au LACP et en regroupant les ports de manière statique, il est généralement possible de faire fonctionner ensemble différentes implémentations telles que 802.3ad et EtherChannel et d’autres mécanismes de regroupement de liens d’autres fournisseurs.

En ce qui concerne le Layer 3, les ports groupés constituent une interface unique avec une seule adresse IP. Ainsi, BGP peut simplement être configuré comme d’habitude et le trafic sera réparti sur les ports à l’aide de l’algorithme ECMP.

Cependant, il n’est pas toujours possible d’utiliser 802.3ad, EtherChannel ou un protocole similaire ; par exemple parce que les ports ne sont pas des ports Ethernet, ou à cause de limitations sur les ports pouvant être regroupés. Alternativement, on peut configurer chaque port avec son propre sous-réseau IP, mais continuer à exécuter une seule session BGP sur l’ensemble des ports. Cela fonctionne comme suit:

 

Dans cet exemple, les deux interfaces GE ont des sous-réseaux 10.0.1.0/30 et 10.0.2.0/30, respectivement. Le routeur local a également l’adresse IP 192.168.0.1/32 configurée sur son interface loopback. (On doit en effet se rappeler, que sur les routeurs, une interface loopback n’a pas l’adresse 127.0.0.1 pour la communication locale, mais plutôt une adresse “réelle” qui reste accessible car les interfaces peuvent faillir et ensuite redevenir opérationnels. Les adresses loopback sont souvent utilisées pour la gestion, et pour les sessions iBGP).

L’adresse 172.16.31.2 est l’interface loopback du routeur à l’autre extrémité des deux liens Gigabit Ethernet. Les routes statiques acheminent 172.16.31.2 sur les deux ports GE. On peut alors établir une session BGP vers 172.16.31.2. Pour être sûr que les mises à jour BGP utilisent l’adresse loopback de notre côté, on doit configurer update-source loopback0. On a également besoin d’ebgp-multihop 2 car le niveau supplémentaire d’indirection peut faire penser au routeur qu’il y a un routeur supplémentaire sur le chemin. Normalement, ce n’est pas autorisé, mais cela ne posera pas de problème avec avec la commande ebgp-multihop 2.

Avec ces paramètres, la session BGP sera ouverte et les préfixes appris au cours de la session auront comme adresse de saut suivant 172.16.31.2. Cette adresse pointe vers les deux ports GE, donc les paquets seront équilibrés en charge sur les deux ports à l’aide d’ECMP.

La troisième façon d’exécuter BGP sur plusieurs liens est de tout simplement configurer une session BGP sur chaque lien:

 

Dans des circonstances normales, BGP aurait maintenant deux copies de chaque préfixe: l’une apprise du voisin 10.0.1.2 et l’autre du voisin 10.0.2.2, et ensuite essayerait de déterminer la meilleure en les départageant selon des règles prédéfinies (« tie-breaker »).

Cependant, avec la commande maximum-paths 2, le routeur installera les deux copies d’une route dans la table de routage principale, ce qui déclenchera l’ECMP entre les deux routes. En fonction de la version IOS, le nombre de chemins pouvant être configurés peut être limité à 6. Pour que l’équilibrage de charge ait lieu, les attributs de chemin suivants doivent être les mêmes pour les préfixes appris au cours des sessions BGP parallèles (voir la documentation de Cisco):

• weight
• local preference
• AS path length
• origin
• MED
• l’AS voisin ou le chemin complet de l’AS (selon la version IOS)

L’utilisation d’une session BGP séparée pour chacun des liens parallèles utilise plus de mémoire et de cycles CPU ; ce n’est donc pas l’option optimale. Cependant, cette option a un avantage important : contrairement aux deux autres options, celle-ci fonctionne également si les liens se connectent à des routeurs différents de l’autre côté, à condition que les attributs listés ci-dessus soient les mêmes.

Accéder à la version anglaise de cet article – BGP and equal-cost multipath (ECMP)