مشغلات SONET

المقدمة

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

يفحص هذا المستند المشغلات التي تتعلق بأحداث الواجهة لأعلى ولأسفل. يشرح هذا المستند أيضا كيفية نشر الحزمة عبر SONET (POS)، ويأخذ في الاعتبار إتفاقيات مستوى الخدمة (SLAs) وأوقات التقارب في الطبقة 3.

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

المتطلبات

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

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

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

الاصطلاحات

راجع اصطلاحات تلميحات Cisco التقنية للحصول على مزيد من المعلومات حول اصطلاحات المستندات.

الأحداث التي أدت إلى إسقاط واجهة نقطة البيع

يصف هذا القسم الأحداث التي تتسبب في إسقاط واجهة نقطة البيع، ويسرد الأوامر ذات الصلة.

مشغلات مستوى القسم والخط

تشير قائمة المشغلات في هذا القسم إلى أنظمة نقل الشبكة الضوئية المتزامنة (SONET) GR-253-CORE: المواصفات العامة العامة الشائعة للمعايير:

• قسم فقدان الإشارة (SLOS)- تشير المواصفات إلى أنه يجب عليك اكتشاف ما لا يقل عن 2.5 us، وما لا يزيد عن 100us (6.2.1.1.1).

• فقد القسم للإطار (SLOF)—تشير المواصفات إلى أنه يجب عليك اكتشاف ذلك في 3 مللي ثانية على الأقل (أو 24 من رابطات الإطارات المعطلة المتعاقبة) (6.2.1.1.2).

• إشارة إشارة التنبيه - يجب إرسال الخط (AIS-L) - AIS-L عندما يكون ذلك مناسبا، خلال 125USEC من الكشف. يجب أن يكتشف الجهاز إستلام AIS-L إذا رأى الجهاز 5 إطارات متتالية حيث تم تعيين وحدات بت 6،7 و 8 من K2 إلى 111 (6.2.1.2.1).

• معدل خطأ البت المنحط للإشارة (SD-Ber)—يعد SD-Ber بمثابة مشغل فقط على الواجهات باستخدام التحويل التلقائي للحماية (AP) (المرتبط بحساب B2 BER).

• معدل خطأ بت فشل الإشارة (SF-Ber)—SF-BER هو مشغل لكل من واجهات APs وغير APs (المرتبط بحساب B2 BER).

• الإشارة إلى العيوب عن بعد - الخط (RDI-L) - لا يعد RDI-L بمثابة مشغل لنقاط الوصول أو نقاط الوصول. (ومع ذلك، يعد RDI-L بمثابة مشغل ل MPLS FRR) (القسم 5.3.3.1).

لمزيد من المعلومات حول الأقسام المذكورة في هذه القائمة، راجع موقع الويب Telcordia Information SuperStore .

الأوامر ذات الصلة

تأجيل نقطة البيع يقوم بتشغيل السطر n يمر خارج LOS/LOF/AIS ل n ms قبل أن يقوم الأمر بتشغيل الخط إلى أسفل:

إذا قمت بتكوين الأمر بدون أي قيمة رقمية، فإن وقت التأخير يكون 100 مللي ثانية بشكل افتراضي. يمكنك إستخدام مشغلات الخط على أي واجهة ليس APs POS. لا يمكنك إستخدام مشغلات الخط على الواجهات التي تشارك في نقاط الوصول، لأن مشغلات الخط تتداخل مع عملية APs. لا يسمح أمر تأخير نقطة البيع بتشغيل السطر n للخط بالإنخفاض إلى أسفل في نقطة الوصول (LOS) الموجزة التي تأتي من معدات تجميع طول الموجة الكثيف (DWDM) المحمي داخليا، من وقت حدوث محول حماية DWDM داخلي. إذا انقشع العيب خلال الفترة المقلولة كأن العيب لم يحدث.

يقوم تأخير نقطة البيع بتشغيل السطر بإيقاف تشغيل أي إجراء يستند إلى العيب (باستثناء زيادة العداد المعيب) حتى تنتهي فترة التسليم المحددة.

إذا لم تقم بتمكين هذا الأمر، يتم تشغيل نقاط الوصول (APs) والربط لأسفل من عيوب SONET المذكورة أعلاه فورا في معالج التوجيه (RP).

مشغلات المسار

تقوم هذه العيوب المحددة في مستوى المسار ببدء تغيير الحالة فقط إذا قمت بتمكين تأخير نقطة البيع لتشغيل المسار على الواجهة:

• AIS-P - يجب رفع هذا العيب ضمن 125usec من كشف العيب الذي ينتج في AIS-P. يجب أن تكشف أجهزة إنهاء المسار (PTE) هذا العيب عندما تحتوي وحدات البايت H1 و H2 لمسار STS على كل 1S ل 3 إطارات متتالية. تحتاج المسارات المتسلسلة إلى ملاحظة أول وحدات البايت H1 و H2 فقط. ولمزيد من المعلومات، انظر الفرع 6-2-1-2-2 من R6-175 و R6-176.

• RDI-P — إذا كان RDI-P موجودا، يجب اكتشاف العيب ضمن 10 إطارات. انظر 6.2.1.3.2 من R6-221.

• B3-TCA (أجهزة التنبيه عبر الحد الفاصل) ل B3- يتم ربط هذا التنبيه بحساب إتصالات B3 الثنائية المتزامنة (Bisync) IP (BIP).

• LOP-P (فقد المسار للمؤشر) (إذا كان إصدار IOS يتضمن CSCdx58021)—راجع القسم 6.2.1.1.3 من GR-253.

لمزيد من المعلومات حول الأقسام المذكورة في هذه القائمة، راجع موقع الويب Telcordia Information SuperStore .

أمر ذو صلة

يقوم تأخير نقطة البيع بتشغيل المسار <msec>بتمكين تشغيل إلغاء الارتباط على AIS-P، RDI-P، وأخطاء B3 الزائدة. بشكل افتراضي، يتم تعطيل إطلاق الارتباط لأسفل لأخطاء المسار.

كما يحدد الأمر وقت التسليم في النطاق من 0 إلى 511 مللي ثانية (الافتراضي هو 100 مللي ثانية). لا تتسبب عيوب مشغل المسار (AIS-P، RDI-P) التي تظهر قبل نهاية فترة التسليم في إطلاق. عندما لا تقوم بتكوين هذا الأمر بشكل صريح على واجهة POS، لا ينتج أي إجراء إذا تم معالجة عيوب مستوى PATH. بخلاف مشغلات الخط، تتيح واجهات APs مشغلات المسار، لأن مشغلات المسار لا تتداخل مع نشاط مستوى الخط لنقاط الوصول. لم يتم السماح بتكوين مشغلات المسار باستخدام نقاط الوصول (APs) في الإصدارات الأقدم من برنامج Cisco IOS® الإصدار 12.0(28)S. تمت إضافة مشغلات المسار لتسريع سلوك الارتباط لأعلى/لأسفل لواجهات POS عند الاتصال بشبكات SONET. وهذا يسمح بتقارب أسرع للطبقة 3 في وجود الأخطاء البعيدة.

ملخص مشغلات POS لسلوك CLI

يسرد هذا الجدول شروط مشغلات نقطة البيع والنتائج المقترنة بها:

الشرط	نتيجة
إذا قمت بتكوين لا شيء مرتبط بشكل صريح بمشغلات نقطة البيع.	تتم معالجة مشغلات مستوى البند على الفور.
إذا كنت قد انتهيت من تكوين أمر تأخير نقطة البيع" يؤدي إلى تشغيل السطر.	تتم معالجة مشغلات مستوى الخط بعد تأخير قدره 100 مللي ثانية.
إذا كنت قد انتهيت من تكوين أمر تأخير نقطة البيع يشغل السطر x.	تتم معالجة مشغلات مستوى الخط بعد x مللي ثانية، حيث يكون x بين 0 و 511.
إذا قمت بتكوين لا شيء مرتبط بشكل صريح بمشغلات المسار.	لم تتم معالجة مشغلات المسار ولن تتسبب في إتخاذ أي إجراء.
إذا كنت قد انتهيت من تكوين الأمر pos delay drivers path.	تتم معالجة مشغلات مستوى المسار بعد تأخير قدره 100 مللي ثانية.
إذا كنت قد انتهيت من تكوين تأجيل نقطة البيع يشغل الأمر x المسار.	تتم معالجة مشغلات مستوى المسار بعد x مللي ثانية، حيث تكون x بين 0 و 511.

إبطال أجهزة تنبيه SONET

يتم الاحتفاظ بتنبيهات SONET الناتجة عن العيوب لمدة 10 ثوان (10.5 +-.5) بعد مسح الخلل.

معالجة الخلل

في IOS، تغير بطاقات نقطة البيع حالة الخط الخاصة بها بسبب مشغلات مختلفة، من خلال وسيلتين عامتين لمعالجة العيوب. بينما يعتمد هذا على التكوين المحدد للواجهة (APs أو غير APs)، هناك بشكل عام نوعان من الفشل:

• مدارا

• غير مدارة

يجب أن تفهم المصطلحات الخاصة بمعالجة التنبيه التي يستخدمها هذا المستند:

• الخلل - حالة الفشل التي يتعرف عليها الجهاز.

• الفشل - عيب تم نبذه ل 2.5 ثانية تقريبا، ثم يتم الإبلاغ عنه من خلال رسائل SONET-4-alarm. أي خلل يكون بمثابة زناد لا تغرق فيه.

• حالات الفشل غير المدارة - أحداث مثل LOS و LOF، وما إلى ذلك. يتم الكشف عنها بواسطة أداة إعداد SONET بواسطة مجموعة محددة من المعلمات، ولا تتطلب أي حساب. إما أن يكون هناك عيب موجود ويتم تأكيده من قبل الجهاز، أو أنه لا يوجد عيب. وعموما، تعالج حالات الفشل العسير كهذه من خلال فترات الانقطاع. ويجري على الفور تأكيد صحة نظام لوس أنجلوس (LOS)، والنظام الدولي للفرانكوفونية (AIS-P)، ونظام RDI-P (RDI-P). هذه تعتمد على الصانع والقواعد المعرفة لاكتشاف كل من هذه العيوب. والواقع أن التأثير المترتب على هذه العيوب فوري. ومع ذلك، يمكنك توجيه الموجه لتأخير تأكيد هذا العيب كفشل. هناك إثنان من وحدات التوقيت التي تحدد قيمة التأخير، مشغلات تأخير نقطة البيع [مسار | خط] وتأخير الناقل. وتتناول هذه المسائل في وقت لاحق من الوثيقة.

• أجهزة الإنذار المدارة - أحداث مثل TCAs وحسابات SD/SF-Ber. وهذه تتطلب بعض الحسابات لتحديد ما إذا كانت موجودة، أو أنها في زيادة أو انخفاض، وما إلى ذلك. على سبيل المثال، لا يمكنك الحصول على نقطة وصول (LOS) تزيد من "LOS" الخاصة بها من منظور الموجه. ومع ذلك، يمكن أن يكون لديك BER في حالة زيادة أو انخفاض، وقد يكون الإجراء المتخذ مختلفا. إن حالات الفشل البسيطة، مثل BER و TCA، تحتاج إلى بعض الحسابات، لأنها تعتمد على عدد من العوامل، على سبيل المثال، الحدود التي يستطيع المستخدم تكوينها، ومعدل البت، وأقصى عدد من BIP CVs (لأنها مختلفة عن B1، B2، و B3). كما تستغرق هذه الأعطال وقتا أطول للكشف عنها، نظرا لاستطلاع الأجهزة لعدادات بروتوكول BIP، وأيضا لأن هذه الأنواع من العيوب تكون تدريجية في طبيعتها ومتراكمة على مر الوقت. وصحيح أيضا أنك بشكل عام لا تنتقل من 0 بيتابايت إلى إشارة تدهور (SD) أو فشل إشارة (SF) بدون وجود نوع آخر من حالات التعطل الشديد في الشبكة. هذه العيوب تحدث بشكل أبطأ عند مقارنتها مع الإخفاقات الصلبة.

وفي ما يلي نهج معمم لحسابات أساسية يصف كيفية حساب حساب حساب معدل الأرباح (BER):

بعد كل عملية إعادة تشغيل للحسابات وإلى أن تصل BER_PERIOD إلى REQUIRED_BER_PERIOD (لا يتم نشر نافذة التكامل بالكامل)، تعمل الخوارزمية بدقة كعملية تكامل أو متوسط:

• BER_PERIOD = BER_PERIOD + 1 ثانية.

• Current_BIP = Current_BIP + BIP_NEW.

• Current_BER = current_BIP/ber_Period.

بعد أن يصل BER_PERIOD إلى REQUIRED_BER_PERIOD (تم نشر نافذة التكامل بالكامل وبدأ في الانزلاق)، تعمل الخوارزمية كدلو مثقوب:

• ber_period = required_ber_period.

• Current_BIP = current_BIP + BIP_NEW - Current_BER * 1 ثانية.

• Current_BER = current_BIP/ber_Period.

يتم تحديد REQUIRED_BER_PERIOD استنادا إلى معدل الخط وعتبة BER التي تم تكوينها فقط وفقا للمعايير (انظر الشكل 5-5، معايير وقت بدء المحول، GR-253). لكنه أقل من ثانية واحدة، معدل أخذ العينات لدينا.

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

• لا يزال BER يقع ضمن نفس النطاق. لا يوجد إجراء جديد.

• لقد زاد BER مرة أخرى، وتجاوز حد SD أو SF (بالنسبة للفئة B2). إرفع إنذارا جديدا.

• انخفض BER إلى أقل من حد BER. امسح المنبه.

لتأكيد TCA أو SD/SF، يجب الانتظار فقط حتى تقوم بتجاوز حد معين في فترة الاستطلاع هذه. في وقت إجراء الحساب، تأكد مما إذا كان Current_BER قد تجاوز الحد، وإذا كان قد تجاوز الحد، فيمكنك التقدم وتأكيد التنبيه مباشرة من خلال البرنامج.

وهذا صحيح لأنه، إذا كان Current_BER كبيرا بما يكفي لتشغيل التنبيه في البداية، فإن الحالة لا تزال صحيحة في نهاية BER_Period. يعتمد هذا على كيفية تعريف القيم ومقارنتها بالنسبة لنافذة الحساب.

عند مسح تنبيه، يجب الانتظار حتى نهاية نافذة حساب BER_PERIOD. وهذا لضمان عدم تراكم أي من بطاقات BIP الجديدة خلال الجزء الأخير من النافذة التي قد تبقيك فوق الحد المسموح.

ملاحظة: وفقا للطراز GR-253، يتم ربط كل من SD-BER و SF-BER بشكل صارم بعدد وحدات BIP من الطراز B2. الحدود الافتراضية الحالية هي:

• حدود ber — SF = 10e-3 SD = 10e-6

• حدود TCA—B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

ملاحظة: تشتمل بطاقات Engine2 OC-48 على هذه الحدود الافتراضية:

• حدود ber — SF = 10e-4 SD = 10e-6

• حدود TCA—B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

إذا كنت تريد أن يكون لديك فعل مشغل مسار B3 TCA مماثل ل SF، فيجب تعيين عتبة B3 على نفس العتبة، 10e-3. يمكنك القيام بذلك من خلال الأمر pos threshold b3-tca 3 في موجه الأمر (config-if)#.

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

المشغلات قيد التنفيذ

يوفر هذا القسم بعض المعلومات الأساسية لفحص تفاعل بعض المقابض المختلفة القابلة للتوليف الخاصة بالمستخدم في IOS:

يؤدي تأخير نقطة البيع إلى تشغيل [السطر | path] يؤدي الأمر إلى تأخير إرسال التقارير حول خلل ما والإجراء المتخذ.

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

الخط الزمني:

|----------|----------|----------|----------|----------|
T0         T1         T2         T3         T4         T5

هنا:

• t0—الوقت الذي يحدث فيه العيب.

• t1—الوقت الذي يكتشف فيه الجهاز العيب.

• t2—الوقت الذي يتم فيه الإبلاغ عن العيب على أنه فشل.

• t2-T3—الوقت الذي يتم إيقافه لأي مشغلات تم تكوينها.

• T3-T4- الوقت الذي تنتظر فيه بسبب تأخر الناقل.

• t4—الوقت الذي يظهر فيه الواجهة فعليا في برنامج IOS.

• t5—الوقت الذي يتم فيه إسقاط أي تجاور لبروتوكول التوجيه.

افحص الخط الزمني لمراقبة كيفية تعديل المقابض المختلفة لتحقيق نتائج مختلفة.

يؤثر الأمر post delay ggers على المدة بين T2 و T3، وفي الواقع، يخفي العيب من IOS، حتى تنتهي فترة التسليم. طبعا إذا كان العيب امسح قبل وصولك للt3 ما بيصير شي و كأنو صاير شي. القيمة الافتراضية لكل من مشغلات الخط والمسار هي 100 مللي ثانية، والنطاق هو من 0 إلى 511 مللي ثانية. لا يتم تمكين مشغلات المسار (بمعنى آخر، لا تتخذ أي إجراء) ما لم يتم تكوين مسار تأخير نقطة البيع أولا. مسار مشغل تأخير نقطة البيع هو وقت الانتظار قبل الاستجابة إلى تنبيه المسار. الافتراضي هو عدم التفاعل. إذا قمت بتكوين مسار مشغل تأخير نقطة البيع مباشرة بدون أي قيمة، فسيتم تعيين القيمة الافتراضية 100 مللي ثانية تلقائيا. ويشمل ذلك AIS-P و RDI-P و B3-TCA. تمت إضافة هذه الوظيفة من خلال CSCds82814 (حوالي 12.0(15.5)S/ST).

Carrier-Delay هو وقت الإيقاف بين نهاية وقت الإيقاف لتأخير نقطة البيع وسيؤدي إلى إسقاط واجهة IOS. القيمة الافتراضية هي 2000 مللي ثانية. تأخير الناقل هو الوقت بين T3 (عندما يصبح IOS واعيا بفشل) و T4 (عند تعطل الواجهة). بشكل افتراضي، يتم تعيين هذا إلى 2 ثانية، ويمكن تكوينه لقيم msec. كما يشير الخط الزمني، فإنه دالة إضافية فوق أدوات التقاط مستوى SONET. ويتصرف بنفس الطريقة التي يعمل بها مشغلات POS - إذا تم مسح التنبيه قبل نهاية فترة التسليم، فلن يتم إسقاط الواجهة. ولكن هنالك لغز هنا. لا يقوم مؤقت تعطيل SONET بمسح العيب قبل تنشيط تأخير الناقل، إلا إذا كان تأخير الناقل كبيرا (أكثر من 10 ثوان). وهذا يؤدي إلى حالة يتم فيها تنشيط تأخر الناقل دائما تقريبا، وبالتالي يجب اعتباره صغيرا إلى حد ما عند نشره مع واجهات نقطة البيع. كما تتم إضافة تأخير الناقل بعد مسح التنبيه، قبل إعلان الواجهة أيضا. وبالتالي، يمكنك حساب قيمة تأخر الناقل مرتين قبل أن تظهر الواجهة مرة أخرى.

هذا مفيد مع بعض الواجهات والوسائط المادية. ومع ذلك، مع واجهات POS، هناك عدد من المشغلات ووحدات التوقيت التي يمكنك إستخدامها، ويتم دمجها لإنشاء التأثير المرغوب، دون تأخير من قبل شركة النقل الذي يقوم بمثل هذا الدور الرئيسي. تعد قيمة تأخير الناقل التي تتراوح من 0 إلى 8 مللي ثانية نقطة بداية جيدة للعملاء للتفكير فيها عند إختبار هذه المقابض بمفردهم. بشكل عام، تتمثل الاستراتيجية الجيدة في إستخدام الأمر Pos Delay Ggers لاستيعاب أي مشاكل، وتوفير تأثير التسليم المطلوب. يمكن إبقاء تأخر الناقل صغيرا لتقليل تأثيره.

تم تعيين مؤقت تعطيل SONET المذكور أعلاه على 10 ثوان (+/- .5 ثانية)، ويطلب بواسطة GR-253 لضمان عدم حدوث فترة رفرفة أقل من 10 ثوان. يبدأ المؤقت بعد مسح العيب. تتم إعادة تعيين المؤقت إذا حدث خطأ آخر قبل انتهاء صلاحية نافذة المؤقت.

الخط الزمني:

|----------|----------|----------|----------|----------|---------|
T0         T1         T2         T3         T4         T5        T6

هنا:

• t0—مسح العيب.

• يبدأ مؤقت t0—Debonce.

• t4-t0 + 10sec (وبالتالي، يجب أن يعمل الفشل على مسح ما إذا لم تحدث أي عيوب جديدة بين t0 و t4).

إن يقع حدث قبل T4، (لنقل) at T2 (هو يستطيع كنت آخر عيب، أو تكرار من ال نفسه نوع عيب)، المؤقت توقف إلى أن هذا عيب جديد يمسح. عند T3، يبدأ المؤقت مرة أخرى، عندما لا يكون هناك عيوب نشطة، ويحسب ل ~10 ثوان. في حالة عدم مواجهة أي أحداث جديدة، قم بإلغاء تحديد التنبيه في T5، ثم ابدأ تشغيل مؤقت تأخير الناقل. عند مسح تأخير الناقل في T6، قم بإعادة إظهار الواجهة.

يجب أن تسمح هذه المعلومات للعميل بفهم كيفية إستجابة واجهات POS لشتى حالات SONET/SDH بشكل أكثر وضوحا. وهذا يسمح بتكوين الجهاز على نحو أكثر دقة وفقا للسلوك الذي يريده العملاء.

لماذا إستخدام المشغلات؟

يشرح هذا القسم متى يجب أن تستخدم مشغلات تأخير نقطة البيع [السطر | path] أمر، ومتى يجب ألا تستخدمه.

فيما يلي السيناريوهات التي يجب عدم إستخدام مشغلات تأخير نقطة البيع. هناك العديد من السيناريوهات:

• لا يمكنك إستخدام مشغلات الأسطر مع واجهات APs التي تم تكوينها. لا تسمح الإصدارات الأقدم من برنامج Cisco IOS الإصدار 12.0(28)S حتى باستخدام مشغلات المسار.

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

• عندما تريد أن تقوم مشغلات مستوى السطر بإسقاط الواجهة بدون تأخير، لا يمكنك إستخدام هذا الأمر.

فيما يلي السيناريوهات التي يمكنك فيها إستخدام أمر مشغلات تأخير نقطة البيع:

• عندما تريد إيقاف تأثير عيب مستوى خط مؤقتا.

• لتمكين قدرة العيوب في مستوى المسار على إسقاط الواجهة على الفور.

• لتمكين العيوب في مستوى المسار لإسقاط الواجهة، لكن مع بعض القيد مضمن.

مشغلات SLAs و POS

اختبر هذا الخط الزمني:

|----------|--------------------|
T0         T1                   T2

• الوقت t=0 (t0)- عندما يتم اكتشاف العيب.

• الوقت T2 - وقت إستعادة إتفاقية مستوى الخدمة (SLA) المطلوبة.

• Time T1-Any Transfer من تأخير نقطة البيع يشغل أمر أن يكون شكلت (التقصير ل LINE هو 0 والافتراضي ل PATH ليس مكنت).

• X هي قيمة التسليم (حتى X = قيمة T1).

• Y هو الوقت المستغرق لاستعادة الخدمة من الطبقة 3.

مبرهنة

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

فرضيات

• إذا كان Y > (T2-T1) لأي قيمة T1، فإن التسليم ليس فكرة جيدة لأنه، أنت لا يمكن أن تلتقي SLA الخاص بك إذا شكلت أي مقبض.

• إذا كان Y <= (T2-T1)، أنت يستطيع وضعت في الاعتبار تنفيذ من مقبض. إذا كانت مدة الفشل أقل من (T1-T0)، فيمكنك الانتظار بسبب، عدم الحاجة إلى إستخدام موارد الموجه، ويمكنك الوفاء ب SLA المطلوبة. إذا استمر العيب في المرة السابقة T1، لا يزال بإمكانك تلبية إتفاقية مستوى الخدمة (SLA)، رغم إضاعة بعض الوقت قبل بدء الاستعادة على مستوى IP.

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

وإليك طريقة عمل المشغلات:

• يقوم تأخير نقطة البيع بتشغيل السطر n بأمر إيقاف تشغيل LOS/LOF/AIS ل n ms قبل أن يقوم الأمر بتشغيل الخط إلى أسفل. القيمة الافتراضية هي 100 مللي ثانية. يمكنك إستخدام هذا الأمر على أي واجهة ليس APs POS. لا يسمح أمر تأخير نقطة البيع بتشغيل السطر n بانتقال الخط إلى الأسفل على نقطة الوصول (LOS) الوجيزة التي تأتي من معدات DWDM المحمية داخليا، من وقت حدوث محول حماية DWDM داخلي. إذا انقشع العيب خلال الفترة المقلولة كأن العيب لم يحدث.

• سيقوم أمر تأخير نقطة البيع بتشغيل السطر بإيقاف أي إجراء يستند إلى العيب (باستثناء زيادة العداد المعيب)، حتى تنتهي فترة التسليم المحددة.

  إذا لم تقم بتمكين هذا الأمر، سيتم تشغيل نقاط الوصول (AP) والربط لأسفل فورا في بروتوكول RP.

نشر مشغلات SONET

يصف هذا القسم نشر مشغلات SONET.

شبكة SONET المحمية: لا توجد نقاط وصول (AP) على الموجهات

الشكل 1 - شبكة SONET المحمية داخليا

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

لاتخاذ هذا القرار، عليك فهم التكلفة المرتبطة بكل من النهجين. كمشغل شبكة، يجب عليك مراعاة الأسئلة التالية:

• هل تتلاقى الشبكة بسرعة كافية؟ وإن لم يكن الأمر كذلك فإن هذا النهج غير مناسب.

• ما هو تأثير التوجيه حول مثل هذا الفشل؟ هل هو التأثير الكبير على الموجه حتى ينخفض الأداء إلى أقل من مستوى مقبول؟

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

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

شبكة SONET غير المحمية داخليا

الشكل 2 - شبكة SONET غير المحمية داخليا

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

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

شبكة SONET محمية أو غير محمية

الشكل 3 - شبكة SONET غير المحمية داخليا

في برنامج Cisco IOS الإصدار 12.0(28)S، يمكنك تمكين مشغلات المسار على دارات APs. عندما تقوم بنشر نقاط الوصول على الموجهات المحلية أو البعيدة، يتسبب محول APs في أن ترى الموجهات التي تعمل عن بعد وتحميها عيبا في مستوى المسار الموجز. مع قيمة زناد صغيرة تنزل القارن، هذا حالة غير مرغوب. تقوم الواجهة التي تنتقل بتأخير عملية إستعادة الخدمة قيد التقدم بالفعل. كما يمكن أن يؤدي الفشل المؤقت الذي يحدث داخل السحابة إلى تأخير إستعادة الخدمة. ومع ذلك، يشير حدوث خطأ مستمر في مستوى المسار إلى أن حماية الدائرة (إما داخل الشبكة أو في الطرف البعيد) لم تتمكن من إستعادة الاتصال. في هذه الحالة، يجب أن تتخذ موجهات نقاط الوصول (AP) إجراء، وأن تبدأ إعادة تقارب التوجيه. يمكنك تكوين قيم تأخير مشغل المسار >= 100 مللي ثانية. مع هذا التكوين، عند حدوث خطأ متواصل إما داخل شبكة SONET أو في الطرف البعيد، تقوم الموجهات بجلب كلا واجهات APs إلى حالة إرتباط لأسفل. وبالتالي، تقوم الموجهات ببدء إعادة التوجيه واستعادة الخدمة بشكل أسرع.

شبكة DWDM محمية

الشكل 4 - شبكة DWDM المحمية

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

مرة أخرى، نظرا لأن شبكة DWDM محمية داخليا، يتسبب حدوث فشل داخلي في الشبكة في حدوث عملية الاستعادة قريبا. عادة ما يرى الموجه مجموعة مختصرة جدا من أخطاء LOS أو LOF أو مجموعة من أخطاء BIP.

لذلك، تحتاج فقط إلى تحديد ما إذا كان القيد مرغوبا في هذه الشبكة.

تأخير نقطة البيع يشغل السطر أمر كافي في هذه الحالة، إن أخترت تأخير.

شبكة DWDM غير محمية

الشكل 5 - شبكة DWDM غير محمية

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

إذا كنت تتطلب بعض التسليم، فإن أمر تأخير نقطة البيع يشغل السطر يكون كافيا لتوفير هذه الوظيفة.

الموجهات المتصلة من الخلف إلى الخلف

الشكل 6 - الموجهات المتصلة من الخلف إلى الخلف

يجب أن يعمل موجهان متصلان من الخلف إلى الخلف بين واجهات POS كما هو الحال في السيناريو الأخير. يمكنك مشاهدة حالات الأعطال على أي من الموجهين على الفور، نظرا لعدم وجود معدات وسيطة تعمل على وحدات SONET الإضافية أو تنهي أي جزء من إشارة مستوى SONET.

ومن الحالات المثيرة للاهتمام أن R1 يرى نظام النقل الجوي من المستوى S-LOS، وأن R2 يرى كلا من RDI من المستوى L و P-RDI، حيث أن R1 هو معدات إنهاء الخط (LTE) ومعدات إنهاء المسار (PTE). ونظرا لأن L-RDI يرفض بشكل صريح أي إجراء ناتج يتم إتخاذه عند الاستلام، فإن R2 لا يسقط الواجهة كنتيجة لذلك. من المحتمل أن تؤدي هذه المشكلة إلى حالة تعطل فيها واجهة R1، ولكن واجهة R2 لا تزال تزيد حركة المرور وتعيدها. بطبيعة الحال، أي رسالة تنشيط من الطبقة 2 (مثل التحكم في إرتباط البيانات عالي المستوى (HDLC) توفر) أوقات وتعلن عن الارتباط لأسفل، عادة في 30 ثانية، بناء على المؤقتات التي تم تكوينها. مهما، يعجز عدد من المشغلين هذا طبقة 2 keepalives، ويستطيع لا يمنع هذا حالة. من أجل معالجة هذه المشكلة، يمكنك أخذ عدة طرق، وكل نهج يعالج هذا من منظور مختلف، كما هو موضح هنا:

• تشغيل مشغلات المسار—حيث إن P-RDI يجلب واجهة لأسفل مع تمكين مشغلات المسار، يمكنك إستخدام هذه الطريقة لإحداث إستجابة سريعة، وإسقاط الواجهة. النقطة المثيرة للاهتمام هي أن L-RDI يقنع p-RDI تحت التشغيل العادي طبقا ل GR-253. بما أن مشغلات POS تتم معالجتها عند مستوى الخلل، فإن المشغلات تتم معالجتها قبل تقنيع التنبيه، ولا تزال الواجهة تسقط وفقا لوقت التأخير الذي تم تكوينه.

• إتاحة طبقة 2 keepalives- يسبب هذا خيار القارن على R2 أن وقت انتهاء بعد 3 keepalives أن يفتقد. بشكل نموذجي، إجمالي 30 ثانية (3x10)، ولا توصي Cisco بشكل عام بهذا الخيار كأداة لضبط تقارب الارتباط السريع.

• قم بتمكين بروتوكول توجيه حالة الارتباط — عندما يتم إسقاط الواجهة على R1 بسبب S-LOS، يتم إرسال رسالة حالة الارتباط على الفور. وعلى الرغم من أنه لا يزال من الممكن تشغيل الواجهة على R2، فعندما يتم إستلام رسالة حالة الارتباط عبر المنطقة، يتم تشغيل SPF، ويزال الارتباط من المخطط لأن الارتباط يفشل في التحقق من الاتصال ثنائي الإتجاه. وهذا يمنع الشبكة من محاولة التوجيه عبر سيناريو التبسيط هذا.

إعلام عن بعد استنادا إلى جودة الإشارة

عند توصيل موجهين، إما من الخلف، أو عبر شبكة SONET، تغطي بنية OAM المقدمة كشف معظم سيناريوهات الفشل.

توجد بشكل نموذجي إعلامات محلية وإعلامات عن بعد. ومع ذلك، عندما يتجاوز عدد كبير من أخطاء BIP عتبة (SD أو SF أو B3-TCA)، لا يتم إرسال إعلام عن بعد للإشارة إلى حدوث هذه الحالة. لذلك، عند إستخدام حماية سريعة لإعادة التوجيه لتحويل أسماء البروتوكولات المتعددة (MPLS)، لا يوجد مشغل يقوم بتنشيط محول حماية فوري. تستمر حركة المرور في التحجيم إلى أن يتم فقد حركة مرور كافية للتسبب في فشل أي من رسائل keepalive للطبقة 2 على الارتباط أو علاقات الجوار بين أقران بروتوكول العبارة الداخلية (IGP). وفي بعض الأحيان لا يحدث هذا أبدا، ويستمر في إفساد حركة المرور.

لمعالجة هذا السيناريو، يقدم CSCec85117 الأمر pos action b3-ber prdi إلى بنية أمر POS و SONET.

يسمح هذا الأمر للمشغل بتكوين الواجهة لإرسال بروتوكول P-RDI عند تجاوز عتبة B3. يتيح لك هذا الخيار إمكانية مراقبة الارتباط من نهاية إلى نهاية بشكل مثالي، بغض النظر عن المخطط. إذا تم تمكين مسار تأخير نقطة البيع على الموجهات، فإن الأمر pos action b3-ber prdi ينشط الارتباط الذي ينقطع (والأمر المقابل fast reRoute (FRR) أو تحديث التوجيه). وهذا يتجنب تأثير الثقب الأسود على الروابط المتدهورة.

لتغيير حساسية هذا الإجراء، قم بضبط b3-tca كما هو موضح هنا:

router(config-if)# pos threshold b3-tca ?

القيمة المتوفرة هي المكون الأسي لحساب BER (على سبيل المثال، يحدد حد نقطة البيع B3-TCA 3 B3-TCA على أن يكون مكافئا لمعدل 1×10^-3).

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

• متجر المعلومات فائق السرعة من Telcordia
• الدعم التقني والمستندات - Cisco Systems

محفوظات المراجعة