تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يقدم هذا المستند نظرة عامة فنية على تجزئة الارتباط والتداخل (LFI) عبر اتصال ترحيل الإطارات إلى العمل البيني ل ATM (IWF) (كما هو محدد بواسطة منتدى ترحيل الإطارات أو إتفاقية FRF.8)، بالإضافة إلى نموذج تكوين لاستخدام LS1010 أو Catalyst 8500 كجهاز IWF في شبكة WAN. يستخدم LFI قدرات التجزئة المدمجة الخاصة بتضمين بروتوكول نقطة إلى نقطة متعدد الارتباطات (MLPPP) عبر ATM وترحيل الإطارات لتوفير تجزئة شاملة وحل تداخل للروابط المنخفضة السرعة بأطوال عريضة تصل إلى 768 كيلوبت/ثانية.
يتطلب هذا المستند فهم ما يلي:
بيئة FRF.8 النموذجية وأوضاع FRF.8 الشفافة وأوضاع الترجمة - راجع فهم الأوضاع الشفافة وأوضاع الترجمة باستخدام FRF.8.
إلمام بأوامر التكوين LS1010 و Catalyst 8500 وكيفية تنفيذ أي من مهايئ منفذ ترحيل الإطارات Channelized E1 Frame Relay أو مهايئ منفذ ترحيل الإطارات Channelized DS3 Frame Relay Port Adapter للعمل البيني بين نقطة نهاية ترحيل الإطارات ونقطة نهاية ATM.
تأخير وترنح التسلسل. راجع إرتباطات VoIP عبر PPP بجودة الخدمة (أولوية LLQ / IP RTP و LFI و cRTP) وVoIP عبر ترحيل الإطارات مع جودة الخدمة (التجزئة، وتنظيم حركة البيانات، أولوية IP RTP).
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.
التجزئة هي تقنية أساسية للتحكم في تأخير تسلسل وتباين التأخير على الروابط المنخفضة السرعة التي تحمل حركة مرور الوقت الحقيقي وحركة مرور غير الوقت. تأخير التسلسل هو التأخير الثابت المطلوب لتدقيق إطار الصوت أو البيانات على واجهة الشبكة، ويرتبط مباشرة بمعدل الساعة على خط الاتصال. تحتاج إلى علامة إضافية لفصل الإطارات من أجل سرعات ساعة منخفضة وحجم إطار صغير.
يستخدم LFI إمكانيات التجزئة المدمجة ل MLPPP لمنع التأخير والتشوه (الاختلافات في التأخير) الناتج عن وجود حزم كبيرة متغيرة الحجم يتم وضعها في قائمة الانتظار بين حزم الصوت الصغيرة نسبيا. باستخدام LFI، يتم تضمين الحزم الأكبر من حجم الجزء الذي تم تكوينه في رأس MLPPP. يحدد RFC 1990 رأس MLPPP وكذلك ما يلي:
(ب)يعد بت التجزئة حقل بت واحد يتم تعيينه على 1 على الجزء الأول المشتق من حزمة PPP ويتم تعيينه على 0 لجميع الأجزاء الأخرى من حزمة PPP نفسها.
(ه) يقصد ب NDING Gment Bit حقل بت واحد تم تعيينه على 1 في الجزء الأخير وتم تعيينه على 0 لجميع الأجزاء الأخرى.
حقل التسلسل هو رقم 24-بت أو 12-بت الذي يتم زيادته لكل جزء يتم إرساله. بشكل افتراضي، يكون حقل التسلسل طويل 24 وحدة بت، ولكن يمكن التفاوض عليه ليكون 12 وحدة بت فقط مع خيار تكوين بروتوكول LCP الموضح أدناه.
بالإضافة إلى التجزئة، يجب جدولة الحزم الحساسة للتأخير بأولوية كافية بين أجزاء الحزمة الكبيرة. باستخدام التجزئة، تصبح قوائم الانتظار العادلة والمقدرة (WFQ) "مدركة" لما إذا كانت الحزمة جزءا من جزء أو أنها غير مجزأة. يقوم WFQ بتعيين رقم تسلسلي لكل حزمة واردة ثم جدولة الحزم بناء على هذا الرقم.
يوفر تجزئة الطبقة الثانية حلا فائقا لجميع النهج الأخرى في حل "مشكلة الحزمة الكبيرة". يوضح الجدول التالي مزايا وعيوب الحلول المحتملة الأخرى.
حل محتمل | المزايا | مساوئ |
---|---|---|
أجهض إرسال الحزمة الكبيرة وأعد انتظارها خلف التأخير حركة المرور الحساسة. |
|
|
تجزئة الحزمة الكبيرة باستخدام تقنيات تجزئة طبقة الشبكة. |
|
|
تجزئة الحزمة باستخدام تقنيات طبقة الارتباط. |
|
|
يجب أن يسمح حجم الجزء المثالي لبروتوكول نقطة إلى نقطة متعدد الارتباطات عبر ATM (MLPPPoATM) بملائمة الأجزاء في عدد محدد من خلايا ATM. راجع تجزئة الارتباط والتداخل لترحيل الإطارات ودائرة ATM الظاهرية للحصول على إرشادات حول تحديد قيم التجزئة.
يتكون تكوين نموذجي ل FRF.8 مما يلي:
نقطة نهاية ترحيل الإطارات
نقطة نهاية ATM
جهاز العمل البيني (IWF)
تقوم كل نقطة نهاية بتضمين البيانات والحزم الصوتية في رأس عملية كبسلة الطبقة 2، والتي تتصل بالبروتوكول المغلف والمنقول في الإطار أو الخلية. كلا من ترحيل الإطارات و ATM دعم معرف بروتوكول طبقة الشبكة (NLPID) الخاص بعملية التضمين. تحدد وثيقة ISO/International Electrotechnical Commission (IEC) TR 9577 قيم NLPID المعروفة لعدد محدد من البروتوكولات. يتم تعيين قيمة 0xCF إلى PPP.
يحدد RFC 1973 PPP في ترحيل الإطارات ورأس MLPPPoFR، بينما يحدد RFC 2364 PPP عبر AAL5 ورأس MLPPPoA. يستخدم كلا الرأسين قيمة NLPID الخاصة ب 0xCF لتعريف PPP كبروتوكول يغلف.
ويتم توضيح كل رأس من هذه الرؤوس في الشكل 1 أدناه.
شكل 1. PPP عبر رأس AAL5، رأس MLPPPoA مع تضمين NLPID، ورأس MLPPPoA مع تجميع VC
ملاحظة: يتضمن رأس MLPPPoFR أيضا حقل علامة مكون من بايت واحد بحجم 0x7e، والذي لا يظهر في الشكل 1. بعد الرؤوس، تبدأ البايت رقم 5 في حقول بروتوكول ppp أو MLPPP.
الجدول 1 - شفاف FRF.8 مقابل FRF.8 مترجم.
شكل 2. كيفية تجزئة حزمة MLPPPoATM باستخدام NLPID.
شكل 3. كيفية تجزئة حزمة MLPPPoATM باستخدام تجميع VC.
يتم عرض معنى قيم البايت أدناه:
0xFEFE - يحدد نقاط الوصول إلى الخدمة المصدر والوجهة (SAPs) في رأس عنصر التحكم في الارتباط المنطقي (LLC). تشير قيمة 0xFEFE إلى أن ما يلي هو رأس NLPID قصير النموذج، والذي يتم إستخدامه مع البروتوكولات التي تحتوي على قيمة NLPID معرفة.
0x03 - حقل التحكم المستخدم مع العديد من عمليات التضمين، بما في ذلك التحكم في إرتباط البيانات عالي المستوى (HDLC). يشير أيضا إلى أن محتويات الحزمة تتألف من معلومات غير مرقمة.
0xCF - قيمة NLPID معروفة جيدا ل PPP.
تحدد إتفاقية FRF.8 وضعين للتشغيل لجهاز IWF:
شفاف - يقوم جهاز IWF بإعادة توجيه رؤوس التضمين دون تغيير. ولا يقوم بأي تخطيط أو تجزئة أو إعادة تجميع لرأس البروتوكول.
الترجمة - يقوم جهاز IWF بتنفيذ تخطيط رأس البروتوكول بين رأسي التضمين لحساب الفروق الصغيرة بين أنواع التضمين.
يؤدي الوضع الذي تم تكوينه على جهاز IWF، والذي يمكن أن يكون محول مجمع Cisco ATM أو موجه من السلسلة 7200 مع مهايئ منفذ PA-A3 ATM، إلى تغيير عدد وحدات بايت رؤوس الطبقة 2 على أجزاء ATM وترحيل الإطارات من إرتباط العمل البيني. لنلقي نظرة على هذه النفقات العامة بمزيد من التفاصيل.
يوضح الجدولان التاليان وحدات البايت الإضافية لحزم البيانات وحزم نقل الصوت عبر IP (VoIP).
الجدول 2 - نقل البيانات بالبايت لحزمة بيانات عبر إرتباط FRF.8.
وضع FRF.8 | شفاف | ترجمة | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
إتجاه حركة المرور | ترحيل الإطارات إلى ATM | ATM إلى ترحيل الإطارات | ترحيل الإطارات إلى ATM | ATM إلى ترحيل الإطارات | |||||||||
ترحيل الإطارات أو رجل ATM ل PVC | ترحيل الإطارات Frame Relay | ATM | ATM | ترحيل الإطارات Frame Relay | ترحيل الإطارات Frame Relay | ATM | ATM | ترحيل الإطارات Frame Relay | |||||
علامة إطار (0x7e) | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | |||||
رأس ترحيل الإطارات | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | |||||
LLC DSAP/SSAP (0xfefe) | 0 | 0 | 2 | 2 | 0 | 2 | 2 | 0 | |||||
التحكم في LLC (0x03) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||
NLPID (0xcf ل PPP) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||
معرف بروتوكول MLP (0x003d) | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | |||||
رقم تسلسل MLP | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | |||||
معرف بروتوكول PPP (الإطار الأول فقط) | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | |||||
الحمولة (الطبقة 3+) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |||||
طبقة ملاءمة ATM (AAL) 5 | 0 | 8 | 8 | 0 | 0 | 8 | 8 | 0 | |||||
تسلسل التحقق من الإطارات (FCS) | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | |||||
إجمالي المصروفات العامة (بالبايت) | 15 | 18 | 20 | 17 | 15 | 20 | 20 | 15 |
الجدول 3 - تكدس إرتباط البيانات بالبايت لحزمة VoIP عبر إرتباط FRF.8.
وضع FRF.8 | شفاف | ترجمة | ترحيل الإطارات إلى ترحيل الإطارات | ||||||
---|---|---|---|---|---|---|---|---|---|
إتجاه حركة المرور | ترحيل الإطارات إلى ATM | ATM إلى ترحيل الإطارات | ترحيل الإطارات إلى ATM | ATM إلى ترحيل الإطارات | |||||
ترحيل الإطارات أو رجل ATM ل PVC | ترحيل الإطارات Frame Relay | ATM | ATM | ترحيل الإطارات Frame Relay | ترحيل الإطارات Frame Relay | ATM | ATM | ترحيل الإطارات Frame Relay | |
علامة إطار (0x7e) | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
رأس ترحيل الإطارات | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | 2 |
LLC DSAP/SSAP (0xfefe) | 0 | 0 | 2 | 2 | 0 | 2 | 2 | 0 | 0 |
التحكم في LLC (0x03) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
NLPID (0xcf ل PPP) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
معرف PPP | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 0 |
الحمولة (بروتوكول مخطط بيانات IP+المستخدم (UDP)+RTP+Voice) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
AAL5 | 0 | 8 | 8 | 0 | 0 | 8 | 8 | 0 | 0 |
FCS | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | 2 |
إجمالي المصروفات العامة (بالبايت) | 9 | 12 | 14 | 11 | 9 | 14 | 14 | 9 | 7 |
عند مراجعة الجداول الواردة أعلاه، لاحظ ما يلي:
يتم تضمين الحزم الأصغر من حجم التجزئة المحدد فقط في رأس PPP وليس في رأس MLPPP. وبالمثل، يتم تضمين الحزم الأكبر من حجم التجزئة المحدد في كل من رأس PPP ورأس MLPPP. وبالتالي، تقل نفقات حزم نقل الصوت عبر بروتوكول الإنترنت (VoIP) عن النفقات العامة بما يصل إلى ثمانية بايت.
يتضمن الجزء الأول فقط من بروتوكول PPP متعدد الارتباطات (MLP) حقل معرف بروتوكول PPP. وهكذا، يحمل الجزء الاول نوعين اضافيين من المصاريف العامة.
في الوضع الشفاف، يتم تمرير رؤوس التضمين بدون تغيير من خلال جهاز IWF. وهكذا تختلف النفقات في كل إتجاه وفي كل جزء. وعلى وجه الخصوص، يبدأ رأس MLPPPoA برأس NLPID قصير الشكل من 0xFEFE. في الوضع الشفاف، يتم تمرير هذا الرأس بدون تغيير بواسطة جهاز IWF من مقطع ATM إلى مقطع ترحيل الإطارات. ومع ذلك، في إتجاه ترحيل الإطارات إلى ATM، لا يوجد مثل هذا الرأس في الوضع الشفاف على أي من المقاطع.
في وضع الترجمة، يغير جهاز IWF رؤوس التضمين. وهكذا تكون النفقات العامة هي نفسها على كل جزء في الاتجاهين. وعلى وجه الخصوص، في ATM إلى إتجاه ترحيل الإطارات، تتضمن نقطة نهاية ATM الحزمة في رأس MLPPPoA. يزيل جهاز IWF رأس NLPID قبل تمرير الإطار المتبقي إلى مقطع ترحيل الإطارات. في إتجاه ترحيل الإطارات إلى ATM، يعالج جهاز IWF الإطار مرة أخرى ويضع مسبقا رأس NLPID قبل تمرير الإطار المجزأ إلى نقطة نهاية ATM.
عند تصميم إرتباطات FRF باستخدام MLP، تأكد من حساب عدد وحدات البايت الإضافية الخاصة بارتباط البيانات الصحيح. وتؤثر مثل هذه التكاليف الإضافية على كمية النطاق الترددي الذي يستهلكه كل مكالمة هاتفية عبر بروتوكول الإنترنت (VoIP). كما يلعب دورا في تحديد الحجم الأمثل لأجزاء بروتوكول MLP. يعتبر تحسين حجم الجزء ليلائم عددا متكاملا من خلايا ATM أمرا بالغ الأهمية، لا سيما على أجهزة PVCs بطيئة السرعة حيث يمكن إهدار قدر كبير من النطاق الترددي على إضافة الخلية الأخيرة إلى مضاعف حتى يبلغ 48 بايت.
لأغراض الوضوح، دعنا نسير عبر خطوات عملية تضمين الحزمة عندما يذهب ربط في ترحيل الإطارات إلى ATM الإتجاه مع وضع شفاف:
تتضمن نقطة نهاية ترحيل الإطارات الحزمة في رأس MLPPPoFR.
يزيل جهاز IWF رأس ترحيل الإطارات ثنائي البايت باستخدام معرف اتصال إرتباط البيانات (DLCI). ثم يقوم بإعادة توجيه الحزمة المتبقية إلى واجهة ATM الخاصة ب IWF، والتي تقوم بتقسيم الحزمة إلى خلايا وإعادة توجيهها عبر مقطع ATM.
تفحص نقطة نهاية ATM رأس الحزمة المستلمة. إذا كانت أول وحدتي بايت من الحزمة المستلمة هما 0x03CF، فإن نقطة نهاية ATM تعتبر الحزمة حزمة MLPPPoA صالحة.
تعمل وظائف MLPPP على نقطة نهاية ATM على إجراء مزيد من المعالجة.
نظرت في الربط عملية كبسلة عندما يذهب ربط في ال ATM إلى ال إطار ترحيل إتجاه مع أسلوب شفاف:
تتضمن نقطة نهاية ATM الحزمة في رأس MLPPPoA. ثم يقسم الحزم إلى خلايا ويعيد توجيههم خارج مقطع ATM.
يستقبل IWF الحزمة، ويعيد توجيهها إلى واجهة ترحيل الإطارات الخاصة بها، ويسبق رأس ترحيل الإطارات ثنائي البايت.
تفحص نقطة نهاية ترحيل الإطارات رأس الحزمة المستلمة. إذا كانت وحدات البايت الأربع الأولى بعد رأس ترحيل الإطارات ثنائي البايت هي 0xfefe03cf، فإن IWF يتعامل مع الحزمة كحزمة MLPPPoFR قانونية.
تعمل وظائف MLPPP على نقطة نهاية ترحيل الإطارات على إجراء مزيد من المعالجة.
توضح الصور التوضيحية التالية تنسيق حزم MLPPPoA و MLPPPoFR.
شكل 6. مصروفات MLPPPoA. يحمل الجزء الأول فقط رأس PPP.
شكل 7. حمولة MLPPPoFR الإضافية. يحمل الجزء الأول فقط رأس PPP.
عند توفير النطاق الترددي لنقل البيانات عبر بروتوكول الإنترنت (VoIP)، يجب تضمين النفقات الإضافية لارتباط البيانات في حسابات النطاق الترددي العريض. يوضح الجدول 4 متطلبات النطاق الترددي لكل مكالمة خاصة ب VoIP حسب برنامج الترميز واستخدام بروتوكول نقل الوقت الفعلي المضغوط (RTP). تفترض العمليات الحسابية في الجدول 4 سيناريو أفضل حالة لضغط رأس RTP (cRTP)، وبعبارة أخرى، لا يوجد المجموع الاختباري ل UDP أو أخطاء الإرسال. ثم يتم ضغط الرؤوس بشكل مستمر من 40 بايت إلى 2 بايت.
الجدول 4 - متطلبات النطاق الترددي لكل مكالمة عبر بروتوكول الإنترنت (VoIP).
وضع FRF.8 | شفاف | ترجمة | ترحيل الإطارات إلى ترحيل الإطارات | ||||||
---|---|---|---|---|---|---|---|---|---|
إتجاه حركة المرور | ترحيل الإطارات إلى ATM | ATM إلى ترحيل الإطارات | ترحيل الإطارات إلى ATM | ATM إلى ترحيل الإطارات | |||||
ترحيل الإطارات أو رجل ATM ل PVC | ترحيل الإطارات Frame Relay | ATM | ATM | ترحيل الإطارات Frame Relay | ترحيل الإطارات Frame Relay | ATM | ATM | ترحيل الإطارات Frame Relay | |
G729 - 20 مللي ثانية عينة - لا يوجد cRTP | 27.6 | 42.4 | 42.4 | 28.4 | 27.6 | 42.4 | 42.4 | 27.6 | 26.8 |
G729 - 20 مللي ثانية عينة - cRTP | 12.4 | 21.2 | 21.2 | 13.2 | 12.4 | 21.2 | 21.2 | 12.4 | 11.6 |
G729 - 30 مللي ثانية عينة - لا يوجد cRTP | 20.9 | 28.0 | 28.0 | 21.4 | 20.9 | 28.0 | 28.0 | 20.9 | 20.3 |
G729 - 30 مللي ثانية عينات - cRTP | 10.8 | 14.0 | 14.0 | 11.4 | 10.8 | 14.0 | 14.0 | 10.8 | 10.3 |
G711 - 20 مللي ثانية عينة - لا يوجد cRTP | 83.6 | 106.0 | 106.0 | 84.4 | 83.6 | 106.0 | 106.0 | 83.6 | 82.8 |
G711 - 20 مللي ثانية عينة - cRTP | 68.4 | 84.8 | 84.8 | 69.2 | 68.4 | 84.8 | 84.8 | 68.4 | 67.6 |
G711 - 30 مللي ثانية عينة - لا يوجد cRTP | 76.3 | 97.9 | 97.9 | 76.8 | 76.3 | 97.9 | 97.9 | 76.3 | 75.8 |
G711 - عينات 30 مللي ثانية - cRTP | 66.3 | 84.0 | 84.0 | 66.8 | 66.3 | 84.0 | 84.0 | 66.3 | 65.7 |
وبما ان النفعية تتباين على كل ساق من ال PVC، نوصي بالتصميم لسيناريو اسوإ الحالات. على سبيل المثال، تذكر حالة إستدعاء G.279 مع أخذ عينات 20 ميجاثانية و cRTP عبر PVC شفاف. في مرحلة ترحيل الإطارات، يكون متطلبات النطاق الترددي 12.4 كيلوبت/ثانية في إتجاه واحد و 13.2 كيلوبت/ثانية في الإتجاه الآخر. وبالتالي، نوصي بالإمداد استنادا إلى 3.2 كيلوبت في الثانية لكل مكالمة.
لأغراض المقارنة، يعرض الجدول أيضا متطلبات النطاق الترددي العريض لبروتوكول VoIP على PVC شامل لترحيل الإطارات تم تكوينه باستخدام تجزئة FRF.12. وكما تمت الإشارة في الجدول، يستهلك بروتوكول الاتصال من نقطة إلى نقطة (PPP) ما بين 0.5 كيلوبت/ثانية و 0.8 كيلوبت/ثانية من النطاق الترددي الإضافي لكل مكالمة لدعم وحدات بايت رؤوس التضمين الإضافية. وبالتالي، نوصي باستخدام FRF.12 مع شبكات VC لترحيل الإطارات من نهاية إلى نهاية.
يتطلب RTP (cRTP) المضغوط عبر ATM برنامج Cisco IOS® الإصدار 12.2(2)T. عند تمكين cRTP مع MLPoFR و MLPoATM، يتم تمكين ضغط رأس TCP/IP تلقائيا ولا يمكن تعطيله. ينتج هذا التقييد من RFC 2509، والذي لا يسمح بتفاوض PPP لضغط رأس RTP بدون التفاوض أيضا على ضغط رأس TCP.
في الأصل، تطلبت LFI أن تستخدم أجهزة IWF الوضع الشفاف. وفي وقت أحدث، قدم منتدى ترحيل الإطارات FRF.8.1 لدعم وضع الترجمة. قدمت Cisco دعم FRF.8.1 ووضع الترجمة في الإصدارات التالية من برنامج Cisco IOS Software:
12.0(18)W5(23) للسلسلة LS1010 و Catalyst 8500 مع 4CE1 FR-PAM (CSCdt39211)
12.2(3)T و 12.2(2) على موجهات Cisco IOS مع واجهات ATM، مثل PA-A3 (CSCdt70724)
لا يدعم بعض موفري الخدمة بعد ترجمة PPP على أجهزة FRF.8 الخاصة بهم. عندما يكون هذا هو الحالة، يجب أن يشكل الموفر PVCs الخاصة بهم للوضع الشفاف.
يستخدم هذا التكوين الأجهزة والبرامج التالية:
نقطة نهاية ATM - PA-A3-OC3 في موجه من السلسلة 7200 يشغل برنامج Cisco IOS الإصدار 12.2(8)T. (ملاحظة: LFI مدعوم على PA-A3-OC3 و PA-A3-T3 فقط. لا يتم دعمه على مهايئات المنفذ IMA و ATM OC-12.)
جهاز IWF - LS1010 مع وحدة مهايئ Channelized T3 Port Adapter Module وبرنامج Cisco IOS الإصدار 12.1(8)EY.
نقطة نهاية ترحيل الإطارات - PA-MC-T3 في موجه من السلسلة 7200 يشغل برنامج Cisco IOS الإصدار 12.2(8)T.
يوضح هذا القسم كيفية تكوين ميزة LFI عبر إرتباط FRF.8 في الوضع الشفاف. وهو يستخدم قالبا ظاهريا على نقطتي نهاية الموجهات، والتي يتم من خلالها نسخ واجهة الوصول الظاهرية الخاصة بحزمة MLP. يدعم LFI واجهات المتصل والقوالب الظاهرية لتحديد معلمات طبقة البروتوكول الخاصة ب MLPPP. يزيد الإصدار 12.2(8)T من برنامج Cisco IOS Software عدد القوالب الظاهرية الفريدة التي يمكن تكوينها لكل موجه إلى 200. تدعم الإصدارات السابقة ما يصل إلى 25 قوالب افتراضية فقط لكل موجه. يمكن أن يكون هذا التحديد مشكلة قياس على موجه توزيع ATM إذا كان كل PVC مطلوبا أن يكون له عنوان IP فريد. كحل بديل، أستخدم IP كقوالب غير مرقمة أو استبدل القوالب الظاهرية بواجهات المتصل على الروابط المرقمة.
قدم Cisco IOS الإصدار 12.1(5)T دعم LFI عبر إرتباط عضو واحد فقط لكل حزمة MLPPP. وبالتالي، يستخدم هذا التكوين معرف فئة مورد (VC) واحد فقط عند كل نقطة نهاية. يخطط دعم ل يتعدد VCs لكل حزمة لإصدار قادم من cisco ios.
نقطة نهاية ترحيل الإطارات |
---|
|
تكوين LS1010 |
---|
|
نقطة نهاية ATM |
---|
|
أستخدم الأوامر التالية على نقطة نهاية ATM لتأكيد عمل LFI بشكل صحيح. قبل إصدار أوامر تصحيح الأخطاء، يرجى الاطلاع على المعلومات المهمة في أوامر تصحيح الأخطاء.
show ppp multilink - يستخدم LFI واجهتي وصول ظاهري — واحدة ل PPP وواحدة لحزمة MLP. أستخدم show ppp متعدد الارتباطات للتمييز بين الاثنين.
ATMside#show ppp multilink Virtual-Access2, bundle name is FRAMEside !--- The bundle interface is assigned to VA 2. Bundle up for 01:11:55 Bundle is Distributed 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x1E received sequence, 0xA sent sequence Member links: 1 (max not set, min not set) Virtual-Access1, since 01:11:55, last rcvd seq 00001D 187 weight !--- The PPP interface is assigned to VA 1.
show interface virtual-access 1 - تأكد من أن واجهة الوصول الظاهري قيد التشغيل/لأعلى وتزيد من عدادات حزم الإدخال والإخراج.
ATMside#show int virtual-access 1 Virtual-Access1 is up, line protocol is up Hardware is Virtual Access interface Internet address is 1.1.1.1/24 MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 5 seconds on reset LCP Open, multilink Open Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 Cloned from virtual-template: 1 Last input 01:11:30, output never, output hang never Last clearing of "show interface" counters 2w1d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 878 packets input, 13094 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 255073 packets output, 6624300 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
show policy-map int virtual-access 2 - تأكد من إرتباط سياسة خدمة QoS بواجهة حزمة MLPPP.
ATMside#show policy-map int virtual-access 2 Virtual-Access2 Service-policy output: example queue stats for all priority classes: queue size 0, queue limit 27 packets output 0, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 Class-map: call-control (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 103 queue size 0, queue limit 3 packets output 0, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 Bandwidth: 10%, kbps 15 Class-map: voice (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip rtp 16384 16383 Priority: kbps 110, burst bytes 4470, b/w exceed drops: 0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any queue size 0, queue limit 5 packets output 0, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 Fair-queue: per-flow queue limit 2
debug ppp packet و debug atm packet - أستخدم هذه الأوامر إذا كانت جميع الواجهات up/up، ولكن لا يمكنك إختبار الاتصال من نهاية إلى نهاية. وبالإضافة إلى ذلك، يمكنك إستخدام هذه الأوامر لالتقاط رسائل تنشيط بروتوكول الاتصال من نقطة إلى نقطة (PPP)، كما هو موضح أدناه.
2w1d: Vi1 LCP-FS: I ECHOREQ [Open] id 31 len 12 magic 0x52FE6F51 2w1d: ATM1/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03 Length:0x16 2w1d: CFC0 210A 1F00 0CB1 2342 E300 0532 953F 2w1d: 2w1d: Vi1 LCP-FS: O ECHOREP [Open] id 31 len 12 magic 0xB12342E3 !--- This side received an Echo Request and responded with an outbound Echo Reply. 2w1d: Vi1 LCP: O ECHOREQ [Open] id 32 len 12 magic 0xB12342E3 2w1d: ATM1/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03 Length:0x16 2w1d: CFC0 2109 2000 0CB1 2342 E300 049A A915 2w1d: Vi1 LCP-FS: I ECHOREP [Open] id 32 len 12 magic 0x52FE6F51 2w1d: Vi1 LCP-FS: Received id 32, sent id 32, line up !--- This side transmitted an Echo Request and received an inbound Echo Reply.
أستخدم الأوامر التالية على نقطة نهاية ترحيل الإطارات لتأكيد عمل LFI بشكل صحيح. قبل إصدار أوامر تصحيح الأخطاء، يرجى الاطلاع على المعلومات المهمة في أوامر تصحيح الأخطاء.
show ppp multilink - يستخدم LFI واجهتي وصول ظاهري — واحدة ل PPP وواحدة لحزمة MLP. أستخدم show ppp متعدد الارتباطات للتمييز بين الاثنين.
FRAMEside#show ppp multilink Virtual-Access2, bundle name is ATMside Bundle up for 01:15:16 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x19 received sequence, 0x4B sent sequence Member links: 1 (max not set, min not set) Virtual-Access1, since 01:15:16, last rcvd seq 000018 59464 weight
show policy-map interface virtual-access - تأكد من إرتباط سياسة خدمة QoS بواجهة حزمة MLPPP.
FRAMEside#show policy-map int virtual-access 2 Virtual-Access2 Service-policy output: example Class-map: voice (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip rtp 16384 16383 Weighted Fair Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 110 (kbps) Burst 2750 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: class-default (match-any) 27 packets, 2578 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Weighted Fair Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/0/0
debug frame packet و debug ppp packet - أستخدم هذه الأوامر إذا كانت جميع الواجهات up/up، ولكن لا يمكنك إختبار الاتصال من نهاية إلى نهاية.
FRAMEside#debug frame packet Frame Relay packet debugging is on FRAMEside# FRAMEside#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms FRAMEside# 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52
تقوم MLPPPoA و MLPPPoFR باستنساخ واجهتي وصول ظاهري من واجهة المتصل أو القالب الظاهري. يمثل واحد من هذا قارن ال PPP خطوة، والآخر يمثل ال MLP حزمة قارن. أستخدم الأمر show ppp multilink لتحديد الواجهة المحددة المستخدمة لكل وظيفة. حتى هذه الكتابة، يتم دعم VC واحد فقط لكل حزمة، وبالتالي يجب أن تظهر واجهة وصول ظاهري واحدة فقط في قائمة أعضاء الحزمة في إخراج show ppp multilink.
بالإضافة إلى واجهتي الوصول الظاهري، يتم إقران كل PVC بواجهة رئيسية وواجهة فرعية. توفر كل واجهة من هذه الواجهات شكلا ما من قوائم الانتظار. ومع ذلك، فإن واجهة الوصول الظاهري التي تمثل واجهة الحزمة فقط هي التي تدعم قوائم انتظار الترحال عبر سياسة خدمة جودة الخدمة المطبقة. يجب أن تحتوي الواجهات الثلاث الأخرى على قوائم انتظار FIFO. عند تطبيق سياسة خدمة على قالب ظاهري، يعرض الموجه الرسالة التالية:
cr7200(config)#interface virtual-template 1 cr7200(config)#service-policy output Gromit Class Base Weighted Fair Queueing not supported on interface Virtual-Access1
ملاحظة: قوائم الانتظار العادلة والمقدرة المعتمدة على الفئة مدعومة على واجهة حزمة MLPPP فقط.
هذه الرسائل عادية. الرسالة الأولى هي التنويه بأن سياسة الخدمة غير مدعومة على واجهة الوصول الظاهري ل PPP. وتؤكد الرسالة الثانية أن سياسة الخدمة يتم تطبيقها على واجهة الوصول الظاهري لحزمة MLP. لتأكيد آلية قوائم الانتظار على واجهة حزمة MLP، أستخدم الأوامر show interface virtual-access، وshow queue virtual-access، وshow policy-map interface virtual-access.
يتطلب MLPPPoFR تمكين تنظيم حركة بيانات ترحيل الإطارات (FRTS) على الواجهة المادية. يقوم FRTS بتنشيط قوائم الانتظار لكل عنصر افتراضي. على الأنظمة الأساسية مثل 7200 و 3600 و 2600 Series، يتم تكوين FRTS باستخدام الأمرين التاليين:
تنظيم حركة بيانات ترحيل الإطارات على الواجهة الرئيسية
فئة الخريطة باستخدام أي أوامر تشكيل.
تقوم الإصدارات الحالية من Cisco IOS بطباعة رسالة التحذير التالية إذا تم تطبيق MLPoFR بدون FRTS.
"MLPoFR not configured properly on Link x Bundle y"
إذا ظهرت لك رسالة التحذير هذه، فتأكد من تكوين FRTS على الواجهة المادية ومن إرفاق سياسة خدمة جودة الخدمة بالقالب الظاهري. للتحقق من التكوين، أستخدم الواجهة التسلسلية show running-config وأمر show running-config virtual-template. عند تكوين MLPPPoFR، تتغير آلية قوائم انتظار الواجهة إلى FIFO مزدوج، كما هو موضح أدناه. تقوم قائمة الانتظار عالية الأولوية بمعالجة الحزم الصوتية وحزم التحكم، مثل واجهة الإدارة المحلية (LMI)، وتقوم قائمة الانتظار منخفضة الأولوية بمعالجة الحزم المجزأة، والتي يفترض أنها حزم بيانات أو حزم غير صوتية.
Router#show int serial 6/0:0 Serial6/0:0 is up, line protocol is down Hardware is Multichannel T1 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, crc 16, Data non-inverted Keepalive set (10 sec) LMI enq sent 236, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down LMI enq recvd 353, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 Last input 00:00:02, output 00:00:02, output hang never Last clearing of "show interface" counters 00:39:22 Queueing strategy: dual fifo Output queue: high size/max/dropped 0/256/0 !--- high-priority queue Output queue 0/128, 0 drops; input queue 0/75, 0 drops !--- low-priority queue 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 353 packets input, 4628 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 353 packets output, 4628 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions no alarm present Timeslot(s) Used:12, subrate: 64Kb/s, transmit delay is 0 flags
يستخدم LFI طبقتين من قوائم الانتظار — مستوى حزمة MLPPP، الذي يدعم قوائم انتظار الترجيح، ومستوى PVC، الذي يدعم قوائم انتظار FIFO فقط. تحافظ واجهة الحزمة على قائمة الانتظار الخاصة بها. تمر جميع حزم MLP من خلال حزمة MLP وطبقات الوصول الظاهري أولا قبل ترحيل الإطارات أو طبقة ATM. يراقب LFI حجم قوائم انتظار الأجهزة الخاصة بالارتباطات الأعضاء وحزم إلغاء قوائم الانتظار إلى قوائم انتظار الأجهزة عندما تقع أسفل عتبة، والتي كانت في الأصل قيمة مقدارها إثنان. وإلا، يتم وضع الحزم في قائمة انتظار حزمة MLP.
يسرد الجدول التالي المشاكل المعروفة مع LFI عبر إرتباطات FRF ويركز على خطوات أستكشاف الأخطاء وإصلاحها التي يجب إتخاذها لعزل الأعراض الخاصة بك إلى خطأ تم حله.
العرض | خطوات أستكشاف الأخطاء وإصلاحها | الأخطاء التي تم حلها |
---|---|---|
معدل إخراج منخفض في ساق ATM أو ساق ترحيل الإطارات |
|
CSCdt59038 - مع تعيين الحزم ذات 1500 بايت والتجزئة على 100 بايت، هناك 15 حزمة مجزأة. حدث هذا التأخير بسبب مستويات متعددة من قوائم الانتظار. CSCdu18344 - مع FRTS، يتم إلغاء قوائم الانتظار للحزم بشكل أبطأ من المتوقع. تقوم دالة إلغاء قائمة الانتظار لمجموعة MLPPP بالتحقق من حجم قائمة الانتظار الخاصة بقائمة انتظار متتبع حركة المرور. كان FRTS بطيئا جدا في مسح قائمة الانتظار هذه. |
الحزم الخارجة عن الترتيب |
|
CSCdv89201 - عندما تكون واجهة ATM المادية مزدحمة، يتم إسقاط أجزاء MLP أو استقبالها خارج الترتيب في الطرف البعيد. تؤثر هذه المشكلة على الوحدات النمطية لشبكة ATM فقط على السلسلة 2600 و 3600. وهو ينتج عن كيفية تحويل برنامج تشغيل الواجهة الحزم بشكل غير صحيح في المسار السريع (مثل التحويل السريع أو إعادة التوجيه السريع من Cisco). وعلى وجه الخصوص، تم إرسال الجزء الثاني من الحزمة الحالية بعد الجزء الأول من الحزمة التالية |
فقد الاتصال الشامل عند تنفيذ السلسلة 3600 لبروتوكول iWF في وضع شفاف |
|
CSCdw11409 - يضمن أن CEF يبحث في مكان البايت الصحيح لبدء معالجة رؤوس التضمين من حزم MLPPP |
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
28-May-2002 |
الإصدار الأولي |