OSPF single-area: cấu hình, kiểm tra neighbor và tìm lỗi

R1 đã học được neighbor R2, nhưng máy phía R1 chưa tới mạng sau R3. Người trực đề nghị chạy lại tiến trình OSPF để “đồng bộ cho chắc”. Cách làm này có thể cắt các adjacency đang tốt trong khi lỗi thực sự là LAN chưa được đưa vào OSPF hoặc server dùng gateway sai.

Lab dưới đây triển khai OSPFv2 single-area từ interface tới phép thử đầu cuối. Quy trình giữ riêng ba tầng bằng chứng: adjacency, thông tin topology/route và dịch vụ. Khi một tầng đã đúng, ta dùng nó để khoanh vùng tầng kế tiếp.

1. Chuẩn bị địa chỉ, interface và kết quả mong đợi

Đây là lab mới dạng chuỗi R1–R2–R3, không giữ link trực tiếp R1–R3 của bài cơ chế OSPF. Transit R1 Gi0/0 10.0.12.1/30 nối R2 Gi0/0 10.0.12.2/30. R2 Gi0/1 10.0.23.1/30 nối R3 Gi0/0 10.0.23.2/30. Các link transit chạy point-to-point ở cả hai đầu và cost 10.

R1 Gi0/1 là 10.10.10.1/24, R3 Gi0/1 là 10.30.30.1/24, cost LAN bằng 1. Máy A 10.10.10.10/24 dùng gateway .1, máy B 10.30.30.77/24 cũng dùng gateway .1 trong subnet của nó. Tất cả thuộc area 0; Router ID R1/R2/R3 là 1.1.1.1/2.2.2.2/3.3.3.3. Không NAT, VRF, redistribution hoặc route static cạnh tranh trong lab.

Chuỗi R1 R2 R3 area 0 với hai transit /30, LAN hai đầu và số tiến trình OSPF cục bộ 10 20 30 — Hình 1. Process ID khác nhau vẫn có thể lập adjacency; area, điều kiện interface và Router ID mới là dữ kiện cần đối chiếu.

Mẫu lệnh theo router IOS/IOS XE hỗ trợ OSPFv2, chưa chạy trên hardware. Cần interface đã đặt IP, no shutdown và up/up. Giữ cấu hình trước thay đổi, console hoặc đường quản trị riêng. Trên mạng thật, chọn Router ID, passive và network type có thể làm rớt adjacency/route, nên triển khai trong cửa sổ thay đổi.

2. Bật OSPF rõ trên interface, giữ LAN passive

Chọn process ID cục bộ 10 trên R1, 20 trên R2 và 30 trên R3 để thấy chúng không cần bằng nhau. Dùng lệnh tại interface giúp tránh wildcard rộng vô tình chọn thêm cổng. Hướng dẫn cấu hình OSPF của Cisco mô tả cách kích hoạt này; phải kiểm tra cú pháp của release đang dùng.

! R1, các interface đã có IP đúng bảng địa chỉ
configure terminal
router ospf 10
 router-id 1.1.1.1
 passive-interface default
 no passive-interface GigabitEthernet0/0
exit
interface GigabitEthernet0/0
 ip ospf 10 area 0
 ip ospf network point-to-point
 ip ospf cost 10
exit
interface GigabitEthernet0/1
 ip ospf 10 area 0
 ip ospf cost 1
end

! R2, chỉ hai cổng transit
configure terminal
router ospf 20
 router-id 2.2.2.2
 passive-interface default
 no passive-interface GigabitEthernet0/0
 no passive-interface GigabitEthernet0/1
exit
interface GigabitEthernet0/0
 ip ospf 20 area 0
 ip ospf network point-to-point
 ip ospf cost 10
exit
interface GigabitEthernet0/1
 ip ospf 20 area 0
 ip ospf network point-to-point
 ip ospf cost 10
end

! R3, LAN vẫn passive
configure terminal
router ospf 30
 router-id 3.3.3.3
 passive-interface default
 no passive-interface GigabitEthernet0/0
exit
interface GigabitEthernet0/0
 ip ospf 30 area 0
 ip ospf network point-to-point
 ip ospf cost 10
exit
interface GigabitEthernet0/1
 ip ospf 30 area 0
 ip ospf cost 1
end

Passive không gửi Hello và không lập neighbor trên interface đó, nhưng subnet đã được đưa vào OSPF vẫn có thể được quảng bá như mạng stub trong topology. Đây là lựa chọn cho LAN không có router peer, không phải cách loại LAN khỏi quảng bá. Đối chiếu tài liệu passive-interface và xem trạng thái thật sau cấu hình.

Cách viết cũ network 10.0.12.0 0.0.0.3 area 0 chọn interface có địa chỉ khớp, không tạo subnet chưa có trên router. Wildcard là mặt nạ so khớp, không nhập subnet mask 255.255.255.252 thay vào vị trí đó. Lab dùng cách interface, không cần chồng thêm network statement để “quảng bá mạnh hơn”.

3. Đọc interface trước, rồi xác nhận đúng neighbor

show ip interface brief
show ip ospf interface brief
show ip ospf interface GigabitEthernet0/0
show ip ospf neighbor
show ip protocols
show ip ospf

R1 dự kiến có peer Router ID 2.2.2.2, địa chỉ transit 10.0.12.2; R3 có peer 2.2.2.2 qua 10.0.23.1. R2 có hai peer 1.1.1.1 và 3.3.3.3 trên hai interface riêng. Không tìm peer3.3.3.3 trong bảng neighbor R1 vì R3 không nối trực tiếp R1 ở lab này.

Trên point-to-point, trạng thái thường hiển thị Full với hậu tố không có vai trò DR/BDR, chẳng hạn FULL/-. Đọc network type trong output trước khi áp kỳ vọng đó. Nếu link vẫn broadcast do cấu hình chưa đúng, vai trò và tiến trình bầu có thể khác. Không gọi mọi hậu tố /DROTHER là lỗi.

Thang bằng chứng từ interface up tới đúng network type, neighbor Full, LSDB và route mạng LAN — Hình 2. Kỳ vọng neighbor bám theo topology chuỗi; R1 không phải lập Full trực tiếp với R3.

Ghi Router ID đang hoạt động, không chỉ dòng cấu hình. Đổi Router ID có thể reset adjacency; ở IOS XE 17.13.1a trở đi, tài liệu nêu thay đổi có thể có hiệu lực ngay với adjacency đang hoạt động. Không dùng quy tắc chung “phải clear process mới áp dụng” cho mọi release, cũng không đổi Router ID như một phép thử ít tác động.

4. Xác nhận LAN đi qua LSDB, RIB và đường trả lời

Trên R1, đọc LSDB và route cụ thể, rồi đối chiếu R3 theo chiều ngược:

show ip ospf database
show ip route ospf
show ip route 10.30.30.77
ping 10.30.30.1 source 10.10.10.1
ping 10.30.30.77 source 10.10.10.1

Với cấu hình đã nêu, R1 có ứng viên intra-area tới 10.30.30.0/24 cost 21: hai transit 10 + 10 và LAN 1. Next-hop là 10.0.12.2. R3 có đường về 10.10.10.0/24 qua 10.0.23.1 cùng cost 21. R2 tới mỗi LAN có cost 11. Đây là kết quả tính của mô hình, không phải output thiết bị đã quan sát.

Nếu neighbor Full nhưng không có LAN trong LSDB, xem IP/interface LAN, area và kích hoạt OSPF. Nếu LSDB có mà route OSPF không được cài, kiểm tra nguồn khác tới cùng prefix hoặc policy trong bảng định tuyến. Một route static ưu tiên có thể giải thích kết quả, như bài static route, mà không cần reset neighbor.

Ping source địa chỉ LAN của router giúp thử đường về subnet ấy, nhưng chưa xác nhận máy A dùng đúng gateway hoặc B cho phép giao thức thử. Tiếp tục từ A tới B và dịch vụ cần dùng. Nếu gateway R3 tới được còn B không phản hồi, ưu tiên LAN B, ARP và host policy trước khi quy lỗi OSPF.

5. Dựa vào trạng thái để thu hẹp nguyên nhân chưa Full

Bảng neighbor trống: kiểm tra interface up/up, transit cùng subnet, OSPF đã chọn đúng cổng, không passive, area/timer/authentication tương thích và IP protocol 89 được cho phép. OSPFv2 không có TCP/UDP port89 để “mở cổng” theo cách đó. Chưa thấy peer cũng có thể do chưa đủ thời gian khởi tạo; ghi timer thật thay vì chờ một con số tùy ý.

Init kéo dài gợi ý Hello một chiều hoặc peer chưa nhìn thấy mình. So hai đầu và lọc/control-plane policy. Trạng thái 2-Way trên point-to-point của lab cần điều tra, nhưng 2-Way giữa hai DROTHER trên broadcast có thể hoàn toàn bình thường. Cisco hướng dẫn chẩn đoán theo neighbor state thay vì sửa cùng một tham số cho mọi tình huống.

Exstart/Exchange kéo dài: so MTU, Router ID trùng, mất gói và log trao đổi DBD. MTU mismatch là một nguyên nhân được Cisco phân tích riêng, không phải kết luận duy nhất. Sửa MTU theo thiết kế và khả năng đường truyền; không bật ip ospf mtu-ignore chỉ để làm trạng thái Full trong khi đường dữ liệu vẫn không mang nổi gói lớn.

Ma trận triệu chứng neighbor trống Init Exstart Exchange Full thiếu route và các bằng chứng cần thu — Hình 3. Trạng thái chỉ gợi nhóm giả thuyết; cần bằng chứng hai đầu trước khi chọn thay đổi.

Loading kéo dài cần xem yêu cầu LSA, retransmission và tình trạng peer. Full rồi liên tục Down/Full cần đối chiếu timestamp, interface flap, Dead timer và tài nguyên. Một ảnh chụp Full sau lần khởi động lại không chứng minh đã sửa nguyên nhân chập chờn.

6. Sửa từng điều kiện, giữ tác động và bằng chứng

Thu show clock, log liên quan và output hai đầu trước sửa. Chỉ thay một nhóm điều kiện có căn cứ, dự đoán trạng thái sau thay đổi, rồi đo lại. Đổi network type, timer hoặc authentication có thể làm neighbor rớt ngay; giữ đường console và cấu hình khôi phục. Lab cô lập này chưa bật xác thực, không phải mẫu bảo mật hoàn chỉnh để đưa nguyên vào production.

Không đưa clear ip ospf process thành bước chuẩn đầu tiên. Nó reset quan hệ và có thể rút route đang phục vụ; đồng thời xóa hiện trạng cần phân tích. Debug cũng có thể tạo tải CPU và log lớn. Nếu phải dùng, cần quy trình của thiết bị, phạm vi hẹp, thời gian giới hạn và cách dừng rõ ràng.

Ví dụ LAN chưa có OSPF thì bổ sung vào đúng area, vẫn giữ passive nếu không có peer. Lỗi subnet transit thì sửa địa chỉ/mask theo bảng đã duyệt, có thể cắt phiên quản trị đi qua link đó. Lỗi host gateway thì sửa endpoint; thay cost OSPF trong trường hợp này không xử lý được nguyên nhân.

Phân biệt thay đổi có chủ đích với thử lỗi ngẫu nhiên bằng một hồ sơ ngắn: triệu chứng ban đầu, giả thuyết, bằng chứng ủng hộ, lệnh dự kiến và điều kiện quay lại. Chẳng hạn nhận định “thiếu quảng bá LAN R3” cần output interface và LSDB phù hợp, không chỉ một ping timeout. Sau bổ sung, kỳ vọng thông tin LAN xuất hiện và route tới đích được cài; nếu hai điều này đã đúng nhưng dịch vụ vẫn lỗi, chuyển hướng điều tra thay vì tiếp tục sửa tiến trình.

7. Nghiệm thu trên ba lớp và lưu bài học có thể lặp lại

Chụp neighbor/route ổn định ở nhiều thời điểm phù hợp với triệu chứng, không chỉ ngay sau thay đổi. Đối chiếu R2 đủ hai peer, LAN hai đầu có route về nhau, cost đúng và phép thử từ endpoint thành công. Lưu source, đích, loại dịch vụ và mốc thời gian để người khác lặp lại được.

Interface, IP/mask, area và network type khớp bảng địa chỉ.
Process ID được đọc cục bộ; Router ID độc nhất và đúng trạng thái hoạt động.
Transit lập Full; LAN quảng bá nhưng không gửi Hello nhờ passive.
R1/R3 có route remote cost 21 trong giả thiết lab, R2 cost 11.
Đường về và dịch vụ được thử riêng; lưu startup-config sau nghiệm thu.

PDF trang vật lý 262–279 cung cấp nền cấu hình và kiểm tra OSPF. Bài dùng lại nguyên lý, viết mới lab, sơ đồ và quy trình; cú pháp interface và khác biệt Router ID/passive đối chiếu Cisco hiện hành. Không nhận cấu hình đã thử trên hardware. Tự đặt câu hỏi cuối: nếu R1 ping được 10.30.30.1 từ địa chỉ nguồn LAN nhưng B chưa truy cập được dịch vụ, cần thu bằng chứng nào ở LAN và host trước khi đụng tới OSPF?