Host EVPN yang senyap tidak pernah terselesaikan: ikuti ARP sampai ke binding

Endpoint terpasang, portnya aktif, dan host pemantau tetap tidak dapat menjangkaunya. Seseorang menjalankan ping dari sisi jauh dan semuanya mulai berfungsi, yang membuat masalah tampak intermiten dan fabric tampak tidak bersalah. Pola itu adalah tanda khas host senyap: ia jarang mengirim, jadi perilaku penemuan dan penyegaran fabric lebih penting daripada status lampirannya. Mulailah dengan satu IP, MAC, dan bridge domain yang dituju lalu ikuti pertukaran resolusi berikutnya.

Ikuti pertukaran ARP atau ND berikutnya

Untuk IPv4, amati pertukaran ARP host yang meminta; untuk IPv6, ikuti Neighbor Solicitation dan Advertisement. Pastikan permintaan masuk ke segmen lokal yang dituju dan VNI yang dituju, karena permintaan yang tidak pernah mencapai bridge domain yang benar tidak dapat dijawab oleh proxy mana pun.

Lalu lihat apa yang diketahui fabric tentang target. Rute hanya-MAC dapat mengidentifikasi tujuan Layer 2 sementara proxy masih belum memiliki binding IP-to-MAC untuknya. Keduanya catatan terpisah, dan memeriksa satu tidak memberi tahu apa pun tentang yang lain.

Jika binding yang valid ada, proxy dapat menjawab sesuai kebijakannya, tetapi MAC dalam binding itu tetap memerlukan jalur penerusan yang aktif. Jika binding tidak ada, permintaan harus mencapai lampiran endpoint melalui jalur flooding atau replikasi sebelum apa pun dapat belajar dari balasannya.

Dua catatan yang harus cocok

Rute MAC menjawab di mana alamat Ethernet berada. Tabel proxy menjawab IP mana yang dipetakan ke MAC mana. Host yang belum berbicara baru-baru ini dapat memiliki rute MAC yang sangat baik dan tidak memiliki entri proxy yang dapat digunakan, dan itulah tepatnya keadaan yang menghasilkan kegagalan resolusi pada lampiran yang sehat.

Di lampiran jauh, periksa apakah endpoint benar-benar menerima dan menjawab pertukaran itu. Balasannya menyegarkan pembelajaran lokal dan pengumuman EVPN yang sesuai, itulah sebabnya ping manual tampak memperbaiki keadaan: Anda menghasilkan lalu lintas yang ditunggu fabric. Itu juga menjelaskan mengapa perbaikannya tidak bertahan: begitu entri yang disegarkan menua, endpoint kembali senyap. Ping terjadwal mengobati gejalanya dan menyembunyikan celah desain.

Setelah balasan, ikuti rute yang dipilih dan status penerusan yang terpasang kembali menuju peminta. Resolusi berhasil dan penerusan berhasil adalah dua peristiwa terpisah, dan tiket yang mencampuradukkannya mengirim Anda ke lapisan yang salah.

Apa yang sebenarnya diasumsikan standar

RFC 9161 menjelaskan pembelajaran proxy dinamis dan flooding default atas permintaan ARP dan ND yang tidak dikenal. Penindasan penuh atas flooding itu terbatas pada penerapan yang asumsi pembelajaran atau penyediaannya membuatnya aman, yang merupakan syarat lebih sempit daripada yang disiratkan sebagian besar panduan konfigurasi.

Fabric yang mengharapkan endpoint yang baru ditemukan memerlukan jalur yang berfungsi untuk permintaan tersebut. Jika seseorang menonaktifkan flooding permintaan tak dikenal untuk mengurangi lalu lintas BUM, host senyap adalah populasi yang membayarnya, dan gejalanya datang berminggu-minggu kemudian sebagai keluhan keterjangkauan intermiten.

Bacalah pengaturan penindasan sebagai pernyataan tentang apa yang dijanjikan fabric untuk diketahui. Jika tidak ada yang menyediakan binding, janji itu tidak berlaku bagi pengirim yang jarang. Bandingkan penindasan yang dikonfigurasi dengan sistem penyediaan yang seharusnya memberinya masukan. Ketika keduanya tidak sepakat, fabric berperilaku persis seperti yang dikonfigurasi, dan ekspektasinya yang perlu diperbaiki.

Penyegaran, penuaan, dan alternatif statis

Standar menjelaskan probe penyegaran yang didukung sebelum entri dinamis menua. Balasan menyegarkan status bridge dan proxy yang relevan; tidak adanya balasan secara sah dapat menyebabkan penghapusan dan penarikan rute. Itu bukan bug yang harus ditindas dengan meregangkan setiap timer.

Memperpanjang timer penuaan tanpa batas menukar kegagalan yang terlihat dengan kegagalan yang basi: fabric terus mengumumkan lokasi yang telah ditinggalkan host. Gunakan kontrol terdokumentasi dari implementasi dan pilih masa hidup yang sesuai dengan seberapa sering endpoint dapat diharapkan berbicara.

Untuk endpoint yang dikenal dan dikelola, binding statis atau yang disediakan pengontrol adalah model kedua yang sah. Binding itu memerlukan pemilik yang menangani penggantian dan perpindahan, karena catatan yang disediakan tidak memperbarui dirinya saat host pindah ke port lain.

Apa yang harus dicatat sebelum tiket berikutnya

Simpan sumber binding, waktu penyegaran terakhir, lokasi saat ini, dan setiap peristiwa penarikan di samping rute MAC. Catatan itu menjawab pertanyaan yang sebenarnya diajukan tiket: apakah aplikasi menunggu penemuan, mengandalkan status basi, atau gagal meneruskan setelah resolusi berhasil?

Lalu putuskan mana dari ketiganya yang bersedia Anda operasikan. Penemuan dengan flooding, penyegaran dengan masa hidup yang realistis, atau penyediaan dengan pemilik semuanya dapat dipertahankan. Fabric yang dikonfigurasi untuk satu hal dan diharapkan berperilaku seperti yang lain adalah tempat host senyap menghilang.