Imaginez que vous louiez des bureaux pour un événement de trois jours. Vous installez à la hâte quelques commutateurs Ethernet et scotchez des câbles au sol pour connecter tout le monde. Malheureusement, Gaston, votre collègue le plus maladroit, trébuche sur un câble à chaque fois qu’il se lève pour aller chercher un café. Des câbles supplémentaires régleraient le problème, mais une boucle se transforme en tempête de diffusion : les paquets Ethernet se multiplient jusqu’à saturation. C’est là qu’intervient le spanning tree protocol : il bloque juste assez de câbles pour ne laisser qu’un arbre sans boucle, et le reconstruit en une seconde à chaque nouvelle bévue de Gaston¹.

Ce contenu est aussi disponible en version texte, avec des démonstrations interactives qui font tourner une véritable implémentation directement dans votre navigateur !

Cette vidéo est une expérimentation². Honnêtement, hormis pour Radia Perlman lisant son poème³, vous devriez plutôt lire l’article original. Il présente le même contenu, mais vous pouvez jouer avec les exemples interactifs, qui en sont la principale contribution. En revanche, si la vidéo vous plaît, dites-le moi en commentaire !

Imaginez que vous louiez des bureaux pour un événement de trois jours. Vous installez à la hâte quelques commutateurs Ethernet et scotchez des câbles au sol pour connecter tout le monde. Malheureusement, Gaston, votre collègue le plus maladroit, trébuche sur un câble à chaque fois qu’il se lève pour aller chercher un café. Vous pourriez ajouter des câbles supplémentaires, mais vous provoqueriez alors une tempête de diffusion : des paquets Ethernet qui tournent en boucle et se multiplient jusqu’à saturation.

C’est là qu’intervient le spanning tree protocol (STP). STP bloque le trafic sur un sous-ensemble des câbles pour ne laisser qu’un arbre sans boucle. Quand Gaston récidive, STP reconstruit l’arbre en une seconde, ce qui laisse à Nono, votre unique renfort technique, le temps de rebrancher le câble¹. Jugez par vous-même : l’illustration ci-dessous fait tourner une véritable implémentation de STP dans votre navigateur !

:demo

A1 @0,0 prio=4096
A2 @0,1
A3 @0,2
A4 @0,3

B1 @1,0 prio=8192
B2 @1,1
B3 @1,2
B4 @1,3

C1 @2,0 prio=8192
C2 @2,1
C3 @2,2
C4 @2,3

A1 -- A2 hazard=0
A2 -- A3 hazard=0
A3 -- A4 hazard=0
B1 -- B2
B2 -- B3
B3 -- B4
C1 -- C2 hazard=0
C2 -- C3 hazard=0
C3 -- C4 hazard=0

A1 -- B1 cost=10
B1 -- C1 cost=10
A4 -- B4 cost=20
B4 -- C4 cost=20

Léo @-0.3,0.7 proto=none icon=👦🏻
Zoé @-0.3,1.3 proto=none icon=👧🏽
Eva @0.3,0.7  proto=none icon=👱🏻‍♀️
Luc @0.3,1.3  proto=none icon=👨🏾
A2 -- Léo hazard=0 A2:edge
A2 -- Zoé hazard=0 A2:edge
A2 -- Eva hazard=0 A2:edge
A2 -- Luc hazard=0 A2:edge

Max @-0.3,1.7 proto=none icon=👨🏽
Ana @-0.3,2.3 proto=none icon=👩🏾
Ida @0.3,1.7  proto=none icon=👵🏾
Léa @0.3,2.3  proto=none icon=👩🏼
A3 -- Max hazard=0 A3:edge
A3 -- Ana hazard=0 A3:edge
A3 -- Ida hazard=0 A3:edge
A3 -- Léa hazard=0 A3:edge

Tom @0.7,0.7 proto=none icon=👦🏼
Zac @0.7,1.3 proto=none icon=👨🏻
Sam @1.3,0.7  proto=none icon=🧑🏽
Noa @1.3,1.3  proto=none icon=👱🏼
B2 -- Tom hazard=0.2 B2:edge
B2 -- Zac hazard=0.2 B2:edge
B2 -- Sam hazard=0.2 B2:edge
B2 -- Noa hazard=0.2 B2:edge

Isa @0.7,1.7 proto=none icon=👩🏻
Cam @0.7,2.3 proto=none icon=🧑🏾‍🦱
Aya @1.3,1.7  proto=none icon=🧕🏽
Guy @1.3,2.3  proto=none icon=👴🏿
B3 -- Isa hazard=0.2 B3:edge
B3 -- Cam hazard=0.2 B3:edge
B3 -- Aya hazard=0.2 B3:edge
B3 -- Guy hazard=0.2 B3:edge

Awa @1.7,0.7 proto=none icon=👩🏿
Ève @1.7,1.3 proto=none icon=👧🏼
Aël @2.3,0.7  proto=none icon=🧓🏿
Ali @2.3,1.3  proto=none icon=🧔🏾
C2 -- Awa hazard=0 C2:edge
C2 -- Ève hazard=0 C2:edge
C2 -- Aël hazard=0 C2:edge
C2 -- Ali hazard=0 C2:edge

Gil @1.7,1.7 proto=none icon=👨🏼‍🦳
Lou @1.7,2.3 proto=none icon=🧑🏿
Lia @2.3,1.7  proto=none icon=👧🏻
Mia @2.3,2.3  proto=none icon=👩🏽‍🦰
C3 -- Gil hazard=0 C3:edge
C3 -- Lou hazard=0 C3:edge
C3 -- Lia hazard=0 C3:edge
C3 -- Mia hazard=0 C3:edge

Les bases

Conçu dans les années 80, le spanning tree protocol a donné naissance à une déclinaison « rapide » (RSTP) et à une variante « compatible VLAN » (MSTP)². Tout ingénieur réseau sensé sait qu’il existe de meilleures solutions, comme BGP EVPN VXLAN. Pourtant, puisque n’importe quel commutateur le parle, le vénérable spanning tree protocol n’a pas dit son dernier mot.

Nous nous concentrons sur RSTP : il a remplacé le protocole d’origine en 2004. Pour éliminer les boucles réseau, RSTP met en œuvre une machine à états complexe. Les temporisateurs, les changements d’état des liens et les trames de contrôle qu’un pont reçoit de ses voisins directs pilotent ses transitions. Ces trames Ethernet sont les Bridge Protocol Data Units (BPDU). Vous pouvez les voir à l’œuvre ci-dessous : appuyez sur le bouton « Start ».

:protocol rstp
:tx-hold 10

A1 @0,1
C11 @1,0 prio=4096 icon=🌳
C12 @1,2 prio=4096 icon=🌳
C21 @2,0 prio=4096 icon=🌳
C22 @2,2 prio=4096 icon=🌳
A2 @3,1

H1 @0,0.2 proto=none icon=💻
H2 @0,1.8 proto=none icon=🖨️
H3 @3,0.2 proto=none icon=📠
H4 @3,1.8 proto=none icon=📺

A1 -- C11
A1 -- C12
A2 -- C21
A2 -- C22
C11 -- C12
C11 -- C21
C11 -- C21
C11 -- C22
C12 -- C21
C12 -- C22
C21 -- C22
A1 -- H1 A1:edge
A1 -- H2 A1:edge
A2 -- H3 A2:edge
A2 -- H4 A2:edge

Au bout de quelques instants, la topologie converge vers un arbre : depuis la racine C11, il existe un chemin vers chaque pont³ et aucune boucle. En haut à droite, l’interface affiche une icône d’arbre 🌳 suivie du temps qu’il a fallu pour atteindre cet état. Coupez un lien et observez comment le protocole trouve en moins d’une seconde un autre chemin pour joindre C12. Vous pouvez arrêter la simulation, l’avancer pas à pas, la réinitialiser ou la ralentir avec le mode « escargot » 🐌. Ne vous inquiétez pas de toutes les informations affichées : je les explique plus loin.

Tous les exemples s’exécutent dans votre navigateur grâce à MSTPD, une implémentation libre de RSTP⁴ fonctionnant en espace utilisateur⁵.

Interlude historique

Radia Perlman, intronisée à l’Internet Hall of Fame en 2014, a résumé dans ce poème l’ancêtre de STP qu’elle a inventé chez DEC. Il a été repris plus tard dans un brevet américain :

I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial property
Is loop-free connectivity.
A tree which must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.

― Radia Perlman, Algorhyme.

Élection de la racine

Pour construire un arbre, RSTP commence par élire comme pont racine celui qui a l’identifiant de pont le plus faible. Cet identifiant combine la priorité et l’adresse MAC : 8192.6e:2b:10:a0:5f:29.

Dans l’exemple ci-dessous, S1 et S2 ont des priorités de 4 096 et 8 192 : S1 devient racine. S4 a une priorité de 12 288, tandis que S3 conserve la priorité par défaut de 32 768⁶ : S4 devient racine. S5 et S6 n’ont pas de priorité particulière : l’adresse MAC la plus faible l’emporte et S5 devient racine.

:protocol rstp

S1 @0,0 prio=4096
S2 @0,1 prio=8192
S1 -- S2

S3 @1,0
S4 @1,1 prio=12288
S3 -- S4

S5 @2,0
S6 @2,1
S5 -- S6

Au départ, chaque pont s’annonce comme racine⁷ :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    Root Identifier: 8192.02:00:00:01:00:01
    Bridge Identifier: 8192.02:00:00:01:00:01

Dès qu’un pont reçoit une BPDU annonçant une meilleure racine, il propage cette nouvelle information à ses voisins.

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    Root Identifier: 4096.02:00:00:00:00:00
    Bridge Identifier: 8192.02:00:00:00:00:01

Attribution des rôles aux ports

La deuxième étape consiste à attribuer un rôle à chaque port. RSTP définit cinq rôles, chacun représenté par une lettre :

• racine (R, root),
• désigné (D, designated),
• alternatif (A, alternate),
• désactivé (X, disabled),
• de secours (B, backup)⁸.

Chaque pont qui n’est pas racine choisit comme port racine celui dont le chemin vers la racine a le coût le plus faible. Sauf configuration explicite, chaque pont déduit le coût d’un lien à partir de son débit : 20 000 pour 1 Gbit/s. En cas d’égalité, l’identifiant de port le plus faible l’emporte.

Chacun des ports restants devient un port désigné si la BPDU qu’il émet est « meilleure » que celle qu’il reçoit. Sinon, il devient un port alternatif. Plus tard, si le port racine tombe, le « meilleur » port alternatif devient le port racine. Les critères pour choisir la meilleure BPDU sont :

1. l’identifiant de pont racine le plus faible,
2. le coût cumulé jusqu’à la racine le plus faible,
3. l’identifiant de pont le plus faible,
4. l’identifiant de port le plus faible.

:protocol rstp

S1 @1,0  prio=4096 icon=🌳
S2 @0,1
S3 @2,1

S1 -- S2
S1 -- S3
S1 -- S3
S2 -- S3

Dans l’exemple ci-dessus, après convergence, S1 est la racine car sa priorité est de 4 096, alors que les autres ponts ont une priorité de 32 768. Tous ses ports sont des ports désignés puisque le coût cumulé jusqu’à la racine est nul.

Le port de S2 face à S1 devient un port racine car il présente le coût cumulé le plus faible vers la racine : 20 000 contre 40 000. S3 possède deux ports face à S1 et celui dont l’identifiant de port est le plus faible devient le port racine : 0x8000 contre 0x8001. L’autre candidat est un port alternatif car le port distant sur ce lien émet une meilleure BPDU, avec un coût cumulé nul. Sur le segment entre S2 et S3, c’est le port de S2 qui l’emporte : les deux ponts ont le même coût cumulé jusqu’à la racine (20 000), mais l’identifiant de pont de S2 est plus petit : 32768.02:00:00:00:00:01 contre 32768.02:00:00:00:00:02.

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 20000
    Bridge Identifier: 32768.02:00:00:00:00:01
    Port identifier: 0x8002

Si vous coupez le lien actif entre S1 et S3, S3 promeut le « meilleur » port alternatif en port racine. Si vous désactivez aussi le second lien, S3 retient le port alternatif restant comme port racine. En revanche, si vous désactivez le lien entre S1 et S2, S2 doit travailler un peu plus pour élire un nouveau port racine, car il ne dispose d’aucun port alternatif.

Sauf événement particulier, les ports désignés émettent une BPDU toutes les 2 secondes⁹. Si un pont ne reçoit plus de BPDU de son voisin pendant 3 périodes « hello » consécutives, il le considère comme mort et efface les informations associées au port.

Transition d’état des ports

Chaque port se trouve dans l’un des trois états suivants. Le schéma représente chaque état par une couleur de fond :

• rejet (discarding, rouge),
• apprentissage (learning, jaune),
• transmission (forwarding, vert).

Un port racine passe automatiquement à l’état de transmission. Un port alternatif reste à l’état de rejet. Un port désigné dispose de deux moyens pour passer de l’état de rejet à l’état de transmission :

• Si le port est un port d’extrémité (edge port), soit par configuration, soit parce que l’équipement distant ne parle aucune variante de STP, le pont suppose que cet équipement ne participe pas au protocole et ne peut donc pas créer de boucle. Dans ce cas, le port désigné passe immédiatement à l’état de transmission.
• Sinon, il envoie une proposition à son voisin en aval. Si le pont distant estime que la BPDU reçue est « meilleure » que toutes celles mémorisées pour ses autres ports, il élit le port de réception comme port racine et démarre le processus de synchronisation : pour éviter une boucle, il fait passer à l’état de rejet tous les ports désignés qui ne sont ni des ports d’extrémité ni déjà synchronisés. Il renvoie ensuite un accord. À la réception de cet accord, le port désigné du pair passe à l’état de transmission¹⁰.

:protocol rstp

S1 @1,0 prio=4096 icon=🌳
S2 @1,1
S3 @0,2
S4 @2,2
S5 @0,3 prio=8192 icon=🪾
S6 @2,3
H1 @0,1.2   proto=none icon=🖨️
H2 @2,1.2   proto=none icon=📠
H3 @2.5,1.3 proto=none icon=📺
H4 @2.5,2.3 proto=none icon=💻

S1 -- S2
S2 -- S3
S2 -- S4
S3 -- S5
S4 -- S6
S4 -- S3
S5 -- S6

S3 -- H1 S3:edge
S4 -- H2 S4:edge
S4 -- H3 S4:edge
S6 -- H4 S6:edge

Dans la topologie ci-dessus, H1, H2, H3 et H4 sont des équipements terminaux qui ne participent pas au protocole. Nous configurons les ports auxquels ils sont raccordés comme des ports d’extrémité : ces ports passent donc immédiatement à l’état de transmission.

Utilisez le bouton « step » pour faire avancer la simulation. L’horloge passe à 1 seconde. Avancez encore d’un cran : S1 et S2 s’envoient mutuellement une proposition. Voici celle de S2 :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x4e, Agreement, Port Role: Designated, Proposal
        0... .... = Topology Change Acknowledgment: No
        .1.. .... = Agreement: Yes
        ..0. .... = Forwarding: No
        ...0 .... = Learning: No
        .... 11.. = Port Role: Designated (3)
        .... ..1. = Proposal: Yes
        .... ...0 = Topology Change: No
    Root Identifier: 32768.02:00:00:00:00:01
    Root Path Cost: 0
    Bridge Identifier: 32768.02:00:00:00:00:01
    Port identifier: 0x8001

S1 ignore cette proposition : son propre identifiant de racine est plus faible. Quand S2 reçoit une proposition similaire de S1, il accepte S1 comme racine. Il élit également le port vers S1 comme port racine et démarre le processus de synchronisation. Ses deux ports désignés sont déjà à l’état de rejet : rien ne change de ce côté. Avancez encore d’un cran : S2 envoie deux BPDU à S1. Dans l’une d’elles, le bit d’accord vaut 1 et le bit de proposition vaut 0. Elle montre aussi que S2 a accepté S1 comme racine et que son port racine est désormais à l’état de transmission. À la réception de cette BPDU, S1 fait passer son propre port désigné à l’état de transmission. À partir de cet instant, le lien entre S1 et S2 achemine le trafic utilisateur.

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x79, Agreement, Forwarding, Learning, Port Role: Root, Topology Change
        0... .... = Topology Change Acknowledgment: No
        .1.. .... = Agreement: Yes
        ..1. .... = Forwarding: Yes
        ...1 .... = Learning: Yes
        .... 10.. = Port Role: Root (2)
        .... ..0. = Proposal: No
        .... ...1 = Topology Change: Yes
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 20000
    Bridge Identifier: 32768.02:00:00:00:00:01
    Port identifier: 0x8001

Voyons maintenant ce qui est arrivé à S5. Réinitialisez la simulation et avancez de deux pas. S5 échange des BPDU avec S3 et S6. Comme S5 possède un identifiant de racine plus faible que S3 et S6, il reste la racine, tandis que S3 et S6 acceptent la proposition et élisent leurs ports racines. S3 et S6 démarrent le processus de synchronisation. Le port de S6 vers H4 reste actif car il s’agit d’un port d’extrémité. Avancez d’un cran : S3 et S6 renvoient tous deux un accord à S5, qui fait passer ses deux ports désignés à l’état de transmission. Pourtant, le lien entre S5 et S3 continue de rejeter le trafic utilisateur ! Si vous regardez attentivement, le port de S3 vers S5 est maintenant un port désigné, et non un port racine. Lors de la même étape, S3 reçoit aussi une meilleure BPDU de S2, avec S1 comme racine. Il élit son port vers S2 comme port racine et rétrograde le port vers S5 en port désigné, qui reste à l’état de rejet.

À l’étape suivante, les choses se corsent un peu. S3 envoie une proposition à S5¹¹ :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x4f, Agreement, Port Role: Designated, Proposal, Topology Change
        0... .... = Topology Change Acknowledgment: No
        .1.. .... = Agreement: Yes
        ..0. .... = Forwarding: No
        ...0 .... = Learning: No
        .... 11.. = Port Role: Designated (3)
        .... ..1. = Proposal: Yes
        .... ...1 = Topology Change: Yes
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 40000
    Bridge Identifier: 32768.02:00:00:00:00:02
    Port identifier: 0x8002

S5 élit S1 comme racine et le port vers S3 comme port racine. Il démarre son processus de synchronisation, mais le port désigné vers S6 ne passe pas à l’état de rejet. Pourquoi ? Ce port reste un port désigné et son voisin S6 a déjà envoyé un accord sur ce lien : il conserve donc son statut de port synchronisé.

Revenons maintenant un pas en arrière pour observer ce qui arrive à S6. À cet instant, S6 croit que S5 est la racine. Avancez d’un cran : S4 envoie une nouvelle proposition à S6. S6 l’accepte, élit S1 comme racine et le port vers S4 comme port racine. Le rôle du port face à S5 change : de port racine, il devient port désigné. Comme son pair continue d’annoncer une BPDU inférieure sur le lien, ce port devient contesté (disputed) et passe à l’état de rejet. Le port racine passe à l’état de transmission et le lien devient immédiatement opérationnel, car le port désigné de S4 est déjà à l’état de transmission. Si nous avançons d’un cran, S5 et S6 échangent deux BPDU. Celle de S5 est meilleure grâce à son identifiant de pont plus faible. Le port de S5 reste un port désigné, tandis que S6 rétrograde le sien en port alternatif.

Reprenons une dernière fois depuis le début : coupez le lien entre S1 et S2, laissez tourner la simulation jusqu’à ce que la topologie soit stable, arrêtez-la, puis rétablissez le lien entre S1 et S2. Lors du premier pas, S1 et S2 échangent des propositions. S2 élit S1 comme racine à la place de S5, et le port vers S1 comme port racine. Il rétrograde son ancien port racine en port désigné et le place à l’état de rejet. L’autre port désigné reste synchronisé et conserve son état de transmission. À l’étape suivante, S2 envoie un accord à S1 et le lien entre eux commence à acheminer le trafic utilisateur. S2 envoie également une proposition à S3, mais pas à S4 : il lui envoie une BPDU ordinaire. S4 élit malgré tout S1 comme racine et le port vers S2 comme port racine. Il rétrograde son ancien port racine, celui vers S3, en port désigné, qui passe à l’état de rejet à cause du changement de port racine. L’autre port alternatif, celui vers S6, devient lui aussi un port désigné et reste à l’état de rejet. Le nouveau port racine passe à l’état de transmission. À l’étape suivante, le port de S4 vers S3 se stabilise comme port alternatif après avoir reçu une « meilleure » BPDU de S3.

RSTP est une gigantesque machine à états découpée en machines plus petites : Bridge Detection, Port Information, Port Protocol Migration, Port Role Selection, Port Role Transitions, Port Receive, Port State Transitions, Port Timers, Port Transmit et Topology Change. Certaines s’appliquent à l’ensemble du pont, d’autres à chaque port. Chaque pont en exécute une instance. Le temps, les changements d’état opérationnel des ports et les BPDU reçues des autres instances en pilotent les transitions. Ce fonctionnement par événements rend RSTP plus efficace, mais aussi plus difficile à appréhender.

Notification de changement de topologie

Un pont maintient automatiquement une table d’adresses MAC : il associe chaque adresse MAC source au port qui l’a reçue en dernier. Pour commuter une trame Ethernet, il consulte cette table afin de choisir le bon port¹². Quand un lien tombe, un frigo connecté joignable par un port peut le devenir par un autre. Les ponts concernés doivent alors purger les adresses MAC apprises : elles ne sont peut-être plus valables.

Pour cela, RSTP met en œuvre des notifications de changement de topologie à l’aide d’un mécanisme d’inondation. Lorsqu’un port qui n’est pas un port d’extrémité passe à l’état de transmission, un pont génère des BPDU dont le bit topology change (TC) est activé. Il les envoie à tous ses ports désignés, à l’exception des ports d’extrémité, ainsi qu’à son port racine. Il purge également la table d’adresses MAC sur ces ports. Quand un pont reçoit une telle BPDU, il propage la notification sur ses ports désignés hors ports d’extrémité et sur son port racine, sauf celui par lequel elle est arrivée. Il purge lui aussi la table d’adresses MAC sur ces ports. Dans les exemples, les BPDU dont le bit TC vaut 1 sont entourées d’un cercle rouge.

:protocol rstp

S1 @1,0 prio=4096 icon=🌳
S2 @0,1
S3 @1,1
S4 @2,1
S5 @1,2
LPT @0.1,2 proto=none icon=🖨️

S1 -- S2
S1 -- S3
S1 -- S4
S2 -- S3
S2 -- S5
S4 -- S5
S5 -- LPT S5:edge

Lancez la simulation et attendez quelques secondes que la topologie se stabilise. Arrêtez la simulation et désactivez le lien entre S2 et S5. S5 élit le port face à S4 comme port racine, lequel passe immédiatement à l’état de transmission. Avancez d’un cran : S5 émet une BPDU avec le bit TC à 1 :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x79, Agreement, Forwarding, Learning, Port Role: Root, Topology Change
        0... .... = Topology Change Acknowledgment: No
        .1.. .... = Agreement: Yes
        ..1. .... = Forwarding: Yes
        ...1 .... = Learning: Yes
        .... 10.. = Port Role: Root (2)
        .... ..0. = Proposal: No
        .... ...1 = Topology Change: Yes
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 40000
    Bridge Identifier: 32768.02:00:00:00:00:04
    Port identifier: 0x8002

S4 reçoit cette BPDU. Il purge la table d’adresses MAC sur le port face à S1 : LPT était auparavant joignable par ce port, mais il l’est désormais par S5. Avancez d’un cran : S4 envoie à S1 une BPDU avec le bit TC à 1. À la réception de cette BPDU, S1 purge la table d’adresses MAC sur les ports face à S2 et S3. Avancez d’un cran : S1 envoie une notification à S2 et à S3. Avancez encore d’un cran : S2 envoie une notification à S3, tandis que S3 ne fait rien car son port vers S2 est un port alternatif. S3 ne purge aucune table d’adresses MAC : LPT reste joignable par son port vers S1.

Si vous avancez encore un peu, vous verrez que certaines BPDU périodiques conservent le bit TC à 1. Chaque port dispose d’un temporisateur égal au temporisateur « hello » plus une seconde¹³. Ce temporisateur démarre quand le port émet une notification. Jusqu’à son expiration, le port positionne le bit TC à 1 dans toutes les BPDU qu’il envoie. Vous pouvez aussi voir certaines BPDU périodiques sans le bit TC : elles proviennent d’un port qui n’a fait que recevoir une notification et qui n’a donc pas armé son temporisateur.

Sécurité

RSTP est sensible aux erreurs de configuration et peu résistant face aux acteurs malveillants. Un pont qui ne parle pas RSTP peut créer une boucle. Une personne malveillante peut s’insérer dans la topologie pour perturber le service, espionner le trafic ou le modifier.

Pour limiter ces problèmes, vous devez identifier les ports d’extrémité. Un port d’extrémité est raccordé à un équipement tel qu’un PC ou une imprimante. Ces équipements ne génèrent pas de BPDU et ne peuvent pas créer de boucle. RSTP propose deux options liées :

• Quand elle est vraie, AdminEdge initialise un port comme port d’extrémité.
• Quand elle est vraie, AutoEdge permet à un port de devenir un port d’extrémité s’il ne reçoit aucune BPDU pendant 3 secondes. Cette option est activée par défaut.

Si un port d’extrémité reçoit une BPDU, quelles que soient les valeurs de ces deux options, il redevient un port ordinaire.

R0 @1.5,1.5 prio=8192

# AutoEdge=true, AdminEdge=false, bridge
S1 @3,1.58
R0 -- S1

# AutoEdge=true, AdminEdge=false, end device
H1 @2.84,2.18 icon=🖨️ proto=none
R0 -- H1

# AutoEdge=true, AdminEdge=true, bridge
S2 @2.18,2.84
R0 -- S2 R0:edge

# AutoEdge=true, AdminEdge=true, end device
H2 @1.58,3 icon=💻 proto=none
R0 -- H2 R0:edge

# AutoEdge=false, AdminEdge=true, bridge
S3 @0.68,2.76
R0 -- S3 R0:edge R0:no-auto-edge

# AutoEdge=false, AdminEdge=true, end device
H3 @0.24,2.32 icon=📠 proto=none
R0 -- H3 R0:edge R0:no-auto-edge

# AutoEdge=false, AdminEdge=false, bridge
S4 @0,1.42
R0 -- S4 R0:no-auto-edge

# AutoEdge=false, AdminEdge=false, end device
H4 @0.16,0.82 icon=📺 proto=none
R0 -- H4 R0:no-auto-edge

# Network port, bridge
S5 @0.82,0.16
R0 -- S5 R0:network S5:network

# Network port, end device
H5 @1.42,0 icon=☕ proto=none
R0 -- H5 R0:network

# AdminEdge=true, bpdu-guard=true, bridge
S6 @2.32,0.24
R0 -- S6 R0:bpdu-guard R0:edge

# AdminEdge=true, bpdu-guard=true, end device
H6 @2.76,0.68 icon=💡 proto=none
R0 -- H6 R0:bpdu-guard R0:edge

Dans la topologie ci-dessus, S1, S2, S3, S4, S5 et S6 se comportent comme des ponts, tandis que H1, H2, H3, H4, H5 et H6 se comportent comme des équipements terminaux :

• S1 et H1 sont sur un port sans configuration : AutoEdge est vraie, AdminEdge est fausse,
• S2 et H2 sont sur un port où AdminEdge est vraie,
• S3 et H3 sont sur un port où AutoEdge est fausse et AdminEdge est vraie,
• S4 et H4 sont sur un port où AutoEdge est fausse.

Si vous lancez la simulation et attendez une vingtaine de secondes, les liens vers S1, S2, S3, S4, H1, H2, H3 et H4 finissent par acheminer le trafic utilisateur : aucune de ces options n’a d’importance.

Mais qu’en est-il des deux dernières paires ? S5 et H5 sont raccordés à un port de type network. Un tel port active une fonctionnalité propriétaire : le bridge assurance. Le port émet des BPDU quel que soit son rôle. S’il n’en reçoit aucune pendant 3 périodes « hello » consécutives, il passe à l’état de rejet. Sur le lien entre R0 et S5, vous pouvez voir des BPDU circuler dans les deux sens, contrairement aux autres liens, où seuls les ports désignés en émettent.

S6 et H6 sont raccordés à un port où AdminEdge est vraie et où le BPDU guard est activé. Il s’agit d’une autre fonctionnalité propriétaire, qui désactive un port s’il reçoit une BPDU.

En résumé, si vous attendez d’un port qu’il soit un port d’extrémité, positionnez AdminEdge à vrai et activez le BPDU guard. Sinon, déclarez-le comme port network.

Pourquoi RSTP aujourd’hui ?

Un cas d’usage solide pour RSTP aujourd’hui est le réseau d’administration hors bande (OOB) d’un centre de données, où quelques secondes d’indisponibilité sont tolérables. La configuration est minimale et vous pouvez utiliser des commutateurs bon marché, comme un Cisco 2960X¹⁴. Deux commutateurs jouent le rôle de ponts racines et plusieurs boucles raccordent les commutateurs présents dans chaque baie. Cette conception simple survit à une panne sur chaque boucle¹⁵.

:protocol rstp
:tx-hold 10

# Root bridges
R1 @0,1 prio=0
R2 @0,2 prio=4096
R1 -- R2 cost=200 R1:network R2:network
R1 -- R2 cost=200 R1:network R2:network

# First loop
C1  @1,0 icon=🗄️
C4  @2,0 icon=🗄️
C7  @3,0 icon=🗄️
C10 @4,0 icon=🗄️
C12 @5,0 icon=🗄️
C13 @5,3 icon=🗄️
C15 @4,3 icon=🗄️
C18 @3,3 icon=🗄️
C21 @2,3 icon=🗄️
C24 @1,3 icon=🗄️
R1  -- C1  R1:network C1:network
C1  -- C4  C1:network C4:network
C4  -- C7  C4:network C7:network
C7  -- C10 C7:network C10:network
C10 -- C12 C10:network C12:network
C12 -- C13 C12:network C13:network
C13 -- C15 C13:network C15:network
C15 -- C18 C15:network C18:network
C18 -- C21 C18:network C21:network
C21 -- C24 C21:network C24:network
C24 -- R2  C24:network R2:network

# Second loop
C2  @1,0.5 icon=🗄️
C5  @2,0.5 icon=🗄️
C8  @3,0.5 icon=🗄️
C11 @4,0.5 icon=🗄️
C14 @4,2.5 icon=🗄️
C17 @3,2.5 icon=🗄️
C20 @2,2.5 icon=🗄️
C23 @1,2.5 icon=🗄️
R1  -- C2  R1:network C2:network
C2  -- C5  C2:network C5:network
C5  -- C8  C5:network C8:network
C8  -- C11 C8:network C11:network
C11 -- C14 C11:network C14:network
C14 -- C17 C14:network C17:network
C17 -- C20 C17:network C20:network
C20 -- C23 C20:network C23:network
C23 -- R2  C23:network R2:network

# Third loop
C3  @1,1 icon=🗄️
C6  @2,1 icon=🗄️
C9  @3,1 icon=🗄️
C16 @3,2 icon=🗄️
C19 @2,2 icon=🗄️
C22 @1,2 icon=🗄️
R1  -- C3  R1:network C3:network
C3  -- C6  C3:network C6:network
C6  -- C9  C6:network C9:network
C9  -- C16 C9:network C16:network
C16 -- C19 C16:network C19:network
C19 -- C22 C19:network C22:network
C22 -- R2  C22:network R2:network

Cette topologie converge en environ 6 secondes. Chaque boucle doit rester petite (environ 16 ponts) pour réduire la probabilité d’une double panne et éviter de partager trop de bande passante. Cette conception peut évoluer un peu sans devenir trop complexe : un VLAN par boucle ou un domaine de pont par boucle.

Quelle taille pour un réseau ?

L’âge maximal, dont la valeur par défaut est 20, détermine la distance maximale entre un pont et la racine. La topologie ci-dessous est trop grande : les BPDU issues de R1 ne parviennent pas au-delà de S20¹⁶.

:protocol rstp
:tx-hold 10
:max-age 20

R1 @0,0 prio=4096 icon=🌳
R2 @0,5 prio=4096 icon=🪾

S1  @1,0
S2  @2,0
S3  @3,0
S4  @4,0
S5  @5,0
S6  @6,0

S7  @6,1
S8  @5,1
S9  @4,1
S10 @3,1
S11 @2,1
S12 @1,1

S13 @1,2
S14 @2,2
S15 @3,2
S16 @4,2
S17 @5,2
S18 @6,2

S19 @6,3
S20 @5,3
S21 @4,3
S22 @3,3
S23 @2,3
S24 @1,3

S25 @1,4
S26 @2,4
S27 @3,4
S28 @4,4
S29 @5,4
S30 @6,4

S31 @6,5
S32 @5,5
S33 @4,5
S34 @3,5
S35 @2,5
S36 @1,5

R1  -- S1
S1  -- S2
S2  -- S3
S3  -- S4
S4  -- S5
S5  -- S6
S6  -- S7
S7  -- S8
S8  -- S9
S9  -- S10
S10 -- S11
S11 -- S12
S12 -- S13
S13 -- S14
S14 -- S15
S15 -- S16
S16 -- S17
S17 -- S18
S18 -- S19
S19 -- S20
S20 -- S21
S21 -- S22
S22 -- S23
S23 -- S24
S24 -- S25
S25 -- S26
S26 -- S27
S27 -- S28
S28 -- S29
S29 -- S30
S30 -- S31
S31 -- S32
S32 -- S33
S33 -- S34
S34 -- S35
S35 -- S36
S36 -- R2
R1  -- R2 cost=200 down

Une fois la topologie stabilisée, une partie du réseau considère R1 comme racine et l’autre partie vote pour R2. À la frontière, S20 tente de démarrer une synchronisation avec S21 pour faire passer son port désigné à l’état de transmission. Sa BPDU ressemble à ceci :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x4e, Agreement, Port Role: Designated, Proposal
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 400000
    Bridge Identifier: 32768.02:00:00:00:00:15
    Port identifier: 0x8002
    Message Age: 20
    Max Age: 20

S21 la rejette car l’âge du message est égal à l’âge maximal. De son côté, la BPDU que S21 envoie à S20 ressemble à ceci :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x7c, Agreement, Forwarding, Learning, Port Role: Designated
    Root Identifier: 4096.02:00:00:00:00:01
    Root Path Cost: 320000
    Bridge Identifier: 32768.02:00:00:00:00:16
    Port identifier: 0x8001
    Message Age: 16
    Max Age: 20

Cela ne suffit pas à changer le port racine de S20, car S20 dispose d’un identifiant de racine plus faible : 4096.02:00:00:00:00:00 contre 4096.02:00:00:00:00:01.

Réparer le lien entre R1 et R2 résout le problème. L’âge de message maximal transporté par un paquet est désormais de 18, en dessous de l’âge maximal configuré. Mais cela ne fonctionne que jusqu’à la rupture d’un autre lien. Une correction possible consiste à porter l’âge maximal à 40¹⁷.

RSTP est-il rapide ?

RSTP converge en général en quelques secondes au démarrage. Il répare souvent un arbre en moins d’une seconde. Même la topologie à 38 ponts converge en moins de 10 secondes¹⁸. Certaines topologies mettent un peu plus de temps à se rétablir quand la racine devient indisponible¹⁹.

:protocol rstp

R0 @1,0 prio=0
S1 @1,1 prio=4096
S2 @0,2 prio=8192
S3 @2,2

R0 -- S1
S1 -- S2
S2 -- S3
S3 -- S1

Dans la topologie ci-dessus, lancez la simulation, attendez la convergence, arrêtez-la, puis coupez le lien entre R0 et S1. La topologie est déjà optimale, mais RSTP peine à converger de nouveau.

D’abord, S1 perd son port racine. Il n’a plus aucune information sur R0 et se proclame racine. Il conserve ses ports vers S2 et S3 comme ports désignés à l’état de transmission. Avancez d’un cran : il envoie une BPDU à S2 et à S3 pour les informer du changement de racine. À sa réception, S2 accepte S1 comme racine, car il ne connaît pas de meilleure racine sur un autre port. Il élit le port vers S1 comme port racine. L’autre port reste un port désigné. Aucun des deux ports ne change d’état.

À la réception de la BPDU de S1, S3 se comporte différemment : il connaît R0 comme une meilleure racine que S1 grâce à son port alternatif vers S2. Il promeut ce port en port racine et rétrograde le port vers S1 en port désigné, ce qui nécessite un nouvel accord. Avancez d’un cran : S3 envoie une proposition à S1 avec R0 comme racine. S1 élit R0 comme racine et promeut son port vers S3 en port racine.

Lors de la même séquence, S3 reçoit aussi une BPDU de S2 affirmant que S1 est la racine. S3 n’a donc plus aucun port annonçant R0 comme racine : il élit S1 comme racine et son port vers S2 comme port racine. Avancez d’un cran : sa BPDU suivante vers S1 contient cette information et S1 s’élit de nouveau racine. Mais lors de la même vague, S1 envoie une proposition à S2 avec R0 comme racine. Alors que S1 et S3 s’accordent sur le fait que S1 est la racine, S2 croit désormais que c’est R0 ! À son tour, S2 convainc de nouveau S3 que R0 est la racine, S3 convainc S1, S1 convainc S2 et S2 convainc S3.

Cela pourrait durer indéfiniment, mais ce n’est pas le cas. Les BPDU affirmant « R0 est la racine » finissent par se périmer lorsque l’âge du message dépasse l’âge maximal. Dans l’exemple ci-dessus, à la onzième seconde, S2 envoie une BPDU à S3 avec R0 comme racine, mais S3 la jette car elle a atteint l’âge maximal. Avec un peu de chance, la convergence peut aussi être plus rapide si un port cesse de transmettre des BPDU après avoir atteint le nombre maximal autorisé par seconde : il s’agit du transmit hold count, dont la valeur par défaut est 6.

À propos de MSTP

MSTP est la version « compatible VLAN » de RSTP : il exécute plusieurs instances de RSTP et permet d’associer chaque VLAN à une instance donnée. Par exemple, vous pouvez rattacher les VLAN 100 à 200 à une première instance et les VLAN 300 à 400 à une seconde. Les VLAN restants sont rattachés à une instance spéciale appelée Internal Spanning Tree (IST). MSTP apporte sa propre complexité, mais l’idée est de disposer de plusieurs topologies logiques indépendantes. Pour creuser le sujet, jetez un œil à « MSTP Tutorial Part I: Inside a Region ».

À propos des exemples interactifs

Les exemples interactifs exécutent MSTPD directement dans votre navigateur, compilé en WebAssembly avec emscripten. Une API C remplace le code qui dialogue avec le noyau Linux : elle gère les ponts et les ports, exporte l’état en JSON et fait avancer le temps de manière déterministe. Une surcouche JavaScript la rend plus agréable à utiliser :

import { loadMSTPD } from "./dist/mstpd.mjs";
const mstp = await loadMSTPD();

// Crée 3 ponts
const a = mstp.createBridge("A", { priority: 4096 });
const b = mstp.createBridge("B", { priority: 8192 });
const c = mstp.createBridge("C");

// Chaque pont a deux ports
const a1 = a.addPort("a-b", { portno: 1 });
const a2 = a.addPort("a-c", { portno: 2 });
const b1 = b.addPort("b-a", { portno: 1 });
const b2 = b.addPort("b-c", { portno: 2 });
const c1 = c.addPort("c-a", { portno: 1 });
const c2 = c.addPort("c-b", { portno: 2 });

// Construit une topologie en triangle
mstp.link(a1, b1);
mstp.link(a2, c1);
mstp.link(b2, c2);

// Active tous les ponts et tous les ports
for (const br of [a, b, c]) br.enable();
for (const p of [a1, a2, b1, b2, c1, c2]) p.enable();

// Exécute 40 secondes de temps réel et affiche la topologie
mstp.step(40);
console.log("Topology:", mstp.topology());

Plusieurs dizaines de tests unitaires explorent les fonctionnalités de MSTPD et vérifient qu’elles se comportent correctement dans cet environnement :

$ node --test *.test.mjs
✔ two bridges: lower priority becomes root (41.657342ms)
✔ triangle loop: exactly one port blocks and all agree on the root (5.832ms)
✔ breaking the active link reconverges and restoring recovers (18.730753ms)
[…]
ℹ tests 40
ℹ pass 40
ℹ fail 0
[…]
ℹ duration_ms 396.190897

Du code JavaScript supplémentaire recherche les blocs <pre> contenant une définition de topologie et les transforme en composants interactifs. Vous pouvez inspecter et modifier la définition en cliquant sur le bouton « edit ».

Il y a aussi une astuce pour déterminer si la topologie a convergé. Après chaque pas, nous enregistrons un instantané de la mémoire de la simulation, jouons 50 secondes en accéléré pour vérifier que la topologie est stable, puis remontons le temps en restaurant cet instantané. 🕰️

Le code complet se trouve sur GitHub. Je suis très satisfait du résultat. Il peut être difficile de suivre tout ce qui se passe à chaque étape, mais la possibilité d’avancer et reculer aide beaucoup. Je compte réutiliser cette approche dans de prochains articles.

Pour associer des informations de routage, telles que les chemins d’AS ou les communautés BGP, aux flux, Akvorado peut importer des routes via le BGP Monitoring Protocol (BMP). Comme la table de routage Internet contient plus d’un million de routes, Akvorado doit gérer des dizaines de millions de routes¹. C’est un défi de longue date², mais je pense que ce problème est désormais résolu grâce au sharding de la RIB, une méthode qui découpe la base de routage en plusieurs parties afin de permettre les mises à jour concurrentes.

Implémentation précédente

Akvorado associe deux éléments pour construire sa RIB :

1. un arbre de préfixes et
2. une liste de routes attachée à chaque préfixe.

Dans le diagramme ci-dessus, la RIB stocke cinq préfixes IPv4 et deux préfixes IPv6. L’un d’eux, 2001:db8:1::/48, contient trois routes :

• depuis le pair 3, via 2001:db8::3:1, AS 65402, chemin d’AS 65402, communauté 65402:31 ;
• depuis le pair 4, via 2001:db8::4:1, mêmes ASN, chemin d’AS et communauté ;
• depuis le pair 5, via 2001:db8::5:1, AS 65402, chemin d’AS 65401 65402, communauté 65402:31.

La structure rib est définie en Go de la manière suivante :

type rib struct {
    tree          *bart.Table[prefixIndex]
    routes        map[routeKey]route
    nlris         *intern.Pool[nlri]
    nextHops      *intern.Pool[nextHop]
    rtas          *intern.Pool[routeAttributes]
    nextPrefixID  prefixIndex
    freePrefixIDs []prefixIndex
}

L’arbre de préfixes s’appuie sur le paquet bart, une adaptation de l’algorithme ART de Donald Knuth. Les benchmarks montrent qu’il surpasse les autres implémentations pour les recherches, les insertions et la consommation mémoire³. De plus, l’auteur est d’une grande aide.

Stocker les routes dans une table associative

La liste des routes de chaque préfixe n’est pas stockée directement dans l’arbre de préfixes : cela mettrait trop de pression sur le ramasse-miettes en allouant un tableau par préfixe.

À la place, la RIB attribue un identifiant de 32 bits unique à chaque préfixe, soit en prenant le dernier identifiant disponible dans le tableau freePrefixIDs, soit en utilisant la valeur nextPrefixID avant de l’incrémenter. Les routes sont ensuite stockées dans la table associative routes, qui s’appuie en Go sur une structure particulièrement optimisée. Pour récupérer les routes attachées à un préfixe, nous les cherchons un par un dans la table routes via une clef de 64 bits qui combine l’index de 32 bits du préfixe avec l’index de 32 bits représentant la position de la route dans la liste. Akvorado parcourt les routes de la première à la dernière pour trouver la meilleure⁴. Il sait qu’il n’y a plus de route lorsque la clé ne renvoie aucun résultat.

type prefixIndex uint32
type routeIndex uint32
type routeKey uint64

Canonisation des routes

Une route contient un identifiant de pair BGP, un NLRI partiel⁵, le prochain saut et les attributs.

type route struct {
    peer       uint32
    nlri       intern.Reference[nlri]
    nextHop    intern.Reference[nextHop]
    attributes intern.Reference[routeAttributes]
    prefixLen  uint8
}

type nlri struct {
    family bgp.Family
    path   uint32
    rd     RD
}
type nextHop netip.Addr
type routeAttributes struct {
    asn              uint32
    asPath           []uint32
    communities      []uint32
    largeCommunities []bgp.LargeCommunity
}

Pour économiser la mémoire et les allocations, les NLRI, les prochains sauts et les attributs de route sont canonisés : un entier de 32 bits remplace la valeur réelle. Ce mécanisme est antérieur au paquet unique introduit dans Go 1.23. Nous le conservons car ses compromis sont différents :

• il utilise un comptage de références explicite plutôt que des pointeurs faibles ;
• il fonctionne avec des valeurs non comparables implémentant les méthodes Hash() et Equal()⁶ ;
• il utilise des instances explicites pour la canonisation, ce qui se révèlera utile pour le sharding ;
• il offre de meilleures performances. Voir par exemple ce benchmark ;
• il consomme deux fois moins de mémoire grâce à des références 32 bits plutôt que des pointeurs ;
• mais il n’est pas utilisable de manière concurrente.

Qu’est-ce qui pose problème ?

Le verrou global en lecture/écriture est le goulot d’étranglement de cette implémentation. Mais pourquoi ? Plusieurs composants utilisent la RIB, chacun avec ses propres contraintes :

• Les consommateurs Kafka consultent la RIB pour enrichir les flux avec des informations de routage. Leur nombre est bornée par la somme des partitions Kafka⁸. Akvorado ajuste également ce nombre afin de garantir un export groupé efficace des flux vers ClickHouse. Sur notre installation, la quantité de consommateurs oscille entre 8 et 16. Comme nous voulons observer les données récentes le plus tôt possible, nous ne pouvons pas nous permettre que les consommateurs Kafka prennent trop de retard.

• Les routeurs surveillés envoient leurs routes via le protocole BMP. À la connexion, ils peuvent envoyer des millions de routes⁹. Après la synchronisation initiale, les mises à jour arrivent en continu et peuvent connaître des pics ponctuels. Le routeur détecte une station BMP bloquée lorsque sa fenêtre TCP est pleine. Dans ce cas, il réinitialise la session. Bien qu’Akvorado dispose d’un important tampon en entrée, il doit appliquer les routes reçues suffisamment vite pour ne pas être considéré comme bloqué.

• Quand un pair BGP distant tombe, Akvorado purge les routes associées en parcourant la RIB. Quand un routeur surveillé tombe, Akvorado patiente un peu, mais finit par purger toutes les routes associées.

En résumé : sur une installation chargée, la contention sur le verrou est forte autant pour les lecteurs que pour les écrivains, et aucun des deux ne peut prendre trop de retard.

Sharding de la RIB

Première étape

Pour supprimer le verrou global, la RIB est découpée en plusieurs « shards », chacun gérant un sous-ensemble des préfixes :

L’arbre de préfixes reste global et protégé par un unique verrou. Chaque partition dispose de son propre verrou en lecture/écriture, de sa table de routes et de ses blocs de canonisation pour stocker les NLRI, les prochains sauts et les attributs de route, ce qui n’aurait pas été possible avec le paquet unique de Go. Les index de préfixes sont eux aussi partitionnés : les 8 bits de poids fort correspondent à l’index de la partition et les 24 bits de poids faible à l’index local du préfixe.

Gerhard a confirmé que suite à ce changement à l’aveugle, le composant BMP a commencé à ronronner. 🎉

J’ai ensuite écrit un benchmark portant sur un demi-million de routes synthétiques mais plausibles¹⁰, réparties entre 0 et 8 écrivains qui modifient les routes aussi vite que possible, tandis que 1 à 16 lecteurs consultent en boucle un ensemble de 10 000 routes. J’ignore si ce benchmark est réaliste, mais il confirme les améliorations à la fois sur les latences en lecture et en écriture :

Il montre également qu’un grand nombre d’écrivains dégrade la latence en lecture.

Deuxième étape

L’unique verrou en lecture/écriture protégeant l’arbre de préfixes constitue la cible suivante. Le paquet bart propose des méthodes alternatives pour les mutations. Elles renvoient un arbre mis à jour via une copie partielle. Les lecteurs n’ont plus besoin du verrou global, qui ne sert plus qu’à synchroniser les écrivains. L’arbre de préfixes est encapsulé dans un pointeur atomique.

Sans verrou, un lecteur peut désormais récupérer un index de préfixe périmé en parcourant sa copie de l’arbre, lorsqu’un écrivain concurrent supprime la dernière route attachée à cet index et le recycle pour un autre préfixe. Pour éviter ce problème, nous combinons l’index de préfixe avec un numéro de génération que nous stockons dans l’arbre :

type generation uint32
type prefixRef struct {
    idx prefixIndex
    gen generation
}
type rib struct {
    mu     sync.Mutex
    tree   atomic.Pointer[bart.Table[prefixRef]]
    shards []*ribShard
}

Chaque partition stocke le numéro de génération de chaque index de préfixe local. Ce numéro est incrémenté quand l’index de préfixe associé est libéré. Lors de la recherche des routes attachées à un index de préfixe, le lecteur vérifie que le numéro de génération correspond. Sinon, il considère que l’index a été recyclé et que la liste de routes est vide¹¹. Le schéma précédent illustre ce cas pour l’index de préfixe 5, stocké avec un numéro de génération de 3, alors que la valeur actuelle dans le tableau []generations est 4. Le numéro de génération peut boucler, mais ce n’est pas un problème car les recherches sont rapides.

L’exécution du benchmark sur cette nouvelle implémentation montre les améliorations sur la latence en lecture ainsi qu’en écriture dès que le coût de la copie partielle de l’arbre de préfixes est amorti.

Parmi les nombreuses tentatives d’optimisation du composant BMP, le sharding de la RIB est l’une des plus satisfaisantes. Akvorado 2.2 implémente la première étape. La PR #2433, rédigée pendant l’écriture de ce billet, implémente la seconde et est sortie avec Akvorado 2.4. 🪓

Akvorado, un collecteur de flux réseau, s’appuie sur Traefik, un proxy HTTP, pour exposer les services HTTP d’un environnement Docker Compose. Des labels Docker attachés à chaque service définissent les règles de routage. Traefik les prend en compte automatiquement au démarrage d’un conteneur. Plutôt que de maintenir un fichier de configuration statique pour collecter les métriques Prometheus, la même approche s’applique avec Grafana Alloy, simplifiant sa configuration.

Traefik & Docker

Traefik écoute les événements sur la socket Docker. Chaque service annonce sa configuration via des labels. Par exemple, voici le service Loki dans Akvorado :

services:
  loki:
    # …
    expose:
      - 3100/tcp
    labels:
      - traefik.enable=true
      - traefik.http.routers.loki.rule=PathPrefix(`/loki`)

Dès que le conteneur est opérationnel, Traefik crée un routeur qui redirige les requêtes correspondant à /loki vers le premier port exposé. Placer la configuration Traefik au sein même de la définition du service est attirant. Comment obtenir la même chose pour les métriques Prometheus ?

Découverte de métriques avec Alloy

Grafana Alloy, un collecteur de métriques capable de collecter des métriques Prometheus, inclut un composant discovery.docker. Tout comme Traefik, il se connecte à la socket Docker¹. Avec quelques règles de réétiquetage, on peut lui apprendre à utiliser les labels Docker pour localiser et collecter les métriques.

On définit trois labels sur chaque service :

• metrics.enable active la collecte de métriques,
• metrics.port indique le port exposant les métriques Prometheus,
• metrics.path indique le chemin vers les métriques.

Si le service expose plus d’un port, metrics.port est obligatoire, sinon il prend par défaut la valeur de l’unique port exposé. La valeur par défaut de metrics.path est /metrics. Le service Loki devient :

services:
  loki:
    # …
    expose:
      - 3100/tcp
    labels:
      - traefik.enable=true
      - traefik.http.routers.loki.rule=PathPrefix(`/loki`)
      - metrics.enable=true
      - metrics.path=/loki/metrics

La configuration d’Alloy se divise en quatre parties :

1. découvrir les conteneurs via la socket Docker,
2. filtrer et réétiqueter les cibles à l’aide des labels Docker,
3. collecter les métriques,
4. transmettre les métriques à Prometheus.

Découverte des conteneurs Docker

Le premier bloc découvre les conteneurs en cours d’exécution :

discovery.docker "docker" {
  host             = "unix:///var/run/docker.sock"
  refresh_interval = "30s"
  filter {
    name   = "label"
    values = ["com.docker.compose.project=akvorado"]
  }
}

Alloy se connecte à la socket Docker et liste les conteneurs toutes les 30 secondes². Le bloc filter restreint la découverte aux conteneurs du projet akvorado, évitant toute interférence avec d’autres conteneurs sur le même hôte. Pour chaque conteneur découvert, Alloy produit une cible avec des labels tels que __meta_docker_container_label_metrics_port pour le label Docker metrics.port.

Réétiquetage des cibles

L’étape de réétiquetage filtre et transforme les cibles brutes issues de la découverte Docker en cibles exploitables. La première étape ne conserve que les cibles dont metrics.enable vaut true :

discovery.relabel "prometheus" {
  targets = discovery.docker.docker.targets

  // Keep only targets with metrics.enable=true
  rule {
    source_labels = ["__meta_docker_container_label_metrics_enable"]
    regex         = `true`
    action        = "keep"
  }

  // …
}

La deuxième étape remplace le port découvert lorsque metrics.port est défini :

// When metrics.port is set, override __address__.
rule {
  source_labels = ["__address__", "__meta_docker_container_label_metrics_port"]
  regex         = `(.+):\d+;(.+)`
  target_label  = "__address__"
  replacement   = "$1:$2"
}

Ensuite, on gère les conteneurs en mode réseau host. Quand __meta_docker_network_name vaut host, l’adresse est réécrite en host.docker.internal au lieu de localhost³ :

// When host networking, override __address__ to host.docker.internal.
rule {
  source_labels = ["__meta_docker_container_label_metrics_port", "__meta_docker_network_name"]
  regex         = `(.+);host`
  target_label  = "__address__"
  replacement   = "host.docker.internal:$1"
}

L’étape suivante dérive le label job à partir du nom du service, en supprimant tout suffixe numéroté. Le label instance est l’adresse sans le port :

rule {
  source_labels = ["__meta_docker_container_label_com_docker_compose_service"]
  regex         = `(.+)(?:-\d+)?`
  target_label  = "job"
}
rule {
  source_labels = ["__address__"]
  regex         = `(.+):\d+`
  target_label  = "instance"
}

Si un conteneur définit metrics.path, Alloy l’utilise comme chemin. Sinon, la valeur par défaut est /metrics :

rule {
  source_labels = ["__meta_docker_container_label_metrics_path"]
  regex         = `(.+)`
  target_label  = "__metrics_path__"
}
rule {
  source_labels = ["__metrics_path__"]
  regex         = ""
  target_label  = "__metrics_path__"
  replacement   = "/metrics"
}

Collecte et transmission

Une fois les cibles correctement réétiquetées, la collecte et la transmission sont sommaires :

prometheus.scrape "docker" {
  targets         = discovery.relabel.prometheus.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
}

prometheus.remote_write "default" {
  endpoint {
    url = "http://prometheus:9090/api/v1/write"
  }
}

prometheus.scrape récupère périodiquement les métriques des cibles découvertes. prometheus.remote_write les transmet à Prometheus.

Exporteurs intégrés

Certains services n’exposent pas de point d’accès Prometheus. Redis et Kafka en sont des exemples courants. Alloy embarque des exporteurs Prometheus capables d’interroger ces services et d’exposer les métriques à leur place.

prometheus.exporter.redis "docker" {
  redis_addr = "redis:6379"
}
discovery.relabel "redis" {
  targets = prometheus.exporter.redis.docker.targets
  rule {
    target_label = "job"
    replacement  = "redis"
  }
}
prometheus.scrape "redis" {
  targets         = discovery.relabel.redis.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
}

Le même schéma s’applique à Kafka :

prometheus.exporter.kafka "docker" {
  kafka_uris = ["kafka:9092"]
}
discovery.relabel "kafka" {
  targets = prometheus.exporter.kafka.docker.targets
  rule {
    target_label = "job"
    replacement  = "kafka"
  }
}
prometheus.scrape "kafka" {
  targets         = discovery.relabel.kafka.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
}

Chaque exporteur est un composant distinct avec sa propre configuration de réétiquetage et de collecte. Le label job est défini explicitement.

Avec cette configuration, ajouter des métriques à un nouveau service disposant d’un point d’accès Prometheus se résume à quelques labels dans docker-compose.yml, tout comme l’ajout d’une route Traefik. Alloy s’en charge automatiquement. Une approche similaire est possible avec d’autres méthodes de découverte, comme discovery.kubernetes, discovery.scaleway ou discovery.http. 🩺

Akvorado 2.0 est publié aujourd’hui ! Akvorado est un collecteur de flux réseau IPFIX et sFlow. Il enrichit les flux et les stocke dans une base de données ClickHouse. Les utilisateurs peuvent parcourir les données via une console web. Cette version introduit un changement architectural important et d’autres améliorations mineures. Regardons plus en détails ! 🤿

$ git diff --shortstat v1.11.5
 493 files changed, 25015 insertions(+), 21135 deletions(-)

Nouveau service « outlet »

Le changement majeur dans Akvorado 2.0 est la séparation du service inlet en deux parties : l’inlet et l’outlet. Auparavant, l’inlet gérait tout le traitement des flux : réception, décodage et enrichissement. Les flux étaient ensuite envoyés à Kafka pour stockage dans ClickHouse :

Les flux réseau atteignent le service inlet via des chaussettes UDP, un protocole non fiable. L’inlet doit les traiter assez rapidement pour éviter de perdre des paquets. Pour gérer un grand nombre de flux, l’inlet crée plusieurs ensembles de workers pour recevoir les flux, récupérer les métadonnées et assembler les flux enrichis pour Kafka. De nombreuses options de configuration existaient pour la montée en charge, ce qui augmentait la complexité pour les utilisateurs. Le code devait éviter tout blocage, rendant la chaîne de traitement complexe et parfois peu fiable, notamment le composant BMP¹. L’ajout de nouvelles fonctionnalités sans aggraver le problème devenait difficile².

Dans Akvorado 2.0, l’inlet reçoit les flux et les pousse vers Kafka sans les décoder. Le nouveau service outlet gère les tâches restantes :

Ce changement va au-delà d’un simple découpage³ : l’outlet lit maintenant les flux depuis Kafka et les pousse vers ClickHouse, deux tâches qu’Akvorado ne gérait pas auparavant. Les flux sont groupés par lots pour augmenter l’efficacité et réduire la charge sur ClickHouse en utilisant ch-go, un client Go bas niveau pour ClickHouse. Quand les lots sont trop petits, des insertions asynchrones sont utilisées (e20645). Le nombre de workers de l’outlet s’ajuste dynamiquement (e5a625) en fonction de la cible sur la taille des lots et de la latence (50 000 flux et 5 secondes par défaut).

Cette nouvelle architecture nous permet également de simplifier et optimiser le code. L’outlet récupère les métadonnées de façon synchrone (e20645). Le composant BMP devient plus simple en supprimant le multitâche coopératif (3b9486). Réutiliser le même objet RawFlow pour décoder les flux Protobuf depuis Kafka réduit la pression sur le ramasse-miettes (8b580f).

L’effet sur les performances globales d’Akvorado était quelque peu incertain, mais un utilisateur a indiqué gagner 35 % d’utilisation CPU en moins après migration depuis la version précédente, ainsi que la résolution du problème de longue date du composant BMP. 🥳

Autres changements

Cette nouvelle version inclut de nombreux changements divers. On y trouve par exemple la complétion pour les ports sources et destinations (f92d2e), et le redémarrage automatique de l’orchestrateur (0f72ff) lors de changements de configuration pour éviter un piège courant pour les nouveaux utilisateurs.

Concentrons-nous sur quelques domaines clés pour cette version : observabilité, documentation, CI, Docker, Go et JavaScript.

Observabilité

Akvorado expose des métriques pour fournir une visibilité sur la chaîne de traitement et aider à diagnostiquer les problèmes. Elles sont disponibles au format Prometheus, via par exemple /api/v0/inlet/metrics. Avec l’introduction de l’outlet, de nombreuses métriques ont été déplacées. Certaines ont également été renommées (4c0b15) pour correspondre aux bonnes pratiques Prometheus. Une métrique pour mesurer le décalage des consommateurs Kafka a été ajoutée (e3a778).

Si vous n’avez pas votre propre pile d’observabilité, la configuration Docker Compose fournie avec Akvorado en propose une. Vous pouvez l’activer avec les profils introduits à cette fin (529a8f).

Le profil prometheus fournit Prometheus pour stocker les métriques et Alloy pour les collecter (2b3c46, f81299 et 8eb7cd). Les métriques Redis et Kafka sont collectées via l’exporteur intégré à Alloy (560113). Les autres métriques sont exposées au format Prometheus et sont automatiquement récupérées par Alloy à l’aide d’annotations Docker. C’est similaire à ce qui est fait pour configurer Traefik. cAdvisor a également été ajouté (83d855) pour fournir des métriques liées aux conteneurs.

Le profil loki fournit Loki pour stocker les logs (45c684). Bien qu’Alloy puisse collecter et envoyer les logs vers Loki, ses capacités d’analyse sont limitées : je n’ai pas trouvé de moyen de préserver toutes les métadonnées associées aux logs structurés produits par de nombreuses applications, y compris Akvorado. Vector remplace Alloy (95e201) et propose un langage, VRL, pour transformer les logs. Malheureusement, il ne peut actuellement pas récupérer les logs Docker précédant son démarrage.

Enfin, le profil grafana fournit Grafana, mais les tableaux de bord fournis sont pour le moment cassés. Ce sera corrigé dans une prochaine version.

Documentation

La configuration Docker Compose fournie par Akvorado facilite la mise en route rapide. Cependant, Akvorado nécessite quelques étapes obligatoires pour être fonctionnel. Il est livré avec une documentation complète, y compris un chapitre sur le dépannage des problèmes. J’espérais que cette documentation réduirait la charge de support. Il est difficile de savoir si cela fonctionne. Les utilisateurs satisfaits rapportent rarement leurs succès, tandis qu’une poignée d’utilisateurs ouvrent des discussions pour demander de l’aide sans avoir vraiment lu la documentation.

Dans cette version, la documentation a été considérablement améliorée.

$ git diff --shortstat v1.11.5 -- console/data/docs
 10 files changed, 1873 insertions(+), 1203 deletions(-)

La documentation a été mise à jour (fc1028) pour correspondre à la nouvelle architecture d’Akvorado. La section de dépannage a été réécrite (17a272). Une documentation sur comment améliorer les performances de ClickHouse lors de la mise à niveau depuis des versions antérieures à 1.10.0 a été ajoutée (5f1e9a). Un LLM a relu l’ensemble (06e3f3). La documentation destinée aux développeurs a également été améliorée (548bbb, e41bae et 871fc5).

Du point de vue de l’utilisabilité, les sections de la table des matières peuvent maintenant se replier (c142e5). Les avertissements aident à attirer l’attention des utilisateurs sur les points importants (8ac894).

Intégration continue

Cette version inclut des efforts pour accélérer l’intégration continue sur GitHub. Les tests de couverture et de concurrence s’exécutent en parallèle (6af216 et fa9e48). L’image Docker se construit pendant les tests mais ne reçoit son étiquette qu’après leurs succès (8b0dce).

Les tests de bout en bout (883e19) s’assurent que la configuration Docker Compose fournie fonctionne comme attendu. Hurl exécute des tests sur diverses URL, notamment pour vérifier les métriques (42679b et 169fa9). Par exemple :

## Test inlet has received NetFlow flows
GET http://127.0.0.1:8080/prometheus/api/v1/query
[Query]
query: sum(akvorado_inlet_flow_input_udp_packets_total{job="akvorado-inlet",listener=":2055"})
HTTP 200
[Captures]
inlet_receivedflows: jsonpath "$.data.result[0].value[1]" toInt
[Asserts]
variable "inlet_receivedflows" > 10

## Test inlet has sent them to Kafka
GET http://127.0.0.1:8080/prometheus/api/v1/query
[Query]
query: sum(akvorado_inlet_kafka_sent_messages_total{job="akvorado-inlet"})
HTTP 200
[Captures]
inlet_sentflows: jsonpath "$.data.result[0].value[1]" toInt
[Asserts]
variable "inlet_sentflows" >= {{ inlet_receivedflows }}

Docker

Akvorado est fourni avec une configuration Docker Compose complète pour aider les utilisateurs à démarrer rapidement. Elle assure un déploiement cohérent, éliminant de nombreux problèmes liés à l’environnement et la configuration. Elle sert également de documentation.

Cette version apporte quelques petites améliorations autour de Docker :

• un exemple pour configurer Traefik pour TLS avec Let’s Encrypt (1a27bb),
• la compression HTTP (bee9a5), et
• le support d’IPv6 (a74a41).

Auparavant, de nombreuses images Docker provenaient de la bibliothèque de conteneurs Bitnami. Cependant, Bitnami a été racheté par VMWare en 2019 et VMWare a été racheté par Broadcom en 2023. En conséquence, les images Bitnami ont été dépréciées en moins d’un mois. Ce n’était pas vraiment une surprise⁴. Les versions précédentes d’Akvorado avaient déjà commencé à s’en éloigner. Dans cette version, l’image Kafka du projet Apache remplace celle de Bitnami (1eb382). Grâce au passage au mode KRaft, Zookeeper n’est plus nécessaire (0a2ea1, 8a49ca et f65d20).

Les images Docker d’Akvorado étaient auparavant compilées avec Nix. Cependant, construire des images AArch64 sur x86-64 est lent car cela repose sur l’émulation de QEMU. Le Dockerfile mis à jour utilise des constructions multi-étapes et multi-plateformes : une étape construit la partie JavaScript sur la plateforme hôte, une étape construit la partie Go en compilation croisée sur la plateforme hôte, et la dernière étape assemble l’image en se basant sur une image légère (268e95 et d526ca).

# Ceci est une version simplifiée
FROM --platform=$BUILDPLATFORM node:20-alpine AS build-js
RUN apk add --no-cache make
WORKDIR /build
COPY console/frontend console/frontend
COPY Makefile .
RUN make console/data/frontend

FROM --platform=$BUILDPLATFORM golang:alpine AS build-go
RUN apk add --no-cache make curl zip
WORKDIR /build
COPY . .
COPY --from=build-js /build/console/data/frontend console/data/frontend
RUN go mod download
RUN make all-indep
ARG TARGETOS TARGETARCH TARGETVARIANT VERSION
RUN make

FROM gcr.io/distroless/static:latest
COPY --from=build-go /build/bin/akvorado /usr/local/bin/akvorado
ENTRYPOINT [ "/usr/local/bin/akvorado" ]

Lors de la construction pour plusieurs plateformes avec --platform linux/amd64,linux/arm64,linux/arm/v7, les étapes de construction jusqu’à la ligne surlignée ne s’exécutent qu’une seule fois pour toutes les plateformes. Cela accélère considérablement la compilation. 🚅

Akvorado livre maintenant des images Docker pour ces plateformes : linux/amd64, linux/amd64/v3, linux/arm64 et linux/arm/v7. Lors du téléchargement de ghcr.io/akvorado/akvorado, Docker sélectionne la meilleure image pour le CPU actuel. Sur x86-64, il y a deux choix. Si votre CPU est assez récent, Docker télécharge linux/amd64/v3. Cette version contient des optimisations supplémentaires et devrait s’exécuter plus rapidement que la version linux/amd64. Il serait intéressant de livrer une image pour linux/arm64/v8.2, mais Docker ne supporte pas encore le même mécanisme pour AArch64 (792808).

Go

Cette version inclut de nombreux changements liés à Go mais non visibles pour les utilisateurs.

Chaîne de compilation

Par le passé, Akvorado supportait les deux dernières versions de Go, empêchant l’utilisation immédiate des dernières améliorations. L’objectif était de permettre aux utilisateurs de distributions stables d’utiliser les versions de Go fournies avec leur distribution pour compiler Akvorado. Cependant, cela pouvait être frustrant quand des fonctionnalités intéressantes, comme go tool, étaient publiées. Akvorado 2.0 nécessite Go 1.25 (77306d) mais peut être compilé avec des chaînes de compilation plus anciennes en téléchargeant automatiquement une version plus récente (94fb1c)⁵. Les utilisateurs peuvent toujours modifier GOTOOLCHAIN pour annuler cette décision. La chaîne de compilation recommandée est mise à jour hebdomadairement via la CI pour s’assurer d’obtenir la dernière version mineure (5b11ec). Ce changement simplifie aussi les mises à jour vers des versions plus récentes : seul go.mod doit être mis à jour.

Grâce à ce changement, Akvorado utilise maintenant wg.Go() (77306d) et j’ai commencé à convertir certains tests unitaires vers le nouveau paquet test/synctest (bd787e, 7016d8 et 159085).

Tests

Pour tester l’égalité, j’utilise une fonction Diff() qui affiche les différences en cas d’échec :

got := input.Keys()
expected := []int{1, 2, 3}
if diff := helpers.Diff(got, expected); diff != "" {
    t.Fatalf("Keys() (-got, +want):\n%s", diff)
}

Cette fonction utilise kylelemons/godebug. Ce paquet n’est plus maintenu et présente des lacunes : par exemple, par défaut, elle ne compare pas les champs privés des structures, ce qui peut causer des tests qui réussissent de façon inattendue. Je l’ai remplacé par google/go-cmp, qui est plus strict et formatte la différence de manière plus lisible (e2f1df).

Un autre paquet pour Kafka

Un autre changement est le passage de Sarama à franz-go pour interagir avec Kafka (756e4a et 2d26c5). La principale motivation pour ce changement est de travailler avec un meilleur modèle de concurrence. Sarama repose fortement sur les canaux et il est difficile de savoir quand un objet n’est plus utilisé. franz-go utilise une approche plus moderne⁶ et performante avec des fonctions de rappel. Il est également livré avec un paquet pour lancer de faux clusters Kafka, ce qui est plus pratique que les fonctions de simulation fournies par Sarama.

Table de routage améliorée pour BMP

Pour stocker les routes, le composant BMP utilisait kentik/patricia, une implémentation d’un arbre patricia axée sur la réduction de la pression sur le ramasse-miettes. gaissmai/bart est une alternative plus récente utilisant une adaptation de l’algorithme ART de Donald Knuth qui promet de meilleures performances et les fournit : recherches 90 % plus rapides et insertions 27 % plus rapides (92ee2e et fdb65c).

Contrairement à kentik/patricia, gaissmai/bart n’aide pas à stocker efficacement les valeurs attachées à chaque préfixe. J’ai adapté la même approche utilisée par kentik/patricia pour stocker les listes de routes pour chaque préfixe : stocker un index 32 bits pour chaque préfixe, et l’utiliser pour construire un index 64 bits pour rechercher les routes dans un tableau associatif, qui est une structure particulièrement efficace de Go.

gaissmai/bart supporte également une version sans verrous de la table de routage, mais ce n’est pas aussi simple car nous aurions besoin d’étendre cela au tableau stockant les routes et au mécanisme d’internement. J’ai également tenté d’utiliser le nouveau paquet unique de Go pour remplacer le paquet intern inclus dans Akvorado, mais les performances étaient pires⁷.

Divers

Les versions précédentes d’Akvorado utilisaient un encodeur Protobuf personnalisé pour les performances et la flexibilité. Avec l’introduction du service outlet, Akvorado n’a besoin que d’un schéma statique simple, donc ce code a été supprimé. Cependant, il est possible d’améliorer les performances avec planetscale/vtprotobuf (e49a74 et 8b580f). De plus, la dépendance à protoc, un programme C++, était quelque peu ennuyeuse. Par conséquent, Akvorado utilise maintenant buf, écrit en Go, pour convertir un schéma Protobuf en code Go (f4c879).

Une autre petite optimisation pour réduire la taille du binaire d’Akvorado de 10 MB a consisté à compresser les ressources statiques intégrées dans Akvorado dans un fichier ZIP. Cela inclut la base des numéros d’AS, ainsi que les images SVG pour la documentation. Un bout de code rend ce changement transparent (b1d638 et e69b91).

JavaScript

Récemment, deux grandes attaques de la chaîne d’approvisionnement ont frappé l’écosystème JavaScript : une affectant les paquets populaires chalk et debug et une autre impactant le paquet populaire @ctrl/tinycolor. Ces attaques existent aussi dans d’autres écosystèmes, mais JavaScript est une cible privilégiée en raison de l’usage intensif de petites dépendances. La version précédente d’Akvorado reposait sur 653 dépendances.

npm-run-all a été supprimé (3424e8, 132 dépendances). patch-package a été supprimé (625805 et e85ff0, 69 dépendances) en déplaçant les définitions TypeScript manquantes vers env.d.ts. eslint a été remplacé par oxlint, un linter écrit en Rust (97fd8c, 125 dépendances, plugins inclus).

J’ai basculé de npm vers Pnpm, un gestionnaire de paquets alternatif (fce383). Pnpm n’exécute pas les scripts d’installation par défaut⁸ et empêche l’installation de paquets trop récents. Il est également significativement plus rapide⁹. Contrairement à npm, il n’est pas livré avec Node.js. Cependant, Node.js contient Corepack, qui nous permet d’utiliser Pnpm sans l’installer. Pnpm peut également lister les licences utilisées par chaque dépendance, supprimant le besoin d’utiliser license-compliance (a35ca8, 42 dépendances).

Pour des améliorations de vitesse supplémentaires, au-delà du passage à Pnpm et Oxlint, Vite a été remplacé par sa version Rolldown plus rapide (463827).

Après ces changements, Akvorado ne nécessite plus « que » 225 dépendances. 😱

Prochaines étapes

J’aimerais intégrer trois fonctionnalités dans la prochaine version d’Akvorado :

• Ajouter des tableaux de bord Grafana pour compléter la pile d’observabilité. Voir le ticket #1906 pour les détails.

• Intégrer le plugin Grafana d’OVH en fournissant une API stable pour de telles intégrations. La console web d’Akvorado resterait utile pour parcourir les résultats, mais si vous voulez créer et partager des tableaux de bord, vous devrez passer à Grafana. Voir le ticket #1895.

• Déplacer une partie du travail actuellement fait dans ClickHouse (dictionnaires personnalisés, GeoIP et ajout d’informations liées aux IP) vers le service outlet. Cela devrait donner plus de flexibilité pour ajouter des fonctionnalités comme celle demandée dans le ticket #1030. Voir le ticket #2006.

J’ai commencé à travailler sur la division de l’inlet il y a plus d’un an. J’ai retrouvé de la motivation ces derniers mois, en partie grâce à Claude Code, que j’ai utilisé comme canard en plastique. Presque aucun code produit n’a été conservé¹⁰ : c’est comme un stagiaire qui n’apprend pas. D’ailleurs, il est aussi flemmard. Pour la traduction en français, il a fallu insister de nombreuses fois pour traduire l’intégralité de l’article. 🦆

La combinaison des confédérations BGP et du remplacement d’AS peut potentiellement créer une boucle de routage BGP, résultant en un chemin d’AS qui grossit indéfiniment.

La confédération BGP est une technique utilisée pour réduire le nombre de sessions iBGP et améliorer le passage à l’échelle dans les grands systèmes autonomes (AS). Elle divise un AS en sous-AS. La plupart des règles eBGP s’appliquent entre les sous-AS, sauf que le saut suivant, la MED et les préférences locales restent inchangés. La longueur du chemin d’AS ignore les contributions des sous-AS de la confédération. La confédération BGP est rarement utilisée et la réflexion des routes BGP lui est généralement préférée.

Le remplacement d’AS est une fonctionnalité qui permet à un routeur de remplacer l’ASN d’un voisin dans le chemin d’AS des routes BGP sortantes par le sien. C’est utile lorsque deux systèmes autonomes distincts partagent le même ASN. Cependant, cela interfère avec le mécanisme de prévention des boucles de BGP et doit être utilisé avec prudence. Une alternative plus sûre est la directive allowas-in¹.

Dans l’exemple ci-dessous, nous avons quatre routeurs dans une seule confédération, chacun dans son propre sous-AS. R0 est à l’origine du préfixe 2001:db8::1/128. R1, R2, et R3 transmettent ce préfixe au routeur suivant dans la boucle.

Les configurations des routeurs sont disponibles dans un dépôt Git. Ils tournent sous Cisco IOS XR. R2 utilise la configuration BGP suivante :

router bgp 64502
 bgp confederation peers
  64500
  64501
  64503
 !
 bgp confederation identifier 64496
 bgp router-id 1.0.0.2
 address-family ipv6 unicast
 !
 neighbor 2001:db8::2:0
  remote-as 64501
  description R1
  address-family ipv6 unicast
  !
 !
 neighbor 2001:db8::3:1
  remote-as 64503
  advertisement-interval 0
  description R3
  address-family ipv6 unicast
   next-hop-self
   as-override
  !
 !
!

La session avec R3 utilise à la fois les directives as-override et next-hop-self. Cette dernière est seulement nécessaire pour rendre le préfixe annoncé valide, car il n’y a pas d’IGP dans cet exemple².

Voici la séquence d’événements menant à un chemin d’AS infini :

1. R0 envoie le préfixe à R1 avec le chemin d’AS (64500)³.

2. R1 le sélectionne comme meilleur chemin et le transmet à R2 avec le chemin d’AS (64501 64500).

3. R2 le sélectionne comme meilleur chemin et le transmet à R3 avec le chemin d’AS (64502 64501 64500).

4. R3 le sélectionne comme meilleur chemin. Il devrait le transmettre à R1 avec le chemin d’AS (64503 64502 64501 64500), mais en raison du remplacement d’AS, il substitue l’ASN de R1 par le sien, le transmettant avec le chemin d’AS (64503 64502 64503 64500).

5. R1 accepte le préfixe, car son propre ASN n’est pas dans le chemin d’AS. Il compare ce nouveau préfixe avec celui de R0. (64500) et (64503 64502 64503 64500) ont la même longueur car les sous-AS de la confédération ne contribuent pas à la longueur du chemin d’AS. Le premier critère pour départager les deux routes est alors l’ID du routeur. L’ID du routeur de R0 (1.0.0.4) est plus élevé que celui de R3 (1.0.0.3). Le nouveau préfixe devient le meilleur chemin et est transmis à R2 avec le chemin d’AS (64501 64503 64501 64503 64500).

6. R2 reçoit le nouveau préfixe, remplaçant l’ancien. Il le sélectionne comme meilleur chemin et le transmet à R3 avec le chemin d’AS (64502 64501 64502 64501 64502 64500).

7. R3 reçoit le nouveau préfixe, remplaçant l’ancien. Il le sélectionne comme meilleur chemin et le transmet à R0 avec le chemin d’AS (64503 64502 64503 64502 64503 64502 64500).

8. R1 reçoit le nouveau préfixe, remplaçant l’ancien. Encore une fois, il est en concurrence avec le préfixe de R0, et encore une fois le nouveau préfixe gagne en raison de l’ID de routeur inférieur. Le préfixe est transmis à R2 avec le chemin d’AS (64501 64503 64501 64503 64501 64503 64501 64500).

Quelques itérations plus tard, R1 voit le préfixe en boucle comme suit⁴ :

RP/0/RP0/CPU0:R1#show bgp ipv6 u 2001:db8::1/128 bestpath-compare
BGP routing table entry for 2001:db8::1/128
Last Modified: Jul 28 10:23:05.560 for 00:00:00
Paths: (2 available, best #2)
  Path #1: Received by speaker 0
  Not advertised to any peer
  (64500)
    2001:db8::1:0 from 2001:db8::1:0 (1.0.0.4), if-handle 0x00000000
      Origin IGP, metric 0, localpref 100, valid, confed-external
      Received Path ID 0, Local Path ID 0, version 0
      Higher router ID than best path (path #2)
  Path #2: Received by speaker 0
  Advertised IPv6 Unicast paths to peers (in unique update groups):
    2001:db8::2:1
  (64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64503 64502 64500)
    2001:db8::4:0 from 2001:db8::4:0 (1.0.0.3), if-handle 0x00000000
      Origin IGP, metric 0, localpref 100, valid, confed-external, best, group-best
      Received Path ID 0, Local Path ID 1, version 37
      best of AS 64503, Overall best

Il n’y a pas de limite supérieure pour un chemin d’AS, mais les messages BGP ont des limites de taille (4096 octets selon RFC 4271 ou 65535 octets selon RFC 8654). Passé un certain nombre d’itérations, les mises à jour BGP ne peuvent plus être générées. Sur Cisco IOS XR, le processus BGP plante bien avant d’atteindre cette limite⁵.

Les principales leçons de cette histoire sont de n’utiliser en aucune circonstance les confédérations BGP et d’être prudent avec les fonctionnalités qui affaiblissent la détection de boucles de routage BGP. 🌀