يقدم هذا المستند نموذجا لتكوين حركة بيانات ترحيل الإطارات.
لا توجد متطلبات أساسية خاصة لهذا المستند.
تم دعم تنظيم حركة بيانات ترحيل الإطارات منذ برنامج Cisco IOS® الإصدار 11.2.
وهو مدعوم على موجهات Cisco 7200 والأنظمة الأساسية الدنيا. يتم دعم تنظيم حركة البيانات الموزعة على موجهات Cisco 7500 والموجهات 7600 والوحدة النمطية FlexWAN.
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، راجع اصطلاحات تلميحات Cisco التقنية.
عمليات التنفيذ الشائعة لتنظيم حركة بيانات ترحيل الإطارات هي:
السرعة العالية إلى عدم توافق الدوائر المنخفضة السرعة: هناك إحتمالان هنا:
يحتوي موقع الصرة على خط T1 في السحابة، بينما يحتوي الموقع البعيد على سرعة أقل (56 كيلوبت/ثانية). في هذه الحالة، تحتاج إلى تحديد المعدل لموقع الموزع بحيث لا يتجاوز معدل الوصول من الجانب البعيد.
يحتوي موقع الصرة على خط T1 واحد في السحابة، بينما تحتوي المواقع البعيدة أيضا على خط T1 كامل في السحابة، يتصل بنفس موقع الصرة. في هذه الحالة، تحتاج إلى تحديد معدل المواقع البعيدة بحيث لا يتم تجاوز الصرة.
الاشتراك الزائد: على سبيل المثال، إذا كان المعدل المضمون على الدائرة الافتراضية الدائمة (PVC) هو 64 كيلوبت/ثانية وكان معدل الوصول هو 128 كيلوبت/ثانية على كلا الطرفين، فمن الممكن الاندفاع فوق المعدل المضمون عندما لا يكون هناك إزدحام والرجوع إلى المعدل المضمون عندما يكون هناك إزدحام.
جودة الخدمة: لتنفيذ ميزات تجزئة FRF.12 أو قوائم انتظار تقليل التأخير لتحقيق جودة خدمة أفضل، راجع VoIP عبر ترحيل الإطارات مع جودة الخدمة.
ملاحظة: معدل الوصول هو سرعة الخط الفعلي للواجهة المتصلة بترحيل الإطارات. المعدل المضمون هو معدل المعلومات الملتزم به (CIR) الذي منحه Telco ل PVC. يجب تجنب تعيين CIR أو MinCIR بمعدل الوصول، لأنه قد يؤدي إلى انخفاض الإخراج، مما يؤدي إلى كبح حركة المرور. السبب في ذلك هو أن معدل الشكل لا يأخذ في الاعتبار وحدات البايت الإضافية الخاصة بحقول الإشارة والتحقق الدوري من التكرار (CRC). لذلك، فإن التشكيل حسب معدل الخط هو في الواقع زيادة في الاشتراك، وسيتسبب في إزدحام الواجهة. لا يوصى بالتصميم حسب معدل الوصول. يجب دائما تشكيل حركة المرور بنسبة 95 بالمائة من معدل الوصول. وبشكل أعم، يجب ألا يكون المعدل الإجمالي المصمم أكثر من 95 بالمائة من معدل الوصول.
في هذا القسم، تُقدّم لك معلومات تكوين الميزات الموضحة في هذا المستند.
ملاحظة: للعثور على معلومات إضافية حول الأوامر المستخدمة في هذا المستند، أستخدم أداة بحث أوامر IOS
يستخدم هذا المستند إعداد الشبكة التالي:
في المثال أعلاه، لدينا القيم التالية:
لوحة الوصل - معدل الوصول = 192 كيلوبت في الثانية، المعدل المضمون = 32 كيلوبت في الثانية
البعيد - معدل الوصول = 64 كيلوبت/ثانية، معدل مضمون = 32 كيلوبت/ثانية
نقوم هنا بتطبيق تنظيم حركة البيانات على كلا طرفيها بحيث يكون متوسط معدل الإرسال هو 64 كيلوبت/ثانية. إذا لزم الأمر، يمكن أن ينفجر الموزع فوق هذا. في حالة الازدحام، يمكن أن ينخفض إلى 32 كيلوبت في الثانية كحد أدنى. إعلام الازدحام من السحابة من خلال إعلام الازدحام الصريح الرجعي (BECN). ومن ثم، يتم تكوين عملية التشكيل للتكيف مع شبكة BECN.
ملاحظة: يتم تمكين تنظيم حركة بيانات ترحيل الإطارات على الواجهة الرئيسية، ويتم تطبيقها على جميع معرفات اتصال إرتباط البيانات (DLCIs) أسفل هذه الواجهة. لا يمكننا تمكين تنظيم حركة المرور فقط ل DLCI معين أو واجهة فرعية تحت الواجهة الرئيسية. إذا لم يتم إرفاق فئة خريطة ب DLCI معينة، وتم تمكين تنظيم حركة مرور البيانات على الواجهة الرئيسية، يتم تعيين فئة الخريطة الافتراضية إلى DLCI مع CIR = 56000.
يستخدم هذا المستند التكوينات التالية:
موزع
عن بعد
موزع |
---|
interface Serial0/0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping !--- Apply traffic shaping to main interface (step 3). interface Serial0/0.1 point-to-point ip address 10.1.1.1 255.255.255.0 frame-relay interface-dlci 16 frame-relay class cisco !--- Apply map class to the DLCI / subinterface (step 2). ! ! !--- Configure map class parameters (step 1). map-class frame-relay cisco frame-relay cir 64000 frame-relay mincir 32000 frame-relay adaptive-shaping becn frame-relay bc 8000 frame-relay be 16000 ! |
عن بعد |
---|
interface Serial0/0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point ip address 10.1.1.2 255.255.255.0 frame-relay interface-dlci 16 frame-relay class cisco ! map-class frame-relay cisco frame-relay cir 64000 frame-relay mincir 32000 frame-relay adaptive-shaping becn frame-relay bc 8000 ! |
يبدي هذا رسم بياني حركة مرور يكون أرسلت من الصرة مسحاج تخديد:
بافتراض أن حركة المرور يتم إرسالها بفاصلة من 80000 بت، يتم إرسال هذا الأمر من PVC في فواصل 8 TC (كل منها 125 ميجابت في الثانية). يمكننا تحقيق هذا لأنه، في الفاصل الزمني الأول، الائتمان المتاح هو bc + be = 8000 + 16000 = 24000 بت. وهذا يعني أن المعدل هو 24000 بت/125 مللي ثانية = 192 كيلوبت/ثانية.
في الفواصل السبعة التالية سيكون BC = 8000 بت فقط. وبالتالي المعدل هو 8000 / 125 مللي ثانية = 64 كيلوبت/ثانية.
على سبيل المثال، إذا إستلمنا دفعة من 88000 بت، فلن يمكننا إرسال كل حركة المرور هذه في فواصل 8 TC. سيتم إرسال ال 8000 بت الأخيرة في الفاصل التاسع للسلسلة TC. وبالتالي، يتم تأخير حركة المرور هذه بواسطة آلية تشكيل حركة المرور.
يوفر هذا القسم معلومات يمكنك إستخدامها للتأكد من أن التكوين يعمل بشكل صحيح.
يتم دعم بعض أوامر العرض بواسطة أداة مترجم الإخراج (العملاء المسجلون فقط)، والتي تتيح لك عرض تحليل إخراج أمر العرض.
أستخدم الأمر show frame relay pvc <dlci>لعرض تفاصيل التكوين:
Hub#show frame relay pvc 16 PVC Statistics for interface Serial0/0 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1 input pkts 8743 output pkts 5 in bytes 2548330 out bytes 520 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 Shaping adapts to BECN pvc create time 6d01h, last time pvc status changed 6d01h cir 64000 bc 8000 be 16000 byte limit 3000 interval 125 mincir 56000 byte increment 1000 Adaptive Shaping BECN pkts 5 bytes 170 pkts delayed 0 bytes delayed 0 shaping inactive traffic shaping drops 0 Queueing strategy: fifo Output queue 0/40, 0 drop, 0 dequeued
يوضح هذا، في الوقت الفعلي، ما إذا كانت آلية تنظيم حركة المرور قد تم تنشيطها أم لا. تنظيم حركة البيانات نشط في السيناريوهات التالية:
يتم تلقي BECNs، وقد تم تكوين DLCI لتشكل BECN.
عدد وحدات بايت البيانات التي سيتم إرسالها من واجهة ما أكثر من الائتمان المتوفر (حد البايت) في فاصل زمني محدد (TC).
تم تكوين تجزئة FRF.12، وتنتظر الحزم ليتم تجزئتها.
يعرض هذا عدد الحزم ووحدات البايت التي تم تأجيلها بسبب تنشيط آلية تنظيم حركة مرور البيانات. وينطبق هذا بشكل رئيسي إذا تجاوز عدد وحدات البايت التي سيتم إرسالها الرصيد المتوفر لكل فاصل زمني، أو إذا كانت الحزم بحاجة إلى تجزئتها (FRF.12). يتم تخزين هذه الحزم ووحدات البايت في قائمة انتظار التشكيل (يتم تخصيصها لكل VC) ثم يتم إرسالها في فترات زمنية لاحقة عندما يكون هناك اعتماد متوفر كاف.
وهذا يوضح عدد حالات السقوط في قائمة انتظار التشكيل. يتم تأخير وحدات البايت أولا بواسطة آلية التشكيل ويتم تخزينها في قائمة الانتظار هذه. إذا تم تعبئة قائمة الانتظار، يتم إسقاط الحزم. بشكل افتراضي، يكون نوع قائمة الانتظار هو FCFS (أول خدمة تأتي أولا) أو FIFO، ولكن يمكن تغييره إلى WFQ أو PQ أو CQ أو CBWFQ أو LLQ. الاطلاع على المعلومات ذات الصلة
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
31-May-2005 |
الإصدار الأولي |