Устранение неисправностей соединений «Down BGP»

В нашей сети произошел кратковременный сбой, когда один из наших маршрутов BGP вчера отключился на короткое время. К счастью, через несколько минут наши соединения перешли на наш вторичный маршрут BGP, и основной маршрут стал работать после завершения / отсутствия закрытия на стороне провайдера.

У нас работают 2 стековых (объединительных) коммутатора Cisco 3750e под управлением iOS 12.2 58.

В моем разговоре с нашим провайдером они не смогли дать однозначных ответов на причину. Есть ли что-нибудь, что мы можем сделать, чтобы определить причину с нашей стороны, чтобы избежать этой проблемы в будущем?

Журнал во время ошибки

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

Журнал, когда интернет-провайдер сделал закрытый / без закрытия, чтобы сбросить BGP на их стороне

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

Журнал, когда BGP-соединение, наконец, перешло из режима ожидания в Up

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

Интерфейс BGP с нашей стороны (примечание: нет CRC, отбрасываний, сообщений о коллизиях ...)

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

172259: 6 мая 14:43:06:% BGP-3-NOTIFICATION: отправлено соседу xxx.xxx.12.34 4/0 (время удержания истекло) 0 байтов

Как правило, это означает, что другая сторона соединения не отвечает ни на какие сообщения активности в таймере удержания (по умолчанию 180 секунд). Есть множество проблем, которые могли бы вызвать это. Обычно это проблема достижимости уровня 3. Если это произойдет снова, вы должны исключить проблему layer3, протестировав одноранговый узел с помощью ping и telnet (telnet на порт 179, посмотрите, отвечает ли он).

Если это не проблема достижимости уровня 3, то была проблема с одним концом соседства (более вероятно, с дальней стороной в этом случае).

Если вы просто ищете «первопричину» этой проблемы:

Возможно, вы захотите спросить своего провайдера, были ли какие-либо изменения в конфигурации, сделанные на его конце, непосредственно перед тем, как это произошло. На маршрутизаторах Cisco есть экземпляры (которые не уверены на 100%, какая версия кода сейчас), когда сеансы BGP будут прерываться, когда одна сторона удаляет и повторно добавляет «карту маршрутов» с «mpls-ip» и / или «mtu». "конфигурация в пиринге BGP. Хотя такого рода обслуживание не должно вызывать проблем с пиринговым сеансом, я слышал историю об этом.

Кроме того, я не уверен, что им нужно было бы зайти так далеко, чтобы отбросить интерфейс и вернуть его обратно, чтобы «исправить» проблему. Я думаю, что простого сброса сеанса пиринга было бы достаточно, но если бы в момент сбоя не проходил трафик, можно утверждать, что не имеет значения, что они отбросили интерфейс для возобновления работы.

Это может быть проблемой MTU. Если бы это было некоторое время назад. Запускается нормально, но когда получено UPDATE с большим количеством маршрутов, оно теряется из-за несоответствия MTU. Также, если у вас есть устройства L2 (коммутатор? Медиаконвертер?) Между двумя вашими маршрутизаторами, возможно, что соединение прервано, и интерфейс не будет отключен.

Не из того, что я вижу. Маршрутизатор вашего интернет-провайдера прекратил отвечать на приветственные сообщения от вашего маршрутизатора, поэтому вы потеряли соединение BGP. Также возможно, что ваш маршрутизатор прекратил прослушивание приветственных сообщений от интернет-провайдера, но я не вижу в сообщениях ничего очевидного, что помогло бы определить проблему. Может быть, кто-то более сфокусированный на треке провайдера может прокомментировать и пролить свет?