6. BGP Error Handling (Gestion des erreurs BGP)

BGP Error Handling (Gestion des erreurs BGP)

Cette section décrit les actions à entreprendre lorsque des erreurs sont détectées lors du traitement des messages BGP.

Lorsque l'une des conditions décrites ici est détectée, un message NOTIFICATION, avec le code d'erreur, le sous-code d'erreur et les champs de données indiqués, est envoyé, et la connexion BGP est fermée (sauf s'il est explicitement indiqué qu'aucun message NOTIFICATION ne doit être envoyé et que la connexion BGP ne doit pas être fermée). Si aucun sous-code d'erreur n'est spécifié, alors zéro doit (MUST) être utilisé.

L'expression "la connexion BGP est fermée" signifie que la connexion TCP a été fermée, l'Adj-RIB-In associé a été effacé et toutes les ressources pour cette connexion BGP ont été désallouées. Les entrées dans le Loc-RIB associées au pair distant sont marquées comme invalides. Le système local recalcule ses meilleures routes pour les destinations des routes marquées comme invalides. Avant que les routes invalides ne soient supprimées du système, il annonce à ses pairs soit des retraits pour les routes marquées comme invalides, soit les nouvelles meilleures routes avant que les routes invalides ne soient supprimées du système.

Sauf indication explicite, le champ Data du message NOTIFICATION envoyé pour indiquer une erreur est vide.

6.1. Message Header Error Handling (Gestion des erreurs d'en-tête de message)

Toutes les erreurs détectées lors du traitement de l'en-tête de message doivent (MUST) être indiquées en envoyant le message NOTIFICATION avec le code d'erreur Message Header Error. Le sous-code d'erreur précise la nature spécifique de l'erreur.

La valeur attendue du champ Marker de l'en-tête de message est tous les uns. Si le champ Marker de l'en-tête de message n'est pas comme prévu, alors une erreur de synchronisation s'est produite et le sous-code d'erreur doit (MUST) être défini sur Connection Not Synchronized.

Si au moins l'une des conditions suivantes est vraie:

si le champ Length de l'en-tête de message est inférieur à 19 ou supérieur à 4096, ou
si le champ Length d'un message OPEN est inférieur à la longueur minimale du message OPEN, ou
si le champ Length d'un message UPDATE est inférieur à la longueur minimale du message UPDATE, ou
si le champ Length d'un message KEEPALIVE n'est pas égal à 19, ou
si le champ Length d'un message NOTIFICATION est inférieur à la longueur minimale du message NOTIFICATION,

alors le sous-code d'erreur doit (MUST) être défini sur Bad Message Length. Le champ Data doit (MUST) contenir le champ Length erroné.

Si le champ Type de l'en-tête de message n'est pas reconnu, alors le sous-code d'erreur doit (MUST) être défini sur Bad Message Type. Le champ Data doit (MUST) contenir le champ Type erroné.

6.2. OPEN Message Error Handling (Gestion des erreurs de message OPEN)

Toutes les erreurs détectées lors du traitement du message OPEN doivent (MUST) être indiquées en envoyant le message NOTIFICATION avec le code d'erreur OPEN Message Error. Le sous-code d'erreur précise la nature spécifique de l'erreur.

Si le numéro de version dans le champ Version du message OPEN reçu n'est pas pris en charge, alors le sous-code d'erreur doit (MUST) être défini sur Unsupported Version Number. Le champ Data est un entier non signé de 2 octets, qui indique le plus grand numéro de version pris en charge localement inférieur à la version proposée par le pair BGP distant (comme indiqué dans le message OPEN reçu), ou si le plus petit numéro de version pris en charge localement est supérieur à la version proposée par le pair BGP distant, alors le plus petit numéro de version pris en charge localement.

Si le champ Autonomous System du message OPEN est inacceptable, alors le sous-code d'erreur doit (MUST) être défini sur Bad Peer AS. La détermination des numéros de système autonome acceptables est en dehors du champ d'application de ce protocole.

Si le champ Hold Time du message OPEN est inacceptable, alors le sous-code d'erreur doit (MUST) être défini sur Unacceptable Hold Time. Une implémentation doit (MUST) rejeter les valeurs Hold Time d'une ou deux secondes. Une implémentation peut (MAY) rejeter toute Hold Time proposée. Une implémentation qui accepte une Hold Time doit (MUST) utiliser la valeur négociée pour la Hold Time.

Si le champ BGP Identifier du message OPEN est syntaxiquement incorrect, alors le sous-code d'erreur doit (MUST) être défini sur Bad BGP Identifier. L'exactitude syntaxique signifie que le champ BGP Identifier représente une adresse d'hôte IP unicast valide.

Si l'un des paramètres optionnels du message OPEN n'est pas reconnu, alors le sous-code d'erreur doit (MUST) être défini sur Unsupported Optional Parameters.

Si l'un des paramètres optionnels du message OPEN est reconnu, mais est malformé, alors le sous-code d'erreur doit (MUST) être défini sur 0 (Unspecific).

6.3. UPDATE Message Error Handling (Gestion des erreurs de message UPDATE)

Toutes les erreurs détectées lors du traitement du message UPDATE doivent (MUST) être indiquées en envoyant le message NOTIFICATION avec le code d'erreur UPDATE Message Error. Le sous-code d'erreur précise la nature spécifique de l'erreur.

La vérification des erreurs d'un message UPDATE commence par l'examen des attributs de chemin. Si Withdrawn Routes Length ou Total Attribute Length est trop grand (c'est-à-dire si Withdrawn Routes Length + Total Attribute Length + 23 dépasse la longueur du message), alors le sous-code d'erreur doit (MUST) être défini sur Malformed Attribute List.

Si un attribut reconnu a des drapeaux d'attribut qui sont en conflit avec le code de type d'attribut, alors le sous-code d'erreur doit (MUST) être défini sur Attribute Flags Error. Le champ Data doit (MUST) contenir l'attribut erroné (type, longueur et valeur).

Si un attribut reconnu a une longueur d'attribut qui est en conflit avec la longueur attendue (basée sur le code de type d'attribut), alors le sous-code d'erreur doit (MUST) être défini sur Attribute Length Error. Le champ Data doit (MUST) contenir l'attribut erroné (type, longueur et valeur).

Si l'un des attributs bien connus obligatoires n'est pas présent, alors le sous-code d'erreur doit (MUST) être défini sur Missing Well-known Attribute. Le champ Data doit (MUST) contenir le code de type d'attribut de l'attribut bien connu manquant.

Si l'un des attributs bien connus obligatoires n'est pas reconnu, alors le sous-code d'erreur doit (MUST) être défini sur Unrecognized Well-known Attribute. Le champ Data doit (MUST) contenir l'attribut non reconnu (type, longueur et valeur).

Si l'attribut ORIGIN a une valeur non définie, alors le sous-code d'erreur doit (MUST) être défini sur Invalid Origin Attribute. Le champ Data doit (MUST) contenir l'attribut non reconnu (type, longueur et valeur).

Si le champ d'attribut NEXT_HOP est syntaxiquement incorrect, alors le sous-code d'erreur doit (MUST) être défini sur Invalid NEXT_HOP Attribute. Le champ Data doit (MUST) contenir l'attribut incorrect (type, longueur et valeur). L'exactitude syntaxique signifie que l'attribut NEXT_HOP représente une adresse d'hôte IP valide.

L'adresse IP dans NEXT_HOP doit (MUST) répondre aux critères suivants pour être considérée comme sémantiquement correcte:

a) Elle ne doit (MUST) pas être l'adresse IP du haut-parleur récepteur.

b) Dans le cas d'un EBGP, où l'émetteur et le récepteur sont à un saut IP l'un de l'autre, soit l'adresse IP dans NEXT_HOP doit (MUST) être l'adresse IP de l'émetteur utilisée pour établir la connexion BGP, soit l'interface associée à l'adresse IP NEXT_HOP doit (MUST) partager un sous-réseau commun avec le haut-parleur BGP récepteur.

Si l'attribut NEXT_HOP est sémantiquement incorrect, l'erreur devrait (SHOULD) être enregistrée, et la route devrait (SHOULD) être ignorée. Dans ce cas, un message NOTIFICATION ne devrait (SHOULD) pas être envoyé, et la connexion ne devrait (SHOULD) pas être fermée.

L'attribut AS_PATH est vérifié pour l'exactitude syntaxique. Si le chemin est syntaxiquement incorrect, alors le sous-code d'erreur doit (MUST) être défini sur Malformed AS_PATH.

Si le message UPDATE est reçu d'un pair externe, le système local peut (MAY) vérifier si l'AS le plus à gauche (par rapport à la position des octets dans le message de protocole) dans l'attribut AS_PATH est égal au numéro de système autonome du pair qui a envoyé le message. Si la vérification détermine que ce n'est pas le cas, le sous-code d'erreur doit (MUST) être défini sur Malformed AS_PATH.

Si un attribut optionnel est reconnu, alors la valeur de cet attribut doit (MUST) être vérifiée. Si une erreur est détectée, l'attribut doit (MUST) être rejeté, et le sous-code d'erreur doit (MUST) être défini sur Optional Attribute Error. Le champ Data doit (MUST) contenir l'attribut (type, longueur et valeur).

Si un attribut apparaît plus d'une fois dans le message UPDATE, alors le sous-code d'erreur doit (MUST) être défini sur Malformed Attribute List.

Le champ NLRI dans le message UPDATE est vérifié pour la validité syntaxique. Si le champ est syntaxiquement incorrect, alors le sous-code d'erreur doit (MUST) être défini sur Invalid Network Field.

Si un préfixe dans le champ NLRI est sémantiquement incorrect (par exemple, une adresse IP multicast inattendue), une erreur devrait (SHOULD) être enregistrée localement, et le préfixe devrait (SHOULD) être ignoré.

Un message UPDATE qui contient des attributs de chemin corrects, mais pas de NLRI, doit (SHALL) être traité comme un message UPDATE valide.

6.4. NOTIFICATION Message Error Handling (Gestion des erreurs de message NOTIFICATION)

Si un pair envoie un message NOTIFICATION, et que le récepteur du message détecte une erreur dans ce message, le récepteur ne peut pas utiliser un message NOTIFICATION pour signaler cette erreur au pair. Toute erreur de ce type (par exemple, un code d'erreur ou un sous-code d'erreur non reconnu) devrait (SHOULD) être remarquée, enregistrée localement et portée à l'attention de l'administration du pair. Les moyens pour ce faire, cependant, sont en dehors du champ d'application de ce document.

6.5. Hold Timer Expired Error Handling (Gestion des erreurs d'expiration du temporisateur Hold)

Si un système ne reçoit pas de messages KEEPALIVE, UPDATE et/ou NOTIFICATION successifs dans la période spécifiée dans le champ Hold Time du message OPEN, alors le message NOTIFICATION avec le code d'erreur Hold Timer Expired est envoyé et la connexion BGP est fermée.

6.6. Finite State Machine Error Handling (Gestion des erreurs de machine à états finis)

Toute erreur détectée par la machine à états finis BGP (par exemple, réception d'un événement inattendu) est indiquée en envoyant le message NOTIFICATION avec le code d'erreur Finite State Machine Error.

6.7. Cease (Cessation)

En l'absence de toute erreur fatale (indiquée dans cette section), un pair BGP peut (MAY) choisir, à tout moment, de fermer sa connexion BGP en envoyant le message NOTIFICATION avec le code d'erreur Cease. Cependant, le message NOTIFICATION Cease ne doit (MUST) pas être utilisé lorsqu'une erreur fatale indiquée par cette section existe.

Un haut-parleur BGP peut (MAY) prendre en charge la capacité d'imposer une limite supérieure configurée localement sur le nombre de préfixes d'adresse que le haut-parleur est prêt à accepter d'un voisin. Lorsque la limite supérieure est atteinte, le haut-parleur, sous le contrôle de la configuration locale, soit (a) rejette les nouveaux préfixes d'adresse du voisin (tout en maintenant la connexion BGP avec le voisin), soit (b) termine la connexion BGP avec le voisin. Si le haut-parleur BGP décide de terminer sa connexion BGP avec un voisin parce que le nombre de préfixes d'adresse reçus du voisin dépasse la limite supérieure configurée localement, alors le haut-parleur doit (MUST) envoyer au voisin un message NOTIFICATION avec le code d'erreur Cease. Le haut-parleur peut (MAY) également enregistrer cela localement.

6.8. BGP Connection Collision Detection (Détection de collision de connexion BGP)

Si une paire de haut-parleurs BGP tente d'établir une connexion BGP l'un avec l'autre simultanément, alors deux connexions parallèles seront formées. Si l'adresse IP source utilisée par l'une de ces connexions est la même que l'adresse IP de destination utilisée par l'autre, et que l'adresse IP de destination utilisée par la première connexion est la même que l'adresse IP source utilisée par l'autre, une collision de connexion s'est produite. En cas de collision de connexion, l'une des connexions doit (MUST) être fermée.

Sur la base de la valeur de l'identifiant BGP, une convention est établie pour détecter quelle connexion BGP doit être préservée lorsqu'une collision se produit. La convention consiste à comparer les identifiants BGP des pairs impliqués dans la collision et à ne conserver que la connexion initiée par le haut-parleur BGP avec l'identifiant BGP de valeur supérieure.

À la réception d'un message OPEN, le système local doit (MUST) examiner toutes ses connexions qui sont dans l'état OpenConfirm. Un haut-parleur BGP peut (MAY) également examiner les connexions dans un état OpenSent s'il connaît l'identifiant BGP du pair par des moyens extérieurs au protocole. Si, parmi ces connexions, il existe une connexion à un haut-parleur BGP distant dont l'identifiant BGP est égal à celui du message OPEN, et que cette connexion entre en collision avec la connexion sur laquelle le message OPEN est reçu, alors le système local effectue la procédure de résolution de collision suivante:

L'identifiant BGP du système local est comparé à l'identifiant BGP du système distant (tel que spécifié dans le message OPEN). La comparaison des identifiants BGP se fait en les convertissant en ordre d'octets de l'hôte et en les traitant comme des entiers non signés de 4 octets.
Si la valeur de l'identifiant BGP local est inférieure à celle du distant, le système local ferme la connexion BGP qui existe déjà (celle qui est déjà dans l'état OpenConfirm), et accepte la connexion BGP initiée par le système distant.
Sinon, le système local ferme la connexion BGP nouvellement créée (celle associée au message OPEN nouvellement reçu), et continue à utiliser celle existante (celle qui est déjà dans l'état OpenConfirm).

Sauf autorisation par configuration, une collision de connexion avec une connexion BGP existante qui est dans l'état Established provoque la fermeture de la connexion nouvellement créée.

Notez qu'une collision de connexion ne peut pas être détectée avec des connexions qui sont dans les états Idle, Connect ou Active.

La fermeture de la connexion BGP (résultant de la procédure de résolution de collision) est accomplie en envoyant le message NOTIFICATION avec le code d'erreur Cease.