المقدمة
يصف هذا المستند العلاقة الموجودة بين حزم BFD Hello وإحصاءات نفق التوجيه مع مراعاة التطبيقات.
المتطلبات الأساسية
المتطلبات
cisco يوصي أن يتلقى أنت معرفة من هذا موضوع:
- شبكة المنطقة الواسعة (SD-WAN) المعرفة من قبل برنامج Cisco Catalyst Software.
- التوجيه مع مراعاة التطبيقات.
- محرك أقراص BFD.
المكونات المستخدمة
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
- مدير Cisco Catalyst SD-WAN.
- الحواف Cisco IOS® XE Catalyst SD-WAN.
معلومات أساسية
يعمل بروتوكول اكتشاف إعادة التوجيه ثنائي الإتجاه (BFD) عبر جميع أنفاق مستوى البيانات بين أجهزة Cisco IOS-XE Catalyst SD-WAN. يتم إستخدام هذا البروتوكول لمراقبة صلاحية الأنفاق وخصائصها الخاصة بالمسار مثل أداء النفق الذي يتم الإبلاغ عنه كفقد وترنح وزمن وصول.
تستخدم أجهزة الحافة مسابير BFD Hello لتوفير قياس لفقدان الحزمة والتشوه وزمن الوصول على النفق. ويتم حساب هذه الإحصائيات لكل تحقيق BFD Hello ويتم أخذها عبر نافذة زمنية منزلقة تسمى الفاصل الزمني للاستطلاع.
يتم إستخدام إحصائيات الخسائر وزمن الوصول والتشوه هذه من قبل التوجيه مع مراعاة التطبيقات لتقديم حركة المرور استنادا إلى المتطلبات المحددة في السياسة، والتي تسمى فئات SLA، والتي تحدد فيها الحد الأقصى للخسارة والتشوه وزمن الوصول المسموح به في النفق المحدد لتسليم البيانات.
ولهذا السبب، من الأهمية بمكان أن نفهم كيف يتم حساب المقاييس وكيف يمكن أن يؤثر التغيير في قيم BFD على حساب أداء النفق على الخسارة في المقام الأول. معلمات BFD هي:
بارامتر |
القيمة الافتراضية |
النطاق |
إستخدام |
الفاصل الزمني لترحيب BFD
|
ثانية واحدة |
من 1 إلى 65535 ثانية |
حزم لاكتشاف حيوية اتصال النفق ولاكتشاف الأخطاء الموجودة على النفق. |
الفاصل الزمني لعملية التحقق |
10 دقائق (600000 مللي ثانية) |
من 1 إلى 4،294،967 مللي ثانية |
عدد المرات التي يتم فيها حساب مقياس المستودع لتوفير إحصائيات. |
مضاعف |
6 |
من 1 إلى 6 |
القيمة التي تضاعف الفاصل الزمني للاستقصاء لتحديد الوقت اللازم لحساب الخسارة الوسطية، ومتوسط زمن الوصول، ومتوسط الرجفان. تحدد هذه القيمة عدد الدلاء. |
حساب إحصائيات أداء النفق
بالنسبة لمعلمات BFD المحددة كافتراضي، يتم حساب الإحصائيات على النحو التالي:
الفاصل الزمني لعملية التحقق / الفاصل الزمني للتعريف بمنتج BFD = 600000 مللي ثانية / 1000 مللي ثانية = 600 BFD متوسط لكل دلو.
بما أن المضاعف مضبوط على 6، فإنه يعني أن 6 مقابس تستخدم لحساب متوسط زمن الانتقال، الرجفان، والخسارة. بالقيم الافتراضية يساوي هذا ساعة واحدة. ويعرف هذا الوقت الإجمالي أيضا بفاصل مسار التطبيق.
الفاصل الزمني لمسار التطبيق = الفاصل الزمني لعملية التحقق * المضاعف = 600000 مللي ثانية x 6 = 3600000 مللي ثانية تساوي ساعة واحدة.
يتم إستخدام حسابات إحصائيات مسار التطبيق بواسطة التوجيه مع مراعاة التطبيق لتحديد التغييرات في مستوى البيانات. من أجل أن يستفيد جهاز Edge من إحصائيات مسار التطبيق، يجب تحديد فئات SLA في سياسة AAR التي تم فيها تعيين الحد الأقصى المسموح به لارتداد الحزم والفقدان وزمن الوصول. يتم إستخدام فئات SLA هذه في سياسة AAR لتوجيه حركة مرور البيانات لتطبيقات محددة وفقا لمستندات SLAs.
وبمجرد تكوينها في جهاز Edge، يتم إستخدام إحصائيات AAR للمقارنة مقارنة مقارنة بخسارة متوسطة وزمن وصول متوسط وموضع رجفان توفره الإحصائيات التي يتم حسابها مع جميع الدلاء (على مدى فاصل مسار التطبيق بالكامل). ومن المهم أيضا ملاحظة أن إتفاقات مستوى الخدمة تحدث بعد كل فترة استبيان، كل عشر دقائق بشكل افتراضي.
للحصول على متوسط الخسارة، متوسط درجة الاهتزاز، ومتوسط زمن الوصول المعادلات المستخدمة هي:
متوسط الخسارة = (إجمالي الخسارة عبر جميع الدلاء * 100) / إجمالي الحزم.
متوسط زمن الوصول = (إجمالي الفقد عبر جميع الدلاء) / مقدار الدلاء.
متوسط الرجفان = (إجمالي الرجفان عبر كل الدلاء) / مقدار الدلو.
يمكن مراجعة حساب هذه القيم بجانب متوسط كل دلو في واجهة سطر الأوامر مع:
vEdge#show app-route stats
cEdge#show sdwan app-route stats
أثناء التواجد في واجهة المستخدم الرسومية، يمكن مراجعة متوسط الفقد ومتوسط زمن الوصول ومتوسط رجفان فقط في شاشة > نظرة عامة > قسم التوجيه مع مراعاة التطبيقات.
كما يمكن مراجعتها في قسم أجهزة > جهاز تحديد > شبكة WAN > النفق.
أمثلة لقيم BFD علاقة بالخسارة
ونظرا لأن BFD Hellos قيم قابلة للتكوين، فإنه يمكن تعديلها بناء على المتطلبات؛ ومع ذلك، فمن المهم تعديلها بعد دراسة متأنية، ويمكن الحصول على حسابات منحرفة أو إحصاءات إيجابية خاطئة نظرا لأن دقة حساب متوسط الخسارة تعتمد على قيم BFD. على سبيل المثال، بالقيم الافتراضية ل:
بارامتر |
افتراضي |
حزمة BFD Hello |
ثانية واحدة |
الفاصل الزمني لعملية التحقق |
(600000 مللي ثانية) 10 دقائق |
مضاعف |
6 |
vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color private1
remote-color private1
mean-loss 1
mean-latency 110
mean-jitter 51
sla-class-index 0,2
IPV6 TX IPV6 RX
TOTAL AVERAGE AVERAGE TX DATA RX DATA DATA DATA
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS PKTS PKTS
----------------------------------------------------------------------------
0 596 7 110 50 0 0 0 0
1 596 5 111 50 0 1 0 0
2 597 13 111 53 0 0 0 0
3 594 4 111 53 0 0 0 0
4 596 5 110 50 0 0 0 0
5 594 12 111 50 0 2 0 0
متوسط الخسارة = ((7+5+13+4+5+12)100)/ (596+596+597+594+596+594)
= 4600/3573
= من 1.28 إلى 1٪
متوسط زمن الوصول = (110+111+111+111+110+111)/6
= من 110.66 إلى 110 مللي ثانية
متوسط الرجفان = (50+50+53+53+50+50) / 6
= 3 /6 = 51 مللي ثانية
ملاحظة: بالنسبة لكل عملية حسابية تم القيام بها، يتم عرض قيم عدد صحيح فقط. حتى عندما تكون النتيجة العشرية هي النتيجة الصحيحة، يتم تقريب قيم العدد الصحيح إلى أقرب عدد صحيح أقل.
عادة، يكون خيارا جيدا لتعديل هذه القيم لجعل الحساب أكثر تكرارا ولكن يمكن أن يسبب تأثير كبير، على سبيل المثال، إذا تم تعديل الفاصل الزمني للاستقصاء بدلا من القيم الافتراضية إلى:
بارامتر |
افتراضي |
حزمة BFD Hello |
ثانية واحدة |
الفاصل الزمني لعملية التحقق |
(60000 مللي ثانية) 1 دقيقة |
مضاعف |
6 |
هذا التغيير يعني أنه يستخدم 1 × 60 = 60 حزمة لكل دلو بدلا من 600 كافتراضي. نتيجة متوسط الخسارة هي:
vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color private1
remote-color private1
mean-loss 3
mean-latency 112
mean-jitter 51
sla-class-index 0,2
IPV6 TX IPV6 RX
TOTAL AVERAGE AVERAGE TX DATA RX DATA DATA DATA
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS PKTS PKTS
----------------------------------------------------------------------------
0 59 1 113 53 0 0 0 0
1 60 3 111 52 0 1 0 0
2 59 1 111 51 0 1 0 0
3 60 3 111 50 0 1 0 0
4 60 2 115 50 0 0 0 0
5 59 1 111 50 0 2 0 0
متوسط الخسارة = ((1+3+1+3+2+1)*100)/(59+60+59+60+60+59)
= (1100)/ 357
= 3.08 إلى 3٪
عند هذه النقطة، إذا تم تعيين فئة SLA على سبيل المثال على حد أقصى للفقدان يبلغ 3، فسيكون النفق تحت حد انتهاك SLA. ومع ذلك، إذا تم تعديل الفاصل الزمني لعملية التحقق إلى:
بارامتر |
افتراضي |
حزمة BFD Hello |
ثانية واحدة |
الفاصل الزمني لعملية التحقق |
(6000 مللي ثانية) ثانية واحدة |
مضاعف |
6 |
هذا التغيير يعني أنه يستخدم 1 × 6 = 6 حزم لكل دلو بدلا من 600 كافتراضي. نتيجة متوسط الخسارة هي:
vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color private1
remote-color private1
mean-loss 17
mean-latency 110
mean-jitter 0
sla-class-index None
IPV6 TX IPV6 RX
TOTAL AVERAGE AVERAGE TX DATA RX DATA DATA DATA
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS PKTS PKTS
----------------------------------------------------------------------------
0 5 1 113 2 0 0 0 0
1 6 1 110 1 0 1 0 0
2 6 1 111 2 0 0 0 0
3 6 0 111 0 0 0 0 0
4 6 1 111 0 0 0 0 0
5 6 1 111 0 0 2 0 0
متوسط الخسارة = ((5)100)/(5+6+6+6+6)
= (500)/29
= من 17.24 إلى 17٪
ما إذا تم تقليل الفاصل الزمني للاستطلاع دون التحقق الصحيح من عدد الحزم التي يتم إستخدامها للقياس، فقد يؤثر على متوسط الخسارة، يمكن تطبيق الأمر نفسه إذا كان الفاصل الزمني مرحبا لبروتوكول BFD أكبر بدون زيادة الفاصل الزمني للتجمع.
في المثال الأخير، حيث يتم إستخدام حزم قليلة جدا لإجراء الحساب، مع فقدان حزمة واحدة فقط، يمكن أن يتأثر متوسط الخسارة بشكل كبير. وكانت نتيجة هذه الحسابات سلوك سياسي مدروس للتطبيق مع حدوث حالات فشل متعددة ومتكررة للغاية.
والغرض من هذا الشرح ليس تجنب تعديل تلك القيم، بل على العكس من ذلك، يلزم في كثير من الحالات تعديل تلك المسابر. وهذا يعتمد بالكامل على متطلبات الشبكة، ولكن من المهم للغاية مراجعة مدى إمكانية تقليل حزم الترحيب هذه.
أمر التكوين المراد تعديله بشكل عام الفاصل الزمني للاستطلاع هو:
vEdge(config)# bfd app-route poll-interval 600000