Bài 51: OSPFv2 — Neighbor States, Troubleshooting Cơ Bản

💡 Liên hệ thực tế

Ở Bài 49, bạn đã thấy trạng thái FULL trong show ip ospf neighbor và biết đó là dấu hiệu tốt. Nhưng nếu 2 Router mãi không lên được FULL, mà "kẹt" ở 1 trạng thái nào đó khác — làm sao biết vấn đề nằm ở đâu? Giống như theo dõi tiến trình 1 cuộc phỏng vấn xin việc: "đã nộp hồ sơ" → "đã liên hệ" → "đã phỏng vấn" → "đã nhận việc" — nếu hồ sơ mãi kẹt ở bước "đã liên hệ" không tiến triển, bạn cần biết chính xác bước đó là gì để tìm đúng nguyên nhân.

🔍 OSPF có đúng 8 "bước tiến trình" như vậy, gọi là Neighbor State (trạng thái láng giềng), được định nghĩa chính thức trong RFC 2328.

📘 Kiến thức cốt lõi

⚙️ 8 trạng thái Neighbor State theo đúng thứ tự tiến triển:

🎯 Mẹo nhớ thứ tự: "Down đến Init, bắt tay 2-Way, rồi Exstart-Exchange-Loading để cuối cùng Full."

⚠️ 2 tình huống "kẹt trạng thái" phổ biến nhất và cách xử lý:

Kẹt ở 2-Way (trên mạng Multi-Access): ✅ Đây thường không phải lỗi — theo đúng thiết kế OSPF, các Router DROTHER (không phải DR/BDR, đã học ở Bài 50) chỉ hình thành quan hệ FULL với DR và BDR, còn với nhau chỉ dừng ở 2-Way là hành vi hoàn toàn bình thường.

Kẹt ở Exstart/Exchange: ⚠️ Đây thường là dấu hiệu có vấn đề thực sự cần kiểm tra — nguyên nhân phổ biến nhất là MTU (Maximum Transmission Unit) không khớp giữa 2 Interface. Nếu 1 bên cấu hình MTU lớn hơn bên kia, gói DBD lớn có thể bị từ chối, khiến quá trình trao đổi Database liên tục thất bại và quay vòng ở Exstart/Exchange.

Router# show interfaces gigabitEthernet 0/1 | include MTU

📎 Kiểm tra và đảm bảo MTU khớp nhau ở cả 2 đầu Interface là bước xử lý đầu tiên khi gặp tình huống Neighbor kẹt ở Exstart/Exchange.

🔍 Lệnh kiểm tra tổng quan trạng thái Neighbor:

Router# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2         1     FULL/DR         00:00:35    192.168.100.2   GigabitEthernet0/1
3.3.3.3         1     2WAY/DROTHER    00:00:32    192.168.100.3   GigabitEthernet0/1

💬 Hỏi & Đáp nhanh

❓ Vì sao trạng thái Exstart lại cần "Master/Slave", trong khi 2 Router vốn bình đẳng với nhau? 

✅ Vì quá trình trao đổi DBD cần 1 bên chủ động điều phối số thứ tự (Sequence Number) để tránh nhầm lẫn gói tin nào đến trước, gói nào đến sau. Router có Router ID cao hơn được chọn làm Master (chủ động tăng Sequence Number), Router còn lại làm Slave — đây chỉ là cơ chế điều phối kỹ thuật tạm thời cho giai đoạn Exstart/Exchange, không liên quan gì đến vai trò DR/BDR đã bầu trước đó.

❓ Nếu Neighbor kẹt mãi ở Down, cần kiểm tra điều gì trước tiên? 

✅ Down nghĩa là chưa nhận được gói Hello nào cả — cần kiểm tra những nguyên nhân cơ bản nhất trước: cáp có kết nối không, Interface có đang up/up không, cả 2 Interface có cùng nằm trong dải mạng và Area đã khai báo bằng lệnh network (Bài 49) hay không, và không có ACL nào đang chặn traffic Multicast của OSPF.

❓ Vì sao Neighbor có thể kẹt ở Init dù đã gửi được Hello? 

✅ Init nghĩa là đã nhận được Hello từ láng giềng, nhưng láng giềng đó chưa thấy phản hồi ngược lại từ phía mình (chưa xác nhận 2 chiều). Nguyên nhân phổ biến là Firewall hoặc ACL đang chặn gói Hello phản hồi theo chiều ngược lại — cần kiểm tra kỹ các access-list áp trên Interface, đảm bảo không vô tình chặn địa chỉ Multicast 224.0.0.5/224.0.0.6 mà OSPF dùng để gửi Hello.

📝 Bài tập đánh giá

Câu 1: Trạng thái nào cho biết 2 Router OSPF đã hoàn tất đồng bộ đầy đủ Link State Database?

• A. 2-Way
• B. Exchange
• C. Loading
• D. Full

Câu 2: Nguyên nhân phổ biến nhất khiến OSPF Neighbor bị kẹt ở trạng thái Exstart/Exchange là gì?

• A. Sai địa chỉ IP Loopback
• B. MTU không khớp giữa 2 Interface
• C. Router ID trùng nhau
• D. Chưa cấu hình VLAN

👉 Đáp án:

Câu 1: D — Full là trạng thái cuối cùng, cho biết 2 Router đã đồng bộ hoàn chỉnh Link State Database và chính thức thiết lập quan hệ láng giềng.

Câu 2: B — MTU không khớp là nguyên nhân phổ biến nhất khiến quá trình trao đổi gói DBD thất bại liên tục, khiến Neighbor kẹt ở Exstart hoặc Exchange.

📚 Bài viết thuộc khóa học CCNA của VNExperts

🧭 Điều hướng