Seperti yang saya pahami, Cisco IOS CAR (Committed Access Rate) didasarkan pada algoritma bucket bocor (idenya persis sama dengan algoritma token bucket ) dan jumlah bit yang saya konfigurasikan sebagai laju rata-rata, adalah jumlah "air yang terus bocor ember ". Sebagai contoh di sini rata-rata tingkat batas input rate 5Mbps:
interface FastEthernet0/0
ip address 10.10.10.2 255.255.255.0
rate-limit input 5000000 937500 1875000 conform-action transmit exceed-action drop
Sekarang jika tingkat lalu lintas di bawah tingkat rata-rata, maka itu selalu sesuai. Apakah saya benar bahwa "burst normal" menentukan seberapa besar traffic burst dapat dilakukan sebelum tindakan berlebihan diterapkan? Jadi dalam kasus contoh di atas, jika ada laju lalu lintas konstan 5Mbps (625000 byte dalam bucket), maka saya dapat mengirim 7,5Mbps satu detik (menambahkan 312500 byte tambahan ke bucket) lalu lintas dan tidak ada sedikit pun yang dijatuhkan ? Dan jika byte dalam bucket berada di antara burst normal dan burst maksimum, maka byte dijatuhkan berdasarkan algoritma seperti RED hingga semua paket baru dijatuhkan jika burst maksimum juga penuh?
Jawaban:
Mari kita hitung apa yang kita hadapi di sini. CAR pada dasarnya adalah versi lama dari perpolisian iOS, jadi semua konsep ini berlaku untuk keduanya.
Tingkat kami ingin membatasi arus adalah 5Mbps. Bucket Komit adalah 937.500 byte. Burst Bucket adalah 1,875,000 byte. Dan ember diisi ulang setiap 187,5 ms.
Seperti yang Anda sebutkan, iOS menggunakan mekanisme bucket untuk membatasi jumlah lalu lintas yang dapat dilewati. Itu tidak memuluskan lalu lintas ke X% dari bandwidth antarmuka selama periode waktu yang sewenang-wenang! Sebagai gantinya, ini memungkinkan akses penuh ke bandwidth antarmuka selama Anda memiliki token untuk membayarnya.
Juga, karena ini adalah pemolisian, RED / WRED tidak bermain. RED hanya terjadi ketika ada antrian untuk dikelola. Tidak ada buffering / antrian dalam kepolisian, hanya dalam membentuk.
Mari kita berurusan dengan Commit Bucket (Bc) terlebih dahulu. Asumsikan bahwa tidak ada Bucket Kelebihan (Be) untuk saat ini.
* Commit Bucket Only (Dua-Warna Policer) *
Ini adalah polisi yang sangat ketat yang hanya akan membiarkan Anda mengirim dalam CIR dengan tepat; tidak ada ledakan di atas. Hanya ada satu ember, Bc. Ada dua "warna" untuk lalu lintas, menyesuaikan dan melebihi .
Waktu = 0 ms - Ember mulai penuh, dengan nilai token 937.500 byte di dalamnya. Katakanlah Anda mengirim 7.500 byte di seluruh antarmuka. Sekarang iOS mengurangi bucket sebesar 7.500 byte, dan bucket sekarang memiliki token senilai 930.000 byte di dalamnya. Lalu lintas yang dikirim dianggap "sesuai" dan menerapkan "tindakan sesuai" untuknya.
Waktu = 187,5 ms - Kami menekan Tc sekarang, dan mengisi ulang ember Bc. Token senilai 937.500 byte ditambahkan. Token tambahan apa pun tumpah dan hilang.
Waktu = 190 ms - Ember komit memiliki 937.500 token di dalamnya. Kami menerima 2.000.000 byte lalu lintas. 937.500 byte pertama ditransfer dengan baik karena ember memiliki token untuk itu. Lalu lintas yang tersisa dianggap "melebihi" dan diperlakukan sesuai dengan "melebihi tindakan". Ingat, tidak ada buffering dalam kepolisian (yang disebut membentuk) - Anda mengirim, berkomentar dan mengirimkan, atau menjatuhkan.
Waktu = 375 ms - Kami menekan Tc lagi, dan ember Bc diisi ulang dengan 937.500 token.
* Bucket Berkomitmen dengan Kelebihan Bucket (Policer Tiga Warna) *
Anda dapat menambahkan Bucket Kelebihan (Be) secara opsional. Ini memungkinkan lalu lintas untuk melebihi Bc bucket secara sementara. CIR keseluruhan harus tetap sama. Ini adalah tiga "polisi" warna: menyesuaikan, melampaui, dan melanggar .
Waktu = 0 ms - Kedua kotak (Bc dan Be) mulai penuh. Bc memiliki 937.500 token, Be memiliki 1.875.000 token.
Waktu = 50 ms - 2.000.000 byte lalu lintas tiba. Router pertama-tama mengurangi token bucket Bc. Ini mengurangi Bc bucket menjadi nol. 937.500 byte lalu lintas yang dicakup oleh Bc dianggap "sesuai" dan memiliki "tindakan sesuai" yang diterapkan padanya.
Itu meninggalkan 1.062.500 byte lalu lintas yang belum memiliki token. Sekarang router mencelupkan ke dalam ember Be, dan kurangi 1.062.500 token untuk menutupi sisa lalu lintas. Bytes ini dianggap "melebihi" dan akan memiliki "melebihi aksi" yang diterapkan padanya. Dalam contoh Anda, lalu lintas akan turun, tetapi Anda berpotensi berkomentar atau mengirimnya.
Jika Anda menyimpan skor di rumah, SM sekarang memiliki token nol, Jadilah memiliki 812.500 token.
Waktu = 75 ms - Sekarang, router menerima 1.200.000 byte lalu lintas. Bc bucket kosong, jadi tidak ada bantuan di sana. Be bucket dapat membantu, sehingga mencakup 812.500 byte pertama dari lalu lintas dengan tokennya, dan sekarang kosong. Lalu lintas ini dianggap "melebihi" dan akan memiliki "tindakan melebihi" yang diterapkan padanya.
Sekarang, ember sudah kering, tetapi masih ada 387.500 byte yang tersisa untuk ditangani. Lalu lintas ini dianggap "melanggar" dan selalu dijatuhkan dengan CAR (Anda dapat melakukan hal-hal lain dengan menggunakan MQC dan perintah polisi dengan "melanggar aksi").
Waktu = 187,5 ms - Sekarang kita tiba pada interval Tc pertama, saatnya mengisi ember kita. Poin kunci adalah bahwa hanyatoken senilai Bc yang diisi ulang! Bucket Bc diisi terlebih dahulu hingga 937.500. The Be bucket TETAP KOSONG.
Waktu = 375 ms - Sudah sepi, dan kami membuatnya ke interval Tc berikutnya. Token senilai Bc ditambahkan ke ember Bc. Karena ember Bc sudah penuh, token berlebih tidak hilang - mereka "tumpah" ke keranjang Be sebagai gantinya. Sekarang ember Bc penuh dengan 937.500 token dan ember Be sebagian penuh dengan 937.500 token.
Waktu = 562,5 ms - Diam, dan kami berada di Tc berikutnya. Token senilai Bc ditambahkan ke ember Bc, yang sudah penuh. Semuanya tumpah ke dalam ember Be (yang sudah memiliki 937.500 token). Be mengisi hingga 1.875.000 token.
* Catatan Akhir *
Konfigurasi Anda tidak menggunakan ember Be. Anda membatasi tingkat / pemolisian hanya menggunakan ember Bc, yang mungkin memiliki efek samping yang tidak diinginkan jika polisi / pembentuk mengirimkan data kepada Anda tidak dikonfigurasi secara identik dan tidak dalam sinkronisasi Tc-bijaksana.
CAR / rate-limit sudah sangat tua dan usang. Pertimbangkan beralih ke MQC dan QoS modern untuk menerapkan ini, karena akan memberi Anda lebih banyak informasi dan opsi.
Saya benar-benar mengabaikan penundaan serialisasi (waktu yang diperlukan untuk mengirimkan data pada saluran) di atas, dan saya cukup yakin matematika tidak bekerja dalam skenario nyata. Namun konsepnya solid terlepas dari angka pastinya yang digunakan.
* Contoh MQC *
* Sumber *
http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html
Materi Pelatihan INE CCIE
CCIE # 38955
sumber