لب عملی: پیکربندی Low Latency Queuing (LLQ)

هدف لب

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

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

لب QoS پایه قبلی صف‌بندی اولویت سخت‌گیرانه را به‌تنهایی پیکربندی کرد، و لب قبلی CBWFQ را به‌تنهایی پیکربندی کرد. LLQ صرفاً ترکیب هر دو درون یک policy-map است — یک کلاس اولویت برای ترافیک حساس-به-تأخیر مانند صدا، در کنار کلاس‌های CBWFQ برای هر چیز دیگر — که استراتژی صف‌بندی واقعاً مستقر در اکثریت قریب‌به‌اتفاق شبکه‌های تولیدی واقعی را نمایندگی می‌کند.

توپولوژی لب

R1 ---- Gi0/1 (لینک 100 Mbps، همان سناریوی
               ازدحام لب CBWFQ قبلی، اکنون با
               ترافیک صوتی اضافه‌شده)

VOICE-TRAFFIC: اولویت سخت‌گیرانه، policed در 10 Mbps
CRITICAL-DATA: 40٪ تضمین‌شده
BULK-DATA: 20٪ تضمین‌شده
class-default: باقی‌مانده

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

یک class-map که DSCP EF (ترافیک صوتی) را تطبیق می‌دهد تعریف کن.

وظیفه ۲: پیکربندی سیاست LLQ که Priority و CBWFQ را ترکیب می‌کند

کلاس صوتی را با استفاده از دستور priority با یک سقف پهنای‌باند صریح، در کنار پیکربندی موجود CRITICAL-DATA، BULK-DATA، و class-default از لب قبلی اضافه کن.

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

policy-map به‌روزشده را روی اینترفیس ازدحامی اعمال کن.

وظیفه ۴: تولید ترافیک صوتی در کنار ازدحام داده موجود

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

وظیفه ۵: تأیید دریافت تأخیر حداقلی توسط صدا با وجود ازدحام

تأیید کن ترافیک صوتی تأخیر و drop تقریباً صفر تجربه می‌کند، در حالی که سایر کلاس‌ها همچنان تضمین‌های CBWFQ خودشان را حفظ می‌کنند.

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

R1(config)# class-map match-all VOICE-TRAFFIC
R1(config-cmap)# match dscp ef

R1(config)# policy-map CBWFQ-POLICY
R1(config-pmap)# class VOICE-TRAFFIC
R1(config-pmap-c)# priority 10000

-- دستور priority یک صف اولویت سخت‌گیرانه
-- می‌سازد که پیش از هر کلاس دیگر خدمت می‌گیرد،
-- اما با یک policer ضمنی که آن را در 10 Mbps
-- مشخص‌شده محدود می‌کند -- این policing چیزی
-- است که از گرسنه‌ماندن کامل CRITICAL-DATA و
-- BULK-DATA توسط صف اولویت جلوگیری می‌کند، چون
-- بدون یک سقف، یک حجم بدرفتار یا غرق‌کننده
-- ترافیک "صوتی" می‌توانست در غیر این صورت کل
-- لینک را مصرف کند

-- بقیه policy-map (CRITICAL-DATA، BULK-DATA،
-- class-default) بدون تغییر از لب CBWFQ قبلی
-- باقی می‌ماند

R1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output CBWFQ-POLICY
-- (از‌قبل از لب قبلی اعمال شده؛ تعریف
--  به‌روزشده policy-map به‌طور خودکار اعمال می‌شود)

TrafficGen> [8 Mbps ترافیک صوتی در کنار همان
             ترکیب ترافیک 50/40/30 Mbps
             CRITICAL/BULK/default از لب
             قبلی تولید می‌کند -- 128 Mbps
             ترکیب‌شده به‌سمت یک لینک 100 Mbps]

R1# show policy-map interface gigabitethernet0/1

  Service-policy output: CBWFQ-POLICY

    Class-map: VOICE-TRAFFIC
      Strict Priority
      Bandwidth 10000 (kbps) Burst 250000 (Bytes)
      (pkts matched/bytes matched) 42106/...
      (total drops) 0
-- صفر drop برای صدا، که تأیید می‌کند بلافاصله
-- پیش از هر کلاس دیگر صرف‌نظر از حالت ازدحام
-- خودشان خدمت می‌گیرد

    Class-map: CRITICAL-DATA
      Bandwidth 40% (40000 kbps)
      (queue depth/total drops/no-buffer drops) 4/145/0

    Class-map: BULK-DATA
      Bandwidth 20% (20000 kbps)
      (queue depth/total drops/no-buffer drops) 9/580/0
-- CRITICAL-DATA و BULK-DATA همچنان تقریباً
-- سهم تضمین‌شده‌شان از پهنای‌باند باقی‌مانده
-- پس از کنارگذاشته‌شدن 10 Mbps صدا اول را
-- دریافت می‌کنند -- هیچ‌کدام از تضمین‌ها به‌طور
-- معنادار با افزودن صدا به ترکیب مختل نشد

VoiceClient> [کیفیت تماس را اندازه‌گیری می‌کند]

Jitter: 2ms, Packet loss: 0%
-- کیفیت تماس صوتی با وجود اینکه اینترفیس
-- به‌طور قابل‌توجهی بیش‌اشتراک‌گذاری‌شده در کل
-- است عالی باقی می‌ماند

نکته کلیدی

LLQ یک مکانیزم جداگانه از صف‌بندی اولویت و CBWFQ نیست — صرفاً عمل استاندارد ترکیب هر دو درون یک policy-map واحد است، با استفاده از اولویت سخت‌گیرانه برای یک‌مشت نوع ترافیک واقعاً حساس-به-تأخیر و jitter (صدا، ویدیو) در حالی که از تضمین‌های پهنای‌باند CBWFQ برای هر چیز دیگری که نیاز به انصاف دارد اما می‌تواند مقداری تأخیر صف‌بندی را تحمل کند استفاده می‌کند؛ سقف پهنای‌باند اجباری روی کلاس اولویت چیزی است که این ترکیب را پایدار نگه می‌دارد، و تضمین می‌کند ترافیک حساس-به-تأخیر نمی‌تواند ناخواسته کل لینک را به هزینه تضمین‌های هر کلاس دیگر مصرف کند.