أستكشاف أخطاء سياسات أمان قائمة التحكم في الوصول (ACI) وإصلاحها - العقود

المقدمة

يصف هذا المستند خطوات فهم سياسات أمان قائمة التحكم في الوصول (ACI) واستكشاف أخطائها وإصلاحها، المعروفة باسم العقود.

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

استخرجت المادة من هذا المستند من أستكشاف أخطاء Cisco Application Centric Infrastructure وإصلاحها، الإصدار الثاني من كتاب، وخاصة سياسات الأمان - نظرة عامة، سياسات الأمان - الأدوات، سياسات الأمان - EPG إلى EPG، سياسات الأمان - المجموعة المفضلة وسياسات الأمان - vzAny إلى فصول EPG.

نظرة عامة

تتبع بنية الأمان الأساسية لحل قائمة التحكم في الوصول (ACI) نموذج قائمة السماح. ما لم يتم تكوين VRF في وضع غير مفروض، فإن كل تدفقات حركة مرور EPG إلى EPG يتم إسقاطها ضمنيا. كما هو ضمني في نموذج قائمة الترخيص من خارج المربع، فإن إعداد VRF الافتراضي يكون في الوضع فرض. يمكن السماح بتدفقات حركة المرور أو رفضها بشكل صريح من خلال تنفيذ قواعد تقسيم المناطق على عقد المحول. يمكن برمجة قواعد تقسيم المناطق هذه في مجموعة متنوعة من التكوينات المختلفة بناء على تدفق الاتصال المرغوب بين مجموعات نقاط النهاية (EPG) والطريقة المستخدمة في تعريفها. لاحظ أن إدخالات قاعدة التقسيم إلى مناطق ليست ذات حالة رسمية وستسمح/ترفض بشكل نموذجي بناء على المنفذ/المقبس نظرا لوجود وحدتي EPG بمجرد برمجة القاعدة.

أساليب برمجة قواعد تقسيم المناطق

وفيما يلي الأساليب الرئيسية لبرمجة قواعد تقسيم المناطق في إطار مبادرة التعاون في مجال الوصول:

• عقود EPG إلى EPG: تتطلب عادة مستهلك واحد على الأقل ومزود واحد برمجة قواعد تقسيم المناطق عبر مجموعتين أو أكثر من مجموعات نقاط النهاية المميزة.
• المجموعات المفضلة: يتطلب تمكين التجميع على مستوى VRF؛ يمكن أن توجد مجموعة واحدة فقط لكل VRF. يمكن لجميع أعضاء المجموعة التواصل بحرية. غير الأعضاء يحتاجون إلى عقود للسماح بالتدفق إلى المجموعة المفضلة.
• vzAny: 'مجموعة EPG' يتم تعريفها ضمن VRF معين. يمثل vzAny جميع EPGs في VRF. يسمح إستخدام vzAny بالتدفق بين واحد EPG وكل EPGs داخل VRF من خلال اتصال عقد واحد.

يمكن إستخدام المخطط التالي للإشارة إلى دقة قاعدة تقسيم المناطق التي يسمح بها كل من الأساليب المذكورة أعلاه للتحكم:

المقارنة بين منهجيات قاعدة تقسيم المناطق

وعند إستخدام طريقة التعاقد في برمجة قواعد تقسيم المناطق، هناك خيار لتحديد نطاق العقد. يجب أخذ هذا الخيار بعين الاعتبار بعناية في حالة الحاجة إلى تصميم خدمة مشترك/تسرب أي مسار. وإذا كانت الرغبة هي الانتقال من تردد عالي القيمة (VRF) إلى آخر داخل بنية واجهة برمجة التطبيقات (ACI)، فإن العقود هي الطريقة للقيام بذلك.

يمكن أن تكون قيم النطاق كما يلي:

• التطبيق: لن تعمل علاقة المستهلك/الموفر المتعاقد عليها إلا على برمجة القواعد بين مجموعات تطوير البرامج (EPG) التي تم تعريفها ضمن نفس ملف تعريف التطبيق. إعادة إستخدام العقد نفسه عبر بروتوكولات EPG الأخرى لملف تعريف التطبيق لن يسمح بالتقاطع بينها.
• VRF (الافتراضي): ستقوم علاقة مستهلك/مزود العقد ببرمجة القواعد بين مجموعات إدارة نظام ملفات الإنترنت (EPG) التي يتم تعريفها ضمن نفس VRF. إعادة إستخدام العقد نفسه عبر بروتوكولات EPG الأخرى لملف تعريف التطبيق سيسمح بالتقاطع بينها. وينبغي الحرص على ضمان عدم السماح بالتدفقات المرغوبة إلا، وإلا ينبغي تحديد عقد جديد لمنع التجاوز غير المقصود.
• المستأجر: ستقوم علاقة مستهلك/موفر العقد ببرمجة القواعد بين EPGs التي تم تعريفها داخل نفس المستأجر. إذا كانت هناك شبكات EPG مرتبطة بشبكات VRF متعددة داخل مستأجر واحد وتستهلك/توفر العقد نفسه، يمكن إستخدام هذا النطاق للحث على تسريب المسار للسماح بالاتصال بين شبكات VRF.
• عمومي: ستقوم علاقة مستهلك/مزود العقد ببرمجة القواعد بين EPGs عبر أي مستأجر داخل بنية ACI. وهذا هو أكبر نطاق ممكن للتعريف، وينبغي توخي الحذر الشديد عند تمكين ذلك في عقود محددة سابقا من أجل منع تسرب التدفق غير المقصود.

قراءة إدخال قاعدة تقسيم المناطق

وحالما تبرمج قاعدة تقسيم المناطق، ستظهر كالتالي على ورقة:

+---------+--------+--------+----------+----------------+---------+---------+-----------------+----------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  |       Name      |  Action  |       Priority       |
+---------+--------+--------+----------+----------------+---------+---------+-----------------+----------+----------------------+

• معرف القاعدة: معرف إدخال القاعدة. لا أهمية حقيقية سوى العمل كمعرف فريد.
• SRC EPG: معرف فريد لكل VRF (pcTag) من مجموعة نقطة النهاية المصدر.
• DST EPG: معرف فريد لكل VRF (pcTag) لمجموعة نقاط النهاية الوجهة.
• FilterID: معرف عامل التصفية الذي تحاول القاعدة مضاهاته. يحتوي عامل التصفية على معلومات البروتوكول التي ستتم مطابقة القاعدة لها.
• دير: مدى إتجاه قاعدة تقسيم المناطق.
• OperSt: حالة تشغيل القاعدة.
• النطاق: معرف فريد ل VRF الذي ستتم مطابقة القاعدة عليه.
• الاسم: اسم العقد الذي أدى إلى برمجة هذا الإدخال.
• العملية: ماذا تفعل الورقة عندما تطابق ذلك المدخل. تشمل: [إسقاط، تصريح، سجل، إعادة توجيه].
• الأولوية: الترتيب الذي سيتم به التحقق من صحة قواعد تقسيم المناطق للإجراء نظرا لإدخالات النطاق المتطابق و SrcEPG و DstEPG و Filter.

الذاكرة القابلة للتوجيه إلى المحتوى الخاص بالنهج (CAM)

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

تسرب التردد اللاسلكي، وعلامات الكمبيوتر العالمية، وتوجيه تطبيق السياسات لعمليات L3Out المشتركة

هذا وسيلة شرح خاصة لحالة إستخدام الخدمات المشتركة التي تتطلب تكوين العقود. تنطوي الخدمات المشتركة عادة على حركة مرور بين الترددات الخاصة الظاهرية (VRF) داخل بنية قائمة التحكم في الوصول (ACI) التي تعتمد على إستخدام عقد نطاق 'مستأجر' أو 'عمومي'. ولفهم ذلك بشكل كامل، يجب أولا تعزيز فكرة أن قيمة PCtag النموذجية التي تم تعيينها إلى EPG ليست فريدة بشكل عام. حيث يتم تحديد نطاق PCtags إلى VRF، ويمكن إعادة إستخدام نفس PCtag ضمن VRF آخر. عند ظهور مناقشة تسريب المسار، ابدأ في فرض المتطلبات على بنية واجهة التحكم في الوصول (ACI) بما في ذلك الحاجة إلى قيم فريدة عالميا بما في ذلك الشبكات الفرعية و PCtags.

والأمر الذي يجعل من هذا اعتبارا خاصا هو الجانب الاتجاهي المرتبط بتحول شركة "إي بي جي" إلى مستهلك في مقابل مقدم خدمات. في سيناريو الخدمات المشتركة، من المتوقع عادة أن يقوم الموفر بتشغيل PCtag عمومي للحصول على قيمة فريدة للقناة الليفية. وفي الوقت نفسه، سيحتفظ المستهلك ب VRF الخاص به والذي يضعه في وضع خاص يتيح له إمكانية برمجة وفهم إستخدام قيمة PCtag العالمية لتنفيذ النهج.

بالنسبة للمرجع، يكون نطاق تخصيص pcTag كما يلي:

• النظام المحجوز: 1-15.
• النطاق العالمي: 16-16384 لأجهزة EPG الخاصة بمزود الخدمات المشتركة.
• النطاقات المحلية: 16385-65535 لملقمات EPG ذات نطاق VRF.

توجيه فرض التحكم في سياسة VRF

في كل VRF، من الممكن تحديد إعداد إتجاه الإنفاذ.

• الإعداد الافتراضي لتوجيه الإنفاذ هو مدخل.
• الخيار الآخر لتوجيه الإنفاذ هو المخرج.

يعتمد فهم أين يتم فرض السياسة على عدة متغيرات مختلفة.

يساعد الجدول التالي في فهم أين يتم فرض سياسة الأمان على مستوى الورق.

أين يتم فرض السياسة؟

سيناريو	وضع فرض التردد اللاسلكي VRF	مستهلك	موفر	تم فرض النهج على
Intra-VRF	مدخل/مخرج	EPG	EPG	· إذا تم تعلم نقطة نهاية الوجهة: مدخل صفحة* · إذا لم يتم تعلم نقطة نهاية الوجهة: مخرج ورقة
	مدخل	EPG	L3Out EPG	ورقة مستهلكة (ورقة غير حدودية)
	مدخل	L3Out EPG	EPG	ورقة الموفر (ورقة غير حدود)
	مخرج	EPG	L3Out EPG	ورقة الحدود -> حركة مرور الأوراق غير الحدودية · إذا تم تعلم نقطة نهاية الوجهة: ورقة الحدود · إذا لم يتم تعلم نقطة نهاية الوجهة: ورقة غير حدود حركة مرور أوراق الحدود غير الحدودية · ورقة الحدود
	مخرج	L3Out EPG	EPG
	مدخل/مخرج	L3Out EPG	L3Out EPG	ورقة المدخل*
Inter-VRF	مدخل/مخرج	EPG	EPG	ورقة إستهلاكية
	مدخل/مخرج	EPG	L3Out EPG	ورقة مستهلكة (ورقة لا حدود لها)
	مدخل/مخرج	L3Out EPG	EPG	ورقة المدخل*
	مدخل/مخرج	L3Out EPG	L3Out EPG	ورقة المدخل*

*يتم تطبيق تطبيق النهج على أول ورقة يتم الوصول إليها بواسطة الحزمة.

يوضح الشكل التالي مثالا لإنفاذ العقود حيث يكون EPG-Web كمستهلك و L3Out EPG كموفر لديه عقد بين VRF. إذا تم تعيين VRF على وضع فرض الدخول، يتم فرض السياسة بواسطة العقد الطرفية حيث يتواجد EPG-Web. إن ثبتت VRF يكون إلى مخرج فرض أسلوب، سياسة فرض بالحدود ورقة عقد حيث L3Out يقيم إن VM-Web نقطة نهاية علمت على الحد ورقة.

تطبيق إجراءات الدخول والخروج

أدوات

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

التحقق من صحة قاعدة التقسيم إلى مناطق

يمكن إستخدام الأدوات والأوامر التالية للتحقق بشكل صريح من قواعد تقسيم المناطق التي يتم برمجتها على محولات طرفية نتيجة للعلاقات المكتملة مع المستهلك/الموفر الخاص بالعقد.

عرض قواعد تقسيم المناطق

أمر على مستوى المحول يعرض جميع قواعد تقسيم المناطق في موضعها.

leaf# show zoning-rule
+---------+--------+--------+----------+----------------+---------+----------+-----------------+----------+----------------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope   |       Name      |  Action  |          Priority          |
+---------+--------+--------+----------+----------------+---------+----------+-----------------+----------+----------------------------+
|   4156  |   25   | 16410  |   425    | uni-dir-ignore | enabled | 2818048  | external_to_ntp |  permit  |       fully_qual(7)        |
|   4131  | 16410  |   25   |   424    |     bi-dir     | enabled | 2818048  | external_to_ntp |  permit  |       fully_qual(7)        |
+---------+--------+--------+----------+----------------+---------+----------+-----------------+----------+----------------------------+

'show zoning-filter'

عامل تصفية يحتوي على معلومات الرياضة/المنفذ التي تعمل عليها قاعدة تقسيم المناطق. يمكن التحقق من برمجة المرشح باستخدام هذا الأمر.

leaf# show zoning-filter
+----------+----------+-------------+-------------+-------------+----------+-------------+-------------+-------------+-------------+----------+
| FilterId |   Name   |    EtherT   |     Prot    | ApplyToFrag | Stateful |  SFromPort  |   SToPort   |  DFromPort  |   DToPort   |   Prio   |
+----------+----------+-------------+-------------+-------------+----------+-------------+-------------+-------------+-------------+----------+
| implarp  | implarp  |     arp     | unspecified |      no     |    no    | unspecified | unspecified | unspecified | unspecified |  dport   |
| implicit | implicit | unspecified | unspecified |      no     |    no    | unspecified | unspecified | unspecified | unspecified | implicit |
|   425    |  425_0   |      ip     |     tcp     |      no     |    no    |     123     |     123     | unspecified | unspecified |  sport   |
|   424    |  424_0   |      ip     |     tcp     |      no     |    no    | unspecified | unspecified |     123     |     123     |  dport   |
+----------+----------+-------------+-------------+-------------+----------+-------------+-------------+-------------+-------------+----------+

'إظهار إحصائيات النهج الداخلي للنظام'

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

leaf# show system internal policy-mgr stats
Requested Rule Statistics
Rule (4131) DN (sys/actrl/scope-2818048/rule-2818048-s-16410-d-25-f-424) Ingress: 0, Egress: 0, Pkts: 0  RevPkts: 0
Rule (4156) DN (sys/actrl/scope-2818048/rule-2818048-s-25-d-16410-f-425) Ingress: 0, Egress: 0, Pkts: 0  RevPkts: 0

'show ip access-list internal packet log deny'

أمر على مستوى المحول يمكن تشغيله على مستوى iBaseH يقدم تقارير عن حالات السقوط ذات الصلة بقوائم التحكم في الوصول (ACL) (العقد) والمعلومات المتعلقة بالتدفق، بما في ذلك:

• VRF
• vlan-id
• Mac/Dest المصدر
• مصدر IP/DEST IP
• منفذ المصدر/المنفذ الأكبر
• واجهة المصدر

leaf# show logging ip access-list internal packet-log deny  
[ Tue Oct  1 10:34:37 2019 377572 usecs]: CName: Prod1:VRF1(VXLAN: 2654209), VlanType: Unknown, Vlan-Id: 0, SMac: 0x000c0c0c0c0c, DMac:0x000c0c0c0c0c, SIP: 192.168.21.11, DIP: 192.168.22.11, SPort: 0, DPort: 0, Src Intf: Tunnel7, Proto: 1, PktLen: 98
[ Tue Oct  1 10:34:36 2019 377731 usecs]: CName: Prod1:VRF1(VXLAN: 2654209), VlanType: Unknown, Vlan-Id: 0, SMac: 0x000c0c0c0c0c, DMac:0x000c0c0c0c0c, SIP: 192.168.21.11, DIP: 192.168.22.11, SPort: 0, DPort: 0, Src Intf: Tunnel7, Proto: 1, PktLen: 98

contract_parser

نص تنفيذي ل Python على الجهاز ينتج مخرجات تربط قواعد تقسيم المناطق، المرشحات وإحصائيات الوصول أثناء إجراء عمليات البحث عن الأسماء من المعرفات. هذا البرنامج النصي مفيد للغاية في أنه يأخذ عملية متعددة الخطوات ويحولها إلى أمر واحد يمكن تصفيته إلى EPGs/VRFs معينة أو على قيم أخرى متعلقة بالعقد.

leaf# contract_parser.py
Key:  
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]

[7:4131] [vrf:common:default] permit ip tcp tn-Prod1/ap-Services/epg-NTP(16410) tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123  [contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]  
[7:4156] [vrf:common:default] permit ip tcp tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123 tn-Prod1/ap-Services/epg-NTP(16410)  [contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]  
[12:4169] [vrf:common:default] deny,log any tn-Prod1/l3out-L3Out1/instP-extEpg(25) epg:any [contract:implicit] [hit=0]  
[16:4167] [vrf:common:default] permit any epg:any tn-Prod1/bd-Services(32789) [contract:implicit] [hit=0]

التحقق من صحة تصنيف الحزمة

ELAM

يستخدم تقرير مستوى ASIC للتحقق من تفاصيل إعادة التوجيه والتي تشير، في حالة الحزمة التي سقطت، إلى سبب الإسقاط. فيما يتعلق بهذا القسم، يمكن أن يكون السبب SECURITY_GROUP_DENY (إسقاط سياسة العقد).

fTriage

أداة قائمة على Python على APIC يمكنها تعقب تدفق الحزم من نهاية إلى نهاية مع ELAM.

تطبيق مساعد ELAM

تطبيق APIC يلخص تعقيد العديد من ASICs لجعل قرار إعادة التوجيه التفتيش أكثر سهولة وسهولة.

يرجى الرجوع إلى قسم "إعادة التوجيه بين البنى" للحصول على تفاصيل إضافية حول أدوات ELAM و fTriage و ELAM المساعدة

إستخدام حدبة النهج

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

طريقة عرض "السعة الطرفية" للوحة معلومات السعة

عرض الحالة الصحية الداخلية للنظام الأساسي

هذا الأمر مفيد للتحقق من مجموعة متنوعة من حدود الموارد واستخدامها، بما في ذلك حدبة النهج. لاحظ أن هذا الأمر يمكن تشغيله فقط في vsh_lc، لذلك قم بتمريره باستخدام علامة '-c' إذا كان يتم تشغيله من iBash.

leaf8# vsh_lc -c "show platform internal hal health-stats"
|Sandbox_ID: 0  Asic Bitmap: 0x0
|-------------------------------------
 ...
Policy stats:
=============
policy_count                  : 96
max_policy_count              : 65536
policy_otcam_count            : 175
max_policy_otcam_count            : 8192
policy_label_count                : 0
max_policy_label_count            : 0
=============

EPG إلى EPG

اعتبارات إسقاط السياسة العامة

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

بعض الأسئلة عالية المستوى التي تستحق أن تطرح قبل الغوص فيها:

• هل نقاط النهاية متطابقة أم مختلفة؟
  • يتم رفض حركة المرور بين نقطتي نهاية مقيمتين في EPG مختلفة (بين EPG) بشكل ضمني وتتطلب جهة اتصال للسماح بالاتصال.
  • يسمح ضمنيا بحركة المرور بين نقطتي نهاية داخل نفس EPG (intra-EPG)، ما لم تكن العزل بين نقاط النهاية قيد الاستخدام.
• هل تم فرض إطار التردد اللاسلكي أو عدم فرضه؟
  • عندما يكون VRF في الوضع فرض ، — ضمن VRF — يلزم عقد لنقاط النهاية في وحدتين مختلفتين من EPG للاتصال.
  • عندما يكون VRF في وضع غير مفروض ، — داخل VRF - سيتم السماح بجميع حركات مرور البيانات من خلال بنية قائمة التحكم في الوصول (ACI) عبر العديد من بروتوكولات EPG التي تنتمي إلى بروتوكول VRF غير المفروض، بغض النظر عن عقود قائمة التحكم في الوصول (ACI) المطبقة.

منهجية

وبالاستعانة بالأدوات المختلفة المتاحة، هناك بعض الأدوات الأكثر ملاءمة وملاءمة للبدء بها من غيرها، اعتمادا على مستوى المعلومات المعروفة بالفعل عن التدفق المتضرر.

هل يعرف المسار الكامل للحزمة في بنية ACI (مدخل ورقة، مخرج صفحة...)؟

• إذا كانت الإجابة نعم، فيجب إستخدام مساعد ELAM لتحديد سبب الإسقاط في محول المصدر أو الوجهة.
• إذا كانت الإجابة لا، فإن أوامر Visibility & Troubleshooting و fTriage و contract_parser و Operation في طريقة عرض المستأجر و iBash ستساعد على تضييق مسار الحزمة أو منح مزيد من الرؤية في أسباب الإسقاط.

يرجى ملاحظة أنه لن يتم مناقشة أداة الفرز بالتفصيل في هذا القسم. ارجع إلى الفصل "إعادة التوجيه داخل البنية" للحصول على مزيد من التفاصيل حول إستخدام هذه الأداة.

ضع في الاعتبار أنه في حين يمكن أن تساعد الرؤية واستكشاف الأخطاء وإصلاحها في التصور السريع لأماكن إسقاط الحزم بين نقطتي نهاية، إلا أن تطبيق FTriage يظهر مزيدا من المعلومات التفصيلية لمزيد من أستكشاف الأخطاء وإصلاحها. على سبيل المثال، ستساعد ميزة Triage في تحديد الواجهة وسبب الإسقاط والتفاصيل الأخرى منخفضة المستوى حول التدفق المتضرر

.

يوضح سيناريو المثال التالي كيفية أستكشاف أخطاء السياسة وإصلاحها بين نقطتي نهاية: 192.168.21.11 و 192.168.23.11

بافتراض حدوث عمليات إسقاط حزم بين نقطتي النهاية هاتين، سيتم إستخدام سير عمل أستكشاف الأخطاء وإصلاحها التالية لتحديد السبب الجذري للمشكلة:

التعرف على ورقة (أوراق) SRC/DST المعنية بتدفق حركة المرور:

1. أستخدم إمكانية الرؤية واستكشاف الأخطاء وإصلاحها لتتبع تدفق الحزمة والتعرف على الجهاز الذي يقوم بإسقاط الحزمة.
2. قم بتشغيل الأمر "show logging ip access-list internal packet-log deny" على الجهاز المحدد.
   • إذا تم رفض حزمة تحتوي على أحد عناوين IP ذات الفائدة وتسجيلها، فإن سجل الحزم سيطبع نقطة النهاية ذات الصلة واسم العقد على أساس كل ضغطة.
3. أستخدم الأمر 'contract_parser.py —vrf <tenant>:<VRF>' على ورقة المصدر والوجهة لمراقبة عدد مرات الوصول للعقد الذي تم تكوينه:
   • إذا كانت الحزمة تصل إلى العقد إما على المحول المصدر أو الوجهة، فسيزداد عداد العقد ذي الصلة
   • هذه الطريقة أقل دقة من طريقة سجل الحزم الداخلي لقائمة وصول IP في الحالات التي يمكن أن يصل فيها العديد من التدفقات إلى نفس القاعدة (العديد من نقاط النهاية/التدفقات بين وحدتي EPG موضع الاهتمام).

ويرد وصف أكثر للخطوات المذكورة أعلاه في الفقرة التالية.

مثال أستكشاف أخطاء سيناريو EPG إلى EPG وإصلاحها

يوضح سيناريو المثال كيفية أستكشاف أخطاء السياسة وإصلاحها بين نقطتي نهاية: 192.168.21.11 في EPG-Web و 192.168.23.11 في EPG-DB.

طوبولوجيا

التعرف على المحولات الطرفية المصدر والوجهة المعنية في إسقاط الحزمة

إمكانية الرؤية واستكشاف الأخطاء وإصلاحها

ستساعد أداة الرؤية واستكشاف الأخطاء وإصلاحها في عرض المحول حيث حدث إسقاط الحزمة لتدفق معين من EP إلى EP والتعرف على مكان إسقاط الحزم المحتمل.

تكوين إمكانية الرؤية واستكشاف الأخطاء وإصلاحها

تكوين اسم جلسة ومصدر ونقطة نهاية وجهة. ثم انقر فوق 'إرسال' أو 'إنشاء تقرير'.

وسوف تجد الأداة تلقائيا نقاط النهاية في النسيج وتوفر معلومات عن المستأجر وملف تعريف التطبيق وبيانات EPG التي تنتمي إليها.

في هذه الحالة، سيكتشف أن EPs تنتمي إلى Prod1 المستأجر، وتنتمي إلى نفس ملف تعريف التطبيق 'AppProf' ويتم تعيينها إلى EPGs مختلفة: 'Web' و'DB'.

تعريف الإسقاط

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

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

والواقع أن العديد من حالات السقوط هذه تعد سلوكا متوقعا ومن الممكن تجاهلها.

تفاصيل الإسقاط

بالحفر لأسفل للتفاصيل المنسدلة باستخدام الزر الأصفر "الحزم المسقطة" على مخطط المحول، يمكن للمستخدم عرض تفاصيل حول التدفق المسقط.

تفاصيل العقد

من خلال الانتقال إلى القائمة الفرعية العقود، يمكن للمستخدم تحديد العقد الذي يتسبب في إسقاط النهج بين وحدات EPG. في المثال، من الضمني رفض Prod1/VRF1 الذي يظهر بعض النتائج. لا يعني هذا بالضرورة أن التدفق المحدد (192.168.21.11 و 192.168.23.11) يضرب هذا الرفض الضمني. إذا كانت قاعدة "نتائج الرفض الضمني للسياق" في أزدياد، فإنها تعني ضمنا وجود حركة مرور بين PROD1/DB و PROD1/Web لا تصل إلى أي من العقود، وبالتالي يتم إسقاطها بواسطة الرفض الضمني.

في عرض طبولوجيا ملف تعريف التطبيق في المستأجر > تحديد اسم ملف تعريف التطبيق على اليسار > الطبولوجيا ، من الممكن التحقق من العقود التي يتم تطبيقها على DB EPG. وفي هذه الحالة، لا يتم تعيين عقد إلى EPG:

عرض العقد

الآن، وبعد أن أصبحت ملقمات EPG المصدر والوجهة معروفة، من الممكن أيضا تحديد معلومات أخرى ذات صلة مثل ما يلي:

• SRC/DST EPG PCtag لنقاط النهاية المتأثرة. PCtag هو معرف الفئة المستخدم لتعريف EPG باستخدام قاعدة تقسيم المناطق.
• SRC/DST VRFNid، المشار إليه أيضا بنطاق، لنقاط النهاية المتأثرة.

يمكن إسترداد معرف الفئة والنطاق بسهولة من واجهة المستخدم الرسومية (GUI) لواجهة المستخدم الرسومية (APIC) من خلال فتح المستأجر > تحديد اسم المستأجر على اليسار > تشغيل > معرفات الموارد > EPG

معرف مورد المستأجر للعثور على EPG PCtag والنطاق

في هذه الحالة يكون معرف الفئة والنطاقات:

• Web EPG PCtag 32778
• نطاق EPG على الويب 2654209
• DB EPG PCtag 49159
• نطاق DB EPG 2654209

تحقق من تطبيق النهج على تدفق حركة المرور الذي يسبب المشاكل

آي باش

إحدى الأدوات المثيرة للاهتمام للتحقق من أن الحزمة التي تم إسقاطها على ورقة قائمة التحكم في الوصول (ACI) هي سطر الأوامر iBash: 'show logging ip access-list internal packet-log deny':

leaf5# show logging ip access-list internal packet-log deny | grep 192.168.21.11
[2019-10-01T14:25:44.746528000+09:00]: CName: Prod1:VRF1(VXLAN: 2654209), VlanType: FD_VLAN, Vlan-Id: 114, SMac: 0xf6f26c4ec8d0, DMac:0x0022bdf819ff, SIP: 192.168.21.11, DIP: 192.168.23.11, SPort: 0, DPort: 0, Src Intf: Ethernet1/19, Proto: 1, PktLen: 126
[2019-10-01T14:25:44.288653000+09:00]: CName: Prod1:VRF1(VXLAN: 2654209), VlanType: FD_VLAN, Vlan-Id: 116, SMac: 0x3e2593f0eded, DMac:0x0022bdf819ff, SIP: 192.168.23.11, DIP: 192.168.21.11, SPort: 0, DPort: 0, Src Intf: Ethernet1/19, Proto: 1, PktLen: 126

وفقا للناتج السابق، يمكن ملاحظة أنه على المحول الطرفي، تم إسقاط العديد من حزم ICMP التي تم الحصول عليها من EP 192.168.23.11 نحو 192.168.21.11.

ستساعد أداة contract_parser على التحقق من السياسات الفعلية المطبقة على VRF حيث نقاط النهاية مرتبطة ب:

leaf5# contract_parser.py --vrf Prod1:VRF1
Key:
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]

[7:5159] [vrf:Prod1:VRF1] permit ip tcp tn-Prod1/ap-App1/epg-App(32771) eq 5000 tn-Prod1/ap-App1/epg-Web(32772)  [contract:uni/tn-Prod1/brc-web_to_app] [hit=0]
[7:5156] [vrf:Prod1:VRF1] permit ip tcp tn-Prod1/ap-App1/epg-Web(32772) tn-Prod1/ap-App1/epg-App(32771) eq 5000  [contract:uni/tn-Prod1/brc-web_to_app] [hit=0]
[16:5152] [vrf:Prod1:VRF1] permit any epg:any tn-Prod1/bd-Web(49154) [contract:implicit] [hit=0]
[16:5154] [vrf:Prod1:VRF1] permit arp epg:any epg:any [contract:implicit] [hit=0]
[21:5155] [vrf:Prod1:VRF1] deny,log any epg:any epg:any [contract:implicit] [hit=38,+10]
[22:5153] [vrf:Prod1:VRF1] deny,log any epg:any pfx-0.0.0.0/0(15) [contract:implicit] [hit=0]

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

leaf5# show zoning-rule scope 2654209
+---------+--------+--------+----------+----------------+---------+----------+------------+----------+-------------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope   |    Name    |  Action  |         Priority        |
+---------+--------+--------+----------+----------------+---------+----------+------------+----------+-------------------------+
|   5155  |   0    |   0    | implicit |    uni-dir     | enabled | 2654209  |            | deny,log |     any_any_any(21)     |
|   5159  | 32771  | 32772  |   411    | uni-dir-ignore | enabled | 2654209  | web_to_app |  permit  |      fully_qual(7)      |
|   5156  | 32772  | 32771  |   410    |     bi-dir     | enabled | 2654209  | web_to_app |  permit  |      fully_qual(7)      |
+---------+--------+--------+----------+----------------+---------+----------+------------+----------+-------------------------+

كما هو موضح مسبقا بواسطة أداة الرؤية واستكشاف الأخطاء وإصلاحها وأداة contract_parser وقواعد المناطق، يؤكد الإخراج عدم وجود عقد بين وحدات حماية مستوى التحكم في المصدر والوجهة في أستكشاف الأخطاء وإصلاحها. من السهل افتراض أن الحزم التي تم إسقاطها تطابق قاعدة الرفض الضمني 5155.

أسر ELAM

يوفر التقاط ELAM تقريرا عن مستوى ASIC يستخدم للتحقق من تفاصيل إعادة التوجيه والتي تشير، في حالة الحزمة التي تم إسقاطها، إلى سبب الإسقاط. عندما يكون سبب السقوط هو حدوث إسقاط في السياسة، كما هو الحال في هذا السيناريو، فإن مخرجات التقاط ELAM ستبدو كما يلي.

يرجى ملاحظة أنه لن تتم مناقشة تفاصيل إعداد التقاط ELAM في هذا الفصل، الرجاء مراجعة الفصل "إعادة التوجيه بين البنى".

leaf5# vsh_lc
module-1# debug platform internal tah elam asic 0
module-1(DBG-elam)# trigger init in-select 6 out-select 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 192.168.21.11 dst_ip 192.168.23.11
module-1(DBG-elam-insel6)# start
module-1(DBG-elam-insel6)# status

ELAM STATUS
===========
Asic 0 Slice 0 Status Triggered
Asic 0 Slice 1 Status Armed

module-1(DBG-elam-insel6)# ereport | grep reason
RW drop reason                          : SECURITY_GROUP_DENY
LU drop reason                          : SECURITY_GROUP_DENY
    pkt.lu_drop_reason: 0x2D

يظهر تقرير ELAM أعلاه بوضوح أن الحزمة تم إسقاطها بسبب إسقاط سياسة: 'SECURITY_GROUP_DENY'

مساعد ELAM:

ويمكن عرض النتيجة نفسها لأسر ELAM من خلال تطبيق مساعد ELAM على واجهة المستخدم الرسومية APIC.

التكوين

بشكل نموذجي، سيقوم المستخدم بتكوين كل من تفاصيل المصدر والوجهة لتدفق الفائدة. في هذا المثال، يتم إستخدام SRC IP لالتقاط حركة المرور نحو نقطة النهاية في EPG الوجهة التي ليس لها علاقة عقد مع EPG المصدر.

تقرير مساعد ELAM Express

هناك ثلاثة مستويات من الإنتاج يمكن مشاهدتها مع مساعد ELAM. وهذه التفاصيل واضحة وخام.

تقرير مساعد ELAM Express (تابع)

تحت "النتيجة السريعة"، يشير سبب الرمز الإسقاط SECURITY_GROUP_DENY إلى أن الإسقاط كان نتيجة لإبرام عقد.

المجموعة المفضلة

حول المجموعات المفضلة للعقود

هناك نوعان من عمليات فرض السياسة المتاحة ل EPGs في VRF مع تكوين مجموعة مفضلة بموجب عقد:

• (أ) وحدات حماية البيئة المدرجة: يمكن أن تتصل وحدات حماية البيئة بحرية مع بعضها البعض بدون عقود، إذا كانت لديها عضوية في مجموعة مفضلة بموجب عقد. ويعتمد هذا على القاعدة الافتراضية source-any-destination-any-allowed.
• وحدات حماية البيئة المستبعدة: تتطلب مجموعات حماية البيئة غير الأعضاء في المجموعات المفضلة عقودا للتواصل مع بعضها البعض. وإلا، يتم تطبيق قواعد الرفض بين EPG المستبعد وأي EPG.

تتيح ميزة المجموعة المفضلة للعقد إمكانية تحكم أكبر في الاتصال بين بروتوكولات إدارة الشبكة (EPG) في إطار VRF. إذا كان ينبغي أن يكون لمعظم مجموعات إدارة الموارد البشرية في إطار التردد اللاسلكي اتصال مفتوح، ولكن لا ينبغي أن يكون لبعضها سوى اتصال محدود مع مجموعات إدارة الموارد البشرية الأخرى، فقم بتكوين مزيج من مجموعة تفضل العقود والعقود مع عوامل التصفية للتحكم في الاتصال بين مجموعات إدارة الموارد البشرية (EPG) بشكل أدق.

لا يمكن ل EPGs المستبعدة من المجموعة المفضلة الاتصال إلا ب EPGs أخرى إذا كان هناك عقد في موضعه لتجاوز القاعدة الافتراضية source-any-destination-any-deny.

برمجة مجموعة العقود المفضلة

وفي الأساس، فإن المجموعات المفضلة للعقود هي عكس للعقود العادية. بالنسبة للعقود العادية، تتم برمجة قواعد تقسيم المناطق التصريحة الخاصة بالرخص باستخدام قاعدة رفض تقسيم المناطق ضمنيا مع نطاق التردد اللاسلكي الظاهري (VRF). بالنسبة للمجموعات المفضلة، تتم برمجة قاعدة تقسيم السماح الضمني باستخدام أعلى قيمة أولوية عددية كما تتم برمجة قواعد تقسيم الرفض المحددة لعدم السماح بحركة المرور من EPGs التي ليست أعضاء مجموعة مفضلة. ونتيجة لذلك، يتم تقييم قواعد الرفض أولا وإذا لم يكن التدفق متطابقا مع هذه القواعد، حينئذ يتم السماح بالتدفق ضمنيا.

هناك دائما زوج من قواعد الرفض الصريحة لتقسيم المناطق لكل EPG خارج المجموعة المفضلة:

• واحد من عضو المجموعة غير المفضل إلى أي PCtag (القيمة 0).
• آخر من أي pcTag (القيمة 0) إلى عضو المجموعة غير المفضل.

سيناريو أستكشاف أخطاء المجموعة المفضلة وإصلاحها

يوضح الشكل التالي طوبولوجيا منطقية يتم فيها تكوين تطبيق EPGs و App2 و App3 كأعضاء مفضلين في المجموعة.

يعد VM-App جزءا من EPG-App، كما يعد VM-App2 جزءا من EPG-App2. يجب أن يكون كل من App و App2 EPG جزءا من التطبيق المفضل، ومن ثم يجب الاتصال بحرية.

يقوم VM-App ببدء تدفق حركة مرور البيانات على منفذ TCP رقم 6000 إلى VM-App2. يعد كل من EPG-App و EPG-App2 أعضاء المجموعة المفضلين كجزء من VRF1. لا يتلقى VM-App2 أبدا أي حزم على منفذ TCP 6000.

طوبولوجيا

سير العمل

1. ابحث في PCtag الخاص بتطبيق EPG و VRF الخاص به/النطاق

EPG و VRF PCtags

2. تحقق من برمجة العقود باستخدام contract_parser.py على ورقة الدخول

أستخدم الأمر contract_parser.py و/أو الأمر 'show zoning-rule' وحدد معرف فئة المورد (VRF)

fab3-leaf8# show zoning-rule scope 2654209
+---------+--------+--------+----------+---------+---------+---------+------+----------+----------------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |   Dir   |  operSt |  Scope  | Name |  Action  |          Priority          |
+---------+--------+--------+----------+---------+---------+---------+------+----------+----------------------------+
|   4165  |   0    |   0    | implicit | uni-dir | enabled | 2654209 |      |  permit  | grp_any_any_any_permit(20) |  
|   4160  |   0    |   0    | implarp  | uni-dir | enabled | 2654209 |      |  permit  |     any_any_filter(17)     |
|   4164  |   0    |   15   | implicit | uni-dir | enabled | 2654209 |      | deny,log | grp_any_dest_any_deny(19)  |
|   4176  |   0    | 16386  | implicit | uni-dir | enabled | 2654209 |      |  permit  |      any_dest_any(16)      |
|   4130  | 32770  |   0    | implicit | uni-dir | enabled | 2654209 |      | deny,log |  grp_src_any_any_deny(18)  |
|   4175  | 49159  |   0    | implicit | uni-dir | enabled | 2654209 |      | deny,log |  grp_src_any_any_deny(18)  |
|   4129  |   0    | 49159  | implicit | uni-dir | enabled | 2654209 |      | deny,log | grp_any_dest_any_deny(19)  |
|   4177  | 32778  |   0    | implicit | uni-dir | enabled | 2654209 |      | deny,log |  grp_src_any_any_deny(18)  |
|   4128  |   0    | 32778  | implicit | uni-dir | enabled | 2654209 |      | deny,log | grp_any_dest_any_deny(19)  |
|   4178  | 32775  |   0    | implicit | uni-dir | enabled | 2654209 |      | deny,log |  grp_src_any_any_deny(18)  |
|   4179  |   0    | 32775  | implicit | uni-dir | enabled | 2654209 |      | deny,log | grp_any_dest_any_deny(19)  |
+---------+--------+--------+----------+---------+---------+---------+------+----------+----------------------------+

fab3-leaf8# contract_parser.py --vrf Prod1:VRF1
Key:
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]
[16:4176] [vrf:Prod1:VRF1] permit any epg:any tn-Prod1/bd-App(16386) [contract:implicit] [hit=0]
[16:4160] [vrf:Prod1:VRF1] permit arp epg:any epg:any [contract:implicit] [hit=0]
[18:4130] [vrf:Prod1:VRF1] deny,log any tn-Prod1/vrf-VRF1(32770) epg:any [contract:implicit] [hit=?]
[18:4178] [vrf:Prod1:VRF1] deny,log any epg:32775 epg:any [contract:implicit] [hit=?]
[18:4177] [vrf:Prod1:VRF1] deny,log any epg:32778 epg:any [contract:implicit] [hit=?]
[18:4175] [vrf:Prod1:VRF1] deny,log any epg:49159 epg:any [contract:implicit] [hit=?]
[19:4164] [vrf:Prod1:VRF1] deny,log any epg:any pfx-0.0.0.0/0(15) [contract:implicit] [hit=0]
[19:4179] [vrf:Prod1:VRF1] deny,log any epg:any epg:32775 [contract:implicit] [hit=?]
[19:4128] [vrf:Prod1:VRF1] deny,log any epg:any epg:32778 [contract:implicit] [hit=?]
[19:4129] [vrf:Prod1:VRF1] deny,log any epg:any epg:49159 [contract:implicit] [hit=?]
[20:4165] [vrf:Prod1:VRF1] permit any epg:any epg:any [contract:implicit] [hit=65]

وبفحص الناتج المذكور أعلاه، يلاحظ إدخال تصريح ضمني - معرف القاعدة 4165 - مع أعلى أولوية وهي 20. ستؤدي قاعدة السماح الضمني هذه إلى السماح بجميع تدفقات حركة المرور ما لم تكن هناك قاعدة رفض صريحة ذات أولوية أقل تمنع تدفق حركة المرور.

بالإضافة إلى ذلك، تمت ملاحظة قاعدتي رفض صريحتين ل pcTag 32775 وهما pcTag ل EPG App2. لا يسمح هذان النوعان الصريحان من قواعد تقسيم المناطق بحركة المرور من أي EPG إلى EPG App2، والعكس بالعكس. ولتلك القواعد الأولوية 18 و 19، ولذلك فإنها ستنال الأسبقية على قاعدة السماح الافتراضي.

والاستنتاج هو أن EPG App2 ليس عضوا مفضلا في المجموعة مع مراعاة قواعد الرفض الصريحة.

3. التحقق من تكوين أعضاء المجموعة المفضلة ل EPG

قم بالتنقل في واجهة المستخدم الرسومية (GUI) الخاصة ب APIC وتحقق من تكوين أعضاء المجموعة المفضلة لتطبيق EPG2 و EPG، في الشكل التالي، لم يتم تكوين EPG App2 كعضو مفضل في المجموعة.

EPG App2 — تم إستبعاد إعداد أعضاء المجموعة المفضلة

تطبيق EPG — تم تضمين إعداد عضو المجموعة المفضل

4. تعيين EPG App2 ليكون عضوا مفضلا في المجموعة

يؤدي تغيير تكوين App2 EPG إلى تمكين المجموعة المفضلة من الاتصال بحرية كجزء من المجموعة المفضلة.

EPG App2 — تم تضمين إعداد عضو المجموعة المفضل

5. إعادة التحقق من برمجة العقود باستخدام contract_parser.py على الورقة حيث يوجد SRC EP

أستخدم contract_parser.py مرة أخرى وحدد اسم VRF للتحقق مما إذا كانت قواعد الرفض الصريحة لتطبيق EPG2 قد إختفت الآن.

fab3-leaf8# contract_parser.py --vrf Prod1:VRF1
Key:
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]
[16:4176] [vrf:Prod1:VRF1] permit any epg:any tn-Prod1/bd-App(16386) [contract:implicit] [hit=0]
[16:4160] [vrf:Prod1:VRF1] permit arp epg:any epg:any [contract:implicit] [hit=0]
[18:4175] [vrf:Prod1:VRF1] deny,log any epg:16390 epg:any [contract:implicit] [hit=0]
[18:4167] [vrf:Prod1:VRF1] deny,log any epg:23 epg:any [contract:implicit] [hit=0]
[18:4156] [vrf:Prod1:VRF1] deny,log any tn-Prod1/vrf-VRF1(32770) epg:any [contract:implicit] [hit=0]
[18:4168] [vrf:Prod1:VRF1] deny,log any epg:49159 epg:any [contract:implicit] [hit=0]
[19:4164] [vrf:Prod1:VRF1] deny,log any epg:any pfx-0.0.0.0/0(15) [contract:implicit] [hit=0]
[19:4169] [vrf:Prod1:VRF1] deny,log any epg:any epg:16390 [contract:implicit] [hit=0]
[19:4159] [vrf:Prod1:VRF1] deny,log any epg:any epg:23 [contract:implicit] [hit=0]
[19:4174] [vrf:Prod1:VRF1] deny,log any epg:any epg:49159 [contract:implicit] [hit=0]
[20:4165] [vrf:Prod1:VRF1] permit any epg:any epg:any [contract:implicit] [hit=65]

لم تعد تلاحظ قواعد الرفض الصريحة ل EPG App2 و PCtag 32775 في الإخراج أعلاه. وهذا يعني أن حركة المرور بين وحدات EP في تطبيق EPG و EPG App2 ستطابق الآن قاعدة الترخيص الضمني - القاعدة 4165 - مع أعلى أولوية وهي 20.

vzAny to EPG

حول VzAny

عند تكوين العقود بين واحد أو أكثر من EPG، يمكن تكوين العقود كعلاقة مستهلكة أو مقدمة. وعندما يزداد عدد مجموعات حماية البيئة، يزداد كذلك مقدار علاقات العقود فيما بينها. تتطلب بعض حالات الاستخدام الشائعة قيام جميع بروتوكولات EPG بتبادل تدفقات حركة المرور مع EPG محدد آخر. وقد تكون حالة الاستخدام هذه عبارة عن EPG يحتوي على وحدات EP توفر الخدمات التي يلزم إستهلاكها بواسطة جميع مجموعات EPG الأخرى داخل نفس VRF (NTP أو DNS على سبيل المثال). تسمح VZany بمصروفات تشغيل أقل في تكوين علاقات العقد بين جميع مجموعات EPG ووحدات EPG محددة توفر الخدمات التي يجب إستهلاكها بواسطة جميع شبكات EPG الأخرى. بالإضافة إلى ذلك، تسمح VZany باستخدام CAM لنهج الأمان على المحولات الطرفية بقدر أكبر من الكفاءة حيث تتم إضافة قاعدتي تقسيم فقط لكل علاقة من علاقات العقود الخاصة ب VZany.

مثال على حالة الاستخدام

يصف الشكل التالي حالة إستخدام من هذا القبيل حيث يحتاج VM-Web و VM-App في EPGs Web و App على التوالي إلى إستهلاك خدمات NTP من VM-NTP في EPG-NTP. وبدلا من تكوين عقد مقدم على EPG NTP، وبالتالي الحصول على نفس العقد كعقد مستهلك على موقع EPGs Web and App، فإن VZany يسمح لكل EPG في VRF Prod:VRF1 باستهلاك خدمات NTP من EPG NTP.

vzAny — يمكن أن يستهلك أي بروتوكول EPG في VRF Prod:VRF1 خدمات NTP من EPG NTP

ضع في الاعتبار سيناريو يتم فيه ملاحظة حالات انخفاض بين مجموعات تطوير البرامج (EPG) التي تستهلك خدمات NTP عند عدم وجود عقد بينها.

سيناريو أستكشاف الأخطاء وإصلاحها - تسقط حركة المرور إذا لم يكن هناك عقد

سير العمل

1. ابحث في PCtag الخاص ب EPG NTP و VRF الخاص به/النطاق

يسمح 'Tenant>Operational > Resource IDs > EPGs' بالعثور على pcTag والنطاق

EPG NTP PCtag و VRF الخاص به vNID/Scope

2. التحقق من تكوين عقد كعقد vzAny مستهلك كجزء من VRF

انتقل إلى VRF وتحقق مما إذا كان هناك عقد مستهلك تم تكوينه ك vzAny ضمن "مجموعة EPG ل VRF".

تم تكوين العقد كعقد vzAny مستهلك على VRF

3. التحقق من تطبيق العقد نفسه كعقد مقدم على EPG NTP

ومن أجل إقامة علاقة تعاقدية، يلزم تطبيق نفس العقد كعقد مقدم بشأن بروتوكول وقت الشبكة EPG NTP الذي يوفر خدمات بروتوكول وقت الشبكة (NTP) إلى مجموعات الشركاء الأقران الأخرى في إطار التردد اللاسلكي الخاص بها.

4. التحقق من قاعدة تقسيم المناطق على ورقة الدخول باستخدام contract_parser.py أو 'show zoning-rule'

يجب أن تحتوي ورقة المدخل على قاعدتي تقسيم للسماح بتدفق حركة المرور ثنائية الإتجاه (إذا تم تعيين موضوع العقد للسماح بالاتجاهين) بين أي EPG و EPG NTP. ويشار إلى 'Any EPG' على أنه pcTag 0 في برمجة قاعدة تقسيم المنطقة.

يسمح إستخدام أمر contract_parser.py أو أمر 'show zoning-rule' على المدخل ورقة أثناء تحديد VRF التأكد من برمجة قاعدة التقسيم إلى مناطق.

قواعد تقسيم المناطق التي تسمح بحركة المرور من/إلى EPG NTP من بروتوكولات EPG الأخرى في التردد اللاسلكي الحالي

إستخدام contract_parser.py و'show zoning-rule' للتحقق من وجود قواعد تقسيم المناطق المستندة إلى vzAny.

هنا يوجد نوعان من القواعد الواضحة:

1. القاعدة 4156 والقاعدة 4168 التي تسمح لأي منهما بممارسة التجارة عبر الوطنية والعكس بالعكس. ولهما الأولوية 13 و 14:
   • قاعدة التقسيم إلى مناطق تسمح بتدفق حركة المرور من أي EPG (pcTag 0) إلى EPG NTP (pcTag 49161).
   • قاعدة التقسيم إلى مناطق تسمح بتدفق حركة المرور من EPG NTP (pcTag 46161) إلى أي EPG آخر (pcTag 0).
2. القاعدة 4165 وهي قاعدة أي إلى أي رفض (تقصير) بالأولوية 21.

ونظرا لأن الأولوية الدنيا لها الأولوية، فسيكون لجميع مجموعات إدارة الموارد البشرية (VRF) حق الوصول إلى NTP EPG.

fab3-leaf8# contract_parser.py --vrf Prod1:VRF
Key:
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]

[13:4156] [vrf:Prod1:VRF1] permit ip tcp tn-Prod1/ap-Services/epg-NTP(49161) eq 123 epg:any  [contract:uni/tn-Prod1/brc-any_to_ntp] [hit=0]
[14:4168] [vrf:Prod1:VRF1] permit ip tcp epg:any tn-Prod1/ap-Services/epg-NTP(49161) eq 123  [contract:uni/tn-Prod1/brc-any_to_ntp] [hit=0]
[16:4176] [vrf:Prod1:VRF1] permit any epg:any tn-Prod1/bd-App(16386) [contract:implicit] [hit=0]
[16:4174] [vrf:Prod1:VRF1] permit any epg:any tn-Prod1/bd-Services(32776) [contract:implicit] [hit=0]
[16:4160] [vrf:Prod1:VRF1] permit arp epg:any epg:any [contract:implicit] [hit=0]
[21:4165] [vrf:Prod1:VRF1] deny,log any epg:any epg:any [contract:implicit] [hit=65]
[22:4164] [vrf:Prod1:VRF1] deny,log any epg:any pfx-0.0.0.0/0(15) [contract:implicit] [hit=0]

fab3-leaf8# show zoning-rule scope 2654209
+---------+--------+--------+----------+---------+---------+---------+------------+----------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |   Dir   |  operSt |  Scope  |    Name    |  Action  |       Priority       |
+---------+--------+--------+----------+---------+---------+---------+------------+----------+----------------------+
|   4165  |   0    |   0    | implicit | uni-dir | enabled | 2654209 |            | deny,log |   any_any_any(21)    |
|   4160  |   0    |   0    | implarp  | uni-dir | enabled | 2654209 |            |  permit  |  any_any_filter(17)  |
|   4164  |   0    |   15   | implicit | uni-dir | enabled | 2654209 |            | deny,log | any_vrf_any_deny(22) |
|   4176  |   0    | 16386  | implicit | uni-dir | enabled | 2654209 |            |  permit  |   any_dest_any(16)   |
|   4174  |   0    | 32776  | implicit | uni-dir | enabled | 2654209 |            |  permit  |   any_dest_any(16)   |
|   4168  |   0    | 49161  |   424    | uni-dir | enabled | 2654209 | any_to_ntp |  permit  | any_dest_filter(14)  |
|   4156  | 49161  |   0    |   425    | uni-dir | enabled | 2654209 | any_to_ntp |  permit  |  src_any_filter(13)  |
+---------+--------+--------+----------+---------+---------+---------+------------+----------+----------------------+

L3Out مشترك إلى EPG

حول L3Out المشترك

Shared Layer 3 Out هو تكوين يسمح بوجود L3Out في واحد VRF يوفر بعض الخدمات (وصول خارجي) وواحد أو أكثر من VRFs آخر يستهلك هذا L3Out. يمكن العثور على مزيد من التفاصيل حول L3Out المشترك في الفصل "التوجيه الخارجي".

عند تنفيذ L3Out مشترك يوصى بأن يكون موفر العقد هو L3Out المشترك و EPG هو المستهلك للعقد. سيتم توضيح هذا السيناريو في هذا القسم.

ولا يوصى بالقيام بعكس ذلك، أي أن L3Out يستهلك خدمة تقدمها شركة EPG. وسبب ذلك يتعلق بقابلية التطوير نظرا لأنه تم تثبيت قواعد تقسيم المناطق على VRF الخاص بالمستهلك فقط للخدمات المشتركة. وتشير مبادئ إستهلاك وتوفير البيانات إلى المكان الذي تبدأ فيه تدفقات حركة المرور. مع فرض سياسات الدخول بشكل افتراضي، هذا يعني أن تنفيذ السياسة سيتم تطبيقه على جانب المستهلك وبشكل أكثر تحديدا على المدخل الورقة (ورقة خارج الحدود). يتطلب المدخل ورقة أن يفرض سياسة ال pcTag من الغاية. في هذا السيناريو، تكون الوجهة هي EPG pcTag الخارجي. وبالتالي تقوم ورقة المدخل بتنفيذ السياسة وإعادة توجيه الحزم إلى ورقة الحدود. تستلم ورقة الحدود الحزمة على رابط البنية الخاص بها التي تقوم بعمل بحث عن المسار (LPM) وإعادة توجيه الحزمة إلى التجاور لبادئة الوجهة.

غير أن ورقة الحدود لا تنفذ أي إنفاذ للسياسة عند إرسال حركة المرور إلى EP الوجهة ولا تقوم بذلك على تدفق حركة المرور العائدة إلى المصدر EP.

ونتيجة لذلك، تم تثبيت الإدخالات (في VRF الخاص بالمستهلك) بواسطة حدبة النهج لورقة BL غير المتوفرة بالمدخل فقط ولا تتأثر حدبة نهج BL.

أستكشاف أخطاء L3out المشتركة وإصلاحها

سير العمل

1. التحقق من EPG PCtag و VRF VNID/Scope ل EPG للمستهلك

مع L3Out مشترك، ركبت ال zoning-rules فقط في مستهلك VRF. يجب أن يحتوي الموفر على PCtag عمومي (أقل من 16 كيلو) يسمح باستخدام PCtag هذا في كافة VRFs للمستهلك. في السيناريو الخاص بنا، يكون الموفر هو EPG الخارجي وسيحتوي على PCtag عمومي. سيكون ل EPG المستهلك PCtag محلي كالمعتاد.

EPG للمستهلك

2. التحقق من PcTag و VRF VNID/Scope الخاص ب الموفر L3Out EPG

كما هو موضح في الخطوة 1، المزود L3Out EPG يتلقى شامل مدى pcTag كبادئات من L3Out والتي يتم تسريبها إلى المستهلك VRF. ونتيجة لذلك، يتطلب الأمر L3Out EPG PCtag لعدم تداخل علامات تمييز الكمبيوتر في VRF المستهلك، وبالتالي فهي تقع ضمن نطاق pcTag العام.

EPG الخارجي الخاص بالمزود

3. تحقق من أن EPG الخاص بالمستهلك لديه عقد خاص بالمستأجر مستورد أو عقد عمومي تم تكوينه

يستهلك EPG NTP للمستهلك مع الشبكة الفرعية المعرفة بموجب EPG/BD عقد النطاق 'مستأجر' أو 'عمومي'

العقد الذي يستهلكه EPG

4. تحقق مما إذا كان BD الخاص ب EPG المستهلك يحتوي على شبكة فرعية تم تكوينها بنطاقها على 'مشتركة بين VRFs'

يتم تكوين الشبكة الفرعية ل EPG تحت مجال الجسر ولكن يجب أن يكون لها علامة "مشترك بين VRF" (للسماح بالتسرب الموجه) وعلامة "معلن عنها خارجيا" (للسماح بالإعلان عن L3Out)

5. تحقق من أن L3Out EPG للموفر لديه عقد نطاق مستأجر مستورد أو عقد عمومي تم تكوينه

يجب أن يحتوي EPG الخاص ب L3Out على عقد خاص بالمستأجر أو عقد عمومي تم تكوينه كعقد تم توفيره.

عقد على الموفر L3Out

6. تحقق مما إذا كان لدى موفر L3Out EPG شبكة فرعية تم تكوينها بالنطاقات الضرورية التي تم فحصها

يجب أن يحتوي موفر L3Out EPG على البادئة المراد تسريبها والتي تم تكوينها باستخدام النطاقات التالية:

• الشبكات الفرعية الخارجية ل EPG الخارجي.
• الشبكة الفرعية للتحكم في المسار المشترك.
• الشبكة الفرعية لاستيراد الأمان المشترك.

لمزيد من التفاصيل حول علامة الشبكة الفرعية في L3Out EPG راجع الفصل "إعادة التوجيه الخارجية".

إعدادات الشبكة الفرعية EPG الخارجية

تم توسيع إعدادات شبكة EPG الفرعية الخارجية

7. التحقق من البطاقة الشخصية لشبكة L3Out EPG الفرعية على الشبكة غير BL الخاصة ب VRF المستهلك

عند إدخال حركة المرور الموجهة إلى الشبكة الفرعية EPG الخارجية للشبكة غير BL، يتم إجراء بحث مقابل بادئة الوجهة لتحديد pcTag. يمكن التحقق من هذا باستخدام الأمر التالي على BL.

لاحظ أن هذا المخرج مأخوذ في نطاق VNI 2818048 وهو معرف فئة المورد (VRF) للمستهلك. من خلال النظر إلى الجدول، يمكن للمستهلك العثور على pcTag الخاص بالوجهة، على الرغم من أنه ليس في نفس VRF.

fab3-leaf8# vsh -c 'show system internal policy-mgr prefix' | egrep 'Vrf-Vni|==|common:default'
Vrf-Vni VRF-Id Table-Id Table-State  VRF-Name                    Addr                                Class Shared Remote Complete
======= ======  =========== =======  ============================ ================================= ====== ====== ====== ========
2818048 19     0x13          Up     common:default                                       0.0.0.0/0   15      False  False  False
2818048 19     0x80000013    Up     common:default                                            ::/0   15      False  False  False
2818048 19     0x13          Up     common:default                                   172.16.10.0/24  25      True   True   False

يوضح الإخراج أعلاه الجمع بين الشبكة الفرعية L3Out EPG والكمبيوتر الشخصي العالمي 25 الخاص بها.

8. التحقق من قواعد تقسيم المناطق المبرمجة على BL الخاصة ب VRF للمستهلك

أستخدم الأمر 'contract_parser.py' أو الأمر 'show zoning-rule' وحدد معرف فئة المورد (VRF).

أدناه مخرج أمر عرض إثنان قاعدة تقسيم إلى مناطق ركبت للسماح بحركة مرور من المستهلك EPG محلي pcTag 16410 إلى L3Out EPG شامل pcTag 25. هذا في النطاق 2818048، وهو نطاق VRF للمستهلك.

fab3-leaf8# show zoning-rule scope 2818048
+---------+--------+--------+----------+----------------+---------+---------+-----------------+----------+-----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  |       Name      |  Action  |        Priority       |
+---------+--------+--------+----------+----------------+---------+---------+-----------------+----------+-----------------------+
|   4174  |   0    |   0    | implarp  |    uni-dir     | enabled | 2818048 |                 |  permit  |   any_any_filter(17)  |
|   4168  |   0    |   15   | implicit |    uni-dir     | enabled | 2818048 |                 | deny,log |  any_vrf_any_deny(22) |
|   4167  |   0    | 32789  | implicit |    uni-dir     | enabled | 2818048 |                 |  permit  |    any_dest_any(16)   |
|   4159  |   0    |   0    | implicit |    uni-dir     | enabled | 2818048 |                 | deny,log |    any_any_any(21)    |
|   4169  |   25   |   0    | implicit |    uni-dir     | enabled | 2818048 |                 | deny,log | shsrc_any_any_deny(12)|
|   4156  |   25   | 16410  |   425    | uni-dir-ignore | enabled | 2818048 | external_to_ntp |  permit  |     fully_qual(7)     |
|   4131  | 16410  |   25   |   424    |     bi-dir     | enabled | 2818048 | external_to_ntp |  permit  |     fully_qual(7)     |
+---------+--------+--------+----------+----------------+---------+---------+-----------------+----------+-----------------------+

fab3-leaf8# contract_parser.py  --vrf common:default
Key:
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]

[7:4131] [vrf:common:default] permit ip tcp tn-Prod1/ap-Services/epg-NTP(16410) tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123  [contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]
[7:4156] [vrf:common:default] permit ip tcp tn-Prod1/l3out-L3Out1/instP-extEpg(25) eq 123 tn-Prod1/ap-Services/epg-NTP(16410)  [contract:uni/tn-Prod1/brc-external_to_ntp] [hit=0]
[12:4169] [vrf:common:default] deny,log any tn-Prod1/l3out-L3Out1/instP-extEpg(25) epg:any [contract:implicit] [hit=0]
[16:4167] [vrf:common:default] permit any epg:any tn-Prod1/bd-Services(32789) [contract:implicit] [hit=0]
[16:4174] [vrf:common:default] permit arp epg:any epg:any [contract:implicit] [hit=0]
[21:4159] [vrf:common:default] deny,log any epg:any epg:any [contract:implicit] [hit=0]
[22:4168] [vrf:common:default] deny,log any epg:any pfx-0.0.0.0/0(15) [contract:implicit] [hit=0]

9. التحقق من قواعد تقسيم المناطق المبرمجة على BL الخاصة بالمزود VRF

أستخدم الأمر 'contract_parser.py' أو الأمر 'show zoning-rule' وحدد معرف فئة المورد (VRF). تظهر مخرجات الأمر التالية أنه لا توجد قواعد تقسيم محددة في VRF الخاص بالمزود كما تم توضيحه عدة مرات من قبل.

إنه في النطاق 2719752 الذي هو نطاق VRF الخاص بالموفر.

border-leaf# show zoning-rule scope 2719752
+---------+--------+--------+----------+----------------+---------+---------+--------------+----------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  |     Name     |  Action  |       Priority       |
+---------+--------+--------+----------+----------------+---------+---------+--------------+----------+----------------------+
|   4134  | 10937  |   24   | default  | uni-dir-ignore | enabled | 2719752 | vrf1_to_vrf2 |  permit  |    src_dst_any(9)    |
|   4135  |   24   | 10937  | default  |     bi-dir     | enabled | 2719752 | vrf1_to_vrf2 |  permit  |    src_dst_any(9)    |
|   4131  |   0    |   0    | implicit |    uni-dir     | enabled | 2719752 |              | deny,log |   any_any_any(21)    |
|   4130  |   0    |   0    | implarp  |    uni-dir     | enabled | 2719752 |              |  permit  |  any_any_filter(17)  |
|   4132  |   0    |   15   | implicit |    uni-dir     | enabled | 2719752 |              | deny,log | any_vrf_any_deny(22) |
+---------+--------+--------+----------+----------------+---------+---------+--------------+----------+----------------------+

border-leaf# contract_parser.py --vrf Prod1:VRF3
Key:
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]

[9:4134] [vrf:Prod1:VRF3] permit any tn-Prod1/l3out-L3Out1/instP-extEpg2(10937) tn-Prod1/l3out-L3Out2/instP-extEpg2(24) [contract:uni/tn-Prod1/brc-vrf1_to_vrf2] [hit=0]
[9:4135] [vrf:Prod1:VRF3] permit any tn-Prod1/l3out-L3Out2/instP-extEpg2(24) tn-Prod1/l3out-L3Out1/instP-extEpg2(10937) [contract:uni/tn-Prod1/brc-vrf1_to_vrf2] [hit=0]
[16:4130] [vrf:Prod1:VRF3] permit arp epg:any epg:any [contract:implicit] [hit=0]
[21:4131] [vrf:Prod1:VRF3] deny,log any epg:any epg:any [contract:implicit] [hit=0]
[22:4132] [vrf:Prod1:VRF3] deny,log any epg:any pfx-0.0.0.0/0(15) [contract:implicit] [hit=0]