In recent years, the concepts of Artificial Intelligence (AI) and Machine Learning (ML)...
La découverte des peers BGP LLDP
Link Layer Discovery Protocol (LLDP) est un protocole de découverte indépendant du constructeur et défini dans la norme IEEE 802.1AB. Il a été conçu afin de remplacer le protocole propriétaire Cisco Discovery Protocol (CDP). Avec LLDP, les périphériques réseau tels que les commutateurs fonctionnant sur la couche 2 (« Link layer ») du modèle OSI peuvent collecter des informations de la couche supérieure du périphérique voisin, telles que l’adresse IP, la version du système d’exploitation, etc. LLDP est un protocole de découverte des voisins et donc, ne peut pas être utilisé pour la configuration des périphériques réseau.
Chaque trame Ethernet LLDP contient une unité de données LLDP (LLDPDU) avec le type Ethernet défini sur la valeur 0x88CC. Le routeur envoie par défaut les annonces LLDP à partir de ses ports chaque 30 secondes. L’adresse MAC source (SA) est ainsi l’adresse MAC du routeur, tandis que l’adresse de destination (DA) est l’adresse multicast LLDP 01-80-C2-00-00-0E. La trame Ethernet LLDP reçu n’est pas transmise aux autres routeurs.
Image 1 – La structure du cadre Ethernet LLDP
L’unité de données LLDP transportée à l’intérieur de la frame Ethernet contient plusieurs structures différentes Type Length Values (TLVs). Un routeur envoie un LLDPDU avec différents TLV pour informer un appareil voisin sur les informations locales. Pendant que certains TLV sont obligatoires, d’autres sont facultatifs. Par exemple, les TLV obligatoires à l’intérieur de chaque LLDPU sont les suivants: Chassis ID (Type 1), TLV Port ID (Type 2), Time to Live (TTL) (type 3) et End of LLDPDU (Type 0).
Le “chassis ID” et le “port ID TLVs” sont utilisés afin d’identifier le routeur. Le TLV “Time to Live” est utilisé pour mesurer le vieillissement de l’information, et indique combien de temps l’annonce LLDP doit être conservé par le récepteur.
Remarque: Dans la notion “TLV”, T est le type d’information, L est la longueur de l’information et V est la valeur (contenu TLV). |
Les TLV spécifiques à l’organisation (OS-TLV) sont l’un des types de TLV facultatifs. Ils partagent tous la valeur de type commune – 127. Les organisations sont identifiées par l’Identifiant Unique à l’Organisation (OUI). Par exemple, le OUI 00-00-5E a été assigné à l’organisation l’IANA. Chaque organisation définit ses propres OS-TLV identifiés par le sous-type.
Le Config BGP OS-TLV est utilisé pour annoncer les informations de configuration BGP. L’OUI utilisé pour le Config BGP OS-TLV est 00-00-5E (IANA) pendant que le sous-type est réglé sur 1. Les informations de configuration BGP dans le Config BGP OS-TLV sont composées de Config BGP Sub -TLV. Chaque sub-TLV contient des informations de configuration BGP spécifiques. Par exemple, le Sub-TLV BGP Local AS contient un ou plusieurs numéros de système autonome (AS) locaux de 4 octets. Tous les sous-TLV de configuration BGP contiennent des champs Type et Length,
chacun d’eux ayant une longueur d’un octet.
Remarque: Plusieurs OS-TLV de BGP Config peuvent être inclus dans LLDPDU. |
Ci-dessous se trouve une structure de BGP Config OS-TLV encapsulée à l’intérieur du champ LLDPDU de la frame Ethernet.
Image 2 – BGP Config OS-TLV
Les sub-TLV de BGP Config sont identifiés par leur type de sub-TLV. Par exemple, le sous-TLV BGP Local AS correspond au type 2, tandis que le sub-TLV BGP Identifier correspond au type 3. Dans le tableau 1 ci-dessous, on peut visualiser tous les TLV de configuration BGP connus ainsi que leurs types.
Nom du sub-TLV de configuration BGP | Type |
---|---|
Peering Address Sub-TLV | 1 |
BGP Local AS Sub-TLV | 2 |
BGP Identifier Sub-TLV | 3 |
Session Group-ID Sub-TLV | 4 |
BGP Session Capabilities Sub-TLV | 5 |
Key Chain Sub-TLV | 6 |
Tableau 1 – Les Sub-TLV de configuration BGP et leurs types
L’importance des sub-TLV de configuration BGP et de leur fonctionnement est absolument évidente: un routeur configuré pour la découverte des LLDP peers envoie le Sub-TLV Peering Address du TLV de la configuration BGP à l’intérieur du LLDPDU du cadre Ethernet. L’annonce informe un routeur sur le site opposé d’un lien sur l’adresse de peering de l’expéditeur. La distance peut être d’un ou deux sauts (lorsque l’adresse loopback est utilisée), tandis que l’adresse est soit IPv4 ou IPv6. Un récepteur BGP configuré pour la découverte des peers LLDP essaie d’établir une session BGP avec le peer. Le routeur expéditeur peut annoncer son numéro AS local dans le sub-TLV BGP Local AS du BGP OS-TLV. En cas de migration d’ASN, un deuxième ASN local peut également être inclus. Le routeur expéditeur peut également annoncer son identifiant BGP local (ID du routeur BGP) dans le sub-TLV BGP Identifier du TLV BGP-OS où le BGP Identifier est utilisé pour débogage. Un routeur BGP peut envoyer un sub-TLV Session Group-ID pour classer les sessions Top of Rack (ToR) ou Spine BGP dans les centres de données. Le routeur expéditeur peut envoyer le sub-TLV BGP Session Capabilities du TLV BGP-OS pour annoncer la prise en charge des capacités pertinentes telles que l’authentification MD5, l’option d’authentification TCP (TCP-AO) et le mécanisme de sécurité TTL généralisé (GTSM). Dans ce cas, l’expéditeur envoie également le sub-TLV Key Chain du TLV BGP-OS. Il s’agit d’une chaîne (jusqu’à 64 octets) qui spécifie le nom du “key chain”.
La découverte du BGP peering à l’aide de LLDP peut être utilisée dans de grands centres de données Layer 3 où on utilise eBGP comme protocole de routage unique. Le déploiement de BGP avec la fonction “BGP peering discovery” activée à l’aide de LLDP pourra réduire considérablement la charge de configuration BGP dans de grands centres de données. La fonctionnalité “BGP Peering discovery” est actuellement un défi important à résoudre, une chose qu’est également indiquée par l’existence d’un autre projet IEFT. Ce projet nous suggère une autre approche – changer le BGP lui-même. Ce projet introduit un nouveau message “BGP Hello”, au lieu d’utiliser d’autres protocoles tels que LLDP. Ce message est envoyé dans un intervalle de temps périodique sur les interfaces où la fonctionnalité “BGP neighbor autodiscovery” est activée à l’adresse IP multicast à l’aide du port UDP 179. Le message “Hello” contient l’ASN de l’expéditeur ainsi que les TLV composés d’une adresse de connexion du peer, l’ID de routeur, etc.
L’existence de deux projets actifs de l’IETF sur la fonctionnalité “BGP neighbor auto-discovery” nous prouve l’importance de ce sujet actuellement. Le projet initial “BGP Neighbor Autodiscovery” est apparu pour la première fois en décembre 2016, tandis que le projet “BGP LLDP Peer Discovery” en mars 2017. Ces projets sont actuellement loin d’être déployés car les deux sont toujours dans l’état initial “I-D Exist”. Les documents ne sont pas suivis par l’Internet Engineering Steering Group (IESG), car aucune demande n’a encore été envoyée au groupe. Cependant, quel que soit le projet qui sera mis en œuvre par les constructeurs dans le futur, la fonctionnalité “BGP peer discovery” est sans aucun doute une demande légitime.
Accéder à la version anglaise de cet article – BGP LLDP Peer Discovery
Boost BGP Performance
Automate BGP Routing optimization with Noction IRP
SUBSCRIBE TO NEWSLETTER
You May Also Like
La configuration BGP a l’aide du GRE Tunnel
Dans cet article, nous allons expliquer comment le tunnel Generic Routing Encapsulation (GRE) peut être utilisé dans...
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....
L’évolution des méthodes de surveillance des flux réseau, de NetFlow à IPFIX
La surveillance des flux réseau est un outil essentiel pour de nombreux administrateurs réseau. La surveillance des...