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

المقدمة

يصف هذا وثيقة steps أن يفهم واستكشاف أخطاء L3out في ACI

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

استخرجت المادة من هذا المستند من أستكشاف أخطاء البنية الأساسية المرتكزة على تطبيق Cisco وإصلاحها، وكتاب الإصدار الثاني وخاصة إعادة التوجيه الخارجي- نظرة عامة، وإعادة التوجيه الخارجي - التجاور، وإعادة التوجيه الخارجية - إعلان المسار، وإعادة التوجيه الخارجية - العقد والخروج من L3وإعادة التوجيه الخارجية - مشاركة فصول L3out.

نظرة عامة

مكونات L3Out

توضح الصورة التالية الوحدات البنائية الرئيسية المطلوبة لتكوين L3 خارج (L3Out).

المكونات الرئيسية ل L3Out

1. جذر L3Out:
   • حدد بروتوكول توجيه ليتم نشره (مثل OSPF و BGP).
   • حدد VRF لنشر بروتوكول التوجيه.
   • حدد مجال L3Out لتعريف الواجهات الطرفية المتوفرة وشبكة VLAN ل L3Out.
2. ملف تعريف العقدة:
   • حدد المحولات الطرفية لنشر بروتوكول التوجيه. وتعرف هذه المحولات عادة باسم "المحولات الطرفية المحدودة" (BL).
   • قم بتكوين Router-id (RID) لبروتوكول التوجيه على كل ورقة حدود. وعلى عكس الموجه العادي، لا تقوم قائمة التحكم في الوصول (ACI) بتعيين Router-ID تلقائيا استنادا إلى عنوان IP على المحول.
   • تكوين مسار ثابت.
3. ملف تعريف الواجهة:
   • قم بتكوين واجهات الأوراق لتشغيل بروتوكول التوجيه.
     أي نوع الواجهة (SVI و routed-port و subinterface) ومعرف الواجهة وعناوين IP وما إلى ذلك.
   • حدد سياسة لمعلمات بروتوكول توجيه مستوى الواجهة (مثل الفاصل الزمني مرحبا).
4. EPG خارجي (L3Out EPG):
   • يعد 'EPG الخارجي' متطلبا صعبا لنشر جميع السياسات المرتبطة ب L3Out، مثل عناوين IP أو SVIs لإنشاء جيران. وستغطى لاحقا تفاصيل عن كيفية إستخدام شبكات EPG الخارجية.

التوجيه الخارجي

يوضح المخطط التالي العملية عالية المستوى المعنية بالتوجيه الخارجي.

تدفق توجيه خارجي عالي المستوى

1. ستقوم الخادم (BL) بإنشاء عمليات تجاور بروتوكول التوجيه مع الموجهات الخارجية.
2. يتم تلقي بادئات المسار من الموجهات الخارجية ويتم حقنها في MP-BGP كمسار فئة عنوان VPNv4.
   • يجب على الأقل تكوين عقدتين عموديتين كعاكسات مسار BGP لعكس المسارات الخارجية لجميع العقد الطرفية.
3. يجب إعادة توزيع البادئات الداخلية (شبكات BD الفرعية) و/أو البادئات المستلمة من L3Out الأخرى بشكل صريح في بروتوكول التوجيه للإعلان عنها إلى الموجه الخارجي.
4. فرض الأمان: يحتوي L3Out على L3Out EPG واحد على الأقل. يجب إستهلاك عقد أو توفيره على L3Out EPG (يسمى أيضا l3extInstP من اسم الفئة) للسماح بحركة المرور في/خارج L3Out.

خيارات تكوين L3Out EPG

في قسم EPG الخاص ب L3Out، يمكن تحديد الشبكات الفرعية باستخدام سلسلة من خيارات "النطاق" و"التجميع" كما هو موضح أدناه:

شبكة فرعية L3Out يتم تعريفها بما في ذلك تعريف "النطاق"

خيارات 'النطاق':

• تصدير الشبكة الفرعية للتحكم في المسار: الغرض من هذا النطاق هو الإعلان (تصدير) عن شبكة فرعية من ACI إلى الخارج عبر L3Out. وعلى الرغم من أن هذا يتم أساسا لتوجيه النقل، إلا أن هذا يمكن إستخدامه أيضا للإعلان عن شبكة BD الفرعية كما هو موضح في قسم "إعلان الشبكة الفرعية ل ACI BD".
• الشبكة الفرعية للتحكم في المسار للاستيراد: يتعلق هذا النطاق بتعلم (إستيراد) شبكة فرعية خارجية من L3Out. بشكل افتراضي، يتم تعطيل هذا النطاق، وبالتالي يتم حفره إلى الخارج، وتعلم ورقة الحدود (BL) أي مسارات من بروتوكول التوجيه. يمكن تمكين هذا النطاق عندما يحتاج إلى تقييد المسارات الخارجية التي تم التعرف عليها عبر OSPF و BGP. هذا غير مدعوم ل EIGRP. لاستخدام هذا النطاق، يلزم تمكين 'إستيراد فرض التحكم في المسار' أولا على L3Out معين.
• الشبكات الفرعية الخارجية ل EPG الخارجي (import-security): يستخدم هذا النطاق للسماح بالحزم ذات الشبكة الفرعية التي تم تكوينها من أو إلى L3Out مع عقد. وهو يصنف حزمة في L3Out EPG الذي تم تكوينه استنادا إلى الشبكة الفرعية حتى يمكن تطبيق عقد على L3Out EPG على الحزمة. هذا النطاق هو أطول تطابق للبادئة بدلا من تطابق تام مثل النطاقات الأخرى لجدول التوجيه. إذا تم تكوين 10.0.0.0/16 باستخدام "الشبكات الفرعية الخارجية ل EPG الخارجي" في L3Out EPG A، فسيتم تصنيف أي حزم ذات IP في تلك الشبكة الفرعية، مثل 10.0.1.1، في L3Out EPG A لاستخدام عقد عليها. لا يعني هذا أن "الشبكات الفرعية الخارجية لنطاق EPG الخارجي" تقوم بتثبيت مسار 10.0.0.0/16 في جدول توجيه. وسينشئ جدولا داخليا مختلفا لتعيين شبكة فرعية إلى EPG (pcTag) فقط للعقد. ولا يؤثر على سلوكيات بروتوكول التوجيه. يتم تكوين هذا النطاق على L3Out الذي يتعلم الشبكة الفرعية.
• الشبكة الفرعية للتحكم في المسار المشترك: الغرض من هذا النطاق هو تسريب شبكة فرعية خارجية إلى شبكة VRF أخرى. تستخدم واجهة التحكم في الوصول (ACI) بروتوكول MP-BGP وهدف المسار لتسريب مسار خارجي من موجه VRF إلى آخر. يقوم هذا النطاق بإنشاء قائمة البادئات مع الشبكة الفرعية، والتي يتم إستخدامها كعامل تصفية لتصدير/إستيراد المسارات باستخدام هدف المسار في MP-BGP. هذا مجال أن يكون شكلت على L3Out أن يعلم الشبكة الفرعية في ال VRF أصلي.
• الشبكة الفرعية لاستيراد الأمان المشترك: يتم إستخدام هذا النطاق للسماح بالحزم باستخدام الشبكة الفرعية التي تم تكوينها عندما تنتقل الحزم عبر VRF باستخدام L3Out. يتم تسريب مسار في جدول توجيه إلى منفذ VRF آخر باستخدام "الشبكة الفرعية المشتركة للتحكم في المسار" كما هو مذكور أعلاه. ومع ذلك، لم يعرف بعد عامل آخر من أجل إعادة التوجيه (VRF) إلى أي موقع ينبغي للمسار المسرب أن ينتمي. تقوم "الشبكة الفرعية لاستيراد الأمان المشترك" بإعلام VRF آخر ب L3Out EPG الذي ينتمي إليه المسار المسرب. وبالتالي، يمكن إستخدام هذا النطاق فقط عند إستخدام "الشبكات الفرعية الخارجية ل EPG الخارجي" أيضا، وإلا فإن VRF الأصلي لا يعرف أي L3Out EPG تنتمي الشبكة الفرعية إلى أي منهما. هذا النطاق أيضا هو أطول تطابق للبادئة.

خيارات 'التجميع':

• التصدير الكلي: يمكن إستخدام هذا الخيار ل 0.0.0.0/0 فقط مع 'الشبكة الفرعية للتحكم في مسار التصدير'. عند تمكين كل من 'تصدير الشبكة الفرعية للتحكم في المسار' و'التصدير الكلي' ل 0.0.0.0/0، فإنها تقوم بإنشاء قائمة البادئات مع '0.0.0.0/0 le 32' التي تطابق أي شبكات فرعية. وبالتالي، يمكن إستخدام هذا الخيار عندما يحتاج L3Out للإعلان (تصدير) عن أي مسارات إلى الخارج. عندما يكون مطلوبا مزيد من التجميع متعدد المستويات، يمكن إستخدام خريطة/ملف تعريف المسار مع قائمة بادئات صريحة.
• إستيراد التجميع: يمكن إستخدام هذا الخيار ل 0.0.0.0/0 فقط مع 'الشبكة الفرعية للتحكم في مسار الاستيراد'. عند تمكين كل من 'إستيراد الشبكة الفرعية للتحكم في المسار' و'إستيراد التجميع' ل 0.0.0.0/0، فإنها تقوم بإنشاء قائمة البادئات ب '0.0.0.0/0 le 32' التي تطابق أي شبكات فرعية. وبالتالي، يمكن إستخدام هذا الخيار عندما يحتاج L3Out إلى معرفة (إستيراد) أي مسارات من الخارج. ومع ذلك، يمكن تحقيق الأمر نفسه من خلال تعطيل "فرض التحكم في المسار للاستيراد" وهو الإعداد الافتراضي. عندما يكون مطلوبا مزيد من التجميع متعدد المستويات، يمكن إستخدام خريطة/ملف تعريف المسار مع قائمة بادئات صريحة.
• تجميع المسارات المشتركة: يمكن إستخدام هذا الخيار لأي شبكات فرعية باستخدام "الشبكة الفرعية للتحكم في المسار المشترك". عند تمكين كل من "الشبكة الفرعية للتحكم في المسار المشترك" و"تجميع المسارات المشتركة" ل 10.0.0.0/8 كمثال، فإنها تقوم بإنشاء قائمة بادئات مع "10.0.0.0/8 le 32" تطابق 10.0.0.0/8 و 10.1.0.0/16 وما إلى ذلك.

مخطط L3Out المستخدم في هذا القسم

سيتم إستخدام المخطط التالي في هذا القسم:

طوبولوجيا L3Out

تجاور

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

فيما يلي بضعة معلمات للتحقق من أنها ستكون قابلة للتطبيق على جميع بروتوكولات التوجيه الخارجية الخاصة بواجهة التحكم في الوصول (ACI):

• معرف الموجه: في قائمة التحكم في الوصول (ACI)، يحتاج كل L3Out إلى إستخدام معرف الموجه نفسه في VRF نفسه على نفس الصفحة حتى إذا كانت بروتوكولات التوجيه مختلفة. أيضا، فقط واحد من تلك L3out على ال نفسه ورقة يستطيع خلقت إسترجاع مع المسحاج تخديد id، أي يكون عادة BGP.
• MTU: على الرغم من أن المتطلب الصعب ل MTU هو لتجاور OSPF فقط، إلا أنه يوصى لمطابقة MTU لأي بروتوكولات توجيه لضمان أن أي حزم كبيرة تستخدم لتبديل/تحديثات المسار يمكن إرسالها دون تجزئة، حيث أنه سيتم إرسال معظم إطارات مستوى التحكم مع مجموعة بت DF (عدم التجزئة)، والتي ستسقط الإطار إذا تجاوز حجمها الحد الأقصى ل MTU للواجهة.
• عاكس موجه MP-BGP: بدون هذا، لن تبدأ عملية BGP على العقد الطرفية. وعلى الرغم من أن ذلك ليس مطلوبا من OSPF أو EIGRP لمجرد إنشاء جار، فإنه لا يزال مطلوبا من المحولات الطرفية لتوزيع المسارات الخارجية على عقد طرفية أخرى.
• الأخطاء: تأكد دائما من فحص الأخطاء أثناء اكتمال التكوين وبعده.

BGP

يستخدم هذا القسم مثالا على تجانس eBGP بين الاسترجاع في BL3، BL4، و R34 من المخطط في قسم النظرة العامة. BGP AS في R34 هو 65002.

تحقق من المعايير التالية عند إنشاء تجاور BGP.

• BGP المحلي كرقم (جانب ACI BL).

ملف تعريف اتصال النظير — محلي

سيكون رقم BGP AS الخاص بمستخدم L3Out تلقائيا هو نفسه BGP كما هو الحال بالنسبة ل infra-MP-BGP الذي تم تكوينه في سياسة عاكس مسار BGP. لا يكون تكوين "المحلي باسم" في ملف تعريف اتصال نظير BGP مطلوبا ما لم يحتاج المرء إلى إخفاء بروتوكول BGP لقائمة التحكم في الوصول (ACI) كما هو الحال في العالم الخارجي. وهذا يعني أن الموجهات الخارجية يجب أن تشير إلى BGP كما تم تكوينه في عاكس مسار BGP.

ملاحظة — السيناريو الذي يتطلب تكوين محلي AS هو نفسه الأمر NX-OS 'local-as' المستقل.

• رقم BGP البعيد كرقم (الجانب الخارجي)

  ملف تعريف اتصال النظير — وحدة التحكم في الوصول عن بعد

  

  ال BGP البعيد كرقم مطلوب فقط ل eBGP حيث BGP المجاور مختلف من ACI BGP as.

  • مصدر IP لجلسة عمل نظير BGP.

  L3Out — ملف تعريف اتصال نظير BGP

  

  تدعم واجهة التحكم في الوصول (ACI) توفير جلسة عمل BGP من واجهة الاسترجاع الموجودة أعلى نوع واجهة ACI L3Out النموذجية (موجه، واجهة فرعية، SVI).

  عندما يحتاج BGP جلسة أن يكون sourced من loopback، شكلت ال BGP نظير موجز تحت ال منطقي عقدة ملف تعريف.

  عندما يحتاج ال BGP جلسة أن يكون sourced من مسحاج تخديد/subinterface/SVI، شكلت ال BGP نظير موضح تحت ال منطقي قارن ملف تعريف.

  • إمكانية الوصول إلى بروتوكول IP لنظير BGP.

  ملف تعريف العقدة المنطقي — اقتران العقدة

  

  عندما تكون عناوين IP النظيرة ل BGP عبارة عن إرتباطات، فتأكد من توفر إمكانية الوصول إلى عنوان IP للموجه الخارجي وشبكة BL. يمكن إستخدام المسارات الثابتة أو OSPF للحصول على إمكانية الوصول إلى عناوين IP النظيرة.

  التحقق من واجهة سطر الأوامر (CLI) ل BGP (eBGP مع مثال إسترجاع)

  يتم تجميع مخرجات واجهة سطر الأوامر (CLI) للخطوات التالية من الخادم النصلي (BL3) في المخطط من قسم النظرة العامة.

  1. التحقق مما إذا تم إنشاء جلسة BGP

  يعني "State/PfxRcd" في إخراج واجهة سطر الأوامر (CLI) التالي إنشاء جلسة BGP.

f2-leaf3# show bgp ipv4 unicast summary vrf Prod:VRF1
BGP summary information for VRF Prod:VRF1, address family IPv4 Unicast
BGP router identifier 10.0.0.3, local AS number 65001

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.134      4 65002      10      10       10    0    0 00:06:39 0

إذا كانت 'State/PfxRcd' تظهر خاملة أو نشطة، فلا يتم تبادل حزم BGP مع النظير بعد. في مثل هذا السيناريو، تحقق من التالي وانتقل إلى الخطوة التالية.

• تأكد من أن الموجه الخارجي يشير إلى BGP الخاص بواجهة التحكم في الوصول (ACI) بشكل صحيح (محلي ك رقم 65001).
• تأكد من أن ملف تعريف اتصال نظير BGP الخاص ب ACI يحدد IP المجاور الصحيح الذي يقوم الموجه الخارجي منه باستيراد جلسة BGP (10.0.0.134).
• تأكد من أن ملف تعريف اتصال نظير BGP الخاص بواجهة التحكم في الوصول (ACI) يحدد المجاور الصحيح كما هو الحال مع الموجه الخارجي (رقم النظام الذاتي عن بعد في واجهة المستخدم الرسومية (GUI) الذي يظهر في CLI ك AS 65002).

2. التحقق من تفاصيل جار BGP (ملف تعريف اتصال نظير BGP)

يعرض الأمر التالي المعلمات التي هي مفتاح لإنشاء جار BGP.

• IP المجاور: 10.0.0.134.
• BGP المجاور ك: بعيد ك 65002.
• المصدر IP: إستخدام الاسترجاع 3 كمصدر تحديث.
• بروتوكول eBGP متعدد الخطوات: قد يكون نظير BGP الخارجي على بعد حتى نقطتين.

f2-leaf3# show bgp ipv4 unicast neighbors vrf Prod:VRF1
BGP neighbor is 10.0.0.134,  remote AS 65002, ebgp link,  Peer index 1
 BGP version 4, remote router ID 10.0.0.134
 BGP state = Established, up for 00:11:18
 Using loopback3 as update source for this peer
 External BGP peer might be upto 2 hops away
 
...

  For address family: IPv4 Unicast
...
Inbound route-map configured is permit-all, handle obtained
Outbound route-map configured is exp-l3out-BGP-peer-3047424, handle obtained
Last End-of-RIB received 00:00:01 after session start
Local host: 10.0.0.3, Local port: 34873
 Foreign host: 10.0.0.134, Foreign port: 179
 fd = 64

بمجرد إنشاء نظير BGP بشكل صحيح، يظهر كل من "المضيف المحلي" و"المضيف الخارجي" في أسفل الإخراج.

3. التحقق من إمكانية الوصول إلى IP لنظير BGP

f2-leaf3# show ip route vrf Prod:VRF1
10.0.0.3/32, ubest/mbest: 2/0, attached, direct
   *via 10.0.0.3, lo3, [0/0], 02:41:46, local, local
   *via 10.0.0.3, lo3, [0/0], 02:41:46, direct
10.0.0.134/32, ubest/mbest: 1/0
   *via 10.10.34.1, vlan27, [1/0], 02:41:46, static    <--- neighbor IP reachability via static route
10.10.34.0/29, ubest/mbest: 2/0, attached, direct
   *via 10.10.34.3, vlan27, [0/0], 02:41:46, direct
   *via 10.10.34.2, vlan27, [0/0], 02:41:46, direct
10.10.34.2/32, ubest/mbest: 1/0, attached
   *via 10.10.34.2, vlan27, [0/0], 02:41:46, local, local
10.10.34.3/32, ubest/mbest: 1/0, attached
   *via 10.10.34.3, vlan27, [0/0], 02:41:46, local, local

تأكد من عمل إختبار الاتصال إلى IP المجاور من مصدر IP الخاص ب ACI BGP.

f2-leaf3# iping 10.0.0.134 -V Prod:VRF1 -S 10.0.0.3
PING 10.0.0.134 (10.0.0.134) from 10.0.0.3: 56 data bytes
64 bytes from 10.0.0.134: icmp_seq=0 ttl=255 time=0.571 ms
64 bytes from 10.0.0.134: icmp_seq=1 ttl=255 time=0.662 ms

4. تحقق من نفس الشيء على الموجه الخارجي

فيما يلي مثال على التكوين على الموجه الخارجي (NX-OS المستقل).

router bgp 65002
 vrf f2-bgp
   router-id 10.0.0.134
   neighbor 10.0.0.3
     remote-as 65001
     update-source loopback134
     ebgp-multihop 2
     address-family ipv4 unicast
   neighbor 10.0.0.4
     remote-as 65001
     update-source loopback134
     ebgp-multihop 2
     address-family ipv4 unicast

interface loopback134
 vrf member f2-bgp
 ip address 10.0.0.134/32
 
interface Vlan2501
 no shutdown
 vrf member f2-bgp
 ip address 10.10.34.1/29

vrf context f2-bgp
 ip route 10.0.0.0/29 10.10.34.2

5. خطوة إضافية — tcpdump

على العقد الطرفية المرتكزة على التطبيقات، يمكن لأداة tcpdump التقاط واجهة وحدة المعالجة المركزية (CPU) ل 'kpm_inb' لتأكيد ما إذا كانت حزم البروتوكول تصل إلى وحدة المعالجة المركزية (CPU) الطرفية. أستخدم منفذ L4 179 (BGP) كمرشح.

f2-leaf3# tcpdump -ni kpm_inb port 179
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on kpm_inb, link-type EN10MB (Ethernet), capture size 65535 bytes
20:36:58.292903 IP 10.0.0.134.179 > 10.0.0.3.34873: Flags [P.], seq 3775831990:3775832009, ack 807595300, win 3650, length 19: BGP, length: 19
20:36:58.292962 IP 10.0.0.3.34873 > 10.0.0.134.179: Flags [.], ack 19, win 6945, length 0
20:36:58.430418 IP 10.0.0.3.34873 > 10.0.0.134.179: Flags [P.], seq 1:20, ack 19, win 6945, length 19: BGP, length: 19
20:36:58.430534 IP 10.0.0.134.179 > 10.0.0.3.34873: Flags [.], ack 20, win 3650, length 0

بروتوكول أقصر مسار أولاً (OSPF)

يستخدم هذا القسم مثالا لعلاقات الجوار عبر OSPF بين BL3 و BL4 و R34 من المخطط في قسم "نظرة عامة" مع OSPF AreaID 1 (NSSA).

ما يلي هي المعايير الشائعة للتحقق من إنشاء تجاور OSPF.

• معرف منطقة OSPF والنوع

L3Out — ملف تعريف واجهة OSPF — معرف المنطقة والنوع

يجب أن يتطابق معرف منطقة OSPF والنوع مع أي جهاز توجيه. تتضمن بعض القيود الخاصة بواجهة برمجة التطبيقات (ACI) على تكوينات معرف منطقة OSPF:

• يمكن أن يحتوي L3Out واحد على معرف منطقة OSPF واحد فقط.
• يمكن أن يستخدم إثنان L3out نفس معرف منطقة OSPF في نفس VRF فقط عندما يكونون على عقدتين طرفيتين مختلفتين.

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

• MTU

ملف تعريف الواجهة المنطقي — SVI

تكون وحدة الحد الأقصى للنقل (MTU) الافتراضية على قائمة التحكم في الوصول (ACI) 9000 بايت، بدلا من 1500 بايت، وهو عادة الإعداد الافتراضي المستخدم على أجهزة التوجيه التقليدية. تأكد من تطابق وحدة الحد الأقصى للنقل (MTU) مع الجهاز الخارجي. عندما يفشل إنشاء جار OSPF بسبب MTU، فإنه يعلق في Exchange/DROTHER.

• قناع شبكة IP الفرعية. يتطلب OSPF أن يستخدم IP المجاور قناع الشبكة الفرعية نفسه.
• ملف تعريف واجهة OSPF.

ملف تعريف واجهة OSPF

وهذا يعادل 'ip router ospf <tag> area <area id>' على تكوين NX-OS مستقل لتمكين OSPF على الواجهة. وبدون ذلك، لن تنضم الواجهات الطرفية إلى OSPF.

• مؤقت OSPF Hello / Dead، نوع الشبكة

ملف تعريف واجهة OSPF — مؤقت الترحيب / الإيقاف المؤقت ونوع الشبكة

تفاصيل سياسة واجهة OSPF

يتطلب OSPF توفر وحدات توقيت Hello و Dead لمطابقتها على كل جهاز مجاور. ويتم تكوين هذه في ملف تعريف واجهة OSPF.

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

التحقق من واجهة سطر الأوامر (CLI) ل OSPF

وتجمع نواتج واجهة سطر الأوامر في الخطوات التالية من الخادم النصلي الثالث في المخطط من قسم "نظرة عامة".

1. التحقق من حالة جار OSPF

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

f2-leaf3# show ip ospf neighbors vrf Prod:VRF2
OSPF Process ID default VRF Prod:VRF2
Total number of neighbors: 2
Neighbor ID     Pri State            Up Time  Address         Interface
10.0.0.4          1 FULL/DR          00:47:30 10.10.34.4      Vlan28      <--- neighbor with BL4
10.0.0.134        1 FULL/DROTHER     00:00:21 10.10.34.1      Vlan28      <--- neighbor with R34

في قائمة التحكم في الوصول الخاصة بالمنفذ (ACI)، ستشكل نقاط الوصول (BLs) نقاط الجوار عبر بروتوكول فتح أقصر مسار أولا (OSPF) مع بعضها البعض فوق الموجهات الخارجية عند إستخدام معرف شبكة VLAN نفسه مع SVI. هذا لأن ACI يتلقى مجال يفيض داخلي يدعو L3Out BD (أو BD خارجي) لكل VLAN id في L3Out SVIs. لاحظ أن معرف VLAN 28 هو شبكة VLAN داخلية تسمى PI-VLAN (شبكة VLAN مستقلة عن النظام الأساسي) بدلا من شبكة VLAN الفعلية (منفذ encap VLAN) المستخدمة على السلك. أستخدم الأمر التالي للتحقق من الوصول عبر شبكة VLAN ('vlan-2502').

f2-leaf3# show vlan id 28 extended
 VLAN Name                             Encap            Ports
 ---- -------------------------------- ---------------- ------------------------
 28   Prod:VRF2:l3out-OSPF:vlan-2502   vxlan-14942176,  Eth1/13, Po1
                                       vlan-2502

يمكن للمرء الحصول على نفس الإخراج من خلال معرف شبكة VLAN الخاصة بالوصول أيضا.

f2-leaf3# show vlan encap-id 2502 extended
 VLAN Name                             Encap            Ports
 ---- -------------------------------- ---------------- ------------------------
 28   Prod:VRF2:l3out-OSPF:vlan-2502   vxlan-14942176,  Eth1/13, Po1
                                       vlan-2502

2. راجع منطقة OSPF

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

f2-leaf3# show ip ospf interface brief vrf Prod:VRF2
OSPF Process ID default VRF Prod:VRF2
Total number of interface: 1
Interface               ID     Area            Cost   State    Neighbors Status
Vlan28                  94     0.0.0.1         4      BDR      2         up 
f2-leaf3# show ip ospf vrf Prod:VRF2
Routing Process default with ID 10.0.0.3 VRF Prod:VRF2
...
  Area (0.0.0.1)
       Area has existed for 00:59:14
       Interfaces in this area: 1 Active interfaces: 1
       Passive interfaces: 0  Loopback interfaces: 0
       This area is a NSSA area
       Perform type-7/type-5 LSA translation
       SPF calculation has run 10 times
        Last SPF ran for 0.001175s
       Area ranges are
       Area-filter in 'exp-ctx-proto-3112960'
       Area-filter out 'permit-all'
       Number of LSAs: 4, checksum sum 0x0

3. التحقق من تفاصيل واجهة OSPF

تأكد من أن معلمات مستوى الواجهة تلبي متطلبات إنشاء جار OSPF مثل شبكة IP الفرعية، نوع الشبكة، مؤقت Hello/Dead. يرجى ملاحظة معرف شبكة VLAN لتحديد SVI هو PI-VLAN (VLAN28)

f2-leaf3# show ip ospf interface vrf Prod:VRF2
Vlan28 is up, line protocol is up
   IP address 10.10.34.3/29, Process ID default VRF Prod:VRF2, area 0.0.0.1
   Enabled by interface configuration
   State BDR, Network type BROADCAST, cost 4
   Index 94, Transmit delay 1 sec, Router Priority 1
   Designated Router ID: 10.0.0.4, address: 10.10.34.4
   Backup Designated Router ID: 10.0.0.3, address: 10.10.34.3
   2 Neighbors, flooding to 2, adjacent with 2
   Timer intervals: Hello 10, Dead 40, Wait 40, Retransmit 5
     Hello timer due in 0.000000
   No authentication
   Number of opaque link LSAs: 0, checksum sum 0

f2-leaf3# show interface vlan28
Vlan28 is up, line protocol is up, autostate disabled
  Hardware EtherSVI, address is  0022.bdf8.19ff
  Internet Address is 10.10.34.3/29
  MTU 9000 bytes, BW 10000000 Kbit, DLY 1 usec

4. التحقق من إمكانية وصول IP إلى الجار

على الرغم من أن حزم OSPF Hello هي ربط حزم البث المتعدد المحلية، إلا أن حزم OSPF DBD المطلوبة لتبادل OSPF LSDB الأول هي unicast. وبالتالي، يلزم أيضا التحقق من إمكانية الوصول إلى البث الأحادي بالنسبة إلى مؤسسة الجوار التابعة لبروتوكول فتح أقصر مسار أولا (OSPF).

f2-leaf3# iping 10.10.34.1 -V Prod:VRF2
PING 10.10.34.1 (10.10.34.1) from 10.10.34.3: 56 data bytes
64 bytes from 10.10.34.1: icmp_seq=0 ttl=255 time=0.66 ms
64 bytes from 10.10.34.1: icmp_seq=1 ttl=255 time=0.653 ms

5. تحقق من نفس الشيء على الموجه الخارجي

فيما يلي أمثلة على التكوينات على الموجه الخارجي (NX-OS المستقل)

router ospf 1
    vrf f2-ospf
    router-id 10.0.0.134
    area 0.0.0.1 nssa

interface Vlan2502
    no shutdown
    mtu 9000
    vrf member f2-ospf
    ip address 10.10.34.1/29
    ip router ospf 1 area 0.0.0.1

تأكد من التحقق من وحدة الحد الأقصى للنقل (MTU) كذلك على الواجهة المادية.

6. خطوة إضافية - tcpdump

على العقد الطرفية الخاصة بواجهة وحدة المعالجة المركزية (ACI)، يمكن للمستخدم تنفيذ tcpdump على واجهة وحدة المعالجة المركزية (CPU) ل 'kpm_inb' للتحقق مما إذا كانت حزم البروتوكول قد وصلت إلى وحدة المعالجة المركزية (CPU) الطرفية. على الرغم من وجود عوامل تصفية متعددة ل OSPF، فإن رقم بروتوكول IP هو عامل التصفية الأكثر شمولا.

• رقم بروتوكول IP: الإصدار 89 (IPv4) أو الإصدار السادس من بروتوكول الإنترنت (IPv6) 0x59 (IPv6)
• عنوان IP الخاص بالجار: المضيف <ip>
• OSPF Link Local MCast IP: المضيف 224.0.0.5 أو المضيف 224.0.0.6

f2-leaf3# tcpdump -ni kpm_inb proto 89
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on kpm_inb, link-type EN10MB (Ethernet), capture size 65535 bytes
22:28:38.231356 IP 10.10.34.4 > 224.0.0.5: OSPFv2, Hello, length 52
22:28:42.673810 IP 10.10.34.3 > 224.0.0.5: OSPFv2, Hello, length 52
22:28:44.767616 IP 10.10.34.1 > 224.0.0.5: OSPFv2, Hello, length 52
22:28:44.769092 IP 10.10.34.3 > 10.10.34.1: OSPFv2, Database Description, length 32
22:28:44.769803 IP 10.10.34.1 > 10.10.34.3: OSPFv2, Database Description, length 32
22:28:44.775376 IP 10.10.34.3 > 10.10.34.1: OSPFv2, Database Description, length 112
22:28:44.780959 IP 10.10.34.1 > 10.10.34.3: OSPFv2, LS-Request, length 36
22:28:44.781376 IP 10.10.34.3 > 10.10.34.1: OSPFv2, LS-Update, length 64
22:28:44.790931 IP 10.10.34.1 > 224.0.0.6: OSPFv2, LS-Update, length 64

EIGRP

يستخدم هذا القسم مثالا على جوار EIGRP بين BL3 و BL4 و R34 من المخطط في قسم "نظرة عامة" مع EIGRP AS 10.

فيما يلي المعايير المشتركة لإنشاء تجاور EIGRP.

• EIGRP AS: يتم تعيين L3Out لبروتوكول EIGRP ك. يجب أن يتطابق هذا مع الجهاز الخارجي.
• ملف تعريف واجهة EIGRP.

ملف تعريف واجهة EIGRP

وهذا يعادل تكوين 'ip router eigrp <as>' على جهاز NX-OS مستقل. بدون هذا، لن تنضم الواجهات الطرفية إلى EIGRP.

• MTU

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

التحقق من واجهة سطر الأوامر (CLI) ل EIGRP

وتجمع نواتج واجهة سطر الأوامر في الخطوات التالية من الخادم النصلي الثالث في المخطط من قسم "نظرة عامة".

1. تحقق من حالة جار EIGRP

f2-leaf3# show ip eigrp neighbors vrf Prod:VRF3
EIGRP neighbors for process 10 VRF Prod:VRF3
H   Address                 Interface       Hold  Uptime  SRTT   RTO  Q  Seq
                                           (sec)         (ms)       Cnt Num
0   10.10.34.4              vlan29          14   00:12:58  1    50    0   6    <--- neighbor with BL4
1   10.10.34.1              vlan29          13   00:08:44  2    50    0   4    <--- neighbor with R34

في قائمة التحكم في الوصول (ACI)، تشكل نقاط الوصول (BLs) جوار EIGRP مع بعضها البعض فوق الموجهات الخارجية عند إستخدام معرف شبكة VLAN نفسه مع SVI. هذا لأن ACI يتلقى داخلي يفيض مجال يدعو L3Out BD (أو BD خارجي) ل كل VLAN id في L3Out SVIs.

يرجى ملاحظة أن معرف شبكة VLAN رقم 29 هو شبكة VLAN داخلية تسمى PI-VLAN (شبكة VLAN مستقلة عن النظام الأساسي) بدلا من شبكة VLAN الفعلية (منفذ Encap VLAN) المستخدمة على السلك. أستخدم الأمر التالي للتحقق من الوصول عبر شبكة VLAN (VLAN-2503).

f2-leaf3# show vlan id 29 extended
 VLAN Name                             Encap            Ports
 ---- -------------------------------- ---------------- ------------------------
 29   Prod:VRF3:l3out-EIGRP:vlan-2503  vxlan-15237052,  Eth1/13, Po1
                                       vlan-2503

يمكن للمرء الحصول على نفس الإخراج من خلال معرف شبكة VLAN الخاصة بالوصول أيضا.

f2-leaf3# show vlan encap-id 2503 extended
 VLAN Name                             Encap            Ports
 ---- -------------------------------- ---------------- ------------------------
 29   Prod:VRF3:l3out-EIGRP:vlan-2503  vxlan-15237052,  Eth1/13, Po1
                                       vlan-2503

2. التحقق من تفاصيل واجهة EIGRP

تأكد من تشغيل EIGRP على الواجهة المتوقعة. إذا لم تكن هناك مساحة، فتحقق من ملف تعريف الواجهة المنطقية وملف تعريف واجهة EIGRP.

f2-leaf3# show ip eigrp interfaces vrf Prod:VRF3
EIGRP interfaces for process 10 VRF Prod:VRF3
                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
vlan29             2        0/0         1       0/0         50             0
  Hello interval is 5 sec
  Holdtime interval is 15 sec
  Next xmit serial: 0
  Un/reliable mcasts: 0/2     Un/reliable ucasts: 5/10
  Mcast exceptions: 0    CR packets: 0    ACKs suppressed: 2
  Retransmissions sent: 2    Out-of-sequence rcvd: 0
  Classic/wide metric peers: 2/0

f2-leaf3# show int vlan 29
Vlan29 is up, line protocol is up, autostate disabled
  Hardware EtherSVI, address is  0022.bdf8.19ff
  Internet Address is 10.10.34.3/29
  MTU 9000 bytes, BW 10000000 Kbit, DLY 1 usec

3. تحقق من نفس الشيء على الموجه الخارجي

فيما يلي مثال التكوين على الموجه الخارجي (NX-OS المستقل).

router eigrp 10
 vrf f2-eigrp

interface Vlan2503
 no shutdown
 vrf member f2-eigrp
 ip address 10.10.34.1/29
 ip router eigrp 10

4. خطوة إضافية - tcpdump

على العقد الطرفية الخاصة بواجهة وحدة المعالجة المركزية (ACI)، يمكن للمستخدم تنفيذ tcpdump على واجهة وحدة المعالجة المركزية (CPU) ل 'kpm_inb' لتأكيد ما إذا كانت حزم البروتوكول قد وصلت إلى وحدة المعالجة المركزية (CPU) الخاصة بالورقة. أستخدم بروتوكول IP رقم 88 (EIGRP) كعامل تصفية.

f2-leaf3# tcpdump -ni kpm_inb proto 88
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on kpm_inb, link-type EN10MB (Ethernet), capture size 65535 bytes
23:29:43.725676 IP 10.10.34.3 > 224.0.0.10: EIGRP Hello, length: 40
23:29:43.726271 IP 10.10.34.4 > 224.0.0.10: EIGRP Hello, length: 40
23:29:43.728178 IP 10.10.34.1 > 224.0.0.10: EIGRP Hello, length: 40
23:29:45.729114 IP 10.10.34.1 > 10.10.34.3: EIGRP Update, length: 20
23:29:48.316895 IP 10.10.34.3 > 224.0.0.10: EIGRP Hello, length: 40

إعلان المسار

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

• الإعلان عن الشبكة الفرعية لمجالات الجسر.
• إعلان مسار النقل.
• التحكم في مسار الاستيراد والتصدير.

يناقش هذا القسم تسريب المسار فيما يتعلق بعمليات خروج L3المشتركة في الأقسام اللاحقة.

سير عمل إعلان مسار مجال الجسر

قبل النظر إلى حل المشاكل الشائع، يجب على المستخدم أن يتعرف على الطريقة التي يفترض أن يعمل بها إعلان مجال Bridge.

يتضمن إعلان BD، عندما يكون BD و L3Out في نفس VRF،:

• وجود علاقة عقد بين L3Out و EPG الداخلي.
• ربط L3Out بمجال Bridge.
• تحديد "الإعلان خارجيا" على الشبكة الفرعية ل BD.

وبالإضافة إلى ذلك، من الممكن أيضا التحكم في إعلان مجال Bridge باستخدام ملفات تعريف مسار التصدير التي تمنع الحاجة إلى ربط L3Out. ومع ذلك، ما يزال يجب تحديد 'Advertising خارجيا'. هذه حالة إستخدام أقل شيوعا لذلك لن يتم مناقشتها هنا.

يلزم وجود علاقة العقد بين L3Out و EPG من أجل دفع مسار BD الثابت المتفشي إلى BL. تتم معالجة إعلان المسار الفعلي من خلال إعادة توزيع المسار الثابت إلى البروتوكول الخارجي. وأخيرا، سيتم تثبيت خرائط مسار إعادة التوزيع فقط داخل L3Out المرتبطة ب BD. بهذه الطريقة لا يتم الإعلان عن المسار عبر كل L3Out.

في هذه الحالة، تكون الشبكة الفرعية BD هي 192.168.1.0/24 ويجب الإعلان عنها عبر OSPF L3Out.

قبل تطبيق العقد بين L3Out و EPG الداخلي

leaf103# show ip route 192.168.1.0/24 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 
Route not found

لاحظ أن مسار BD غير موجود بعد على BL.

بعد تطبيق العقد بين L3Out و EPG الداخلي

في هذه المرحلة لم يتم إجراء أي تكوين آخر. لم يتم إقران L3Out ب BD ولم يتم تعيين علامة 'Advertising خارجيا'.

leaf103# show ip route 10.0.1.0/24 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 
192.168.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.120.34%overlay-1, [1/0], 00:00:08, static, tag 4294967294
        recursive next hop: 10.0.120.34/32%overlay-1

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

بعد تحديد "إعلان خارجيا" على الشبكة الفرعية ل BD

لم يتم اقتران L3Out ب BD بعد. ومع ذلك، لاحظ أن العلامة قد تم مسحها.

leaf103# show ip route 192.168.1.0/24 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

192.168.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.120.34%overlay-1, [1/0], 00:00:06, static
        recursive next hop: 10.0.120.34/32%overlay-1

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

leaf103# show ip ospf vrf Prod:Vrf1
Routing Process default with ID 10.0.0.3 VRF Prod:Vrf1
Stateful High Availability enabled
Supports only single TOS(TOS0) routes
Supports opaque LSA
Table-map using route-map exp-ctx-2392068-deny-external-tag
Redistributing External Routes from
  static route-map exp-ctx-st-2392068
  direct route-map exp-ctx-st-2392068
  bgp route-map exp-ctx-proto-2392068
  eigrp route-map exp-ctx-proto-2392068
  coop route-map exp-ctx-st-2392068

تتم برمجة مسار BD كمسار ثابت، لذلك تحقق من مخطط مسار إعادة التوزيع الثابت عن طريق تشغيل 'show route-map <route-map name>' ثم 'show ip prefix-list <name>' على أي قوائم بادئات موجودة في خريطة المسار. قم بذلك في الخطوة التالية.

بعد ربط L3Out ب BD

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

leaf103# show route-map exp-ctx-st-2392068
route-map exp-ctx-st-2392068, deny, sequence 1
 Match clauses:
   tag: 4294967294
 Set clauses:

...
route-map exp-ctx-st-2392068, permit, sequence 15803
 Match clauses:
   ip address prefix-lists: IPv4-st16390-2392068-exc-int-inferred-export-dst
   ipv6 address prefix-lists: IPv6-deny-all
 Set clauses:
   tag 0

التحقق من قائمة البادئات:

leaf103# show ip prefix-list IPv4-st16390-2392068-exc-int-inferred-export-dst
ip prefix-list IPv4-st16390-2392068-exc-int-inferred-export-dst: 1 entries
  seq 1 permit 192.168.1.1/24

تتم مطابقة الشبكة الفرعية ل BD لإعادة توزيعها في OSPF.

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

• بالنسبة إلى EIGRP، تحقق من تثبيت المسار في جدول المخطط باستخدام <name> 'show ip eigrp topology vrf
• بالنسبة ل OSPF، تحقق من أنه يتم تثبيت المسار في جدول قاعدة البيانات ك LSA خارجي مع 'show ip ospf database vrf <name>'
• بالنسبة لبروتوكول BGP، تحقق من أن المسار موجود في بروتوكول BGP مع <name><name> ل VRF أحادي البث 'show bgp ipV4

إعلان مسار BGP

بالنسبة لبروتوكول BGP، يتم السماح ضمنيا لجميع المسارات الثابتة لإعادة التوزيع. يتم تطبيق خريطة المسار التي تطابق شبكة BD الفرعية على مستوى جار BGP.

leaf103# show bgp ipv4 unicast neighbor 10.0.0.134 vrf Prod:Vrf1 | grep Outbound
 Outbound route-map configured is exp-l3out-BGP-peer-2392068, handle obtained

في المثال السابق، 10.0.0.134 هي جارة BGP التي تم تكوينها داخل L3Out.

إعلان مسار EIGRP

وكما هو الحال مع OSPF، يتم إستخدام خريطة المسار للتحكم في إعادة توزيع EIGRP الثابتة. بهذه الطريقة، يجب إعادة توزيع الشبكات الفرعية المرتبطة ب L3Out فقط والتي تم تعيينها على "الإعلان خارجيا". يمكن التحقق من هذا الإجراء باستخدام هذا الأمر:

leaf103# show ip eigrp vrf Prod:Vrf1
IP-EIGRP AS 100 ID 10.0.0.3 VRF Prod:Vrf1
 Process-tag: default
 Instance Number: 1
 Status: running
 Authentication mode: none
 Authentication key-chain: none
 Metric weights: K1=1 K2=0 K3=1 K4=0 K5=0
 metric version: 32bit
 IP proto: 88 Multicast group: 224.0.0.10
 Int distance: 90 Ext distance: 170
 Max paths: 8
 Active Interval: 3 minute(s)
 Number of EIGRP interfaces: 1 (0 loopbacks)
 Number of EIGRP passive interfaces: 0
 Number of EIGRP peers: 2
 Redistributing:
   static route-map exp-ctx-st-2392068
   ospf-default route-map exp-ctx-proto-2392068
   direct route-map exp-ctx-st-2392068
   coop route-map exp-ctx-st-2392068
   bgp-65001 route-map exp-ctx-proto-2392068

يتم عرض تكوين BD العامل النهائي أدناه.

تكوين Bridge Domain L3

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

في هذه الحالة، يكون العرض النموذجي هو عدم الإعلان عن شبكة BD فرعية مكونة من خارج L3Out. اتبع سير العمل السابق لفهم أي مكون تم كسره.

ابدأ بالتكوين قبل الحصول على مستوى منخفض جدا عن طريق التحقق مما يلي:

• هل هناك عقد بين EPG و L3Out؟
• هل L3Out مرتبط ب BD؟
• هل تم تعيين الشبكة الفرعية ل BD للإعلان عنها خارجيا؟
• هل تم تشغيل تجاور البروتوكول الخارجي؟

السبب المحتمل: لم يتم نشر BD

تنطبق هذه الحالة في سيناريوهين مختلفين، مثل:

• يستخدم EPG الداخلي دمج VMM مع خيار "عند الطلب" ولم يتم إرفاق نقاط نهاية VM بمجموعة المنافذ الخاصة ب EPG.
• تم إنشاء EPG الداخلي ولكن لم يتم تكوين أي روابط مسار ثابتة أو أن الواجهة التي تم تكوين المسار الثابت عليها معطلة.

وفي كلتا الحالتين، لن يتم نشر BD، ونتيجة لذلك، لن يتم دفع المسار الثابت ل BD إلى BL. الحل هنا هو نشر بعض الموارد النشطة داخل EPG والمرتبط ب BD هذا حتى يتم نشر الشبكة الفرعية.

السبب المحتمل: تم تكوين OSPF L3Out على أنه 'stub' أو 'NSSA' بدون إعادة توزيع

عندما يتم إستخدام OSPF كبروتوكول L3Out، يجب متابعة قواعد OSPF الأساسية. لا تسمح مناطق الكعب بإعادة توزيع LSAs ولكن يمكن الإعلان عن مسار افتراضي بدلا من ذلك. تسمح مناطق NSSA بالمسارات التي تمت إعادة توزيعها ولكن يجب تحديد 'إرسال LSAs التي تمت إعادة توزيعها في منطقة NSSA' على L3Out. أو يمكن أن يعلن NSSA أيضا عن مسار افتراضي بدلا من ذلك بتعطيل "إنشاء ملخص LSA" أيضا وهو سيناريو نموذجي حيث سيتم تعطيل "إرسال إعلانات LSA المعاد توزيعها في منطقة NSSA".

السبب المحتمل: ملف تعريف المسار "Default-Export" مع إجراء "Deny" مكون ضمن L3Out

عندما يتم تكوين ملفات تعريف المسار تحت L3Out بأسماء 'default-export' أو 'default-import'، فإنها يتم تطبيقها ضمنيا على L3Out. بالإضافة إلى ذلك، إذا تم تعيين ملف تعريف مسار التصدير الافتراضي على إجراء رفض وتم تكوينه على أنه 'تطابق البادئة ونهج التوجيه'، فيجب الإعلان عن الشبكات الفرعية ل BD من خرج L3Out هذا وسوف يتم رفضها ضمنيا:

ملف تعريف مسار رفض التصدير الافتراضي

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

سير عمل إستيراد المسار الخارجي

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

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

بشكل افتراضي، تتم إعادة توزيع جميع الموجهات التي يتم التعرف عليها من خلال البروتوكول الخارجي في عملية BGP الخاصة بالنسيج الداخلي. وهذا صحيح بغض النظر عن الشبكات الفرعية التي يتم تكوينها تحت EPG الخارجي والأعلام التي يتم تحديدها. هناك مثالين حيث أن هذا غير صحيح.

• في حالة تعيين خيار "فرض التحكم في المسار" في نهج L3Out للمستوى الأعلى على "إستيراد". في هذه الحالة، ينتقل نموذج إستيراد المسار من نموذج قائمة حظر (حدد فقط ما يجب ألا يسمح به) إلى نموذج قائمة السماح (يتم رفض كل شيء ضمنيا ما لم يتم تكوينه بشكل آخر).
• إذا كان البروتوكول الخارجي هو EIGRP أو OSPF وكان ملف تعريف المسار المتداخل المستخدم لا يطابق المسارات الخارجية.

لكي يتم توزيع مسار خارجي على ورقة داخلية، يجب أن يحدث ما يلي:

• يجب تعلم المسار على BL من الموجه الخارجي. لكي تكون مرشحا لإعادة التوزيع في عملية MP-BGP الليفية، يجب تثبيت المسار في جدول التوجيه بدلا من تثبيته في ملف تعريف البروتوكول فقط.
• يجب السماح بإعادة توزيع المسار أو الإعلان عنه في عملية BGP الداخلية. يجب أن يحدث هذا دائما ما لم يتم إستخدام فرض التحكم في المسار للاستيراد أو ملف تعريف مسار متداخل.
• يجب تكوين سياسة عاكس مسار BGP وتطبيقها على مجموعة نهج POD يتم تطبيقها على ملف تعريف POD. إذا لم يتم تطبيق ذلك، فلن تتم تهيئة عملية BGP على المحولات.

إذا كان EPG/BD الداخلي في نفس VRF الخاص ب L3Out فإن الخطوات الثلاث المذكورة أعلاه هي كل ما هو مطلوب ل EPG/BD الداخلي لاستخدام المسارات الخارجية.

يتم تثبيت المسار في جدول توجيه BL

وفي هذه الحالة، فإن المسار الخارجي الذي ينبغي تعلمه على المحولين 103 و 104 هو 172.16.20.1/32.

leaf103# show ip route 172.16.20.1 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.20.1/32, ubest/mbest: 1/0
    *via 10.10.34.3, vlan347, [110/20], 00:06:29, ospf-default, type-2

من الواضح أنه تم تثبيته في جدول التوجيه كما تم تعلمه من خلال OSPF. إذا لم يتم رؤيتها هنا، تحقق من البروتوكول الفردي وتأكد من وجود التجاور. يتم إعادة توزيع المسار إلى BGP يمكن التحقق من خريطة مسار إعادة التوزيع، بعد التحقق من عدم إستخدام أي من تنفيذ "الاستيراد" أو ملفات تعريف المسار المتداخلة، من خلال النظر في خريطة المسار المستخدمة للبروتوكول الخارجي لإعادة توزيع BGP. راجع الأمر التالي:

leaf103# show bgp process vrf Prod:Vrf1

Information regarding configured VRFs:

BGP Information for VRF Prod:Vrf1
VRF Type                       : System
VRF Id                         : 85
VRF state                      : UP
VRF configured                 : yes
VRF refcount                   : 1
VRF VNID                       : 2392068
Router-ID                      : 10.0.0.3
Configured Router-ID           : 10.0.0.3
Confed-ID                      : 0
Cluster-ID                     : 0.0.0.0
MSITE Cluster-ID               : 0.0.0.0
No. of configured peers        : 1
No. of pending config peers    : 0
No. of established peers       : 1
VRF RD                         : 101:2392068
VRF EVPN RD                    : 101:2392068
...
    Redistribution
        direct, route-map permit-all
        static, route-map imp-ctx-bgp-st-interleak-2392068
        ospf, route-map permit-all
        coop, route-map exp-ctx-st-2392068
        eigrp, route-map permit-all

وهنا يتضح أن خريطة المسار "السماح بكل شيء" تستخدم لإعادة توزيع OSPF إلى BGP. هذا هو الإعداد الافتراضي. من هنا، يمكن التحقق من BL ويتم التحقق من المسار المحلي المنشأ من BGP:

a-leaf101# show bgp ipv4 unicast 172.16.20.1/32 vrf Prod:Vrf1
BGP routing table information for VRF Prod:Vrf1, address family IPv4 Unicast
BGP routing table entry for 172.16.20.1/32, version 25 dest ptr 0xa6f25ad0
Paths: (2 available, best #2)
Flags: (0x80c0002 00000000) on xmit-list, is not in urib, exported
  vpn: version 16316, (0x100002) on xmit-list
Multipath: eBGP iBGP


  Advertised path-id 1, VPN AF advertised path-id 1
  Path type: redist 0x408 0x1 ref 0 adv path ref 2, path is valid, is best path
  AS-Path: NONE, path locally originated
    0.0.0.0 (metric 0) from 0.0.0.0 (10.0.0.3)
      Origin incomplete, MED 20, localpref 100, weight 32768
      Extcommunity:
          RT:65001:2392068
          VNID:2392068
          COST:pre-bestpath:162:110

  VRF advertise information:
  Path-id 1 not advertised to any peer

  VPN AF advertise information:
  Path-id 1 advertised to peers:
    10.0.64.64         10.0.72.66
  Path-id 2 not advertised to any peer

في الإخراج المذكور أعلاه، يشير 0.0.0.0/0 إلى أنه تم إنشاؤه محليا. قائمة النظراء المعلن عنهم هي عقد العمود الفقري في البنية التي تعمل كعاكس المسار.

التحقق من المسار على الورقة الداخلية

يجب أن تعلن BL عن ذلك إلى عقد العمود الفقري من خلال عائلة عناوين BGP الخاصة ب VPNv4. يجب أن تعلن عقد العمود الفقري عن ذلك إلى أي عقد طرفية يتم نشر VRF (صح بالنسبة للمثال الذي لا يتسرب من المسار). على أي من هذه العقد الطرفية تقوم بتشغيل <route> VRF-1 للبث الأحادي 'show bgp vpnv4' للتحقق من أنه في VPNv4

أستخدم الأمر أدناه للتحقق من المسار على الورقة الداخلية.

leaf101# show ip route 172.16.20.1 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.20.1/32, ubest/mbest: 2/0
    *via 10.0.72.64%overlay-1, [200/20], 00:21:24, bgp-65001, internal, tag 65001
         recursive next hop: 10.0.72.64/32%overlay-1
    *via 10.0.72.67%overlay-1, [200/20], 00:21:24, bgp-65001, internal, tag 65001
         recursive next hop: 10.0.72.67/32%overlay-1

في الإخراج المذكور أعلاه، يتم تعلم المسار من خلال بروتوكول بوابة الحدود (BGP) ويجب أن تكون الخطوات التالية هي الخطوات الفيزيائية TEPs (PTEP) للنقاط الثنائية (BLs).

leaf101# acidiag fnvread
      ID   Pod ID                 Name    Serial Number         IP Address    Role        State   LastUpdMsgId
--------------------------------------------------------------------------------------------------------------
     103        1            a-leaf101      FDO20160TPS      10.0.72.67/32    leaf         active   0
     104        1            a-leaf103      FDO20160TQ0      10.0.72.64/32    leaf         active   0

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

في هذا السيناريو، لا تتلقى الورقة الداخلية (101) مسارا (مسارات) خارجيا.

كما هو الحال دائما، تحقق أولا من الأساسيات. تأكد من:

• توجد عمليات تجاور بروتوكول التوجيه على BLs.
• يتم تطبيق سياسة عاكس مسار BGP على مجموعة سياسة Pod وملف تعريف Pod.

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

السبب المحتمل: لم يتم نشر VRF على الورقة الداخلية

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

لأن L3Out VRF لا ينشر على الورقة الداخلية (دققت مع 'show vrf' على ورقة داخلية) فإن الورقة الداخلية لن تستورد المسار BGP من VPNv4.

لحل هذه المشكلة، يجب على المستخدم نشر الموارد داخل L3Out VRF على الورقة الداخلية.

السبب المحتمل: يتم إستخدام فرض مسار الاستيراد

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

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

leaf103# vsh -c "show ip ospf database external 172.16.20.1 vrf Prod:Vrf1"
        OSPF Router with ID (10.0.0.3) (Process ID default VRF Prod:Vrf1)

                Type-5 AS External Link States

Link ID         ADV Router      Age        Seq#       Checksum Tag
172.16.20.1     10.0.0.134      455        0x80000003 0xb9a0    0

leaf103# show ip route 172.16.20.1 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

Route not found

فيما يلي خريطة الجدول التي تم تثبيتها الآن مسببة هذا السلوك:

leaf103# show ip ospf vrf Prod:Vrf1

 Routing Process default with ID 10.0.0.3 VRF Prod:Vrf1
 Stateful High Availability enabled
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Table-map using route-map exp-ctx-2392068-deny-external-tag
 Redistributing External Routes from..

leaf103# show route-map exp-ctx-2392068-deny-external-tag
route-map exp-ctx-2392068-deny-external-tag, deny, sequence 1
  Match clauses:
    tag: 4294967295
  Set clauses:
route-map exp-ctx-2392068-deny-external-tag, deny, sequence 19999
  Match clauses:
    ospf-area: 0.0.0.100
  Set clauses:

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

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

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

السبب المحتمل: يتم إستخدام ملف تعريف تداخل

يتم إستخدام ملفات تعريف المسار المتداخلة ل EIGRP و OSPF L3out ويقصد بها السماح بالتحكم في ما تتم إعادة توزيعه من بروتوكول العبارة الداخلية إلى BGP وكذلك السماح بتطبيق سياسة مثل تعيين سمات BGP.

بدون ملف تعريف مسار متداخل، يتم إستيراد جميع المسارات ضمنيا إلى BGP.

بدون ملف تعريف مسار متقلب:

leaf103# show bgp process vrf Prod:Vrf1

Information regarding configured VRFs:

BGP Information for VRF Prod:Vrf1
VRF Type                       : System
VRF Id                         : 85
VRF state                      : UP
VRF configured                 : yes
VRF refcount                   : 1
VRF VNID                       : 2392068
Router-ID                      : 10.0.0.3
Configured Router-ID           : 10.0.0.3
Confed-ID                      : 0
Cluster-ID                     : 0.0.0.0
MSITE Cluster-ID               : 0.0.0.0
No. of configured peers        : 1
No. of pending config peers    : 0
No. of established peers       : 1
VRF RD                         : 101:2392068
VRF EVPN RD                    : 101:2392068

...
    Peers      Active-peers    Routes     Paths      Networks   Aggregates
    1          1               7          11         0          0

    Redistribution
        direct, route-map permit-all
        static, route-map imp-ctx-bgp-st-interleak-2392068
        ospf, route-map permit-all
        coop, route-map exp-ctx-st-2392068
        eigrp, route-map permit-all

مع ملف تعريف مسار متقلب:

a-leaf103# show bgp process vrf Prod:Vrf1

Information regarding configured VRFs:

BGP Information for VRF Prod:Vrf1
VRF Type                       : System
VRF Id                         : 85
VRF state                      : UP
VRF configured                 : yes
VRF refcount                   : 1
VRF VNID                       : 2392068
Router-ID                      : 10.0.0.3
Configured Router-ID           : 10.0.0.3
Confed-ID                      : 0
Cluster-ID                     : 0.0.0.0
MSITE Cluster-ID               : 0.0.0.0
No. of configured peers        : 1
No. of pending config peers    : 0
No. of established peers       : 1
VRF RD                         : 101:2392068
VRF EVPN RD                    : 101:2392068

...

    Redistribution
        direct, route-map permit-all
        static, route-map imp-ctx-bgp-st-interleak-2392068
        ospf, route-map imp-ctx-proto-interleak-2392068
        coop, route-map exp-ctx-st-2392068
        eigrp, route-map permit-all

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

سير عمل إعلان مسار النقل

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

سيستخدم هذا السيناريو المخطط التالي:

مخطط توجيه النقل

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

لكي يتم الإعلان عن المسار 172.16.20.1 في EIGRP، يجب تكوين أحد العناصر التالية:

• يمكن تحديد الشبكة الفرعية التي سيتم الإعلان عنها على EIGRP L3Out باستخدام علامة "تصدير الشبكة الفرعية للتحكم في المسار". وكما هو مذكور في قسم النظرة العامة، يتم إستخدام هذه العلامة بشكل رئيسي لتوجيه النقل ويحدد الشبكات الفرعية التي يجب الإعلان عنها من خرج L3Out هذا.
• قم بتكوين 0.0.0.0/0 وحدد كلا من "تجميع التصدير" و"تصدير الشبكة الفرعية للتحكم في المسار". وهذا يؤدي إلى إنشاء خريطة مسار لإعادة التوزيع في البروتوكول الخارجي الذي يطابق 0.0.0.0/0 وجميع البادئات الأكثر تحديدا (والتي تكون مطابقة فعالة لأي). لاحظ أنه عند إستخدام 0.0.0.0/0 مع 'التصدير الكلي'، لن تتم مطابقة المسارات الثابتة لإعادة التوزيع. وذلك لمنع الإعلان عن موجهات BD بشكل غير مقصود التي يجب الإعلان عنها.
• وأخيرا، من الممكن إنشاء ملف تعريف مسار تصدير يطابق البادئات التي سيتم الإعلان عنها. يمكن أن يقوم إستخدام هذه الطريقة بتكوين الخيار 'التجميع' باستخدام البادئات بجانب 0.0.0.0/0.

ستؤدي التكوينات المذكورة أعلاه إلى الإعلان عن مسار النقل، ولكن لا يزال يتعين وجود سياسة أمان عليه للسماح بحركة مرور مستوى البيانات بالتدفق. كما هو الحال مع أي اتصال EPG ب EPG، يجب أن يكون العقد ساري المفعول قبل السماح بحركة المرور.

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

من المهم أيضا أن تفهم أن كل مسارات النقل يتم تمييزها ببطاقة VRF معينة. بشكل افتراضي، هذه العلامة هي 4294967295. يتم تكوين نهج علامة المسار ضمن 'مستأجر > شبكة > بروتوكولات > علامة المسار:

سياسة علامات المسار

يطبق هذا طريق بطاقة نهج بعد ذلك إلى ال VRF. الغرض من هذه العلامة أساسا لمنع حلقات التكرار. يتم تطبيق علامة المسار هذه عندما يتم الإعلان عن مسار النقل من L3Out. إذا تم تلقي هذه المسارات مرة أخرى مع نفس علامة المسار ثم يتم تجاهل المسار.

تحقق من أن المسار موجود على BL المستقبل عبر OSPF

على غرار القسم الأخير، تحقق أولا من أن الخادم (BL) الذي يجب أن يستقبل المسار الصحيح في البداية.

leaf103# show ip route 172.16.20.1 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.20.1/32, ubest/mbest: 1/0
    *via 10.10.34.3, vlan347, [110/20], 01:25:30, ospf-default, type-2

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

تحقق من وجود المسار في BGP على منفذ OSPF BL المستقبل

لكي يتم الإعلان عن موجه OSPF إلى موجه EIGRP الخارجي، يلزم الإعلان عن المسار في BGP على منفذ OSPF BL المتلقي.

leaf103# show bgp ipv4 unicast 172.16.20.1/32 vrf Prod:Vrf1
BGP routing table information for VRF Prod:Vrf1, address family IPv4 Unicast
BGP routing table entry for 172.16.20.1/32, version 30 dest ptr 0xa6f25ad0
Paths: (2 available, best #1)
Flags: (0x80c0002 00000000) on xmit-list, is not in urib, exported
  vpn: version 17206, (0x100002) on xmit-list
Multipath: eBGP iBGP

  Advertised path-id 1, VPN AF advertised path-id 1
  Path type: redist 0x408 0x1 ref 0 adv path ref 2, path is valid, is best path
  AS-Path: NONE, path locally originated
    0.0.0.0 (metric 0) from 0.0.0.0 (10.0.0.3)
      Origin incomplete, MED 20, localpref 100, weight 32768
      Extcommunity:
          RT:65001:2392068
          VNID:2392068
          COST:pre-bestpath:162:110

  VRF advertise information:

  Path-id 1 not advertised to any peer

  VPN AF advertise information:
  Path-id 1 advertised to peers:
    10.0.64.64         10.0.72.66
  Path-id 2 not advertised to any peer

المسار في BGP.

تحقق من صحة EIGRP BL الذي يجب أن يعلن عن المسار الذي تم تثبيته فيه

leaf102# show ip route 172.16.20.1 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.20.1/32, ubest/mbest: 2/0
    *via 10.0.72.67%overlay-1, [200/20], 00:56:46, bgp-65001, internal, tag 65001
         recursive next hop: 10.0.72.67/32%overlay-1
    *via 10.0.72.64%overlay-1, [200/20], 00:56:46, bgp-65001, internal, tag 65001
         recursive next hop: 10.0.72.64/32%overlay-1

يتم تثبيته في جدول التوجيه مع تضمين الخطوات التالية التي تشير إلى العقد الطرفية الحدودية الناشئة.

leaf102# acidiag fnvread

      ID   Pod ID                 Name    Serial Number         IP Address    Role        State   LastUpdMsgId
--------------------------------------------------------------------------------------------------------------
     103        1            a-leaf101      FDO20160TPS      10.0.72.67/32    leaf         active   0
     104        1            a-leaf103      FDO20160TQ0      10.0.72.64/32    leaf         active   0

التحقق من الإعلان عن المسار على BL

سيتم الإعلان عن المسار بواسطة BL 102 نتيجة لتعيين العلامة "تصدير الشبكة الفرعية للتحكم في المسار" على الشبكة الفرعية التي تم تكوينها:

التحكم في مسار التصدير

أستخدم الأمر التالي لعرض خريطة المسار التي تم إنشاؤها نتيجة لعلامة "تصدير التحكم في المسار" هذه:

leaf102# show ip eigrp vrf Prod:Vrf1
IP-EIGRP AS 101 ID 10.0.0.2 VRF Prod:Vrf1
  Process-tag: default
  Instance Number: 1
  Status: running
  Authentication mode: none
  Authentication key-chain: none
  Metric weights: K1=1 K2=0 K3=1 K4=0 K5=0
  metric version: 32bit
  IP proto: 88 Multicast group: 224.0.0.10
  Int distance: 90 Ext distance: 170
  Max paths: 8
  Active Interval: 3 minute(s)
  Number of EIGRP interfaces: 1 (0 loopbacks)
  Number of EIGRP passive interfaces: 0
  Number of EIGRP peers: 1
  Redistributing:
    static route-map exp-ctx-st-2392068
    ospf-default route-map exp-ctx-proto-2392068
    direct route-map exp-ctx-st-2392068
    coop route-map exp-ctx-st-2392068
    bgp-65001 route-map exp-ctx-proto-2392068

للبحث عن "إعادة توزيع BGP > EIGRP"، راجع خريطة المسار. ولكن يجب أن تكون خريطة المسار نفسها هي نفسها بغض النظر عما إذا كان بروتوكول المصدر هو OSPF أو EIGRP أو BGP. سيتم التحكم في المسارات الثابتة باستخدام خريطة مسار مختلفة.

leaf102# show route-map exp-ctx-proto-2392068
route-map exp-ctx-proto-2392068, permit, sequence 15801
  Match clauses:
    ip address prefix-lists: IPv4-proto32771-2392068-exc-ext-inferred-export-dst
    ipv6 address prefix-lists: IPv6-deny-all
  Set clauses:
    tag 4294967295

a-leaf102# show ip prefix-list IPv4-proto32771-2392068-exc-ext-inferred-export-dst
ip prefix-list IPv4-proto32771-2392068-exc-ext-inferred-export-dst: 1 entries
   seq 1 permit 172.16.20.1/32

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

توجيه النقل عند تلقي BL والإعلان عنها هي نفسها

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

وفيما يلي وصف موجز لكيفية تنفيذ ذلك:

• يتم التحكم في توجيه النقل بين عمليتي L3Out من OSPF على نفس الورقة: إعلان المسار من خلال 'عامل تصفية المنطقة' المطبق على مستوى عملية OSPF. ويجب نشر مادة L3Out في المنطقة 0 على الورقة لأن الموجهات يتم الإعلان عنها بين المناطق وليس من خلال إعادة التوزيع. أستخدم 'show ip ospf vrf <name>' لعرض قائمة عوامل التصفية. عرض محتويات عامل التصفية باستخدام 'show route-map <filter name>'.
• توجيه النقل بين OSPF و EIGRP L3Out على نفس الصفحة: يتم التحكم في إعلان المسار من خلال خرائط مسار إعادة التوزيع التي يمكن رؤيتها مع 'show ip ospf' و'show ip eigrp'. لاحظ أنه إذا كان هناك العديد من OSPF L3Out موجودة على نفس BL فإن الطريقة الوحيدة لإعادة التوزيع إلى واحد فقط من عمليات OSPF L3Out هذه هي إذا كان الآخر عبارة عن STUB أو NSSA مع تعطيل إرسال LSA المعاد توزيعها إلى منطقة NSSA" بحيث لا تسمح بأي LSA خارجية.
• يتم التحكم في توجيه النقل بين OSPF أو EIGRP و BGP على نفس الورقة: يتم التحكم في إعلان المسار إلى بروتوكول العبارة الداخلية من خلال خرائط مسار إعادة التوزيع. يتم التحكم في إعلان المسار إلى BGP عبر خريطة مسار صادرة يتم تطبيقها مباشرة على جار BGP الذي يجب إرسال المسار إليه. يمكن التحقق من هذا الإجراء باستخدام <name> <neighbor address> vrf المجاور للبث الأحادي 'show bgp ipV4 | GREP Outbound'.
• توجيه النقل بين إثنان BGP L3Out على نفس الصفحة: يتم التحكم في جميع الإعلانات عبر خرائط المسار المطبقة مباشرة على جار BGP الذي يجب إرسال المسار إليه. يمكن التحقق من هذا الإجراء باستخدام <name> <neighbor address> vrf المجاور للبث الأحادي 'show bgp ipV4 | GREP Outbound'.

سيناريوهات أستكشاف أخطاء توجيه النقل وإصلاحها #1: لم يتم الإعلان عن مسار النقل

يتضمن سيناريو أستكشاف الأخطاء وإصلاحها هذا المسارات التي يجب التعرف عليها من خلال خرج L3Out واحد ولا يتم إرسالها من خرج L3Out الآخر.

كالعادة، تحقق من الأساسيات قبل النظر إلى أي شيء خاص ب ACI.

• هل هناك تجاور للبروتوكول؟
• هل الطريق، الذي يجب أن تكون ACI دعائية، تعلمناه من بروتوكول خارجي في المقام الأول؟
• ل BGP، هل يتم إسقاط المسار بسبب بعض سمة BGP؟ (كمسار، إلخ.).
• هل يحتوي L3Out المستقبل على هذا في قاعدة بيانات OSPF، أو جدول مخطط EIGRP، أو جدول BGP؟
• هل يتم تطبيق سياسة عاكس مسار BGP على مجموعة نهج Pod التي يتم تطبيقها على ملف تعريف Pod؟

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

السبب المحتمل: لا توجد منطقة OSPF رقم 0

إذا كانت الطوبولوجيا المتأثرة تتضمن عمليتي توصيل OSP L3Out على نفس ورقة الحدود، فيجب أن تكون هناك منطقة 0 للطرق التي يتم الإعلان عنها من منطقة إلى أخرى. انظر إلى النقطة المنسوبة أعلاه "توجيه النقل بين إثنين من OSPF L3Out على نفس الورقة" للحصول على مزيد من التفاصيل.

السبب المحتمل: منطقة OSPF عبارة عن كعب أو NSSA

وسيظهر هذا إذا تم تكوين OSPF L3Out باستخدام منطقة Stub أو NSSA التي لم يتم تكوينها للإعلان عن LSAs الخارجية. باستخدام بروتوكول فتح أقصر مسار أولا (OSPF)، لا يتم الإعلان أبدا عن إتفاقات منطقة التخزين الطويلة (LSA) الخارجية في مناطق كعب. ويتم الإعلان عنها في مناطق NSSA إذا تم تحديد "إرسال LSA التي تمت إعادة توزيعها في منطقة NSSA".

سيناريوهات أستكشاف أخطاء توجيه النقل وإصلاحها #2: لم يتم إستلام مسار النقل

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

السبب المحتمل: تم تكوين BL باستخدام معرف الموجه نفسه في شبكات VRF متعددة

من منظور تكوين، لا يمكن تكرار معرف الموجه داخل نفس VRF. مهما، هو عادة جيد أن يستعمل ال نفسه مسحاج تخديد-id في VRFs مختلف طالما الإثنان VRFs لا يربط إلى ال نفسه تحشد بروتوكول مجال.

تأملوا في الطوبولوجيا التالية:

الموجه الخارجي مع VRF أحادي — لم يتم إستلام مسار النقل

المشكلة هنا أن ACI يرى ورقة LSAs مع نفسه مسحاج تخديد id يتلقى، ينتج عن هذا لا يركب في ال OSPF قاعدة معطيات.

وبالإضافة إلى ذلك، إذا تم مشاهدة نفس الإعداد مع أزواج أجهزة الكمبيوتر الخاصة الظاهرية (VPC)، فسيتم إضافة وحدات LSA وحذفها باستمرار على بعض الموجهات. على سبيل المثال، قد يرى الموجه LSAs الواردة من نظير VPC الخاص به مع VRF و LSAs القادمة من العقدة نفسها (مع نفس معرف الموجه) التي تم إنشاؤها في VRF الآخر.

لحل هذه المشكلة، يجب على المستخدم التأكد من أن العقدة سيكون لها معرف موجه مختلف وفريد داخل كل VRF يحتوي على L3Out.

السبب المحتمل: تم تلقي المسارات من خرج L3Out واحد في بنية قائمة التحكم في الوصول (ACI) على بنية أخرى بنفس علامة VRF

تكون علامة المسار الافتراضية في ACI دائما هي نفسها ما لم يتم تغييرها. إذا تم الإعلان عن الموجهات من خرج L3واحد في بنية VRF أو ACI إلى خرج آخر من L3Out في بنية VRF أو ACI دون تغيير علامات VRF الافتراضية، فسيتم إسقاط الموجهات بواسطة شبكات BL المستقبلة.

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

سيناريوهات أستكشاف أخطاء توجيه النقل وإصلاحها #3 — مسارات النقل التي لم يتم الإعلان عنها بشكل متوقع

ويمكن ملاحظة هذا السيناريو عندما يتم الإعلان عن طرق النقل من خلال مخرج L3Out حيث لا يكون من المقصود الإعلان عنها.

السبب المحتمل: إستخدام 0.0.0.0/0 مع "التصدير الكلي"

عند تكوين شبكة فرعية خارجية على هيئة 0.0.0.0/0 باستخدام "الشبكة الفرعية للتحكم في مسار التصدير" و"التصدير الكلي"، تكون النتيجة هي تثبيت تطابق مع جميع خريطة مسار إعادة التوزيع. في هذه الحالة، يتم الإعلان عن جميع المسارات على بروتوكول BL التي تم التعرف عليها من خلال OSPF أو EIGRP أو BGP من خلال L3Out حيث تم تكوين هذا.

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

leaf102# show ip eigrp vrf Prod:Vrf1
IP-EIGRP AS 101 ID 10.0.0.2 VRF Prod:Vrf1
 Process-tag: default
 Instance Number: 1
 Status: running
 Authentication mode: none
 Authentication key-chain: none
 Metric weights: K1=1 K2=0 K3=1 K4=0 K5=0
 metric version: 32bit
 IP proto: 88 Multicast group: 224.0.0.10
 Int distance: 90 Ext distance: 170
 Max paths: 8
 Active Interval: 3 minute(s)
 Number of EIGRP interfaces: 1 (0 loopbacks)
 Number of EIGRP passive interfaces: 0
 Number of EIGRP peers: 1
 Redistributing:
   static route-map exp-ctx-st-2392068
   ospf-default route-map exp-ctx-proto-2392068
   direct route-map exp-ctx-st-2392068
   coop route-map exp-ctx-st-2392068
   bgp-65001 route-map exp-ctx-proto-2392068
 Tablemap: route-map exp-ctx-2392068-deny-external-tag , filter-configured
 Graceful-Restart: Enabled
 Stub-Routing: Disabled
 NSF converge time limit/expiries: 120/0
 NSF route-hold time limit/expiries: 240/0
 NSF signal time limit/expiries: 20/0
 Redistributed max-prefix: Disabled
 selfAdvRtTag: 4294967295
leaf102# show route-map exp-ctx-proto-2392068
route-map exp-ctx-proto-2392068, permit, sequence 19801
 Match clauses:
   ip address prefix-lists: IPv4-proto32771-2392068-agg-ext-inferred-export-dst
   ipv6 address prefix-lists: IPv6-deny-all
 Set clauses:
   tag 4294967295

leaf102# show ip prefix-list IPv4-proto32771-2392068-agg-ext-inferred-export-dst  
    ip prefix-list IPv4-proto32771-2392068-agg-ext-inferred-export-dst: 1 entries  
seq 1 permit 0.0.0.0/0 le 32

هذا هو السبب الأول لحلقات تكرار التوجيه التي تتضمن بيئة قائمة التحكم في الوصول (ACI).

العقد والخروج من L3Out

EPG المستند إلى البادئة على L3Out

في EPG داخلي (ليس L3Out)، يتم فرض العقود بعد اشتقاق ال pcTag من المصدر وال pcTag من الغاية EPG. يتم إستخدام عملية كبسلة VLAN/VXLAN الخاصة بالحزمة المستلمة على منفذ التنزيل لتشغيل هذا pcTag من خلال تصنيف الحزمة في EPG. عند تعلم عنوان MAC أو عنوان IP، يتم تعلمه مع تضمين الوصول الخاص به وعلامة EPG PCtag المقترنة. لمزيد من التفاصيل حول pcTag وإنفاذ العقد، يرجى الرجوع إلى الفصل "سياسات الأمان".

L3Out أيضا يقود pcTag باستخدام EPG الخاص به L3Out (EPG خارجي) الموجود تحت 'مستأجر > شبكة > L3OUT > شبكات > L3OUT-EPG'. ومع ذلك، لا تعتمد L3out على شبكات VLAN والواجهات لتصنيف الحزم على هذا النحو. وبدلا من ذلك، يستند التصنيف إلى بادئة/شبكة فرعية للمصدر في نمط 'أطول تطابق للبادئة'. ومن ثم، يمكن الإشارة إلى وضع حماية مستوى التحكم في الوصول إلى المنفذ (L3Out EPG) على أنه EPG مستند إلى البادئة. بعد تصنيف الحزمة إلى L3Out استنادا إلى شبكة فرعية، فإنها تتبع نمط تنفيذ سياسة مماثل ك EPG منتظم.

يوضح المخطط التالي أين يمكن العثور على PCtag الخاص ب L3Out EPG محدد داخل واجهة المستخدم الرسومية (GUI).

موقع PCtag ل L3Out

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

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

vsh -c 'show system internal policy-mgr prefix'

ملاحظات:

• تم تحديد نطاق إدخالات جدول LPM إلى معرف VRF VNID. يتم إجراء البحث لكل vrf_vnid/src pcTag/dst pcTag.
• يشير كل مدخل إلى PCtag واحد. ونتيجة لذلك، لا يمكن أن تستخدم وحدتا EPG L3Out نفس الشبكة الفرعية التي لها نفس طول القناع داخل نفس VRF.
• تستخدم الشبكة الفرعية 0.0.0.0/0 دائما PCtag 15 الخاصة. وعلى هذا النحو، يمكن تكراره، ولكن لا ينبغي القيام بذلك إلا بفهم كامل للآثار المترتبة على إنفاذ السياسات.
• يستخدم هذا الجدول في كلا الاتجاهين.
  • من L3Out إلى نقطة النهاية المحلية للورقة، مصدر pcTag مشتق باستخدام هذا الجدول.
  • من نقطة النهاية المحلية للورقة إلى L3Out، يتم اشتقاق ال pcTag للوجهة باستخدام هذا الجدول.
• إذا كان VRF يحتوي على إعداد فرض "الدخول" ل "توجيه فرض التحكم في السياسة"، فسيكون جدول بادئة LPM موجودا على شبكات L3Out BLs بالإضافة إلى أي محولات طرفية في VRF تحتوي على عقد مع L3Out.

مثال 1: خرج L3Out أحادي ببادئة محددة

السيناريو: BGP L3Out واحد في VRF prod:VRF1 مع L3Out EPG واحد. يتم تلقي البادئة 172.16.1.0/24 من مصدر خارجي لذلك يجب تصنيفها في L3Out EPG.

bdsol-aci32-leaf3# show ip route 172.16.1.0  vrf Prod:VRF1
IP Route Table for VRF "Prod:VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.1.0/24, ubest/mbest: 1/0
    *via 10.0.0.134%Prod:VRF1, [20/0], 00:56:14, bgp-132, external, tag 65002
         recursive next hop: 10.0.0.134/32%Prod:VRF1

أولا، أضف الشبكة الفرعية إلى جدول البادئات.

شبكة فرعية بنطاق 'شبكات فرعية خارجية لنطاق EPG الخارجي'

دققت البرمجة من البادئة قائمة على الورقة مفتاح أن يتلقى ال VRF من L3Out:

bdsol-aci32-leaf3# vsh -c ' show system internal  policy-mgr prefix ' |  egrep "Prod|==|Addr"
Vrf-Vni VRF-Id Table-Id Table-State  VRF-Name                    Addr                                Class Shared Remote Complete
======= ======  =========== =======  ============================ ================================= ====== ====== ====== ========
2097154 35     0x23          Up     Prod:VRF1                                            0.0.0.0/0   15      True   True   False
2097154 35     0x23          Up     Prod:VRF1                                         172.16.1.0/24  32772   True   True   False

ال pcTag من L3Out EPG 32772 في VRF مجال 2097154.

مثال 2: خرج L3Out واحد مع بادئات متعددة

تمديد على المثال السابق، في هذا السيناريو، يستقبل L3Out بادئات متعددة. بينما يكون إدخال كل بادئة سليما من الناحية الوظيفية، فإن الخيار البديل (حسب التصميم المقصود) هو قبول كل البادئات المستلمة على L3Out.

ويمكن تحقيق ذلك باستخدام البادئة '0.0.0.0/0'.

يؤدي هذا إلى إدخال جدول البادئات التالية الخاصة ب Policy-mgr:

bdsol-aci32-leaf3# vsh -c ' show system internal  policy-mgr prefix ' |  egrep "Prod|==|Addr"
Vrf-Vni VRF-Id Table-Id Table-State  VRF-Name                    Addr                                Class Shared Remote Complete
======= ======  =========== =======  ============================ ================================= ====== ====== ====== ========
2097154 35     0x23          Up     Prod:VRF1                                            0.0.0.0/0   15      True   True   False
2097154 35     0x23          Up     Prod:VRF1                                         172.16.1.0/24  32772   True   True   False

لاحظ أن pcTag المعين إلى 0.0.0.0/0 يستخدم القيمة 15، وليس 32772. PCtag 15 هو pcTag محجوز لنظام يتم إستخدامه فقط مع 0.0.0.0/0 والذي يعمل كحرف بدل لمطابقة جميع البادئات على L3Out.

إذا كان VRF به L3Out واحد مع L3Out EPG وحيد باستخدام 0.0.0.0/0، عندئذ تظل بادئة السياسة فريدة وهي أسهل طريقة لالتقاط الكل.

مثال 3a: ملحقات L3Out متعددة في VRF

في هذا السيناريو، توجد العديد من بروتوكولات L3Out EPG في نفس VRF.

ملاحظة: من منظور EPG القائم على البادئات، ينتج عن التكوينين التاليين إدخالات مكافئة لجدول بادئة LPM Policy-mgr:

1. L3out مع L3Out EPG واحد لكل منهما.
2. L3Out واحد مع إثنان L3Out EPGs

في كلا السيناريوهين، يكون العدد الإجمالي لملقمات L3Out EPG 2. وهذا يعني أن كل واحد سيكون لديه PCtag الخاص به والشبكات الفرعية المرتبطة به.

يمكن عرض جميع علامات تمييز EPG الخاصة ب L3Out المحددة في واجهة المستخدم الرسومية (GUI) في 'Tenant>Operational > معرف الموارد > L3Out'

التحقق من L3Out pcTag

في هذا السيناريو، تتلقى بنية قائمة التحكم في الوصول (ACI) العديد من البادئات من الموجهات الخارجية ويكون تعريف EPG للخرج من L3Out كما يلي:

• تم تعيين 172.16.1.0/24 إلى L3OUT-EPG.
• تم تعيين 172.16.2.0/24 إلى L3OUT-EPG2.
• تم تعيين 172.16.0.0/16 إلى L3OUT-EPG (للقبض على البادئة 172.16.3.0/24).

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

• يحتوي L3OUT-EPG على شبكة فرعية 172.16.1.0/24 و 172.16.0.0/16 كلاهما بنطاق 'شبكة فرعية خارجية ل EPG الخارجي'.
• يحتوي L3OUT-EPG2 على شبكة فرعية 172.16.2.0/24 مع نطاق 'شبكة فرعية خارجية ل EPG الخارجي'.

ستكون إدخالات جدول البادئات الناتجة:

bdsol-aci32-leaf3# vsh -c 'show system internal  policy-mgr prefix' |  egrep "Prod|==|Addr"
Vrf-Vni VRF-Id Table-Id Table-State  VRF-Name                    Addr                                Class Shared Remote Complete
======= ======  =========== =======  ============================ ================================= ====== ====== ====== ========
2097154 35     0x23          Up     Prod:VRF1                                            0.0.0.0/0   15      True   True   False
2097154 35     0x23          Up     Prod:VRF1                                         172.16.1.0/24  32772   True   True   False
2097154 35     0x23          Up     Prod:VRF1                                         172.16.0.0/16  32772   True   True   False
2097154 35     0x23          Up     Prod:VRF1                                         172.16.2.0/24  32773   True   True   False

يتم تعيين 172.16.2.0/24 إلى pcTag 32773 (L3OUT-EPG2) ويتم تعيين 172.16.0.0/16 إلى 32772 (L3OUT-EPG).

في هذا السيناريو، يكون الإدخال ل 172.16.1.0/24 مكرر حيث يتم تعيين الشبكة الفائقة /16 إلى نفس EPG.

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

مثال 3b: ملحقات L3Out متعددة بعقود مختلفة

يحتوي هذا السيناريو على الإعداد التالي:

• عقد ICMP يسمح ب ICMP فقط.
• عقد HTTP يسمح فقط TCP غاية ميناء 80.
• يوفر EPG1 (pcTag 32770) عقد HTTP الذي يستهلكه L3OUT-EPG (pcTag 32772).
• يوفر EPG2 (pcTag 32771) عقد ICMP الذي يستهلكه L3OUT-EPG2 (pcTag 32773).

سيتم إستخدام نفس بادئات PolicyMgr من المثال السابق:

• 172.16.1.0/24 في L3OUT-EPG يجب أن يسمح HTTP إلى EPG1
• 172.16.2.0/24 في L3OUT-EPG2 يجب أن يسمح ICMP ب EPG2

البادئة الخاصة ب policy-mgr وقواعد تقسيم المنطقة:

bdsol-aci32-leaf3# vsh -c ' show system internal  policy-mgr prefix ' |  egrep "Prod|==|Addr"
Vrf-Vni VRF-Id Table-Id Table-State  VRF-Name                    Addr                                Class Shared Remote Complete
======= ======  =========== =======  ============================ ================================= ====== ====== ====== ========
2097154 35     0x23          Up     Prod:VRF1                                            0.0.0.0/0   15      True   True   False
2097154 35     0x23          Up     Prod:VRF1                                         172.16.1.0/24  32772   True   True   False
2097154 35     0x23          Up     Prod:VRF1                                         172.16.0.0/16  32772   True   True   False
2097154 35     0x23          Up     Prod:VRF1                                         172.16.2.0/24  32773   True   True   False

bdsol-aci32-leaf3# show zoning-rule scope 2097154
+---------+--------+--------+----------+----------------+---------+---------+------+----------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |  Action  |       Priority       |
+---------+--------+--------+----------+----------------+---------+---------+------+----------+----------------------+
|   4326  |   0    |   0    | implicit |    uni-dir     | enabled | 2097154 |      | deny,log |   any_any_any(21)    |
|   4335  |   0    | 16387  | implicit |    uni-dir     | enabled | 2097154 |      |  permit  |   any_dest_any(16)   |
|   4334  |   0    |   0    | implarp  |    uni-dir     | enabled | 2097154 |      |  permit  |  any_any_filter(17)  |
|   4333  |   0    |   15   | implicit |    uni-dir     | enabled | 2097154 |      | deny,log | any_vrf_any_deny(22) |
|   4332  |   0    | 16386  | implicit |    uni-dir     | enabled | 2097154 |      |  permit  |   any_dest_any(16)   |
|   4342  | 32771  | 32773  |    5     | uni-dir-ignore | enabled | 2097154 | ICMP |  permit  |    fully_qual(7)     |
|   4343  | 32773  | 32771  |    5     |     bi-dir     | enabled | 2097154 | ICMP |  permit  |    fully_qual(7)     |
|   4340  | 32770  | 32772  |    38    |    uni-dir     | enabled | 2097154 | HTTP |  permit  |    fully_qual(7)     |
|   4338  | 32772  | 32770  |    37    |    uni-dir     | enabled | 2097154 | HTTP |  permit  |    fully_qual(7)     |
+---------+--------+--------+----------+----------------+---------+---------+------+----------+----------------------+

التحقق من صحة البيانات باستخدام fTriage — التدفق المسموح به من قبل النهج

باستخدام تدفق ICMP بين 172.16.2.1 على الشبكة الخارجية و 192.168.3.1 في EPG2، يمكن إستخدام fTriage لصيد التدفق وتحليله. في هذه الحالة، بداية الفرز على على حد سواء ورقة مفتاح 103 و 104 بما أن حركة مرور يستطيع دخلت إما منهم:

admin@apic1:~> ftriage route -ii LEAF:103,104 -sip 172.16.2.1 -dip 192.168.3.1
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "14454", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-02-22-30-41-871.txt
2019-10-02 22:30:41,874 INFO     /controller/bin/ftriage route -ii LEAF:103,104 -sip 172.16.2.1 -dip 192.168.3.1
2019-10-02 22:31:28,868 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-02 22:32:15,076 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-leaf3 Ingress: Eth1/12 (Po1) Egress: Eth1/12 (Po1) Vnid: 11365
2019-10-02 22:32:15,295 INFO     ftriage:     main:242  ingress encap string vlan-2551
2019-10-02 22:32:17,839 INFO     ftriage:     main:271  Building ingress BD(s), Ctx
2019-10-02 22:32:20,583 INFO     ftriage:     main:294  Ingress BD(s) Prod:VRF1:l3out-BGP:vlan-2551
2019-10-02 22:32:20,584 INFO     ftriage:     main:301  Ingress Ctx: Prod:VRF1
2019-10-02 22:32:20,693 INFO     ftriage:   pktrec:490  bdsol-aci32-leaf3: Collecting transient losses snapshot for LC module: 1
2019-10-02 22:32:38,933 INFO     ftriage:     nxos:1404 bdsol-aci32-leaf3: nxos matching rule id:4343 scope:34 filter:5
2019-10-02 22:32:39,931 INFO     ftriage:     main:522  Computed egress encap string vlan-2502
2019-10-02 22:32:39,933 INFO     ftriage:     main:313  Building egress BD(s), Ctx
2019-10-02 22:32:41,796 INFO     ftriage:     main:331  Egress Ctx Prod:VRF1
2019-10-02 22:32:41,796 INFO     ftriage:     main:332  Egress BD(s): Prod:BD2
2019-10-02 22:32:48,636 INFO     ftriage:     main:933  SIP 172.16.2.1 DIP 192.168.3.1
2019-10-02 22:32:48,637 INFO     ftriage:  unicast:973  bdsol-aci32-leaf3: <- is ingress node
2019-10-02 22:32:51,257 INFO     ftriage:  unicast:1202 bdsol-aci32-leaf3: Dst EP is local
2019-10-02 22:32:54,129 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: EP if(Po1) same as egr if(Po1)
2019-10-02 22:32:55,348 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: DMAC(00:22:BD:F8:19:FF) same as RMAC(00:22:BD:F8:19:FF)
2019-10-02 22:32:55,349 INFO     ftriage:     misc:659  bdsol-aci32-leaf3: L3 packet getting routed/bounced in SUG
2019-10-02 22:32:55,596 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: Dst IP is present in SUG L3 tbl
2019-10-02 22:32:55,896 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: RW seg_id:11365 in SUG same as EP segid:11365
2019-10-02 22:33:02,150 INFO     ftriage:     main:961  Packet is Exiting fabric with peer-device: bdsol-aci32-n3k-3 and peer-port: Ethernet1/16

يؤكد fTriage تنفيذ قاعدة تقسيم المناطق مقابل قاعدة ICMP من L3OUT_EPG2 إلى EPG:

2019-10-02 22:32:38,933 INFO     ftriage:     nxos:1404 bdsol-aci32-leaf3: nxos matching rule id:4343 scope:34 filter:5

التحقق من صحة البيانات باستخدام fTriage — التدفق الذي لا يسمح به النهج

مع وصول حركة مرور ICMP من 172.16.1.1 (L3OUT-EPG) إلى 192.168.3.1 (EPG2)، توقع إسقاط السياسة.

admin@apic1:~> ftriage route -ii LEAF:103,104 -sip 172.16.1.1 -dip 192.168.3.1
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "15139", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-02-22-39-15-050.txt
2019-10-02 22:39:15,056 INFO     /controller/bin/ftriage route -ii LEAF:103,104 -sip 172.16.1.1 -dip 192.168.3.1
2019-10-02 22:40:03,523 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-02 22:40:43,338 ERROR    ftriage:  unicast:234  bdsol-aci32-leaf3: L3 packet getting fwd dropped, checking drop reason
2019-10-02 22:40:43,339 ERROR    ftriage:  unicast:234  bdsol-aci32-leaf3: L3 packet getting fwd dropped, checking drop reason
SECURITY_GROUP_DENY              condition setcast:236  bdsol-aci32-leaf3: Drop reason - SECURITY_GROUP_DENY              condition set
2019-10-02 22:40:43,340 INFO     ftriage:  unicast:252  bdsol-aci32-leaf3: policy drop flow sclass:32772 dclass:32771 sg_label:34 proto:1
2019-10-02 22:40:43,340 INFO     ftriage:     main:681  : Ftriage Completed with hunch: None
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "Idle", "pid": "0", "apicId": "0", "id": "0"}}}

يؤكد fTriage أنه يتم إسقاط الحزمة باستخدام سبب SECURITY_GROUP_DENY (إسقاط السياسة) وأن المصدر المشتق pcTag هو 32772 والوجهة pcTag هو 32771. وبالتحقق من ذلك مقابل قواعد تقسيم المناطق، من الواضح أنه لا توجد إدخالات بين تلك EPG.

bdsol-aci32-leaf3# show zoning-rule  scope 2097154 src-epg 32772 dst-epg 32771
+---------+--------+--------+----------+-----+--------+-------+------+--------+----------+
| Rule ID | SrcEPG | DstEPG | FilterID | Dir | operSt | Scope | Name | Action | Priority |
+---------+--------+--------+----------+-----+--------+-------+------+--------+----------+
+---------+--------+--------+----------+-----+--------+-------+------+--------+----------+

مثال 4: نقاط نهاية L3متعددة مع بادئات متعددة

السيناريو هو إعداد مماثل للمثال 3 (تعريفات L3Out و L3Out EPG)، ولكن الشبكة المعرفة على كل من L3Out EPGs هي 0.0.0.0/0.

تكوين العقد هو التالي:

• عقد ICMP1 يسمح ب ICMP.
• عقد ICMP2 يسمح ب ICMP.
• يوفر EPG1 (pcTag 32770) عقد ICMP1 الذي يستهلكه L3OUT-EPG (pcTag 32772).
• يوفر EPG2 (pcTag 32771) عقد ICMP2 الذي يستهلكه L3OUT-EPG2 (pcTag 32773).

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

على الرغم من إستخدام '0.0.0.0/0' مرتين في نفس VRF، يتم برمجة بادئة واحدة فقط في جدول البادئات mgr الخاصة بالسياسة:

bdsol-aci32-leaf3# vsh -c ' show system internal  policy-mgr prefix ' |  egrep "Prod|==|Addr"
Vrf-Vni VRF-Id Table-Id Table-State  VRF-Name                    Addr                                Class Shared Remote Complete
======= ======  =========== =======  ============================ ================================= ====== ====== ====== ========
2097154 35     0x23          Up     Prod:VRF1                                            

أعيد فحص دفعتين أدناه. بناء على تكوين العقد أعلاه، من المتوقع ما يلي:

1. يجب السماح ب 172.16.2.1 (L3OUT-EPG2) إلى 192.168.3.1 (EPG2) بواسطة ICMP2
2. لا يجب السماح بالتحويل من 172.16.2.1 (L3OUT-EPG2) إلى 192.168.1.1 (EPG1) نظرا لعدم وجود عقد بين EPG1 و L3OUT-EPG2

التحقق من صحة البيانات باستخدام fTriage — التدفق المسموح به من قبل النهج

قم بتشغيل fTriage باستخدام تدفق ICMP من 172.16.2.1 (L3OUT-EPG2) إلى 192.168.3.1 (EPG2 — pcTag 32771).

Starting ftriage
Log file name for the current run is: ftlog_2019-10-02-23-11-14-298.txt
2019-10-02 23:11:14,302 INFO     /controller/bin/ftriage route -ii LEAF:103,104 -sip 172.16.2.1 -dip 192.168.3.1
2019-10-02 23:12:00,887 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-02 23:12:44,565 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-leaf3 Ingress: Eth1/12 (Po1) Egress: Eth1/12 (Po1) Vnid: 11365
2019-10-02 23:12:44,782 INFO     ftriage:     main:242  ingress encap string vlan-2551
2019-10-02 23:12:47,260 INFO     ftriage:     main:271  Building ingress BD(s), Ctx
2019-10-02 23:12:50,041 INFO     ftriage:     main:294  Ingress BD(s) Prod:VRF1:l3out-BGP:vlan-2551
2019-10-02 23:12:50,042 INFO     ftriage:     main:301  Ingress Ctx: Prod:VRF1
2019-10-02 23:12:50,151 INFO     ftriage:   pktrec:490  bdsol-aci32-leaf3: Collecting transient losses snapshot for LC module: 1
2019-10-02 23:13:08,595 INFO     ftriage:     nxos:1404 bdsol-aci32-leaf3: nxos matching rule id:4336 scope:34 filter:5
2019-10-02 23:13:09,608 INFO     ftriage:     main:522  Computed egress encap string vlan-2502
2019-10-02 23:13:09,609 INFO     ftriage:     main:313  Building egress BD(s), Ctx
2019-10-02 23:13:11,449 INFO     ftriage:     main:331  Egress Ctx Prod:VRF1
2019-10-02 23:13:11,449 INFO     ftriage:     main:332  Egress BD(s): Prod:BD2
2019-10-02 23:13:18,383 INFO     ftriage:     main:933  SIP 172.16.2.1 DIP 192.168.3.1
2019-10-02 23:13:18,384 INFO     ftriage:  unicast:973  bdsol-aci32-leaf3: <- is ingress node
2019-10-02 23:13:21,078 INFO     ftriage:  unicast:1202 bdsol-aci32-leaf3: Dst EP is local
2019-10-02 23:13:23,926 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: EP if(Po1) same as egr if(Po1)
2019-10-02 23:13:25,216 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: DMAC(00:22:BD:F8:19:FF) same as RMAC(00:22:BD:F8:19:FF)
2019-10-02 23:13:25,217 INFO     ftriage:     misc:659  bdsol-aci32-leaf3: L3 packet getting routed/bounced in SUG
2019-10-02 23:13:25,465 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: Dst IP is present in SUG L3 tbl
2019-10-02 23:13:25,757 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: RW seg_id:11365 in SUG same as EP segid:11365
2019-10-02 23:13:32,235 INFO     ftriage:     main:961  Packet is Exiting fabric with peer-device: bdsol-aci32-n3k-3 and peer-port: Ethernet1/16

يتم السماح بهذا التدفق (كما هو متوقع) بواسطة قاعدة تقسيم المناطق 4336.

التحقق من صحة البيانات باستخدام fTriage — التدفق الذي لا يسمح به النهج

قم بتشغيل fTriage باستخدام تدفق ICMP من 172.16.2.1 (L3OUT-EPG2) إلى 192.168.1.1 (EPG1 — pcTag 32770):

admin@apic1:~> ftriage route -ii LEAF:103,104 -sip 172.16.2.1 -dip 192.168.1.1
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "31500", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-02-23-53-03-478.txt
2019-10-02 23:53:03,482 INFO     /controller/bin/ftriage route -ii LEAF:103,104 -sip 172.16.2.1 -dip 192.168.1.1
2019-10-02 23:53:50,014 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-02 23:54:39,199 INFO     ftriage:     main:839  L3 packet Seen on bdsol-aci32-leaf3 Ingress: Eth1/12 (Po1) Egress: Eth1/12 (Po1) Vnid: 11364
2019-10-02 23:54:39,417 INFO     ftriage:     main:242  ingress encap string vlan-2551
2019-10-02 23:54:41,962 INFO     ftriage:     main:271  Building ingress BD(s), Ctx
2019-10-02 23:54:44,765 INFO     ftriage:     main:294  Ingress BD(s) Prod:VRF1:l3out-BGP:vlan-2551
2019-10-02 23:54:44,766 INFO     ftriage:     main:301  Ingress Ctx: Prod:VRF1
2019-10-02 23:54:44,875 INFO     ftriage:   pktrec:490  bdsol-aci32-leaf3: Collecting transient losses snapshot for LC module: 1
2019-10-02 23:55:02,905 INFO     ftriage:     nxos:1404 bdsol-aci32-leaf3: nxos matching rule id:4341 scope:34 filter:5
2019-10-02 23:55:04,525 INFO     ftriage:     main:522  Computed egress encap string vlan-2501
2019-10-02 23:55:04,526 INFO     ftriage:     main:313  Building egress BD(s), Ctx
2019-10-02 23:55:06,390 INFO     ftriage:     main:331  Egress Ctx Prod:VRF1
2019-10-02 23:55:06,390 INFO     ftriage:     main:332  Egress BD(s): Prod:BD1
2019-10-02 23:55:13,571 INFO     ftriage:     main:933  SIP 172.16.2.1 DIP 192.168.1.1
2019-10-02 23:55:13,572 INFO     ftriage:  unicast:973  bdsol-aci32-leaf3: <- is ingress node
2019-10-02 23:55:16,159 INFO     ftriage:  unicast:1202 bdsol-aci32-leaf3: Dst EP is local
2019-10-02 23:55:18,949 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: EP if(Po1) same as egr if(Po1)
2019-10-02 23:55:20,126 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: DMAC(00:22:BD:F8:19:FF) same as RMAC(00:22:BD:F8:19:FF)
2019-10-02 23:55:20,126 INFO     ftriage:     misc:659  bdsol-aci32-leaf3: L3 packet getting routed/bounced in SUG
2019-10-02 23:55:20,395 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: Dst IP is present in SUG L3 tbl
2019-10-02 23:55:20,687 INFO     ftriage:     misc:657  bdsol-aci32-leaf3: RW seg_id:11364 in SUG same as EP segid:11364
2019-10-02 23:55:26,982 INFO     ftriage:     main:961  Packet is Exiting fabric with peer-device: bdsol-aci32-n3k-3 and peer-port: Ethernet1/16

هذا التدفق مسموح به (غير متوقع) بواسطة قاعدة التقسيم إلى مناطق 4341. ولابد الآن من تحليل قواعد تقسيم المناطق لكي نفهم السبب وراء ذلك.

التحقق من صحة البيانات — قواعد تقسيم المناطق

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

• المتوقع — يقع التدفق فوق سطر قاعدة التقسيم 4336 (عقد ICMP2).
• غير متوقع — التدفق يضرب سطر قاعدة تقسيم المنطقة 4341 (عقد ICMP1).

+---------+--------+--------+----------+---------+---------+---------+-------+----------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID |   Dir   |  operSt |  Scope  |  Name |  Action  |       Priority       |
+---------+--------+--------+----------+---------+---------+---------+-------+----------+----------------------+
|   4326  |   0    |   0    | implicit | uni-dir | enabled | 2097154 |       | deny,log |   any_any_any(21)    |
|   4335  |   0    | 16387  | implicit | uni-dir | enabled | 2097154 |       |  permit  |   any_dest_any(16)   |
|   4334  |   0    |   0    | implarp  | uni-dir | enabled | 2097154 |       |  permit  |  any_any_filter(17)  |
|   4333  |   0    |   15   | implicit | uni-dir | enabled | 2097154 |       | deny,log | any_vrf_any_deny(22) |
|   4332  |   0    | 16386  | implicit | uni-dir | enabled | 2097154 |       |  permit  |   any_dest_any(16)   |
|   4339  | 32770  |   15   |    5     | uni-dir | enabled | 2097154 | ICMP2 |  permit  |    fully_qual(7)     |
|   4341  | 49153  | 32770  |    5     | uni-dir | enabled | 2097154 | ICMP2 |  permit  |    fully_qual(7)     |
|   4337  | 32771  |   15   |    5     | uni-dir | enabled | 2097154 | ICMP1 |  permit  |    fully_qual(7)     |
|   4336  | 49153  | 32771  |    5     | uni-dir | enabled | 2097154 | ICMP1 |  permit  |    fully_qual(7)     |
+---------+--------+--------+----------+---------+---------+---------+-------+----------+----------------------+

يتم اشتقاق كلا التدفقات من SRC pcTag الخاص ب 49153. هذا ال pcTag من ال VRF. يمكن التحقق من هذا في واجهة المستخدم:

التحقق من ال pcTag من ال VRF

يحدث التالي عندما تكون البادئة 0.0.0.0/0 قيد الاستخدام مع L3Out:

• سوف تستخرج حركة المرور من EPG داخلي إلى EPG L3Out مع 0.0.0.0/0 علامة كمبيوتر وجهة من 15.
• سوف تستمد حركة المرور من L3Out EPG مع 0.0.0.0/0 إلى ACI داخلي EPG مصدر pcTag من ال VRF (49153).

يعطي البرنامج النصي contract_parser نظرة شاملة على قواعد تقسيم المناطق:

bdsol-aci32-leaf3# contract_parser.py --vrf Prod:VRF1
Key:
[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]
[7:4339] [vrf:Prod:VRF1] permit ip icmp tn-Prod/ap-App/epg-EPG1(32770) pfx-0.0.0.0/0(15) [contract:uni/tn-Prod/brc-ICMP2] [hit=0]
[7:4337] [vrf:Prod:VRF1] permit ip icmp tn-Prod/ap-App/epg-EPG2(32771) pfx-0.0.0.0/0(15) [contract:uni/tn-Prod/brc-ICMP] [hit=0]
[7:4341] [vrf:Prod:VRF1] permit ip icmp tn-Prod/vrf-VRF1(49153) tn-Prod/ap-App/epg-EPG1(32770) [contract:uni/tn-Prod/brc-ICMP2] [hit=270]
[7:4336] [vrf:Prod:VRF1] permit ip icmp tn-Prod/vrf-VRF1(49153) tn-Prod/ap-App/epg-EPG2(32771) [contract:uni/tn-Prod/brc-ICMP] [hit=0]

تأكيد PCtag المستخدم من قبل الحزمة باستخدام تطبيق مساعد ELAM

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

تعرض لقطة الشاشة أدناه نتيجة ELAM لحركة المرور من pcTag 32771 إلى pcTag 49153.

إخراج تطبيق مساعد ELAM ل SRC 32771 إلى DST 49153

القرار

يجب تعقب إستخدام 0.0.0.0/0 بعناية داخل VRF حيث سيرث كل L3Out باستخدام هذه الشبكة الفرعية العقود المطبقة على كل L3Out آخر يستخدمه. ومن المرجح أن يؤدي هذا إلى تدفقات تصاريح غير مخطط لها.

L3Out مشترك

نظرة عامة

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

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

يستخدم هذا القسم المخطط التالي لأمثالنا.

طبولوجيا L3Out المشتركة

على مستوى عال، يجب أن تكون التكوينات التالية في مكانها ليعمل L3Out مشترك:

• يجب تكوين شبكة فرعية L3Out باستخدام نطاق "الشبكة الفرعية للتحكم في المسار المشترك" لتسريب المسارات الخارجية إلى شبكات VRF الداخلية. كما يمكن تحديد الخيار 'Aggregate Shared' لتسريب جميع المسارات الأكثر تحديدا من الشبكة الفرعية التي تم تكوينها.
• يجب تكوين شبكة فرعية L3Out باستخدام نطاق "الشبكة الفرعية لاستيراد الأمان المشترك" لبرمجة سياسات الأمان الضرورية للسماح بالاتصال من خلال L3Out هذا.
• يجب تعيين الشبكة الفرعية ل BD الداخلية على "مشاركة بين VRFs" و"الإعلان خارجيا" لبرمجة الشبكة الفرعية ل BD في VRF الخارجي والإعلان عنها.
• يجب تكوين عقد نطاق 'مستأجر' أو 'عمومي' بين EPG الداخلي و EPG الخارجي ل L3Out المشترك.

سيتطرق القسم التالي إلى تفاصيل حول كيفية الإعلان عن المسارات المسربة والتعلم منها في واجهة التحكم في الوصول (ACI).

سير عمل L3Out المشترك — تعلم المسارات الخارجية

يحدد هذا القسم مسار مسار مسار خارجي متعلم أثناء الإعلان عنه في البنية.

الطريق الخارجي كما يرى على الورقة الحدودية

سيظهر هذا الأمر المسار الخارجي الذي تم تعلمه من OSPF:

leaf103# show ip route 172.16.20.1/32 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

172.16.20.1/32, ubest/mbest: 1/0
    *via 10.10.34.3, vlan347, [110/20], 03:59:59, ospf-default, type-2

بعد ذلك، يجب إستيراد المسار إلى BGP. بشكل افتراضي، يجب إستيراد جميع الموجهات الخارجية إلى BGP.

عمليات التحقق من BGP على الورقة الحدودية

يجب أن يكون المسار في فئة عنوان VPNv4 لبروتوكول BGP مع هدف توجيه ليتم توزيعه عبر البنية. المسار-target هو مجتمع BGP موسع يتم تصديره بواسطة VRF الخارجي ويستورد بواسطة أي VRFs داخلي يحتاج إلى إستقبال المسار.

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

leaf103# show bgp process vrf Prod:Vrf1

Information regarding configured VRFs:

BGP Information for VRF Prod:Vrf1
VRF Type                       : System
VRF Id                         : 85
VRF state                      : UP
VRF configured                 : yes
VRF refcount                   : 1
VRF VNID                       : 2392068
Router-ID                      : 10.0.0.3
Configured Router-ID           : 10.0.0.3
Confed-ID                      : 0
Cluster-ID                     : 0.0.0.0
MSITE Cluster-ID               : 0.0.0.0
No. of configured peers        : 1
No. of pending config peers    : 0
No. of established peers       : 0
VRF RD                         : 101:2392068
VRF EVPN RD                    : 101:2392068

...

    Wait for IGP convergence is not configured
    Export RT list:
        65001:2392068
    Import RT list:
        65001:2392068
    Label mode: per-prefix

يوضح الإخراج المذكور أعلاه أن أي مسارات يتم الإعلان عنها من التردد اللاسلكي الخارجي إلى VPNv4 يجب أن تتلقى موجه الهدف 65001:2392068.

بعد ذلك، دققت ال BGP ممر:

leaf103# show bgp ipv4 unicast 172.16.20.1/32 vrf Prod:Vrf1
BGP routing table information for VRF Prod:Vrf1, address family IPv4 Unicast
BGP routing table entry for 172.16.20.1/32, version 30 dest ptr 0xa6f25ad0
Paths: (2 available, best #1)
Flags: (0x80c0002 00000000) on xmit-list, is not in urib, exported
  vpn: version 17206, (0x100002) on xmit-list
Multipath: eBGP iBGP

  Advertised path-id 1, VPN AF advertised path-id 1
  Path type: redist 0x408 0x1 ref 0 adv path ref 2, path is valid, is best path
  AS-Path: NONE, path locally originated
    0.0.0.0 (metric 0) from 0.0.0.0 (10.0.0.3)
      Origin incomplete, MED 20, localpref 100, weight 32768
      Extcommunity:
          RT:65001:2392068
          VNID:2392068
          COST:pre-bestpath:162:110

  VRF advertise information:
  Path-id 1 not advertised to any peer

  VPN AF advertise information:
  Path-id 1 advertised to peers:
    10.0.64.64         10.0.72.66
  Path-id 2 not advertised to any peer

توضح المخرجات الواردة أعلاه أن المسار له المسار-الهدف الصحيح. كما يمكن التحقق من مسار VPNv4 باستخدام الأمر 'show bgp vpnv4 unicast 172.16.20.1 vrf overlay-1'.

عمليات التحقق على ورقة الخادم

لكي تتمكن ورقة EPG الداخلية من تثبيت المسار المعلن عنه بواسطة BL، يجب عليها إستيراد الموجه-الهدف (المذكور أعلاه) إلى تردد الراديو الظاهري الداخلي. يمكن التحقق من عملية BGP الخاصة ب VRF الداخلي للتحقق من صحة ما يلي:

leaf101# show bgp process vrf Prod:Vrf2

Information regarding configured VRFs:

BGP Information for VRF Prod:Vrf2
VRF Type                       : System
VRF Id                         : 54
VRF state                      : UP
VRF configured                 : yes
VRF refcount                   : 0
VRF VNID                       : 2916352
Router-ID                      : 192.168.1.1
Configured Router-ID           : 0.0.0.0
Confed-ID                      : 0
Cluster-ID                     : 0.0.0.0
MSITE Cluster-ID               : 0.0.0.0
No. of configured peers        : 0
No. of pending config peers    : 0
No. of established peers       : 0
VRF RD                         : 102:2916352
VRF EVPN RD                    : 102:2916352
...
    Wait for IGP convergence is not configured
    Import route-map 2916352-shared-svc-leak
    Export RT list:
        65001:2916352
    Import RT list:
        65001:2392068
        65001:2916352

يظهر الإخراج أعلاه VRF الداخلي الذي يستورد المسار-الهدف الذي يتم تصديره بواسطة VRF الخارجي. وبالإضافة إلى ذلك، هناك 'إستيراد مخطط المسار' المشار إليه. ويتضمن مخطط مسار الاستيراد البادئات المحددة التي يتم تعريفها في L3Out المشترك باستخدام العلامة 'الشبكة الفرعية للتحكم في المسار المشترك'.

يمكن التحقق من محتويات خريطة المسار للتأكد من أنها تتضمن البادئة الخارجية:

leaf101# show route-map 2916352-shared-svc-leak
route-map 2916352-shared-svc-leak, deny, sequence 1
 Match clauses:
   pervasive: 2
 Set clauses:
route-map 2916352-shared-svc-leak, permit, sequence 2
 Match clauses:
   extcommunity  (extcommunity-list filter): 2916352-shared-svc-leak
 Set clauses:
route-map 2916352-shared-svc-leak, permit, sequence 1000
 Match clauses:
   ip address prefix-lists: IPv4-2392068-16387-5511-2916352-shared-svc-leak
   ipv6 address prefix-lists: IPv6-deny-all
 Set clauses:
a-leaf101# show ip prefix-list IPv4-2392068-16387-5511-2916352-shared-svc-leak
ip prefix-list IPv4-2392068-16387-5511-2916352-shared-svc-leak: 1 entries
  seq 1 permit 172.16.20.1/32

يعرض الإخراج أعلاه خريطة مسار الاستيراد التي تتضمن الشبكة الفرعية التي سيتم إستيرادها.

تتضمن عمليات التحقق النهائية التحقق من أن المسار موجود في جدول BGP وأنه مثبت في جدول التوجيه.

جدول BGP على ورقة الخادم:

leaf101# show bgp ipv4 unicast 172.16.20.1/32 vrf Prod:Vrf2
BGP routing table information for VRF Prod:Vrf2, address family IPv4 Unicast
BGP routing table entry for 172.16.20.1/32, version 3 dest ptr 0xa763add0
Paths: (2 available, best #1)
Flags: (0x08001a 00000000) on xmit-list, is in urib, is best urib route, is in HW
  vpn: version 10987, (0x100002) on xmit-list
Multipath: eBGP iBGP

  Advertised path-id 1, VPN AF advertised path-id 1
  Path type: internal 0xc0000018 0x40 ref 56506 adv path ref 2, path is valid, is best path
             Imported from 10.0.72.64:5:172.16.20.1/32
  AS-Path: NONE, path sourced internal to AS
    10.0.72.64 (metric 3) from 10.0.64.64 (192.168.1.102)
      Origin incomplete, MED 20, localpref 100, weight 0
      Received label 0
      Received path-id 1
      Extcommunity:
          RT:65001:2392068
          VNID:2392068
          COST:pre-bestpath:162:110
      Originator: 10.0.72.64 Cluster list: 192.168.1.102

يتم إستيراد المسار إلى جدول VRF BGP الداخلي ويحتوي على المسار-الهدف المتوقع.

يمكن التحقق من المسارات المثبتة:

leaf101# vsh -c "show ip route 172.16.20.1/32 detail vrf Prod:Vrf2"
IP Route Table for VRF "Prod:Vrf2"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 
172.16.20.1/32, ubest/mbest: 2/0
   *via 10.0.72.64%overlay-1, [200/20], 01:00:51, bgp-65001, internal, tag 65001 (mpls-vpn)
        MPLS[0]: Label=0 E=0 TTL=0 S=0 (VPN)
        client-specific data: 548
        recursive next hop: 10.0.72.64/32%overlay-1
        extended route information: BGP origin AS 65001 BGP peer AS 65001 rw-vnid: 0x248004 table-id: 0x36 rw-mac: 0
   *via 10.0.72.67%overlay-1, [200/20], 01:00:51, bgp-65001, internal, tag 65001 (mpls-vpn)
        MPLS[0]: Label=0 E=0 TTL=0 S=0 (VPN)
        client-specific data: 54a
        recursive next hop: 10.0.72.67/32%overlay-1
        extended route information: BGP origin AS 65001 BGP peer AS 65001 rw-vnid: 0x248004 table-id: 0x36 rw-mac: 0

يستخدم الإخراج أعلاه أمر 'vsh -c' محدد للحصول على الإخراج 'detail'. تتضمن علامة 'detail' معرف VNID الخاص بإعادة كتابة VXLAN. هذا ال VXLAN VNID من ال VRF خارجي. عندما يستقبل BL حركة مرور مستوى البيانات باستخدام معرف فئة المورد (VNID) هذا، فإنه يعرف أن يتخذ قرار إعادة التوجيه في VRF الخارجي.

قيمة rw-vnid هي hex، لذلك التحويل إلى decimal سيحصل على ال VRF VNID ل 2392068. ابحث عن VRF المتوافق باستخدام 'show system internal epm vrf all | GREP 2392068 على الورقة. يمكن إجراء بحث عمومي على APIC باستخدام الأمر 'moquery -c fvCtx -f 'fv.Ctx.seg="2392068"'.

يجب أن يشير عنوان IP الخاص بالخطوة التالية أيضا إلى BL PTEPs ويشير '٪overlay-1' إلى أن بحث المسار الخاص بالخطوة التالية موجود في VRF التغشية.

سير عمل L3Out مشترك — إعلان المسارات الداخلية

كما هو الحال في الأقسام السابقة، تتم معالجة إعلان الشبكات الفرعية BD الداخلية من خلال L3Out المشتركة بواسطة ما يلي:

• يتم تثبيت الشبكة الفرعية ل BD (VRF داخلي) على BL (VRF خارجي) كمسار ثابت. نشر المسار الثابت هذا هو نتيجة لعلاقة العقد بين EPG الداخلي و L3Out.
• تتم إعادة توزيع المسار الثابت في البروتوكول الخارجي عند تعيين النطاق "المعلن خارجيا" على الشبكة الفرعية ل BD.

التحقق من مسار BD الثابت على BL

leaf103# vsh -c "show ip route 192.168.1.0 detail vrf Prod:Vrf1"
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

192.168.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
    *via 10.0.120.34%overlay-1, [1/0], 00:55:27, static, tag 4294967292
         recursive next hop: 10.0.120.34/32%overlay-1
         vrf crossing information:  VNID:0x2c8000 ClassId:0 Flush#:0

لاحظت أن في الإنتاج أعلاه، ال VNID من الداخلي VRF ثبتت ل rewrite. كما يتم تعيين الخطوة التالية على عنوان Proxy-v4-anyCast.

ويتم الإعلان عن المسار المذكور أعلاه خارجيا من خلال خرائط المسار نفسها التي يتم عرضها في قسم "إعلان المسار".

إذا تم تعيين شبكة BD فرعية إلى "الإعلان خارجيا"، تتم إعادة توزيعها في كل بروتوكول خارجي ل L3Out يكون ل EPG داخلي علاقة عقد معه.

سيناريو أستكشاف أخطاء L3Out المشتركة وإصلاحها — تسرب غير متوقع للمسار

يحتوي هذا السيناريو على نقاط وصول متعددة في VRF الخارجي ويحصل EPG داخلي على مسار من L3Out حيث لم يتم تعريف الشبكة باستخدام خيارات النطاق 'المشتركة'.

إستخدام 'Aggregate Shared'

تأملوا في الشكل التالي:

تسرب غير متوقع للمسار

يتم تطبيق خريطة إستيراد BGP مع قائمة البادئات المبرمجة من علامات الشبكة الفرعية للتحكم في المسار المشترك على مستوى VRF. إذا كان لواحد من L3Out في VRF1 شبكة فرعية مع "الشبكة الفرعية للتحكم في المسار المشترك"، فسيتم إستيراد جميع المسارات المستلمة على L3Out داخل VRF1 التي تطابق هذه الشبكة الفرعية للتحكم في المسار المشترك إلى VRF2.

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