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

21

В нашей сети произошел кратковременный сбой, когда один из наших маршрутов 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
Джон Ли
источник
обратите внимание, что в мета-версии уже есть обсуждение тегов. Пожалуйста, подумайте (или перейдите к разделу meta and chime in), чтобы превратить ваш номер модели cisco в MANUFAC-MODELSERIES ... не уверен насчет 3750e, но, возможно, это серия 3700? Итак, «cisco-3700» для тега. В противном случае это будет море модели аппаратного супа. Пожалуйста, сохраняйте также тег «cisco», чтобы люди могли искать / подписываться / подписываться на «cisco».
Крейг Константин
Сделано как предложено.
Джон Ли
Там нет упоминания о том, напрямую подключены 2 пира BGP или нет. Если между ними есть какое-либо другое устройство, они могут создать множество других возможных проблем.
noaru
помечен как cisco-3750, так как 3700 - маршрутизатор более старой модели. Коммутаторы Catalyst - 3750.
Дейв Нунан,
@noaru 2 одноранговых узла BGP напрямую связаны.
Джон Ли

Ответы:

19

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

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

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

Джастин Сибрук-Роча
источник
4

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

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

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

GoatAtWork
источник
Не слышал о сбросе сеанса пиринга. Это похоже на то, что упоминается здесь? ссылка Также, могу ли я что-то сделать с нашей стороны, чтобы сбросить соединение?
Джон Ли
1
Это просто «clear ip bgp nei xx.xx.xx.xx», также известный как «очистка сеанса». Он просто сбрасывает соседство BGP (hard clear сбрасывает сеанс и восстанавливает его).
Джастин Сибрук-Роча
Быстрый вопрос: нужно ли делать «clear ip bgp nei» на стороне интернет-провайдера или мы тоже могли его инициировать?
Джон Ли
Любой конец может инициировать очистку сеанса. Иногда, когда происходят «странные» вещи, как, например, здесь, стоит попробовать это с обоих концов. Я бы делал каждый конец по одному, просто ради устранения неполадок.
GoatAtWork
Стоит отметить, что вы можете выполнить программный сброс (просто добавьте ключевое слово «soft» в конце команды) - это вызывает повторную отправку обновлений без разрыва соединения (и отношений с соседями).
noaru
4

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

Себастьян Визингер
источник
0

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

Эвери Эбботт
источник
Вы имеете в виду keepalive, а не приветственные сообщения - это BGP, а не OSPF.
Нильс
Спасибо да Иногда я немного путаюсь.
Эвери Эбботт