إستخدام عامل ضمان الخدمة من Cisco ومراقبة أداء الشبكة البينية لإدارة جودة الخدمة في شبكات Voice عبر IP

خيارات التنزيل

  • PDF     (428.9 KB)
    عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
  • ePub     (246.2 KB)
    العرض في تطبيقات مختلفة على iPhone أو iPad أو نظام تشغيل Android أو قارئ Sony أو نظام التشغيل Windows Phone
  • Mobi (Kindle)     (323.8 KB)
    عرض على جهاز Kindle أو تطبيق Kindle على أجهزة متعددة
تم التحديث:٢٩ أغسطس ٢٠١٧
معرّف المستند:13938

لغة خالية من التحيز

تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.

حول هذه الترجمة

ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).

المقدمة

يصف هذا المستند إستخدام عامل ضمان الخدمة (SAA) من Cisco ومراقبة أداء الشبكة البينية (IPM) لقياس جودة الخدمة (QoS) في شبكات نقل الصوت عبر بروتوكول الإنترنت (VoIP). تستند هذه المعلومات على مشروع مهاتفة IP في العالم الحقيقي. يركز هذا المستند على تطبيق المنتجات، وليس على المنتجات نفسها. يجب أن تكون على دراية بالفعل ب Cisco SAA و IPM وأن تتمتع بحق الوصول إلى وثائق المنتج المطلوبة. راجع المعلومات ذات الصلة للحصول على مراجع لوثائق أخرى.

ملاحظة: كانت وظيفة Cisco SAA في برنامج Cisco IOS® تعرف سابقا باسم مراسل وقت الاستجابة (RTR).

عندما تقوم بإدارة شبكة VoIP واسعة النطاق، يجب أن تكون لديك الأدوات اللازمة للمراقبة والإبلاغ بموضوعية عن جودة الصوت في الشبكة. وليس من المجدي الاعتماد على آراء المستعملين وحدهم، لأنه كثيرا ما يكون غير موضوعي وغير مكتمل. عادة ما تنشأ مشكلات جودة الصوت من مشكلات جودة الخدمة في الشبكة. لذلك، عندما تقوم بتحديد مشكلات جودة الصوت، تحتاج إلى أداة ثانية لإدارة ومراقبة جودة الخدمة في الشبكة. يستخدم المثال الموجود في هذا المستند Cisco SAA و IPM لهذا الغرض.

يتم إستخدام مدير الصوت من Cisco (CVM) مع Telemate.net لإدارة جودة الصوت. وهو يقدم تقارير عن جودة الصوت للمكالمات عبر عامل تلف/انخفاض التخطيط المحسوب (ICPIF) الذي يتم حسابه بواسطة بوابة Cisco IOS لكل مكالمة. وهذا يسمح لمدير الشبكة بتحديد المواقع التي تعاني من جودة صوت رديئة. راجع إدارة جودة الصوت باستخدام برنامج إدارة الصوت (CVM) من Cisco وبرنامج Telemate للحصول على مزيد من المعلومات.

المتطلبات الأساسية

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

المكونات المستخدمة

لا يقيد هذا وثيقة إلى خاص برمجية أو جهاز صيغة، غير أن المثالفي هذا وثيقة يستعمل هذا برمجية وجهاز صيغة:

  • برنامج IOS الإصدار 12.1(4) من Cisco

  • IPM 2.5 ل Windows NT

  • محول سلسلة Catalyst 4500

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر.

مشاكل جودة الخدمة في شبكة VoIP

قد تؤدي عدة عوامل إلى تدهور جودة الصوت في الشبكة الصوتية المحددة الخطوات:

  • فقدان الحزمة

  • تأخير مفرط

  • رجفان مفرط

من المهم بشكل خاص أن يراقب أنت هذا رقم على أساس مستمر، إن ربط استعملت خدمات يحول في ال WAN (مثلا، ATM، ترحيل إطار، أو ip فعلي خاص شبكة). هناك العديد من السيناريوهات حيث يمكن أن يؤدي الازدحام في شبكة الناقل أو تنظيم حركة مرور البيانات بشكل غير صحيح على أجهزة الحافة أو تنظيم تنظيم تنظيم البيانات بشكل غير صحيح على جانب الناقل إلى فقدان الحزمة أو التخزين المؤقت المفرط. عندما تقوم شركة النقل بإسقاط الحزم، لا يوجد دليل واضح على الأجهزة الطرفية. لذلك، يحتاج أنت أداة نهاية إلى نهاية مثل cisco SAA أن يستطيع حقن حركة مرور على المدخل ومتحقق من وصولها الناجح عند المخرج.

إدارة جودة الخدمة باستخدام Cisco SAA و IPM

هناك ثلاثة مكونات Cisco SAA و IPM:

  • مسبار RTR

  • المستجيب RTR

  • وحدة تحكم IPM

يرسل مسبار RTR دفعة من الحزم إلى المستجيب RTR. ويقوم المسعف الذي يعمل بتقنية RTR بإلقائهم وإعادتهم إلى المسبار. وتتيح هذه العملية البسيطة للمجس إمكانية قياس فقدان الحزمة وتأخير الرحلة ذهابا وإيابا. لقياس الرجفان، يرسل المسبار حزمة تحكم إلى المستجيب قبل أن يبدأ الربط تفجير. تقوم حزمة التحكم بإعلام المستجيب بعدد المللي ثانية (مللي ثانية) التي يمكن توقعها بين كل حزمة في الاندفاع. بعد ذلك يقوم المستجيب بقياس التأخير بين الحزم أثناء الاندفاع، ويتم تسجيل أي انحراف عن الفاصل الزمني المتوقع على أنه رجفان.

تتحكم وحدة تحكم IPM في مراقبة جودة الخدمة. وهو يقوم ببرمجة عمليات فحص RTR باستخدام المعلومات ذات الصلة من خلال بروتوكول إدارة الشبكة البسيط (SNMP). كما أنها تجمع النتائج عبر بروتوكول SNMP. لا يتطلب تكوين واجهة سطر الأوامر Cisco IOS على مستكشفات RTR.

قم بإصدار أمر التكوين العام rtr responder، لتكوين المستجيبين في RTR يدويا.

يجب أن تقوم مستكشفات RTR والمستجيبون بتشغيل برنامج Cisco IOS Software، الإصدار 12.0(5)T أو إصدار أحدث. يوصى بأحدث إصدار للصيانة وهو الإصدار 12.1 من الإتجاه السائد. تقوم مستكشفات RTR والمستجيبون في الأمثلة الواردة في هذا المستند بتشغيل الإصدار 12.1(4). إصدار IPM المستخدم هو IPM 2. 5 ل Windows NT. يتوفر تصحيح على Cisco.com لهذا الإصدار. هذا التصحيح مهم، حيث أنه يقوم بإصلاح مشكلة حيث يقوم IPM بتكوين إختبارات RTR باستخدام إعداد أسبقية IP غير صحيح.

تصميم

قبل نشر حل Cisco SAA و IPM، يجب عليك القيام ببعض أعمال التصميم مع وضع هذه الاعتبارات في الاعتبار:

  • وضع مستكشفات RTR والمستجيبين

  • نوع حركة المرور التي يتم إرسالها من المسبار إلى المستجيب

هناك عدد من الأمور التي يجب أخذها بعين الإعتبار عند إتخاذ قرار بشأن وضع المسابير والمستجيبين. أولا، تريد أن يغطي قياس جودة الخدمة كل موقع، وليس فقط المواقع التي بها مشاكل. وذلك نظرا لأن تقارير IPM حول التأخير وأرقام الموجات مفيدة للغاية عند مقارنتها بالمواقع الأخرى في الشبكة نفسها. وبالتالي، فأنت تريد قياس المواقع بجودة خدمة جيدة وجودة خدمة رديئة. كما أن الموقع الجيد الأداء قد يصبح غدا موقعا ضعيف الأداء بسبب التغييرات في أنماط حركة المرور أو تغيرات الشبكة. سوف ترغب في اكتشاف هذا قبل أن يؤثر على جودة الصوت ويتم الإبلاغ عنه من قبل المستخدمين.

ثانيا، يعتبر إستخدام وحدة المعالجة المركزية (CPU) أمرا مهما. قد لا يتمكن الموجه المشغول بالفعل من خدمة مكون RTR في الوقت المناسب، وقد يؤدي ذلك إلى تشويه النتائج. أيضا، إذا قمت بوضع عدد كبير للغاية من مثيلات المسبار على أي موجه واحد، فقد تقوم بإنشاء مشاكل إستخدام عالية لوحدة المعالجة المركزية (CPU) على الرغم من عدم وجود أي منها من قبل. تتمثل الطريقة المختارة لشبكة المثال في هذا المستند (ويجب أن يعمل هذا في معظم الشبكات) في وضع مستكشفات RTR على موجهات الجهات البعيدة/الفرعية. عادة ما تقوم هذه الموجهات بتوصيل شبكة LAN واحدة بخدمة WAN بطيئة نسبيا. وبالتالي، غالبا ما يكون إستخدام موجهات الفروع لوحدة المعالجة المركزية (CPU) منخفضا جدا، كما يمكنها التعامل بسهولة مع RTR. الفائدة الأخرى من هذا تصميم أن تقوم بتوزيع الحمل على أكبر عدد ممكن من الموجهات. تذكر دائما أنه من العمل أن تكون مجبرا أكثر من أن تكون مستجيبا، لأن المستكشفات تأخذ كمية معينة من SNMP الاقتراع.

من خلال هذا التصميم، يجب وضع المستجيبين بتقنية RTR في المركز. سيكون المستجيبون أكثر انشغالا من المستكشفات، لأنهم سيستجيبون للعديد من الاستكشافات. وبالتالي، يعمل التصميم القوي على نشر الموجهات المخصصة التي تعمل كجهات إستجابة فقط. تحتوي معظم المؤسسات على موجهات متقاعدة على الرف يمكنها أداء هذه الوظيفة. سيكون أي موجه مزود بواجهة إيثرنت كافيا. بدلا من ذلك، يمكن أن تتضاعف أجهزة التوجيه الأساسية/الموزعة كأجهزة إستجابة. يصف الرسم التخطيطي للشبكة في هذا القسم كلا السيناريوهين.

يمكنك نشر الحمل عبر أكبر عدد ممكن من الموجهات، ومراقبة إستخدام وحدة المعالجة المركزية (CPU) الخاصة ب RTR باستخدام هذا الأمر:

Router# show processes cpu | i Rtt|PID

PID  Runtime(ms)  Invoked  uSecs  5Sec   1Min   5Min    TTY Process
67           0         7      0   0.00%  0.00%  0.00%   0 Rtt Responder

13938-csaaipm1.gif

عند مطابقة التحاليل مع المستجيبين، يوصى بالحفاظ على مخطط متناسق بين المسبار والمستجيب. على سبيل المثال، يجب فصل جميع أجهزة الاستشعار والمستجيبين بنفس عدد الموجهات والمحولات وارتباطات شبكة WAN. وعندئذ فقط يمكن مقارنة نتائج IPM بشكل مباشر بين المواقع.

وفي هذا المثال، هناك 200 موقع بعيد وأربعة مواقع أساسية/للتوزيع. يعمل محول Catalyst 4500 في كل موقع توزيع كمستجيب متخصص في إستجابة إستجابة إستجابة إستجابة إستجابة المحطة السريعة (RTR). يعمل كل موجه من الموجهات البعيدة ال 200 كتحقيق في RTR. ويستهدف كل مسبار المستجيب الموجود في موقع التوزيع المتصل مباشرة.

يجب منح دفعات حركة المرور التي يتم إرسالها بواسطة المستكشفات إلى المستجيبين نفس مستويات جودة الخدمة (QoS) بواسطة الشبكة كما هو معطى للصوت. وقد يعني ذلك أنه يجب عليك ضبط تكوينات أولوية بروتوكول جدول التوجيه (RTP) أو قوائم انتظار المهلة المنخفضة على الموجه، حتى تخضع حركة مرور البيانات من إختبارات RTR إلى قوائم انتظار أولوية صارمة. عندما يشكل أنت التحقيق ل RTP ربط، فقط الغاية مستعمل مخطط بيانات بروتوكول (UDP) ميناء يستطيع كنت ضبطت ولا المصدر ميناء. يحتوي تكوين موجه LLQ النموذجي في هذا المثال على قوائم وصول تصنف حزم RTR بشكل خاص في قائمة الانتظار نفسها كصوت:

class-map VoiceRTP
  match access-group name IP-RTP

policy-map 192Kbps_site
  class VoiceRTP
    priority 110

ip access-list extended IP-RTP
  deny   ip any any fragments
  permit udp 10.0.16.0 0.255.239.255
             range 16384 32768 10.0.16.0 0.255.239.255
             range 16384 32768 precedence critical
  permit udp any any eq 20000 precedence critical
  permit udp any eq 20000 any precedence critical

تحتوي قائمة الوصول إلى IP-RTP على خطوط التصنيف التالية:

  • رفض ip أي أجزاء

    رفض أي جزء من IP، نظرا لأن قائمة الوصول للطبقة 4 تسمح بذلك بشكل ضمني.

  • السماح بنطاق UDP 10.0.16.0.255.239.255 النطاق 16384 32768 10.0.16.0.255.239.255 النطاق 16384 32768 للأسبقية الحرجة

    السماح لحزم RTP من الشبكات الفرعية الصوتية مع تعيين أسبقية IP على 5.

  • السماح ب UDP لأي أسبقية EQ 20000 حاسمة

    السماح لحزم RTP من تحقيق RTR بالذهاب إلى مستجيب RTR.

  • السماح ب UDP أي EQ 20000 أي أسبقية حرجة

    السماح لحزم RTP من المستجيب RTR بالعودة إلى تحقيق RTR.

تأكد من أن إضافة حركة مرور RTR لا تتسبب في زيادة اشتراكات قوائم انتظار LLQ وتتسبب في إسقاط الحزم الصوتية الحقيقية. ترسل العملية القياسية Default60ByteVoice IPM دفعات من حزم RTP باستخدام هذه المعلمات:

  • حمولة الطلب: 60 بايت

    ملاحظة: هذا هو عنوان RTP وصوته. أضف 28 بايت (IP/UDP) للحصول على حجم مخطط البيانات من L3.

  • الفاصل الزمني: 20 مللي ثانية

  • عدد الحزم: 10

وهذا يعني أن تردد RTR يستهلك أثناء الانفجار 35. 2 كيلوبت من عرض النطاق الترددي العريض لمعيار LLQ. إذا لم يكن هناك نطاق ترددي كاف ل LLQ، فقم بإنشاء عملية IPM جديدة وزيادة فترة الحزمة. مع المعلمات الموضحة في نافذة تكوين IPM هذه، يستهلك الاندفاع 1 كيلوبت في الثانية فقط من عرض النطاق الترددي:

13938-csaaipm2.gif

النتائج

الجدول الموجود في هذا القسم هو مثال على تقرير IPM. يحتوي هذا التقرير على ثلاث مثيلات لمتحقق RTR. تذكر أنه قد يتم تكوين تحقيق فعلي واحد باستخدام مثيلات تحقيق RTR المتعددة التي تستهدف مستجيبين مختلفين أو تستخدم حمولات مختلفة.

13938-csaaipm3.gif

هذه هي معاني كل عمود:

متوسط:

يقوم IPM بحساب متوسط لكل ساعة من أخذ العينات. ثم يجري حساب متوسطات هذه الساعات على مدى فترة اطول للحصول على متوسطات يومية، أسبوعية، أو شهرية. وبكلمات أخرى، يحسب المعهد بالنسبة للتقرير اليومي المتوسط لكل ساعة على مدى ال 24 ساعة الماضية. ومن ثم يحسب المتوسط اليومي كمتوسط لهذه المتوسطات ال 24.

متوسط الحد الأقصى:

هذه القيمة هي متوسط كل الحدود القصوى بالساعة لكل يوم وأسبوع وشهر في المخطط. وبعبارة أخرى، يستوعب التقرير اليومي أكبر عينة يتم الإبلاغ عنها في غضون كل ساعة من الساعات الأربع والعشرين الماضية. ومن ثم يحسب المتوسط الأقصى اليومي كمتوسط لهذه العينات ال 24.

أكثر من ٪:

هذه هي النسبة المئوية للعينات التي تجاوزت الحد الذي تم تكوينه للمجمع.

خطأ ٪:

هذه هي النسبة المئوية للحزم التي واجهت خطأ. يقوم مسبار الرجفان بالتبليغ عن عدة أنواع من الأخطاء:

  • فقد حزم SD — الحزم المفقودة بين المصدر والوجهة

  • فقد حزم DS - الحزم المفقودة بين الوجهة والمصدر

  • عمليات التشغيل — عدد المرات التي تعذر فيها بدء عملية وقت الذهاب والعودة (RTT) بسبب عدم إكمال عملية سابقة ل RTT

  • التسلسل- عدد عمليات إكمال RTT التي تم تلقيها بمعرف تسلسل غير متوقع. هذه بعض الأسباب المحتملة التي قد تؤدي إلى حدوث هذا:

    • تم تلقي حزمة مكررة.

    • تم تلقي رد بعد انقضاء المهلة المحددة.

    • تم تلقي حزمة تالفة ولم يتم الكشف عنها.

  • عدد مرات حدوث أي من هذه الحالات:

    • تعذر بدء عملية RTT بسبب عدم توفر بعض الموارد الداخلية الضرورية (على سبيل المثال، الذاكرة أو النظام الفرعي لبنية شبكة الأنظمة [SNA])

    • تعذر التعرف على إكمال العملية.

  • MIA (مفقود في العمل)- عدد الحزم التي يتم فقدها والتي لا يمكن تحديد إتجاه لها.

  • متأخر—عدد الحزم التي وصلت بعد المهلة.

السؤال الذي ينشأ عن هذه المعلومات هو ما هي قيم التأخير والتشوه والخطأ المقبولة في شبكة VoIP. ولكن من المؤسف أنه لا توجد إجابة بسيطة على هذا السؤال. تعتمد القيم المقبولة على نوع برنامج الترميز وحجم المخزن المؤقت للرجفان وعوامل أخرى. وبالإضافة إلى ذلك، هناك ترابطات بين هذه المتغيرات. وقد يعني إرتفاع معدل فقدان حزم البيانات أنه يمكن تحمل معدل أقل من الاهتزاز.

أفضل طريقة للحصول على أرقام قابلة للتطبيق للتأخير والتشوه هي مقارنة المواقع المماثلة في نفس الشبكة. إذا كانت جميع المواقع المتصلة بسرعة 192 كيلوبت في الثانية بينما يقدر تقرير واحد قيمة النقش بحوالي 50 ميللي ثانية، بينما يبلغ عدد المواقع الأخرى عن وجود 100 ميللي ثانية، فيعني ذلك وجود مشكلة، بغض النظر عن القيم الإسمية. يمكن أن يوفر نظام منع الاختراقات (IPM) قياسات التأخير والتشوه المستمرة على مدار 24 ساعة طوال أيام الأسبوع للشبكة بالكامل، كما يمكن أن يوفر خط أساس لاستخدامه كمعيار للمقارنات بين التأخير والتشوه.

الأخطاء مختلفة، على أي حال. من حيث المبدأ، أي نسبة خطأ غير الصفر هي علامة حمراء. يتم منح حزم RTR نفس معالجة جودة الخدمة مثل الحزم الصوتية. إذا كانت جودة خدمة الشبكة والتحكم في دخول المكالمات قوية، فلا يجب أن يتسبب أي مستوى من الازدحام في فقدان الحزمة أو التأخير المفرط لحزم RTR أو الصوت. لذلك، يمكنك توقع أن يكون عدد أخطاء IPM صفرا. الأخطاء الوحيدة التي يمكن اعتبارها "عادية" هي أخطاء التحقق الدوري من التكرار (CRC)، ولكن يجب أن تكون نادرة في بنية أساسية للجودة. وإذا تكررت هذه الآراء، فإنها تشكل خطرا على جودة الصوت.

معلومات ذات صلة

هل كان هذا المستند مفيدًا؟

Feedbackالتعليقات

اتصل بنا