Mon blog

Un très court RFC pour enrichir la liste des codes d'erreur qu'un routeur BGP peut envoyer à son pair en cas de problèmes dans l'automate à états finis du protocole. Cela devrait permettre d'améliorer les messages d'erreur vus par les opérateurs de routeurs.

La section 4.5 du RFC 4271 (qui normalise BGP), indique le mécanismes des codes d'erreur à envoyer à un pair en cas de problèmes. Il y a les codes (1 pour une erreur dans l'en-tête d'un paquet, 2 pour une erreur à l'ouverture d'une session, 3 pour une erreur lors du traitement d'une mise à jour des routes, etc) et les sous-codes, dont la signification dépend du code. Ainsi, lorsque le code vaut 2 (erreur lors d'une ouverture de session BGP entre deux pairs), un sous-code 2 indique que le numéro d'AS du pair n'est pas celui qui était configuré (tcpdump affiche cette erreur avec BGP (NOTIFICATION: error OPEN Message Error, subcode Bad Peer AS). Lorsque le code d'erreur est 3 (erreur lors d'un message UPDATE), le sous-code 2 veut dire, par contre, qu'un attribut BGP envoyé par le pair est inconnu.

Un des codes d'erreur est 5, problème dans l'automate à états finis : typiquement, un message a été reçu alors qu'il n'aurait pas dû l'être, vu l'état actuel de l'automate. Mais ce code 5 n'avait pas de sous-code (cf. RFC 4271, section 6.6) et il était donc difficile de connaître le problème exact. Ce RFC comble ce manque.

Les nouveaux sous-codes sont donc (la liste des états de l'automate est dans le RFC 4271, section 8.2) :

• 0 : erreur non spécifiée (la situation actuelle).
• 1 : message inattendu alors que l'envoyeur de l'erreur était dans l'état OpenSent. Par exemple, si un routeur est dans l'état OpenSent (message OPEN envoyé mais pas encore de réponse favorable) et reçoit un message UPDATE (mise à jour des routes, ne devrait être envoyé que si la session est opérationnelle), alors il renverra un message NOTIFICATION avec le code à 5 et le sous-code à 1.
• 2 : message inattendu alors que l'envoyeur de l'erreur était dans l'état OpenConfirm,
• 3 : message inattendu alors que l'envoyeur de l'erreur était dans l'état Established (session BGP opérationnelle). Ce serait le cas, par exemple, d'un message OPEN reçu dans cet état.

Ces sous-codes sont enregistrés à l'IANA et de nouveaux sous-codes ne pourront être ajoutés que via un RFC sur le chemin des normes (cf. RFC 5226).

L'annonce du RFC notait qu'il existait déjà deux mises en œuvre de ces sous-codes mais j'avoue ignorer desquelles il s'agit.