Tweet
Xử lý sự cố EIGRP Flapping
Ta có mô hình:
Cấu hình như sau:
Router A# interface ethernet 0
ip address 10.1.1.1 255.255.255.0
interface serial 0
ip address 10.1.2.1 255.255.255.0
Router B# interface serial 0
ip address 10.1.2.2 255.255.255.0
interface serial 1
ip address 10.1.3.1 255.255.255.0
Router C# interface ethernet 0
ip address 10.1.1.2 255.255.255.0
interface serial 0
ip address 10.1.4.1 255.255.255.0
Router D# interface ethernet 0
ip address 10.1.1.3 255.255.255.0
interface serial 0
ip address 10.1.5.1 255.255.255.0
Vấn đề xảy ra trong Router A, thời gian route timer của các tuyến đường 150.150.0.0/16 trong bảng định tuyến là liên tục tại 00:00:00. Bằng cách nhìn vào Router C, các next hop, bạn có thể thấy rằng các tuyến đường là ổn định và không flapping. Các mối quan hệ hàng xóm trong Router A cũng ổn định, bước tiếp theo là nhìn vào bản ghi sự kiện trong EIGRP và xem những người hàng xóm đang cập nhật Router A liên tục về tuyến đường 150.150.0.0/16.
Router A# show ip eigrp event
20:47:13.2 Rcv update dest/nh: 150.150.0.0/16 10.1.1.3
20:47:13.2 Metric set: 150.150.0.0/16 4872198
20:47:13.2 Rcv update dest/nh: 150.150.0.0/16 10.1.1.3
20:47:13.2 Metric set: 150.150.0.0/16 4872198
Từ nhật ký sự kiện EIGRP, Router D liên tục gửi thông tin cập nhật đến Router A. Bước tiếp theo là để đi đến Router D để điều tra lý do tại sao nó được cập nhật Router A với bản cập nhật. Một lý do có thể là bản cập nhật này liên tục xảy ra là có một vòng lặp định tuyến trong Router D cho tuyến đường 150.150.0.0/16 với các router khác trong mạng X, gây ra các tuyến đường được gửi đến nhau. Nếu một vòng lặp định tuyến xảy ra trong mạng, bạn cần một sơ đồ mạng hiện tại để đi hop bởi hop cho mỗi bộ định tuyến để theo dõi các vòng lặp định tuyến.
Một khả năng khác có thể là việc chuyển đổi mạng LAN trên Router A Ethernet 0 có thể có một vấn đề cây kéo dài mà giữ Looping các gói tin từ Router D để Router A.
Nếu không có vòng lặp định tuyến là trong mạng và không có vấn đề cây bao trùm là trên switch, các khả năng khác là Router D có thể được chạy vào một lỗi EIGRP trong đó nó được liên tục gửi ra bản cập nhật cho Router A không có lý do. Một trong những lỗi có thể có thể CSCdt15109, trong đó các bộ định tuyến liên tục gửi ra bản cập nhật mà không thay đổi. Cisco IOS 12.1.7 và sau đó sẽ có sửa chữa lỗi cho vấn đề này, tuy nhiên, nó luôn luôn khuyến khích để tham khảo ý kiến với Cisco TAC để xác định xem vấn đề là do một lỗi phần mềm.
Trong ví dụ này, Router D được chạy vào các lỗi phần mềm đã đề cập. Nhận thấy rằng vấn đề không phải là trên Router A, nhưng trên Router D. Router D liên tục gửi ra bản cập nhật cho Router A và Router A liên tục làm mới bộ đếm thời gian của nó. Router A chỉ đơn giản là kết quả của các vấn đề gây ra bởi Router D. Sau khi nâng cấp phần mềm Cisco IOS trên Router D, Router A tạm dừng làm mới tuyến giờ bảng của nó. Ngoài ra, thực hiện show ip eigrp sự kiện nhiều lần liên tiếp cho thấy giờ trên bảng sự kiện không thay đổi. Điều này cũng xác nhận rằng quá trình EIGRP là ổn định và không phải nhận bản cập nhật từ hàng xóm.
Nguyễn Minh Hải – VnPro
Cấu hình như sau:
Router A# interface ethernet 0
ip address 10.1.1.1 255.255.255.0
interface serial 0
ip address 10.1.2.1 255.255.255.0
Router B# interface serial 0
ip address 10.1.2.2 255.255.255.0
interface serial 1
ip address 10.1.3.1 255.255.255.0
Router C# interface ethernet 0
ip address 10.1.1.2 255.255.255.0
interface serial 0
ip address 10.1.4.1 255.255.255.0
Router D# interface ethernet 0
ip address 10.1.1.3 255.255.255.0
interface serial 0
ip address 10.1.5.1 255.255.255.0
Vấn đề xảy ra trong Router A, thời gian route timer của các tuyến đường 150.150.0.0/16 trong bảng định tuyến là liên tục tại 00:00:00. Bằng cách nhìn vào Router C, các next hop, bạn có thể thấy rằng các tuyến đường là ổn định và không flapping. Các mối quan hệ hàng xóm trong Router A cũng ổn định, bước tiếp theo là nhìn vào bản ghi sự kiện trong EIGRP và xem những người hàng xóm đang cập nhật Router A liên tục về tuyến đường 150.150.0.0/16.
Router A# show ip eigrp event
20:47:13.2 Rcv update dest/nh: 150.150.0.0/16 10.1.1.3
20:47:13.2 Metric set: 150.150.0.0/16 4872198
20:47:13.2 Rcv update dest/nh: 150.150.0.0/16 10.1.1.3
20:47:13.2 Metric set: 150.150.0.0/16 4872198
Từ nhật ký sự kiện EIGRP, Router D liên tục gửi thông tin cập nhật đến Router A. Bước tiếp theo là để đi đến Router D để điều tra lý do tại sao nó được cập nhật Router A với bản cập nhật. Một lý do có thể là bản cập nhật này liên tục xảy ra là có một vòng lặp định tuyến trong Router D cho tuyến đường 150.150.0.0/16 với các router khác trong mạng X, gây ra các tuyến đường được gửi đến nhau. Nếu một vòng lặp định tuyến xảy ra trong mạng, bạn cần một sơ đồ mạng hiện tại để đi hop bởi hop cho mỗi bộ định tuyến để theo dõi các vòng lặp định tuyến.
Một khả năng khác có thể là việc chuyển đổi mạng LAN trên Router A Ethernet 0 có thể có một vấn đề cây kéo dài mà giữ Looping các gói tin từ Router D để Router A.
Nếu không có vòng lặp định tuyến là trong mạng và không có vấn đề cây bao trùm là trên switch, các khả năng khác là Router D có thể được chạy vào một lỗi EIGRP trong đó nó được liên tục gửi ra bản cập nhật cho Router A không có lý do. Một trong những lỗi có thể có thể CSCdt15109, trong đó các bộ định tuyến liên tục gửi ra bản cập nhật mà không thay đổi. Cisco IOS 12.1.7 và sau đó sẽ có sửa chữa lỗi cho vấn đề này, tuy nhiên, nó luôn luôn khuyến khích để tham khảo ý kiến với Cisco TAC để xác định xem vấn đề là do một lỗi phần mềm.
Trong ví dụ này, Router D được chạy vào các lỗi phần mềm đã đề cập. Nhận thấy rằng vấn đề không phải là trên Router A, nhưng trên Router D. Router D liên tục gửi ra bản cập nhật cho Router A và Router A liên tục làm mới bộ đếm thời gian của nó. Router A chỉ đơn giản là kết quả của các vấn đề gây ra bởi Router D. Sau khi nâng cấp phần mềm Cisco IOS trên Router D, Router A tạm dừng làm mới tuyến giờ bảng của nó. Ngoài ra, thực hiện show ip eigrp sự kiện nhiều lần liên tiếp cho thấy giờ trên bảng sự kiện không thay đổi. Điều này cũng xác nhận rằng quá trình EIGRP là ổn định và không phải nhận bản cập nhật từ hàng xóm.
Nguyễn Minh Hải – VnPro