المقدمة
يوضح هذا المستند كيفية حل بروتوكول تكرار موجه SD-WAN الظاهري (VRRP) Viptela العالق في حالة النشاط.
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- معرفة أساسية بحلول Meraki
- معرفة أساسية ب VRRP
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
- vEdge 2000، الإصدار 19.2.3
- MS250-48FP، نسخة MS 12.28
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
طوبولوجيا
العرض 1. VRRP في حالة النشاط-النشط
تعمل كل من أجهزة vEdge لعبارة الخادم المتصلة بالأسفل إلى محولات مكدس Meraki كجهاز أساسي لبروتوكول VRRP.
VE1# show vrrp
MASTER PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN LIST
VPN IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME TRACK PREFIX LIST STATE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
11 10ge0/0.670 1 10.17.69.1 00:00:5e:00:01:01 110 master up 1 3 2021-10-12T02:16:49+00:00 Default_Route_Prefix_List resolved
VE2# show vrrp
MASTER PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN LIST
VPN IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME TRACK PREFIX LIST STATE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
11 10ge0/0.670 1 10.17.69.1 00:00:5e:00:01:01 100 master up 1 3 2021-10-12T02:16:40+00:00 Default_Route_Prefix_List resolved
العرض 2. التبديل تنبيه إلى DNS غير صحيح
تم تنبيه المحول 2 المتصل ب VE2 إلى "تكوين DNS بشكل غير صحيح" في لوحة معلومات Meraki.
العرض 3. APs انتقل في وضع مكرر
ذهبت نقاط الوصول (APs) المتصلة بالمحول 2 إلى وضع إعادة الإرسال نظرا لأن المحول لا يحتوي على قابلية الوصول إلى البوابة.
استكشاف الأخطاء وإصلاحها
- تحقق من سلوك VRRP من vEdges.
قم بتجميع "tcpdump" من كل من vEdges والتحقق من حالة حزمة VRRP. في هذه الحالة، لاحظت أن حزم VRRP تتلقى وترسل بواسطة VE1. غير أنه لا يتم تلقي حزم VRRP من VE1 إلى VE2. ومع ذلك، تم إرسال الأمر نفسه من VE1. وبالتالي، يمكنك تأكيد عدم وجود مشاكل في وظيفة vEdges للعبارة.
من VE1:
10.17.69.3 > 224.0.0.18: vrrp 10.17.69.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20, addrs: 10.17.69.1
08:57:12.744406 80:b7:09:32:e5:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 6968, offset 0, flags [DF], proto VRRP (112), length 40)
10.17.69.2 > 224.0.0.18: vrrp 10.17.69.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 110, authtype none, intvl 1s, length 20, addrs: 10.17.69.1
08:57:13.708034 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 56: (tos 0xc0, ttl 255, id 29924, offset 0, flags [DF], proto VRRP (112), length 40)
من VE2:
10.17.69.3 > 224.0.0.18: vrrp 10.17.69.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20, addrs: 10.17.69.1
08:57:50.644532 80:b7:09:31:82:a2 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 31817, offset 0, flags [DF], proto VRRP (112), length 40)
لا توجد حزمة VRRP من VE1 (10.17.69.2)، وبالتالي يفترض VE2 أن VE1 معطل ويعمل كبروتوكول VRRP أساسي.
- تحقق من سلوك مكدس Meraki.
تشير لوحة معلومات Meraki إلى أن AP4 و AP3 في وضع إعادة الإرسال المتصل بمحول الربط 2 الذي يحصل على التنبيه إلى DNS التالف.
لتأكيد حالة المكدس، افتح Meraki TAC حيث تكون رسائل اتصال المكدس مرئية فقط ل Meraki TAC. عند التحقق، يتم تحديد أن مشاكل الاتصال داخل المكدس بين المحولات الأساسية والثانوية في المكدس.
كما أكدت Meraki أن هذه المشكلة نتجت عن حزمة VRRP من VE1 التي لم يتم الوصول إليها إلى VE2 عبر محول عضو المكدس 1(أساسي) من خلال عضو المكدس 2. هذه مشكلة معروفة في ال 12.28 رمز.
الحل
- إعادة تحميل جميع المحولات الأعضاء في المكدس (الإصلاح المؤقت).
- قم بترقية البرنامج الثابت لمحول Meraki إلى أحدث تصميم مستقر.