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
la source
Réponses:
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).
la source
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.
la source
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.
la source
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?
la source