Hos EVPN senyap tidak pernah diselesaikan: ikuti ARP hingga ke pengikatan

Titik akhir dilampirkan, portnya aktif, dan hos pemantauan masih tidak dapat mencapainya. Seseorang menjalankan ping dari sisi jauh dan ia mula berfungsi, yang membuat masalah kelihatan berselang-seli dan fabric kelihatan tidak bersalah. Corak itu ialah tandatangan hos senyap: ia jarang menghantar, jadi tingkah laku penemuan dan penyegaran fabric lebih penting daripada keadaan lampirannya. Mulakan dengan satu IP, MAC dan bridge domain yang dimaksudkan dan ikuti pertukaran penyelesaian seterusnya.

Ikuti pertukaran ARP atau ND seterusnya

Untuk IPv4, perhatikan pertukaran ARP hos yang meminta; untuk IPv6, ikuti Neighbor Solicitation dan Advertisement. Sahkan bahawa permintaan memasuki segmen setempat yang dimaksudkan dan VNI yang dimaksudkan, kerana permintaan yang tidak pernah sampai ke bridge domain yang betul tidak boleh dijawab oleh mana-mana proksi.

Kemudian lihat apa yang fabric tahu tentang sasaran. Laluan hanya-MAC boleh mengenal pasti destinasi Layer 2 sementara proksi masih belum mempunyai pengikatan IP-to-MAC untuknya. Itu rekod berasingan, dan memeriksa satu tidak memberitahu apa-apa tentang yang lain.

Jika pengikatan yang sah wujud, proksi boleh menjawab mengikut dasarnya, tetapi MAC dalam pengikatan itu masih memerlukan laluan penghantaran yang aktif. Jika pengikatan tiada, permintaan mesti sampai ke lampiran titik akhir melalui laluan flooding atau replikasi sebelum apa-apa boleh belajar daripada jawapannya.

Dua rekod yang mesti sepadan

Laluan MAC menjawab di mana alamat Ethernet berada. Jadual proksi menjawab IP mana yang dipetakan ke MAC mana. Hos yang tidak bercakap baru-baru ini boleh mempunyai laluan MAC yang sangat baik dan tiada entri proksi yang boleh digunakan, dan itulah keadaan yang menghasilkan kegagalan penyelesaian pada lampiran yang sihat.

Di lampiran jauh, periksa sama ada titik akhir benar-benar menerima dan menjawab pertukaran itu. Jawapannya menyegarkan pembelajaran setempat dan pengumuman EVPN yang berkaitan, itulah sebabnya ping manual kelihatan membaiki keadaan: anda menjana trafik yang ditunggu oleh fabric. Itu juga menjelaskan mengapa pembaikan tidak bertahan: sebaik sahaja entri yang disegarkan menjadi tua, titik akhir menjadi senyap semula. Ping berjadual merawat gejala dan menyembunyikan jurang reka bentuk.

Selepas jawapan, ikuti laluan yang dipilih dan keadaan penghantaran yang dipasang kembali ke arah peminta. Kejayaan penyelesaian dan kejayaan penghantaran ialah dua peristiwa berasingan, dan tiket yang mengelirukan kedua-duanya menghantar anda ke lapisan yang salah.

Apa yang sebenarnya diandaikan oleh standard

RFC 9161 menerangkan pembelajaran proksi dinamik dan flooding lalai bagi permintaan ARP dan ND yang tidak dikenali. Penindasan penuh flooding itu terhad kepada penggunaan yang andaian pembelajaran atau peruntukannya menjadikannya selamat, iaitu syarat yang lebih sempit daripada yang disiratkan oleh kebanyakan panduan konfigurasi.

Fabric yang menjangka titik akhir yang baru ditemui memerlukan laluan yang berfungsi untuk permintaan itu. Jika seseorang mematikan flooding permintaan tidak dikenali untuk mengurangkan trafik BUM, hos senyap ialah populasi yang membayarnya, dan gejalanya tiba beberapa minggu kemudian sebagai aduan kebolehcapaian berselang-seli.

Baca tetapan penindasan sebagai kenyataan tentang apa yang fabric janjikan untuk tahu. Jika tiada apa-apa yang memperuntukkan pengikatan, janji itu tidak benar untuk penghantar jarang. Bandingkan penindasan yang dikonfigurasikan dengan sistem peruntukan yang sepatutnya memberinya makan. Apabila kedua-duanya tidak bersetuju, fabric berkelakuan tepat seperti yang dikonfigurasikan, dan jangkaan itulah yang perlu diperbaiki.

Penyegaran, penuaan dan alternatif statik

Standard menerangkan prob penyegaran yang disokong sebelum entri dinamik menjadi tua. Jawapan menyegarkan keadaan bridge dan proksi yang berkaitan; ketiadaan jawapan boleh membawa secara sah kepada pembuangan dan penarikan balik laluan. Itu bukan pepijat yang perlu ditindas dengan meregangkan setiap pemasa.

Memperpanjang pemasa penuaan tanpa had menukar kegagalan yang kelihatan dengan kegagalan yang usang: fabric terus mengumumkan lokasi yang telah ditinggalkan oleh hos. Gunakan kawalan yang didokumenkan oleh pelaksanaan dan pilih jangka hayat yang sepadan dengan kekerapan titik akhir boleh dijangka bercakap secara munasabah.

Untuk titik akhir yang diketahui dan diurus, pengikatan statik atau yang diperuntukkan pengawal ialah model kedua yang sah. Ia memerlukan pemilik yang mengendalikan penggantian dan perpindahan, kerana rekod yang diperuntukkan tidak mengemas kini dirinya apabila hos berpindah ke port lain.

Apa yang perlu direkodkan sebelum tiket seterusnya

Simpan sumber pengikatan, masa penyegaran terakhir, lokasi semasa dan sebarang peristiwa penarikan balik di sebelah laluan MAC. Rekod itu menjawab soalan yang sebenarnya ditanya oleh tiket: adakah aplikasi menunggu penemuan, bergantung pada keadaan usang, atau gagal menghantar selepas penyelesaian berjaya?

Kemudian tentukan yang mana antara tiga anda sanggup kendalikan. Penemuan dengan flooding, penyegaran dengan jangka hayat realistik, atau peruntukan dengan pemilik semuanya boleh dipertahankan. Fabric yang dikonfigurasikan untuk satu dan dijangka berkelakuan seperti yang lain ialah tempat hos senyap hilang.