Modul ASA FirePOWER tidak memiliki rute manajemen ke FMC

FMC menampilkan modul sebagai tidak terjangkau, pendaftaran tetap tertunda, dan ping dari dalam ASA berjalan tanpa cela. Pada penerapan ASA FirePOWER yang sudah ada, kombinasi itu normal. Modul memiliki alamat manajemennya sendiri, gateway defaultnya sendiri, dan keputusan peruteannya sendiri, dan berbagi koneksi manajemen fisik dengan ASA pada beberapa platform tidak meleburkannya menjadi satu tumpukan jaringan. Dua perangkat menjawab dari dua sudut pandang berbeda pada kabel yang sama.

Berikut ini berlaku untuk modul yang sudah beroperasi. Identifikasi model sasis, jenis modul, dan versi perangkat lunak yang didukung sebelum menerapkan diagram port apa pun dari panduan.

Gambarkan modul sebagai host terpisah

Mulailah diagram dengan IP manajemen modul, mask, dan gateway default, VLAN yang benar-benar membawa koneksi itu, serta alamat FMC yang harus dicapai. Lalu, di kotak terpisah, tuliskan alamat antarmuka ASA dan tabel perutean lengkapnya. Jika kedua kotak akhirnya berbagi subnet dengan alamat milik pihak berbeda, Anda telah menemukan bagian menarik dari masalah ini.

Panduan modul ASA FirePOWER menunjukkan bagaimana susunan port berbeda antarpaltform, termasuk pengkabelan manajemen bersama di mana ASA dan modul membawa alamat terpisah pada segmen yang sama. Diagram perangkat keras itu adalah masukan bagi desain, bukan catatan kaki.

Temukan di mana jalur balik terputus

Ambil tata letak yang dirutekan melalui inti. Modul mengirim lalu lintas menuju FMC ke inti Layer 3, inti meneruskan tujuan manajemen jarak jauh ke antarmuka dalam ASA, dan VPN situs membawanya ke sisi lain. Situs jarak jauh kemudian membutuhkan rute balik ke subnet manajemen modul. Setiap lompatan dalam rantai itu bisa benar sementara rute terakhir tersebut hilang, dan itulah sebabnya kegagalan begitu sering tampak seperti terowongan yang rusak.

Baca pandangan ASA sendiri sebelum mengubah apa pun:

show interface ip brief
show route
show running-config interface

Perintah ketiga penting karena alamat antarmuka yang Anda lupakan justru yang membuat jalur balik mendarat di perangkat yang salah.

Periksa apa yang dianggap terhubung oleh ASA

Jika ASA memiliki alamat pada subnet manajemen modul, rute terhubungnya memiliki prefiks itu. Rute statis menuju inti tidak menggusur kepemilikan rute terhubung, sehingga paket kembali ke ASA dan berhenti di sana. Pendaftaran kemudian gagal pada titik yang tidak ada hubungannya dengan kredensial.

Jangan menyimpulkan bahwa pemeriksaan anti-spoofing tertentu membuang paket kecuali Anda memiliki pengamatan perangkat itu sendiri di depan Anda. Bandingkan saja antarmuka masuk, rute tujuan yang dipilih, dan batas penerusan antara manajemen dan data yang didukung untuk platform itu. Ketiga fakta itu biasanya menyingkap konflik topologi sebelum siapa pun mulai mengatur ulang kunci pendaftaran.

Pilih koreksi yang menjaga modul tetap terhubung

Menghapus alamat ASA dari segmen itu dan menonaktifkan port bersama secara fisik bukan tindakan yang setara. Pada platform tempat modul melewati koneksi manajemen fisik yang sama, menonaktifkan port menghilangkan satu-satunya tautan modul — Anda akan mengubah masalah perutean menjadi perangkat mati. Utamakan perubahan yang menetapkan ulang kepemilikan perutean manajemen, dan siapkan bersama pemilik jaringan.

Opsi kedua yang didukung adalah memberi jalur administratif ASA segmennya sendiri agar subnet manajemen modul hanya punya satu pemilik. Itu memakan satu alamat dan sedikit dokumentasi, dan menghilangkan ambiguitas secara permanen. Jalur mana pun yang Anda pilih, pastikan setelahnya modul masih dapat menjangkau FMC maupun sumber DNS atau NTP-nya.

Daftarkan hanya setelah jalurnya koheren

Setelah jalur balik bersih, rencanakan konektivitas manajemen dan parameter pendaftaran dari panduan rilis FMC dan modul yang sesuai. Jauhkan rahasia pendaftaran dari catatan dan tiket bersama, dan tahan godaan untuk mendaftar ulang sebagai langkah diagnostik: kunci baru pada jalur yang rusak hanya menghasilkan kegagalan yang sama dengan cap waktu lebih baru.

Terima jalur dari tumpukan manajemen modul sendiri, bukan dari ping yang berasal dari ASA, karena sumber pengujian justru hal yang dicurigai. Catat lompatan berikutnya modul, pilihan VPN ASA, dan rute balasan FMC, serta pertahankan metode pemulihan independen untuk kedua peran manajemen. Catatan itulah yang memisahkan transportasi yang diperbaiki dari pendaftaran yang berhasil.

Ketika modul akhirnya muncul di FMC, jalankan lagi tiga perintah yang sama dan simpan keluarannya di samping diagram. Orang berikutnya yang menyentuh segmen manajemen itu akan membutuhkan perbandingan itu.