Rute

Rute Google Cloud menentukan jalur yang diambil traffic jaringan dari instance virtual machine (VM) ke tujuan lain. Tujuan ini dapat berada di dalam jaringan Virtual Private Cloud (VPC) Google Cloud (misalnya, di VM lain) atau di luarnya.

Dalam jaringan VPC, rute terdiri dari satu awalan tujuan dalam format CIDR dan satu next hop. Saat instance dalam jaringan VPC mengirim paket, Google Cloud mengirimkan paket ke next hop rute jika alamat tujuan paket tersebut berada dalam rentang tujuan rute.

Halaman ini memberikan ringkasan cara kerja rute di Google Cloud.

Pemilihan rute di Google Cloud

Setiap jaringan VPC menggunakan mekanisme pemilihan rute virtual yang skalabel dan terdistribusi. Tidak ada perangkat fisik yang ditetapkan ke jaringan. Beberapa rute dapat diterapkan secara selektif, tetapi tabel pemilihan rute untuk jaringan VPC ditentukan pada tingkat jaringan VPC.

Setiap instance VM memiliki pengontrol yang terus mendapatkan informasi tentang semua rute yang berlaku dari tabel pemilihan rute jaringan. Setiap paket yang meninggalkan VM dikirim ke next hop yang sesuai dari rute yang berlaku berdasarkan urutan pemilihan rute. Saat Anda menambahkan atau menghapus rute, kumpulan perubahan akan diterapkan ke pengontrol VM dengan menggunakan desain yang akhirnya akan konsisten.

Jenis rute

Tabel berikut merangkum cara Google Cloud mengategorikan rute dalam jaringan VPC.

Jenis dan tujuan Next hop Catatan
Rute yang dibuat oleh sistem
Rute default yang dibuat oleh sistem
0.0.0.0/0 untuk IPv4
::/0 untuk IPv6		 default-internet-gateway Berlaku untuk seluruh jaringan VPC

Dapat dihapus atau diganti
Rute subnet
Dibuat secara otomatis untuk setiap rentang alamat IP subnet 		Jaringan VPC
Meneruskan paket ke VM dan load balancer internal

Dibuat, diperbarui, dan dihapus secara otomatis oleh Google Cloud selama peristiwa siklus proses subnet.

Rute subnet lokal berlaku untuk seluruh jaringan VPC.
Rute kustom
Rute statis
Mendukung berbagai tujuan 		Meneruskan paket ke next hop rute statis Untuk detail tentang setiap next hop rute statis, lihat pertimbangan untuk:
Rute dinamis
Tujuan yang tidak bertentangan dengan rute subnet atau rute statis		 Peer sesi BGP di Cloud Router Rute ditambahkan dan dihapus secara otomatis berdasarkan rute yang dipelajari dari Cloud Router di jaringan VPC Anda.

Rute berlaku untuk VM sesuai dengan mode pemilihan rute dinamis jaringan VPC.
Rute Peering Jaringan VPC
Rute subnet peering
Mewakili rentang alamat IP subnet di jaringan VPC berbeda yang terhubung menggunakan Peering Jaringan VPC 		Next hop di jaringan VPC peer

Peering Jaringan VPC menyediakan opsi untuk bertukar rute subnet.

Dibuat, diperbarui, dan dihapus secara otomatis oleh Google Cloud selama peristiwa siklus proses subnet.

Rute subnet peering yang diimpor berlaku untuk seluruh jaringan VPC.
Rute statis dan dinamis peering
Rute statis atau dinamis di jaringan VPC berbeda yang terhubung menggunakan Peering Jaringan VPC 		Next hop di jaringan VPC peer

Peering Jaringan VPC menyediakan opsi untuk bertukar rute statis.

Rute statis peering yang diimpor berlaku untuk seluruh jaringan VPC.

Peering Jaringan VPC menyediakan opsi untuk pertukaran rute dinamis.

Rute dinamis peering yang diimpor berlaku untuk satu atau semua region jaringan VPC sesuai dengan mode perutean dinamis jaringan VPC yang mengekspor rute.
Rute Network Connectivity Center
Rute subnet Network Connectivity Center
Mewakili rentang alamat IP subnet di VPC berbicara (jaringan VPC berbeda yang terhubung ke hub Network Connectivity Center) 		Hub Network Connectivity Center

Administrator berbicara Network Connectivity Center dapat mengecualikan ekspor rute subnet.

Dibuat, diperbarui, dan dihapus secara otomatis oleh Google Cloud selama peristiwa siklus proses subnet.

Rute subnet Network Connectivity Center yang diimpor berlaku untuk seluruh jaringan VPC.
Rute berbasis kebijakan
Rute berbasis kebijakan
Rute berbasis kebijakan dapat diterapkan untuk paket berdasarkan alamat IP sumber, alamat IP tujuan, protokol, atau kombinasinya.

Rute berbasis kebijakan dievaluasi sebelum rute lain dievaluasi. Rute berbasis kebijakan dapat berlaku untuk semua VM dalam jaringan, ke VM tertentu yang dipilih oleh tag jaringan, atau untuk traffic yang masuk ke jaringan VPC melalui lampiran VLAN Cloud Interconnect yang Anda tentukan.

Rute berbasis kebijakan tidak pernah dipertukarkan melalui Peering Jaringan VPC.

Rute default yang dibuat oleh sistem

Saat Anda membuat jaringan VPC, ini mencakup[ rute default IPv4 yang dihasilkan oleh sistem (0.0.0.0/0). Saat Anda membuat subnet dual-stack dengan rentang alamat IPv6 eksternal di jaringan VPC, rute default IPv6 yang dihasilkan oleh sistem (::/0) akan ditambahkan ke jaringan itu jika rute tersebut belum ada. Rute default memiliki tujuan berikut:

Google Cloud hanya menggunakan rute default jika rute dengan tujuan yang lebih spesifik tidak berlaku untuk suatu paket. Untuk mengetahui informasi tentang cara penggunaan kekhususan tujuan dan prioritas rute untuk memilih rute, lihat urutan pemilihan rute.

Jika ingin mengisolasi jaringan sepenuhnya dari internet atau jika perlu mengganti rute default dengan rute kustom, Anda dapat menghapus rute default:

  • Khusus IPv4: Jika ingin merutekan traffic internet ke next hop yang berbeda, Anda dapat mengganti rute default dengan rute statis atau dinamis kustom. Misalnya, Anda dapat menggantinya dengan rute statis kustom yang next hop-nya adalah VM proxy.

  • IPv4 dan IPv6: Jika Anda menghapus rute default dan tidak menggantinya, paket yang ditujukan ke rentang IP yang tidak dicakup oleh rute lain akan dihapus.

Rute subnet

Rute subnet menentukan jalur ke resource seperti VM dan load balancer internal di jaringan VPC.

Setiap subnet memiliki setidaknya satu rute subnet yang tujuannya cocok dengan rentang IPv4 utama subnet. Jika subnet memiliki rentang IP sekunder, ada rute subnet yang sesuai untuk setiap rentang alamat IP sekundernya. Jika subnet memiliki rentang IPv6, ada rute subnet yang sesuai untuk rentang alamat IPv6 tersebut. Untuk mengetahui informasi selengkapnya tentang rentang IP subnet, lihat Subnet.

Rute subnet selalu memiliki tujuan yang paling spesifik. Rute tersebut tidak dapat diganti oleh rute lain, meskipun rute lain memiliki prioritas yang lebih tinggi. Hal ini karena Google Cloud mengutamakan kekhususan tujuan dibandingkan prioritas saat memilih rute. Google Cloud menggunakan 0 sebagai prioritas untuk semua rute subnet.

Interaksi dengan rute statis

Rute subnet lokal dan rute subnet peering yang diimpor berinteraksi dengan rute statis kustom dengan cara berikut:

  • Google Cloud tidak mengizinkan Anda membuat rute statis kustom yang memiliki tujuan yang sama atau lebih sempit daripada rute subnet atau rute subnet peering mana pun. Contoh:

    • Jika ada rute subnet lokal atau rute subnet peering untuk tujuan 10.70.1.0/24, Anda tidak dapat membuat rute statis kustom baru untuk 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25, atau tujuan lain yang cocok dalam 10.70.1.0/24.

    • Jika ada rute subnet lokal atau rute subnet peering untuk tujuan 2001:0db8:0a0b:0c0d::/64 Anda tidak dapat membuat rute statis kustom baru untuk 2001:0db8:0a0b:0c0d::/64 atau tujuan apa pun yang cocok dalam 2001:0db8:0a0b:0c0d::/64, misalnya 2001:0db8:0a0b:0c0d::/96.

  • Sebaliknya, Google Cloud tidak mengizinkan Anda membuat rute subnet baru atau rute subnet peering yang tujuannya sama persis atau lebih luas dari (berisi) rute statis kustom yang ada. Contoh:

    • Jika jaringan VPC Anda memiliki rute statis kustom untuk tujuan 10.70.1.128/25, Google Cloud melarang pembuatan rute subnet atau rute subnet peering apa pun yang memiliki rentang alamat IPv4 subnet primer atau sekunder 10.70.1.128/25, 10.70.1.0/24, atau rentang lain yang berisi semua alamat IPv4 di 10.70.1.128/25.

    • Jika jaringan VPC Anda memiliki rute statis kustom untuk tujuan 2001:0db8:0a0b:0c0d::/96, Google Cloud melarang pembuatan rute subnet stack ganda atau rute subnet peering yang memiliki rentang alamat IPv6 2001:0db8:0a0b:0c0d::/64 atau rentang lain yang berisi semua alamat IPv6 di 2001:0db8:0a0b:0c0d::/96.

Interaksi dengan rute dinamis

Rute subnet lokal dan rute subnet peering yang diimpor berinteraksi dengan Cloud Router dengan cara berikut:

  • Saat Cloud Router mempelajari awalan yang sama persis dengan tujuan dari rute subnet atau rute subnet peering yang ada, Google Cloud tidak akan membuat rute dinamis kustom apa pun untuk awalan yang bertentangan. Misalnya, jika subnet atau rute subnet peering dengan tujuan 10.70.1.0/24 ada, jika Cloud Router di jaringan VPC menerima awalan 10.70.1.0/24 melalui BGP, Google Cloud akan menggunakan rute subnet atau rute subnet peering, dan tidak membuat rute dinamis kustom untuk 10.70.1.0/24.

    • Saat rute subnet atau rute peering subnet yang tujuannya sama persis dengan awalan yang dipelajari oleh Cloud Router di jaringan VPC dibuat, Google Cloud menghapus rute dinamis kustom untuk awalan yang mengalami konflik guna memberi ruang bagi rute subnet atau rute subnet peering.

  • Saat Cloud Router mempelajari awalan yang sesuai dengan tujuan rute subnet atau rute subnet peering yang ada, Google Cloud tidak akan membuat rute dinamis kustom apa pun untuk awalan yang mengalami konflik. Misalnya, saat rute subnet atau rute subnet peering dengan tujuan 10.70.1.0/24, saat Cloud Router di jaringan VPC menerima awalan 10.70.1.0/25 dan 10.70.1.128/25 melalui BGP, Google Cloud menggunakan rute subnet atau rute peering subnet, dan tidak membuat rute dinamis kustom untuk 10.70.1.0/25 dan 10.70.1.128/25.

    • Saat rute subnet atau rute subnet peering yang tujuannya berisi awalan yang dipelajari oleh Cloud Router di jaringan VPC dibuat, Google Cloud menghapus rute dinamis kustom untuk awalan yang bertentangan guna memberi ruang bagi rute subnet atau rute subnet peering.

Siklus proses rute subnet

Rute subnet dibuat, diupdate, dan dihapus saat Anda membuat, mengubah, atau menghapus subnet atau rentang alamat IP subnetnya:

  • Saat Anda menambahkan subnet, Google Cloud akan membuat rute subnet yang sesuai untuk rentang alamat IP utama subnet.

  • Jaringan VPC mode otomatis membuat rute subnet untuk rentang IP utama dari setiap subnet yang dibuat secara otomatis. Anda dapat menghapus subnet ini hanya jika mengonversi jaringan VPC mode otomatis ke mode kustom.

  • Anda tidak dapat menghapus rute subnet kecuali Anda mengubah atau menghapus subnet:

    • Jika rentang sekunder dihapus dari subnet, rute subnet untuk rentang sekunder tersebut akan otomatis dihapus.

    • Saat Anda menghapus subnet, semua rute subnet untuk rentang primer dan sekunder akan otomatis dihapus. Anda tidak dapat menghapus rute subnet untuk rentang utama subnet dengan cara lain.

Jumlah rute subnet dalam jaringan VPC dibatasi oleh Jumlah maksimum rentang IP subnet (primer dan sekunder).

Rute dinamis

Cloud Router memerintahkan jaringan VPC untuk membuat, mengupdate, dan menghapus rute dinamis berdasarkan pesan Border Gateway Protocol (BGP) yang diterima dan rute kustom Cloud Router yang dipelajari yang Anda konfigurasikan. Bidang kontrol Cloud Router menginstal rute dinamis secara regional berdasarkan mode pemilihan rute dinamis jaringan VPC:

  • Jika jaringan VPC menggunakan mode pemilihan rute dinamis regional, Cloud Router di setiap region hanya membuat rute dinamis di region yang sama dengan Cloud Router.

  • Jika jaringan VPC menggunakan mode pemilihan rute dinamis global, Cloud Router di setiap region membuat rute dinamis di semua region jaringan VPC.

Next hop dari rute dinamis dapat berupa salah satu dari berikut ini:

Jika next hop untuk rute dinamis tidak dapat diakses, Cloud Router yang mengelola sesi BGP-nya akan menginstruksikan jaringan VPC untuk menghapus rute dinamis setelah salah satu kondisi berikut terpenuhi:

Google Cloud menyelesaikan konflik antara rute dinamis dan rute subnet lokal dan subnet peering seperti yang dijelaskan dalam Interaksi dengan rute dinamis.

Rute subnet peering

Rute subnet peering menentukan jalur ke resource pada subnet di jaringan VPC lain yang terhubung melalui Peering Jaringan VPC. Untuk mengetahui informasi selengkapnya, lihat Opsi untuk bertukar rute subnet.

Rute subnet lokal dan subnet peering tidak boleh tumpang-tindih. Untuk mengetahui informasi selengkapnya, lihat Interaksi rute subnet dan subnet peering.

Jumlah rute subnet per grup peering dikontrol oleh rentang subnetwork per jaringan per kuota grup peering.

Rute statis dan dinamis peering

Saat menggunakan Peering Jaringan VPC untuk menghubungkan dua jaringan VPC, Anda dapat mengekspor rute statis dan dinamis dari satu jaringan dan mengimpornya ke jaringan lain. Untuk informasi selengkapnya, lihat:

Jumlah rute statis per grup peering dan rute dinamis per region per grup peering dibatasi oleh kuota rute statis dan dinamis per jaringan.

Pemberlakuan dan urutan

Rute yang berlaku

Setiap instance memiliki serangkaian rute yang berlaku, yang merupakan subset dari semua rute di jaringan VPC. Rute yang berlaku adalah kemungkinan jalur traffic keluar yang dapat diambil paket saat dikirim dari instance.

  • Jalur pengembalian khusus berlaku saat melakukan perutean kembali ke load balancer proxy, sistem health check, dan layanan Google lainnya. Untuk mengetahui informasi selengkapnya, lihat jalur kembali load balancer. Rute ini tidak ditampilkan di tabel rute mana pun.

  • Rute berbasis kebijakan dapat berlaku untuk paket yang dikirim dari instance VM Compute Engine atau paket yang diterima oleh lampiran VLAN Cloud Interconnect. Rute berbasis kebijakan hanya berlaku jika paket cocok dengan kriteria rute berbasis kebijakan.

  • Rute subnet lokal dan peering berlaku untuk semua instance. Kecuali untuk rute berbasis kebijakan, tidak ada jenis rute lain yang dapat memiliki tujuan yang cocok atau sesuai dengan tujuan rute subnet lokal atau peering. Untuk mengetahui detail selengkapnya tentang penyelesaian konflik antara rute subnet, statis, dan dinamis, lihat Interaksi subnet dan rute statis serta Interaksi subnet dan rute dinamis.

  • Rute statis kustom dapat diterapkan ke semua instance atau instance tertentu. Rute statis dengan atribut tag berlaku untuk instance yang memiliki tag jaringan yang sama. Jika rute tidak memiliki tag jaringan, rute tersebut berlaku untuk semua instance dalam jaringan.

  • Rute dinamis berlaku untuk instance berdasarkan mode pemilihan rute dinamis jaringan VPC.

Jalur kembali khusus

Jaringan VPC memiliki rute khusus untuk layanan tertentu. Rute ini ditentukan di luar jaringan VPC Anda, dalam jaringan produksi Google. Rute ini tidak muncul di tabel rute jaringan VPC Anda. Anda tidak dapat menghapus atau menggantinya, meskipun Anda menghapus atau mengganti rute default di jaringan VPC. Namun, Anda dapat mengizinkan atau menolak paket menggunakan aturan firewall VPC, kebijakan firewall jaringan, atau kebijakan firewall hierarkis.

Jalur kembali load balancer

Google Cloud menggunakan rute khusus di luar jaringan VPC Anda untuk mengirimkan paket antara:

  • Sistem klien dan backend load balancer (untuk Load Balancer Jaringan passthrough eksternal)
  • Sistem proxy dan backend load balancer (untuk load balancer proxy eksternal)
  • Penguji health check dan backend load balancer
Jalur antara proxy dan backend Google Front End (GFE)

Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi Klasik, Load Balancer Jaringan proxy klasik, dan Load Balancer Jaringan proxy eksternal global menggunakan sistem Front End Google (GFE) sebagai proxy.

Saat klien mengirim permintaan ke load balancer, GFE menghentikan koneksi TCP pertama tersebut. GFE kemudian membuka koneksi TCP kedua ke VM backend. Google Cloud menggunakan rute yang ditentukan di luar jaringan VPC Anda untuk merutekan paket antara proxy GFE dan VM backend.

Jalur ke backend Load Balancer Jaringan passthrough eksternal

Untuk Load Balancer Jaringan passthrough eksternal, Google Cloud menggunakan rute yang ditentukan di luar jaringan VPC Anda untuk merutekan paket antara klien dan VM backend.

Health check untuk semua jenis load balancer

Paket yang dikirim dari sistem pemeriksaan health check Google Cloud menggunakan sumber paket yang didokumentasikan dalam Memeriksa rentang IP dan aturan firewall.

IAP

Google Cloud menyertakan rute ke dan dari 35.235.240.0/20 di setiap jaringan VPC untuk mendukung penerusan TCP menggunakan IAP. Jaringan produksi Google menggunakan 35.235.240.0/20 sebagai rentang khusus internal. Next hop untuk 35.235.240.0/20 sepenuhnya berada dalam jaringan produksi Google.

Cloud DNS dan Direktori Layanan

Google Cloud menyertakan rute ke dan dari 35.199.192.0/19 di setiap jaringan VPC untuk mendukung target penerusan yang menggunakan pemilihan rute pribadi terkait Cloud DNS, server nama alternatif yang menggunakan pemilihan rute pribadi milik Cloud DNS, dan akses jaringan pribadi untuk Direktori Layanan. Jaringan produksi Google menggunakan 35.199.192.0/19 sebagai rentang khusus internal. Next hop untuk 35.199.192.0/19 sepenuhnya berada dalam jaringan produksi Google.

Akses VPC Serverless

Google Cloud menyertakan rute ke dan dari 35.199.224.0/19 di setiap jaringan VPC untuk mendukung Akses VPC Serverless. Jaringan produksi Google menggunakan 35.199.224.0/19 sebagai rentang khusus internal. Next hop untuk 35.199.224.0/19 sepenuhnya berada dalam jaringan produksi Google.

Urutan pemilihan rute

Proses berikut memodelkan perilaku pemilihan rute jaringan VPC, dimulai dengan serangkaian rute yang berlaku yang dijelaskan di bagian sebelumnya.

  1. Jalur kembali khusus: Jalur kembali khusus tidak ditampilkan dalam tabel rute jaringan VPC Anda. Rute yang Anda konfigurasi di jaringan VPC tidak berlaku untuk paket respons untuk load balancer Google Cloud, sistem health check, Identity-Aware Proxy (IAP), dan proxy Cloud DNS tertentu. Untuk mengetahui detailnya, lihat Jalur kembali khusus.

    Jika jalur kembali khusus berlaku, model pemilihan rute Anda hanya berisi jalur kembali khusus. Semua rute lainnya diabaikan, dan evaluasi berhenti pada langkah ini.

  2. Rute berbasis kebijakan: Rute berbasis kebijakan dievaluasi setelah jalur kembali khusus, tetapi sebelum jenis rute lainnya. Jika tidak ada rute berbasis kebijakan di jaringan VPC, Google Cloud akan melewati langkah ini dan melanjutkan ke langkah tujuan yang paling spesifik.

    • Google Cloud mengevaluasi rute berbasis kebijakan hanya berdasarkan prioritasnya. Google Cloud mengevaluasi sumber dan tujuan paket untuk setiap rute berbasis kebijakan, dimulai dengan rute berbasis kebijakan dengan prioritas tertinggi. Jika karakteristik paket tidak cocok dengan rute berbasis kebijakan, Google Cloud akan mengabaikan rute berbasis kebijakan tersebut dan terus mengevaluasi rute berbasis kebijakan berikutnya dalam daftar yang diurutkan. Rute berbasis kebijakan berikutnya yang akan dievaluasi mungkin memiliki prioritas yang sama dengan rute berbasis kebijakan yang diabaikan, atau mungkin memiliki prioritas yang lebih rendah.

    • Jika karakteristik paket tidak cocok dengan rute berbasis kebijakan apa pun setelah mengevaluasi semua rute berbasis kebijakan dalam model pemilihan rute Anda, Google Cloud akan mengabaikan semua rute berbasis kebijakan dan melanjutkan ke langkah tujuan paling spesifik.

    • Jika karakteristik paket cocok dengan rute berbasis kebijakan yang memiliki prioritas tertinggi, Google Cloud akan mengabaikan semua rute berbasis kebijakan yang prioritasnya lebih rendah. Jika dua rute berbasis kebijakan atau lebih tersisa dalam daftar, Google Cloud akan mengevaluasi setiap rute berbasis kebijakan lainnya yang memiliki prioritas identik. Google Cloud akan mengabaikan rute berbasis kebijakan yang tersisa jika karakteristik paket tidak cocok. Setelah langkah ini, model pemilihan rute Anda mungkin berisi satu atau beberapa rute berbasis kebijakan.

      • Jika model pemilihan rute Anda menyertakan dua atau beberapa rute berbasis kebijakan yang memiliki prioritas tertinggi yang cocok, Google Cloud akan memilih satu rute berbasis kebijakan menggunakan algoritma internal. Rute berbasis kebijakan yang dipilih mungkin bukan yang paling spesifik untuk sumber atau tujuan paket. Untuk menghindari ambiguitas ini, sebaiknya buat rute berbasis kebijakan dengan prioritas yang unik.

      • Jika model pemilihan rute Anda hanya menyertakan satu rute berbasis kebijakan yang memiliki prioritas tertinggi yang dikonfigurasi untuk melewati rute berbasis kebijakan lainnya, Google Cloud akan mengevaluasi rute yang tidak berbasis kebijakan di langkah tujuan paling spesifik dan mengabaikan semua rute berbasis kebijakan.

      • Jika model pemilihan rute Anda hanya menyertakan satu rute berbasis kebijakan yang memiliki prioritas tertinggi tidak dikonfigurasi untuk melewati rute berbasis kebijakan lainnya, Google Cloud mengirimkan paket ke Load Balancer Jaringan passthrough internal next hop, dan mengabaikan semua rute berbasis non-kebijakan.

  3. Tujuan paling spesifik: Google Cloud menentukan rute yang berlaku yang memiliki tujuan paling spesifik yang berisi alamat IP tujuan paket. Google Cloud mengabaikan semua rute lain dengan tujuan yang kurang spesifik. Misalnya, 10.240.1.0/24 adalah tujuan yang lebih spesifik daripada 10.240.0.0/16. Tujuan yang paling spesifik bisa berupa jenis rute apa pun; namun, rute subnet, rute subnet peering, dan jalur kembali khusus adalah yang paling spesifik menurut definisinya.

    Setelah langkah ini, model pemilihan rute Anda tidak berisi jalur kembali khusus atau rute berbasis kebijakan. Ini hanya mencakup rute dengan tujuan yang paling spesifik.

  4. Next hop dalam jaringan VPC tunggal: Langkah ini hanya berlaku jika jaringan VPC yang perilaku rutenya yang Anda modelkan terhubung ke satu atau beberapa jaringan VPC menggunakan Peering Jaringan VPC. Dengan Peering Jaringan VPC, rute kustom dengan tujuan yang identik mungkin ada di lebih dari satu jaringan dalam grup peering. Persyaratan yang dimodelkan pada langkah ini adalah Google Cloud memilih next hop yang semuanya berada dalam satu jaringan VPC.

    • Jika satu atau beberapa rute dalam model rute Anda memiliki next hop di dalam jaringan VPC yang Anda modelkan, abaikan semua rute yang memiliki next hop dalam jaringan peer. Dalam situasi ini, Google Cloud hanya menggunakan next hop di jaringan VPC lokal, meskipun next hop untuk tujuan yang sama ada di satu atau beberapa jaringan VPC peer.

    • Jika tidak ada rute di model rute Anda yang memiliki next hop di dalam jaringan VPC yang Anda modelkan, dan semua next hop ada di beberapa jaringan peer, Google Cloud menggunakan algoritma internal untuk memilih jaringan peer tunggal dengan next hop untuk tujuan yang paling spesifik. Prioritas rute tidak dipertimbangkan pada tahap ini. Selain itu, jika jaringan VPC Anda melakukan peering dengan jaringan VPC baru atau jika jaringan tersebut terputus dari jaringan VPC peer yang ada, jaringan VPC yang dipilih untuk next hop mungkin berubah.

    Setelah langkah ini, model pemilihan rute Anda hanya berisi rute dengan tujuan paling spesifik, dan next hop untuk rute ini semuanya berada dalam satu jaringan VPC.

  5. Abaikan rute statis kustom yang next hop-nya tidak berjalan: Langkah ini membuat model dua situasi saat Google Cloud mengabaikan next hop yang dianggap tidak berjalan. Langkah ini hanya berlaku untuk rute statis kustom. Rute dinamis kustom akan otomatis ditambahkan dan dihapus menggunakan pemberitahuan BGP.

    • Google Cloud mengabaikan setiap instance VM next hop (next-hop-instance atau next-hop-address) jika VM next hop telah dihentikan atau dihapus. Untuk mengetahui detail selengkapnya, lihat Perilaku saat instance dihentikan atau dihapus di bagian Pertimbangan untuk instance next hop. Jika model rute Anda berisi rute statis yang VM next hop-nya dihentikan atau dihapus, hapus rute tersebut dari model Anda.

    • Google Cloud mengabaikan setiap rute statis kustom yang menggunakan tunnel VPN klasik next hop jika tunnel tidak memiliki asosiasi keamanan (SA) Fase 1 (IKE). Untuk detail selengkapnya, lihat Urutan rute dalam dokumentasi VPN Klasik. Jika model rute Anda berisi rute statis yang next hop-nya adalah tunnel VPN Klasik tanpa SA IKE yang ditetapkan, hapus rute tersebut dari model Anda.

  6. Abaikan rute prioritas rendah: Langkah ini memodelkan cara Google Cloud membuang semua rute kecuali rute dengan prioritas tertinggi.

    Setelah langkah ini, model pemilihan rute Anda mungkin kosong, atau mungkin berisi satu atau beberapa rute. Jika model Anda berisi rute, semua rute memiliki semua karakteristik berikut:

    • Tujuan yang identik dan paling spesifik
    • Semua next hop-nya dalam satu jaringan VPC—jaringan VPC lokal atau jaringan VPC peer tunggal
    • Next hop yang tidak diketahui mengalami gangguan
    • Prioritas tertinggi yang identik

  7. Hanya pilih kategori preferensi yang paling disukai: Google Cloud akan menghindari pemilihan rute ECMP di antara berbagai jenis next hop. Anda dapat memodelkan perilaku ini dengan mempertimbangkan sistem kategori preferensi yang dijelaskan dalam tabel berikut. Langkah ini akan meningkatkan kualitas model rute Anda sehingga hanya berisi rute dengan jenis rute yang sama atau kombinasi jenis rute dan jenis next hop.

    Kategori preferensi Kombinasi kategori dan next hop
    Pilihan pertama (preferensi tertinggi) Rute statis kustom dengan instance next hop yang sedang berjalan (next-hop-instance atau next-hop-address ) atau SA IKE membentuk tunnel VPN Klasik next hop
    Pilihan kedua Rute dinamis kustom yang dipelajari dari sesi BGP apa pun di Cloud Router
    Pilihan ketiga Satu rute statis kustom dengan Google Cloud next hop Load Balancer Jaringan passthrough internal
    menggunakan algoritma internal untuk memilih satu Load Balancer Jaringan passthrough internal next hop, dengan mengabaikan next hop Load Balancer Jaringan passthrough internal lainnya dengan prioritas yang sama. Untuk detail selengkapnya, lihat "Tujuan yang sama dan beberapa Load Balancer Jaringan passthrough internal next hop" di bagian Pertimbangan untuk next hop Load Balancer Jaringan passthrough internal.
    Pilihan keempat Rute statis kustom menggunakan next hop default-internet-gateway

    Pada akhir langkah ini, mungkin ada nol rute, satu rute, atau dua atau beberapa rute di model rute.

  8. Kirim atau hentikan paket: Ini bergantung pada jumlah rute yang tersisa dalam model rute:

    • Jika model rute kosong, paket akan dihentikan dengan error pada tujuan ICMP atau jaringan yang tidak dapat dijangkau. Google Cloud tidak pernah kembali ke rute yang kurang spesifik yang mungkin memiliki next hop yang berfungsi.

    • Jika model rute berisi rute tunggal, Google Cloud akan mengirimkan paket ke next hop. Untuk next hop pada VM, Google Cloud tidak memvalidasi bahwa next hop VM dapat memproses paket. Untuk mengetahui detailnya, lihat Pertimbangan umum untuk next hop Load Balancer Jaringan passthrough internal dan instance. Jika rute tunggal adalah rute subnet atau rute subnet peering, dan tidak ada resource Google Cloud di alamat IP tujuan paket, paket akan dihentikan.

    • Jika model rute berisi dua rute atau lebih, rute tersebut berbagi tujuan paling spesifik yang sama, terletak di satu jaringan VPC, memiliki next hop yang tidak diketahui mengalami gangguan, memiliki prioritas tertinggi yang sama, dan termasuk dalam satu jenis rute dan kombinasi next hop (kategori preferensi). Google Cloud mendistribusikan paket di antara next hop yang menerapkan equal-cost multipath (ECMP) menggunakan algoritma hashing. Penghitungan hash dilakukan untuk setiap paket pada saat paket dikirim, berdasarkan jumlah next hop saat ini. Google Cloud menggunakan hash lima tuple jika paket tersebut berisi informasi port; jika tidak, model ini menggunakan hash tiga tuple. Jika model rute berubah saat paket berikutnya dikirim, Google Cloud mungkin mengarahkan paket tersebut ke next hop yang berbeda meskipun hash-nya sama.

Rute statis

Anda dapat membuat rute statis dengan salah satu dari dua cara berikut:

Anda dapat menukar rute statis dengan jaringan VPC yang di-peering seperti yang dijelaskan dalam Opsi untuk pertukaran rute statis kustom dalam dokumentasi Peering Jaringan VPC.

Parameter rute

Rute statis mendukung atribut berikut:

  • Nama dan Deskripsi. Kolom ini mengidentifikasi rute. Nama wajib diisi, tetapi deskripsi bersifat opsional. Setiap rute dalam project Anda harus memiliki nama yang unik.

  • Jaringan. Setiap rute harus dikaitkan dengan hanya satu jaringan VPC.

  • Next hop Next hop mengidentifikasi resource jaringan yang menjadi tujuan pengiriman paket. Semua jenis next hop mendukung tujuan IPv4, dan beberapa jenis next hop mendukung tujuan IPv6. Untuk informasi selengkapnya, lihat Next hop dan fitur-fitur.

  • Rentang tujuan. Rentang tujuan adalah notasi CIDR IPv4 atau IPv6 tunggal. Tujuan untuk rute statis harus mengikuti aturan yang dijelaskan dalam Interaksi dengan rute statis serta interaksi subnet dan rute statis. Tujuan terluas yang memungkinkan untuk rute statis IPv4 adalah 0.0.0.0/0. Tujuan terluas yang memungkinkan untuk rute statis IPv6 adalah ::/0.

  • Prioritas. Angka yang lebih kecil menunjukkan prioritas yang lebih tinggi. Prioritas tertinggi adalah 0, dan prioritas terendah adalah 65,535.

  • Tag jaringan. Anda dapat menerapkan rute statis hanya ke instance VM tertentu di jaringan VPC, yang diidentifikasi dengan tag jaringan. Jika Anda tidak menentukan tag jaringan, Google Cloud akan membuat rute statis berlaku untuk semua instance dalam jaringan. Rute statis dengan tag tidak pernah dipertukarkan saat menggunakan Peering Jaringan VPC.

Next hop dan fitur-fitur

Tabel berikut merangkum dukungan fitur rute statis berdasarkan jenis next hop:

Jenis next hop IPv4 IPv6 ECMP1
Gateway next hop (next-hop-gateway)
Menentukan gateway internet default untuk menentukan jalur ke alamat IP eksternal.
Instance next hop berdasarkan nama dan zona (next-hop-instance)
Mengirim paket ke VM next hop yang diidentifikasi berdasarkan nama dan zona, serta berada dalam project yang sama dengan rute. Untuk informasi selengkapnya, lihat Pertimbangan untuk instance next hop.
Instance next hop menurut alamat (next-hop-address)
Mengirim paket ke VM next hop yang diidentifikasi oleh alamat IPv4 utama antarmuka jaringannya. Untuk informasi selengkapnya, lihat Pertimbangan untuk instance next hop.
Load Balancer Jaringan passthrough internal next hop berdasarkan nama dan region aturan penerusan (next-hop-ilb)
Mengirim paket ke backend Load Balancer Jaringan passthrough internal yang diidentifikasi oleh nama dan region aturan penerusan. Untuk mengetahui informasi selengkapnya, baca bagian Pertimbangan untuk next hop Load Balancer Jaringan passthrough internal.
Load Balancer Jaringan passthrough internal next hop berdasarkan alamat (next-hop-ilb)
Mengirim paket ke backend Load Balancer Jaringan passthrough internal yang diidentifikasi dengan alamat IP aturan penerusan load balancer. Untuk mengetahui informasi selengkapnya, baca bagian Pertimbangan untuk next hop Load Balancer Jaringan passthrough internal.
Tunnel VPN klasik next hop (next-hop-vpn-tunnel)
Mengirim paket ke tunnel VPN Klasik next hop menggunakan pemilihan rute berbasis kebijakan atau VPN berbasis rute. Untuk informasi selengkapnya, lihat Pertimbangan untuk next hop tunnel VPN Klasik.
1Equal-cost multipath (ECMP) berarti dua rute statis atau lebih dapat memiliki rentang tujuan dan prioritas yang sama. Meskipun Anda dapat membuat dua atau beberapa rute statis dalam jaringan VPC dengan tujuan yang sama, prioritas yang sama, dan next hop gateway internet default, efeknya sama seperti memiliki satu rute statis yang menggunakan next hop gateway internet default untuk tujuan dan prioritas tersebut.

Jaringan dan project next hop

Next hop rute statis dikaitkan dengan jaringan VPC dan project:

  • Jaringan: Kecuali seperti yang ditunjukkan pada tabel di bawah, jaringan VPC next hop harus cocok dengan jaringan VPC rute.

  • Project: Kecuali seperti yang ditunjukkan pada tabel di bawah, next hop harus berada dalam project yang berisi jaringan VPC next hop (project mandiri atau project host VPC Bersama). Beberapa next hop dapat ditemukan di project layanan VPC Bersama.

Jenis next hop Dapat berada dalam jaringan VPC yang di-peering Dapat berada dalam project layanan VPC Bersama
Gateway next hop (next-hop-gateway)
Instance next hop berdasarkan nama (next-hop-instance)
Instance next hop berdasarkan alamat (next-hop-address)
Load Balancer Jaringan passthrough internal next hop berdasarkan aturan penerusan nama dan region (next-hop-ilb)
Load Balancer Jaringan passthrough internal next hop berdasarkan alamat (next-hop-ilb)
Tunnel VPN Klasik next hop (next-hop-vpn-tunnel)

Pertimbangan umum untuk next hop Load Balancer Jaringan passthrough internal dan instance

Pemilihan rute berbasis instance mengacu pada rute statis dengan next hop yang merupakan instance VM (next-hop-instance atau next-hop-address).

Load Balancer Jaringan passthrough internal sebagai next hop mengacu pada rute statis dengan next hop yang merupakan Load Balancer Jaringan passthrough internal (next-hop-ilb).

Saat Anda mengonfigurasi pemilihan rute berbasis instance atau Load Balancer Jaringan passthrough internal sebagai next hop, pertimbangkan pedoman berikut:

  • Anda harus mengonfigurasi VM backend atau instance next hop untuk meneruskan paket dari alamat IP sumber mana pun. Untuk mengonfigurasi penerusan, aktifkan penerusan IP (can-ip-forward) berbasis per VM saat Anda membuat VM. Untuk VM yang dibuat secara otomatis sebagai bagian dari grup instance terkelola, aktifkan penerusan IP di template instance yang digunakan oleh grup instance. Anda harus membuat perubahan konfigurasi ini sebagai tambahan pada konfigurasi sistem operasi yang diperlukan untuk merutekan paket.

  • Software yang berjalan di VM backend atau instance next hop harus dikonfigurasi dengan benar. Misalnya, VM perangkat pihak ketiga yang bertindak sebagai router atau firewall harus dikonfigurasi sesuai dengan petunjuk produsen.

  • VM backend atau instance next hop harus memiliki aturan firewall yang sesuai. Anda harus mengonfigurasi aturan firewall yang berlaku untuk paket yang dirutekan. Perhatikan hal-hal berikut:

    • Aturan firewall traffic masuk yang berlaku untuk instance yang menjalankan fungsi perutean harus menyertakan alamat IP sumber paket yang dirutekan. Aturan traffic masuk deny tersirat akan memblokir semua paket masuk, sehingga Anda setidaknya harus membuat aturan firewall allow traffic masuk kustom.
    • Aturan firewall traffic keluar yang berlaku untuk instance yang menjalankan fungsi perutean harus menyertakan alamat IP tujuan paket yang dirutekan. Aturan traffic keluar allow tersirat memberikan izin atas hal ini kecuali jika Anda telah menentukan aturan deny traffic keluar khusus untuk menggantikannya.
    • Pertimbangkan apakah VM backend atau Instance Next Hop menjalankan Penafsiran Alamat Jaringan (NAT) saat membuat aturan firewall.

    Untuk mengetahui informasi selengkapnya, lihat Aturan firewall tersirat.

  • Region sumber paket yang dikirim oleh VM backend atau instance next hop adalah region tempat VM backend atau instance next hop berada. Misalnya, paket yang diproses oleh VM backend atau instance next hop di us-west1 dapat dikirim ke tujuan yang hanya dapat diakses di us-west1 meskipun VM backend atau instance next hop awalnya menerima paket dari resource di region yang berbeda dengan us-west1. Contoh resource yang hanya dapat diakses di region yang sama dengan VM yang mengirim paket meliputi:

    • Load Balancer Jaringan passthrough internal, Load Balancer Aplikasi internal, dan Load Balancer Jaringan proxy internal regional dengan akses global dinonaktifkan
    • Tunnel Cloud VPN, lampiran VLAN Cloud Interconnect, dan VM perangkat Router Network Connectivity jika jaringan VPC menggunakan pemilihan rute dinamis regional

Pertimbangan untuk instance next hop

  • Next hop berdasarkan nama dan zona instance (next-hop-instance): Saat Anda membuat rute statis yang memiliki instance next hop yang ditentukan oleh zona dan nama instance, Google Cloud mengharuskan instance dengan nama tersebut berada di zona yang ditentukan, dan memenuhi kriteria berikut:

    • Instance tersebut berada dalam project yang sama dengan rute.
    • Instance memiliki antarmuka jaringan (NIC) di jaringan VPC rute (bukan jaringan VPC yang di-peering).

    Selama ada rute statis yang next hop-nya ditentukan berdasarkan nama dan zona instance, hal berikut akan diberlakukan:

    • Google Cloud akan otomatis memperbarui pemrograman untuk next hop dalam salah satu kasus berikut:

      • Alamat IPv4 internal utama dari instance next hop berubah, atau
      • Anda mengganti instance next hop, dan instance pengganti memiliki nama yang sama, berada di zona dan project yang sama, serta memiliki antarmuka jaringan di jaringan VPC rute.

    • Google Cloud tidak memperbarui pemrograman untuk next hop dalam kasus berikut:

      • Saat instance dihapus
      • Rentang alamat IPv6 yang ditetapkan ke NIC instance berubah
      • Jika alamat IPv4 atau IPv6 instance tidak ditetapkan

  • Alamat IP internal instance next hop (next-hop-address): Saat Anda membuat rute statis yang memiliki instance next hop yang ditentukan oleh alamat IPv4 internal, Google Cloud memverifikasi bahwa alamat IPv4 VM next hop sesuai dengan rentang subnet IPv4 dari subnet di jaringan VPC rute. Namun, Google Cloud akan memprogram rute hanya jika alamat next hop adalah alamat IPv4 internal utama yang ditetapkan ke NIC VM dalam jaringan VPC rute (bukan jaringan VPC yang di-peering).

    Google Cloud secara otomatis memperbarui pemrograman untuk next hop saat alamat IPv4 next hop dipindahkan ke VM yang berbeda, asalkan VM pengganti memenuhi persyaratan yang sama.

  • Instance next hop di project layanan VPC Bersama: Saat Anda menentukan VM next hop berdasarkan alamat IP, VM tersebut dapat berada di salah satu project yang sama sebagai rute (project mandiri atau project host VPC Bersama) atau VM dapat ditempatkan di project layanan VPC Bersama. Saat Anda menentukan VM next hop berdasarkan nama dan zona instance, VM next hop harus ditempatkan di project yang sama dengan rute dan jaringan VPC (project mandiri atau project host VPC Bersama).

  • Biaya dan latensi region-ke-region: Saat Anda menggunakan VM sebagai next hop, next hop tersebut berada di zona suatu region. Rute yang menggunakan next hop tersedia untuk semua instance dalam jaringan VPC yang sama atau untuk memilih instance dengan tag jaringan yang cocok. Google Cloud tidak mempertimbangkan jarak regional untuk rute yang menggunakan instance sebagai next hop, sehingga Anda dapat membuat rute yang mengirimkan traffic ke VM next hop di region yang berbeda. Mengirim paket dari satu region ke region lain akan menambahkan biaya transfer data keluar dan menimbulkan latensi jaringan.

  • Tidak dilakukan health check, tidak dilakukan validasi konfigurasi: Google Cloud tidak pernah memeriksa apakah instance next hop memenuhi semua persyaratan yang diuraikan dalam Pertimbangan umum untuk next hop Load Balancer Jaringan passthrough internal dan instance. Menonaktifkan antarmuka jaringan VM dengan mengonfigurasi sistem operasi tamu instance tidak menyebabkan Google Cloud mengabaikan instance next hop.

  • Tidak ada hashing simetris saat menghubungkan dua jaringan VPC: Google Cloud tidak menawarkan hashing simetris saat menggunakan dua VM next hop atau lebih yang memiliki beberapa antarmuka jaringan dalam konfigurasi yang memenuhi semua kriteria berikut:

    • VM memiliki satu antarmuka jaringan dalam satu jaringan VPC dan antarmuka lainnya dalam jaringan VPC kedua.
    • Di setiap jaringan VPC, ada set yang terdiri dari setidaknya dua rute statis kustom untuk tujuan yang sama, menggunakan prioritas yang sama, di mana setiap rute dalam set mereferensikan VM next hop yang unik.

    Jika Anda menggunakan dua VM atau lebih dengan beberapa antarmuka untuk menghubungkan jaringan VPC, dan Anda mengharuskan VM yang sama memproses paket untuk koneksi tertentu di kedua arah, Anda memerlukan hashing simetris, yang hanya didukung oleh Load Balancer Jaringan passthrough internal next hop. Untuk mengetahui detail tentang hashing simetris, lihat Dokumentasi hashing simetris di Load Balancer Jaringan passthrough internal sebagai next hop.

  • Perilaku saat instance dihentikan atau dihapus: Google Cloud tidak mencegah Anda dari menghentikan atau menghapus VM next hop rute statis (yang ditentukan berdasarkan nama dan zona atau alamat internal). Saat VM next hop tidak berjalan, pemilihan rute untuk tujuan bergantung pada adanya rute lain untuk tujuan yang sama persis dan jika rute lain tersebut memiliki next hop yang sedang berjalan. Untuk menggambarkan perilaku ini, pertimbangkan contoh berikut:

    • Paket yang tujuannya sesuai dengan 192.168.168.0/24 akan dikirim ke next hop dari route-vm-b dalam situasi berikut saat next hop untuk rute prioritas tertinggi tidak berjalan. Pemilihan rute ini terjadi karena Google Cloud mengabaikan next hop yang tidak berjalan sebelum mempertimbangkan langkah mengabaikan rute dengan prioritas rendah dalam urutan perutean:

      • route-vm-a, tujuan 192.168.168.0/24, prioritas 10, VM next hop dihentikan
      • route-vm-b, tujuan 192.168.168.0/24, prioritas 20, VM next hop sedang berjalan
      • route-vm-c, tujuan 192.168.168.0/24, prioritas 30, VM next hop sedang berjalan

    • Paket yang tujuannya sesuai dengan 192.168.168.0/24 akan dihentikan dalam contoh berikutnya saat semua VM next hop untuk rute 192.168.168.0/24 tidak berjalan, meskipun rute untuk 192.168.0.0/16 yang lebih luas memiliki VM next hop yang sedang berjalan. Paket tersebut dihentikan karena Google Cloud mengabaikan rute dengan rentang tujuan yang lebih luas (panjang subnet mask yang lebih pendek) pada langkah tujuan paling spesifik, yang terjadi sebelum langkah mengabaikan rute statis kustom yang next hop-nya tidak berjalan dari urutan pemilihan rute kami:

      • route-vm-x, tujuan 192.168.168.0/24, prioritas 10, VM next hop dihentikan
      • route-vm-y, tujuan 192.168.168.0/24, prioritas 20, VM next hop dihentikan
      • route-vm-z, tujuan 192.168.0.0/16, prioritas 0, VM next hop sedang berjalan

Pertimbangan untuk next hop Load Balancer Jaringan passthrough internal

  • Aturan penerusan yang didukung. Google Cloud hanya mendukung aturan penerusan Load Balancer Jaringan passthrough internal next hop. Google Cloud tidak mendukung aturan penerusan next hop yang digunakan oleh load balancer lain, penerusan protokol, atau sebagai endpoint Private Service Connect.

  • Metode spesifikasi serta jaringan dan project aturan penerusan. Anda dapat menentukan aturan penerusan next hop menggunakan salah satu dari tiga metode berikut. Metode spesifikasi yang Anda gunakan menentukan apakah jaringan aturan penerusan harus cocok dengan jaringan rute dan dalam project apa aturan penerusan tersebut dapat ditemukan:

    • Berdasarkan nama aturan penerusan (--next-hop-ilb) dan region (--next-hop-ilb-region): Saat Anda menentukan aturan penerusan next hop berdasarkan nama dan region, jaringan aturan penerusan harus cocok dengan jaringan VPC rute. Aturan penerusan harus berada dalam project yang sama yang berisi jaringan aturan penerusan (project mandiri atau project host VPC Bersama).

    • Berdasarkan aturan penerusan link resource: Link resource aturan penerusan menggunakan format /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, dengan PROJECT_ID adalah project ID dari project yang berisi aturan penerusan, REGION adalah region aturan penerusan, dan FORWARDING_RULE_NAME adalah nama aturan penerusan. Saat Anda menentukan aturan penerusan next hop berdasarkan link resource-nya, jaringan aturan penerusan harus cocok dengan jaringan VPC rute. Aturan penerusan dapat berada di salah satu project yang berisi jaringan aturan penerusan (project mandiri atau project host VPC Bersama) atau di project layanan VPC Bersama.

    • Dengan alamat IPv4 aturan penerusan: Saat Anda menentukan aturan penerusan next hop berdasarkan alamat IPv4-nya, jaringan aturan penerusannya dapat berupa salah satu dari jaringan VPC rute atau jaringan VPC yang di-peering. Aturan penerusan bisa juga ditempatkan di project yang berisi jaringan aturan penerusan (project mandiri atau project host VPC Bersama) atau project layanan VPC Bersama.

  • Pengaruh akses global. Rute statis kustom yang menggunakan next hop Load Balancer Jaringan passthrough internal diprogram di semua region. Kemampuan next hop untuk dapat digunakan bergantung pada setelan akses global load balancer. Dengan mengaktifkan akses global, next hop load balancer dapat diakses di semua region jaringan VPC. Jika akses global dinonaktifkan, next hop load balancer hanya dapat diakses di region yang sama dengan load balancer. Dengan menonaktifkan akses global, paket yang dikirim dari region lain ke rute menggunakan next hop Load Balancer Jaringan passthrough internal akan dihentikan.

  • Saat semua backend tidak responsif. Jika semua backend Load Balancer Jaringan passthrough internal gagal dalam health check, rute yang menggunakan next hop load balancer tersebut masih akan berpengaruh. Paket yang diproses oleh rute dikirim ke salah satu backend load balancer next hop sesuai dengan distribusi traffic.

  • Aturan penerusan yang menggunakan alamat IP internal yang umum (--purpose=SHARED_LOADBALANCER_VIP) tidak didukung. Load Balancer Jaringan passthrough internal next hop dan aturan penerusan Load Balancer Jaringan passthrough internal dengan alamat IP umum adalah fitur yang sama-sama eksklusif. Load Balancer Jaringan passthrough internal next hop harus menggunakan alamat IP yang unik untuk aturan penerusan load balancer, sehingga hanya satu layanan backend (satu load balancer) yang direferensikan dengan jelas. Anda dapat meneruskan aturan penerusan yang menggunakan alamat IP internal umum untuk mereferensikan layanan backend yang berbeda (Load Balancer Jaringan passthrough internal yang berbeda).

  • Tujuan yang sama dan beberapa Load Balancer Jaringan passthrough internal next hop. Jika Anda membuat dua atau lebih rute statis kustom dengan tujuan yang sama dan menggunakan next hop Load Balancer Jaringan passthrough internal yang berbeda, Google Cloud tidak pernah mendistribusikan traffic di antara next hop load balancer menggunakan ECMP. Jika rute memiliki prioritas unik, Google Cloud akan menggunakan Load Balancer Jaringan passthrough internal next hop dari rute dengan prioritas tertinggi. Jika rute memiliki prioritas yang setara, Google Cloud tetap hanya akan memilih satu Load Balancer Jaringan passthrough internal next hop. Dalam situasi terakhir tersebut, seperti yang diilustrasikan dalam diagram di bawah, Google Cloud menggunakan algoritma internal deterministik untuk memilih satu aturan penerusan next hop (forwarding-rule-a), mengabaikan rute lain dengan prioritas yang sama.

    Google Cloud memilih satu next hop saat rute statis dengan berbagai next hop load Balancer Jaringan passthrough internal yang berbeda memiliki prioritas dan tujuan yang sama.

  • Beberapa tujuan dan Load Balancer Jaringan passthrough internal next hop yang sama.

    Dengan tag instance:

    Jika menggunakan tag instance (juga disebut tag jaringan), Anda dapat menggunakan Load Balancer Jaringan passthrough internal next hop yang sama untuk beberapa rute statis kustom dengan tujuan dan prioritas yang sama.

    Tanpa tag instance: Tanpa tag instance, Anda tidak dapat membuat beberapa rute statis kustom yang memiliki kombinasi tujuan, prioritas, dan next hop Load Balancer Jaringan passthrough internal yang sama. Misalnya, route-x, route-y, dan route-z dapat dibuat, tetapi route-x-copy tidak dapat dibuat.

    Rute statis yang tidak memiliki tag instance tidak dapat dibuat dengan next hop Load Balancer Jaringan passthrough internal, prioritas, dan tujuan yang sama.

  • Tag instance.

    Anda dapat menentukan tag instance (juga disebut tag jaringan) sehingga rute next-hop hanya berlaku untuk instance klien yang telah dikonfigurasi dengan tag tersebut. Hal ini memungkinkan Anda memilih instance klien mana yang akan diisi dengan rute next-hop yang diberi tag dan set perangkat mana yang akan dirutekan traffic Anda.

    Anda tidak perlu memisahkan instance klien yang berbeda ke dalam beberapa jaringan VPC terpisah, karena masing-masing akan mengarah ke front-end Load Balancer Jaringan passthrough internal yang diinginkan dari suatu set perangkat.

  • Beberapa rute ke awalan tujuan yang sama. Dengan tag instance, Anda dapat menentukan beberapa rute ke tujuan yang sama dengan load balancer internal yang berbeda seperti next-hop. Anda dapat menggunakan tag instance yang berbeda atau prioritas yang berbeda untuk rute tujuan yang sama ini.

Pertimbangan untuk next hop tunnel VPN Klasik

  • Biaya dan latensi region-ke-region: Google Cloud tidak mempertimbangkan jarak regional untuk rute yang menggunakan tunnel VPN Klasik next hop. Mengirim traffic ke tunnel VPN Klasik hop berikutnya di region lain akan menambah biaya transfer data keluar dan menimbulkan latensi jaringan. Sebagai praktik terbaik, gunakan tunnel VPN dengan ketersediaan tinggi (HA) bersamaan dengan pemilihan rute dinamis karena konfigurasi tersebut memperhatikan jarak regional.

  • Perilaku saat tunnel VPN Klasik tidak berjalan: Rute statis kustom yang next hop-nya adalah tunnel VPN Klasik tidak otomatis dihapus saat tunnel VPN Klasik tidak berjalan. Untuk mengetahui detail tentang hal yang terjadi saat tunnel tidak berjalan, lihat Saat tunnel tidak aktif dalam dokumentasi VPN Klasik.

Langkah selanjutnya