در یک شبکه شلوغ، همه ترافیک‌ها نیاز یکسانی ندارند. تأخیر در دانلود فایل معمولاً مسئله مهمی نیست، اما همین تأخیر در تماس VoIP یا Video Conference می‌تواند کیفیت ارتباط را کاهش دهد. اینجاست که QoS در سوئیچ سیسکو اهمیت پیدا می‌کند. در این مقاله با مفهوم QoS ،Classification ،Marking ،Queueing، Scheduling ،DSCP و CoS آشنا می‌شویم و سپس در سناریوی عملی، روش مدیریت Voice ،Video و Data، Configuration، بررسی عملکرد و عیب‌یابی QoS را در سوئیچ سیسکو به‌صورت کاربردی و دقیق بررسی می‌کنیم.
QoS چیست؟
QoS یا Quality of Service مجموعه‌ای از مکانیزم‌های مدیریت ترافیک شبکه است که به تجهیزات شبکه اجازه می‌دهد بسته‌های Voice، Video و Data را شناسایی کرده و هنگام Congestion، براساس اهمیت و حساسیت آنها اولویت متفاوتی اعمال کنند.
به زبان ساده، QoS مشخص می‌کند وقتی چند نوع Traffic هم‌زمان برای استفاده از منابع محدود شبکه رقابت می‌کنند، کدام Traffic باید سرویس مناسب‌تری دریافت کند. این موضوع در شبکه‌هایی که VoIP، Video Conference و Data روی یک زیرساخت مشترک قرار دارند اهمیت بیشتری پیدا می‌کند.
نکته مهم این است که QoS باعث افزایش Bandwidth نمی‌شود. اگر ظرفیت یک لینک مشخص باشد، فعال‌کردن QoS ظرفیت فیزیکی آن را افزایش نمی‌دهد. QoS فقط نحوه استفاده از منابع موجود را مدیریت می‌کند تا هنگام Congestion، Trafficهای حساس‌تر مانند Voice و Video بتوانند سرویس مناسب‌تری دریافت کنند.
به همین دلیل، ارزش QoS زمانی بیشتر مشخص می‌شود که شبکه با Congestion یا Contention مواجه باشد و چند Traffic Class برای منابع یکسان رقابت کنند.
چرا QoS در شبکه اهمیت دارد؟
همه Applicationها به شرایط شبکه واکنش یکسانی ندارند. Voice به‌طور ویژه به Delay، Jitter و Packet Loss حساس است؛ بنابراین حتی اختلال‌های کوچک هم می‌توانند کیفیت تماس را کاهش دهند. Video Conference علاوه بر Delay و Jitter، به Bandwidth بیشتری نیاز دارد و در زمان Congestion می‌تواند به‌سرعت تحت تأثیر قرار بگیرد. در مقابل، بسیاری از Data Trafficها مانند دانلود فایل یا Backup، تأخیر بیشتری را تحمل می‌کنند.
فرض کنید یک کاربر هم‌زمان با یک تماس VoIP، در حال دانلود یک فایل چند گیگابایتی باشد. اگر ظرفیت Uplink محدود شود، هر دو Traffic برای منابع یکسان رقابت می‌کنند. بدون QoS، این ترافیک‌ها ممکن است رفتار مشابهی داشته باشند؛ اما با یک QoS Policy مناسب می‌توان Voice را در اولویت بالاتری قرار داد، برای Video سرویس مناسب تعریف کرد و Data را با Best Effort یا Policy مشخص مدیریت کرد.
QoS در سوئیچ سیسکو چگونه کار می‌کند؟
عملکرد QoS را می‌توان به یک فرایند چندمرحله‌ای تقسیم کرد. ابتدا Traffic شناسایی می‌شود، سپس در صورت نیاز Marking روی آن انجام می‌شود و بعد بسته براساس Class خود در Queue مناسب قرار می‌گیرد. در مرحله بعد، Scheduler مشخص می‌کند هر Queue با چه ترتیب و سهمی سرویس بگیرد. در برخی سناریوها نیز برای کنترل نرخ Traffic از Policing یا Shaping استفاده می‌شود.
Classification چیست؟
Classification یعنی شناسایی Traffic و مشخص‌کردن اینکه هر بسته به کدام Traffic Class تعلق دارد.
سوئیچ می‌تواند براساس معیارهایی مانند Source IP، Destination IP، TCP یا UDP Port، ACL، VLAN، DSCP و CoS Traffic را طبقه‌بندی کند. برای مثال، اگر Voice با DSCP مشخصی وارد سوئیچ شود، می‌توان آن را به یک Class مخصوص Voice منتقل کرد.
Classification در واقع پاسخ این سؤال است که «این Traffic چیست و باید با کدام Policy مدیریت شود؟»
Marking چیست؟
Marking یعنی ثبت سطح سرویس مورد انتظار روی بسته تا تجهیزات بعدی نیز بتوانند آن را شناسایی و مدیریت کنند.
یکی از مهم‌ترین روش‌های Marking، استفاده از DSCP در IP Header است. برای مثال، می‌توان Voice را با EF علامت‌گذاری کرد تا تجهیزات بعدی بتوانند آن را به‌عنوان Traffic حساس به Delay و Jitter تشخیص دهند.
Queueing چیست؟
هنگامی که خروجی یک Interface با Congestion مواجه شود، بسته‌ها در Queueهای مختلف قرار می‌گیرند. QoS مشخص می‌کند هر Traffic Class در کدام Queue قرار بگیرد و چه سطحی از سرویس دریافت کند.
Scheduling چیست؟
Scheduling مشخص می‌کند بسته‌های موجود در Queueهای مختلف با چه ترتیب و سهمی ارسال شوند. در این مرحله، Priority Queue می‌تواند برای Traffic حساس مانند Voice سرویس سریع‌تری فراهم کند، اما نباید آن‌قدر گسترده باشد که سایر Queueها دچار Starvation شوند.
در کنار این مراحل، Policing و Shaping نیز می‌توانند برای کنترل نرخ Traffic مورد استفاده قرار گیرند.
DSCP چیست و چه ارتباطی با QoS دارد؟
DSCP یا Differentiated Services Code Point مقداری ۶ بیتی در IP Header است که برای مشخص‌کردن رفتار مورد انتظار شبکه نسبت به بسته استفاده می‌شود. تجهیزات شبکه می‌توانند با استفاده از DSCP، Traffic را شناسایی کنند و آن را در Class و Queue مناسب قرار دهند.
به بیان ساده، DSCP یک برچسب برای Traffic است. این برچسب به تجهیزات شبکه کمک می‌کند بفهمند یک بسته چه نوع سرویسی نیاز دارد. برای مثال، Voice معمولاً به Delay و Jitter حساس است و می‌تواند با یک DSCP مشخص علامت‌گذاری شود تا در زمان Congestion، Policy مناسب روی آن اعمال شود.
در طراحی‌های رایج Cisco، چند DSCP برای Trafficهای مشخص بیشتر استفاده می‌شوند:
| نوع Traffic | DSCP متداول | مقدار Decimal |
|---|---|---|
| Voice RTP | EF | 46 |
| Call Signaling | CS3 | 24 |
| Video Conference | AF41 | 34 |
| Best Effort Data | BE | 0 |
این مقادیر را باید به‌عنوان Baseline رایج در نظر گرفت، نه یک قانون ثابت برای تمام شبکه‌ها. انتخاب نهایی DSCP باید براساس نوع Application، معماری شبکه و QoS Policy سازمان انجام شود.
DSCP EF چیست؟
EF یا Expedited Forwarding معمولاً برای Trafficهای بسیار حساس به Delay و Jitter مانند Voice استفاده می‌شود و مقدار Decimal آن 46 است.
در بسیاری از طراحی‌های VoIP، Voice Bearer یا RTP با EF علامت‌گذاری می‌شود. به همین دلیل می‌توان Traffic دارای DSCP EF را در یک Voice Class قرار داد و در زمان Congestion برای آن Priority Service در نظر گرفت.
AF41 چیست؟
AF41 یکی از DSCPهای رایج برای Interactive Video و Video Conference است و مقدار Decimal آن 34 است.
Video مانند Voice به Delay و Jitter حساس است، اما معمولاً Bandwidth بیشتری مصرف می‌کند. به همین دلیل Video می‌تواند در یک Class جداگانه قرار بگیرد تا در زمان Congestion سرویس مناسبی دریافت کند، بدون اینکه الزاماً همان رفتار Priority Voice را داشته باشد.
محصول پیشنهادی جهت خرید سوئیچ سیسکو
Best Effort چیست؟
Best Effort به این معناست که برای Traffic موردنظر، QoS Policy ویژه یا تضمین خاصی تعریف نشده است.
Best Effort به معنی «بدون اهمیت» نیست. ممکن است بخش بزرگی از Traffic شبکه در این دسته قرار بگیرد و بدون مشکل کار کند، مخصوصاً زمانی که Congestion وجود ندارد. مقدار متداول DSCP برای این Traffic برابر 0 یا BE است.
نکته مهم این است که DSCP به‌تنهایی مشخص نمی‌کند یک بسته دقیقاً چه مقدار Bandwidth یا چه Queueای دریافت کند. این موضوع به QoS Policy و نحوه پیاده‌سازی QoS روی تجهیزات شبکه بستگی دارد.
تفاوت DSCP و CoS چیست؟
DSCP و CoS هر دو برای مشخص‌کردن نحوه برخورد شبکه با Traffic استفاده می‌شوند، اما DSCP در Layer 3 و CoS در Layer 2 قرار دارد. DSCP داخل IP Header استفاده می‌شود، در حالی که CoS به 802.1p و VLAN Tag در فریم‌های Ethernet مربوط است.
DSCP
DSCP یا Differentiated Services Code Point در Layer 3 قرار دارد و داخل IP Header استفاده می‌شود. این فیلد ۶ بیت دارد و می‌تواند مقادیری از ۰ تا ۶۳ داشته باشد. به همین دلیل DSCP در شبکه‌های IP، به‌خصوص در مسیرهای Routed، برای انتقال اطلاعات مربوط به QoS کاربرد زیادی دارد.
CoS
CoS یا Class of Service در Layer 2 استفاده می‌شود و با استاندارد IEEE 802.1p ارتباط دارد. این مقدار در VLAN Tag قرار می‌گیرد و سه بیت دارد؛ بنابراین محدوده آن از ۰ تا ۷ است.
| ویژگی | DSCP | CoS |
|---|---|---|
| لایه | Layer 3 | Layer 2 |
| محل قرارگیری | IP Header | 802.1Q Tag |
| تعداد بیت | 6 | 3 |
| محدوده مقدار | 0 تا 63 | 0 تا 7 |
| کاربرد اصلی | شبکه‌های IP و Routed | Ethernet و VLAN |
تفاوت این دو به این معنی نیست که باید یکی را همیشه جایگزین دیگری در نظر گرفت. در یک شبکه Cisco ممکن است Traffic در Layer 2 با CoS مدیریت شود و در ادامه، Marking آن به DSCP تبدیل شود تا در بخش‌های Routed شبکه نیز قابل استفاده باشد.
در نتیجه، DSCP بیشتر برای QoS در Layer 3 و شبکه‌های IP کاربرد دارد، در حالی که CoS بیشتر برای Traffic در Layer 2 و فریم‌های 802.1Q استفاده می‌شود.
Trust Boundary در QoS چیست؟
Trust Boundary نقطه‌ای در شبکه است که مشخص می‌کند از کدام دستگاه یا Interface می‌توان به QoS Marking یک Traffic اعتماد کرد.
این موضوع اهمیت زیادی دارد، چون هر دستگاهی نباید بتواند Traffic خودش را با یک DSCP با اولویت بالا علامت‌گذاری کند و انتظار داشته باشد شبکه همان Marking را بدون بررسی بپذیرد. برای مثال، یک Cisco IP Phone که تحت مدیریت سازمان قرار دارد می‌تواند منبع قابل اعتمادی برای Marking مربوط به Voice باشد، اما یک PC معمولی لزوماً نباید چنین اعتمادی داشته باشد.
یک سناریوی ساده را در نظر بگیرید:
Cisco IP Phone → Access Switch → Distribution → Core → WAN
↑
Trust Boundary
در این حالت، Access Switch می‌تواند تعیین کند که Marking دریافت‌شده از IP Phone معتبر است و در ادامه شبکه حفظ شود. در مقابل، Traffic یک PC می‌تواند قبل از ورود به بخش‌های بالاتر شبکه بررسی یا Remark شود.
به همین دلیل، در طراحی QoS باید مشخص شود:
از کجا به Marking اعتماد می‌کنیم؟
پاسخ این سؤال به نوع Endpoint، میزان کنترل سازمان روی تجهیزات و ساختار شبکه بستگی دارد. تعیین درست Trust Boundary باعث می‌شود Classification و Queueing بر اساس اطلاعات قابل اعتماد انجام شوند و یک دستگاه معمولی نتواند به‌سادگی خود را وارد Classهای دارای Priority بالا کند.
اولویت‌بندی VoIP، Video و Data چگونه انجام می‌شود؟
وقتی Voice، Video و Data روی یک لینک مشترک قرار می‌گیرند، نمی‌توان انتظار داشت همه Trafficها در زمان Congestion به یک شکل مدیریت شوند. هرکدام از این Trafficها نیاز متفاوتی دارند و باید براساس همان نیاز در Traffic Class مناسب قرار بگیرند.
فرض کنید IP Phone، یک سیستم Video Conference و یک PC به یک Cisco Access Switch متصل هستند و Uplink سوئیچ در ساعات کاری با Congestion مواجه می‌شود. در این شرایط می‌توان سه Class اصلی برای مدیریت Traffic تعریف کرد:
| Traffic | Classification | Marking | Queue |
|---|---|---|---|
| VoIP | RTP / DSCP | EF | Priority |
| Video Conference | Application / DSCP | AF41 | Multimedia |
| Business Data | ACL / Application | Policy سازمان | Business |
| General Data | سایر Traffic | BE | Default |
برای VoIP معمولاً Priority بالاتری در نظر گرفته می‌شود، زیرا Voice به Delay و Jitter حساس است. Video Conference نیز Traffic حساسی محسوب می‌شود، اما معمولاً در Class جداگانه‌ای قرار می‌گیرد تا بدون اختصاص Priority نامحدود، سرویس مناسب دریافت کند.
در مورد Data، Traffic عمومی می‌تواند با Best Effort منتقل شود. البته اگر Application سازمانی مهمی وجود داشته باشد، می‌توان برای آن Class و Policy جداگانه تعریف کرد.
Mapping دقیق Queueها، Scheduling و قابلیت‌های سخت‌افزاری به مدل Cisco Catalyst و نسخه Software بستگی دارد؛ بنابراین این ساختار باید به‌عنوان منطق طراحی در نظر گرفته شود، نه Configuration یکسان برای همه Switchها.
آموزش تنظیم QoS در سوئیچ Cisco
قبل از شروع Configuration باید یک نکته مهم را در نظر گرفت. Syntax و قابلیت‌های QoS در خانواده‌های مختلف Cisco Catalyst و نسخه‌های IOS/IOS XE یکسان نیستند. به همین دلیل Configuration زیر یک سناریوی آموزشی برای درک منطق پیاده‌سازی QoS است و قبل از استفاده در شبکه Production باید با مدل دقیق Switch، نسخه Software و معماری Queue همان دستگاه تطبیق داده شود.
در این سناریو فرض می‌کنیم Voice و Video دارای Marking مناسب هستند و می‌خواهیم آنها را از Data عمومی جدا کنیم.
مرحله اول؛ شناسایی Traffic
اولین مرحله، تعریف Traffic Class است. برای مثال می‌توان Voice و Video را براساس DSCP شناسایی کرد:
class-map match-any VOICE
match dscp ef
class-map match-any VIDEO
match dscp af41دستور class-map یک Class برای Traffic ایجاد می‌کند. در این مثال، هر بسته‌ای که DSCP آن برابر EF باشد وارد Class با نام VOICE می‌شود و Traffic دارای AF41 در Class VIDEO قرار می‌گیرد.
اگر Traffic موردنظر Marking مشخصی نداشته باشد، می‌توان برای Classification از روش‌هایی مانند ACL، IP، Port یا معیارهای دیگر استفاده کرد.
مرحله دوم؛ ساخت Policy Map
بعد از تعریف Classها، باید مشخص کنیم هر Class چه نوع سرویسی دریافت کند:
policy-map QOS-POLICY
class VOICE
priority percent 20
class VIDEO
bandwidth percent 30
class class-default
bandwidth percent 50در این نمونه، Class مربوط به Voice با priority در اولویت بالاتری قرار می‌گیرد. برای Video نیز بخشی از Bandwidth تضمین می‌شود و Traffic باقی‌مانده در class-default قرار می‌گیرد.
اعداد استفاده‌شده در این مثال فقط برای آموزش منطق Configuration هستند و نباید به‌عنوان مقدار ثابت برای همه شبکه‌ها در نظر گرفته شوند. مقدار مناسب باید براساس ظرفیت Interface، تعداد تماس‌های هم‌زمان، حجم Video و نیاز واقعی Applicationها تعیین شود.
مرحله سوم؛ اعمال Service Policy
پس از ساخت Policy، باید آن را به Interface موردنظر متصل کنیم:
interface GigabitEthernet1/0/24
service-policy output QOS-POLICYدستور service-policy Policy ساخته‌شده را روی Interface اعمال می‌کند. در این مثال، عبارت output نشان می‌دهد Policy در مسیر خروجی Interface اعمال شده است.
انتخاب Direction اهمیت زیادی دارد. اگر مسئله اصلی در خروجی Uplink و هنگام ارسال Traffic ایجاد شود، باید Policy در نقطه و جهتی اعمال شود که واقعاً Congestion رخ می‌دهد.
محصول پیشنهادی جهت خرید سوئیچ سیسکو
مرحله چهارم؛ بررسی Policy
بعد از اعمال Configuration باید بررسی کنیم Traffic واقعاً وارد Classهای موردنظر می‌شود:
show policy-map
show policy-map interface
show class-mapshow class-map برای بررسی Classهای تعریف‌شده استفاده می‌شود. show policy-map ساختار Policy را نمایش می‌دهد و show policy-map interface برای Verification اهمیت بیشتری دارد، زیرا Counterهای Traffic و Dropهای مربوط به Classها را روی Interface نشان می‌دهد.
اگر Switch مورد استفاده Queue Statistics ارائه دهد، این آمار نیز باید بررسی شود. به این ترتیب می‌توان فهمید آیا Classification درست انجام شده، Packetها وارد Queue مورد انتظار شده‌اند و آیا Congestion باعث افزایش Drop شده است یا خیر.
Policing و Shaping در QoS چه تفاوتی دارند؟
Policing و Shaping هر دو برای کنترل Rate ترافیک استفاده می‌شوند، اما روش برخورد آنها با Traffic خارج از محدوده یکسان نیست. Policing معمولاً Traffic را با یک Rate مشخص مقایسه می‌کند و بسته‌های خارج از Policy را می‌تواند Drop یا Remark کند. در مقابل، Shaping بخشی از Traffic را Buffer می‌کند تا بسته‌ها با Rate کنترل‌شده‌تری ارسال شوند.
Traffic Policing چیست؟
Policing برای اعمال یک سقف مشخص روی Traffic استفاده می‌شود. تجهیزات مقدار Traffic را با Rate تعیین‌شده مقایسه می‌کنند و اگر Traffic از محدوده مجاز بیشتر شود، بسته‌های اضافی ممکن است Drop یا Remark شوند.
بنابراین Policing معمولاً باعث می‌شود Traffic اضافی همان لحظه با یک تصمیم Policy مواجه شود و مانند Shaping برای ارسال بعدی در یک Queue Buffer نشود.
Traffic Shaping چیست؟
Shaping با استفاده از Buffer تلاش می‌کند Rate ارسال Traffic را هموارتر کند. اگر Traffic برای مدتی بیشتر از Rate تعیین‌شده باشد، بخشی از بسته‌ها در Buffer قرار می‌گیرند و بعداً با سرعت کنترل‌شده‌تری ارسال می‌شوند.
مزیت Shaping این است که به‌جای Drop سریع Traffic اضافی، می‌تواند ارسال آن را به‌تدریج انجام دهد. البته Buffer شدن بسته‌ها می‌تواند باعث افزایش Delay شود.
| ویژگی | Policing | Shaping |
|---|---|---|
| کنترل Rate | بله | بله |
| Buffer کردن Traffic | معمولاً خیر | بله |
| Drop Traffic اضافی | ممکن است | معمولاً کمتر |
| افزایش Delay | معمولاً کمتر | ممکن است |
| هدف اصلی | Enforcement | Smooth Traffic |
به‌طور خلاصه، Policing بیشتر برای اعمال یک محدودیت Rate و کنترل Traffic خارج از Policy استفاده می‌شود، در حالی که Shaping با Buffer کردن Traffic تلاش می‌کند نرخ ارسال را هموارتر کند. انتخاب بین این دو باید براساس محل Congestion و هدف QoS Policy انجام شود.
Priority Queue چیست و چرا برای VoIP مهم است؟
Priority Queue صفی است که در زمان Congestion نسبت به Queueهای معمولی سرویس با اولویت بالاتری دریافت می‌کند. این نوع Queue برای Trafficهایی مناسب است که به Delay و Jitter حساس هستند و Voice یکی از مهم‌ترین نمونه‌های آن محسوب می‌شود.
در یک شبکه VoIP، بسته‌های صوتی باید با تأخیر و نوسان زمانی کمی به مقصد برسند. به همین دلیل، Voice معمولاً در یک Priority Queue قرار می‌گیرد تا در زمان شلوغی لینک، زودتر از بسیاری از Trafficهای عادی سرویس بگیرد.
با این حال، Priority Queue نباید بدون محدودیت استفاده شود. اگر حجم زیادی از Traffic در این Queue قرار بگیرد، ممکن است منابع Interface بیش از حد در اختیار آن قرار بگیرد و سایر Queueها دچار Starvation شوند. در نتیجه، طراحی صحیح QoS فقط به «بالاترین اولویت دادن به Voice» محدود نمی‌شود؛ بلکه باید مقدار واقعی Voice، ظرفیت لینک و نیاز سایر Traffic Classها نیز در نظر گرفته شود.
بنابراین هدف Priority Queue این نیست که Voice همیشه تمام منابع را در اختیار داشته باشد، بلکه باید در شرایط Congestion، سرویس مناسب و قابل‌پیش‌بینی برای Traffic حساس فراهم شود.
سناریوی عملی QoS برای VoIP ،Video و Data
برای درک QoS، شبکه‌ای را در نظر بگیرید که یک IP Phone، یک سیستم Video Conference و چند PC به Cisco Access Switch متصل هستند. Uplink این Switch به Distribution یا Core متصل است و در ساعات کاری روی آن Congestion ایجاد می‌شود.
IP Phone ─┐
│
Video ────┼── Cisco Access Switch ── Uplink ── Distribution/Core
│
PC ───────┘
در این سناریو همه Trafficها با یک Policy مدیریت نمی‌شوند. ابتدا هر Traffic شناسایی و براساس نیاز آن، Marking و Queue مناسب انتخاب می‌شود.
Voice
Traffic تماس VoIP معمولاً شامل RTP است. در طراحی رایج، Voice با DSCP EF و مقدار 46 علامت‌گذاری می‌شود. دلیل این انتخاب، حساسیت Voice به Delay و Jitter است. هنگام Congestion، Voice می‌تواند در Priority Queue قرار بگیرد تا سرویس سریع‌تری نسبت به Traffic عادی دریافت کند. با این حال، Priority نباید بدون محدودیت باشد و ظرفیت لینک، تعداد تماس‌های هم‌زمان و Codec باید بررسی شوند.
Video Conference
Video Conference علاوه بر Delay و Jitter، Bandwidth بیشتری نسبت به Voice مصرف می‌کند. در بسیاری از طراحی‌های Cisco، Interactive Video با DSCP AF41 و مقدار 34 علامت‌گذاری می‌شود. این Traffic می‌تواند در Class جدا قرار بگیرد تا هنگام Congestion سرویس مناسب دریافت کند، بدون اینکه الزاماً Priority Queue Voice را اشغال کند.
Data
Traffic PCها می‌تواند با Best Effort مدیریت شود و در Default Queue قرار بگیرد. با این حال، Data الزاماً کم‌اهمیت نیست. برای Applicationهای Business-Critical مانند ERP می‌توان Class و QoS Policy جداگانه تعریف کرد.
نتیجه سناریو
وقتی Uplink آزاد است، تفاوت QoS کمتر دیده می‌شود. ارزش واقعی آن زمانی مشخص می‌شود که Voice، Video و Data برای منابع محدود رقابت کنند. در این شرایط Classification، Marking، Queueing و Scheduling تعیین می‌کنند هر Traffic چه سطحی از سرویس دریافت کند.
چگونه عملکرد QoS را بررسی کنیم؟
تنظیم QoS به‌تنهایی نشان نمی‌دهد Policy درست عمل می‌کند. بعد از Configuration باید بررسی شود که Traffic واقعاً در Class موردنظر قرار گرفته، Policy روی Interface صحیح اعمال شده و Queueها در زمان Congestion رفتار مورد انتظار را دارند.
موارد اصلی برای بررسی عبارت‌اند از:
- آیا Classها واقعاً Packet Match دارند؟
- آیا Traffic با DSCP مورد انتظار وارد سوئیچ می‌شود؟
- آیا Policy روی Interface درست و در Direction مناسب اعمال شده است؟
- آیا Packet Drop مشاهده می‌شود؟
- آیا Priority Queue فعال است؟
- آیا Queue Dropها در زمان Congestion افزایش پیدا می‌کنند؟
- آیا خود Interface واقعاً با Congestion مواجه است؟
یکی از مهم‌ترین دستورات برای بررسی وضعیت Policy عبارت است از:
show policy-map interfaceاین دستور Counterهای مربوط به Classهای مختلف را روی Interface نمایش می‌دهد و کمک می‌کند بفهمیم Traffic مورد انتظار واقعاً وارد Class شده است یا خیر. برای مثال، اگر Counter مربوط به VOICE صفر باشد، باید قبل از بررسی Queue به Classification، DSCP و Class Map برگردیم.
در کنار این دستور می‌توان از show class-map برای بررسی Classها و show policy-map برای مشاهده ساختار Policy استفاده کرد. در Platformهایی که Queue Statistics ارائه می‌کنند، بررسی Drop و وضعیت Queueها نیز برای تشخیص Congestion اهمیت دارد.
عیب‌یابی QoS در سوئیچ Cisco
فعال‌کردن QoS به‌تنهایی تضمین نمی‌کند Traffic مطابق انتظار مدیریت شود. اگر کیفیت Voice یا Video همچنان مناسب نیست، باید مسیر Traffic از Classification تا Queueing بررسی شود.
Policy اعمال شده اما QoS کار نمی‌کند
اول بررسی کنید Policy روی Interface صحیح اعمال شده باشد. سپس Direction را بررسی کنید؛ ممکن است Policy در Input قرار گرفته باشد، در حالی که Congestion اصلی در Output رخ می‌دهد.
بعد از آن، Class Map و Match Conditionها را بررسی کنید. اگر DSCP یا ACL با Traffic واقعی مطابقت نداشته باشد، Packet وارد Class موردنظر نمی‌شود. Trust Boundary نیز باید بررسی شود، زیرا ممکن است Marking در مسیر تغییر کرده باشد.
Voice وارد کلاس Voice نمی‌شود
برای بررسی این مشکل، ابتدا DSCP Traffic را بررسی کنید و سپس به Class Map برسید:
اگر Voice باید با EF شناسایی شود اما Counter کلاس VOICE افزایش پیدا نمی‌کند، باید بررسی کنید Packet واقعاً EF است، Class Map درست نوشته شده و Policy روی Interface مناسب اعمال شده است.
DSCP در مسیر تغییر می‌کند
DSCP ممکن است در طول مسیر توسط تجهیزات میانی Remark شود. بنابراین مسیر زیر را در نظر بگیرید:
اگر DSCP در Access صحیح است اما در Core یا WAN تغییر کرده، باید Policyهای QoS بین این نقاط بررسی شوند. هماهنگی Marking در کل مسیر اهمیت زیادی دارد.
QoS تنظیم شده ولی کیفیت تماس همچنان پایین است
QoS همه مشکلات شبکه را حل نمی‌کند. اگر بعد از Configuration هنوز کیفیت تماس مناسب نیست، موارد دیگری مانند Packet Loss، Interface Errors، CRC، Duplex، Oversubscription، ظرفیت WAN، Latency، Jitter، CPU و مشکلات Physical Layer نیز باید بررسی شوند.
در واقع اگر مشکل از کمبود شدید Bandwidth یا خرابی لینک باشد، QoS به‌تنهایی نمی‌تواند آن را برطرف کند.
اشتباهات رایج هنگام تنظیم QoS
- Trust کردن تمام DSCPها: هر Endpoint نباید بتواند Traffic خود را بدون بررسی وارد Priority Class کند.
- دادن Priority بیش از حد به Voice: اگر حجم زیادی از Traffic وارد Priority Queue شود، ممکن است سایر Queueها دچار Starvation شوند.
- تعریف Classهای بیش از حد: تعداد زیاد Classها Policy را پیچیده و Verification و Troubleshooting را دشوار می‌کند.
- اعمال Policy روی Interface اشتباه: QoS باید در نقطه‌ای اعمال شود که واقعاً Congestion رخ می‌دهد.
- بی‌توجهی به Congestion Point: قبل از طراحی Policy باید مشخص شود کدام Interface یا لینک با محدودیت منابع مواجه است.
- استفاده از Configuration مدل دیگر: Queue Architecture و Syntax در مدل‌های مختلف Cisco یکسان نیستند و Copy/Paste می‌تواند باعث Configuration نادرست شود.
- بررسی نکردن Counterها: وجود Configuration به معنی عملکرد صحیح آن نیست. Match و Drop باید با show policy-map interface بررسی شوند.
- استفاده از QoS برای جبران کمبود شدید Bandwidth: QoS ظرفیت فیزیکی لینک را افزایش نمی‌دهد و نمی‌تواند جایگزین Capacity Planning شود.
- ناهماهنگی QoS در مسیر شبکه: اگر Access، Distribution، Core و WAN Policyهای ناسازگار داشته باشند، Marking و رفتار Traffic ممکن است در مسیر تغییر کند.
آیا QoS باعث افزایش سرعت شبکه می‌شود؟
خیر. QoS سرعت فیزیکی یا Bandwidth لینک را افزایش نمی‌دهد. این فناوری فقط نحوه استفاده از منابع موجود را مدیریت می‌کند تا در زمان Congestion، Trafficهای حساس مانند Voice و Video سرویس مناسب‌تری دریافت کنند.
برای مثال، اگر یک لینک 100Mbps باشد، QoS آن را به 200Mbps تبدیل نمی‌کند. اما می‌تواند مشخص کند هنگام پرشدن لینک، Voice نسبت به یک Backup حجیم سرویس مناسب‌تری دریافت کند.
بنابراین QoS باید در کنار Capacity Planning، طراحی صحیح Network و مدیریت منابع استفاده شود.
چه زمانی به QoS نیاز داریم؟
QoS معمولاً زمانی اهمیت بیشتری پیدا می‌کند که چند نوع Traffic با نیازهای متفاوت روی یک زیرساخت مشترک قرار داشته باشند. برخی نمونه‌های رایج عبارت‌اند از:
- شبکه‌های VoIP
- Video Conference
- Microsoft Teams و Webex
- ارتباطات SIP
- لینک‌های WAN محدود
- شبکه‌های شعب سازمانی
- Backup یا Bulk Transfer سنگین
- Applicationهای Business-Critical
- شبکه‌هایی که در ساعات شلوغی با Latency یا Jitter مواجه می‌شوند
البته QoS همیشه به معنی یک Configuration پیچیده نیست. در یک شبکه ساده ممکن است Policy محدودی کافی باشد، در حالی که یک Enterprise Network با Applicationهای متعدد به طراحی دقیق‌تری نیاز دارد.
جمع‌بندی
QoS در سوئیچ Cisco زمانی ارزش خود را نشان می‌دهد که Trafficهای مختلف روی منابع محدود شبکه با یکدیگر رقابت کنند. Classification و Marking مشخص می‌کنند Traffic چیست و چه سطح سرویسی نیاز دارد؛ Queueing و Scheduling نحوه عبور آن را در زمان Congestion تعیین می‌کنند. در طراحی مناسب، Voice، Video و Data براساس نیاز Application مدیریت می‌شوند، نه بر اساس حدس. بنابراین، موفقیت QoS به Configuration صحیح، انتخاب درست Policy، توجه به نقطه Congestion و Verification مداوم وابسته است.
سوالات متداول
بهترین DSCP برای VoIP چیست؟
برای Voice Bearer یا RTP، مقدار DSCP EF برابر 46 یکی از رایج‌ترین Baselineهای مورد استفاده در طراحی QoS است. با این حال، مقدار نهایی باید با Application و QoS Policy سازمان هماهنگ باشد.
آیا QoS سرعت شبکه را افزایش می‌دهد؟
خیر. QoS Bandwidth یا سرعت فیزیکی لینک را افزایش نمی‌دهد. این فناوری منابع موجود را مدیریت می‌کند تا هنگام Congestion، Trafficهای حساس مانند Voice و Video نسبت به Trafficهای کم‌حساسیت سرویس مناسب‌تری دریافت کنند.
آیا تنظیمات QoS در تمام سوئیچ‌های Cisco یکسان است؟
خیر. Syntax، Queue Architecture و قابلیت‌های QoS به مدل Cisco Catalyst، سخت‌افزار و نسخه IOS/IOS XE بستگی دارند. بنابراین Configuration باید قبل از استفاده در Production با Platform موردنظر تطبیق داده شود.
انتخاب تجهیزات مناسب، تنها به خرید یک مدل خاص محدود نمی‌شود؛ بلکه به انتخاب کانفیگی متناسب با نیاز واقعی سازمان بستگی دارد. در ماهان شبکه ایرانیان، کارشناسان فنی با بررسی تعداد کاربران، نوع نرم‌افزارهای سازمانی، نیازهای پردازشی و بودجه شما، مناسب‌ترین مدل و کانفیگ را پیشنهاد می‌دهند. اگر برای خرید سرور اچ پی یا سایر تجهیزات شبکه جهت ارتقاء زیرساخت خود به راهنمایی نیاز دارید، پیش از تصمیم‌گیری با کارشناسان ما مشورت کنید تا با اطمینان، راهکاری متناسب با نیاز امروز و توسعه آینده کسب‌وکار خود انتخاب کنید.
