Xử lý sự cố kết nối của Down Down

Mạng của chúng tôi gặp sự cố ngừng hoạt động khi một trong các tuyến BGP của chúng tôi bị hỏng trong một thời gian ngắn ngày hôm qua. Rất may, các kết nối của chúng tôi đã thất bại đối với tuyến BGP thứ cấp của chúng tôi sau một vài phút và tuyến chính đã bắt đầu hoạt động sau khi tắt / không tắt bên phía ISP.

Chúng tôi đang chạy 2 bộ chuyển mạch (bảng nối đa năng) Cisco 3750e chạy iOS 12.2 58.

Trong cuộc trò chuyện của tôi với ISP của chúng tôi, họ không thể đưa ra bất kỳ câu trả lời dứt khoát nào cho nguyên nhân. Có bất cứ điều gì mà chúng ta có thể làm để xác định nguyên nhân cuối cùng để tránh vấn đề này trong tương lai không?

Đăng nhập tại thời điểm xảy ra lỗi

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

Đăng nhập khi ISP thực hiện tắt / không tắt để đặt lại BGP về phía họ

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

Đăng nhập khi kết nối BGP cuối cùng đã chuyển từ không hoạt động lên

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

Giao diện BGP ở cuối của chúng tôi (lưu ý: không có CRC, giọt, va chạm được báo cáo ...)

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 tháng 5 14:43:06:% BGP-3-THÔNG BÁO: gửi cho hàng xóm xxx.xxx.12.34 4/0 (hết thời gian chờ) 0 byte

Điều đó thường có nghĩa là phía bên kia của kết nối không phản hồi với bất kỳ sự bảo trì nào trong bộ hẹn giờ giữ (mặc định 180 giây). Có một loạt các vấn đề có thể gây ra điều này. Thông thường nó là một vấn đề khả năng tiếp cận layer3. Nếu nó xảy ra một lần nữa, bạn nên loại trừ sự cố layer3 bằng cách kiểm tra ngang hàng thông qua ping và telnet (telnet đến cổng 179, xem nó có phản hồi không).

Nếu nó không phải là một vấn đề khả năng tiếp cận layer3, thì đã có một vấn đề với một đầu của sự trung thành (nhiều khả năng là phía xa trong trường hợp này).

Nếu bạn chỉ đơn giản là tìm kiếm 'nguyên nhân gốc rễ' thì vấn đề này:

Bạn có thể muốn hỏi nhà cung cấp của mình nếu có bất kỳ thay đổi cấu hình nào được thực hiện ngay trước khi điều này xảy ra. Có các trường hợp trên các bộ định tuyến của Cisco (không chắc chắn 100% về mã nào vào lúc này) khi các phiên BGP sẽ vỗ khi một bên gỡ bỏ và thêm lại "lộ trình bản đồ" với "mpls-ip" và / hoặc "mtu "Cấu hình trong tiên phong BGP. Mặc dù loại bảo trì đó không gây ra vấn đề với phiên làm việc tiên phong, tôi đã nghe câu chuyện về điều này xảy ra.

Ngoài ra, tôi không chắc họ sẽ cần phải bỏ xa giao diện và đưa nó trở lại để 'khắc phục' vấn đề. Tôi nghĩ rằng chỉ cần đặt lại phiên làm việc tiên phong sẽ có hiệu lực, nhưng nếu không có lưu lượng truy cập nào được thông qua tại thời điểm không thành công, người ta có thể lập luận rằng họ không bỏ qua giao diện để khiến mọi thứ trở lại.

Nó có thể là một vấn đề MTU. Có điều này một thời gian trước đây. Khởi động tốt nhưng khi nhận được CẬP NHẬT với rất nhiều tuyến đường, nó sẽ bị mất do không khớp MTU. Ngoài ra, nếu bạn có các thiết bị L2 (chuyển đổi? Bộ chuyển đổi phương tiện truyền thông?) Giữa hai bộ định tuyến của bạn, có thể kết nối bị gián đoạn mà không có giao diện bị hỏng.

Không phải từ những gì tôi đang thấy. Bộ định tuyến của ISP của bạn thoát khỏi việc trả lời các tin nhắn xin chào từ bộ định tuyến của bạn, đó là lý do tại sao bạn mất kết nối BGP. Cũng có thể bộ định tuyến của bạn bỏ nghe các tin nhắn xin chào từ ISP, nhưng tôi không thấy bất cứ điều gì rõ ràng trong các tin nhắn sẽ giúp xác định vấn đề. Có lẽ ai đó tập trung hơn vào theo dõi ISP có thể bình luận và làm sáng tỏ?