d)     Erreurs concernant les messages de notification.

Si un système BGP reçoit un message de notification contenant une erreur, il n’y a aucun moyen de reporter cette erreur grâce à un message de notification ultérieur.

e)     Erreur concernant le Hold Timer.

Si un système BGP ne reçoit pas de messages KEEPALIVE et/ou UPDATE et/ou NOTIFICATION dans la période de temps définie par le compteur de retenue dans le champ Hold Time, un message de notification doit être envoyé avec le code erreur Hold Timer Expired Error.

f)        Erreur concernant la Machine à l’état fini.

Chaque erreur concernant la machine à l’état fini se traduit par l’émission d’un message de notification avec pour code erreur Finite State Machine Error.

Voici les différents états finis de la machine :

Nous allons répertorier un par un tous les différents états possibles d’un système BGP et définir toutes les erreurs qui peuvent intervenir lors de ces différents états.

Idle State (état ralenti) : dans cet état, BGP refuse toutes les connexions BGP entrantes. Aucune ressource n’est allouée au système BGP.

En réponse à un événement de début (Start Event), le système local initialise toutes les ressources BGP, déclenche le temporisateur de nouvelle tentative de connexion (ConnectRetry Timer), engage une connexion de transport avec une autre paire BGP, tout en écoutant une connexion éventuelle mise en place par cette paire BGP distante, puis change son état à Connect.

La valeur exacte du ConnectRetry Timer ne concerne que le système BGP local, mais doit être suffisamment importante pour permettre l’initialisation de la connexion TCP.

Si un système BGP détecte une erreur, il ferme la connexion et remet son état sur Idle.

La sortie de l’état Idle demande la génération d’un Start Event ; si un tel événement est généré automatiquement, des erreurs persistantes vont apparaître (le système BGP va sans arrêt vouloir repasser en mode Connect). Pour éviter cela, il ne faut pas générer ce Start Event immédiatement pour une paire qui est repassée en mode Idle dû à une erreur. Dans ce cas, si l’événement Start Event est généré automatiquement, il faut que le temps consécutif entre deux Start Event augmente de manière exponentielle.

Dans l’état Idle, seul le Start Event est pris en compte.

Connect State (état d’attente de connexion) : dans cet état, le système BGP attend que la connexion du protocole de transport soit complet.

Quand la connexion est terminée, le système local remet à zéro le ConnectRetry Timer, complète l’initialisation, envoie un message OPEN à sa paire et change son état sur OpenSent.(message open envoyé)

Si la connexion échoue, le système local redémarre son ConnectRetry Timer, continue d’écouter une connexion entrante par la paire BGP distante et change son état sur Active State.

Si le ConnectRetry Timer expire, le système local redémarre son ConnectRetry Timer, engage une connexion de transport avec la parie BGP distante, continue d’écouter une connexion entrante de la part de la paire BGP distante, et reste en état Attente de connexion (Connect State).

L’événement de début (Start Event) est ignoré dans l’état actif (Active state).

Dans le cas de n’importe quelle autre événement, le système local libère toutes les ressources associées à cette connexion et passe à l’état Idle.