Unit transmisi maksimum

Unit transmisi maksimum (MTU) adalah ukuran paket IP terbesar dalam byte, 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 apa pun 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). Sebaiknya konfigurasikan MTU untuk setiap antarmuka jaringan (NIC) instance virtual machine (VM) agar cocok dengan MTU jaringan VPC yang terhubung. Untuk mengetahui informasi selengkapnya, lihat VM dan setelan 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 yang identik, paket IP hingga ukuran MTU dapat dikirim di antara dua VM, jika antarmuka untuk kedua VM dikonfigurasi untuk menggunakan MTU jaringan VPC.

Untuk menghindari masalah ketidakcocokan MTU, sebaiknya gunakan MTU yang sama untuk semua jaringan VPC yang terhubung. Meskipun itu adalah praktik yang direkomendasikan, Anda tidak dipaksa untuk memiliki MTU yang sama di antara jaringan VPC yang terhubung. Untuk mengetahui detail tentang cara protokol menangani situasi saat ada ketidakcocokan MTU antara jaringan VPC, lihat MTU yang tidak cocok, MSS clamping, penemuan MTU jalur.

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

  • Alamat IPv4 internal regional di rentang alamat IPv4 primer subnet atau IPv4 sekunder subnet, termasuk rentang alamat IPv4 pribadi dan rentang alamat IPv4 publik yang digunakan secara pribadi, yang 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 dirutekan 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 penerima.
  • 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 menggunakan gateway internet default next hop. Dalam skenario ini, VM penerima tidak berada di jaringan VPC yang sama dengan VM pengirim atau di jaringan VPC yang terhubung ke jaringan VPC VM pengirim 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 1.500 byte, mempertahankan ukuran paket IP pada 1.500 byte atau kurang biasanya menghindari hilangnya paket terkait MTU.

Situasi Perilaku
Paket SYN dan SYN-ACK TCP Google Cloud melakukan clamping MSS jika diperlukan, yang mengubah MSS untuk memastikan paket sesuai dengan 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 yang lebih besar dari 1.600 byte Google Cloud akan menghapus paket dan mengirim pesan Fragmentation Needed (ICMP over IPv4) atau Packet Too Big (ICMPv6) 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 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 menggunakan Akses Google Pribadi untuk host lokal.

Jalur traffic ke Google API dan layanan yang dijelaskan di bagian ini diimplementasikan oleh Google Front End (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 cocok dengan MTU GFE, ukuran segmen akan dinegosiasikan menggunakan iklan MSS TCP seperti yang dijelaskan dalam MTU yang tidak cocok, MSS clamping, penemuan MTU jalur.

Sumber paket Tujuan paket

Alamat IPv4 internal apa pun: 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 melakukan NAT 1-1 pada keluar, mengonversi alamat IPv4 internal utama sumber asli ke alamat IPv4 eksternal sumber yang ditentukan dalam konfigurasi akses.
  • Alamat IPv4 Google API dan layanan 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 stack ganda
  • Alamat IPv6 Google API dan layanan 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 MTU gateway untuk paket yang dienkapsulasi dan MTU payload 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)

Sebaiknya gunakan MTU yang sama untuk semua lampiran VLAN yang terhubung ke jaringan VPC yang sama, dan tetapkan MTU jaringan VPC ke nilai yang sama. Untuk mengetahui detail tentang MTU lampiran VLAN Cloud Interconnect, lihat MTU Cloud Interconnect.

Dukungan frame jumbo

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

Produk atau fitur Dukungan frame jumbo
Compute Engine Ya
Cloud Interconnect Ya
Cloud VPN Tidak
Google API Tidak

Setelan VM dan MTU

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

  • Setiap MTU NIC untuk VM Linux berdasarkan image OS publik otomatis ditetapkan ke MTU jaringan VPC masing-masing menggunakan DHCP Option 26.

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

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

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

  • Jika MTU NIC harus berbeda dengan MTU jaringan VPC, tetapkan MTU NIC ke nilai yang lebih kecil dari MTU jaringan VPC. Menurunkan MTU NIC secara paksa memiliki keuntungan untuk beberapa skenario jaringan lanjutan.

Mengubah MTU jaringan VPC

Jika Anda mengubah MTU jaringan VPC dengan VM yang sedang 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, VM yang berjalan 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 yang tidak cocok, MSS clamping, penemuan MTU jalur

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

Protokol TCP

Protokol TCP menangani ketidakcocokan MTU secara otomatis. Klien dan server secara terpisah menghitung nilai ukuran segmen maksimum (MSS) TCP yang efektif setiap kali koneksi TCP dibuka. Klien dan server tidak harus setujui nilai MSS efektif yang identik.

  • Ukuran segmen maksimum (MSS) TCP efektif klien: Jumlah terbesar data yang dapat ditransmisikan 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 pembuatan koneksi TCP.

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

  • Ukuran segmen maksimum (MSS) TCP efektif dari server: Jumlah terbesar data yang dapat ditransmisikan 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 pembentukan koneksi TCP.

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

TCP MSS clamping

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

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

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

Protokol non-TCP

Protokol lain, seperti UDP, memerlukan penanganan khusus saat dua MTU jaringan VPC yang berbeda terlibat. Sistem pengiriman bertanggung jawab untuk memunculkan paket yang sesuai dengan MTU antarmuka jaringannya, MTU antarmuka jaringan sistem penerima, dan MTU semua jaringan di antaranya. Google Cloud tidak melakukan fragmentasi IP untuk paket yang dirutekan oleh next hop 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 menghapus paket tersebut. Jika paket memiliki bit DF yang ditetapkan, Google Cloud juga akan mengirimkan pesan Fragmentation Needed (ICMP over IPv4) atau Packet Too Big (ICMPv6) kembali ke pengirim.

Google Cloud mengirim pesan Fragmentation Needed atau Packet Too Big dalam situasi berikut, meskipun bit DF nonaktif:

  • 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 Fragmentation Needed atau Packet Too Big diperlukan untuk VM yang mengirim paket agar dapat menggunakan Path MTU Discovery (PMTUD). Untuk mengilustrasikan cara kerja PMTUD, pertimbangkan contoh berikut dengan dua VM di jaringan VPC yang 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 memunculkan paket IP 8.000 byte yang bit Don't Fragment (DF)-nya ditetapkan. Karena paket terlalu besar untuk dikirim ke VM penerima, Google Cloud akan mengirimkan pesan Fragmentation Required atau Packet Too Big ke VM pengirim. 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 Diperlukan atau Paket Terlalu Besar yang dihasilkan PMTUD menggunakan protokol ICMP dan memiliki sumber yang cocok dengan tujuan paket asli:

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

Langkah selanjutnya

Coba sendiri

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

Coba VPC gratis