XOps Network Playbook - Session BGP Déconnectée

Ce playbook décrit les étapes pour résoudre les problèmes lorsqu'une session BGP se déconnecte pour un site.

Vue d'ensemble

Lorsqu'une session BGP est déconnectée, la connexion entre deux routeurs BGP est terminée et peut perturber l'échange des informations de routage. L'impact de la session déconnectée peut varier en fonction de la redondance du réseau et des mécanismes de basculement. Dans les scénarios où des chemins alternatifs existent, l'impact peut être minime. Cependant, dans des configurations moins résilientes, les déconnexions peuvent entraîner des problèmes de routage temporaires et des interruptions de service.

Pour plus d'informations sur BGP, veuillez consulter Utilisation de BGP dans le Cato Cloud.

Il existe différentes manières de découvrir qu'une session BGP a été déconnectée pour un site :

Allez sur la page Atelier des Histoires et utilisez le preset Network XDR pour trouver les histoires Session BGP déconnectée.

L'histoire fournit des informations sur la chronologie de l'incident, le statut actuel du Socket, et plus encore.
Un événement de routage, avec le sous-Type de session BGP avec l'action Déconnecté
- Utilisez le filtre prédéfini Paires BGP déconnectées et ajustez la plage de temps si nécessaire

Notification par email BGP
- Lorsque les notifications par email sont activées pour un pair BGP, des emails sont envoyés à la liste de diffusion (peut inclure des non-administrateurs)

Lors de la réponse aux histoires des Opérations de Site, il est important d'aborder le problème en vérifiant d'abord que le problème est en cours, puis en dépannant le problème et enfin en vérifiant que le problème est résolu.

Étape 1 - Vérification que la session BGP est déconnectée

Cette section discute des différents outils Cato que vous pouvez utiliser pour vérifier que la session BGP pour un site est déconnectée, et quelle peut être la cause racine.

Affichage du statut BGP

Ceci est un exemple de statut pour une session BGP déconnectée :

Affichage des routes BGP

Utilisez l'Application de Gestion Cato pour voir le tableau de routage du compte (Surveillance > Tableau de Routage). Vous pouvez filtrer par le nom du site en question.

L'exemple ci-dessous montre qu'aucune route DYNAMIQUE n'est incluse dans le tableau de routage, ce qui implique qu'aucune route n'est apprise des pairs BGP :

Vérification du statut de déconnexion BGP pour les sites Cloud Interconnect

Pour les sites Cloud Interconnect, BGP est utilisé pour la connectivité entre le sous-réseau de l'environnement cloud et les PoPs.

Dans la page Cloud Interconnect pour le site (Réseau > Sites > {nom du site} > Configuration du Site > Cloud Interconnect), cliquez sur Tester la Connectivité pour montrer le statut BGP du sous-réseau
Dans la page Sites, examinez le statut du site

Étape 2 - Dépannage du statut BGP déconnecté

Cette section discute des outils au sein de Cato qui peuvent être utilisés pour suivre une approche de dépannage structurée pour ce type d'incident. Ces étapes devraient être suivies généralement dans l'ordre mais les résultats de ces vérifications peuvent déterminer quelle pourrait être la prochaine étape.

Raison de Déconnexion de la Session BGP à Préciser

La page Événements de l'Application de Gestion Cato (Accueil > Événements) peut être utilisée pour clarifier la raison pour laquelle la session BGP a été déconnectée.

En utilisant le preset Paires BGP déconnectées, vous pouvez voir un historique de toutes les sessions BGP déconnectées dans votre plage de temps sélectionnée. Ces événements ont également un code d'erreur de déconnexion BGP associé, ce qui peut clarifier la raison de la déconnexion :

Assurez-vous qu'aucune Modification n'a eu Lieu avant cet Incident

Examinez les modifications dans la page de Suivi d'Audit de l'Application de Gestion Cato, et voyez s'il y a une configuration qui est liée à ce problème. Si une modification de configuration a directement précédé cet incident, envisagez de la rétablir et de confirmer quelle devrait être la configuration.

Vérifiez que la Configuration BGP est Correcte

Utilisez l'Application de Gestion Cato pour afficher le statut en temps réel de la session BGP. Dans la page BGP pour le site (Réseau > Sites > {nom du site} > Configuration du Site > BGP), cliquez sur Afficher le statut BGP, puis Statut Brut. Ce statut détaillé liste également les paramètres de configuration. Ceux-ci devraient être vérifiés pour s'assurer que la configuration correcte est appliquée.

Redémarrage Doux de la Configuration

Une fois que vous avez vérifié que le voisin BGP de secours est déconnecté, vous pouvez changer l'un des voisins BGP et cliquer sur Enregistrer. Cela pousse une nouvelle configuration qui peut résoudre le problème. Ensuite, rétablissez les paramètres d'origine et enregistrez la configuration d'origine.

Vérifiez que le Trafic du Protocole BGP est Bidirectionnel entre les Paires

Pour qu'une session BGP soit établie et fonctionne, il doit y avoir un trafic bidirectionnel sur le port TCP 179 du BGP. En utilisant les captures de paquets Cato, la bidirectionnalité de ce trafic peut être examinée et vérifiée.

Pour les sites socket, prenez une capture de paquet (PCAP) sur l'interface LAN du Socket (le port utilisé pour le trafic BGP). Pour plus d'informations, consultez Comment prendre une capture de paquets sur un Socket.

Filtrez le PCAP pour le port 179. Si le trafic est bidirectionnel, assurez-vous que la poignée de main en 3 temps TCP se termine avec succès.
Si la poignée de main se termine avec succès mais que la session n'est toujours pas établie, il est probable qu'une erreur soit signalée par l'un des pairs. Ces erreurs devraient être visibles sur la capture de paquets. Les erreurs signalées devraient être des erreurs standard BGP et peuvent donc être examinées plus en profondeur en vérifiant la documentation des erreurs BGP.
Si le trafic est unidirectionnel, provenant du socket mais non renvoyé par le pair, continuez à la section suivante pour enquêter sur l'accessibilité de la couche 3.

Pour les sites IPSEC, veuillez vous référer aux étapes de capture de paquets mises en évidence dans le Playbook de Dépannage de la Connectivité IPsec.

Vérifiez l'Accessibilité de la Couche 3 au Pair

Utilisez la page Hôtes connus pour le site pour examiner la dernière fois qu'il y a eu une activité pour un hôte. Ceci fournit plus d'informations sur le moment des problèmes de connectivité et de la session BGP.

Ping du pair BGP pour tester l'accessibilité

Pour les sites socket, vous pouvez utiliser l'interface Web du Socket pour ping le pair BGP depuis l'interface LAN, assurez-vous que le pair BGP autorise le trafic ICMP. Pour plus d'informations, consultez Utilisation des Outils WebUI du Socket.

Depuis l'interface Web du Socket, ping l'hôte avec ces paramètres :
- Route via - LAN
- Nom d'hôte/IP - Adresse IP du pair BGP
- Échecs - Le routeur BGP n'est pas accessible, le problème n'est pas lié au Cato Cloud
- Réussites - Il y a un problème entre le PoP et le routeur BGP
  
  Ce sont des conclusions d'exemple basées sur les résultats du ping :

Pour BGP sur des sites IPSEC, vous pouvez suivre la procédure décrite dans Dépannage de la Connectivité IPsec afin d'obtenir des captures de paquets. Une source valide pour le ping est tout hôte sur le réseau étendu qui devrait pouvoir atteindre l'adresse du pair BGP via ICMP.

Étape 3 - Vérification que le statut BGP déconnecté est résolu

Affichage de l'événement de Session BGP Établie

Après que le voisin BGP est connecté au site, un événement de session BGP est généré avec l'Action Établie. Dans la page Événements, vous pouvez configurer manuellement le filtre d'événement pour Action EST Établie pour montrer l'événement.

Test du Statut BGP

Le statut en temps réel de la session BGP montre le statut et les informations de routage. Dans la page BGP pour le site (Réseau > Sites > {nom du site} > Configuration du Site > BGP), cliquez sur Afficher le statut BGP.

Assurer que tous les préfixes sont reçus