Techerest

OSPF Advanced Troubleshooting บน Cisco: แก้ Neighbor, LSDB, LSA และ Routing

การแก้ปัญหา 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 ทำงานปกติ แต่ผู้ใช้ยังไม่สามารถสื่อสารกันได้

ภาค 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
หากไม่มี Baseline ผู้ดูแลอาจเห็น Route หรือ Neighbor แล้วไม่สามารถตัดสินได้ว่า สิ่งที่เห็นนั้นปกติหรือผิดปกติ

ภาค 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
Ping ไม่ผ่านไม่ได้พิสูจน์ว่า OSPF ต้องเสียเสมอไป เพราะ ICMP อาจถูก Filter แต่หาก Directly Connected Routers ไม่มี Basic IP Connectivity ควรตรวจ Layer 2/3 ก่อน

ขั้นที่ 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

หาก ACL หรือ Infrastructure Firewall อยู่ระหว่าง OSPF Routers ต้องพิจารณา IP Protocol 89 และ OSPF Multicast/Unicast Behavior ตาม Network Type

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 ร่วมด้วย

คำสั่งที่ใช้ Ignore MTU Check อาจมีอยู่บนบาง Platform แต่ไม่ควรใช้เป็นวิธีแก้หลัก โดยไม่ทราบว่าทำไม MTU ของสองฝั่งจึงไม่ตรงกัน

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 ไม่เกิดขึ้น

ค่า Default ขึ้นอยู่กับ OSPF Network Type และ Platform จึงไม่ควรจำค่าเดียว แล้วใช้กับทุก Interface โดยไม่ตรวจ Configuration จริง

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

อย่าปิด Authentication ใน Production เพียงเพื่อให้ Neighbor กลับมา FULL โดยไม่มี Change Control ควรหาสาเหตุของ Configuration mismatch ก่อน

Duplicate Router ID

OSPF Router ID ต้องไม่ซ้ำกันภายใน Routing Domain ที่เกี่ยวข้อง

ตรวจ:

show ip ospf

กำหนดแบบ Explicit:

router ospf 1
 router-id 1.1.1.1
การเปลี่ยน Router ID บน OSPF Process ที่กำลังทำงาน อาจต้องทำให้ Process นำค่าใหม่ไปใช้ ขั้นตอนและผลกระทบ ต้องพิจารณาตาม Platform และ Maintenance Plan ไม่ควร Reset Process ใน Production โดยไม่ประเมินผล

ภาค 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 แล้วถูกทิ้ง

หาก Summary Route ทำให้บาง Destination เข้าไม่ได้ อย่าแก้ด้วยการเพิ่ม Static Route แบบสุ่มทันที ให้ตรวจ Address Range, More-Specific Routes, Summary Boundary และ Return Path ก่อน

ภาค 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

ก่อนเปลี่ยน OSPF 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 ตรวจเส้นทางโดยประมาณ
Command Availability และ Output แตกต่างได้ตาม Cisco Platform, IOS/IOS XE Version และ Feature Set จึงควรตรวจ Context Help และ Documentation ของ Platform ที่ใช้งานจริง

ตารางวิเคราะห์อาการ 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 this
Facebook Share X
TECHEREST COMMUNITY

Share your thoughts here

Join the conversation and share your perspective on this article.

Comments will load when you reach this section.