🧗🏽 👩🏼‍🔧 😑 VXLAN dalam NSX-V - Underlay Bermasalah 🚇 🥙 🤹🏻

Salam, dan pertama sedikit lirik. Saya terkadang iri dengan kolega yang bekerja dari jarak jauh - senang bisa bekerja dari mana saja di dunia yang terhubung ke Internet, liburan kapan saja, bertanggung jawab atas proyek dan tenggat waktu, dan tidak berada di kantor mulai 8 hingga 17. Posisi dan tanggung jawab kerja saya praktis tidak termasuk kemungkinan ketidakhadiran lama di pusat data. Namun - kasus-kasus menarik seperti yang dijelaskan di bawah ini kadang-kadang terjadi, dan saya mengerti bahwa ada beberapa posisi di mana ada ruang untuk ekspresi kreatif dari pemecah masalah internal.

Penafian kecil - pada saat penulisan, kasus ini belum sepenuhnya diselesaikan, tetapi mengingat kecepatan respons vendor, solusi lengkap mungkin memakan waktu berbulan-bulan, dan saya ingin membagikan temuan saya sekarang. Saya harap, para pembaca yang budiman, Anda akan memaafkan saya dengan tergesa-gesa. Tapi cukup air - bagaimana dengan kasingnya?

Pendahuluan pertama: ada perusahaan (tempat saya bekerja sebagai insinyur jaringan) yang menampung solusi klien di cloud pribadi VMWare. Sebagian besar solusi baru terhubung ke segmen VXLAN yang dikendalikan oleh NSX-V - saya tidak akan mengevaluasi berapa banyak waktu yang diberikan solusi ini kepada saya, singkatnya - banyak. Saya bahkan berhasil melatih kolega saya untuk mengkonfigurasi NSX ESG dan solusi klien kecil digunakan tanpa partisipasi saya. Catatan penting adalah bidang kontrol dengan replikasi unicast. Hypervisor dihubungkan secara berlebihan oleh dua antarmuka ke switch Juniper QFX5100 fisik yang berbeda (dirakit dalam Virtual Chassis) dan rute kebijakan waktu berdasarkan port virtual asal adalah untuk kelengkapan.

Solusi klien sangat heterogen: dari Windows IIS, di mana semua komponen server web diinstal pada satu mesin ke yang cukup besar - misalnya, front web Apache yang seimbang + LB MariaDB di Galera + server-balon yang disinkronkan menggunakan GlusterFS. Hampir setiap server perlu dimonitor secara terpisah, dan tidak semua komponen memiliki alamat publik - jika Anda mengalami masalah ini dan memiliki solusi yang lebih elegan, saya akan dengan senang hati memberi saran.
Solusi pemantauan saya terdiri dari "menghubungkan" firewall (Fortigate) ke setiap jaringan klien internal (+ SNAT dan, tentu saja, pembatasan ketat pada jenis lalu lintas yang diizinkan) dan pemantauan alamat internal - dengan cara ini penyatuan tertentu dan penyederhanaan pemantauan dicapai. Pemantauan itu sendiri berasal dari sekelompok server PRTG. Skema pemantauannya kira-kira seperti ini:

gambar

Sementara kami hanya beroperasi dengan VLAN, semuanya sangat biasa dan dapat diprediksi berfungsi seperti jam. Setelah implementasi, NSX-V dan VXLAN menghadapi pertanyaan - apakah mungkin untuk melanjutkan pemantauan dengan cara lama? Pada saat pertanyaan ini, solusi tercepat adalah menggunakan NSX ESG dan menghubungkan antarmuka trunk VXLAN ke jaringan VTEP. Kutipan cepat - karena menggunakan GUI untuk mengonfigurasi jaringan klien, SNAT dan aturan firewall dapat dan menyatukan manajemen dalam antarmuka vSphere tunggal, tetapi menurut saya ini agak rumit dan, di antara hal lain, membatasi rangkaian alat untuk pemecahan masalah. Mereka yang menggunakan ESX NSX sebagai pengganti firewall "nyata", saya pikir, akan setuju. Meskipun, mungkin, solusi seperti itu akan lebih stabil - setelah semua, semua terjadi dalam kerangka kerja satu vendor.

Solusi lain adalah dengan menggunakan NSX DLR dalam mode bridge antara VLAN dan VXLAN. Di sini, saya pikir semuanya jelas - manfaat menggunakan VXLAN adalah klise - karena dalam hal ini, Anda masih harus menarik VLAN ke instalasi pemantauan. By the way, dalam proses mengerjakan solusi ini, saya mengalami masalah ketika jembatan DLR tidak mengirim paket ke mesin virtual yang dengannya berada di host yang sama. Saya tahu, saya tahu - dalam buku-buku dan panduan tentang NSX-V secara eksplisit dinyatakan bahwa cluster terpisah harus dialokasikan untuk NSX Edge, tetapi ini ada di buku-buku ... Pokoknya, setelah beberapa bulan dengan dukungan kami tidak menyelesaikan masalah. Pada prinsipnya, saya memahami logika tindakan - modul inti hypervisor yang bertanggung jawab untuk enkapsulasi VXLAN tidak diaktifkan jika DLR dan server yang dipantau berada di host yang sama, karena lalu lintas tidak meninggalkan host dan, secara logis, itu harus dihubungkan ke segmen VXLAN - enkapsulasi tidak diperlukan.Dengan dukungan, kami memutuskan pada vdrPort antarmuka virtual, yang secara logis menggabungkan uplink dan juga melakukan bridging / enkapsulasi - di sana terlihat ketidakcocokan dalam lalu lintas masuk, yang saya ambil untuk bekerja dalam kasus saat ini. Tetapi seperti yang dikatakan, saya tidak menyelesaikan kasus ini sampai akhir, karena dipindahkan ke proyek lain dan cabang awalnya buntu dan tidak ada keinginan khusus untuk mengembangkannya. Jika saya tidak salah, masalahnya diamati dalam versi NSX dan 6.1.4 dan 6.2.karena dipindahkan ke proyek lain dan cabang itu awalnya buntu dan tidak ada keinginan khusus untuk mengembangkannya. Jika saya tidak salah, masalahnya diamati dalam versi NSX dan 6.1.4 dan 6.2.karena dipindahkan ke proyek lain dan cabang itu awalnya buntu dan tidak ada keinginan khusus untuk mengembangkannya. Jika saya tidak salah, masalahnya diamati dalam versi NSX dan 6.1.4 dan 6.2.

Dan di sini - bingo! Fortinet annonsiruet mendukung VXLAN asli . Dan bukan hanya point-to-point atau VXLAN-over-IPSec, bukan bridging VLAN-VXLAN berbasis perangkat lunak - mereka mulai mengimplementasikan semua ini sejak versi 5.4 (dan disajikan oleh vendor lain), tetapi dukungan nyata untuk pesawat kontrol unicast. Ketika menerapkan solusi, saya mengalami masalah lain - server yang diperiksa secara berkala "menghilang" dan kadang-kadang muncul dalam pemantauan, meskipun mesin virtual itu sendiri masih hidup. Alasannya adalah saya lupa mengaktifkan Ping pada antarmuka VXLAN. Dalam proses penyeimbangan kembali kluster, mesin virtual bergerak, dan vMotion berakhir dengan Ping untuk menunjukkan host ESXI baru tempat mesin dipindahkan. Kebodohan saya, tetapi masalah ini sekali lagi merusak kredibilitas dukungan yang dihasilkan - dalam hal ini Fortinet. Saya tidak mengatakan bahwa setiap kasus yang terkait dengan VXLAN dimulai dengan pertanyaan "di mana softswitch VLAN-VXLAN dalam pengaturan Anda?" Kali ini saya disarankan untuk mengubah MTU - ini untuk Ping, yaitu 32 byte. Kemudian "bermain-main" dengan tcp-send-mss dan tcp-accept-mss dalam kebijakan - untuk VXLAN,yang dirangkum dalam UDP. Fuf, maafkan saya - ini mendidih. Secara umum, saya memecahkan masalah ini sendiri.

Setelah berhasil memutar kembali lalu lintas pengujian, diputuskan untuk mengimplementasikan solusi ini. Dan dalam produksi ternyata setelah satu atau dua hari, semua yang dipantau melalui VXLAN secara bertahap jatuh. Menonaktifkan / mengaktifkan antarmuka membantu, tetapi hanya sementara. Sadar akan dukungan yang bergerak lambat, saya masuk untuk pemecahan masalah untuk bagian saya - pada akhirnya, perusahaan saya, jaringan saya adalah tanggung jawab saya.

Di bawah spoiler adalah jalannya pemecahan masalah. Siapa yang bosan dengan surat dan menyombongkan diri - lewati dan pergi ke postanalysis

Penyelesaian masalah

, — !

, , . . , Fortigate 5.6+, «diagnose debug flow» — . . , , RFC1918, . VXLAN ...15, ...254, VTEP.

VXLAN- . overlay ARP OVSDB, underlay ARP CAM. Fortigate VXLAN FDB OVSDB. :

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=...47 port=4789 vni=5008 ifindex=7

— MAC VTEP ...47. ESXI , , MAC , VTEP . CAM/ARP — ESXI :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz

— ? Juniper' — , — VLAN VTEP . DLR-, VDR — ESXI , VMWare. MAC «97:6e» , vmnic1 — , VTEP ...47 "--dir 2":

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

— ARP . ARP . , ...15 — ICMP ? , . , ( teaming policy), vNIC , , :

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

, . . — — VDR, . , , , . «» Ethernet underlay. - MAC VTEP IP. , , — , . ARP , . Ethernet :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep ...42
...42 0 00:50:56:6a:78:86 dmz

Jadi, apa yang kita miliki pada akhirnya - setelah migrasi mesin virtual, fortigate mencoba mengirim lalu lintas ke VTEP dari VXLAN FDB (yang benar), tetapi menggunakan MAC DST yang salah dan lalu lintas diharapkan akan dibuang oleh antarmuka hypervisor penerima. Selain itu, dalam satu dari empat kasus, MAC ini milik hypervisor asli, darimana migrasi mesin dimulai.

Kemarin saya menerima surat dari Fortinet tech support - mereka membuka bug 615586 dalam kasus saya. Saya tidak tahu bagaimana harus bersukacita atau bersedih: di satu sisi, masalahnya bukan pada pengaturan, di sisi lain, perbaikannya hanya akan datang dengan pembaruan firmware, berikut ini, yang terbaik. FAQ juga menghangatkan bug lain yang saya temukan bulan lalu, meskipun pada saat itu di HTML5 GUI vSphere. Nah, departemen QA lokal vendor langsung ...

Saya berani menyarankan yang berikut:

1 - bidang kendali multicast yang kemungkinan besar tidak akan mengalami masalah yang dijelaskan - lagipula, alamat MAC VTEP diperoleh dari alamat IP grup tempat antarmuka berlangganan.

2 - kemungkinan besar masalah fortics di sesi offload di Network Processor (kira-kira analog dengan CEF) - jika setiap paket dilewatkan melalui CPU, tabel yang berisi informasi yang benar - setidaknya secara visual - akan digunakan. Yang mendukung asumsi ini adalah apa yang membantu untuk menutup / membuka antarmuka atau menunggu beberapa saat - lebih dari 5 menit.

3 - mengubah kebijakan tim, misalnya, menjadi failover eksplisit, atau pengenalan LAG tidak akan menyelesaikan masalah, karena MAC terjebak pada hypervisor asli dalam paket enkapsulasi diamati.

Sehubungan dengan ini, saya dapat membagikan apa yang baru saya temukan di sebuah blog, di mana dalam salah satu artikel dinyatakan bahwa firewall dan metode transfer data yang tersimpan adalah kruk. Ya, saya tidak terlalu berpengalaman di bidang IT untuk mengatakan itu, dan saya tidak setuju dengan semua pernyataan di artikel blog. Namun, ada sesuatu yang memberitahuku bahwa ada beberapa kebenaran dalam kata-kata Ivan.

Terima kasih atas perhatian Anda! Saya akan dengan senang hati menjawab pertanyaan dan mendengar kritik membangun.

VXLAN dalam NSX-V - Underlay Bermasalah

More articles: