Halaman ini menunjukkan contoh konfigurasi resource Google Cloud yang tidak valid atau tidak konsisten yang mungkin Anda alami saat memecahkan masalah jaringan dengan Uji Konektivitas.
Untuk petunjuk cara menjalankan pengujian, lihat Membuat dan menjalankan Uji Konektivitas.
Untuk deskripsi pengujian ke dan dari jenis sumber dan tujuan jaringan umum, lihat Kasus penggunaan umum.
Mendeteksi konfigurasi yang tidak valid
Ada berbagai jenis konfigurasi yang tidak valid; yaitu, konfigurasi yang tidak benar atau yang telah diperbarui dan tidak lagi valid.
Salah satu contohnya adalah instance virtual machine (VM) yang telah dikonfigurasi sebagai gateway NAT, tetapi telah dihapus atau dimigrasikan. Dalam hal ini, rute ke instance VM masih ada.
Dalam diagram berikut, VM1 di Network 1 akan dapat mengakses data di
VM2, VM3, dan VM4 di Network 2 melalui instance VM bernama nat_vm_1.
Namun, nat_vm_1 tidak ada lagi karena telah bermigrasi ke VM baru,
nat_vm_2.
Rute yang dikonfigurasi dari VM1 ke tiga instance VM lainnya masih
mengarah ke nat_vm_1 sebagai hop berikutnya. Namun, karena nat_vm_1 sudah tidak ada lagi dan tidak ada rute ke nat_vm_2, VM1 tidak dapat berkomunikasi dengan instance VM lainnya.
Uji Konektivitas yang dijalankan dari VM1 hingga VM2 menunjukkan bahwa traffic antara VM1 dan instance VM lainnya telah berkurang karena next hop yang tidak valid untuk rute ke VM lain.
Sebaliknya, dalam kasus penggunaan untuk
konfigurasi yang tidak konsisten,
VM3 tidak memiliki tag jaringan, sehingga konfigurasi load balancer
tidak konsisten
di seluruh backend load balancer. Namun, konfigurasi untuk VM3 itu sendiri valid karena mengonfigurasi instance VM tidak memerlukan tag.
Mendeteksi konfigurasi yang tidak konsisten
Anda juga dapat menggunakan Uji Konektivitas untuk secara rutin memvalidasi konfigurasi yang tidak konsisten. Konfigurasi ini mungkin tidak menyebabkan masalah konektivitas saat ini, tetapi mungkin secara tidak sengaja mengurangi redundansi jaringan atau menyebabkan masalah performa pada masa mendatang.
Load balancer dikonfigurasi untuk mengirim traffic ke alamat IP eksternal
35.184.176.28. Traffic ke alamat tersebut didistribusikan ke tiga
backend: VM1, VM2, dan VM3. Namun, karena tag jaringan yang hilang pada VM3, aturan firewall Virtual Private Cloud (VPC) mengizinkan traffic dari rentang IP eksternal ke VM1 dan VM2, tetapi menolak traffic tersebut ke VM3.
Pelacakan berikut dari rentang sumber yang diizinkan yang dikonfigurasi untuk load balancing ke alamat IP eksternal tujuan load balancer menunjukkan konfigurasi dan inkonsistensi yang diinginkan. VM1 dan VM2 dapat dijangkau,
tetapi
VM3 tidak dapat dijangkau. Hanya dua backend yang dapat dijangkau karena VM3 gagal
menggagalkan health check.
