Rozwiązywanie problemów z połączeniami „Down BGP”

Nasza sieć uległa awarii, gdy wczoraj jedna z naszych tras BGP uległa awarii. Na szczęście nasze połączenia nie przełączyły się na naszą dodatkową trasę BGP po kilku minutach, a główna trasa zaczęła działać po zamknięciu / braku zamknięcia po stronie dostawcy usług internetowych.

Działamy na dwóch przełącznikach Cisco 3750e w stosie (z tyłu) z systemem iOS 12.2 58.

W mojej rozmowie z naszym dostawcą usług internetowych nie mogli udzielić jednoznacznych odpowiedzi na przyczynę. Czy jest coś, co możemy zrobić, aby wskazać przyczynę z naszej strony, aby uniknąć tego problemu w przyszłości?

Zaloguj się w momencie wystąpienia błędu

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

Zaloguj się, gdy ISP wykonał zamknięcie / brak zamknięcia, aby zresetować BGP po swojej stronie

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

Zaloguj się, kiedy połączenie BGP w końcu przeszło z trybu bezczynności do trybu Up

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

Interfejs BGP na naszym końcu (uwaga: brak CRC, spadki, kolizje zgłoszone ...)

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 maja 14:43:06:% ZGŁOSZENIE BGP-3: wysłane do sąsiada xxx.xxx.12.34 4/0 (czas oczekiwania upłynął) 0 bajtów

Ogólnie oznacza to, że druga strona połączenia nie zareagowała na żadne podtrzymania w ramach timera wstrzymania (domyślnie 180 sekund). Istnieje wiele problemów, które mogły to spowodować. Zwykle jest to problem z osiągalnością warstwy 3. Jeśli to się powtórzy, należy wykluczyć problem z warstwą 3, testując komputer równorzędny przez ping i telnet (telnet na port 179, sprawdź, czy odpowiada).

Jeśli nie jest to problem z osiągalnością warstwy 3, to występował problem z jednym końcem sąsiedztwa (w tym przypadku bardziej prawdopodobne jest to, że jest to druga strona).

Jeśli chcesz po prostu „wywołać przyczynę”, ten problem:

Możesz zapytać swojego dostawcę, czy wprowadzono jakieś zmiany konfiguracji bezpośrednio przed tym. Istnieją routery na routerach Cisco (nie w 100% pewien, jaki kod w tej chwili zmienia), w których sesje BGP będą migać, gdy jedna strona usunie i ponownie doda „mapę trasy” z „mpls-ip” i / lub „mtu "konfiguracja w komunikacji równorzędnej BGP. Chociaż tego rodzaju konserwacja nie powinna powodować problemów z sesją peeringu, słyszałem o tym.

Nie jestem też pewien, czy musieliby posunąć się tak daleko, aby upuścić interfejs i przywrócić go z powrotem, aby „naprawić” problem. Myślę, że wystarczy zresetować sesję równorzędną, ale jeśli w czasie awarii nie byłby przekazywany żaden ruch, można argumentować, że nie ma znaczenia, że ​​porzucili interfejs, aby znów zacząć działać.

Może to być problem MTU. Miałem to jakiś czas temu. Zaczyna się dobrze, ale po otrzymaniu UPDATE z wieloma trasami gubi się z powodu niedopasowania MTU. Również jeśli masz urządzenia L2 (przełącznik? Konwerter mediów?) Między dwoma routerami, możliwe, że połączenie zostanie przerwane bez awarii interfejsu.

Nie z tego, co widzę. Router twojego dostawcy usług internetowych przestał odpowiadać na wiadomości powitalne z routera, dlatego utraciłeś połączenie BGP. Możliwe jest również, że Twój router przestał słuchać przywitanych wiadomości od dostawcy usług internetowych, ale nie widzę w wiadomościach niczego oczywistego, co pomogłoby wskazać problem. Może ktoś bardziej skupiony na utworze ISP może skomentować i rzucić nieco światła?