Hãy tính toán những gì chúng ta đang giải quyết ở đây. CAR về cơ bản là phiên bản cũ hơn của chính sách IOS, vì vậy tất cả các khái niệm này áp dụng cho cả hai.
Committed Information Rate (CIR) = 5,000,000 (5Mbps)
Burst Commit Bucket (Bc) = 937,500
Burst Excess Bucket (Be) = 1,875,000
Time Interval (Tc) = Bc / CIR = 0.1875 s = 187.5 ms
Tốc độ chúng tôi muốn hạn chế lưu lượng là 5Mb / giây. Nhóm Commit là 937.500 byte. Nhóm Burst là 1.875.000 byte. Và các thùng được nạp lại sau mỗi 187,5 ms.
Như bạn đã đề cập, IOS sử dụng cơ chế xô để hạn chế lưu lượng có thể vượt qua. Nó không làm giảm lưu lượng đến X% băng thông giao diện trong một khoảng thời gian tùy ý! Thay vào đó, nó cho phép truy cập đầy đủ vào băng thông của giao diện miễn là bạn có mã thông báo để trả tiền cho nó.
Ngoài ra, vì đây là chính sách, RED / WRED không được chơi. RED chỉ xảy ra khi có hàng đợi để quản lý. Không có bộ đệm / xếp hàng trong việc kiểm soát, chỉ trong việc định hình.
Trước tiên, hãy đối phó với Nhóm Cam kết (Bc). Giả sử rằng bây giờ không có Xô dư (Be).
* Chỉ cam kết xô (Máy đánh bóng hai màu) *
Đây là một chính sách rất nghiêm ngặt sẽ chỉ cho phép bạn gửi chính xác trong CIR; không nổ ở trên. Chỉ có một thùng, Bc. Có hai "màu" cho giao thông, tuân thủ và vượt quá .
Thời gian = 0 ms - Nhóm bắt đầu đầy, với 937.500 byte mã thông báo trong đó. Giả sử bạn gửi 7.500 byte trên giao diện. Bây giờ, iOS giảm số nhóm theo 7.500 byte và nhóm hiện có 930.000 byte giá trị mã thông báo trong đó. Lưu lượng được gửi được coi là "tuân thủ" và áp dụng "hành động tuân thủ" cho nó.
Thời gian = 187,5 ms - Chúng tôi nhấn Tc ngay bây giờ và nạp lại thùng Bc. 937.500 byte giá trị mã thông báo được thêm vào. Bất kỳ mã thông báo bổ sung nào tràn ra và bị mất.
Thời gian = 190 ms - Nhóm cam kết có 937.500 mã thông báo trong đó. Chúng tôi nhận được 2.000.000 byte lưu lượng. 937.500 byte đầu tiên được chuyển tốt vì nhóm có mã thông báo cho nó. Lưu lượng truy cập còn lại được coi là "vượt quá" và được xử lý theo "hành động vượt quá". Remeber, không có bộ đệm trong việc kiểm soát (được gọi là định hình) - bạn có thể truyền, nhận xét và truyền hoặc thả.
Thời gian = 375 ms - Chúng tôi nhấn Tc một lần nữa và nhóm Bc được nạp lại với 937.500 mã thông báo.
* Cam kết với nhóm dư thừa (Máy đánh bóng ba màu) *
Bạn có thể tùy ý thêm một thùng thừa (Be). Điều này cho phép lưu lượng vượt quá nhóm Bc trên cơ sở tạm thời. CIR tổng thể nên giữ nguyên. Đây là một chính sách ba "màu": tuân thủ, vượt quá và vi phạm .
Thời gian = 0 ms - Cả hai nhóm (Bc và Be) bắt đầu đầy đủ. Bc có 937.500 mã thông báo, Be có 1.875.000 mã thông báo.
Thời gian = 50 ms - 2.000.000 byte lưu lượng đến. Bộ định tuyến trước tiên phân rã mã thông báo xô Bc. Nó làm giảm thùng Bc về không. 937.500 byte lưu lượng được bảo hiểm bởi Bc được coi là "tuân thủ" và có "hành động tuân thủ" được áp dụng cho nó.
Điều đó để lại 1.062.500 byte lưu lượng chưa có mã thông báo. Bây giờ bộ định tuyến nhúng vào nhóm Be và trừ đi 1.062.500 mã thông báo để trang trải phần còn lại của lưu lượng. Các byte này được coi là "vượt quá" và sẽ áp dụng "hành động vượt quá" cho nó. Trong ví dụ của bạn, lưu lượng sẽ bị giảm, nhưng bạn có thể nhận xét hoặc chỉ truyền nó.
Nếu bạn đang giữ điểm ở nhà, Bc hiện không có mã thông báo, Be có 812.500 mã thông báo.
Thời gian = 75 ms - Bây giờ, bộ định tuyến nhận thêm 1.200.000 byte lưu lượng. Các thùng Bc trống, vì vậy không có giúp đỡ ở đó. Nhóm Be có thể trợ giúp, do đó, nó bao phủ 812.500 byte lưu lượng truy cập đầu tiên với các mã thông báo của nó và hiện đang trống. Lưu lượng truy cập này được coi là "vượt quá" và sẽ áp dụng "hành động vượt quá" cho nó.
Bây giờ các thùng đã khô, nhưng vẫn còn 387.500 byte để xử lý. Lưu lượng truy cập này được coi là "vi phạm" và luôn bị loại bỏ với CAR (Bạn có thể thực hiện các thao tác khác với MQC và lệnh cảnh sát với "hành động vi phạm").
Thời gian = 187,5 ms - Bây giờ chúng tôi đến khoảng Tc đầu tiên, thời gian để đổ đầy xô của chúng tôi. Một điểm quan trọng là chỉ cómã thông báo giá trị Bc được nạp lại! Các thùng Bc được lấp đầy đầu tiên đến 937.500. Các thùng được nhắc nhở EMPTY.
Thời gian = 375 ms - Thật yên tĩnh và chúng tôi chuyển sang khoảng Tc tiếp theo. Giá trị mã thông báo Bc được thêm vào nhóm Bc. Vì nhóm Bc đã đầy, các mã thông báo dư thừa sẽ không bị mất - thay vào đó, chúng được "đổ" vào thùng Be. Bây giờ, thùng Bc đã đầy với 937.500 mã thông báo và thùng Be đã đầy một phần với 937.500 mã thông báo.
Thời gian = 562,5 ms - Yên tĩnh, và chúng tôi ở Tc tiếp theo. Mã thông báo giá trị Bc được thêm vào nhóm Bc, đã đầy. Tất cả đều tràn vào thùng Be (đã có 937.500 mã thông báo). The Be lấp đầy tất cả các cách lên tới 1.875.000 mã thông báo.
* Ghi chú cuối cùng *
Cấu hình của bạn không sử dụng thùng Be. Bạn đang giới hạn tỷ lệ / kiểm soát chính sách chỉ sử dụng nhóm Bc, có thể có tác dụng phụ ngoài ý muốn nếu bộ chỉnh sửa / máy ép gửi dữ liệu đến bạn không được định cấu hình giống hệt nhau và không đồng bộ hóa Tc-khôn ngoan.
CAR / giới hạn tỷ lệ là rất cũ và không dùng nữa. Cân nhắc chuyển sang MQC và QoS hiện đại để thực hiện điều này, vì nó sẽ cung cấp cho bạn thêm thông tin và tùy chọn.
Tôi hoàn toàn bỏ qua việc trì hoãn tuần tự hóa (thời gian cần để truyền dữ liệu trên đường truyền) ở trên và tôi chắc chắn rằng toán học không hoạt động trong một kịch bản thực tế. Nhưng các khái niệm là vững chắc bất kể số lượng chính xác được sử dụng.
* Ví dụ MQC *
policy-map PM-FA0/0-IN
class class-default
police cir 5000000 bc 937500 be 1875000
!
interface Fa0/0
service-policy input PM-FA0/0-IN
!
* Nguồn *