Усунення несправностей підключень “Down BGP”

Наша мережа зазнала короткого відключення, коли один з наших маршрутів BGP вчора ненадовго зійшов. На щастя, через кілька хвилин наші з’єднання не вдалися до нашого вторинного маршруту BGP, а основний маршрут почав діяти після закриття / відключення на стороні провайдера.

Ми працюємо з двома складеними (на задній площині) комутаторами 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

Увійдіть, коли ISP зробив закриття / без закриття, щоб скинути 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 нарешті перейшло з режиму очікування вгору

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-ПОВІДОМЛЕННЯ: надіслано сусідові xxx.xxx.12.34 4/0 (час закінчення закінчився) 0 байт

Це загалом означає, що інша сторона з'єднання не реагувала на жодні збереження в таймері утримування (за замовчуванням 180 секунд). Існують різноманітні проблеми, які могли викликати це. Зазвичай проблема досяжності шару 3. Якщо це повториться, вам слід виключити випуск рівня 3, перевіривши його на рівний через ping та telnet (telnet до порту 179, подивіться, чи відповідає він).

Якщо це не проблема 3 доступності, то виникла проблема з одним кінцем сусідства (швидше за все, далека сторона в цьому випадку).

Якщо ви просто шукаєте "першопричину" цієї проблеми:

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

Крім того, я не впевнений, що їм потрібно було б зайти, щоб скинути інтерфейс і повернути його назад, щоб "виправити" проблему. Я думаю, що просто перезапустити сеанс "peering" було б достатньо, але якби не було пропущено трафіку на момент відмови, можна стверджувати, що не має значення, що вони кинули інтерфейс, щоб повернути речі знову.

Це може бути проблемою MTU. Це було деякий час тому. Починається чудово, але коли надходить ОНОВЛЕННЯ з великою кількістю маршрутів, вона втрачається через невідповідність MTU. Крім того, якщо у вас є пристрої L2 (перемикач? Медіаконвертер?) Між вашими двома маршрутизаторами, можливо, з'єднання буде перервано без інтерфейсу.

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