Présentation de BGP

Cette section traite des sujets suivants :

• Systèmes autonomes
• Chemins et attributs AS
• BGP externe et interne
• Plusieurs instances de BGP
• Autoriser le trafic de protocole pour les interfaces dans une zone de Sécurité

BGP externe et interne

Le BGP prend en charge deux types d’échanges d’informations de routage : les échanges entre différents AS et les échanges au sein d’un seul AS. Lorsqu’il est utilisé par des AS, le protocole BGP est appelé BGP externe (EBGP) et les sessions BGP effectuent un routage inter-AS. Lorsqu’il est utilisé dans un AS, BGP est appelé BGP interne (IBGP) et les sessions BGP effectuent un routage intra-AS. La figure 1 illustre les AS, IBGP et EBGP.

Figure 1 : AS, EBGP et IBGP

Un système BGP partage des informations d’accessibilité du réseau avec des systèmes BGP adjacents , appelés voisins ou pairs.

Les systèmes BGP sont organisés en groupes. Dans un groupe IBGP, tous les pairs du groupe, appelés pairs internes, sont dans le même AS. Les pairs internes peuvent se trouver n’importe où dans l’AS local et n’ont pas besoin d’être directement connectés les uns aux autres. Les groupes internes utilisent des routes à partir d’un IGP pour résoudre les adresses de transfert. Ils propagent également les routes externes parmi tous les autres routeurs internes exécutant IBGP, en calculant le saut suivant en prenant le saut suivant BGP reçu avec la route et en le résolvant à l’aide des informations de l’un des protocoles de passerelle intérieure.

Dans un groupe EBGP, les pairs du groupe, appelés homologues externes, se trouvent dans des AS différents et partagent normalement un sous-réseau. Dans un groupe externe, le saut suivant est calculé par rapport à l’interface partagée entre l’homologue externe et le routeur local.

Une route BGP est une destination, décrite comme un préfixe d’adresse IP, et une information qui décrit le chemin vers la destination.

Les informations suivantes décrivent le chemin :

• AS chemin, qui est une liste de numéros des AS qu’un itinéraire traverse pour atteindre le routeur local. Le premier numéro du chemin est celui du dernier AS du chemin, l’AS le plus proche du routeur local. Le dernier numéro du chemin est l’AS le plus éloigné du routeur local, qui est généralement l’origine du chemin.

• Attributs de chemin, qui contiennent des informations supplémentaires sur le chemin AS utilisé dans la politique de routage.

Les homologues BGP annoncent des routes les uns vers les autres dans les messages de mise à jour.

BGP stocke ses routes dans la table de routage de Junos OS (inet.0). La table de routage stocke les informations suivantes sur les routes BGP :

• Informations de routage apprises à partir des messages de mise à jour reçus des pairs

• Informations de routage local que BGP applique aux routes en raison de stratégies locales

• Informations que BGP communique aux homologues BGP dans les messages de mise à jour

Pour chaque préfixe de la table de routage, le processus de protocole de routage sélectionne un seul meilleur chemin, appelé chemin actif. À moins que vous ne configuriez BGP pour annoncer plusieurs chemins vers la même destination, BGP annonce uniquement le chemin actif.

Le routeur BGP qui annonce une route en premier lui attribue l’une des valeurs suivantes pour identifier son origine. Lors de la sélection du routage, la valeur d’origine la plus basse est préférée.

• 0 : le routeur a initialement appris la route via un IGP (OSPF, IS-IS ou route statique).

• 1—Le routeur a initialement appris la route via un EGP (très probablement BGP).

• 2 : l'origine de la route est inconnue.

Un BGP interne (IBGP) avec une adresse de saut suivant vers un voisin BGP distant (prochain saut de protocole) doit voir son saut suivant résolu à l’aide d’un autre itinéraire. BGP ajoute cette route au module de résolution RPD pour la résolution du saut suivant. Si RSVP est utilisé dans le réseau, le saut suivant BGP est résolu à l’aide de la route entrante RSVP. Ainsi, la route BGP pointe vers un saut suivant indirect et le saut suivant indirect pointe vers un saut suivant de transfert. Le saut suivant de transfert est dérivé du saut suivant de route RSVP. Il existe souvent un grand ensemble de routes BGP internes qui ont le même protocole next hop, et dans ce cas, l’ensemble des routes BGP fait référence au même saut suivant indirect.

Avant la version 17.2R1 de Junos OS, le module de résolution du processus de protocole de routage (rpd) résolvait les routes au sein des routes reçues par IBGP de la manière suivante :

1. Résolution de route partielle : le saut suivant du protocole est résolu en fonction des routes d’assistance, telles que les routes RSVP ou IGP. Les valeurs de métrique sont dérivées des routes d’assistance, et le saut suivant est appelé le résolveur transférant le saut suivant hérité des routes d’assistance. Ces valeurs de mesure sont utilisées pour sélectionner des routes dans la base d’informations de routage (RIB), également appelée table de routage.

2. Résolution de route complète : le dernier saut suivant est dérivé et est appelé la table de routage du noyau (KRT) transférant le saut suivant en fonction de la stratégie d’exportation de transfert.

À partir de la version 17.2R1 de Junos OS, le module de résolution de rpd est optimisé pour augmenter le débit du flux de traitement entrant, accélérant ainsi le taux d’apprentissage du RIB et de la FIB. Avec cette amélioration, la résolution de la route est affectée comme suit :

• Les méthodes de résolution de route partielle et complète sont déclenchées pour chaque route IBGP, bien que chaque route puisse hériter du même transfert résolu du saut suivant ou du même KRT pour le transfert des sauts suivants.

• La sélection du chemin BGP est reportée jusqu’à ce que la résolution complète du routage soit effectuée pour les informations d’accessibilité de la couche réseau (NLRI) reçues d’un voisin BGP, qui peut ne pas être la meilleure route dans le RIB après la sélection du chemin.

Les avantages de l’optimisation du résolveur RPD incluent :

• Coût de recherche de résolution RIB inférieur : la sortie du chemin résolu est enregistrée dans un cache de résolveur, de sorte que les mêmes valeurs dérivées de saut suivant et de métrique peuvent être héritées vers un autre ensemble de routes partageant le même comportement de chemin au lieu d’effectuer un flux de résolution de route partiel et complet. Cela réduit le coût de recherche de résolution de route en ne conservant que l’état de résolveur le plus fréquent dans un cache avec une profondeur limitée.

• Optimisation de la sélection de route BGP : l’algorithme de sélection de route BGP est déclenché deux fois pour chaque route IBGP reçue, d’abord lors de l’ajout de la route dans le RIB avec le saut suivant comme inutilisable, puis lors de l’ajout de la route avec un saut suivant résolu dans le RIB (après résolution de la route). Cela permet de sélectionner deux fois le meilleur itinéraire. Avec l’optimisation du résolveur, le processus de sélection de route n’est déclenché dans le flux de réception qu’après avoir obtenu les informations du saut suivant du module de résolveur.

• Mise en cache interne pour éviter les recherches fréquentes : le cache du résolveur conserve l’état du résolveur le plus fréquent et, par conséquent, la fonctionnalité de recherche, telle que la recherche de saut suivant et la recherche de route, est effectuée à partir du cache local.

• Groupe d’équivalence de chemin : lorsque différents chemins partagent le même état de transfert ou sont reçus du même protocole au saut suivant, les chemins peuvent appartenir à un groupe d’équivalence de chemin. Cette approche évite d’avoir à effectuer une résolution de route complète pour de tels chemins. Lorsqu’un nouveau chemin nécessite une résolution de routage complète, il est d’abord recherché dans la base de données du groupe d’équivalence de chemin, qui contient la sortie du chemin résolu, telle que le saut suivant indirect et le saut suivant de transfert.

Cette section traite des sujets suivants :

• Messages ouverts
• Messages de mise à jour
• Keepalive Messages
• Notification Messages
• Messages d’actualisation de routage

Le traitement du routage BGP comporte généralement plusieurs étapes de pipeline, telles que la réception des mises à jour, l'analyse des mises à jour, la création de routage, la résolution du saut suivant, l'application de la stratégie d'exportation d'un groupe d'pairs BGP, la formation de mises à jour par pair et l'envoi de mises à jour aux pairs.

BGP sharding RIB divise un RIB BGP unifié en plusieurs sous-RIB et chaque sous-RIB gère un sous-ensemble de routes BGP. Un thread RPD séparé appelé thread de partition BGP sert à chaque sous-RIB par pour obtenir la concurrence. Les threads de partition BGP sont responsables de toutes les étapes du pipeline de traitement de routage BGP, à l’exception de la formation de mises à jour par pair et de l’envoi de mises à jour aux pairs. Les threads de partition BGP reçoivent les mises à jour envoyées par les homologues à partir des threads d’E/S de mise à jour BGP, les threads d’E/S de mise à jour BGP hachent les préfixes dans les mises à jour et envoient les mises à jour aux threads de partition BGP applicables en fonction du calcul de hachage. Le thread de partition BGP traite la configuration de la même manière que le thread principal RPD, crée des pairs, des groupes, des tables de routage et utilise les informations de configuration pour le traitement de la route BGP.

Les threads d’E/S de mise à jour BGP sont responsables de la fin de ce pipeline BGP, ce qui implique la génération de mises à jour par pair pour le(s) groupe(s) BGP(s) individuel(s) et leur envoi au(x) pair(s). Un thread de mise à jour peut servir un ou plusieurs groupes BGP. Les threads d’E/S de mise à jour BGP construisent des mises à jour pour les groupes en parallèle et indépendamment des autres groupes qui sont desservis par d’autres threads de mise à jour. Cela peut offrir une amélioration significative de la convergence dans une charge de travail à forte intensité d’écriture, qui implique de la publicité auprès de nombreux pairs répartis dans de nombreux groupes. Les threads d’E/S de mise à jour BGP sont également responsables de l’écriture et de la lecture à partir des sockets TCP des pairs BGP, ce qui était auparavant fourni par les threads BGPIO (d’où le suffixe IO dans E/S de mise à jour BGP).

Mise à jour BGP Les threads d’E/S peuvent être configurés indépendamment de la fonctionnalité de partitionnement RIB, mais leur utilisation est obligatoire avec le partitionnement RIB afin d’obtenir une meilleure efficacité de compression des préfixes dans le message de mise à jour BGP sortant. Le sharding BGP divise le RIB en plusieurs sous-semi-rigides qui sont desservis par des threads RPD distincts. Par conséquent, les préfixes qui auraient pu faire partie d’une seule mise à jour sortante se retrouvent dans des partitions différentes. Pour pouvoir construire des mises à jour BGP avec des préfixes avec le même attribut sortant qui peuvent appartenir à différents threads de partition RPD, tous les threads de partition envoient des informations de publication compactes pour les préfixes à annoncer à un thread de mise à jour desservant ce groupe pair BGP. Cela permet au thread de mise à jour, desservant ce groupe d’pairs BGP, d’emballer des préfixes avec les mêmes attributs, appartenant potentiellement à différentes partitions dans le même message de mise à jour sortant. Cela minimise le nombre de mises à jour à publier et contribue ainsi à améliorer la convergence. Le thread d’E/S de mise à jour gère les caches locaux des conteneurs d’homopairs, de groupes, de préfixes, de TSI et de RIB.

Le thread de mise à jour BGP et le partitionnement RIB BGP sont désactivés par défaut. Si vous configurez update-threading et rib-sharding sur un moteur de routage, RPD crée des threads de mise à jour. Par défaut, le nombre de threads de mise à jour et de threads de partition créés est le même que le nombre de cœurs de processeur sur le moteur de routage. Le threading de mise à jour n’est pris en charge que sur un processus de protocole de routage (rpd) 64 bits. Vous pouvez également spécifier le nombre de threads que vous souhaitez créer à l’aide d’instructions set update-threading <number-of-threads> and set rib-sharding <number-of-threads> au niveau de la [edit system processes routing bgp] hiérarchie. Pour le thread de mise à jour BGP, la plage est actuellement comprise entre 1 et 128 et pour le partitionnement RIB BGP, la plage est actuellement comprise entre 1 et 31.

Lorsque vous configurez NSR pour les fonctionnalités de partitionnement RIB BGP et d’E/S de mise à jour BGP, le RPD de sauvegarde crée le même nombre de partitions BGP et de threads d’E/S de mise à jour BGP dans le moteur de routage de secours. Les threads d’E/S de mise à jour BGP RPD de sauvegarde lisent la mise à jour BGP répliquée, les autres messages reçus des homologues ainsi que la mise à jour BGP répliquée et les autres messages envoyés aux pairs. En se basant sur le hachage des préfixes, les threads d’E/S de mise à jour BGP RPD de sauvegarde envoient ces messages BGP aux threads principaux de partition et RPD BGP applicables. La partition BGP et les threads principaux RPD dans le RPD de secours créent l’état de routage reçu et annoncé à l’aide de ces messages BGP répliqués. Lorsque le moteur de routage principal tombe en panne, le moteur de routage de secours devient le moteur de routage principal et le RPD de secours devient le RPD principal de manière transparente sans affecter les sessions BGP avec les pairs.

Pour chaque préfixe de la table de routage, le processus de protocole de routage sélectionne un seul meilleur chemin. Une fois le meilleur chemin sélectionné, l’itinéraire est installé dans la table de routage. Le meilleur chemin devient la route active si le même préfixe n’est pas appris par un protocole avec une valeur de préférence globale plus faible (plus préférée), également appelée distance administrative. L’algorithme de détermination de l’itinéraire actif est le suivant :

1. Vérifiez que le saut suivant peut être résolu.

2. Choisissez le chemin avec la valeur de préférence la plus faible (préférence de processus du protocole de routage).

   Les routes qui ne peuvent pas être utilisées pour le transfert (par exemple, parce qu’elles ont été rejetées par la politique de routage ou parce qu’un saut suivant est inaccessible) ont une préférence de –1 et ne sont jamais choisies.

3. Préférez le chemin avec une préférence locale plus élevée.

   Pour les chemins non-BGP, choisissez le chemin avec la valeur preference2 la plus faible.

4. Si l’attribut AIGP (Interior Gateway Protocol) accumulé est activé, ajoutez la métrique IGP et préférez le chemin avec l’attribut AIGP inférieur.

5. Préférez le chemin avec la valeur de chemin de système autonome (AS) la plus courte (ignorée si l’instruction as-path-ignore est configurée).

   Un segment de confédération (séquence ou ensemble) a une longueur de chemin de 0. Un ensemble d’AS a une longueur de chemin de 1.

6. Préférez l’itinéraire avec le code d’origine inférieur.

   Les routes apprises à partir d’un IGP ont un code d’origine inférieur à ceux appris à partir d’un EGP (Exterior Gateway Protocol), et les deux ont des codes d’origine inférieurs à ceux des routes incomplètes (routes dont l’origine est inconnue).

7. Préférez le chemin avec la métrique MED (Multiple Multiple Exit Discriminator) la plus basse.

   Selon que le comportement de sélection de chemin de la table de routage est configuré ou non, il existe deux cas possibles :

   • Si le comportement de sélection de chemin de la table de routage non déterministe n’est pas configuré (c’est-à-dire si l’instruction n’est path-selection cisco-nondeterministic pas incluse dans la configuration BGP), pour les chemins avec les mêmes numéros AS voisins au début du chemin AS, préférez le chemin avec la métrique MED la plus basse. Pour toujours comparer les MED, que les AS homologues des routes comparées soient identiques ou non, incluez l’instruction path-selection always-compare-med .

   • Si le comportement de sélection de chemin de la table de routage non déterministe est configuré (c’est-à-dire que l’instruction path-selection cisco-nondeterministic est incluse dans la configuration BGP), préférez le chemin avec la métrique MED la plus faible.

   Les confédérations ne sont pas prises en compte pour déterminer les AS voisins. Une métrique MED manquante est traitée comme si une MED était présente mais nulle.

   Remarque :

   La comparaison MED fonctionne pour la sélection d’un chemin unique dans un AS (lorsque la route n’inclut pas de chemin AS), bien que cette utilisation soit rare.

   Par défaut, seuls les MED des routes qui ont les mêmes systèmes autonomes (AS) homologues sont comparés. Vous pouvez configurer les options de sélection de chemin de la table de routage pour obtenir différents comportements.

8. Préférez les chemins strictement internes, qui incluent des routes IGP et des routes générées localement (statiques, directes, locales, etc.).

9. Préférez les chemins BGP (EBGP) strictement externes aux chemins externes appris par le biais de sessions BGP internes (IBGP).

10. Préférez le chemin dont le saut suivant est résolu via la route IGP avec la métrique la plus faible. Les routes BGP résolues par le biais d’IGP sont préférées aux routes inaccessibles ou rejetées.

    Remarque :

    Un chemin est considéré comme un chemin à coût égal BGP (et sera utilisé pour le transfert) si un tie-break est effectué après l’étape précédente. Tous les chemins avec le même AS voisin, appris par un voisin BGP compatible avec les chemins multichemins, sont pris en compte.

    Le multichemin BGP ne s’applique pas aux chemins qui partagent le même coût MED-plus-IGP, mais dont le coût IGP diffère. La sélection des chemins multichemins est basée sur la métrique de coût IGP, même si deux chemins ont le même coût MED-plus-IGP.

11. Si les deux chemins sont externes, préférez le chemin le plus ancien, c’est-à-dire le chemin qui a été appris en premier. Ceci est fait pour minimiser les instabilités de route. Cette règle n’est pas utilisée si l’une des conditions suivantes est vraie :

    • path-selection external-router-id est configuré.

    • Les deux pairs ont le même ID de routeur.

    • L’un ou l’autre des pairs est un pair de la Confédération.

    • Aucun des chemins n’est le chemin actif actuel.

12. Préférez le chemin à partir de l’homologue avec l’ID de routeur le plus bas. Pour tout chemin avec un attribut d’ID d’origine, remplacez l’ID de routeur par l’ID d’origine lors de la comparaison d’ID de routeur.

13. Préférez le chemin avec la longueur de liste de cluster la plus courte. La longueur est de 0 pour aucune liste.

14. Préférez le chemin à partir de l’homologue avec l’adresse IP homologue la plus basse.

15. Préférez une route principale à une route secondaire. Une route principale est une route qui appartient à la table de routage. Une route secondaire est une route qui est ajoutée à la table de routage par le biais d’une stratégie d’exportation.

• Sélection du chemin de la table de routage
• Sélection du chemin d’accès à la table BGP
• Effets de la publicité sur les chemins multiples vers une destination

Lorsqu’un message de mise à jour BGP comporte des attributs facultatifs inconnus, ces attributs peuvent être mal formés et de nature transitive. Les routeurs ne pouvant pas effectuer de contrôles de malformation, ces attributs inconnus peuvent donc être transférés à d’autres homologues BGP. La diffusion d’attributs mal formés peut provoquer des menaces pour la sécurité du réseau et compromettre les opérations BGP.

La gestion des attributs inconnus BGP améliore la sécurité et la stabilité du réseau en gérant les attributs BGP transitifs facultatifs inconnus au sein du système BGP. Vous pouvez configurer le système BGP pour qu’il supprime ces attributs BGP ou retire des routes portant ces attributs afin d’éviter le risque de propagation d’attributs mal formés ou potentiellement dangereux sur des homologues BGP. Vous pouvez également spécifier des exceptions pour exclure les attributs BGP transitifs facultatifs inconnus sélectionnés qui ne doivent pas être abandonnés ou entraîner l’abandon d’une route. Ces configurations peuvent être appliquées au niveau global ou du groupe BGP, ou à des voisins individuels, ce qui garantit un contrôle complet sur les opérations BGP.

Pour supprimer les attributs BGP ou retirer des routes portant ces attributs, configurez les path-attributes drop (attributes <>) commandes or path-attributes withdraw-routes (attributes <>) .

Pour supprimer les attributs BGP transitifs facultatifs inconnus ou retirer des routes portant ces attributs, configurez les path-attributes drop (unknown-optional-transitive) commandes or path-attributes withdraw-routes (unknown-optional-transitive) .

Pour définir des exceptions afin d’exclure les attributs BGP transitifs facultatifs inconnus sélectionnés, configurez les path-attributes drop (unknown-optional-transitive [except <>]) commandes ou path-attributes withdraw-routes (unknown-optional-transitive [except <>]) .

Les show BGP neighbor commandes and show log messages affichent les attributs BGP transitifs optionnels inconnus configurés pour supprimer ou déclencher des retraits de route, avec un journal détaillé. La visibilité améliorée facilite la gestion et le dépannage efficaces du réseau en assurant la transparence dans la gestion des activités liées aux attributs BGP au sein du système BGP.

Junos OS améliore la résolution des routes de service en routes d’aide multichemin BGP qui utilisent des structures liste-nexthop. Le résolveur de route crée et gère désormais des dépendances internes pour tous les chemins contributeurs dans une route multichemin, permettant une résolution précise et dynamique lorsque les sauts suivants indirects changent, que la route contributive soit active ou inactive.

Cette fonctionnalité améliore la stabilité du routage de service et empêche les chemins de transfert obsolètes dans les réseaux utilisant BGP ECMP avec résolution indirecte par saut suivant.

• Avantages
• Avant de commencer
• Fonctionnement de la fonctionnalité
• Exemple opérationnel
• Référence des commandes CLI
• Limites

Junos OS prend en charge de manière substantielle les RFC et les projets Internet suivants, qui définissent les normes IP version 4 (IPv4) BGP.

Pour obtenir la liste des normes BGP IP version 6 (IPv6) prises en charge, consultez Normes IPv6 prises en charge.

Junos OS BGP prend en charge l’authentification pour les échanges de protocoles (authentification MD5).

• RFC 1745, BGP4/IDRP pour l’interaction IP-OSPF

• RFC 1772, Application du Border Gateway Protocol sur Internet

• RFC 1997, attribut de communautés BGP

• RFC 2283, Extensions multiprotocoles pour BGP-4

• RFC 2385, Protection des sessions BGP via l’option de signature TCP MD5

• RFC 2439, Amortissement des volets de route BGP

• RFC 2545, Utilisation d’extensions multiprotocoles BGP-4 pour le routage IPv6 inter-domaines

• RFC 2796, Réflexion de route BGP – Une alternative à l’IBGP à maillage complet

• RFC 2858, Extensions multiprotocoles pour BGP-4

• RFC 2918, Capacité d’actualisation de route pour BGP-4

• RFC 3065, Confédérations de systèmes autonomes pour BGP

• RFC 3107, Transport des informations d’étiquette dans BGP-4

• RFC 3345, condition d’oscillation de route persistante du Border Gateway Protocol (BGP)

• RFC 3392, Annonce de capacités avec BGP-4

• RFC 4271, A Border Gateway Protocol 4 (BGP-4)

• RFC 4273, Définitions d’objets gérés pour BGP-4

• RFC 4360, attribut de communautés étendues BGP

• RFC 4364, réseaux privés virtuels (VPN) IP BGP/MPLS

• RFC 4456, Réflexion de route BGP : une alternative au BGP interne à maillage intégral (IBGP)

• RFC 4486, Sous-codes pour le message de notification d’arrêt BGP

• RFC 4576, Utilisation d’un bit d’options LSA (Link State Advertisement) pour éviter les boucles dans les réseaux privés virtuels (VPN) IP BGP/MPLS

• RFC 4659, Extension de réseau privé virtuel (VPN) IP BGP-MPLS pour VPN IPv6

• RFC 4632, Classless Inter-domain Routing (CIDR) : Le plan d’attribution et d’agrégation des adresses Internet

• RFC 4684, Distribution de routes contrainte pour le Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS), les réseaux privés virtuels (VPN) IP (Internet Protocol)

• RFC 4724, Mécanisme de redémarrage agréable pour BGP

• RFC 4760, Extensions multiprotocoles pour BGP-4

• RFC 4781, Mécanisme de redémarrage agréable pour BGP avec MPLS

• RFC 4798, Connexion d’îlots IPv6 sur IPv4 MPLS à l’aide de routeurs IPv6 Provider Edge Routers (6PE)

  L’option 4b (redistribution eBGP des routes IPv6 étiquetées d’AS vers l’AS voisin) n’est pas prise en charge.

• RFC 4893, Prise en charge de BGP pour espace numérique AS de quatre octets

• RFC 5004, Évitez les meilleures transitions de chemin BGP d’un externe à un autre

• RFC 5065, Confédérations de systèmes autonomes pour BGP

• RFC 5082, Mécanisme de sécurité TTL généralisé (GTSM)

• RFC 5291, Capacité de filtrage de route sortante pour BGP-4 (prise en charge partielle)

• RFC 5292, Filtre de route sortant basé sur un préfixe d’adresse pour BGP-4 (prise en charge partielle)

  Les équipements exécutant Junos OS peuvent recevoir des messages ORF basés sur des préfixes.

• RFC 5396, Représentation textuelle des numéros de système autonome (AS)

• RFC 5492, Annonce des capacités avec BGP-4

• RFC 5512, L’identifiant de famille d’adresses ultérieures d’encapsulation BGP (SAFI) et l’attribut d’encapsulation de tunnel BGP

• RFC 5549, Publicité des informations d’accessibilité de la couche réseau IPv4 avec un saut suivant IPv6

• RFC 8955, Diffusion des règles de spécification de flux

• RFC 8956, Diffusion des règles de spécification de flux pour IPv6

• RFC 5668, communauté étendue BGP spécifique à l’AS de 4 octets

• RFC 5701, attribut de communauté étendu BGP spécifique à l’adresse IPv6

• RFC 5925, L’option d’authentification TCP

• RFC 6286, Autonomous-System-Wide-Unique BGP Identifier for BGP-4- entièrement conforme

• RFC 6368, Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

• RFC 6774, Distribution de divers chemins BGP

• RFC 6793, Prise en charge de BGP pour l’espace numérique des systèmes autonomes (AS) à quatre octets

• RFC 6810, La ressource RPKI (Public Key Infrastructure) to Router Protocol

• RFC 6811, Validation de l’origine du préfixe BGP

• RFC 6996, Réservation de système autonome (AS) pour usage privé

• RFC 7300, Réservation de numéros du dernier système autonome (AS)

• RFC 7311, Attribut de métrique IGP cumulé pour BGP

• RFC 7404, Utilisation uniquement d’un adressage local de liaison à l’intérieur d’un réseau IPv6

• RFC 7432, Ethernet VPN basé sur BGP MPLS (eVPN)

• RFC 7606, Gestion des erreurs révisée pour les messages BGP UPDATE

• RFC 7611, BGP ACCEPT_OWN Community Attribut

  Nous soutenons la RFC en permettant aux routeurs Juniper d’accepter les routes reçues d’un réflecteur de route avec la accept-own valeur communautaire.

• RFC 7752, Distribution vers le nord des informations d’ingénierie d’état de lien et de trafic (TE) à l’aide de BGP

• RFC 7854, Protocole de surveillance BGP (BMP)

• RFC 7911, Publication de chemins multiples dans BGP

• RFC 8097, État de validation de l’origine du préfixe BGP Communauté étendue

• RFC 8210, La ressource RPKI (Public Key Infrastructure) to Router Protocol, version 1

• RFC 8212, Comportement de propagation de route externe BGP (EBGP) par défaut sans politiques - entièrement conforme

  Exceptions :

  Les comportements de la RFC 8212 ne sont pas implémentés par défaut afin d’éviter toute perturbation de la configuration client existante. Le comportement par défaut est toujours conservé pour accepter et annoncer toutes les routes en ce qui concerne les pairs EBGP.

• RFC 8277, Utilisation de BGP pour lier des étiquettes MPLS à des préfixes d’adresses

• RFC 8326, Arrêt de session BGP fluide

• RFC 8481, Clarifications de la validation de l’origine BGP basée sur l’infrastructure à clé publique de ressource (RPKI)

• RFC 8538, Prise en charge des messages de notification pour le redémarrage fluide de BGP

• RFC 8571, BGP - Annonce de l’état des liens (BGP-LS) des extensions de métriques de performance de l’ingénierie de trafic IGP

• RFC 8584, Framework for Ethernet VPN Designated Forwarder Election extensibilité

• RFC 8642, Comportement des politiques pour les communautés BGP connues

• RFC 8669, Extensions d’identificateur de segment de préfixe Segment Routing pour BGP

• RFC 8810, Révision des procédures d’enregistrement des codes de capacité

• RFC 8814 Signaling Maximum SID Depth (MSD) à l’aide du Border Gateway Protocol - État des liens (prise en charge partielle)

• RFC 8950, Publicité des informations d’accessibilité de la couche réseau IPv4 (NLRI) avec un saut suivant IPv6

• RFC 8955

• RFC 8956

• RFC 9003, communication d’arrêt administratif BGP étendue

• RFC 9012, Attribut d’encapsulation de tunnel BGP

• RFC 9029, Mises à jour de la politique d’allocation pour les registres de paramètres Border Gateway Protocol - État des liens (BGP-LS)

• RFC 9069, Prise en charge du RIB local dans le protocole de surveillance BGP (BMP)

• RFC 9085, Border Gateway Protocol - Extensions d’état de lien (BGP-LS) pour le Segment Routing

• RFC 9117, Procédure de validation révisée pour la diffusion des spécifications de débit BGP. Cela permet aux spécifications de flux d’être créées dans le même système autonome que le pair BGP effectuant la validation.

• RFC 9234, Prévention et détection des fuites de route à l’aide de rôles dans les messages UPDATE et OPEN

• RFC 9384, un sous-code de notification d’arrêt BGP pour la détection de transfert bidirectionnelle (BFD)

• Internet draft draft-idr-rfc8203bis-00, Communication d’arrêt administratif BGP (expire en octobre 2018)

• Internet draft draft-ietf-grow-bmp-adj-rib-out-01, Prise en charge d’adj-RIB-out dans le protocole de surveillance BGP (BMP) (expire le 3 septembre 2018)

• Internet draft draft-ietf-idr-aigp-06, Attribut de métrique IGP cumulé pour BGP (expire en décembre 2011)

• Internet draft draft-ietf-idr-as0-06, Codification du traitement de l’AS 0 (expire en février 2013)

• Internet draft draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (expire en juillet 2013)

• Internet draft draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Extended Community (support partiel) (expire en mai 2011)

  La communauté étendue (état de validation de l’origine) est prise en charge dans la politique de routage de Junos OS. La modification spécifiée dans la procédure de sélection de route n’est pas prise en charge.

• Brouillon Internet draft-kato-bgp-ipv6-link-local-00.txt, appairage BGP4+ à l’aide d’une adresse link-locale IPv6

Les RFC et l’ébauche Internet suivantes ne définissent pas les normes, mais fournissent des informations sur le BGP et les technologies associées. L’IETF les classe diversement comme « expérimentaux » ou « informationnels ».

• RFC 1965, Confédérations de systèmes autonomes pour BGP

• RFC 1966, Réflexion de route BGP : une alternative à l’IBGP à maillage intégral

• RFC 2270, utilisation d’un AS dédié pour les sites hébergés par un seul fournisseur

• RFC 3345, condition d’oscillation de route persistante du Border Gateway Protocol (BGP)

• RFC 3562, Considérations clés en matière de gestion pour l’option de signature TCP MD5

• Brouillon Internet draft-ietf-ngtrans-bgp-tunnel-04.txt, Connexion d’îlots IPv6 à travers des clouds IPv4 avec BGP (expire en juillet 2002)