Dépannage des connexions «Down BGP»


21

Notre réseau a connu une courte panne lorsque l'une de nos routes BGP a été interrompue pour une courte période hier. Heureusement, nos connexions ont échoué sur notre route BGP secondaire après quelques minutes, et la route principale est devenue opérationnelle après une fermeture / pas de fermeture du côté du FAI.

Nous exécutons 2 commutateurs empilés (fond de panier) Cisco 3750e exécutant iOS 12.2 58.

Dans ma conversation avec notre FAI, ils n'ont pas pu donner de réponses définitives à la cause. Y a-t-il quelque chose que nous puissions faire pour identifier la cause de notre côté pour éviter ce problème à l'avenir?

Connectez-vous au moment de l'erreur

172258: May  6 14:43:06: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Down BGP Notification sent
172259: May  6 14:43:06: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.12.34 4/0 (hold time expired) 0 bytes
172260: May  6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Multicast topology base removed from session  BGP Notification sent
172261: May  6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Unicast topology base removed from session  BGP Notification sent

Connectez-vous lorsque le FAI a fait un arrêt / aucun arrêt pour réinitialiser BGP de leur côté

172542: May  6 15:04:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to down
172543: May  6 15:04:16: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to down
172544: May  6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 DOWN on interface GigabitEthernet2/0/49 non DR
172545: May  6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 UP on interface GigabitEthernet2/0/49 
172546: May  6 15:04:16: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to xxx.xxx.12.35 on interface GigabitEthernet2/0/49
172547: May  6 15:04:18: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to up
172548: May  6 15:04:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to up

Connectez-vous lorsque la connexion BGP est finalement passée de l'inactive à Up

172828: May  6 15:27:33: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Up

Interface BGP de notre côté (note: pas de CRC, chutes, collisions signalées ...)

GigabitEthernet2/0/49 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is xxxx.xxxx
Internet address is xxx.xxx.12.35/31
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:09, output 00:00:12, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/52/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 14536000 bits/sec, 1655 packets/sec
5 minute output rate 1010000 bits/sec, 640 packets/sec
413176726 packets input, 428902543141 bytes, 0 no buffer
Received 143495 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 139275 multicast, 0 pause input
0 input packets with dribble condition detected
125748632 packets output, 42915625632 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

notez qu'il y a une discussion dans Meta (déjà!) sur les balises. Veuillez envisager (ou aller à la méta et au carillon) transformer votre étiquette de numéro de modèle cisco en MANUFAC-MODELSERIES ... vous n'êtes pas sûr de la 3750e, mais c'est peut-être la série 3700? Alors "cisco-3700" pour la balise. Sinon, ce sera une mer de soupe de modèle de matériel. Veuillez également conserver votre balise «cisco», afin que les utilisateurs puissent également rechercher / suivre / s'abonner à «cisco».
Craig Constantine

Fait comme suggéré.
John Lee

Il n'y a aucune mention si les 2 homologues BGP sont directement connectés ou non. S'il y a un autre appareil entre eux, une foule d'autres problèmes possibles pourraient être générés par eux.
noaru

renommé cisco-3750 car le 3700 est un ancien modèle de routeur. Les commutateurs Catalyst sont 3750.
Dave Noonan

@noaru les 2 pairs BGP sont directement connectés.
John Lee

Réponses:


19

172259: 6 mai 14:43:06:% BGP-3-NOTIFICATION: envoyé au voisin xxx.xxx.12.34 4/0 (délai d'attente expiré) 0 octet

Cela signifie généralement que l'autre côté de la connexion n'a répondu à aucun Keepalives dans le temporisateur de mise en attente (180 secondes par défaut). Il existe une variété de problèmes qui pourraient avoir causé cela. Il s'agit généralement d'un problème d'accessibilité de la couche 3. Si cela se reproduit, vous devez exclure le problème de couche 3 en testant l'homologue via ping et telnet (telnet vers le port 179, voir s'il répond).

Si ce n'est pas un problème d'accessibilité de la couche 3, alors il y avait un problème avec une extrémité du voisinage (plus probablement le côté éloigné dans ce cas).


4

Si vous cherchez simplement à «provoquer la cause» de ce problème:

Vous voudrez peut-être demander à votre fournisseur si des modifications de configuration ont été apportées de leur côté immédiatement avant que cela ne se produise. Il y a des cas sur les routeurs Cisco (pas sûr à 100% du code rev pour le moment) où les sessions BGP flapteront lorsqu'un côté supprime et rajoute une "route-map" avec un "mpls-ip" et / ou un "mtu "configuration dans l'homologation BGP. Bien que ce type d'entretien ne devrait pas causer de problèmes avec la session de peering, j'ai entendu parler de cela.

De plus, je ne suis pas certain qu'ils auraient dû aller jusqu'à supprimer l'interface et la ramener pour «résoudre» le problème. Je pense que la simple réinitialisation de la session d'appairage aurait suffi, mais s'il n'y avait pas de trafic passé au moment de l'échec, on pourrait dire qu'il n'a pas d'importance qu'ils aient abandonné l'interface pour que les choses recommencent.


Je n'ai pas entendu parler de réinitialiser la session de peering. Est-ce similaire à ce qui est mentionné ici? link De plus, est-ce que je peux faire de notre côté pour réinitialiser la connexion?
John Lee

1
C'est juste un simple 'clear ip bgp nei xx.xx.xx.xx', également connu sous le nom de 'clearing the session'. Il réinitialise simplement le voisinage BGP (hard clear met fin à la session et la rétablit).
Justin Seabrook-Rocha

Question rapide: le «clear ip bgp nei» doit-il être effectué du côté du FAI ou aurions-nous pu l'initier également?
John Lee

L'une ou l'autre extrémité peut lancer la suppression de la session. Parfois, lorsque des choses "étranges" se produisent, comme c'est le cas ici, cela vaut la peine de l'essayer aux deux extrémités. Je ferais chaque extrémité une à la fois, simplement pour le dépannage.
GoatAtWork

Il convient de mentionner que vous pouvez effectuer une réinitialisation logicielle (ajoutez simplement le mot clé `` soft '' à la fin de la commande) - cela force le renvoi des mises à jour sans interrompre la connexion (et la relation avec le voisin).
noaru

4

Cela pourrait être un problème MTU. Je l'ai eu il y a quelque temps. Démarre bien mais quand une MISE À JOUR avec beaucoup d'itinéraires est reçue, elle est perdue en raison de l'inadéquation MTU. De plus, si vous avez des périphériques L2 (commutateur? Convertisseur de média?) Entre vos deux routeurs, il est possible que la connexion soit interrompue sans que l'interface ne tombe en panne.


0

Pas d'après ce que je vois. Le routeur de votre FAI a cessé de répondre aux messages de bienvenue de votre routeur, c'est pourquoi vous avez perdu votre connexion BGP. Il est également possible que votre routeur arrête d'écouter les messages de bienvenue du FAI, mais je ne vois rien d'évident dans les messages qui aiderait à identifier le problème. Peut-être que quelqu'un plus concentré sur la piste ISP peut commenter et faire la lumière?


Vous voulez dire Keepalives, pas bonjour - c'est BGP, pas OSPF.
Niels

Merci, oui. Je m'embrouille parfois.
Avery Abbott
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.