การแก้ไขปัญหาการเชื่อมต่อ“ ลง BGP”

เครือข่ายของเราประสบปัญหาการขาดแคลนเมื่อหนึ่งในเส้นทาง BGP ของเราลงไปเมื่อไม่นานมานี้ โชคดีที่การเชื่อมต่อของเราล้มเหลวในเส้นทาง BGP รองของเราหลังจากผ่านไปสองสามนาทีและเส้นทางหลักก็เริ่มทำงานหลังจากที่ปิด / ไม่ได้ปิดด้าน ISP

เรากำลังรัน 2 สแต็ก (แบ็คเพลน) สวิตช์ Cisco 3750e ที่รัน iOS 12.2 58

ในการสนทนากับ ISP ของเราพวกเขาไม่สามารถให้คำตอบที่ชัดเจนเกี่ยวกับสาเหตุได้ มีอะไรที่เราสามารถทำได้เพื่อระบุสาเหตุในตอนท้ายของเราเพื่อหลีกเลี่ยงปัญหานี้ในอนาคต?

เข้าสู่ระบบในเวลาที่เกิดข้อผิดพลาด

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-Notification: ส่งไปยังเพื่อนบ้าน xxx.xxx.12.34 4/0 (เวลาในการถือครองหมดอายุ) 0 ไบต์

นั่นหมายความว่าโดยทั่วไปแล้วการเชื่อมต่ออีกด้านไม่ตอบสนองต่อ keepalives ใด ๆ ภายในตัวจับเวลาการพัก (ค่าเริ่มต้น 180 วินาที) มีปัญหามากมายที่อาจทำให้เกิดปัญหานี้ มักจะเป็นปัญหาการเข้าถึงของเลเยอร์ 3 หากเกิดขึ้นอีกครั้งคุณควรตัดปัญหาเลเยอร์ 3 โดยทดสอบกับเพื่อนผ่าน ping และ telnet (telnet ไปยังพอร์ต 179 ดูว่าตอบสนองหรือไม่)

หากไม่ใช่ปัญหาความสามารถในการเข้าถึงของเลเยอร์ 3 แสดงว่ามีปัญหากับปลายด้านหนึ่งของการเป็นเพื่อนบ้าน (มีแนวโน้มที่ด้านไกลในกรณีนี้)

หากคุณกำลังมองหา 'สาเหตุที่แท้จริง' ปัญหานี้:

คุณอาจต้องการถามผู้ให้บริการของคุณว่ามีการเปลี่ยนแปลงการกำหนดค่าใด ๆ ในตอนท้ายก่อนเกิดเหตุการณ์นี้ มีอินสแตนซ์บนเราเตอร์ของซิสโก้ (ไม่แน่ใจ 100% ว่าโค้ด rev ในขณะนี้) ที่เซสชัน BGP จะกระพือเมื่อด้านใดด้านหนึ่งลบและเพิ่ม "แผนที่เส้นทาง" อีกครั้งด้วย "mpls-ip" และ / หรือ "mtu "การกำหนดค่าใน Bering peering แม้ว่าการบำรุงรักษาแบบนั้นไม่ควรทำให้เกิดปัญหากับช่วงเวลาการสนทนา แต่ฉันได้ยินเรื่องนี้เกิดขึ้น

นอกจากนี้ฉันไม่แน่ใจว่าพวกเขาจะต้องไปไกลเท่าที่จะทิ้งอินเทอร์เฟซและนำมันกลับไป 'แก้ไข' ปัญหา ฉันคิดว่าเพียงแค่รีเซ็ตเซสชั่นการเพียร์ริ่งจะพอเพียง แต่ถ้าไม่มีทราฟฟิกถูกส่งผ่านในเวลาที่เกิดความล้มเหลวใคร ๆ ก็สามารถเถียงได้ว่าไม่สำคัญว่าพวกเขาจะทิ้งอินเทอร์เฟซ

อาจเป็นปัญหาของ MTU มีเมื่อไม่นานมานี้ เริ่มต้นได้ดี แต่เมื่อได้รับการอัพเดทพร้อมเส้นทางมากมายมันจะหายไปเนื่องจาก MTU ไม่ตรงกัน นอกจากนี้หากคุณมีอุปกรณ์ L2 (สวิตช์? media converter?) ระหว่างเราเตอร์สองตัวของคุณอาจเป็นไปได้ว่าการเชื่อมต่อถูกขัดจังหวะโดยไม่ต้องอินเทอร์เฟซลง

ไม่ใช่จากสิ่งที่ฉันเห็น เราเตอร์ ISP ของคุณหยุดตอบสนองต่อข้อความสวัสดีจากเราเตอร์ของคุณซึ่งเป็นสาเหตุที่คุณสูญเสียการเชื่อมต่อ BGP ของคุณ อาจเป็นไปได้ว่าเราเตอร์ของคุณเลิกฟังข้อความสวัสดีจาก ISP แต่ฉันไม่เห็นอะไรชัดเจนในข้อความที่จะช่วยระบุปัญหา บางทีใครบางคนที่ให้ความสำคัญกับแทร็ก ISP มากขึ้นสามารถแสดงความคิดเห็นและหลั่งน้ำตาได้บ้าง?