View source for Cisco : Praktikum Uji OSPF dan Diagnosa Neighbor Stuck

== 🎯 Tujuan ==
Setelah menyelesaikan lab ini, kamu bisa:

* Membaca **tujuh status neighbor** OSPF dan tahu artinya, bukan sekadar melihat kata `FULL`.
* Memetakan satu gejala ke **lapis mana yang gagal**: hello, pertukaran database, atau permintaan LSA.
* Membangun lab tiga router yang benar-benar berjalan, lalu **merusaknya dengan sengaja** satu per satu.
* Membedakan kegagalan yang terlihat di **kedua sisi** dan kegagalan yang hanya terlihat di **satu sisi**.
* Menjelaskan ke guru atau atasan **kenapa** adjacency gagal, dengan bukti perintah, bukan tebakan.

== 📍 Konteks nyata ==
Bayangkan pos ronda di tiga kampung yang harus saling melapor tiap malam. Malam pertama mereka hanya saling menyapa lewat pagar: "pos sini hidup". Itu baru **kenalan**, belum **kerja sama**.

Supaya bisa membagi jadwal ronda, mereka harus duduk di satu meja dan **bertukar buku catatan** sampai isinya sama. Dalam OSPF, pos yang baru saling menyapa ada di status `INIT`, dan yang catatannya sudah sama persis ada di status `FULL`.

Masalahnya, dari luar semua terlihat sama: kabel tersambung, lampu nyala, ping ke tetangga langsung jalan. Yang membedakan hanya satu perintah, `show ip ospf neighbor`, dan satu kata status di dalamnya.

🔥 '''Kasus nyata:''' sebuah SMK menyiapkan lab UKK dengan tiga router. Siswa menambah router keempat dengan menyalin konfigurasi router ketiga, termasuk `router-id`-nya. Kabel benar, IP benar, ping antar router tembus, tetapi rute ke LAN server tidak pernah muncul. Dua hari dihabiskan mengganti kabel dan modul serial. Penyebab sebenarnya terlihat dalam 10 detik: kedua router memakai router ID yang sama, jadi hello masing-masing **dibuang** dan status berhenti di `INIT`.

== 🧠 Konsep singkat ==
Tesis utama artikel ini: **neighbor yang tidak `FULL` selalu berhenti di satu lapis tertentu, dan status di layar menunjukkan lapis itu.** Jadi tugas kita bukan "coba-coba", tapi membaca status lalu memeriksa hal yang memang diperiksa di lapis tersebut.

=== 🔹 Tujuh status sebagai tangga ===
Status neighbor naik berurutan. Kalau berhenti di satu anak tangga, penyebabnya ada di pemeriksaan anak tangga itu.

{| class="wikitable"
! Status
! Arti dalam bahasa awam
! Yang biasanya menahan di sini
|-
| `Down`
| Belum ada kabar sama sekali dari tetangga
| kabel mati, interface `shutdown`, OSPF tidak aktif di salah satu sisi, ACL membuang hello
|-
| `Attempt`
| Hanya muncul di link NBMA (Frame Relay); router mengetuk pintu tetangga yang dikonfigurasi manual
| alamat neighbor salah, PVC belum aktif
|-
| `Init`
| Hello sudah diterima, tapi nama kita belum tercantum di hello balasan
| komunikasi satu arah: ACL, filter multicast, atau satu sisi belum mengenal kita
|-
| `2-Way`
| Saling mengenal, tapi belum bertukar database
| normal untuk sesama DROTHER di jaringan broadcast; kalau semua `2-Way`, tidak ada DR terpilih
|-
| `ExStart`
| Sedang bernegosiasi siapa yang jadi "ketua" pertukaran database
| MTU berbeda, router ID kembar, urutan DBD kacau
|-
| `Exchange`
| Database descriptor (daftar isi database) sedang ditukar
| MTU berbeda, paket DBD besar ditolak sisi lain
|-
| `Loading`
| Sudah minta LSA yang kurang, tapi jawabannya belum datang
| LSA rusak, paket LSR/LSU tidak sampai, biasanya disertai `%OSPF-4-BADLSA`
|-
| `Full`
| Database sudah sama, siap meneruskan paket
| tujuan tercapai
|}

📊 '''Angka penting:''' status yang berhenti di `Init` atau `ExStart` hampir selalu bukan masalah routing, tapi masalah **penyaringan atau ketidakcocokan parameter**. Rute tidak akan pernah muncul selama status belum `Full`.

=== 🔹 Lima hal yang harus sama di paket Hello ===
Hello adalah kartu nama yang dikirim tiap interval. Kalau isinya berbeda, kartu itu langsung dibuang tanpa jawaban.

# **Area ID** — interface di area 0 hanya bicara dengan area 0.
# **Hello dan dead interval** — 10/40 detik pada broadcast dan point-to-point; 30/120 pada NBMA.
# **Subnet dan subnet mask** — harus sama persis, bukan hanya "masih satu jaringan".
# **Area type** — satu sisi `stub`, sisi lain normal, tidak akan cocok.
# **Autentikasi** — tipe dan kunci harus sama.

Yang **tidak** ada di hello tetapi tetap menentukan: **router ID harus unik**, dan **MTU interface harus sama** (diperiksa saat DBD, bukan saat hello). Dua hal terakhir inilah yang paling sering lolos dari pemeriksaan pemula.

=== 🔹 Tiga nyawa adjacency dan aturan berhenti ===
* **Nyawa 1 — Hello.** Sampai status `2-Way`. Bukti: `show ip ospf interface`, `show ip ospf neighbor`, `debug ip ospf adj`.
* **Nyawa 2 — DBD.** Dari `ExStart` ke `Exchange`. Bukti: `debug ip ospf adj` yang menyebut MTU, dan `show ip ospf neighbor` yang berhenti di dua status itu.
* **Nyawa 3 — LSR/LSU.** Dari `Loading` ke `Full`. Bukti: `show ip ospf database`, log `BADLSA`.

Aturan kerjanya sederhana: **berhenti di lapis pertama yang gagal.** Jangan memeriksa MTU kalau statusnya masih `Down` — itu seperti membongkar mesin saat bensinnya habis.

=== 🔹 Kenapa 2-WAY bukan selalu rusak ===
Di jaringan broadcast seperti Ethernet, semua router tidak perlu berteman penuh satu sama lain. Mereka memilih **DR (Designated Router)** dan **BDR**, lalu semua router hanya membentuk adjacency penuh dengan dua perangkat itu.

Router yang bukan DR/BDR disebut **DROTHER**. Sesama DROTHER tetap di `2-Way` dan itu **normal**. Jadi kalau kamu melihat `2WAY/DROTHER`, jangan panik — periksa dulu apakah DR dan BDR sudah terpilih.

⚠️ '''Hati-hati:''' kalau **semua** neighbor di satu segmen berhenti di `2-Way`, berarti tidak ada DR terpilih. Penyebab paling umum: semua router diberi `ip ospf priority 0`, atau semua router memakai router ID yang sama.

=== 🔹 Angka timer yang dipakai sebagai bukti ===
{| class="wikitable"
! Parameter
! Broadcast / point-to-point
! NBMA
|-
| Hello interval
| 10 detik
| 30 detik
|-
| Dead interval
| 40 detik
| 120 detik
|-
| Wait timer (pemilihan DR)
| sama dengan dead interval
| sama dengan dead interval
|-
| Retransmit DBD/LSR
| 5 detik
| 5 detik
|}

🧪 '''Uji cepat:''' `show ip ospf interface` menampilkan satu baris `Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5`. Bandingkan baris itu di kedua router. Kalau angkanya beda, selesai — tidak perlu mencari ke tempat lain.

💡 '''Tips:''' di IOS, mengubah `ip ospf hello-interval` biasanya otomatis menggeser dead interval ke empat kali nilai baru. Jangan bergantung pada perilaku itu: set `hello-interval` dan `dead-interval` secara eksplisit di kedua sisi, lalu buktikan lewat `show ip ospf interface`.

== 🧩 Istilah penting ==
{| class="wikitable"
! Istilah
! Penjelasan singkat
|-
| Neighbor
| Router lain yang hello-nya kita dengar. Belum tentu bertukar rute.
|-
| Adjacency
| Hubungan neighbor yang sudah sampai `Full` dan bertukar database.
|-
| Hello packet
| Kartu nama berkala ke alamat multicast `224.0.0.5`.
|-
| Dead interval
| Batas waktu menunggu hello; lewat dari itu neighbor dianggap mati.
|-
| DBD (Database Description)
| Daftar isi database link-state, ditukar saat `ExStart` dan `Exchange`.
|-
| LSR / LSU
| Permintaan LSA tertentu, dan jawabannya berisi LSA lengkap.
|-
| LSA
| Satu lembar informasi topologi (siapa terhubung ke siapa, biaya berapa).
|-
| DR / BDR
| Ketua dan wakil ketua segmen broadcast; mengumpulkan dan menyebarkan LSA.
|-
| DROTHER
| Router yang bukan DR dan bukan BDR; cukup `2-Way` dengan sesama DROTHER.
|-
| Router ID
| Nama unik router di OSPF; harus beda di seluruh domain.
|-
| Passive interface
| Interface yang tetap diumumkan jaringannya, tapi tidak mengirim hello.
|-
| Wildcard mask
| Kebalikan subnet mask, dipakai di perintah `network`.
|}

== 🔧 Praktik: Membangun Lab dan Membuktikan Adjacency ==
Kita pakai tiga router dengan dua jenis link sekaligus: satu segmen **broadcast** lewat switch, dan satu link **serial point-to-point**. Dua jenis link ini memberi dua perilaku adjacency yang berbeda, dan itu yang mau kita buktikan.

{| class="wikitable"
! Perangkat
! Interface
! Alamat IP
! Keterangan
|-
| R1
| G0/0
| 10.20.1.1/24
| LAN siswa, arah PC1
|-
| R1
| G0/1
| 10.20.12.1/24
| segmen broadcast ke SW0
|-
| R2
| G0/1
| 10.20.12.2/24
| segmen broadcast ke SW0
|-
| R2
| S0/1/0
| 10.20.23.1/30
| ke R3, sisi DCE
|-
| R3
| S0/1/0
| 10.20.23.2/30
| ke R2
|-
| R3
| G0/0
| 10.20.3.1/24
| LAN server
|-
| PC1
| Fa0
| 10.20.1.10/24
| gateway 10.20.1.1
|-
| Server
| Fa0
| 10.20.3.10/24
| gateway 10.20.3.1
|}

Tambahkan loopback di tiap router: R1 `1.1.1.1/32`, R2 `2.2.2.2/32`, R3 `3.3.3.3/32`. Loopback dipakai sebagai router ID yang stabil dan tidak ikut mati saat kabel dicabut.

=== 🔹 Langkah 1–6: bangun lab dan rekam baseline ===
# '''Bangun topologi dan alamat.** Pasang IP di semua interface, `no shutdown`, dan di sisi DCE serial tambahkan `clock rate 64000` sebelum link mau naik.
# '''Buktikan kondisi "sebelum".** Di R1 jalankan `show ip route`. Yang muncul hanya `C` (connected) dan `L` (local). Ping dari PC1 ke `10.20.3.10` **gagal**. Catat ini sebagai baseline — tanpa baseline, kamu tidak punya pembanding saat uji rusak.
# '''Tentukan router ID eksplisit** di ketiga router, lalu aktifkan OSPF dengan satu perintah `network` yang mencakup seluruh lab.
<syntaxhighlight lang="text">
R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1
R1(config-router)# network 10.20.0.0 0.0.255.255 area 0
R1(config-router)# passive-interface g0/0
</syntaxhighlight>
# '''Ulangi di R2 (`router-id 2.2.2.2`) dan R3 (`router-id 3.3.3.3`).** `passive-interface` hanya dipasang di interface yang menghadap pengguna atau server, **bukan** di link antar router.
# '''Rekam kondisi sehat.** Jalankan empat perintah ini dan simpan hasilnya:
<syntaxhighlight lang="text">
show ip ospf neighbor
show ip ospf interface brief
show ip ospf database
show ip route ospf
</syntaxhighlight>
# '''Uji ujung ke ujung.** Ping PC1 ke server, lalu `traceroute`. Di R1, rute ke LAN server seharusnya tampil sebagai `O 10.20.3.0/24 [110/65] via 10.20.23.2` — angka 65 berasal dari cost link serial (64) ditambah cost interface (1).

📊 '''Angka penting:''' cost OSPF dihitung dari **reference bandwidth 100 Mbps dibagi bandwidth interface**. Hasilnya: Gigabit = 1, FastEthernet = 10, serial 1.544 Mbps = 64. Karena itu jalur lewat serial selalu terasa "mahal" dibanding Ethernet.

=== 🔹 Uji A: area berbeda ===
Di R3, ubah perintah network menjadi `area 1`, lalu `clear ip ospf process`.

* **Yang terjadi:** R2 kehilangan neighbor R3. Status tidak pernah naik, karena hello ditolak sebelum diproses.
* **Bukti:** `show ip ospf neighbor` di R2 kosong untuk R3, sementara `show ip ospf interface s0/1/0` di R2 tertulis `Area 0` dan di R3 tertulis `Area 1`.
* **Log:** muncul `%OSPF-4-ERRRCV` dengan keterangan area ID tidak cocok.
* **Pelajaran:** area bukan label administratif. Dua interface di area berbeda **tidak akan pernah** berteman, walau IP-nya satu subnet.

Kembalikan ke `area 0`, jalankan `clear ip ospf process`, lalu pastikan `FULL` lagi sebelum lanjut.

=== 🔹 Uji B: timer hello dan dead berbeda ===
Di R1 interface G0/1, jalankan `ip ospf hello-interval 5` lalu `ip ospf dead-interval 20`.

* **Yang terjadi:** hello R1 datang tiap 5 detik, tapi R2 mengharapkan 10 detik — paket dibuang. Sebaliknya hello R2 juga ditolak R1.
* **Bukti:** `show ip ospf interface g0/1` di R1 menampilkan `Hello 5, Dead 20`, di R2 tetap `Hello 10, Dead 40`. Neighbor hilang dari kedua sisi.
* **Pelajaran:** timer yang tidak cocok memberi gejala yang **mirip kabel putus**, padahal link tetap up dan ping ke IP tetangga tetap jalan.

🧪 '''Uji cepat:''' ping ke IP tetangga **berhasil** tetapi `show ip ospf neighbor` kosong? Curigai timer, area, atau ACL — bukan kabel.

=== 🔹 Uji C: subnet dan mask berbeda ===
Di R2 G0/1, ubah alamat menjadi `10.20.12.2 255.255.255.128`. Alamat masih terasa "satu jaringan", tapi mask-nya berbeda.

* **Yang terjadi:** neighbor tidak terbentuk. OSPF membandingkan **subnet dan mask**, bukan hanya apakah IP saling terjangkau.
* **Bukti:** di R2, `show ip ospf interface g0/1` menampilkan `10.20.12.2/25`; di R1 tetap `/24`. Ping ke `10.20.12.1` pun bisa jadi masih jalan karena keduanya berada di rentang yang sama.
* **Pelajaran:** "masih bisa ping" bukan bukti parameter OSPF cocok. Ini penyebab paling umum adjacency gagal di lab siswa.

Kembalikan ke `/24` sebelum uji berikutnya.

=== 🔹 Uji D: wildcard salah dan passive-interface ===
Dua kesalahan konfigurasi yang gejalanya identik: interface **tidak mengirim hello**.

* **Wildcard salah:** di R3 ganti network menjadi `network 10.20.23.0 0.0.0.255 area 0`. Wildcard `0.0.0.255` mencakup jauh lebih luas dari /30, tetapi yang lebih penting: pastikan interface benar-benar masuk. Periksa `show ip ospf interface brief` — kalau `S0/1/0` tidak terdaftar, OSPF tidak berjalan di sana.
* **Passive salah tempat:** di R1 jalankan `passive-interface g0/1`. Interface tetap punya alamat dan tetap diumumkan, tapi berhenti mengirim hello.
* **Bukti:** `show ip ospf interface g0/1` menampilkan keterangan `No Hellos (Passive interface)`, dan `show ip ospf neighbor` kosong.

💡 '''Tips:''' biasakan membaca `show ip ospf interface brief` lebih dulu daripada `show ip ospf neighbor`. Kolom area dan cost di situ langsung menunjukkan interface mana yang **tidak ikut** OSPF — penyebab yang tidak akan pernah muncul di daftar neighbor.

=== 🔹 Uji E: hello satu arah (stuck INIT) ===
Ini uji paling penting untuk memahami arti `INIT`. Di R2 G0/1, pasang ACL yang membuang hello masuk:

<syntaxhighlight lang="text">
R2(config)# access-list 101 deny ip any host 224.0.0.5
R2(config)# access-list 101 permit ip any any
R2(config)# interface g0/1
R2(config-if)# ip access-group 101 in
</syntaxhighlight>

* **Yang terjadi:** R2 tidak mendengar R1, jadi R2 tidak mencantumkan R1 di hello-nya. R1 mendengar R2, tapi namanya tidak disebut — R1 berhenti di `INIT`.
* **Bukti:** di R1 muncul `INIT/DROTHER`; di R2 daftar neighbor **kosong**. Satu masalah, dua wajah berbeda.
* **Log:** `debug ip ospf adj` di R1 menunjukkan hello diterima, tapi tidak ada kemajuan status.

⚠️ '''Hati-hati:''' sebagian platform dan versi IOS/Packet Tracer tidak memfilter multicast link-local lewat ACL interface. Kalau di lab-mu hello tetap lolos, gejalanya berubah menjadi "neighbor normal" — dan itu justru pelajaran bagus: **tidak semua ACL berlaku pada trafik kontrol**. Jangan simpulkan ACL selalu bisa memblokir OSPF.

=== 🔹 Uji F: router ID kembar ===
Ini kasus yang paling sering terjadi saat menyalin konfigurasi. Di R2 jalankan `router-id 1.1.1.1` (sama dengan R1), lalu `clear ip ospf process`.

* **Yang terjadi:** kedua router saling mengabaikan hello karena menganggap hello itu milik dirinya sendiri.
* **Bukti:** `show ip ospf` di kedua router menampilkan router ID yang sama; adjacency hilang dan bisa berhenti di `INIT`.
* **Log:** pada IOS tertentu muncul `%OSPF-4-DUP_RTRID_NBR`.
* **Pelajaran:** router ID adalah identitas, bukan sekadar hiasan. Selalu periksa `show ip ospf` di **kedua** sisi saat adjacency gagal tanpa sebab jelas.

=== 🔹 Uji G: MTU berbeda (stuck EXSTART/EXCHANGE) ===
Di R2 interface S0/1/0, jalankan `mtu 1400`, sementara R3 tetap 1500. Tunggu dead timer atau `clear ip ospf process`.

* **Yang terjadi:** hello tetap bertukar (keduanya `2-Way`), tapi saat DBD berisi ratusan LSA dikirim, paket itu lebih besar dari MTU sisi penerima dan **dibuang tanpa pesan**. Kedua router menunggu jawaban yang tidak pernah datang.
* **Bukti:** di satu sisi `EXSTART`, di sisi lain `EXCHANGE`. Ini pola khas MTU, bukan pola kabel.
* **Bukti tambahan:** `debug ip ospf adj` menampilkan `Nbr 10.20.23.1 has larger interface MTU`.
* **Perbaikan:** samakan MTU di kedua sisi, atau — hanya bila memang tidak bisa disamakan — `ip ospf mtu-ignore` di interface yang MTU-nya lebih kecil.

📊 '''Angka penting:''' DBD membawa field MTU milik pengirim. Sisi dengan MTU lebih kecil membandingkan angka itu dengan MTU-nya sendiri, lalu menolak. Karena itu masalahnya **tidak terlihat di hello** dan tidak akan pernah muncul di `show ip route`.

🔥 '''Kasus nyata:''' sebuah kantor cabang memasang link MPLS baru dengan MTU 1400, sementara router lama memakai 1500. Selama tiga minggu trafik memakai jalur cadangan berbasis static route yang jauh lebih lambat, dan tim mengira ISP bermasalah. Bukti akhirnya satu baris: `show ip ospf neighbor` menampilkan `EXSTART/EXCHANGE` hanya di link baru, dan `debug ip ospf adj` menyebut "larger interface MTU". Perbaikannya hanya `mtu 1400` di kedua ujung.

=== 🔹 Uji H: biaya jalur sebagai tuas ===
Di R2 interface S0/1/0, jalankan `ip ospf cost 10`. Sebelumnya biarkan cost bawaan (64 untuk serial 1.544 Mbps).

* **Yang terjadi:** total cost rute di R1 berubah dari `[110/65]` menjadi `[110/11]`. Rute tetap sama, angkanya yang berubah.
* **Bukti:** `show ip route ospf` di R1 dan `show ip ospf interface s0/1/0` di R2.
* **Pelajaran:** di OSPF, "jalur terbaik" ditentukan **jumlah cost**, bukan jumlah hop. Mengubah cost adalah cara resmi mengarahkan trafik tanpa menyentuh routing statis.
* **Naik level:** `auto-cost reference-bandwidth 1000` di semua router membuat Gigabit bernilai 1 dan FastEthernet bernilai 10, sehingga jalur cepat benar-benar menang. Nilai ini **wajib sama** di seluruh domain, kalau tidak, perhitungan cost antar router jadi tidak konsisten.

Kembalikan cost ke bawaan (`no ip ospf cost`) setelah uji selesai.

=== 🔹 Versi Packet Tracer (GUI) ===
* Tab **Config → Routing → OSPF** bisa menambahkan network dan area, tapi **tidak menampilkan status neighbor**. Verifikasi tetap lewat tab CLI.
* `debug ip ospf adj` didukung di Packet Tracer versi terbaru, dan inilah satu-satunya cara melihat alasan penolakan hello/DBD secara langsung.
* Pada 2911, modul serial harus ditambahkan lewat tab **Physical** sebelum interface `Se0/1/0` muncul.
* `mtu` pada interface Ethernet sering tidak bisa diubah di Packet Tracer. Karena itu uji MTU di artikel ini memakai **link serial** — pilih media yang memang mendukung perintahnya.

=== 🔹 Lembar hasil uji ===
Isi tabel ini sambil praktik. Kolom terakhir adalah inti keterampilannya: **satu gejala, satu bukti, satu kesimpulan.**

{| class="wikitable"
! Uji
! Perubahan
! Status yang muncul
! Bukti utama
! Kesimpulan
|-
| Baseline
| —
| `FULL/-` dan `FULL/DR`
| `show ip ospf neighbor`
| OSPF sehat
|-
| A
| area 1 di R3
| neighbor hilang
| `show ip ospf interface` area beda
| area wajib sama
|-
| B
| hello 5 / dead 20
| neighbor hilang
| baris `Timer intervals`
| timer wajib sama
|-
| C
| mask /25
| neighbor hilang
| alamat interface
| subnet + mask wajib sama
|-
| D
| `passive-interface`
| neighbor hilang
| `No Hellos (Passive interface)`
| passive mematikan hello
|-
| E
| ACL hello masuk
| `INIT` di satu sisi, kosong di sisi lain
| `show ip ospf neighbor` dua sisi
| satu arah = `INIT`
|-
| F
| router ID kembar
| `INIT` / hilang
| `show ip ospf` dua sisi
| ID wajib unik
|-
| G
| MTU 1400 vs 1500
| `EXSTART` / `EXCHANGE`
| `debug ip ospf adj`
| MTU wajib sama
|-
| H
| `ip ospf cost 10`
| tetap `FULL`, cost berubah
| `[110/11]`
| cost mengarahkan jalur
|}

== 🏭 Dipakai di dunia kerja ==
* **Sekolah dan lab UKK:** satu siswa menyalin konfigurasi router lain tanpa mengganti router ID, dan seluruh kelas kehilangan rute ke server nilai. Guru yang bisa membaca `show ip ospf neighbor` menyelesaikan ini dalam satu menit; yang tidak, akan mengganti kabel seharian.
* **Kantor cabang:** link baru dari provider sering datang dengan MTU berbeda (misalnya MPLS 1400 atau tunnel 1400). Tanpa kebiasaan memeriksa status `EXSTART`, tim akan menyalahkan ISP selama berminggu-minggu.
* **ISP dan NOC:** perubahan `hello-interval` di satu perangkat jarang terlihat di grafik monitoring, tetapi langsung memutus adjacency. NOC memakai status neighbor sebagai alarm pertama, sebelum alarm trafik.
* **Rumah sakit dan kampus:** jaringan gedung dengan banyak switch layer 3 menuntut semua router memakai `auto-cost reference-bandwidth` yang sama. Cost yang tidak konsisten membuat trafik rekam medis lewat jalur lambat tanpa ada yang sadar.
* **Industri:** segmentasi area produksi memakai beberapa area OSPF. Interface yang salah area akan "hidup" tetapi tidak pernah berteman, dan mesin tetap mengirim data ke jalur yang salah.
* **Data center:** underlay OSPF mengandalkan loopback sebagai router ID. Router ID yang berubah karena interface mati bisa memicu perhitungan ulang; karena itu router ID selalu dikunci manual.

== ✅ Verifikasi ==
{| class="wikitable"
! Perintah
! Yang dicari
! Kalau tidak sesuai
|-
| `show ip ospf neighbor`
| semua neighbor `FULL/-`, `FULL/DR`, atau `FULL/BDR`
| baca statusnya, lalu periksa lapis sesuai tabel
|-
| `show ip ospf interface brief`
| interface, area, dan cost sesuai rencana
| periksa perintah `network`, wildcard, dan `passive-interface`
|-
| `show ip ospf interface g0/1`
| baris timer dan status DR/BDR
| bandingkan dengan sisi tetangga
|-
| `show ip ospf`
| router ID unik, jumlah area benar
| ganti router ID, lalu `clear ip ospf process`
|-
| `show ip protocols`
| proses OSPF aktif dan sumber rute
| OSPF mungkin tidak berjalan sama sekali
|-
| `show ip ospf database`
| jumlah LSA sebanding di semua router
| flooding belum selesai atau area belum sinkron
|-
| `show ip route ospf`
| baris `O` untuk LAN lawan
| prefix belum diumumkan atau disaring
|-
| `ping` dan `traceroute`
| tembus dua arah, jalur sesuai cost
| periksa rute balik dan ACL
|}

🧪 '''Uji cepat:''' satu perintah untuk memastikan tidak ada yang tertinggal —
<syntaxhighlight lang="text">
show ip ospf neighbor | include FULL
</syntaxhighlight>
Bandingkan jumlah barisnya dengan jumlah neighbor yang seharusnya. Kalau kurang satu, cari yang statusnya `INIT`, `EXSTART`, atau `2-WAY`.

📊 '''Angka penting:''' dead timer 40 detik berarti kamu tidak perlu panik saat adjacency baru putus — beri waktu minimal 40 detik sebelum menyimpulkan. Setelah `clear ip ospf process`, adjacency biasanya kembali dalam 5–15 detik pada lab kecil.

== ⚠️ Kesalahan umum & troubleshooting ==
{| class="wikitable"
! Gejala
! Status yang terlihat
! Penyebab tersering
! Perbaikan
|-
| Neighbor kosong, ping ke tetangga jalan
| tidak ada baris
| area, timer, atau mask berbeda; ACL membuang hello
| bandingkan `show ip ospf interface` kedua sisi
|-
| Neighbor kosong di kedua sisi
| tidak ada baris
| OSPF tidak aktif, `passive-interface`, interface `shutdown`
| `show ip ospf interface brief`
|-
| Hanya satu sisi yang melihat neighbor
| `INIT` di satu sisi, kosong di sisi lain
| komunikasi satu arah (ACL, filter multicast, kabel TX/RX)
| uji ACL dan `debug ip ospf adj`
|-
| Semua neighbor `2-WAY`
| `2WAY/DROTHER`
| semua router `priority 0` atau router ID kembar
| beri priority > 0 di satu router
|-
| Berhenti di `EXSTART`
| `EXSTART/EXCHANGE`
| MTU berbeda, router ID kembar
| samakan MTU atau `ip ospf mtu-ignore`
|-
| Berhenti di `EXCHANGE`
| `EXCHANGE/-`
| paket DBD ditolak karena terlalu besar
| samakan MTU kedua sisi
|-
| Berhenti di `LOADING`
| `LOADING/DR`
| LSA rusak atau LSR tidak dijawab
| `show ip ospf database`, cari `BADLSA`
|-
| `FULL` tapi rute tidak ada
| `FULL/-`
| `network` kurang, `passive` salah, filter distribusi
| `show ip ospf database`, `show ip protocols`
|-
| Rute ada tapi ping gagal
| `FULL/-`
| tidak ada rute balik, ACL, atau NAT
| periksa tabel routing di router terjauh
|-
| Rute muncul-hilang (flapping)
| `FULL` lalu `DOWN` berulang
| link tidak stabil, duplex mismatch, timer terlalu ketat
| periksa `show interface` untuk error dan CRC
|-
| Adjacency putus tiap ±40 detik
| `DOWN` berulang
| hello terbuang periodik, CPU penuh, atau queue penuh
| cek `show processes cpu` dan log
|-
| Cost tidak berubah setelah diubah
| `FULL`
| `auto-cost` atau cost interface di sisi lain
| periksa cost di **kedua** arah jalur
|}

⚠️ '''Hati-hati:''' `clear ip ospf process` memutus semua adjacency di router itu, bukan hanya satu neighbor. Di jaringan produksi, lakukan di jendela pemeliharaan — bukan saat jam ujian atau jam sibuk.

💡 '''Tips:''' saat mendampingi siswa, larang kata "coba ganti kabel" sebelum `show ip ospf neighbor` dijalankan. Satu perintah itu memotong 80 persen tebakan.

== 🔐 Catatan keamanan & etika ==
* **Aktifkan autentikasi OSPF** (`ip ospf authentication message-digest` + `area 0 authentication message-digest`) di jaringan nyata. Tanpa autentikasi, siapa pun yang bisa mengirim hello dapat mengaku sebagai router dan menyuntikkan rute palsu.
* **Jangan pernah menjalankan OSPF di interface yang menghadap internet.** Router tepi hanya boleh berteman dengan perangkat yang kamu kendalikan.
* **`passive-interface` adalah kontrol keamanan, bukan hanya efisiensi.** Interface pengguna yang tidak mengirim hello berarti tidak bisa dipakai menyusup ke proses routing.
* **`debug` hanya di lab atau jendela pemeliharaan.** `debug ip ospf adj` membebani CPU dan membanjiri log; lupakan perintah ini di jam kerja.
* **Semua praktik di artikel ini memakai alamat privat dan perangkat lab sendiri.** Menguji fault injection pada jaringan sekolah tanpa izin bisa memutus layanan ujian — itu bukan latihan, itu insiden.

== 📌 Kesimpulan ==
Status neighbor OSPF adalah **peta lokasi kegagalan**, bukan hiasan output. `INIT` menunjuk ke komunikasi satu arah, `EXSTART`/`EXCHANGE` menunjuk ke MTU atau router ID, dan `FULL` yang tidak diikuti rute menunjuk ke pengumuman network atau filter.

Kalau kamu bisa menyebut lapisnya lebih dulu sebelum menyentuh kabel, kamu sudah bekerja seperti network engineer — bukan seperti orang yang menebak.

Langkah berikutnya: setelah adjacency terbukti sehat, pelajari cara **membagikan alamat IP otomatis** ke PC dan server di lab yang sama lewat `Cisco : DHCP Server di Cisco`, supaya topologi ini bisa dipakai tanpa mengetik IP manual.

== 🔗 Materi terkait ==
* [[Cisco : OSPF Dasar]] — konsep pasangan artikel ini: area, cost, DR/BDR, dan wildcard mask.
* [[Cisco : Routing Statis di Cisco]] — pembanding: rute yang ditulis manual vs rute yang dipelajari otomatis.
* [[Cisco : Trunk dan Inter-VLAN Routing (Router-on-a-Stick)]] — prasyarat memahami segmen dan gateway.
* [[Cisco : Praktikum Uji Routing Statis dan Diagnosa Rute Tidak Terpakai]] — pola diagnosis lima lapis yang dipakai ulang di sini.
* [[Cisco : Dasar CLI Cisco IOS (Mode dan Konfigurasi Awal)]] — kalau masih bingung membedakan mode `config` dan `config-if`.
* [[Cisco : Praktikum Uji Mode CLI dan Diagnosa Konfigurasi Hilang]] — memastikan konfigurasi lab benar-benar tersimpan sebelum bubar.

== 📚 Referensi ==
* RFC 2328 — *OSPF Version 2*, bagian 10.1 (Neighbor states) dan 10.6 (Database Description). https://www.rfc-editor.org/rfc/rfc2328.txt
* Cisco — *Troubleshoot OSPF Neighbor Problems* (pemetaan gejala ke penyebab, tabel alasan adjacency gagal). https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13699-29.html
* Cisco — *Troubleshoot OSPF Neighbors Stuck in Exstart/Exchange State* (mekanisme MTU pada DBD, `ip ospf mtu-ignore`). https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13684-12.html
* Cisco — *Understand OSPF Neighbor States* (definisi resmi tiap status). https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13685-13.html
* Cisco IOS — *OSPF Commands*: `ip ospf hello-interval`, `ip ospf dead-interval`, `ip ospf priority`, `ip ospf cost`, `auto-cost reference-bandwidth`.

[[Category:TKJ]]
[[Category:Jaringan]]
[[Category:Cisco]]
[[Category:Packet Tracer]]