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 konsisten.

Jenis rute

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

Jenis dan tujuan Hop berikutnya Catatan
Rute berbasis kebijakan: Rute berbasis kebijakan dievaluasi sebelum jenis rute lainnya.
Rute berbasis kebijakan
Rute berbasis kebijakan dapat berlaku untuk paket berdasarkan alamat IP sumber, alamat IP tujuan, protokol, atau kombinasinya.

Rute berbasis kebijakan dapat berlaku untuk semua VM di jaringan, ke VM tertentu yang dipilih oleh tag jaringan, atau untuk traffic yang masuk ke jaringan VPC melalui lampiran VLAN untuk Cloud Interconnect (hanya di satu region, atau di semua region).

Rute berbasis kebijakan tidak pernah dipertukarkan melalui Peering Jaringan VPC.
Rute subnet: Semua jenis rute subnet dievaluasi setelah rute berbasis kebijakan, tetapi sebelum rute kustom.
Rute subnet lokal
Dibuat secara otomatis untuk setiap rentang alamat IP subnet 		Jaringan VPC

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

Rute subnet lokal berlaku untuk seluruh jaringan VPC.
Rute subnet peering
Mewakili rentang alamat IP subnet di jaringan VPC yang 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 subnet Network Connectivity Center
Mewakili rentang alamat IP subnet di spoke VPC (jaringan VPC lain yang terhubung ke hub Network Connectivity Center) 		Hub Network Connectivity Center

Administrator spoke 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 kustom: Rute kustom dievaluasi setelah rute berbasis kebijakan dan setelah rute subnet.
Rute statis lokal
Mendukung berbagai tujuan 		Meneruskan paket ke next hop rute statis Untuk detail tentang setiap next hop rute statis, lihat pertimbangan untuk:
Rute dinamis lokal
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 statis peering, rute dinamis peering
Rute statis atau dinamis di jaringan VPC yang 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 bertukar rute dinamis.

Rute dinamis peering berlaku untuk satu region atau semua region jaringan VPC sesuai dengan mode pemilihan rute dinamis jaringan VPC yang mengekspor rute.
Rute dinamis Network Connectivity Center
Rute dinamis yang diimpor dari spoke hybrid Network Connectivity Center yang berada di jaringan VPC yang berbeda 		Hub Network Connectivity Center

Hub Network Connectivity Center dapat memiliki spoke VPC dan spoke hybrid.

Rute dinamis Network Connectivity Center berlaku untuk satu region atau semua region jaringan VPC sesuai dengan mode pemilihan rute dinamis jaringan VPC yang berisi spoke hybrid.
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

Setiap subnet memiliki setidaknya satu rute subnet untuk setiap rentang alamat IP yang terkait dengan subnet. Untuk mengetahui informasi selengkapnya tentang rentang IP subnet, lihat Subnet.

Jenis rute subnet

Jaringan VPC dapat menyertakan jenis rute subnet berikut:

  • Rute subnet untuk subnet di jaringan VPC yang sama, yang disebut sebagai rute subnet lokal.
  • Rute subnet Network Connectivity Center yang diimpor dari spoke VPC hub Network Connectivity Center.
  • Rute subnet peering yang diimpor dari jaringan yang terhubung menggunakan Peering Jaringan VPC.

Rentang tujuan untuk semua jenis rute subnet harus unik. Untuk mengetahui informasi selengkapnya, lihat:

Siklus proses rute subnet

Semua rentang alamat IP yang merupakan bagian dari subnet—rentang alamat IPv4 utama, rentang alamat IPv4 sekunder, dan rentang alamat IPv6—memiliki rute subnet yang sesuai. Google Cloud membuat dan menghapus rute subnet dalam skenario berikut:

  • Anda membuat perubahan konfigurasi subnet, misalnya:

    • Menambahkan atau menghapus subnet.
    • Memperluas rentang IPv4 utama.
    • Menambahkan atau menghapus rentang IPv4 sekunder.
    • Menambahkan atau menghapus rentang IPv6.

  • Google Cloud menambahkan region baru, yang secara otomatis menambahkan subnet baru ke jaringan mode VPC otomatis. Untuk mengetahui informasi tentang rentang alamat IPv4 untuk setiap subnet berdasarkan region-nya, lihat rentang IPv4 mode otomatis.

Rute dinamis

Cloud Router memerintahkan jaringan VPC untuk membuat, mengupdate, dan menghapus rute dinamis berdasarkan pesan Border Gateway Protocol (BGP) yang diterima, kebijakan rute BGP yang berlaku (Pratinjau), dan rute kustom Cloud Router yang dipelajari.

Rute dinamis dibuat di satu region atau di semua region berdasarkan mode pemilihan rute dinamis dan mode pemilihan jalur terbaik jaringan VPC yang berisi Cloud Router. Untuk informasi selengkapnya, lihat referensi berikut:

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. Untuk informasi selengkapnya, lihat Perubahan status BGP.

Jenis rute dinamis

Jaringan VPC dapat menyertakan jenis rute dinamis berikut:

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

Rute default yang dibuat oleh sistem

Rute default memiliki tujuan terluas yang memungkinkan: 0.0.0.0/0 untuk IPv4 dan ::/0 untuk IPv6. Google Cloud hanya menggunakan rute default untuk mengirimkan paket jika paket tidak cocok dengan rute yang lebih spesifik dalam urutan pemilihan rute.

Tidak adanya rute default tidak selalu mengisolasi jaringan Anda dari internet karena jalur perutean khusus untuk Load Balancer Jaringan passthrough eksternal dan penerusan protokol eksternal tidak bergantung pada rute default.

Saat Anda membuat jaringan VPC, Google Cloud akan menambahkan rute default IPv4 yang dihasilkan sistem ke jaringan VPC. Rute default IPv4 yang dibuat sistem adalah rute statis lokal yang memiliki tujuan 0.0.0.0/0 dan next hop gateway internet default. Rute statis lokal dengan tujuan 0.0.0.0/0 dan next hop gateway internet default menyediakan jalur ke alamat IPv4 eksternal, termasuk alamat IPv4 di internet. Contoh resource berikut menggunakan jalur ini:

  • VM dengan alamat IPv4 eksternal yang ditetapkan ke antarmuka jaringannya, jika paket yang dikirim memiliki sumber yang cocok dengan alamat IPv4 internal utama antarmuka jaringan.
  • Gateway Cloud NAT publik yang dikonfigurasi untuk menyediakan layanan NAT ke subnet yang digunakan oleh antarmuka jaringan VM. Bergantung pada rentang alamat IPv4 subnet yang dikonfigurasi gateway Cloud NAT untuk melayani, sumber paket dapat cocok dengan salah satu dari hal berikut:
    • Alamat IPv4 internal dari rentang alamat IP alias antarmuka jaringan VM (baik antarmuka jaringan memiliki alamat IPv4 eksternal maupun tidak), atau
    • Alamat IPv4 internal utama dari antarmuka jaringan VM jika antarmuka jaringan tidak menetapkan alamat IPv4 eksternal.

Saat Anda membuat subnet yang memiliki rentang alamat IPv6 eksternal, Google Cloud akan menambahkan rute default IPv6 yang dihasilkan sistem ke jaringan VPC jika belum ada. Rute default IPv6 yang dihasilkan sistem adalah rute statis lokal yang memiliki tujuan ::/0 dan next hop gateway internet default. Rute statis lokal dengan tujuan ::/0 dan next hop gateway internet default menyediakan jalur ke alamat IPv6 eksternal, termasuk alamat IPv6 di internet. Jalur ini dapat digunakan oleh hal berikut:

  • VM dengan rentang alamat IPv6 eksternal /96 yang ditetapkan ke antarmuka jaringannya, saat paket yang dikirim memiliki sumber dalam rentang alamat /96 tersebut.

Mengakses Google API global terkadang bergantung pada rute default IPv4 atau IPv6 lokal dengan next hop gateway internet default:

  • Jika Anda mengakses Google API dan layanan global dengan mengirim paket ke endpoint Private Service Connect untuk Google API global, jaringan VPC Anda tidak memerlukan rute default dengan next hop gateway internet default. Google Cloud menambahkan jalur pemilihan rute khusus ke endpoint.

  • Jika Anda mengakses Google API dan layanan global dengan mengirim paket ke alamat IPv4 atau IPv6 untuk domain default, alamat IPv4 atau IPv6 untuk private.googleapis.com, atau alamat IPv4 atau IPv6 untuk restricted.googleapis.com, Anda dapat menggunakan rute IPv4 dan IPv6 default yang memiliki next hop gateway internet default, atau Anda dapat membuat dan menggunakan rute statis IPv4 dan IPv6 yang memiliki tujuan dan next hop gateway internet default yang lebih spesifik:

    • Jika VM Anda hanya memiliki alamat IP internal, lihat Opsi rute untuk Akses Google Pribadi.
    • Jika VM Anda memiliki alamat IP eksternal, lihat Opsi rute.

Interaksi rute

Bagian berikut menjelaskan interaksi antara rute subnet dan jenis rute lainnya.

Interaksi antara rute subnet dan rute statis

Google Cloud menerapkan aturan berikut untuk rute subnet lokal, rute subnet peering, dan rute subnet Network Connectivity Center kecuali jika subnet yang sesuai telah dikonfigurasi sebagai subnet hybrid.

  • Google Cloud tidak mengizinkan Anda membuat rute statis baru jika tujuan rute statis baru sama persis atau sesuai dengan tujuan rute subnet lokal, peering, atau Network Connectivity Center yang ada. Contoh:

    • Jika ada rute subnet lokal, peering, atau Network Connectivity Center dengan tujuan 10.70.1.0/24, Anda tidak dapat membuat rute statis 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 peering dengan tujuan 2001:0db8:0a0b:0c0d::/64, Anda tidak dapat membuat rute statis baru untuk 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96, atau tujuan lain yang sesuai dengan 2001:0db8:0a0b:0c0d::/64.

  • Google Cloud tidak mengizinkan Anda melakukan perubahan pada subnet yang menghasilkan rentang alamat IP subnet yang sama persis atau berisi tujuan rute statis lokal atau peering yang ada. Contoh:

    • Jika jaringan VPC Anda memiliki rute statis dengan tujuan 10.70.1.128/25, Anda tidak dapat membuat subnet baru yang memiliki rentang alamat IPv4 primer atau sekunder 10.70.1.128/25, 10.70.1.0/24, atau rentang alamat IP lainnya yang berisi semua alamat IPv4 di 10.70.1.128/25.

    • Jika jaringan VPC Anda memiliki rute statis dengan tujuan 2001:db8:a0b:c0d:e0f:f0e::/96, Google Cloud melarang pembuatan rute subnet lokal atau peering baru yang memiliki rentang alamat IPv6 2001:db8:a0b:c0d::/64 atau rentang lain yang berisi semua alamat IPv6 di 2001:db8:a0b:c0d:e0f:f0e::/96.

Interaksi antara rute subnet dan rute dinamis

Google Cloud menerapkan aturan berikut kecuali subnet telah dikonfigurasi sebagai subnet hybrid.

  • Google Cloud tidak membuat rute dinamis jika Cloud Router mengirim awalan yang sama persis atau sesuai dengan tujuan rute subnet lokal, peering, atau Network Connectivity Center yang ada. Contoh:

    • Jika rute subnet lokal, peering, atau Network Connectivity Center ada dengan tujuan 10.70.1.0/24, dan jika Cloud Router di jaringan VPC, jaringan VPC yang di-peering, atau jaringan yang berisi spoke hybrid Network Connectivity Center menerima 10.70.1.128/25, 10.70.1.0/24, atau awalan lain yang sesuai dengan 10.70.1.0/24, Google Cloud tidak akan membuat rute dinamis lokal, peering, atau Network Connectivity Center untuk awalan yang mengalami konflik yang diterima.

    • Jika rute subnet lokal, peering, atau Network Connectivity Center ada dengan tujuan 2001:0db8:0a0b:0c0d::/64, dan jika Cloud Router di jaringan VPC, jaringan VPC yang melakukan peering, atau jaringan yang berisi spoke campuran Network Connectivity Center menerima 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64, atau awalan lain yang sesuai dengan 2001:0db8:0a0b:0c0d::/64, Google Cloud tidak akan membuat rute dinamis lokal, peering, atau Network Connectivity Center untuk awalan yang bertentangan yang diterima.

  • Google Cloud akan menghapus rute dinamis yang ada jika perubahan pada subnet menghasilkan pembuatan rute subnet lokal, peering, atau Network Connectivity Center baru yang tujuannya sama persis atau berisi tujuan rute dinamis lokal, peering, atau Network Connectivity Center yang ada. Contoh:

    • Jika jaringan VPC Anda memiliki rute dinamis lokal, peering, atau Network Connectivity Center dengan tujuan 10.70.1.128/25, Google Cloud akan menghapus rute dinamis saat rute subnet lokal, peering, atau Network Connectivity Center baru untuk 10.70.1.128/25, 10.70.1.0/24, atau rentang alamat IP lainnya yang berisi semua alamat IPv4 di 10.70.1.128/25 dibuat.

    • Jika jaringan VPC Anda memiliki rute dinamis lokal, peering, atau Network Connectivity Center dengan tujuan 2001:db8:a0b:c0d::/96, Google Cloud akan menghapus rute dinamis saat rute subnet lokal, peering, atau Network Connectivity Center baru untuk 2001:db8:a0b:c0d::/64 dibuat.

Pemberlakuan dan urutan

Rute yang berlaku

Setiap instance, tunnel Cloud VPN, dan lampiran VLAN memiliki serangkaian rute yang berlaku—rute yang berlaku untuk resource tertentu tersebut. Rute yang berlaku adalah subset dari semua rute di jaringan VPC.

Jenis rute berikut selalu berlaku untuk semua instance VM, lampiran VLAN, dan tunnel Cloud VPN:

Jenis rute berikut dapat dikonfigurasi agar hanya berlaku untuk instance VM, lampiran VLAN, atau tunnel Cloud VPN tertentu:

  • Rute berbasis kebijakan dapat diterapkan ke:

    • Semua instance VM, lampiran VLAN, dan tunnel Cloud VPN
    • Hanya instance VM yang diidentifikasi oleh tag jaringan
    • Hanya lampiran VLAN di region tertentu

  • Rute statis dapat diterapkan ke:

    • Semua instance VM, lampiran VLAN, dan tunnel Cloud VPN
    • Hanya instance VM yang diidentifikasi oleh tag jaringan

  • Rute dinamis dapat diterapkan ke instance VM, lampiran VLAN, dan tunnel Cloud VPN di region yang berisi next hop rute dinamis atau semua region, berdasarkan mode pemilihan rute dinamis jaringan VPC.

Jalur pemilihan rute khusus

Jaringan VPC memiliki rute khusus untuk layanan tertentu. Jalur perutean khusus ini tidak muncul di tabel rute jaringan VPC Anda. Anda tidak dapat menghapus jalur pemilihan rute khusus. Namun, Anda dapat mengizinkan atau menolak paket menggunakan aturan firewall VPC atau kebijakan firewall.

Jalur untuk Load Balancer Jaringan passthrough eksternal dan penerusan protokol eksternal

Load Balancer Jaringan passthrough eksternal dan penerusan protokol eksternal menggunakan sistem Maglev untuk merutekan paket dari klien di internet ke VM backend dan instance target di jaringan VPC Anda. Sistem Maglev ini merutekan paket yang memiliki tujuan yang cocok dengan tujuan aturan penerusan eksternal.

Setiap aturan penerusan untuk Load Balancer Jaringan passthrough eksternal atau untuk penerusan protokol eksternal juga menyediakan jalur pemilihan rute untuk VM backend atau instance target untuk mengirim paket ke tujuan di luar jaringan VPC:

  • Paket yang dikirim oleh VM backend atau instance target dapat berupa paket respons keluar (dikirim kembali ke klien) atau berupa paket keluar yang memulai koneksi baru.
  • Sumber paket harus cocok dengan alamat IP aturan penerusan. Protokol paket dan port sumber tidak harus cocok dengan spesifikasi protokol dan port aturan penerusan.
  • Jalur pemilihan rute aturan penerusan tidak bergantung pada rute default atau penggunaan next hop gateway internet default.
  • VM backend dan instance target tidak perlu mengaktifkan penerusan IP.

Jalur antara Google Front End dan backend

Load Balancer Aplikasi Eksternal dan Load Balancer Jaringan proxy eksternal menggunakan Google Front End (GFE). GFE lapisan kedua membuka koneksi TCP ke VM backend Anda dan mengirim paket dari sumber berikut:

  • 35.191.0.0/16
  • 130.211.0.0/22

Google Cloud menggunakan rute di jaringan Google untuk mengirimkan paket dari rentang sumber tersebut ke VM backend di jaringan VPC Anda. Setiap jaringan VPC menyertakan jalur pemilihan rute yang memungkinkan VM mengirim paket respons ke 35.191.0.0/16 dan 130.211.0.0/22.

Jalur untuk health check

Health check untuk semua load balancer dan untuk autohealing grup instance terkelola mengirim paket ke VM backend Anda dari rentang alamat IP pemeriksaan kondisi health check.

Google Cloud menggunakan rute di jaringan Google untuk mengirimkan paket dari sistem pemeriksaan health check ke VM di jaringan VPC Anda. Setiap jaringan VPC menyertakan jalur perutean yang memungkinkan VM mengirim paket respons ke sistem pemeriksaan kondisi health check.

Jalur untuk Identity-Aware Proxy (IAP)

Penerusan TCP menggunakan IAP menggunakan 35.235.240.0/20 sebagai rentang khusus internal dengan next hop yang sepenuhnya berada dalam jaringan Google. Google tidak memublikasikan rute ke 35.235.240.0/20 di internet.

Rute di jaringan Google mengirimkan paket dari 35.235.240.0/20 ke VM di jaringan VPC Anda saat Anda menggunakan penerusan TCP IAP. Setiap jaringan VPC menyertakan jalur perutean yang memungkinkan VM mengirim paket respons ke 35.235.240.0/20.

Jalur untuk Cloud DNS dan Direktori Layanan

Fitur Cloud DNS dan Direktori Layanan berikut menggunakan 35.199.192.0/19 sebagai rentang khusus internal dengan next hop yang sepenuhnya berada dalam jaringan Google. Google tidak memublikasikan rute ke 35.199.192.0/19 di internet.

Rute di jaringan Google mengirimkan paket dari 35.199.192.0/19 ke VM di jaringan VPC Anda saat Anda menggunakan fitur Cloud DNS dan Direktori Layanan ini. Setiap jaringan VPC menyertakan jalur rute yang memungkinkan VM mengirim paket respons ke 35.199.192.0/19.

Jalur untuk Akses VPC Serverless

Akses VPC Serverless menggunakan 35.199.224.0/19 sebagai rentang khusus internal dengan next hop yang sepenuhnya berada dalam jaringan Google. Google tidak memublikasikan rute ke 35.199.224.0/19 di internet.

Rute di jaringan Google mengirimkan paket dari 35.199.224.0/19 ke instance konektor Akses VPC Serverless. Setiap jaringan VPC menyertakan jalur pemilihan rute yang memungkinkan instance konektor mengirim paket respons ke 35.199.224.0/19.

Jalur untuk endpoint Private Service Connect untuk Google API global

Saat Anda membuat endpoint Private Service Connect untuk Google API global, Google Cloud akan menambahkan rute untuk endpoint ke jaringan VPC Anda. Tujuan rute adalah alamat IP internal global dari endpoint.

Urutan pemilihan rute

Mungkin ada lebih dari satu rute yang berlaku untuk paket tertentu. Langkah-langkah berikut membuat model proses yang digunakan untuk memilih rute.

  1. Jalur pemilihan rute khusus: Beberapa jalur pemilihan rute khusus Google Cloud tidak ditampilkan di tabel rute jaringan VPC Anda. Untuk mengetahui detailnya, lihat Jalur pemilihan rute khusus.

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

  2. Rute berbasis kebijakan: Rute berbasis kebijakan dievaluasi setelah jalur pemilihan rute 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 rute subnet.

    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 rute subnet.

    • 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 mengabaikan semua rute berbasis kebijakan dan melanjutkan ke langkah rute subnet.

    • 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. Rute subnet: Google Cloud menentukan apakah tujuan paket sesuai dengan rentang tujuan rute subnet lokal, peering, atau Network Connectivity Center di jaringan VPC.

    • Jika tujuan paket tidak cocok dengan rentang tujuan rute subnet lokal, peering, atau Network Connectivity Center, Google Cloud akan mengabaikan semua rute subnet dan melanjutkan ke langkah Tujuan paling spesifik.

    • Jika tujuan paket cocok dengan rentang tujuan rute subnet lokal, peering, atau Network Connectivity Center di jaringan VPC, perilakunya akan berbeda bergantung pada apakah subnet telah dikonfigurasi sebagai subnet campuran:

      • Untuk sebagian besar subnet, Google Cloud secara eksklusif menggunakan rute subnet, yang mencoba mengirim paket ke resource di subnet, seperti antarmuka jaringan VM atau aturan penerusan internal. Semua rute lainnya diabaikan, dan evaluasi berhenti pada langkah ini. Jika tidak ada resource yang menggunakan tujuan paket atau jika resource adalah instance VM yang dihentikan, paket akan dihapus.

      • Namun, jika rute subnet yang cocok berasal dari subnet hybrid, Google Cloud akan mencoba menemukan resource tujuan yang cocok di subnet, seperti antarmuka jaringan VM atau aturan penerusan internal:

        • Jika ada resource di subnet, Google Cloud akan secara eksklusif menggunakan rute subnet, yang mencoba mengirim paket ke resource. Semua rute lainnya diabaikan, dan evaluasi berhenti pada langkah ini. Jika tidak ada resource di tujuan paket, paket akan dihapus. Jika resource adalah VM yang tidak berjalan, paket juga akan dihentikan.

        • Jika resource tidak ada di subnet, Google Cloud akan mengabaikan semua rute subnet, termasuk rute subnet yang cocok, dan melanjutkan ke langkah Tujuan paling spesifik.

  4. Tujuan paling spesifik: Di awal langkah ini, model pemilihan rute Anda tidak berisi jalur pemilihan rute khusus, rute berbasis kebijakan, dan rute subnet lokal, peering, atau Network Connectivity Center.

    Google Cloud menentukan rute yang berlaku yang tersisa 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.

    Di akhir langkah ini, model pemilihan rute Anda hanya berisi rute kustom dengan tujuan yang sama.

  5. Hanya pilih jenis rute kustom yang paling disukai: Pada langkah ini, Google Cloud akan menghapus semua rute kustom kecuali jenis rute kustom yang paling disukai. Rute kustom lokal lebih diutamakan daripada rute dinamis Network Connectivity Center, dan rute dinamis Network Connectivity Center lebih diutamakan daripada rute kustom peering.

    Tabel berikut meringkas logika yang digunakan Google Cloud dalam langkah ini.

    Kategori rute kustom Yang terjadi
    Rute statis lokal dan dinamis lokal

    Jika model rute Anda berisi minimal satu rute dinamis lokal atau rute statis lokal untuk tujuan, Google Cloud akan menghapus jenis rute kustom berikut, jika ada dalam model rute:

    • Rute dinamis Network Connectivity Center dari spoke hybrid, di jaringan VPC yang berbeda
    • Rute dinamis peering (diimpor dari jaringan VPC lain yang terhubung menggunakan Peering Jaringan VPC)
    Rute dinamis Network Connectivity Center Jika semua kondisi berikut terpenuhi, Google Cloud akan menghapus semua rute dinamis peering dan rute statis peering dari model rute:
    • Model rute Anda tidak berisi rute kustom lokal apa pun untuk tujuan
    • Mode rute Anda berisi setidaknya satu rute dinamis Network Connectivity Center untuk tujuan
    • Rute dinamis Network Connectivity Center berasal dari spoke hybrid di jaringan VPC yang berbeda
    Rute peering dinamis dan peering statis Jenis rute kustom yang paling tidak menguntungkan berisi rute kustom peering. Rute kustom peering untuk tujuan hanya digunakan jika model rute tidak berisi rute kustom lokal atau rute dinamis Network Connectivity Center untuk tujuan.

  6. Memilih next hop untuk rute kustom peering dari satu jaringan VPC: Next hop untuk tujuan yang sama harus berada di jaringan VPC yang sama. Langkah ini hanya berlaku jika model rute Anda berisi rute peering dinamis atau peering statis yang diimpor dari dua atau beberapa jaringan VPC berbeda yang terhubung menggunakan Peering Jaringan VPC.

    Google Cloud menggunakan algoritma internal untuk mengimpor rute kustom peering dari satu jaringan VPC. Jaringan peer yang dipilih Google Cloud mungkin berubah jika jaringan VPC Anda melakukan peering dengan jaringan VPC baru atau jika jaringan tersebut terputus dari jaringan VPC peer yang ada.

  7. Abaikan rute statis dan dinamis dengan next hop yang tidak dapat digunakan: Langkah ini membuat model situasi saat Google Cloud mengabaikan next hop yang tidak aktif atau tidak valid.

    • Spesifikasi alamat IP VM next hop tidak valid: next-hop-address rute statis harus cocok dengan alamat IP yang ditetapkan ke VM di jaringan VPC rute. Alamat IP harus ditetapkan ke antarmuka jaringan VM sebagai salah satu dari berikut:

      • Alamat IPv4 internal utama
      • Alamat IPv6 internal
      • Alamat IPv6 eksternal

      Jika alamat IP yang ditentukan oleh next-hop-address cocok dengan jenis resource yang berbeda (seperti rentang IP alias) atau tidak cocok dengan resource apa pun, Google Cloud akan mengabaikan rute tersebut.

    • VM next hop dihentikan atau dihapus: Google Cloud mengabaikan setiap rute statis yang instance VM next hop-nya telah dihentikan atau dihapus. Perilaku ini berlaku untuk rute yang next hop-nya ditentukan menggunakan next-hop-instance atau next-hop-address. Untuk mengetahui informasi selengkapnya, lihat Perilaku saat instance dihentikan atau dihapus.

    • Spesifikasi alamat IP load balancer next hop tidak valid: Untuk rute statis yang memiliki load balancer next hop yang ditentukan oleh alamat IP, alamat IP harus cocok dengan aturan penerusan Network Load Balancer passthrough internal yang berada di jaringan VPC rute atau di jaringan VPC yang di-peering. Jika alamat IP next hop cocok dengan aturan penerusan jenis load balancer yang berbeda atau tidak cocok dengan aturan penerusan apa pun, Google Cloud akan mengabaikan rute tersebut.

    • Tunnel VPN Klasik next hop yang belum dibuat: Google Cloud mengabaikan setiap rute statis dengan tunnel VPN klasik next hop yang tidak memiliki asosiasi keamanan (SA) Fase 1 (IKE) yang aktif. Untuk detail selengkapnya, lihat Urutan rute dalam dokumentasi VPN Klasik.

    • Rute dinamis dengan next hop yang tidak berfungsi: Bahkan sebelum sesi BGP yang bertanggung jawab untuk memprogram rute dinamis mengalami gangguan, Google Cloud akan mengabaikan rute dinamis jika tunnel Cloud VPN next hop-nya, lampiran VLAN, atau VM peralatan Router tidak berfungsi. Situasi ini umumnya hanya ada selama beberapa detik sebelum rute dinamis dihapus saat sesi BGP Cloud Router yang sesuai mengalami gangguan.

    Google Cloud tidak memvalidasi apakah OS tamu VM next hop atau VM backend untuk load balancer next hop memproses paket. Untuk mengetahui informasi selengkapnya, lihat Pertimbangan umum untuk next hop Load Balancer Jaringan passthrough internal dan instance.

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

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

    • Prioritas yang sama
    • Next hop yang belum diabaikan
    • Tujuan yang identik
    • Jenis rute yang bukan rute berbasis kebijakan atau subnet

  9. Pilih next hop untuk rute dinamis Network Connectivity Center dari satu jaringan VPC: Next hop untuk tujuan yang sama harus berada di jaringan VPC yang sama. Langkah ini hanya berlaku jika model rute Anda berisi rute dinamis Network Connectivity Center yang diimpor dari dua atau beberapa spoke hybrid yang terletak di jaringan VPC yang berbeda.

    Google Cloud menggunakan algoritma internal untuk mengimpor rute dinamis Network Connectivity Center dari spoke hybrid yang terletak di satu jaringan VPC. Spoke hybrid yang dipilih dapat berubah jika Anda menambahkan spoke hybrid ke atau menghapus spoke hybrid dari hub Network Connectivity Center. Untuk menghindari ambiguitas ini, pastikan rute dinamis Network Connectivity Center memiliki prioritas yang unik jika hal berikut berlaku:

    • Rute memiliki tujuan yang identik.
    • Rute diimpor dari dua spoke hybrid atau lebih di jaringan VPC yang berbeda.

  10. Hanya pilih kategori preferensi yang paling disukai: Google Cloud tidak melakukan multi-jalur biaya sama (ECMP) di antara rute yang termasuk dalam kategori preferensi yang berbeda, seperti yang ditentukan dalam langkah ini.

    Kategori preferensi Jenis rute dan jenis next hop
    Preferensi pertama (paling disukai) Satu atau beberapa rute statis dengan instance next hop (next-hop-instance atau next-hop-address) atau tunnel VPN Klasik next hop.
    Preferensi kedua Satu atau beberapa rute dinamis dari satu jenis.
    Pilihan ketiga Satu rute statis dengan next hop Load Balancer Jaringan passthrough internal.
    Preferensi keempat (paling tidak disukai) Satu atau beberapa rute statis dengan next hop default-internet-gateway.

    Pada langkah ini, jika ada dua atau beberapa rute statis dengan load balancer next hop, Google Cloud akan memilih satu rute statis menggunakan algoritma internal. Google Cloud tidak melakukan ECMP di antara beberapa load balancer. Untuk mengetahui informasi selengkapnya, lihat Pertimbangan untuk next hop Load Balancer Jaringan passthrough internal.

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

    • Kategori preferensi yang sama
    • Prioritas yang sama
    • Next hop yang belum diabaikan
    • Next hop dalam satu jaringan VPC
    • Tujuan yang identik
    • Jenis rute yang bukan rute berbasis kebijakan atau subnet

  11. Kirim atau hentikan paket: Bergantung pada jumlah rute yang tersisa dalam model rute, Google Cloud akan mengirim atau menghentikan paket:

    • Jika model rute Anda berisi rute tunggal, Google Cloud akan mengirimkan paket ke next hop, dengan pengecualian berikut:

      Load Balancer Jaringan passthrough internal next hop yang tidak mengaktifkan akses global tidak dapat dijangkau dari region di luar region load balancer. Akibatnya, jika next hop load balancer tidak mengaktifkan akses global, Google Cloud akan menghapus semua paket yang dikirim dari instance VM, lampiran VLAN, dan tunnel Cloud VPN di region yang berbeda dari region load balancer. Untuk mengubah perilaku ini, aktifkan akses global.

    • Jika model rute Anda berisi dua rute atau lebih, Google Cloud akan menjalankan ECMP, yang mendistribusikan paket di antara next hop. Pemilihan next hop bergantung pada penghitungan hash dan jumlah next hop. 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.

    • Jika model rute Anda kosong, Google Cloud akan menghapus paket dengan pesan ICMP jenis 3, kode 0 (jaringan tidak dapat dijangkau).

Langkah selanjutnya