دليل البدء السريع - تجميع البيانات للعديد من مشاكل شبكة SD-WAN

المقدمة

يصف هذا المستند العديد من مشاكل SD-WAN حول البيانات ذات الصلة التي يجب تجميعها مسبقا قبل فتح حالة مركز المساعدة الفنية لتحسين سرعة أستكشاف الأخطاء وإصلاحها و/أو حل المشكلة. يتم تقسيم هذا المستند إلى قسمين فنيين رئيسيين: موجهات vManage و Edge. يتم توفير النواتج ذات الصلة وصياغة الأوامر وفقا للجهاز المعني.

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

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• بنية SDWAN من Cisco
• الفهم العام للحل، بما في ذلك وحدة التحكم vManage بالإضافة إلى cEdge (موجهات IOS-XE SD-WAN) وأجهزة vEdge (موجهات نظام التشغيل ViptelaOS)

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

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

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

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

•  وصف المشكلة وتأثيرها على الشبكة والمستخدمين:
  • وصف سلوك متوقع.
  • صف بالتفصيل السلوك الملاحظ.
  • قم بإعداد مخطط مخطط مخطط مخطط باستخدام العناوين إن أمكن، حتى إذا كان هذا الرسم يدويا.
•  متى بدأت المشكلة؟
  • لاحظ اليوم والوقت اللذين تم فيهما ملاحظة/ملاحظة المشكلة لأول مرة.
• ماذا يمكن ان يكون الدافع المحتمل للمشكلة؟
  • قم بتوثيق التغييرات الأخيرة التي تم إجراؤها قبل بدء المشكلة.
  • لاحظ أي إجراءات أو أحداث محددة حدثت يمكن أن تكون قد أدت إلى بدء المشكلة.
  • هل تتوافق هذه المشكلة مع أي أحداث أو إجراءات أخرى على الشبكة؟
• ما هو معدل حدوث المشكلة؟
  • هل حدث ذلك مرة واحدة؟
  • إذا لم يكن الامر كذلك، كم مرة تحدث المشكلة؟
• توفير معلومات حول الجهاز (الأجهزة) المعنية:
  • إذا كانت هناك أجهزة معينة تتأثر (وليس بشكل عشوائي)، فما هو الشيء المشترك بينها؟
  • IP ومعرف الموقع لكل جهاز.
  • إذا كانت المشكلة موجودة على نظام مجموعة vManage، فقم بتوفير تفاصيل العقد (إن لم يكن نفس التفاصيل عبر كافة العقد في نظام المجموعة).
  • بالنسبة للمشكلات العامة داخل واجهة المستخدم الرسومية (GUI) لبرنامج vManage، قم بالتقاط جميع لقطات الشاشة في ملف تظهر رسائل الخطأ أو أي حالات شاذة/حالات توقف أخرى يجب التحقيق فيها.
• قم بتوفير معلومات حول النتائج المرجوة من TAC وأولوياتك:
  • هل ترغب في الاسترداد من الفشل في أقرب وقت ممكن أو معرفة السبب الرئيسي للفشل؟

vManage

المشكلات هنا هي ظروف المشكلات الشائعة التي تم الإبلاغ عنها ل vManage مع المخرجات المفيدة لكل مشكلة يجب تجميعها بالإضافة إلى ملف (ملفات) admin-tech. بالنسبة لوحدات التحكم المستضافة عبر السحابة، يمكن لمهندس مركز المساعدة التقنية (TAC) الوصول إلى تجميع مخرجات admin-tech المطلوبة للأجهزة استنادا إلى الملاحظات الواردة في قسم المعلومات الأساسية المطلوبة إذا قمت بتوفير موافقة صريحة على هذا. ومع ذلك، فإننا نوصي بالاحتفاظ بمخرجات تقنية الإدارة إذا كانت الخطوات الموضحة هنا لضمان أن البيانات الواردة فيها ذات صلة بموعد المشكلة. وهذا صحيح على وجه التحديد إذا لم تكن المشكلة مستمرة، وهذا يعني أن المشكلة يمكن أن تختفي بحلول الوقت الذي يتم فيه مشاركة TAC. بالنسبة لوحدات التحكم الجاهزة، يجب تضمين admin-tech أيضا مع كل مجموعة من البيانات هنا. بالنسبة لمجموعة vManage، تأكد من التقاط تقنية admin لكل عقدة في نظام المجموعة أو فقط العقدة المتأثرة. 

البطء والكسل

تقرير المشكلة: بطء الوصول إلى واجهة المستخدم الرسومية VManage، زمن الوصول عند إجراء العمليات داخل واجهة المستخدم الرسومية (GUI)، البطء العام أو التباطؤ الذي يظهر داخل vManage

الخطوة 1. التقط 2-3 مثال من عملية طباعة مؤشر الترابط، قم بإعادة تسمية كل ملف طباعة مؤشر ترابط بتسمية رقمية بعد كل ملف (لاحظ إستخدام اسم المستخدم الذي تقوم بتسجيل الدخول إليه باستخدام vManage في مسار الملف)، على سبيل المثال:

vManage# request nms application-server jcmd thread-print | save /home/<username>/thread-print.1

الخطوة 2. سجل الدخول إلى vshell وقم بتشغيل VMSTAT كما هو أدناه:

vManage# vshell
vManage:~$ vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 316172 1242608 5867144 0 0 1 22 3 5 6 1 93 0 0
0 0 0 316692 1242608 5867336 0 0 0 8 2365 4136 6 1 93 0 0
0 0 0 316204 1242608 5867344 0 0 0 396 2273 4009 6 1 93 0 0
0 0 0 316780 1242608 5867344 0 0 0 0 2322 4108 5 2 93 0 0
0 0 0 318136 1242608 5867344 0 0 0 0 2209 3957 9 1 90 0 0
0 0 0 318300 1242608 5867344 0 0 0 0 2523 4649 5 1 94 0 0
1 0 0 318632 1242608 5867344 0 0 0 44 2174 3983 5 2 93 0 0
0 0 0 318144 1242608 5867344 0 0 0 64 2182 3951 5 2 94 0 0
0 0 0 317812 1242608 5867344 0 0 0 0 2516 4289 6 1 93 0 0
0 0 0 318036 1242608 5867344 0 0 0 0 2600 4421 8 1 91 0 0
vManage:~$

الخطوة 3. تجميع تفاصيل إضافية من VSHELL:

vManage:~$ top (press '1' to get CPU counts)
vManage:~$ free -h
vManage:~$ df -kh

الخطوة 4. التقاط جميع تشخيصات خدمات NMS:

vManage# request nms application-server diagnostics
vManage# request nms configuration-db diagnostics
vManage# request nms messaging-server diagnostics
vManage# request nms coordination-server diagnostics
vManage# request nms statistics-db diagnostics

مشكلات/فشل واجهة برمجة التطبيقات

تقرير المشكلة: فشل إستدعاءات API في إرجاع أية بيانات أو البيانات الصحيحة أو المشاكل العامة في تنفيذ الاستعلامات

الخطوة 1. تحقق من الذاكرة المتوفرة:

vManage:~$ free -h
total used free shared buff/cache available
Mem: 31Gi 24Gi 280Mi 60Mi 6.8Gi 6.9Gi
Swap: 0B 0B 0B
vManage:~$ 

الخطوة 2. التقط 2-3 مثال من عملية طباعة مؤشر الترابط مع وجود فجوة 5 ثوان بين الاثنين، قم بإعادة تسمية كل ملف طباعة مؤشر الترابط مع تعيين رقمي بعد كل تشغيل للأمر (لاحظ إستخدام اسم المستخدم الذي تقوم بتسجيل الدخول إليه في vManage باستخدام مسار الملف):

vManage# request nms application-server jcmd thread-print | save /home/<username>/thread-print.1
<WAIT 5 SECONDS>
vManage# request nms application-server jcmd thread-print | save /home/<username>/thread-print.2

الخطوة 3. تجميع تفاصيل أي جلسات عمل HTTP نشطة:

vManage# request nms application-server jcmd gc-class-histo | i io.undertow.server.protocol.http.HttpServerConnection

الخطوة 4. توفير هذه التفاصيل:

1. تم تنفيذ إستدعاءات واجهة برمجة التطبيقات

2. تواتر الاستدعاء

3. طريقة تسجيل الدخول (أي إستخدام رمز مميز واحد لتنفيذ مكالمات API التالية أو إستخدام المصادقة الأساسية لتنفيذ الاستدعاء ثم تسجيل الخروج)

4 - هل يعاد إستخدام JSESSIONID؟

ملاحظة بدءا من برنامج vManage 19.2، يتم دعم المصادقة المستندة إلى الرمز المميز فقط لمكالمات API. للحصول على مزيد من التفاصيل حول إنشاء الرمز المميز والمهلة وانتهاء الصلاحية، راجع هذا الارتباط.

حالة/بطء فحص الحزمة العميقة (DPI)

تقرير المشكلة: مع تمكين إدارة شؤون الإعلام، يمكن أن تكون معالجة الإحصائيات بطيئة أو قد تؤدي إلى حدوث بطء داخل واجهة المستخدم الرسومية vManage.

الخطوة 1. تحقق من حجم القرص المخصص ل DPI داخل vManage عن طريق الانتقال إلى الإدارة > الإعدادات > قاعدة بيانات الإحصائيات > التكوين.

الخطوة 2. تحقق من صحة الفهرس من خلال تشغيل أمر CLI التالي من vManage:

vManage# request nms statistics-db diagnostics

الخطوة 3. تأكيد ما إذا كان يتم تنفيذ أي مكالمات API المتعلقة بحالات DPI خارجيا.

الخطوة 4. تحقق من حالات إدخال/إخراج القرص بمساعدة أمر واجهة سطر الأوامر (CLI) هذا من vManage:

vManage# request nms application-server diagnostics 

فشل دفع القالب

تقرير المشكلة: فشل دفع القالب أو تحديث قالب الجهاز أو انتهاء المهلة.

الخطوة 1. التقاط معاينة التكوين وتكوين الوجهة من vManage قبل النقر فوق الزر تكوين الأجهزة (مثال التنقل المتوفر هنا): 

الخطوة 2. قم بتمكين viptela.enable.rest.log من صفحة logSettings (يجب تعطيل هذا بعد التقاط المعلومات المطلوبة):

https://<vManage IP>:8443/logsettings.html​

الخطوة 3. إذا كان فشل دفع القالب يتضمن مشكلة أو خطأ في NETconf، فقم بتمكين viptela.enable.device.netconf.log بالإضافة إلى سجل REST في الخطوة 1. لاحظ أنه يجب تعطيل هذا السجل أيضا بعد التقاط المخرجات من الخطوة 3 والخطوة 4.

الخطوة 4. حاول إرفاق القالب الفاشل مرة أخرى من vManage والتقاط Admin-tech باستخدام واجهة سطر الأوامر (التقاط هذه العقدة لكل عقدة من نظام المجموعة):

vManage# request admin-tech

الخطوة 5. قم بتوفير لقطات شاشة من المهمة في vManage و Config Diff لتأكيد تفاصيل الفشل مع أي ملفات CSV تستخدم للقالب.

الخطوة 6. قم بتضمين تفاصيل حول الفشل والمهمة، بما في ذلك وقت عملية الدفع الفاشلة و system-ip للجهاز الذي فشل ورسالة الخطأ التي تراها في واجهة المستخدم الرسومية (GUI) لبرنامج vManage.

الخطوة 7. إذا حدث فشل دفع قالب مع ظهور رسالة خطأ تم الإعلام عنها للتكوين بواسطة الجهاز نفسه، فقم بتجميع admin-tech من الجهاز أيضا.

المسائل المتعلقة بالمجموعات

تقرير المشكلة: عدم إستقرار المجموعة الذي يؤدي إلى فترات الانتظار في واجهة المستخدم الرسومية (GUI) أو التباطؤ أو أي حالات شاذة أخرى.

الخطوة 1. التقاط الإخراج من server_configs.json من كل عقدة vManage في نظام المجموعة. على سبيل المثال:

vmanage# vshell
vmanage:~$ cd /opt/web-app/etc/
vmanage:/opt/web-app/etc$ more server_configs.json | python -m json.tool
{
"clusterid": "",
"domain": "",
"hostsEntryVersion": 12,
"mode": "SingleTenant",
"services": {
"cloudAgent": {
"clients": {
"0": "localhost:8553"
},
"deviceIP": "localhost:8553",
"hosts": {
"0": "localhost:8553"
},
"server": true,
"standalone": false
},
"container-manager": {
"clients": {
"0": "169.254.100.227:10502"
},
"deviceIP": "169.254.100.227:10502",
"hosts": {
"0": "169.254.100.227:10502"
},
"server": true,
"standalone": false
},
"elasticsearch": {
"clients": {
"0": "169.254.100.227:9300",
"1": "169.254.100.254:9300",
"2": "169.254.100.253:9300"
},
"deviceIP": "169.254.100.227:9300",
"hosts": {
"0": "169.254.100.227:9300",
"1": "169.254.100.254:9300",
"2": "169.254.100.253:9300"
},
"server": true,
"standalone": false
},
"kafka": {
"clients": {
"0": "169.254.100.227:9092",
"1": "169.254.100.254:9092",
"2": "169.254.100.253:9092"
},
"deviceIP": "169.254.100.227:9092",
"hosts": {
"0": "169.254.100.227:9092",
"1": "169.254.100.254:9092",
"2": "169.254.100.253:9092"
},
"server": true,
"standalone": false
},
"neo4j": {
"clients": {
"0": "169.254.100.227:7687",
"1": "169.254.100.254:7687",
"2": "169.254.100.253:7687"
},
"deviceIP": "169.254.100.227:7687",
"hosts": {
"0": "169.254.100.227:5000",
"1": "169.254.100.254:5000",
"2": "169.254.100.253:5000"
},
"server": true,
"standalone": false
},
"orientdb": {
"clients": {},
"deviceIP": "localhost:2424",
"hosts": {},
"server": false,
"standalone": false
},
"wildfly": {
"clients": {
"0": "169.254.100.227:8443",
"1": "169.254.100.254:8443",
"2": "169.254.100.253:8443"
},
"deviceIP": "169.254.100.227:8443",
"hosts": {
"0": "169.254.100.227:7600",
"1": "169.254.100.254:7600",
"2": "169.254.100.253:7600"
},
"server": true,
"standalone": false
},
"zookeeper": {
"clients": {
"0": "169.254.100.227:2181",
"1": "169.254.100.254:2181",
"2": "169.254.100.253:2181"
},
"deviceIP": "169.254.100.227:2181",
"hosts": {
"0": "169.254.100.227:2888:3888",
"1": "169.254.100.254:2888:3888",
"2": "169.254.100.253:2888:3888"
},
"server": true,
"standalone": false
}
},
"vmanageID": "0"
}

الخطوة 2. التقاط تفاصيل الخدمات التي تم تمكينها أو تعطيلها لكل عقدة. للحصول على هذا، انتقل إلى الإدارة > إدارة المجموعات في واجهة المستخدم الرسومية vManage.

الخطوة 3. تأكيد إمكانية الوصول إلى القاعدة الأساسية على واجهة نظام المجموعة. ولهذا السبب، قم بتشغيل ping <ip-address> من كل عقدة vManage في VPN 0 إلى عنوان IP الخاص بواجهة نظام المجموعة للعقد الأخرى.

الخطوة 4. تجميع التشخيصات من جميع خدمات NMS لكل عقدة vManage في نظام المجموعة:

vManage# request nms application-server diagnostics
vManage# request nms configuration-db diagnostics
vManage# request nms messaging-server diagnostics
vManage# request nms coordination-server diagnostics
vManage# request nms statistics-db diagnostics

Edge (vEdge/cEdge)

المسائل هنا هي ظروف المشاكل الشائعة التي تم الإبلاغ عنها للأجهزة الطرفية مع مخرجات مفيدة لكل واحد يجب تجميعه. تأكد من تجميع تقنية الإدارة لكل مشكلة لكافة الأجهزة الطرفية الضرورية وذات الصلة. بالنسبة لوحدات التحكم المستضافة عبر السحابة، يمكن أن يكون ل TAC حق الوصول لجمع مخرجات admin-tech المطلوبة للأجهزة استنادا إلى الملاحظات الموجودة في قسم المعلومات الأساسية المطلوبة. ومع ذلك، كما هو الحال مع vManage، قد يكون من الضروري التقاط هذه الملفات قبل فتح حالة مركز المساعدة الفنية للتأكد من أن البيانات المضمنة ذات صلة بوقت المشكلة. وهذا صحيح على وجه التحديد إذا لم تكن المشكلة مستمرة، وهذا يعني أن المشكلة يمكن أن تختفي بحلول الوقت الذي يتم فيه مشاركة TAC.

لا تتكون إتصالات التحكم بين الجهاز ووحدة التحكم

تقرير المشكلة: لا يتم تكوين اتصال التحكم من vEdge/cEdge إلى وحدة تحكم واحدة أو أكثر

الخطوة 1. التعرف على الخطأ المحلي/البعيد لفشل اتصال عنصر التحكم:

• ل vEdge: إخراج أمر show control connections-history.
• ل cEdge: إخراج أمر show sdwan control connection-history.

الخطوة 2. تأكد من حالة وحدة (وحدات) TLOC ومن أن أي وكل العناصر تظهر 'up':

• ل vEdge: إخراج أمر show control local-properties.
• ل cEdge: إخراج أمر show sdwan control local-properties.

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

• بالنسبة لوحدات التحكم:

vManage# tcpdump vpn 0 interface eth1 options "-vvvvvv host 192.168.44.6"
tcpdump -p -i eth1 -s 128 -vvvvvv host 192.168.44.6 in VPN 0
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 128 bytes
20:02:07.427064 IP (tos 0xc0, ttl 61, id 50139, offset 0, flags [DF], proto UDP (17), length 168)
192.168.44.6.12346 > 192.168.40.1.12346: UDP, length 140
20:02:07.427401 IP (tos 0xc0, ttl 64, id 37220, offset 0, flags [DF], proto UDP (17), length 210)
192.168.40.1.12346 > 192.168.44.6.12346: UDP, length 182

• • ل vEdge:

vEdge-INET-Branch2# tcpdump vpn 0 interface ge0/2 options "-vvvvvv host 192.168.40.1"
tcpdump -p -i ge0_2 -vvvvvv host 192.168.40.1 in VPN 0
tcpdump: listening on ge0_2, link-type EN10MB (Ethernet), capture size 262144 bytes
20:14:16.136276 IP (tos 0xc0, ttl 64, id 55858, offset 0, flags [DF], proto UDP (17), length 277)
10.10.10.1 > 192.168.40.1.12446: [udp sum ok] UDP, length 249
20:14:16.136735 IP (tos 0xc0, ttl 63, id 2907, offset 0, flags [DF], proto UDP (17), length 129)
192.168.40.1.12446 > 10.10.10.1.12346: [udp sum ok] UDP, length 101

• • ل cEdge (يفترض الالتقاط أدناه أنه تم نقل الجهاز إلى وضع CLI وتم إنشاء قائمة تحكم في الوصول (ACL) تسمى CTRL-CAP للتصفية - راجع المزيد من التفاصيل في مثال التقاط EPC في سيناريو أداء التطبيق/الشبكة):

cEdge-Branch1#config-transaction
cEdge-Branch1(config)# ip access-list extended CTRL-CAP
cEdge-Branch1(config-ext-nacl)# 10 permit ip host 10.10.10.1 host 192.168.40.1
cEdge-Branch1(config-ext-nacl)# 20 permit ip host 192.168.40.1 host 10.10.10.1
cEdge-Branch1(config-ext-nacl)# commit
cEdge-Branch1(config-ext-nacl)# end

cEdge-Branch1#monitor capture CAP control-plane both access-list CTRL-CAP buffer size 10
cEdge-Branch1#monitor capture CAP start

cEdge-Branch1#show monitor capture CAP buffer brief 
----------------------------------------------------------------------------
# size timestamp source destination dscp protocol
----------------------------------------------------------------------------
0 202 0.000000 192.168.20.1 -> 50.50.50.3 48 CS6 UDP
1 202 0.000000 192.168.20.1 -> 50.50.50.4 48 CS6 UDP
2 220 0.000000 50.50.50.3 -> 192.168.20.1 48 CS6 UDP
3 66 0.000992 192.168.20.1 -> 50.50.50.3 48 CS6 UDP
4 220 0.000992 50.50.50.4 -> 192.168.20.1 48 CS6 UDP
5 66 0.000992 192.168.20.1 -> 50.50.50.4 48 CS6 UDP
6 207 0.015991 50.50.50.1 -> 12.12.12.1 48 CS6 UDP

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

التحكم في تدفق الاتصالات بين جهاز الحافة ووحدة التحكم

تقرير المشكلة: إرتباط واحد أو أكثر من إتصالات التحكم بين vEdge/cEdge ووحدة تحكم واحدة أو أكثر. ويمكن ان يكون ذلك تكرارا، متقطعا، أو عشوائيا في الطبيعة.

• غالبا ما تكون نقاط الوصول إلى اتصال التحكم نتيجة لفقدان الحزمة أو مشاكل إعادة التوجيه بين الجهاز ووحدة التحكم. وفي كثير من الأحيان، يرتبط هذا بأخطاء TMO، اعتمادا على إتجاه الفشل. للتحقق من هذا أكثر، أول دققت السبب ل رفرفة:
  • ل vEdge/وحدات التحكم: إخراج أمر show control connections-history.
  • ل cEdge: إخراج أمر show sdwan control connection-history.
• تأكد من حالة TLOC (القيم) ومن أن أي وكل 'up' يظهر عند حدوث التدفق:
  • ل vEdge: إخراج أمر show control local-properties.
  • ل cEdge: إخراج أمر show sdwan control local-properties.
•  تجميع التقاط الحزم على كل من وحدة التحكم (وحدات) وجهاز الحافة. الرجاء الرجوع إلى قسم إتصالات التحكم التي لا تتكون بين الجهاز ووحدة التحكم للحصول على تفاصيل حول معلمات الالتقاط لكل جانب.

لا تتكون جلسات اكتشاف إعادة التوجيه ثنائي الإتجاه (BFD) أو ترفرفة بين الأجهزة الطرفية

تقرير المشكلة: جلسة عمل BFD متوقفة أو تقوم بالتوهج لأعلى ولأسفل بين جهازي الحافة.

الخطوة 1. تجميع حالة جلسة عمل BFD على كل جهاز:

• ل vEdge: إنتاج من عرض bfd جلسة أمر.
• ل cEdge: إنتاج من عرض sdwan bfd جلسة أمر.

الخطوة 2. تجميع تعداد حزم Rx و Tx على كل موجه حافة:

• ل vEdge: إخراج أمر show tunnel statistics bfd.
• ل cEdge: مخرجات show platform hardware qfp سمة نشط bfd datapath sdwan summary أمر.

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

أعطال الجهاز

تقرير المشكلة: تم إعادة تحميل الجهاز بشكل غير متوقع واستبعاد المشاكل المتعلقة بالطاقة. تشير إشارات الجهاز إلى احتمال تعطل الجهاز.

الخطوة 1. تحقق من الجهاز للتأكد مما إذا تم ملاحظة عطل أو إعادة تحميل غير متوقع:

• ل vEdge: إخراج أمر show reboot history .
• ل cEdge: إخراج أمر محفوظات إعادة تمهيد شبكة SDWAN.
• بدلا من ذلك، انتقل إلى شاشة > شبكة، وحدد الجهاز، ثم انتقل إلى حالة النظام > إعادة التمهيد لتأكيد ما إذا تم مشاهدة أي عمليات إعادة تحميل غير متوقعة.

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

انخفاض أداء التطبيق/الشبكة أو فشله بين المواقع

تقرير المشكلة: لا يعمل التطبيق/صفحات HTTP بدون تحميل، بطء/زمن انتقال في الأداء، حالات فشل بعد إجراء تغييرات في السياسة أو التكوين

الخطوة 1. التعرف على زوج IP المصدر/الوجهة لتطبيق أو تدفق يعرض المشكلة.

الخطوة 2. تحديد جميع الأجهزة الطرفية في المسار وتجميع تقنية الإدارة من كل منها من خلال vManage.

الخطوة 3. التقاط حزمة على الأجهزة الطرفية في كل موقع لهذا التدفق عندما ترى المشكلة:

• ل vEdge:
  • قم بتمكين تدفق البيانات تحت الإدارة > إعدادات لحقل اسم المضيف، أدخل عنوان IP للنظام الخاص ب vManage. دخلت ل VPN 0
  • تأكد من تمكين HTTPS ضمن تكوين allow-service لواجهة vManage VPN 0.
  • اتبع الخطوات هنا لالتقاط حركة مرور البيانات على واجهة VPN الخاصة بجانب الخدمة.
• ل cEdge:
  • انقل CEdge (الخوادم) إلى وضع CLI عبر التكوين > الأجهزة > تغيير الوضع > وضع CLI
  • على الخادم (الخوادم) طراز cEdge، قم بتكوين قائمة تحكم في الوصول (ACL) موسعة لمطابقة حركة المرور بشكل ثنائي الإتجاه. أجعل هذا محددا قدر الإمكان لتضمين البروتوكول والمنفذ للحد من الحجم والبيانات في الالتقاط.
• قم بتكوين التقاط الحزم المضمن (EPC) لواجهة جانب الخدمة في كلا الاتجاهين، باستخدام قائمة التحكم في الوصول (ACL) التي تم إنشاؤها في (ب) لتصفية حركة المرور. يمكن تصدير الالتقاط إلى تنسيق PCAP ونسخه من المربع. يتم توفير نموذج التكوين هنا ل GigabitEthernet0/0/0 على موجه باستخدام قائمة التحكم في الوصول (ACL) المسماة Broken-flow:

monitor capture CAP interface GigabitEthernet0/0/0 both access-list BROKEN-FLOW buffer size 10
monitor capture CAP start

show monitor capture CAP parameter
show monitor capture CAP buffer [brief]

monitor capture CAP export bootflash:cEdge1-Broken-Flow.pcap

• • قم بتكوين تتبع الحزمة لحركة المرور في كلا الاتجاهين، باستخدام قائمة التحكم في الوصول (ACL) التي تم إنشاؤها في (ب) لتصفية حركة المرور. يتم توفير نموذج للتكوين أدناه:

debug platform packet-trace packet 2048 fia-trace
debug platform packet-trace copy packet input l3 size 2048
debug platform condition ipv4 access-list BROKEN-FLOW both
debug platform condition start

show platform packet-trace summary
show platform packet-trace packet all | redirect bootflash:cEdge1-PT-OUTPUT.txt

الخطوة 4. إن أمكن، كرر الخطوة 3 في سيناريو عمل للمقارنة.

تلميح: إذا لم تكن هناك طرق أخرى لنسخ الملفات المقابلة خارج الخادم مباشرة، يمكن نسخ الملفات إلى vManage أولا باستخدام الطريقة الموضحة هنا. قم بتشغيل الأمر على vManage:
طلب تنفيذ scp -p 830 <username>@<cEdge system-IP>:/bootflash/<filename> .
وبعد ذلك، سيتم تخزين هذا الملف في /home/<username>/ الدليل لاسم المستخدم الذي أستخدمته لتسجيل الدخول إلى vManage. ومن هناك، يمكنك إستخدام بروتوكول النسخ الآمن (SCP) لبروتوكول نقل الملفات الآمن (SFTP) لنسخ ملف من برنامج vManage باستخدام عميل SCP/SFTP من جهة خارجية أو واجهة سطر أوامر (CLI) جهاز Linux/Unix مع أدوات OpenSSH المساعدة.