Устранение неполадок «Связные соединения BGP»

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

У нас запущены 2 многоуровневые коммутаторы Cisco 3750e с iOS 12.2 58.

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

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

172258: 6 мая 14:43:06:% BGP-5-ADJCHANGE: сосед xxx.xxx.12.34 Вниз отправлено уведомление BGP
172259: 6 мая 14:43:06:% BGP-3-NOTIFICATION: отправлено соседу xxx.xxx.12.34 4/0 (время ожидания истекло) 0 байт
172260: 6 мая 14:43:06:% BGP_SESSION-5-ADJCHANGE: сосед xxx.xxx.12.34 IPv4 База многоадресной топологии удалена из сеанса BGP Уведомление отправлено
172261: 6 мая 14:43:06:% BGP_SESSION-5-ADJCHANGE: сосед xxx.xxx.12.34 IPv4 База топологии одноадресной передачи удалена из сеанса.

Журнал, когда ISP закрыл /не закрыл, чтобы сбросить BGP на их стороне

172542: 6 мая 15:04:15:% LINEPROTO-5-UPDOWN: Строковый протокол интерфейса GigabitEthernet2 /0/49, изменено состояние вниз
172543: 6 мая 15:04:16:% LINK-3-UPDOWN: интерфейс GigabitEthernet2 /0/49, изменено состояние вниз
172544: 6 мая 15:04:16:% PIM-5-NBRCHG: сосед xxx.xxx.12.34 DOWN на интерфейсе GigabitEthernet2 /0/49 non DR
172545: 6 мая 15:04:16:% PIM-5-NBRCHG: сосед xxx.xxx.12.34 UP по интерфейсу GigabitEthernet2 /0/49
172546: 6 мая 15:04:16:% PIM-5-DRCHG: изменение DR от соседа 0.0.0.0 до xxx.xxx.12.35 на интерфейсе GigabitEthernet2 /0/49
172547: 6 мая 15:04:18:% LINK-3-UPDOWN: интерфейс GigabitEthernet2 /0/49, изменено состояние вверх
172548: 6 мая 15:04:19:% LINEPROTO-5-UPDOWN: протокол линии по интерфейсу GigabitEthernet2 /0/49, изменено состояние до

Войдите, когда соединение BGP, наконец, перешло с режима ожидания на

172828: 6 мая 15:27:33:% BGP-5-ADJCHANGE: сосед xxx.xxx.12.34 Вверх

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

GigabitEthernet2 /0/49 вверх, линейный протокол подключен (подключен)
Аппаратное обеспечение - Gigabit Ethernet, адрес - xxxx.xxxx
Интернет-адрес: xxx.xxx.12.35 /31
MTU 1500 байт, BW 1000000 Кбит /с, DLY 10 мкс,
надежность 255/255, txload 1/255, rxload 3/255
Инкапсуляция ARPA, петля не установлена
Keepalive не установлен
Полнодуплексный, 1000 Мбит /с, тип ссылки - авто, тип мультимедиа - 1000BaseLX SFP
входное управление потоком выключено, управление потоком вывода не поддерживается
Тип ARP: ARPA, время ожидания ARP 04:00:00
Последний вход 00:00:09, выход 00:00:12, выход висит никогда
Последняя очистка счетчиков «show interface» никогда не была
Входная очередь: 0/75/52/0 (размер /макс /капли /сбрасывание); Общий выход: 0
Стратегия очередей: fifo
Очередь вывода: 0/40 (размер /макс)
5-минутная скорость ввода 14536000 бит /с, 1655 пакетов /с
5-минутная скорость выхода 1010000 бит /с, 640 пакетов в секунду
413176726 вход пакетов, 428902543141 байт, 0 нет буфера
Получено 143495 трансляций (0 многоадресных IP-адресов)
0 рун, 0 гигантов, 0 дросселей
0 ошибок ввода, 0 CRC, 0 кадров, 0 превышение, 0 игнорируется
0 сторожевой таймер, 139275 многоадресной рассылки, 0 вход паузы
0 входных пакетов с обнаруженным состоянием
125748632 выход пакетов, 42915625632 байт, 0 недоработок
0 ошибок вывода, 0 столкновений, 0 сброса интерфейса
0 неизвестных протоколов
0 babbles, 0 позднее столкновение, 0 отложено
0 потерянный несущий, 0 нет несущей, 0 выход паузы
0 выходных буферов вывода, 0 выходных буферов
19 голосов | спросил John Lee 8 Mayam13 2013, 00:49:24

4 ответа


17

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

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

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

ответил Justin Seabrook-Rocha 8 Mayam13 2013, 01:20:32
3

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

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

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

ответил GoatAtWork 8 Mayam13 2013, 01:12:06
3

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

ответил Sebastian 8 Mayam13 2013, 01:29:52
0

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

ответил Avery Abbott 8 Mayam13 2013, 01:18:32

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132