Introduction
Ce document décrit comment déterminer si les défaillances de voisinage BGP (Border Gateway Protocol) internes ou externes sont causées par des problèmes d'unité de transmission maximale (MTU).
Conditions préalables
Assurez-vous d'effectuer ces tâches sur les deux routeurs BGP avant de terminer les procédures de ce document :
- Vérifiez la configuration BGP.
- Vérifiez que le voisin BGP est accessible via le protocole ICMP (Internet Control Message Protocol) et qu'aucune perte n'est observée.
- Vérifiez que l'interface connectée utilisée pour l'homologue BGP n'est pas surabonnée et ne comporte aucune perte ou erreur d'entrée/sortie.
- Vérifiez l'utilisation du processeur et de la mémoire.
Problème
forme des voisins BGP ; cependant, au moment de l'échange de préfixe, l'état BGP est abandonné et les journaux génèrent des messages de test Hello BGP manquants ou l'autre homologue termine la session.
Complétez ces étapes afin de déterminer si le MTU provoque le battement des voisins BGP :
- Utilisez les commandes ci-dessous afin de vérifier quel voisin est affecté et l'interface connectée sur les deux routeurs BGP. Si l'adresse d'appairage est une adresse de bouclage, vérifiez l'interface connectée par laquelle le bouclage est accessible. Vérifiez également que le BGP OutQ est présent sur les deux routeurs d'appairage. La constante OutQ non nulle indique clairement que les mises à jour n'atteignent pas l'homologue en raison d'un problème de MTU dans le chemin.
Router#show ip bgp summ | in InQ|10.10.10.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.2 4 3 64 62 3 0 0 00:00:3 2
Router#show ip route 10.10.10.2
Routing entry for 10.10.10.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet1/0
Route metric is 0, traffic share count is 1
- Vérifiez le MTU de l'interface des deux côtés :
Router#show ip int g1/0 | i MTU
MTU is 1500 bytes
Router#
- Confirmez le segment de données TCP max convenu pour les deux haut-parleurs BGP :
Router#show ip bgp neigh 20.20.20.2 | inc segment
Datagrams (max data segment is 1460 bytes):
Router#
Dans l'exemple ci-dessus, 1460 est correct car 20 octets sont affectés à l'en-tête TCP et 20 autres à l'en-tête IP.
- Confirmez si BGP utilise path-mtu est activé :
Router#show ip bgp neigh 10.10.10.2 | in tcp
Transport(tcp) path-mtu-discovery is enabled
Router#
- Envoyez une requête ping à l'homologue BGP avec le bit MTU et DF (Don't Fragment) de l'interface max :
Router#ping 10.10.10.2 size 1500 df
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)
- Diminuez la valeur de taille ICMP afin de déterminer la taille MTU maximale pouvant être utilisée :
ping 10.10.10.2 size 1300 df
Solution
Voici quelques causes possibles :
- Le MTU de l’interface sur les deux routeurs ne correspond pas.
- Le MTU de l'interface sur les deux routeurs correspond, mais le domaine de couche 2 sur lequel la session BGP est formée ne correspond pas.
- La découverte MTU du chemin a déterminé la valeur de base de données maximale incorrecte pour la session TCP BGP.
- La découverte PMTUD (BGP Path Maximum Transmission Unit Discovery) peut échouer en raison de paquets ICMP PMTUD bloqués (pare-feu ou ACL)
Voici des moyens possibles de résoudre les problèmes de MTU :
- Le MTU de l’interface sur les deux routeurs doit être identique ; exécuter la commande show ip int | dans la commande MTU afin de vérifier les paramètres MTU actuels.
- Si le MTU de l'interface sur les deux routeurs est correct (par exemple, 1500) mais que les tests ping avec le bit DF défini ne dépassent pas 1300, alors le domaine de couche 2 sur lequel la session BGP affectée est formée peut inclure des configurations MTU incohérentes. Vérifiez chaque MTU d’interface de couche 2. Corrigez le MTU de l'interface de couche 2 afin de résoudre le problème.
- Si vous ne parvenez pas à vérifier/modifier le domaine de couche 2, vous pouvez définir la commande globale ip tcp mss sur une valeur moindre, par exemple 1000, ce qui forcera toutes les sessions de segment de données TCP max d'origine locale (qui inclut BGP) à 1000. Pour plus d'informations sur cette commande, référez-vous à la section ip tcp mss de la référence des commandes des services d'application IP Cisco IOS.
En outre, vous pouvez utiliser la commande ip tcp adjust-mss afin de dépanner plus loin ; cette commande est configurée au niveau de l’interface et affecte toutes les sessions TCP. Pour plus d'informations sur cette commande, référez-vous à la section ip tcp adjust-mss de la référence des commandes des services d'application IP Cisco IOS.
- (Facultatif) La découverte PMTUD (Maximum Transmission Unit Discovery) du chemin BGP risque de ne pas générer la taille maximale de données correcte. Vous pouvez la désactiver globalement ou par voisin afin de confirmer si c'est la cause. Lorsque la PMTUD BGP est désactivée, la taille maximale de segment BGP (MSS) est définie par défaut sur 536, comme défini dans RFC 879.
Pour plus d'informations sur la désactivation de PMTUD, référez-vous à la section Configuration de la prise en charge BGP pour la découverte MTU du chemin TCP par session du Guide de configuration BGP de Cisco IOS.
Pour plus d'informations sur la PMTUD, consultez Qu'est-ce que la PMTUD ?
Commentaires