Unit transmisi maksimum

Unit transmisi maksimum (MTU) adalah ukuran, dalam byte, paket IP terbesar yang memungkinkan, termasuk header IP, header protokol lapisan 4, dan data lapisan 4, yang dapat muat di dalam frame Ethernet.

Ukuran MTU jaringan VPC yang valid

Jaringan Virtual Private Cloud (VPC) menggunakan MTU default sebesar 1.460 byte. Anda dapat menetapkan MTU jaringan VPC ke nilai antara 1.300 byte dan 8.896 byte (inklusif). Ukuran MTU kustom yang umum adalah 1.500 byte (Ethernet standar) atau 8.896 byte (maksimum yang memungkinkan). Google merekomendasikan agar Anda mengonfigurasi MTU untuk setiap antarmuka jaringan instance (NIC) virtual machine (VM) agar sesuai dengan MTU jaringan VPC yang terhubung dengannya. Untuk mengetahui informasi selengkapnya, lihat Setelan VM dan MTU.

Komunikasi antara VM Google Cloud dalam jaringan VPC

Saat mengirim dan menerima VM menggunakan jaringan VPC yang sama atau jaringan VPC yang di-peering yang memiliki MTU identik, paket IP hingga ukuran MTU dapat dikirim di antara kedua VM, jika antarmuka untuk kedua VM dikonfigurasi untuk menggunakan MTU jaringan VPC.

Untuk menghindari masalah ketidakcocokan MTU, Google merekomendasikan agar Anda menggunakan MTU yang sama untuk semua jaringan VPC yang terhubung. Meskipun praktik tersebut direkomendasikan, Anda tidak diharuskan memiliki MTU yang identik di antara jaringan VPC yang terhubung. Untuk mengetahui detail tentang cara protokol menangani situasi saat terdapat ketidakcocokan MTU antarjaringan VPC, lihat MTU yang tidak cocok, pembatasan MSS, penemuan jalur MTU.

Dari perspektif VM pengirim, jalur ke tujuan berikut mewakili traffic VM-ke-VM yang dirutekan dalam jaringan VPC:

  • Alamat IPv4 internal regional dalam rentang alamat IPv4 sekunder subnet atau IPv4 primer subnet, termasuk rentang alamat IPv4 pribadi dan rentang alamat IPv4 publik yang digunakan secara pribadi, digunakan oleh resource tujuan berikut:
    • Alamat IPv4 internal utama dari antarmuka jaringan (NIC) VM penerima .
    • Alamat IPv4 internal dalam rentang IP alias dari NIC VM penerima.
    • Alamat IPv4 internal dari aturan penerusan internal untuk penerusan protokol atau untuk Load Balancer Jaringan passthrough internal.
  • Rentang alamat subnet IPv6 internal yang digunakan oleh resource tujuan berikut:
    • Alamat IPv6 dari rentang alamat IPv6 /96 yang ditetapkan ke NIC VM penerima stack ganda.
    • Alamat IPv6 dari rentang alamat IPv6 /96 dalam aturan penerusan internal untuk penerusan protokol atau untuk Load Balancer Jaringan passthrough internal.
  • Rentang alamat subnet IPv6 eksternal yang digunakan oleh resource tujuan ini saat paket diarahkan menggunakan rute subnet atau rute subnet peering dalam jaringan VPC:
    • Alamat IPv6 dari rentang alamat IPv6 /96 yang ditetapkan ke NIC VM penerima stack ganda.
    • Alamat IPv6 dari rentang alamat IPv6 /96 dari aturan penerusan eksternal untuk penerusan protokol atau untuk Load Balancer Jaringan passthrough eksternal.

Jalur VM-ke-VM berikut diperlakukan dengan cara yang sama seperti Komunikasi ke tujuan di luar jaringan VPC:

  • Jika tujuan paket adalah alamat IPv4 eksternal dari NIC VM Google Cloud yang menerima.
  • Jika tujuan paket adalah alamat IPv4 eksternal dari Load Balancer Jaringan passthrough eksternal.
  • Jika tujuan paket adalah alamat IPv4 eksternal dari aturan penerusan untuk penerusan protokol
  • Jika tujuan paket adalah alamat IPv6 eksternal dari NIC VM Google Cloud, Load Balancer Jaringan passthrough eksternal, atau aturan penerusan untuk penerusan protokol eksternal dan rute yang berlaku di jaringan VPC akan menggunakan next hop internet gateway default. Dalam skenario ini, VM yang menerima tidak berada di jaringan VPC yang sama dengan VM pengirim, atau di jaringan VPC yang terhubung ke jaringan VPC VM yang mengirim menggunakan Peering Jaringan VPC.

Komunikasi ke tujuan di luar jaringan VPC

Google Cloud memproses paket yang dikirim ke tujuan di luar jaringan VPC VM pengirim seperti yang ditunjukkan dalam tabel berikut. Tujuan di luar jaringan VPC VM pengirim mencakup alamat IP yang dapat dirutekan secara publik untuk resource di luar Google Cloud dan alamat IP eksternal yang dapat digunakan pelanggan dalam Google Cloud.

Karena internet umumnya menggunakan MTU sebesar 1.500 byte, menjaga ukuran paket IP pada 1.500 byte atau kurang biasanya akan menghindari paket yang hilang terkait MTU.

Situasi Perilaku
Paket TCP SYN dan SYN-ACK Google Cloud akan melakukan pencatatan MSS jika perlu, dengan mengubah MSS untuk memastikan paket sesuai dalam MTU.
MTU paket IP antara 1.300 byte dan 1.600 byte (inklusif) Google Cloud tidak melakukan perubahan pada paket, kecuali untuk paket SYN dan SYN-ACK seperti yang dibahas di baris pertama.
Paket IP lebih besar dari 1.600 byte Google Cloud menghapus paket dan mengirimkan pesan ICMP Fragmentation Needed baik saat bit DF aktif maupun saat bit DF nonaktif.

Komunikasi ke Google API dan layanan Google

VM yang menggunakan ukuran MTU jaringan VPC yang valid dapat mengirim paket ke Google API dan layanan Google, termasuk menggunakan Akses Google Pribadi dan Private Service Connect untuk Google API. Detail di bagian ini juga berlaku untuk resource lokal yang mengirim paket ke Google API dan layanan Google menggunakan Akses Google Pribadi untuk host lokal.

Jalur traffic ke Google API dan layanan Google yang dijelaskan di bagian ini diterapkan oleh Google Front Ends (GFE). GFE ini menggunakan MTU tetap yang tidak dapat dikonfigurasi. Traffic dari Google Cloud ke Google API dan layanan selalu menggunakan protokol TCP: Jika VM terhubung ke Google API dan layanan dari jaringan VPC yang MTU-nya tidak sesuai dengan MTU GFE, ukuran segmen akan dinegosiasikan menggunakan iklan TCP MSS seperti yang dijelaskan dalam MTU yang tidak cocok, pembatasan MSS, penemuan jalur MTU.

Sumber paket Tujuan paket

Semua alamat IPv4 internal: alamat IPv4 internal utama atau alamat IPv4 internal dari rentang IP alias NIC VM

Alamat IPv4 eksternal yang ditetapkan ke NIC VM menggunakan konfigurasi akses NAT 1-1: Dalam situasi ini, Google Cloud menjalankan 1-1 NAT saat traffic keluar, yang mengonversi alamat IPv4 internal utama sumber asli menjadi alamat IPv4 eksternal sumber yang ditentukan dalam konfigurasi akses.
  • Google API dan layanan Google: Alamat IPv4 untuk domain default
  • 199.36.153.4/30 (restricted.googleapis.com)
  • 199.36.153.8/30 (private.googleapis.com)
  • Endpoint Private Service Connect untuk Google API dan layanan Google
Alamat IPv6 eksternal atau internal, untuk VM dual stack
  • Google API dan layanan Google: Alamat IPv6 untuk domain default
  • 2600:2d00:0002:1000::/64 (restricted.googleapis.com)
  • 2600:2d00:0002:2000::/64 (private.googleapis.com)

Komunikasi melalui tunnel Cloud VPN

Cloud VPN memiliki gateway MTU untuk paket yang dienkapsulasi dan payload MTU untuk paket sebelum dan sesudah enkapsulasi.

Untuk mengetahui nilai MTU payload yang akurat dan informasi MTU Cloud VPN lainnya, lihat pertimbangan MTU dalam dokumentasi Cloud VPN.

Komunikasi melalui lampiran Cloud Interconnect (VLAN)

Google merekomendasikan agar Anda menggunakan MTU yang sama untuk semua lampiran VLAN yang terhubung ke jaringan VPC yang sama, dan menetapkan MTU jaringan VPC ke nilai yang sama. Untuk mengetahui detail tentang MTU lampiran VLAN Cloud Interconnect, lihat MTU Cloud Interconnect.

Dukungan bingkai jumbo

Tabel berikut merangkum dukungan jumbo frame di antara berbagai produk dan fitur Google Cloud:

Produk atau fitur Dukungan bingkai jumbo
Compute Engine Ya
Cloud Interconnect Ya
Cloud VPN Tidak
Layanan yang didukung Google API Tidak

Setelan VM dan MTU

Sebagai praktik terbaik, cocokkan NIC MTU VM dengan MTU jaringan VPC yang terhubung dengan NIC:

  • Setiap NIC MTU untuk VM Linux berdasarkan image OS yang disediakan Google akan otomatis ditetapkan ke MTU jaringan VPC masing-masing menggunakan Opsi DHCP 26.

  • Setiap MTU NIC untuk VM Windows berdasarkan image OS yang disediakan Google dikonfigurasi dengan MTU tetap sebesar 1,460 byte. Jika Anda mengubah MTU jaringan VPC yang berisi VM Windows berdasarkan OS image yang disediakan Google, Anda harus mengubah MTU untuk VM Windows.

  • Jika menggunakan image OS tamu kustom, Anda harus mengonfigurasi NIC MTU atau memastikan bahwa OS tamu menerima MTU jaringan VPC menggunakan Opsi DHCP 26.

  • Jika VM memiliki beberapa antarmuka jaringan, tetapkan setiap NIC MTU ke MTU jaringan VPC masing-masing.

  • Jika MTU NIC harus berbeda dari MTU jaringan VPC, setel MTU NIC ke lebih kecil daripada MTU jaringan VPC. Menurunkan MTU NIC secara paksa menguntungkan bagi beberapa skenario jaringan lanjutan.

Mengubah MTU jaringan VPC

Jika Anda mengubah MTU jaringan VPC dengan VM yang berjalan, perhatikan pertimbangan berikut:

  • Jika Anda mengurangi MTU jaringan VPC, Anda harus menghentikan dan memulai setiap VM. Memulai ulang VM dari dalam sistem operasi tamunya tidak mengupdate MTU-nya.

  • Jika Anda meningkatkan MTU jaringan VPC, menjalankan VM menggunakan jaringan VPC tidak akan memanfaatkan peningkatan MTU jaringan VPC hingga VM dihentikan dan dimulai. Hingga setiap VM dihentikan dan dimulai ulang, VM akan terus menggunakan nilai MTU sebelumnya (lebih rendah).

Untuk mengetahui petunjuknya, lihat Mengubah setelan MTU jaringan VPC.

Setelan GKE dan MTU

MTU yang dipilih untuk antarmuka Pod bergantung pada Antarmuka Jaringan Container (Container Network Interface/CNI) yang digunakan oleh Node cluster dan setelan MTU VPC yang mendasarinya. Untuk mengetahui informasi selengkapnya, lihat Pod.

Nilai MTU antarmuka Pod adalah 1460 atau diwarisi dari antarmuka utama Node.

CNI MTU GKE Standard
kubenet 1460 Default
kubenet
(GKE versi 1.26.1 dan yang lebih baru) 		Diwarisi Default
Calico 1460

Diaktifkan menggunakan --enable-network-policy.

Untuk mengetahui detailnya, silakan melihat Mengontrol komunikasi antara Pod dan Layanan menggunakan kebijakan jaringan.
netd Diwarisi Diaktifkan menggunakan salah satu opsi berikut:
GKE Dataplane V2 Diwarisi

Diaktifkan menggunakan --enable-dataplane-v2.

Untuk mengetahui detailnya, silakan melihat Menggunakan GKE Dataplane V2.

MTU, clamping MSS, penemuan jalur MTU tidak cocok

Bagian ini menjelaskan cara protokol TCP dan non-TCP menangani MTU yang tidak cocok.

Protokol TCP

Protokol TCP menangani ketidakcocokan MTU secara otomatis. Baik klien maupun server menghitung nilai ukuran segmen maksimum (MSS) TCP efektif mereka sendiri setiap kali koneksi TCP dibuka. Klien dan server tidak harus menyetujui nilai MSS efektif yang sama.

  • Ukuran segmen maksimum (MSS) TCP yang efektif dari klien: Jumlah data yang dapat ditransmisikan terbesar dalam segmen TCP yang dikirim dari klien ke server adalah minimum dari dua nilai berikut:

    • Nilai kolom MSS dalam paket SYN-ACK yang diterima oleh klien dari server selama penyiapan koneksi TCP.

    • MTU antarmuka jaringan klien, minus 40 byte. Pengurangan 40 byte mencakup 20 byte untuk header IP dan 20 byte untuk header TCP dasar.

  • Ukuran segmen maksimum TCP yang efektif (MSS) server: Jumlah data yang dapat ditransmisikan terbesar dalam segmen TCP yang dikirim dari server ke klien adalah minimum dari dua nilai berikut:

    • Nilai kolom MSS dalam paket SYN yang diterima oleh server dari klien selama penyiapan koneksi TCP.

    • MTU antarmuka jaringan server, minus 40 byte. Pengurangan 40 byte mencakup 20 byte untuk header IP dan 20 byte untuk header TCP dasar.

Clamping TCP MSS

Clamping TCP MSS adalah proses saat perangkat jaringan antara klien dan server mengubah nilai MSS dalam paket SYN dan SYN-ACK saat mengarahkan paket antara klien dan server. Google Cloud menggunakan clamping MSS setiap kali mengirim paket ke tujuan di luar jaringan VPC.

Tunnel Cloud VPN dan lampiran VLAN Cloud Interconnect juga menggunakan klem MSS. Untuk mengetahui informasi selengkapnya, lihat Enkapsulasi dan pemrosesan paket dalam dokumentasi Cloud VPN dan MTU Cloud Interconnect.

Jaringan VPC tidak melakukan clamping MSS untuk paket yang dirutekan oleh hop berikutnya dalam jaringan VPC karena protokol TCP itu sendiri sudah cukup.

Protokol non-TCP

Protokol lain, seperti UDP, memerlukan perawatan khusus saat dua MTU jaringan VPC yang berbeda terlibat. Sistem pengirim bertanggung jawab untuk memunculkan paket yang sesuai dengan MTU antarmuka jaringannya, MTU antarmuka jaringan sistem penerima, dan MTU dari semua jaringan di antaranya. Google Cloud tidak melakukan fragmentasi IP untuk paket yang dirutekan oleh hop berikutnya dalam jaringan VPC.

Jika paket IP terlalu besar untuk dikirim—misalnya, saat paket melebihi MTU jaringan VPC tempat NIC VM penerima berada, Google Cloud akan membatalkan paket tersebut. Jika paket tersebut memiliki kumpulan bit DF, Google Cloud juga akan mengirimkan pesan Fragmentation Needed (ICMP melalui IPv4) atau Paket Terlalu Besar (ICMPv6) kembali ke pengirim.

Google Cloud mengirimkan pesan Fragmentasi Diperlukan atau Paket Terlalu Besar dalam keadaan berikut, meskipun bit DF tidak ditetapkan:

  • Jika MTU jaringan VPC kurang dari 1.600 byte, dan paket yang dikirim melebihi MTU jaringan VPC.
  • Jika MTU jaringan VPC adalah 1.600 byte atau lebih, dan paket yang dikirim melebihi 1.600 byte.

Pesan ICMP Fragmentasi Diperlukan atau Paket Terlalu Besar diperlukan untuk VM yang mengirim paket untuk menggunakan penemuan MTU Jalur (PMTUD). Untuk menggambarkan cara kerja PMTUD, pertimbangkan contoh berikut dengan dua VM di jaringan VPC berbeda yang terhubung menggunakan Peering Jaringan VPC:

  • VM pengirim memiliki NIC di jaringan VPC yang MTU-nya adalah 8.896 byte.
  • VM penerima memiliki NIC di jaringan VPC yang MTU-nya 1.460 byte.
  • VM pengirim memancarkan paket IP 8.000 byte yang bit Jangan Fragmen (DF) ditetapkan. Karena paket terlalu besar untuk dikirim ke VM penerima, Google Cloud akan mengirimkan pesan Fragmentasi Diperlukan atau Paket Terlalu Besar ke VM yang mengirim. Pesan ini menunjukkan ukuran paket IP terbesar yang dapat digunakan pengirim saat mencoba mengirim ulang paket untuk koneksi.
  • Sistem operasi VM pengirim menggunakan informasi ini untuk menurunkan ukuran paket IP saat mengirim paket berikutnya ke VM penerima.

PMTUD memiliki persyaratan tambahan berikut karena paket Fragmentasi yang dihasilkan PMTUD atau Paket Terlalu Besar menggunakan protokol ICMP dan memiliki sumber yang cocok dengan tujuan paket asli:

  • Anda harus mengonfigurasi izin masuk aturan firewall VPC atau aturan dalam kebijakan firewall sehingga ICMP (untuk IPv4) atau ICMPv6 (untuk IPv6) diizinkan dari sumber yang cocok dengan tujuan paket asli. Untuk menyederhanakan konfigurasi firewall, sebaiknya izinkan ICMP dan ICMPv6 dari semua sumber.
  • Aturan penerusan untuk Load Balancer Jaringan passthrough internal dan penerusan protokol internal harus menggunakan protokol L3_DEFAULT agar dapat memproses ICMP untuk PMTUD dan protokol yang digunakan oleh paket asli.

Langkah selanjutnya

Cobalah sendiri

Jika Anda baru menggunakan Google Cloud, buat akun untuk mengevaluasi performa VPC dalam skenario dunia nyata. Pelanggan baru juga mendapatkan kredit gratis senilai $300 untuk menjalankan, menguji, dan men-deploy workload.

Coba VPC gratis