การแก้ปัญหา OSPF ที่มีประสิทธิภาพ ไม่ควรเริ่มจากการเปลี่ยน Configuration แบบสุ่ม แต่ควรตรวจสอบตามลำดับตั้งแต่ Interface → OSPF Neighbor → LSDB → LSA → SPF → Routing Table → Forwarding Path เพื่อหาว่าปัญหาเกิดขึ้นที่ Control Plane หรือ Data Plane
บทความนี้เป็นภาค Troubleshooting ของชุด OSPF บน Cisco ครอบคลุมปัญหา Neighbor ไม่ขึ้น, Neighbor ค้างในสถานะต่าง ๆ, Area และ Timer ไม่ตรงกัน, Duplicate Router ID, LSA/LSDB ผิดปกติ, Route ไม่เข้า Routing Table, Multi-Area OSPF, Route Summarization รวมถึงกรณี OSPF ทำงานปกติ แต่ผู้ใช้ยังไม่สามารถสื่อสารกันได้
สารบัญ
- OSPF Troubleshooting Model
- สร้าง Network Baseline ก่อนแก้ปัญหา
- ขั้นที่ 1: Interface และ IP Connectivity
- ขั้นที่ 2: ตรวจ OSPF Process
- ขั้นที่ 3: ตรวจ OSPF Neighbor
- OSPF Neighbor States บอกอะไร?
- แก้ปัญหา DOWN และ INIT
- 2-WAY เป็นปัญหาหรือไม่?
- แก้ปัญหา EXSTART/EXCHANGE
- Area และ Network Type
- Hello/Dead Timer
- OSPF Authentication
- Duplicate Router ID
- ขั้นที่ 4: ตรวจ LSDB และ LSA
- ขั้นที่ 5: SPF และ Route Calculation
- ขั้นที่ 6: Routing Table
- Route Selection และ Administrative Distance
- Inter-Area Troubleshooting
- Route Summarization Troubleshooting
- OSPF ปกติ แต่ Ping ไม่ได้
- Cisco Troubleshooting Lab
- Workflow ใช้งานจริง
- Command Cheat Sheet
- FAQ
ภาค 1: OSPF Troubleshooting Framework
OSPF Troubleshooting Model
วิธีที่อ่านง่ายที่สุดคือ แยก OSPF ออกเป็นหลายชั้น แทนการมอง Routing Protocol เป็นระบบเดียวทั้งหมด
1. Physical / Interface
|
v
2. IP Connectivity
|
v
3. OSPF Enabled?
|
v
4. Neighbor Adjacency
|
v
5. LSDB / LSA
|
v
6. SPF Calculation
|
v
7. Routing Table (RIB)
|
v
8. Forwarding Table
|
v
9. Return Path
|
v
10. ACL / Firewall / Application
ถ้า Neighbor ยังไม่เกิด การเริ่มวิเคราะห์ Summary Route หรือ SPF มักเร็วเกินไป
ในทางกลับกัน หาก Neighbor เป็น FULL ก็ไม่ได้หมายความว่า Application จะต้องใช้งานได้ เพราะปัญหาอาจอยู่หลัง OSPF เช่น ACL, Firewall หรือ Return Route
สร้าง Network Baseline ก่อนแก้ปัญหา
ก่อน Troubleshoot ควรรู้ว่า Network ที่ถูกต้องควรมีหน้าตาอย่างไร
ข้อมูล Baseline ที่ควรมี:
- Network Diagram
- IP Address และ Subnet Mask
- Router ID
- OSPF Process
- Area Assignment
- Area Type
- Expected Neighbors
- Interface Cost
- Network Type
- ABR และ ASBR
- Summary Prefixes
- Default Route
- Expected Routing Table
ตัวอย่าง:
R1 -------- R2 -------- R3
| | |
Area 10 Area 0 Area 20
Expected:
R1 <-> R2 = FULL
R2 <-> R3 = FULL
R2 = ABR
R1 should learn:
192.168.30.0/24 as O IA
ภาค 2: Interface และ OSPF Process
ขั้นที่ 1: ตรวจ Interface และ IP Connectivity
ก่อนตรวจ OSPF ให้ยืนยัน Layer 1–3 ก่อน
show ip interface brief
ควรตรวจ:
- Interface เป็น up/up หรือไม่
- IP Address ถูกต้องหรือไม่
- Subnet Mask ตรงกันหรือไม่
- Interface ถูก Shutdown หรือไม่
- มี Duplicate IP หรือไม่
ตัวอย่าง:
R1# show ip interface brief
Interface IP-Address Status Protocol
GigabitEthernet0/0 10.0.12.1 up up
จากนั้น Ping Router ข้างเคียง:
R1# ping 10.0.12.2
ขั้นที่ 2: ตรวจ OSPF Process
show ip ospf
ตรวจข้อมูล เช่น:
- OSPF Process ทำงานหรือไม่
- Router ID คืออะไร
- Router เป็น ABR/ASBR หรือไม่
- มี Area ใดบ้าง
- SPF Information
ตรวจ Interface:
show ip ospf interface brief
คำสั่งนี้ช่วยตอบคำถามสำคัญว่า:
Interface นี้
|
+-- OSPF ทำงานอยู่หรือไม่?
|
+-- อยู่ Area ไหน?
|
+-- Process ใด?
ภาค 3: OSPF Neighbor Troubleshooting
ขั้นที่ 3: ตรวจ OSPF Neighbor
คำสั่งหลัก:
show ip ospf neighbor
ตัวอย่าง:
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:36 10.0.12.2 Gi0/0
ข้อมูลที่ควรดู:
- Neighbor ID
- State
- Dead Time
- Neighbor Address
- Interface
- DR/BDR Role หากเกี่ยวข้อง
OSPF Neighbor States บอกอะไร?
| State | ความหมายโดยย่อ | สิ่งที่ควรตรวจ |
|---|---|---|
| DOWN | ยังไม่ได้รับ Hello ตามที่คาด | Interface, IP, OSPF, ACL, Hello |
| INIT | ได้รับ Hello แต่ Router ยังไม่เห็นตัวเองใน Hello ของอีกฝั่ง | Two-way communication |
| 2-WAY | Two-way communication สำเร็จ | อาจปกติบน Multiaccess Network |
| EXSTART | กำลังตกลง Master/Slave และ Database Exchange Parameters | MTU, Router ID, Connectivity |
| EXCHANGE | แลก Database Description Packets | MTU, packet loss, instability |
| LOADING | ร้องขอ LSA ที่ต้องการเพิ่มเติม | LS Request/Update, packet loss |
| FULL | Adjacency และ LSDB Synchronization ที่จำเป็นสำเร็จ | ตรวจ Routing/LSDB ต่อหากยังมีปัญหา |
Neighbor ค้าง DOWN หรือ INIT
ตรวจตามลำดับ:
show ip interface brief
show ip ospf interface
show ip ospf neighbor
show running-config | section router ospf
สาเหตุที่ควรตรวจ:
- Interface Down
- OSPF ไม่ได้ทำงานบน Interface
- Network Statement ไม่ Match
- Interface ถูก Passive
- Area Configuration ผิด
- Hello Packet ถูก Filter
- Layer 2 มีปัญหา
- Unidirectional Communication
OSPFv2 ใช้ IP Protocol 89 ไม่ใช่ TCP หรือ UDP Port
Neighbor อยู่ 2-WAY ถือว่าผิดหรือไม่?
ไม่เสมอไป
บน Broadcast Multiaccess Network ที่มีหลาย Routers DROTHER Routers ไม่จำเป็นต้องสร้าง Full Adjacency ระหว่างกันทุกคู่
DR
/ \
/ \
R1 R2
\ /
\ /
BDR
DROTHER <-> DROTHER
may remain 2-WAY
ดังนั้นอย่าเห็น
2-WAY
แล้วสรุปทันทีว่า OSPF เสีย
ต้องตรวจ Network Type และ DR/BDR Role ก่อน
Neighbor ค้าง EXSTART หรือ EXCHANGE
หนึ่งในสาเหตุสำคัญ ที่ควรตรวจคือ MTU mismatch รวมถึงปัญหาการแลกเปลี่ยน Database Description Packets
ตรวจ Interface:
show interfaces GigabitEthernet0/0
show ip ospf interface GigabitEthernet0/0
ตรวจ MTU ของทั้งสองฝั่ง และตรวจ Packet Loss หรือ Interface Errors ร่วมด้วย
Area และ Network Type ไม่ตรงกัน
ตรวจ:
show ip ospf interface GigabitEthernet0/0
ดู:
- Area
- Network Type
- Cost
- Hello Interval
- Dead Interval
- DR/BDR
- Authentication
ตัวอย่างปัญหา:
R1 Gi0/0
Area 0
R2 Gi0/0
Area 10
Result:
No normal OSPF adjacency
Routers บน Link เดียวกัน ที่ต้องการเป็น Neighbor ต้องมี OSPF Parameters ที่จำเป็นสอดคล้องกัน
Hello และ Dead Timer ไม่ตรงกัน
ตรวจ:
show ip ospf interface
ตัวอย่าง:
R1
Hello 10
Dead 40
R2
Hello 5
Dead 20
Timer ที่จำเป็นไม่ตรงกัน สามารถทำให้ Adjacency ไม่เกิดขึ้น
OSPF Authentication ไม่ตรงกัน
หาก Network ใช้ OSPF Authentication ทั้งสองฝั่งต้องใช้ Configuration ที่เข้ากันได้
ตรวจ:
show ip ospf interface
show running-config interface GigabitEthernet0/0
show running-config | section router ospf
รูปแบบ Authentication และ Syntax แตกต่างได้ตาม OSPF Version, Cisco IOS/IOS XE และ Platform
Duplicate Router ID
OSPF Router ID ต้องไม่ซ้ำกันภายใน Routing Domain ที่เกี่ยวข้อง
ตรวจ:
show ip ospf
กำหนดแบบ Explicit:
router ospf 1
router-id 1.1.1.1
ภาค 4: LSDB และ LSA Troubleshooting
ขั้นที่ 4: ตรวจ LSDB
หาก Neighbor เป็น FULL แต่ Route ยังไม่เป็นไปตามคาด ขั้นต่อไปคือ LSDB
show ip ospf database
ตรวจ LSA แต่ละประเภท:
show ip ospf database router
show ip ospf database network
show ip ospf database summary
show ip ospf database external
show ip ospf database nssa-external
| LSA | ใช้ตรวจอะไร? |
|---|---|
| Type 1 | Router และ Links ภายใน Area |
| Type 2 | Network LSA จาก DR บน Multiaccess Segment ตามเงื่อนไข |
| Type 3 | Inter-Area Prefix Information |
| Type 4 | ข้อมูลสำหรับการเข้าถึง ASBR ใน OSPFv2 ตามบริบท |
| Type 5 | External Route Information |
| Type 7 | NSSA External Information |
LSA ไม่มี กับ Route ไม่มี เป็นคนละขั้น
หาก Router ไม่เห็น LSA ที่ควรได้รับ ให้ตรวจ Control Plane ก่อน
Expected Route missing
|
v
Is expected LSA in LSDB?
/ \
/ \
NO YES
| |
v v
OSPF/Area SPF/RIB/
LSA issue route selection
นี่เป็นจุดสำคัญในการ แยก Root Cause
ขั้นที่ 5: ตรวจ SPF และ Topology Calculation
OSPF ใช้ Link-State Database สร้าง Topology แล้วคำนวณเส้นทาง ด้วย SPF Algorithm
LSAs
|
v
LSDB
|
v
SPF
|
v
OSPF Routes
|
v
RIB
ตรวจ OSPF Process:
show ip ospf
บน Platform/Release ที่รองรับ Output อาจแสดงข้อมูล เกี่ยวกับ SPF Execution และเหตุการณ์ที่เกี่ยวข้อง
หากมี Topology Change เกิดขึ้นถี่ผิดปกติ ควรตรวจต้นเหตุ เช่น:
- Interface Flapping
- Unstable Link
- Neighbor Reset
- Routing Configuration Change
- Duplicate/Unstable Device
ภาค 5: Routing Table และ Route Selection
ขั้นที่ 6: Route อยู่ใน LSDB แต่ไม่เข้า Routing Table
การมี LSA ใน LSDB ไม่ได้รับประกันว่า Route นั้น ต้องถูกติดตั้งใน Routing Table
ตรวจ:
show ip route
show ip route ospf
show ip route <destination>
show ip protocols
สาเหตุที่ควรตรวจ:
- มี Route จาก Source อื่นที่ถูกเลือก
- Administrative Distance
- More-Specific Route
- OSPF Path Calculation
- Route Filtering
- Summarization
- Next-Hop Resolution
อย่าสับสน Prefix Length, AD และ Metric
เมื่อ Troubleshoot Route Selection ควรแยกแนวคิดออกจากกัน
Packet forwarding
|
v
Longest Prefix Match
Same destination prefix
from different route sources
|
v
Administrative Distance
Paths within routing protocol
|
v
Protocol-specific metric
ตัวอย่าง:
O 10.10.10.0/24 [110/20] via 10.0.12.2
S 10.10.10.0/24 [1/0] via 10.0.13.2
หาก Static Route ใช้งานได้ โดยปกติค่า AD 1 ต่ำกว่า OSPF 110 ดังนั้น Static Route สามารถถูกติดตั้งแทน OSPF สำหรับ Prefix เดียวกัน
แต่หาก OSPF Route เป็น More-Specific Prefix หลัก Longest Prefix Match ยังมีผลต่อ Packet Forwarding
ภาค 6: Multi-Area OSPF Troubleshooting
Inter-Area Route หาย ตรวจอย่างไร?
สมมติ:
Area 10
192.168.10.0/24
|
|
ABR
|
Area 0
|
|
ABR
|
Area 20
Router ใน Area 20 ไม่เห็น:
192.168.10.0/24
ตรวจตามลำดับ:
1. Route exists inside Area 10?
|
v
2. ABR knows the route?
|
v
3. Type 3 information generated?
|
v
4. Backbone connectivity correct?
|
v
5. Remote ABR receives information?
|
v
6. Area 20 router LSDB?
|
v
7. Route installed in RIB?
Commands:
show ip ospf
show ip ospf neighbor
show ip ospf border-routers
show ip ospf database summary
show ip route ospf
ตรวจ Area Type ด้วย
หากใช้:
- Stub Area
- Totally Stubby Area
- NSSA
- Totally NSSA
Routing Information ที่คาดว่าจะเห็น จะแตกต่างจาก Standard Area
ดังนั้นการเห็น Route หาย อาจเป็นผลตาม Area Design ไม่ใช่ Failure
Route Summarization Troubleshooting
หากใช้:
area 10 range 10.10.0.0 255.255.252.0
ตรวจ:
show ip route
show ip route ospf
show ip ospf database summary
ต้องรู้ว่า Summary:
10.10.0.0/22
ครอบคลุม:
10.10.0.0/24
10.10.1.0/24
10.10.2.0/24
10.10.3.0/24
หากบาง Prefix ไม่มีอยู่จริง Traffic สำหรับ Prefix เหล่านั้น อาจมาถึง Summary Router แล้วถูกทิ้ง
ภาค 7: เมื่อ OSPF ปกติ แต่ Network ยังใช้งานไม่ได้
Neighbor FULL และ Route มี แต่ Ping ไม่ได้
กรณีนี้ต้องแยก Control Plane ออกจาก Data Plane
OSPF Neighbor = FULL
|
v
Expected LSA = Present
|
v
Route = Installed
|
v
OSPF Control Plane
likely functioning
|
v
Now inspect Data Plane
ตรวจ:
- ARP
- Next Hop
- VLAN
- Trunk
- SVI
- ACL
- Firewall
- NAT
- Endpoint Gateway
- Return Route
- Application Port
Commands:
show ip route <destination>
show ip arp
ping <destination>
traceroute <destination>
Return Path สำคัญมาก
ตัวอย่าง:
PC-A
|
| Forward path OK
v
R1 ---- R2 ---- R3
|
v
Server
Server Reply
|
X
No return route
จากมุมของ PC-A อาจดูเหมือนว่า OSPF Route ไป Server เสีย ทั้งที่ Forward Path ทำงานถูกต้อง แต่ Reply กลับไม่ได้
ภาค 8: Cisco OSPF Troubleshooting Lab
Lab: หา Fault ทีละขั้น
Topology:
LAN-A
192.168.10.0/24
|
R1
|
10.0.12.0/30
|
R2
|
10.0.23.0/30
|
R3
|
LAN-C
192.168.30.0/24
Expected OSPF Design:
R1 --- R2 --- R3
Area 0
R1 RID = 1.1.1.1
R2 RID = 2.2.2.2
R3 RID = 3.3.3.3
R1
router ospf 1
router-id 1.1.1.1
network 192.168.10.0 0.0.0.255 area 0
network 10.0.12.0 0.0.0.3 area 0
R2
router ospf 1
router-id 2.2.2.2
network 10.0.12.0 0.0.0.3 area 0
network 10.0.23.0 0.0.0.3 area 0
R3
router ospf 1
router-id 3.3.3.3
network 10.0.23.0 0.0.0.3 area 0
network 192.168.30.0 0.0.0.255 area 0
Scenario 1 — R1 ไม่เห็น R2 เป็น Neighbor
เริ่มจาก:
R1# show ip interface brief
R1# show ip ospf interface brief
R1# show ip ospf neighbor
จากนั้น:
R1# show ip ospf interface GigabitEthernet0/1
R2# show ip ospf interface GigabitEthernet0/0
เปรียบเทียบ:
- IP/Subnet
- Area
- Hello/Dead
- Network Type
- Authentication
- Passive Interface
Scenario 2 — Neighbor FULL แต่ R1 ไม่เห็น LAN-C
ตรวจ R3 ก่อน:
R3# show ip route 192.168.30.0
R3# show ip ospf interface brief
ตรวจ R2:
R2# show ip ospf database
R2# show ip route ospf
ตรวจ R1:
R1# show ip ospf database
R1# show ip route 192.168.30.0
R1# show ip route ospf
Scenario 3 — R1 มี Route แต่ PC-A ติดต่อ Server-C ไม่ได้
ตอนนี้อย่าจำกัดการตรวจอยู่ที่ OSPF
PC-A
|
+-- IP correct?
|
+-- Gateway correct?
|
v
R1
|
+-- Route to LAN-C?
|
v
R2
|
v
R3
|
+-- Route back to LAN-A?
|
v
Server-C
|
+-- Gateway?
+-- Firewall?
+-- Service?
ตรวจ Forward และ Return Path ทั้งสองทิศทาง
ภาค 9: Workflow สำหรับงานจริง
OSPF Troubleshooting Workflow
START
|
v
Interface up/up?
|
+-- NO --> Fix Layer 1/2/Interface
|
YES
|
v
Correct IP/Subnet?
|
+-- NO --> Fix addressing
|
YES
|
v
OSPF enabled on interface?
|
+-- NO --> Check network/interface config
|
YES
|
v
Expected neighbor exists?
|
+-- NO --> Area/Timer/Auth/Passive/
| Network Type/Protocol 89
|
YES
|
v
Neighbor FULL when expected?
|
+-- NO --> Check state, MTU, DBD,
| packet loss, DR/BDR context
|
YES
|
v
Expected LSA in LSDB?
|
+-- NO --> Check origin, area,
| ABR/ASBR, filtering
|
YES
|
v
Expected route in RIB?
|
+-- NO --> Check SPF, AD,
| route selection, summary
|
YES
|
v
Forwarding works?
|
+-- NO --> ARP/ACL/Firewall/NAT/
| VLAN/Next Hop
|
YES
|
v
Return path works?
|
+-- NO --> Fix reverse routing/policy
|
YES
|
v
Check application
หลัก Safety ก่อนแก้ Configuration
- บันทึก Current State
- ระบุ Expected State
- เก็บ Output ของคำสั่ง show ที่เกี่ยวข้อง
- ระบุ Root Cause ที่สงสัย
- เปลี่ยนทีละตัวแปรเมื่อเป็นไปได้
- กำหนด Verification Test
- เตรียม Rollback
- ตรวจผลกระทบต่อ Remote Sites
ตัวอย่าง Change Record:
Problem:
R1 cannot learn 192.168.30.0/24
Evidence:
Neighbor R1-R2 = FULL
LSA for destination missing
Suspected cause:
R3 LAN interface not participating in OSPF
Change:
Correct OSPF interface/network configuration
Expected:
Prefix appears in LSDB and RIB
Verify:
show ip ospf database
show ip route 192.168.30.0
ping / traceroute
Rollback:
Restore previous OSPF configuration
clear ip ospf process
เป็นวิธีทดลองแบบสุ่ม
บน Production Network
เพราะ OSPF Adjacencies
และ Routing State
อาจถูกสร้างใหม่และกระทบ Traffic
Cisco OSPF Troubleshooting Command Cheat Sheet
| Command | ใช้ตรวจ |
|---|---|
show ip interface brief |
Interface และ IP Address |
show interfaces |
Errors, MTU, Link State และ Interface Details |
show ip ospf |
OSPF Process, Router ID, Area และ SPF Information |
show ip ospf interface brief |
OSPF Interfaces และ Area |
show ip ospf interface |
Timer, Cost, Network Type, DR/BDR และรายละเอียด Interface |
show ip ospf neighbor |
Neighbor และ Adjacency State |
show ip ospf database |
LSDB |
show ip ospf database router |
Router LSA |
show ip ospf database network |
Network LSA |
show ip ospf database summary |
Inter-Area Summary Information |
show ip ospf database external |
External LSA |
show ip ospf database nssa-external |
NSSA External LSA |
show ip ospf border-routers |
ABR/ASBR Information |
show ip route ospf |
Routes ที่ OSPF ติดตั้ง |
show ip route <destination> |
Route Selection สำหรับ Destination |
show ip protocols |
Routing Protocol Information |
show ip arp |
ARP/Next-Hop Resolution |
ping |
Reachability Test |
traceroute |
ตรวจเส้นทางโดยประมาณ |
ตารางวิเคราะห์อาการ OSPF แบบเร็ว
| อาการ | จุดตรวจหลัก |
|---|---|
| ไม่เห็น Neighbor | Interface, OSPF Enablement, Area, Passive, Protocol 89 |
| Neighbor INIT | Two-way Hello Communication |
| Neighbor 2-WAY | ตรวจ DR/BDR และ Network Type ก่อนสรุปว่าเสีย |
| EXSTART/EXCHANGE ค้าง | MTU, DBD Exchange, Packet Loss, Interface Stability |
| Neighbor FULL แต่ Route หาย | LSDB, LSA, SPF, RIB, Filtering |
| O IA หาย | ABR, Area 0, Type 3, Area Type |
| External Route หาย | ASBR, Redistribution, Type 5/7, NSSA |
| Summary Route ผิด | Prefix/Mask, ABR/ASBR, area range, summary-address |
| Route มีแต่ Ping ไม่ผ่าน | ARP, ACL, Firewall, NAT, VLAN, Return Path |
| บางปลายทางผ่าน บางปลายทางไม่ผ่าน | Longest Prefix Match, Summary, More-Specific Routes |
คำถามที่พบบ่อย — FAQ
คำสั่งแรกที่ควรใช้เมื่อ OSPF มีปัญหาคืออะไร?
ไม่มีคำสั่งเดียวที่เหมาะกับทุกกรณี
แต่โดยทั่วไปควรเริ่มจาก
show ip interface brief,
show ip ospf interface brief
และ show ip ospf neighbor
เพื่อแยก Interface, OSPF Participation
และ Neighbor State ก่อน
Neighbor ต้องเป็น FULL ทุกตัวหรือไม่?
ไม่เสมอไป บน Broadcast Multiaccess Network DROTHER Routers สามารถอยู่ 2-WAY ระหว่างกันได้ตามปกติ ขณะที่สร้าง Full Adjacency กับ DR/BDR ตาม OSPF Behavior
Neighbor FULL หมายความว่า Network ใช้งานได้แน่นอนหรือไม่?
ไม่ FULL แสดงว่า OSPF Adjacency และ Database Synchronization ที่จำเป็นระหว่าง Routers สำเร็จ แต่ Data Traffic ยังอาจติด ACL, Firewall, NAT, Return Route หรือปัญหา Layer 2 ได้
Neighbor ค้าง EXSTART ควรตรวจอะไร?
ควรตรวจ MTU, Interface Stability, Database Description Exchange และ Parameters ที่เกี่ยวข้อง ไม่ควรรีบใช้คำสั่ง Ignore MTU เป็นวิธีแก้ถาวร
OSPF ใช้ TCP หรือ UDP Port อะไร?
OSPF ทำงานโดยตรงบน IP ด้วย IP Protocol Number 89 ไม่ใช้ TCP หรือ UDP Port แบบ BGP หรือ RIP
Route อยู่ใน LSDB แต่ไม่อยู่ใน Routing Table เป็นไปได้หรือไม่?
ได้ LSDB เป็นข้อมูล Link-State ที่ใช้ในการคำนวณ ขณะที่ Routing Table เป็นผลหลัง Route Calculation และ Route Selection จึงต้องตรวจ SPF, Administrative Distance, More-Specific Route และ Routing Policy เพิ่มเติม
ทำไมมี OSPF Route แล้ว Ping ยังไม่ได้?
Routing Table เป็นเพียง ส่วนหนึ่งของ Communication Path ยังต้องตรวจ ARP, Next Hop, VLAN, ACL, Firewall, NAT, Endpoint Gateway และ Return Path
ควรใช้ debug ip ospf หรือไม่?
Debug สามารถให้ข้อมูลละเอียด
แต่บน Production Router
ต้องใช้อย่างระมัดระวัง
เพราะ Debug บางประเภท
สร้าง Output จำนวนมาก
และเพิ่มภาระอุปกรณ์ได้
ควรเริ่มจากคำสั่ง
show ก่อน
และใช้ Debug แบบจำกัดขอบเขต
เมื่อมีเหตุผลชัดเจน
ควร Restart OSPF เมื่อแก้ปัญหาไม่ได้หรือไม่?
ไม่ควรใช้เป็นขั้นตอนแรก เพราะการ Reset Process สามารถทำให้ Neighbor Adjacencies และ Routing State ถูกสร้างใหม่ โดยไม่ได้แก้ Root Cause ที่แท้จริง
OSPF Troubleshooting ควรดู LSDB หรือ Routing Table ก่อน?
ขึ้นอยู่กับอาการ แต่เมื่อ Neighbor เป็น FULL และ Expected Route หาย การตรวจ LSDB ก่อน Routing Table ช่วยแยกได้ว่า ปัญหาอยู่ที่ LSA Propagation หรือ Route Calculation/Selection
สรุป
การ Troubleshoot OSPF ควรใช้กระบวนการที่เป็นลำดับ แทนการเปลี่ยน Configuration ตามการคาดเดา
Interface
|
v
IP Connectivity
|
v
OSPF Interface
|
v
Neighbor
|
v
LSDB / LSA
|
v
SPF
|
v
Routing Table
|
v
Forwarding
|
v
Return Path
|
v
Application
หาก Neighbor ไม่เกิด ให้เน้นตรวจ Interface, Area, Timer, Authentication, Passive Interface, Network Type และ OSPF Protocol 89
หาก Neighbor เป็น FULL แต่ Route หาย ให้เลื่อนการตรวจไปที่ LSDB, LSA, SPF, ABR/ASBR, Summarization และ Route Selection
หาก Route อยู่ใน Routing Table แต่ Traffic ยังไปไม่ถึง ให้หยุดโฟกัสเฉพาะ OSPF แล้วตรวจ Data Plane ทั้ง Forward และ Return Path
Neighbor FULL
!=
Application works
Route exists
!=
Return path exists
OSPF healthy
!=
Entire network healthy
แนวคิดนี้ทำให้การแก้ปัญหา มีหลักฐานรองรับ ลดการแก้ Configuration แบบสุ่ม และสามารถระบุ Root Cause ได้แม่นยำขึ้น
เมื่อจบชุด OSPF แล้ว หัวข้อถัดไปควรเข้าสู่ Gateway Redundancy: HSRP, VRRP และ First Hop Redundancy เพื่อแก้ข้อจำกัดสำคัญอีกจุดหนึ่ง: แม้ Dynamic Routing ระหว่าง Routers จะมี Redundancy แล้ว แต่ Default Gateway ของ End Devices ก็ต้องมี Redundancy เช่นกัน
Share your thoughts here
Join the conversation and share your perspective on this article.