Le protocole d’échange BGP de Nerim

Attention il s’agit là d’une documentation technique super intéressante (mais technique) expliquant le fonctionnement du protocole d’échange BGP utilisé par Nerim.

Quelques définitions

Quelques éléments pour comprendre comment fonctionne le routage IP externe (vers ce que l’on appelle Internet) et son implantation au sein de Nerim.

Protocole de routage : Protocole IP (sens général) utilisé entre plusieurs éléments d’un réseau (local ou étendu) afin de s’échanger des routes de type variés pour accéder à des destinations toutes aussi variées
AS (Autonomous System – Système Autonome) : Réseau gérant son routage global en collaboration avec les autres réseaux d’Internet. Quand on parle de « l’inter-réseaux », les réseaux dont il est question sont les AS. Internet est un ensemble d’AS. Chaque AS reçoit un numéro unique sur le réseau afin de l’identifier parmi les autres, c’est son numéro d’AS.
BGP (Border Gateway Protocol – Protocole de Passerelle Extérieure) : Protocole de routage utilisé au plus haut niveau d’Internet, entre les AS donc. Il fonctionne en TCP (sur le port 179), une session devant donc être établie entre deux équipements de routage afin de s’échanger les routes. Les deux membres d’une session BGP sont appelés peers (sens général, voir plus bas pour les sens dérivés). On les appelle aussi voisins BGP (neighbor). Il y a deux sous-protocoles, qui présentent quelques différences de comportement : l’eBGP (external) entre des routeurs d’un AS différent, et l’iBGP (internal) entre les routeurs d’un même AS.
Préfixe : Ensemble de bits précédant des adresses IP, et communs à un groupe d’adresses IP. On le note en décimal, en spécifiant la première adresse qu’il identifie (bits d’adresse tous à 0) suivi de sa taille en nombre de bits. Exemple, le préfixe 192.168.4.0/24 identifie les adresses IP comprises entre 192.168.4.0 et 192.168.4.255. Chaque réseau (AS) doit annoncer ses préfixes (= adresses IP des interfaces qui constituent son réseau) aux autres, via le BGP, afin d’être visible sur Internet.
Peering/Transit : Relation entre deux peers BGP. Un type particulier de peering BGP est ce qu’on appelle le transit, où un AS (« fournisseur ») autorise un autre (« client ») à joindre des AS tiers au travers de son réseau. Le client utilise l’AS du fournisseur en tant qu’AS de transit (par opposition à destination) vers d’autres AS, d’où le terme de transit.
Dans un « peering » (sens strict), les deux AS ne s’échangent que leurs propres préfixes ainsi que ceux de leurs clients (à qui ils fournissent eux-mêmes du transit). Ce type de peering BGP sert à monter des interconnexions directes (sans relation commerciale le plus souvent) entre réseaux.

Configuration du BGP chez Nerim

Numéro d’AS de Nerim : 13193

Le protocole BGP utilise divers attributs associés aux préfixes afin de choisir une route parmi celles possibles vers un préfixe. Nerim n’utilise pas tous les attributs possibles, mais seulement les suivants, listés ici dans l’ordre de choix. Beaucoup d’attributs sont modifiables par les routeurs lorsqu’ils reçoivent les annonces, avant de les ré-annoncer.

TRES IMPORTANT : ces attributs servent à la sélection des routes depuis Nerim vers Internet, ils ne servent donc qu’à manipuler le trafic SORTANT. Pour le trafic ENTRANT, les possibilités de contrôle sont beaucoup plus limitées, et aucune configuration fine n’est possible en pratique.

1 – local-preference

La « local-preference » (localpref) est un nombre associé à un préfixe à l’intérieur d’un AS (il ne se propage pas entre les AS, mais se propage entre les routeurs d’un même AS, via l’iBGP). Une localpref plus élevée est préférée dans le choix de la route.

La localpref est appliquée comme suit aux annonces eBGP entrant dans le réseau de Nerim.

100 = préfixes annoncés via les liens de transit
120 = préfixes de l’AS3215 (France Télécom/Transpac)
200 = préfixes annoncés via les sessions de peering
300 = préfixes des clients BGP

Nerim préfère toujours un peering par rapport à un transit, même si le chemin (nombre de réseaux traversés) via le peering est plus long et donc potentiellement moins fiable. C’est du pur intérêt commercial :-). Il faut cependant noter que la plupart du temps, l’intérêt commercial rejoint l’intérêt technique, et que par le peering, c’est souvent plus court et plus fiable.

2 – Longueur de l’AS-path

La longueur de l’AS-path est liée au nombre de réseaux traversés pour atteindre une destination. par exemple, pour atteindre le réseau IP de Transpac, un AS-path depuis Nerim peut être 13193 -> 3549 -> 5511 -> 3215 (13193 = Nerim, 3549 = Global Crossing, 5511 = OpenTransit, 3215 = Transpac).

Nerim ne manipule pas les AS-path entrants. Les AS-paths sortants (annonces de Nerim vers les peers, au sens large) sont manipulés exceptionnellement en cas de souci réseau ou de maintenance : ils sont rallongés artificiellement (« prepend ») afin de limiter le trafic entrant sur un lien.

3 – MED ou « metric » (Multi-Exit Discriminator)

Le MED (metric) est un numéro attribué à un préfixe, qui se propage entre les AS. Il peut servir à gérer des préférences de liens lorsque deux liaisons sont équivalentes (exemple typique : peering primaire et secondaire, transit nominal et transit de backup vers le même fournisseur). Le MED n’est interprété que si les attributs (1) et (2) sont identiques entre les deux annonces. Un MED plus faible est préféré (oui, c’est l’inverse de la localpref, il faut faire attention de ne pas s’embrouiller).

Chez Nerim, le MED est attribué en fonction de la taille des liens, de son éloignement par rapport aux abonnés ADSL, et de la qualité générale d’un réseau le cas échéant. Les MEDs suivants sont implémentés.

900 = annonces secondaires des classes FT via n’importe quel lien
800 = annonces primaires des classes FT via n’importe quel lien
700 = annonces via Isdnet
600 = annonces via KPNQwest (plus en service)
500 = annonces via Level 3
400 = annonces via Global Crossing
350 = annonces via un peering secondaire
300 = annonces via un peering primaire
200 = annonces d’un client BGP de Nerim

Donc quand les chemins sont tous identiques entre les transits, le trafic sort par Global Crossing par défaut, tout simplement parce que c’est aujourd’hui le plus gros lien de transit de Nerim. De la même manière, le trafic ne sort par Isdnet que si ce dernier dispose de la meilleure route vers une destination (AS-path), FT mis à part.

4 – MED ou « metric » (Multi-Exit Discriminator)

Un routeur BGP marque les routes joignables directement par un lien connecté sur celui-ci comme « external » (externes), et les routes joignables via un autre routeur du même AS (iBGP) en « internal ». Si tous les paramètres sont identiques, BGP préfère une route externe à une route interne. Ce type de choix ne se produit pas souvent chez Nerim.

5 – Adresse IP du voisin BGP

Si tous les attributs sont identiques, BGP finit par choisir la route annoncée par le voisin BGP sont l’adresse IP est la plus petite. Ce n’est certes pas très glorieux comme choix, mais il faut bien choisir, à la fin.

Looking-Glass de Nerim

A partir de toutes ces informations, vous devriez pouvoir interpréter les sorties des vues BGP obtenues via le looking-glass à l’adresse http://morena.noc.nerim.net/nav/lg/

Comme c’est expliqué sur ces pages, Nerim exploite deux types de routeurs BGP. Les routeurs « core » disposent de la table complète (environ 110000 préfixes actuellement) et prennent des décisions de routage. Les routeurs « borders » disposent d’une table partielle seulement, leur fonction BGP est d’apprendre les routes de Nerim aux peers, et d’apprendre les routes des peers aux routeurs « core ».

Les routeurs « core » n’ont pas de route par défaut (0.0.0.0/0). Quand un routeur « core » (holger, svenny, thevenin ou edou) renvoie un « network unreachable » ou qu’un traceroute ne dépasse pas ces routeurs, cela signifie que l’adresse de destination n’est pas dans la table BGP du routeur, les raisons pouvant être variées (réseau de destination en panne, adresses qui ne sont plus ou pas utilisées, dampening BGP – voir plus bas).

svenny#show ip bgp 199.0.233.22
BGP routing table entry for 199.0.233.0/24, version 35117374
Paths: (3 available, best #1)
Advertised to non peer-group peers:
62.4.16.146
3549 1239 1789, (received & used)
62.4.16.36 from 62.4.16.36 (62.4.16.36)
Origin IGP, metric 400, localpref 100, valid, internal, best
Community: 3549:2202 3549:31826
3356 1239 1789
212.73.200.93 from 212.73.200.93 (212.73.192.171)
Origin IGP, metric 500, localpref 100, valid, external¨C94C 3356 1239 1789, (received-only)¨C95C 212.73.200.93 from 212.73.200.93 (212.73.192.171)¨C96C Origin IGP, metric 100000, localpref 100, valid, external

A vous de décoder à titre d’exercice.

Le routage vers l’AS3215 chez Nerim

En attendant que le peering avec FT/Transpac soit monté, Nerim a mis en place une politique de partage du trafic sortant vers FT utilisant tous les liens de transit, sachant que le trafic entrant arrive de toute façon par Level 3 en temps normal.

Le routage est ainsi fait, aujourd’hui :

Route stratégie AS-path correspondant
--------------------------------------------------------
* Par défaut : au plus court (5594_3215_.*)
* 80.8.0.0/15 : Level 3 (3356_5511_3215)
* 80.11.0.0/17 : Level 3 (3356_5511_3215)
* 80.12.0.0/15 : Global Crossing (3549_5511_3215)
* 80.14.0.0/16 : Level 3 (3356_5511_3215)
* 80.15.0.0/16 : Global Crossing (3549_5511_3215)
* 81.80.0.0/16 : Level 3 (3356_5511_3215)
* 193.251.0.0/18 : Level 3 (3356_5511_3215)
* 193.252.0.0/18 : Level 3 (3356_5511_3215)
* 217.128.0.0/16 : Level 3 (3356_5511_3215)

Lorsque le transit avec C&W sera en service, il est fort probable que cette politique évolue vers celle de la « patate chaude » (voir plus bas).

Quelques éléments techniques supplémentaires sur le BGP, utilisés par Nerim

Le dampening BGP

C’est un processus de prévention contre les routes instables. Lorsqu’une route disparaît de la table BGP d’un routeur puis réapparaît, BGP lui attribue une pénalité qui diminue régulièrement, sauf en cas de nouveau bagot. Au dessus d’une certaine pénalité, la route est marquée comme invalide. Elle est toujours dans la table BGP du routeur, mais elle n’intervient plus dans le processus de décision de celui-ci, jusqu’à ce que sa pénalité redescende.

Les communautés BGP

Il s’agit d’un (autre …) numéro attribué à des préfixes suivant le bon vouloir de l’administrateur du routeur. Ils servent à identifier certains préfixes afin d’effectuer des manipulations sur ceux-ci. Par exemple, les annonces de Nerim peuvent être marqués par une communauté d’un fournisseur, lequel interprètera celle-ci afin de supprimer les annonces en certains points de son réseau par exemple. C’est l’une des rares méthodes qui permet de contrôler le trafic entrant de manière fine.

Nerim utilise aussi les communautés en interne. Par exemple, la communauté 13193:6666 est attribuée aux routes apprises par les peerings secondaires, afin de les reconnaître. Elles sont visibles dans un « show ip bgp » via le looking-glass.

La patate chaude (hot-potato en anglais).

Politique de routage qui consiste à délimiter rapidement une équivalence approximative entre les routes, et à sortir le trafic vers l’extérieur dès que c’est possible. Typiquement, lorsqu’un préfixe est annoncé par deux peerings ou deux transits avec le même AS-path, on peut alors appliquer la politique de la « patate chaude ». Actuellement, elle n’est pas implémentée chez Nerim, mais pourrait l’être dès que tous les liens externes de Nerim seront à peu près équivalents, en particulier pour les classes FT.

Merci au directeur technique et co-fondateur de Nerim : Raphaël Bouaziz (dit raphit).