pfSense di Virtio: TCP macet sampai offload dimatikan
pfSense yang divirtualisasi menjawab ping lalu macet pada TCP berukuran besar. Matikan jalur offload checksum virtio dan ukur biayanya alih-alih mengganti kartu jaringan.
Seorang klien melaporkan bahwa terowongan tersambung, ping dijawab, halaman masuk termuat, lalu transfer membeku di titik yang sama pada setiap percobaan. Pola itu sudah berbicara banyak: keterjangkauan berfungsi dan throughput berkelanjutan tidak. Sebelum membuka firewall, cari tahu apakah VPN sama sekali terlibat dalam kegagalan. Alirkan TCP besar melalui gateway yang sama tanpa terowongan di jalur; jika ikut membeku, OpenVPN tidak pernah terlibat.
Tamu pfSense dengan kartu jaringan virtio punya alasan sangat kuat untuk gagal persis dalam bentuk itu.
Paket kecil lolos, TCP besar menggantung
Handshake, balasan DNS, dan gema ICMP berukuran kecil dan biasanya lolos. Transfer berkelanjutan memaksa tamu menyegmentasi, dan di situlah jalur offload yang rusak muncul. Kesalahannya tidak harus simetris: lalu lintas keluar bisa bersih sementara yang masuk hilang, atau sebaliknya, sehingga pengguna bisa masuk lalu macet pada respons besar pertama. Karena klien yang sama berfungsi melalui gateway lain, komponen terbaru yang disalahkan.
Jadi ujilah gateway tanpa terowongan. Unduhan dari LAN ke WAN yang cukup besar untuk berjalan beberapa detik sudah memadai, dan harus dilakukan sebelum ada perubahan pengaturan agar perbandingan sesudahnya bermakna.
Apa yang sebenarnya dijanjikan offload
virtio bersifat paravirtual: host dan tamu berbagi pekerjaan, host mengumumkan kemampuan checksum dan segmentasi dan mengharapkan tamu menyelesaikan apa yang dimulainya. Jika tumpukan tamu tidak melakukannya, frame keluar dengan checksum tidak lengkap atau dijatuhkan oleh host. E1000 yang diemulasikan menawarkan model lebih sederhana dan lebih lambat yang membuat masalahnya hilang tanpa satu pun perubahan pada pfSense. Negosiasi kemampuan terjadi per perangkat, yang menjelaskan mengapa satu tamu berjalan berbulan-bulan sementara kembarannya yang dibangun ulang gagal pada hari pertama.
Himpunan yang dinegosiasikan bergantung pada versi hypervisor dan model kartu jaringan yang dipilih, bukan hanya pada konfigurasi yang Anda impor.
Satu kotak centang mempertahankan virtio
Di antarmuka pfSense, jalur Sistem lalu Lanjutan lalu Jaringan berisi kotak centang bernama Nonaktifkan offload checksum perangkat keras. Mencentangnya membuat tamu menghitung checksum di perangkat lunak, yang sesuai dengan apa yang diharapkan tumpukan FreeBSD di balik pfSense dari perangkat paravirtual. Dua opsi terkait di halaman yang sama mencakup offload segmentasi TCP perangkat keras dan offload penerimaan besar perangkat keras. Pilihlah keduanya ketika handshake berhasil tetapi transfer besar tidak.
Biarkan kartu jaringan tetap virtio saat melakukan perubahan. Beralih ke E1000 membakar CPU pada setiap paket sepanjang usia VM dan menyembunyikan masalah konfigurasi dari siapa pun yang mewarisi host, yang merupakan pertukaran lebih buruk daripada jalur data yang sedikit lebih lambat tetapi dapat diprediksi.
Ukur biaya yang baru saja Anda terima
Checksum perangkat lunak memindahkan pekerjaan ke tamu, jadi ukurlah throughput sesudahnya alih-alih menganggapnya gratis. Pada VM kecil hukumannya nyata, tetapi terlihat dan stabil, tidak seperti kehilangan diam-diam. Bandingkan penghitung galat antarmuka dan log kernel tamu sebelum dan sesudah. Hypervisor yang menyaring jembatan adalah kesalahan terpisah dengan bukti berbeda, dan tidak ada bendera offload yang menyembuhkannya.
Ubah satu hal per uji dan catat jalur menu, kotak yang Anda centang, dan angka yang Anda ukur. Siapa pun yang menghadapi tamu hasil bangun ulang berikutnya akan memerlukan ketiganya.
Firewall lain berbasis BSD menawarkan kendali setara di pengaturan antarmuka mereka sendiri, sehingga penalarannya tetap berlaku bahkan ketika jalur menunya tidak.