در زمان پشتیبانگیری شعبه، تماسهای تلفنی قطع و وصل میشوند؛ با این حال نمودار مصرف روزانه لینک، اشباع دائمی نشان نمیدهد. تیم شبکه میگوید سیاست اولویتبندی صدا فعال است، اما کسی بررسی نکرده ترافیک واقعاً وارد کلاس درست میشود یا بستهها در کدام مرحله حذف میشوند. افزایش پهنای باند ممکن است مسئله را موقتاً پنهان کند، بدون اینکه خطای سیاست برطرف شود.
اولویتبندی ترافیک شبکه باید قابل مشاهده و قابل آزمون باشد. در این راهنما، با استفاده از گزارشهای NetFlow Analyzer و دادههای کیفیت خدمت مبتنی بر کلاس در تجهیزات سازگار، مسیر بررسی علامتگذاری، کلاس ترافیکی و حذف بسته را توضیح میدهیم. هدف، ارزیابی اثر سیاست موجود است؛ نه ارائه یک پیکربندی یکسان برای همه روترها و شعب.
سه پرسش متفاوت درباره کیفیت خدمت
ابتدا معلوم کنید مشکل مربوط به طبقهبندی ترافیک است، نحوه اعمال سیاست یا کیفیت نهایی خدمت. دانستن اینکه بستهای با برچسب اولویت بالا ارسال شده، ثابت نمیکند همه تجهیزات مسیر با همان اولویت آن را پردازش کردهاند. همچنین سلامت یک لینک، کیفیت کامل تماس میان دو کاربر را تضمین نمیکند.
برای یک مسیر آزمایشی، مبدأ، مقصد، رابط خروجی و خدمت مورد بررسی را مشخص کنید. سپس زمان گزارش کاربر را با بازه دادههای شبکه تطبیق دهید. مقایسه شکایت چندثانیهای کاربر با میانگین یکروزه، نقطه شروع مناسبی برای تشخیص نیست.
گزارش جریان و شمارنده سیاست مکمل هم هستند
در راهنمای نمای کیفیت خدمت، NetFlow Analyzer اطلاعات برچسب DSCP را از دادههای جریان تجهیزات دریافت میکند و امکان بررسی بر اساس دستگاه، رابط، گروه و جهت ترافیک را توضیح میدهد. این داده کمک میکند ببینید چه ترافیکی با چه علامتی از نقطه مشاهده عبور کرده است.
در مقابل، راهنمای CBQoS جمعآوری داده سیاستهای مبتنی بر کلاس از تجهیزات سازگار سیسکو را با SNMP شرح میدهد. گزارشهای پیش از اعمال سیاست، پس از اعمال آن و بستههای حذفشده، برای ارزیابی رفتار هر کلاس به کار میروند. پشتیبانی عمومی از دریافت جریان، به معنای وجود این شمارندهها روی هر تجهیز نیست.
| منبع داده | به چه پرسشی پاسخ میدهد؟ | بهتنهایی چه چیزی را ثابت نمیکند؟ |
|---|---|---|
| گزارش جریان | چه مبدأ، مقصد یا برنامهای ترافیک دارد؟ | رفتار کامل صف سختافزاری |
| برچسب اولویت | ترافیک با چه علامتی مشاهده شده است؟ | رعایت اولویت در همه مسیر |
| شمارنده کلاس | سیاست با ترافیک هر کلاس چه کرده است؟ | رضایت کاربر از تماس |
| آزمون کیفیت مسیر | تأخیر، نوسان تأخیر و افت مسیر چگونه است؟ | علت قطعی هر افت بدون بررسی مکمل |
پیش و پس از سیاست، دو تاریخ متفاوت نیستند
نمودارهای پیشسیاست و پسسیاست، نقاط پردازشی دو طرف سیاست را توصیف میکنند؛ نه لزوماً ترافیک روز قبل و روز بعد از تغییر تنظیمات. برای سنجش اثر یک تغییر، باید علاوه بر این شمارندهها، دو بازه زمانی قابل مقایسه و شرایط بار مشابه داشته باشید.
در گزارش تحویل پروژه بنویسید داده مربوط به کدام رابط، جهت و کلاس است. ترکیب عدد خروجی یک رابط با ورودی رابط دیگر، بدون توجه به مسیر و بازه، میتواند نتیجه نادرست ایجاد کند. این دقت از افزودن نمودارهای بیشتر مهمتر است.
مسیر عملی تشخیص
اول طبقهبندی را بررسی کنید
یک تماس یا تراکنش مجاز آزمایشی ایجاد کنید و آن را با مبدأ، مقصد و زمان مشخص دنبال کنید. اگر داده مورد انتظار در کلاس هدف نیست، ابتدا تطبیق قواعد را بررسی کنید. بالا بردن سهم کلاس صوت، وقتی ترافیک صوت اصلاً وارد آن نمیشود، مشکل را حل نخواهد کرد.
برنامههای دارای درگاه پویا، تونلها و رمزگذاری میتوانند مشاهده را محدود کنند. از شماره درگاه بهتنهایی هویت قطعی برنامه را نتیجه نگیرید. روش شناسایی باید با دادهای که تجهیز و نسخه محصول واقعاً ارائه میکنند متناسب باشد.
سپس جهت اعمال سیاست را کنترل کنید
رابط فیزیکی درست و جهت ورودی یا خروجی را با محل سیاست مقایسه کنید. در مسیرهای تونلی، نقطه مشاهده بیرون تونل ممکن است با نقطه طبقهبندی داخل آن تفاوت داشته باشد. نام یک سیاست در فایل پیکربندی کافی نیست؛ باید روشن شود سیاست به مسیر واقعی مسئله متصل است.
بعد به سراغ محدودیت نرخ و صف بروید
مستند رسمی سیسکو میان محدودسازی نرخ با حذف یا علامتگذاری مجدد و شکلدهی ترافیک با نگهداری موقت بسته در صف تفاوت میگذارد. بنابراین افت ناشی از محدودسازی و تأخیر ناشی از صف را نباید یک مسئله واحد دانست. نوع رفتار باید از پیکربندی و شمارنده متناظر بررسی شود.
افزایش ظرفیت صف ممکن است حذف را کم کند اما زمان انتظار را بیشتر کند. برای خدمت حساس به تأخیر، هدف فقط صفر کردن شمارنده حذف نیست. نتیجه باید با معیار کیفیت همان خدمت ارزیابی شود.
از نشانه به تصمیم قابل دفاع برسید
| مشاهده | فرضیه قابل بررسی | گام بعدی |
|---|---|---|
| کلاس مهم تقریباً خالی است | قاعده طبقهبندی تطبیق نمیکند | ردیابی یک جریان شناختهشده |
| ترافیک وارد کلاس میشود اما حذف بالا میرود | محدودیت یا بار نامتناسب است | بررسی نرخ و سیاست در همان بازه |
| حذف کم است ولی تأخیر زیاد است | صف یا بخش دیگری از مسیر مسئله دارد | آزمون کیفیت مسیر و بررسی وابستگیها |
| برچسب در دو نقطه متفاوت است | علامتگذاری در مسیر تغییر کرده است | بررسی مرز اعتماد و تنظیم تجهیزات میانی |
| همه کلاسها تحت فشارند | ظرفیت واقعی کمتر از نیاز است | تحلیل رشد بار و برنامه ظرفیت |
این جدول مجموعه فرضیههاست، نه تشخیص خودکار محصول. چند علت میتوانند همزمان وجود داشته باشند. برای مثال، طبقهبندی صحیح مانع کمبود ظرفیت فیزیکی نمیشود و یک سیاست خوب نیز جای ظرفیت کافی را نمیگیرد.
فاصله نمونهبرداری را در تحلیل لحاظ کنید
راهنمای تنظیم نمونهبرداری، انتخاب فاصله و زمان انتظار برای دریافت داده CBQoS را توضیح میدهد. مقدار تنظیمشده باید در گزارش فنی ثبت شود. نمودار دورهای ممکن است اثر یک جهش کوتاه را در میانگین پنهان کند؛ نبود جهش در نمودار، دلیل کافی برای رد گزارش کاربر نیست.
در محیط بزرگ، کوتاه کردن فاصله برای همه تجهیزات نیز بدون ارزیابی بار جمعآوری تصمیم مناسبی نیست. ابتدا رابطهای حیاتی را انتخاب کنید، کیفیت داده را بسنجید و سپس دامنه را گسترش دهید. تغییر شناسه رابط یا راهاندازی مجدد تجهیز را نیز هنگام مقایسه شمارندهها در نظر بگیرید.
کیفیت تماس را جداگانه بسنجید
از گزارش DSCP یا شمارنده حذف، امتیاز کیفیت شنیداری تماس استخراج نکنید. برای ارزیابی نهایی، اندازهگیری مناسب تأخیر، نوسان تأخیر و افت لازم است. معرفی رسمی ابزارهای پایش پهنای باند نیز نمای کیفیت مسیر مبتنی بر مانیتور تلفنی IP SLA را جدا از نمای برچسبهای کیفیت خدمت معرفی میکند. دسترسی به آن باید با قابلیت تجهیز و بسته محصول تطبیق داده شود.
برای پیدا کردن بخش پرتأخیر مسیر، راهنمای تحلیل مسیر شبکه مکمل این بررسی است. اگر شواهد کمبود ظرفیت را نشان دادند، برنامهریزی ظرفیت پهنای باند تصمیم خرید لینک را به داده واقعی متصل میکند.
تغییر سیاست را با معیار بازگشت انجام دهید
پیش از اصلاح، پیکربندی معتبر، شاخص مبنا و روش بازگشت را ثبت کنید. تغییر را ابتدا روی مسیر محدود و در پنجره مجاز انجام دهید. پس از آن، کیفیت خدمت اصلی و اثر بر ترافیکهای دیگر را همزمان بررسی کنید؛ بهبود تماس نباید به توقف انتقال ضروری داده تبدیل شود.
معیار پذیرش پیشنهادی این است که ترافیک شناختهشده وارد کلاس درست شود، رفتار سیاست با طراحی سازگار باشد و آزمون انتهابهانتها نتیجه مطلوب بدهد. ادعای «بهبود شبکه» باید به همین شواهد مشخص متکی باشد، نه فقط کاهش یک نمودار.
نکات کلیدی
- علامتگذاری ترافیک، رفتار سیاست و کیفیت نهایی سه سطح متفاوتاند.
- گزارش جریان و شمارندههای مبتنی بر کلاس جای یکدیگر را نمیگیرند.
- محدودسازی نرخ و شکلدهی ترافیک پیامد یکسان ندارند.
- قبل و بعد از تغییر را در شرایط بار قابل مقایسه بسنجید.
سخن پایانی
اولویتبندی ترافیک زمانی مفید است که بتوان نشان داد بسته درست، در کلاس درست و در مسیر درست پردازش میشود. NetFlow Analyzer داده لازم برای بخش مهمی از این بررسی را فراهم میکند، اما تصمیم نهایی باید با آزمون خدمت و شناخت ظرفیت شبکه همراه باشد.
برای بررسی قابلیت تجهیزات، انتخاب بسته مناسب و استعلام لایسنس NetFlow Analyzer، از خدمات مدانت استفاده کنید. راهنمای محاسبه لایسنس به تعیین دامنه پایش کمک میکند و جلسه فنی مدانت میتواند از یک مسیر مسئلهدار و معیار پذیرش مشخص آغاز شود.
