All Products
Search

This Product

    Cloud Enterprise Network:Perutean berbasis kebijakan

    Document Center

    Cloud Enterprise Network:Perutean berbasis kebijakan

    Last Updated:Aug 29, 2026
    Penting

    Fitur ini sedang dalam masa pratinjau undangan saja. Hubungi manajer akun Alibaba Cloud Anda untuk meminta akses.

    Perutean berbasis kebijakan (PBR) memungkinkan Anda menentukan jalur penerusan spesifik untuk lalu lintas yang masuk ke attachment berdasarkan kriteria seperti IP sumber, IP tujuan, protokol, port, atau DSCP. Jika sebuah paket sesuai dengan suatu aturan, paket tersebut akan diteruskan ke tabel rute yang ditentukan dalam aturan tersebut.

    Kasus penggunaan

    Gunakan PBR ketika lalu lintas menuju tujuan yang sama perlu mengikuti jalur berbeda berdasarkan sumbernya, atau ketika Anda perlu mengalihkan lalu lintas tertentu untuk inspeksi keamanan atau kepatuhan.

    Skenario A: Rute traffic berdasarkan IP sumber

    • Prasyarat: Dua subnet dalam vSwitch yang sama harus mengirim lalu lintas ke IDC tujuan yang sama di 10.1.0.0/16 tetapi melalui Virtual Border Router (VBR) yang berbeda: VBR-A dan VBR-B.

    • Konfigurasi: Buat dua aturan PBR. Setiap aturan mencocokkan CIDR sumber dari satu subnet dan mengarahkan lalu lintasnya ke tabel rute yang terkait dengan VBR yang sesuai.

    • Tingkat lanjut: Saat menggunakan ECMP melalui koneksi privat ganda, gunakan atribut AsPathPrepend dalam kebijakan rute Cloud Enterprise Network (CEN) (RouteMap) untuk memastikan jalur balik simetris.

    Skenario B: Jalur aktif-standby tingkat subnet

    • Prasyarat: Satu VPC berisi dua subnet. Dua koneksi privat, A dan B, terhubung ke Transit Router (TR). Subnet A harus menggunakan koneksi privat A sebagai jalur utama dan B sebagai cadangan, sedangkan Subnet B harus menggunakan B sebagai jalur utama dan A sebagai cadangan.

    • Konfigurasi: Buat dua tabel rute, vtb-a-primary dan vtb-b-primary. Di setiap tabel rute, gunakan RouteMap untuk menurunkan prioritas rute yang mengarah ke VBR lawan. Lalu, gunakan PBR untuk mengarahkan lalu lintas dari masing-masing subnet ke tabel rute utamanya.

    • Tingkat lanjut: Jika tautan utama gagal, BGP secara otomatis konvergen ke jalur cadangan. Lalu lintas balik simetris bergantung pada RouteMap dua arah.

    Skenario C: Penyisipan layanan untuk traffic antar-VPC

    • Prasyarat: Cloud Firewall terhubung ke TR sebagai attachment dan memiliki tabel rute khusus sendiri, vtb-firewall.

    • Konfigurasi: Pada attachment untuk VPC sumber, bind tabel rute kebijakan. Buat aturan dengan kondisi pencocokan SourceCidr=10.0.1.0/24, DestinationCidr=10.0.0.0/8 dan tetapkan target ke vtb-firewall. Lalu lintas yang tidak sesuai dengan aturan ini mengikuti tabel rute default.

    • Catatan: Karena firewall bersifat stateful, lalu lintas balik juga harus melewatinya. Anda dapat mencapai hal ini dengan mengikat tabel rute kebijakan serupa ke attachment peer atau dengan mengasosiasikan attachment peer dengan tabel rute yang mengarahkan lalu lintas melalui firewall.

    Skenario D: Isolasi jalur untuk beberapa penyewa

    • Prasyarat: Beberapa penyewa berbagi VPC dan vSwitch yang sama. Setiap penyewa harus mengakses IDC-nya sendiri melalui terowongan IPsec khusus.

    • Konfigurasi: Asosiasikan attachment IPsec setiap penyewa dengan tabel rute terpisah. Gunakan PBR untuk memetakan lalu lintas dari segmen jaringan sumber masing-masing penyewa ke tabel rute yang sesuai.

    Skenario E: Egress zonal untuk arsitektur aktif-aktif

    • Prasyarat: Subnet di zona ketersediaan (AZ) berbeda dan titik egress koneksi privat lokalnya dikonfigurasi sebagai attachment terpisah. Misalnya, 10.1.1.0/24 → att-vbr-az1 dan 10.1.2.0/24 → att-vbr-az2.

    • Konfigurasi: Tetapkan tabel rute terpisah untuk setiap titik egress AZ. Gunakan PBR untuk memetakan lalu lintas dari subnet masing-masing AZ ke tabel rute egress yang sesuai. Hal ini mencegah ECMP melakukan load balancing lalu lintas lintas AZ berbeda.

    • Tingkat lanjut: Untuk failover, Anda dapat mengonfigurasi sebelumnya rute fallback lintas-AZ dalam tabel rute cadangan. Ini menjaga ketersediaan layanan selama gangguan, meskipun dengan potensi penurunan performa.

    Skenario F: Saluran khusus untuk audit kepatuhan

    • Prasyarat: Lalu lintas keluar dari subnet DMZ 10.2.0.0/24 harus dirutekan melalui saluran audit. Perangkat audit terhubung sebagai attachment dan diasosiasikan dengan tabel rute vtb-audit.

    • Konfigurasi: Buat aturan PBR yang mencocokkan segmen jaringan sumber DMZ dan meneruskan lalu lintasnya ke tabel rute vtb-audit. Lalu lintas dari subnet lain tanpa kebijakan yang terikat atau aturan yang sesuai diteruskan sesuai tabel rute default.

    • Catatan: Audit inline mirip dengan stateful firewall dan memerlukan perutean simetris. Audit mirrored (out-of-band) memiliki dampak minimal pada lalu lintas balik.

    Skenario G: Pewarnaan traffic untuk rilis canary

    • Prasyarat: Subnet canary (10.3.100.0/24) dan subnet produksi berbagi VPC yang sama. Kluster backend untuk lingkungan canary terhubung melalui attachment terpisah, yang diasosiasikan dengan tabel rute vtb-gray.

    • Konfigurasi: Buat aturan PBR: SourceCidr=10.3.100.0/24 → vtb-gray. Atur prioritasnya lebih rendah daripada aturan keamanan atau kepatuhan apa pun.

    • Catatan: Lapisan jaringan hanya menentukan jalur lalu lintas. Logika tingkat aplikasi tetap harus mengelola peralihan versi dan rollback.

    Cara kerja

    Proses pencocokan traffic

    Saat lalu lintas masuk ke attachment, sistem mengevaluasinya terhadap tabel rute kebijakan sebelum mencari tabel rute untuk penerusan:

    1. Sebuah paket masuk ke attachment.

    2. Sistem memeriksa apakah tabel rute kebijakan terikat ke attachment tersebut.

      • Jika ya, lanjutkan ke langkah 3.

      • Jika tidak, lewati ke langkah 6.

    3. Sistem mengevaluasi paket terhadap aturan dalam tabel rute kebijakan berdasarkan urutan prioritas.

    4. Sistem memeriksa apakah paket tersebut sesuai dengan suatu aturan.

      • Jika ya, lanjutkan ke langkah 5.

      • Jika tidak, lewati ke langkah 6.

    5. Sistem mencari tujuan dalam tabel rute TR yang ditentukan oleh aturan lalu langsung ke langkah 7.

    6. Sistem mencari tujuan dalam tabel rute TR yang terikat oleh associated forwarding.

    7. Paket diteruskan ke lompatan berikutnya.

    Prinsip utama:

    • Evaluasi berbasis prioritas: Aturan dievaluasi berdasarkan urutan prioritas (nilai lebih kecil = prioritas lebih tinggi). Aturan pertama yang cocok diterapkan, dan evaluasi dihentikan.

    • Pencocokan dan penerusan terpisah: Tabel rute kebijakan hanya menentukan tabel rute mana yang akan digunakan. Tabel rute yang dipilih menyelesaikan lompatan berikutnya.

    • Kontrol ingress: Tabel rute kebijakan terikat ke attachment dan hanya memengaruhi lalu lintas yang masuk ke TR melalui attachment tersebut.

    Bidang pencocokan aturan

    Setiap aturan berisi bidang-bidang berikut:

    Field

    Wajib

    Deskripsi

    IP Address Type

    Tidak

    Nilai yang valid adalah IPv4 dan IPv6. Jika dibiarkan kosong, aturan akan cocok untuk keduanya.

    Source CIDR

    Tidak

    Segmen jaringan sumber dalam format CIDR.

    Destination CIDR

    Tidak

    Segmen jaringan tujuan dalam format CIDR.

    Protocol

    Tidak

    Nilai yang valid adalah ALL, TCP, UDP, dan ICMP.

    Source Port Range

    Tidak

    Contoh: 80/90 menentukan rentang dari 80 hingga 90. 80/80 menentukan satu port.

    Destination Port Range

    Tidak

    Sama seperti di atas.

    DSCP

    Tidak

    Matches the DSCP value already present in the IP packet when it arrives at TR. If not set, all DSCP values are matched. If DSCP is not explicitly set in the ECS operating system or on-premises data center, we recommend leaving this field blank.

    Priority

    Ya

    1 hingga 100. Nilai lebih rendah menunjukkan prioritas lebih tinggi.

    Forwarding Target Route Table

    Ya

    Tabel rute yang akan digunakan jika traffic sesuai dengan aturan.

    Gunakan perutean berbasis kebijakan

    Ikuti tiga langkah berikut:

    1. Buat Policy-Based Routing Table.

      Klik ID TR untuk membuka halaman detailnya. Beralih ke tab Policy-Based Routing Table dan klik Create Policy-Based Routing Table.

    2. Tambahkan Policy-Based Routes.

      1. Pada kolom Actions untuk tabel rute kebijakan yang baru saja Anda buat, klik View Rules.

      2. Pada panel Policy-Based Routing Table Details, pada tab Policy-Based Routes, klik Add Policy Routing Rule.

      3. Pada kotak dialog Add Policy Routing Rule, konfigurasikan pengaturan berikut:

        • Match Condition: Konfigurasikan seperti yang tercantum di Rule matching fields.

        • Priority: 1 hingga 100. Nilai lebih rendah menunjukkan prioritas lebih tinggi.

        • Forwarding Target Route Table: Tabel rute yang akan digunakan jika lalu lintas sesuai dengan aturan.

      Anda dapat menambahkan beberapa aturan ke dalam satu tabel.

    3. Ikat Policy-Based Routing Table ke Network Instances:.

      1. Pada kolom Actions untuk tabel rute kebijakan, klik Manage.

      2. Pada panel Policy-Based Routing Table Details, pada tab Associate Network Instance Connection, selesaikan pengikatan.

    Setelah Anda mengikat tabel tersebut, sistem pertama-tama mengevaluasi lalu lintas yang masuk ke attachment terhadap Policy-Based Routes:

    • Jika lalu lintas sesuai dengan suatu aturan, sistem meneruskannya berdasarkan tabel rute target yang ditentukan.

    • Jika lalu lintas tidak sesuai dengan aturan apa pun, sistem meneruskannya berdasarkan tabel rute yang dikonfigurasi untuk associated forwarding.

    Kelola perutean berbasis kebijakan

    • Lepaskan ikatan tabel rute kebijakan: Pada kolom Manage untuk tabel rute kebijakan yang diinginkan, klik Manage. Lalu, pada kolom Actions untuk ikatan yang ingin dihapus, klik Disassociate.

    • Hapus tabel rute kebijakan: Sebelum Anda dapat menghapus tabel rute kebijakan, Anda harus melepaskan ikatannya dari semua attachment. Lalu, pada kolom Actions untuk tabel rute kebijakan target, klik Delete.

    • Edit aturan perutean berbasis kebijakan: Di pojok kanan atas aturan target, klik Edit.

      Anda hanya dapat mengedit nama dan deskripsi. Untuk mengubah bidang lain, seperti Match Condition, Priority, atau Forwarding Target Route Table, Anda harus menghapus aturan tersebut dan membuat yang baru.

    • Hapus aturan perutean berbasis kebijakan: Di pojok kanan atas aturan target, klik Delete.

    Informasi lebih lanjut

    Kuota dan batasan

    Kuota:

    Item

    Default

    Dapat ditingkatkan

    Jumlah tabel rute kebijakan per instans TR (PolicyTableNumberPerTransitRouter)

    20

    Ya. Hubungi manajer akun Anda.

    Total jumlah aturan perutean berbasis kebijakan per instans TR (PolicyBasedRoutePerTransitRouter)

    100

    Ya. Hubungi manajer akun Anda.

    Jumlah tabel rute kebijakan yang dapat diikat ke satu attachment (AttachmentAssociatedPbrPolicy)

    1

    Tidak

    Metrik pemantauan

    Metrik CloudMonitor berikut menggunakan dimensi PolicyBasedRouteId:

    Metric

    Unit

    Deskripsi

    PolicyBasedRouteHitCount

    packets

    Jumlah paket yang sesuai dengan aturan.

    PolicyBasedRouteHitBandwidth

    bps

    Bandwidth rata-rata traffic yang sesuai dengan aturan.

    PolicyBasedRouteHitTraffic

    Gbytes

    Total volume traffic yang sesuai dengan aturan.

    FAQ

    Mengapa aturan saya tidak berlaku?

    Periksa hal-hal berikut secara berurutan:

    ① Verifikasi bahwa tabel rute kebijakan terikat ke attachment ingress. Anda dapat memeriksanya di tab Intra-Region Connections pada halaman detail TR, di kolom Associate with Route Table untuk attachment target.

    ② Pastikan aturan dikonfigurasi dengan benar dan lalu lintas aktif sesuai dengan kondisinya.

    ③ Periksa apakah aturan dengan prioritas lebih tinggi (nilai prioritas lebih kecil) telah mencocokkan lalu lintas terlebih dahulu.

    ④ Periksa arah lalu lintas. Perutean berbasis kebijakan hanya berlaku untuk lalu lintas yang masuk ke TR. Anda dapat menggunakan metrik pemantauan PolicyBasedRouteHitCount di CloudMonitor untuk memverifikasi apakah paket sesuai dengan aturan.