لب عملی: پیکربندی Class-Based Weighted Fair Queuing (CBWFQ)

هدف لب

پیکربندی CBWFQ با سه کلاس نام‌دار، هرکدام با یک درصد پهنای‌باند حداقل خاص تضمین‌شده، اعمال سیاست روی یک اینترفیس خروجی ازدحامی، و تأیید اینکه هر کلاس حداقل تخصیص پیکربندی‌شده‌اش را در طول ازدحام پایدار از همه کلاس‌ها هم‌زمان دریافت می‌کند.

هدف لب (چرا مهم است)

لب QoS قبلی صف‌بندی اولویت سخت‌گیرانه را به‌طور خاص برای صدا پیکربندی کرد، و لب‌های shaping/policing به محدودسازی نرخ پرداختند، اما هیچ‌کدام به نیاز رایج تضمین سهم پهنای‌باند حداقل در سراسر چند نوع ترافیک غیر-صوتی که برای همان لینک رقابت می‌کنند نپرداختند — CBWFQ این را با تخصیص یک تضمین پهنای‌باند حداقل به هر کلاس تعریف‌شده حل می‌کند.

توپولوژی لب

R1 ---- Gi0/1 (لینک 100 Mbps، ازدحامی توسط
               ترافیک هم‌زمان از هر سه کلاس)

کلاس‌های ترافیک:
CRITICAL-DATA (باید حداقل 40٪ بگیرد)
BULK-DATA (باید حداقل 20٪ بگیرد)
ترافیک DEFAULT (باقی‌مانده، class-default)

وظیفه ۱: ساخت Class-Map برای هر نوع ترافیک

class-map هایی که CRITICAL-DATA (با DSCP AF41) و BULK-DATA (با DSCP AF11) را تطبیق می‌دهند تعریف کن.

وظیفه ۲: پیکربندی Policy-Map در CBWFQ

تضمین‌های درصد پهنای‌باند برای هر کلاس، به‌علاوه مدیریت fair-queue برای class-default پیکربندی کن.

وظیفه ۳: اعمال سیاست خروجی

سیاست CBWFQ را روی اینترفیس ازدحامی اعمال کن.

وظیفه ۴: تولید ترافیک هم‌زمان از همه کلاس‌ها فراتر از ظرفیت لینک

ترافیک کافی از هر سه دسته ترکیب‌شده برای فراتررفتن از ظرفیت 100 Mbps لینک تولید کن.

وظیفه ۵: تأیید دریافت حداقل پهنای‌باند تضمین‌شده توسط هر کلاس

تأیید کن CRITICAL-DATA و BULK-DATA هرکدام حداقل سهم پیکربندی‌شده‌شان را در طول دوره ازدحام دریافت می‌کنند.

راه‌حل و تأیید

R1(config)# class-map match-all CRITICAL-DATA
R1(config-cmap)# match dscp af41
R1(config-cmap)# exit
R1(config)# class-map match-all BULK-DATA
R1(config-cmap)# match dscp af11

R1(config)# policy-map CBWFQ-POLICY
R1(config-pmap)# class CRITICAL-DATA
R1(config-pmap-c)# bandwidth percent 40
R1(config-pmap)# class BULK-DATA
R1(config-pmap-c)# bandwidth percent 20
R1(config-pmap)# class class-default
R1(config-pmap-c)# fair-queue

-- 40٪ + 20٪ = 60٪ صراحتاً رزرو شده، و 40٪ را
-- برای class-default و هر سربار ترافیک صفحه-
-- کنترل پروتکل باقی می‌گذارد -- CBWFQ به‌طور
-- پیش‌فرض هرگز اجازه نمی‌دهد کل رزروها از 75٪
-- پهنای‌باند اینترفیس فراتر رود، و در برابر
-- بیش‌اشتراک‌گذاری محافظت می‌کند

R1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output CBWFQ-POLICY

TrafficGen> [50 Mbps CRITICAL-DATA، 40 Mbps
             BULK-DATA، و 30 Mbps ترافیک
             پیش‌فرض علامت‌گذاری‌نشده تولید
             می‌کند -- 120 Mbps ترکیب‌شده
             به‌سمت یک لینک 100 Mbps، و ازدحام
             پایدار را تضمین می‌کند]

R1# show policy-map interface gigabitethernet0/1

  Service-policy output: CBWFQ-POLICY

    Class-map: CRITICAL-DATA
      Bandwidth 40% (40000 kbps)
      Queueing
      (queue depth/total drops/no-buffer drops) 3/128/0
      (pkts output/bytes output) 284213/...

    Class-map: BULK-DATA
      Bandwidth 20% (20000 kbps)
      Queueing
      (queue depth/total drops/no-buffer drops) 8/512/0
      (pkts output/bytes output) 142106/...

    Class-map: class-default
      Flow Based Fair Queueing
      (queue depth/total drops/no-buffer drops) 15/890/0
      (pkts output/bytes output) 71053/...
-- با وجود اینکه ترافیک بسیار بیشتری از آنچه
-- لینک می‌تواند حمل کند ارائه شد، throughput
-- واقعی CRITICAL-DATA حدود 40 Mbps تضمین‌شده‌اش
-- و BULK-DATA حدود 20 Mbps تضمین‌شده‌اش را
-- تقریب می‌زند -- هر دو سهم حداقلشان را حتی
-- تحت بیش‌اشتراک‌گذاری پایدار حفظ کردند، با
-- اضافی که به‌طور مناسب دور ریخته شد به‌جای
-- اینکه اجازه دهد تضمین‌ها گرسنه بمانند

R1# show policy-map interface gigabitethernet0/1 | include Bandwidth

Bandwidth 40% (40000 kbps)
Bandwidth 20% (20000 kbps)
-- تأیید می‌کند تضمین‌های پیکربندی‌شده در
-- سراسر دوره ازدحام فعال و اعمال‌شده باقی می‌مانند

نکته کلیدی

دستور bandwidth percent در CBWFQ یک حداقل تضمین‌شده برقرار می‌کند، نه یک حداکثر سخت — یک کلاس همچنان می‌تواند بیشتر از درصد پیکربندی‌شده‌اش دریافت کند اگر ظرفیت مازاد وجود داشته باشد، اما در طول ازدحام واقعی (همان‌طور که اینجا با ترافیک فراتر از ظرفیت کل لینک نشان داده شد)، هر کلاس در برابر گرسنه‌ماندن زیر تضمین پیکربندی‌شده‌اش محافظت می‌شود، که دقیقاً مسئله‌ای است که صف‌بندی FIFO ساده یا fair-queuing بدون‌وزن به‌تنهایی نمی‌تواند وقتی چند نوع ترافیک مهم برای همان لینک ازدحامی رقابت می‌کنند حل کند.