QoS per tunnel tidak membatasi total uplink hub Anda

Kepercayaan itu terdengar seperti aritmetika: lima spoke yang masing-masing dibatasi 5 Mbit/s, jadi hub membawa paling banyak 25 Mbit/s. Paruh pertama benar dan kesimpulannya tidak. Kebijakan per tunnel diterapkan sekali per tunnel, bukan sekali per hub, dan uplink bersama yang dilalui kelima tunnel tidak pernah muncul dalam perhitungan itu. Kemacetan di uplink tetap persis seperti semula.

Dari mana kepercayaan itu berasal

Kebingungannya wajar, karena informasi grup NHRP memungkinkan satu definisi kebijakan berlaku untuk seluruh rangkaian spoke. Itu terbaca seperti anggaran bersama dalam berkas konfigurasi. Yang sebenarnya berarti adalah setiap spoke mendapat instansnya sendiri dari definisi itu.

Jadi 5 Mbit/s per spoke adalah plafon per tunnel, dan jumlah plafonnya sama dengan jumlah tunnel.

Apa yang dikendalikan satu instans kebijakan

Panduan Cisco tentang QoS per tunnel di DMVPN pada IOS XE menjelaskan kebijakan keluar hub yang dipilih melalui informasi grup NHRP dan diterapkan secara terpisah pada setiap spoke. Dua batas mengikuti kalimat itu, dan keduanya diabaikan. Laju itu milik satu spoke, bukan ember bersama, dan fitur ini mengatur lalu lintas dari hub ke spoke, bukan sebaliknya.

Rencanakan arah pengiriman spoke secara mandiri. Tidak ada apa pun dalam kebijakan keluar hub yang membatasi apa yang diunggah cabang.

Tempatkan batas agregat di titik kemacetan bersama

Agregat harus dibentuk di tempat agregat benar-benar bersaing: pada antarmuka fisik yang dipakai bersama semua tunnel. Cisco mendokumentasikan shaper class-default pada antarmuka fisik sebagai kebijakan fisik bersamaan yang didukung untuk fitur ini, yang merupakan pernyataan lebih sempit daripada hierarki apa pun yang dapat Anda ketik. Anggap kebijakan fisik kedua yang sewenang-wenang Anda buat tidak didukung sampai seseorang membuktikan sebaliknya.

Lalu putuskan apa yang terjadi ketika semua spoke sibuk bersamaan. Lalu lintas mana yang diterima, kelas mana yang diprioritaskan, dan antrean mana yang memiliki kontensi. Plafon per spoke tidak menjawab satu pun pertanyaan itu, karena setiap spoke dipertimbangkan sendiri.

Cocokkan satuan pembentukan dan akuntansi overhead dengan penyerahan sebenarnya. Overhead enkapsulasi yang Anda keluarkan dari perhitungan laju muncul sebagai tautan yang jenuh sebelum angka yang dikonfigurasi.

Penghitung berbohong dengan satu cara tertentu

Baca penghitung pada lapisan yang Anda bentuk. Panduan Cisco yang sama memperingatkan bahwa penghitung kebijakan antarmuka utama dapat tidak akurat dalam susunan ini. Itu catatan tentang penghitung, bukan bukti bahwa kelas cocok atau menjatuhkan. Pisahkan dari hasil aplikasi, yang satu-satunya hal yang dialami pengguna.

Menyalin contoh traffic-shape lama di samping peta kebijakan yang tidak terkait tidak membuktikan kedua laju mengendalikan paket yang sama.

Uji agregat, bukan hanya plafon

Mulai dengan satu spoke sibuk dan pastikan ia mencapai plafonnya. Lalu tawarkan lalu lintas dari semuanya sekaligus sesuai rencana yang disetujui, dan amati antarmuka fisik di samping angka per tunnel. Jika setiap spoke duduk di plafonnya sementara uplink penuh dan latensi naik, kebijakan per spoke bekerja persis seperti yang dirancang dan anggarannya tetap salah.

Perbaikannya pada titik itu adalah keputusan kapasitas atau penerimaan. Menyetel ulang angka per spoke hanya mengubah cabang mana yang mengeluh lebih dulu.