تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا وثيقة steps أن يفهم واستكشاف أخطاء L3out في ACI
استخرجت المادة من هذا المستند من أستكشاف أخطاء البنية الأساسية المرتكزة على تطبيق Cisco وإصلاحها، وكتاب الإصدار الثاني وخاصة إعادة التوجيه الخارجي- نظرة عامة، وإعادة التوجيه الخارجي - التجاور، وإعادة التوجيه الخارجية - إعلان المسار، وإعادة التوجيه الخارجية - العقد والخروج من L3وإعادة التوجيه الخارجية - مشاركة فصول L3out.
توضح الصورة التالية الوحدات البنائية الرئيسية المطلوبة لتكوين L3 خارج (L3Out).
يوضح المخطط التالي العملية عالية المستوى المعنية بالتوجيه الخارجي.
في قسم EPG الخاص ب L3Out، يمكن تحديد الشبكات الفرعية باستخدام سلسلة من خيارات "النطاق" و"التجميع" كما هو موضح أدناه:
خيارات 'النطاق':
خيارات 'التجميع':
سيتم إستخدام المخطط التالي في هذا القسم:
يشرح هذا القسم كيفية أستكشاف أخطاء بروتوكول التوجيه والتحقق من تجاور بروتوكول التوجيه على واجهات L3Out وإصلاحها.
فيما يلي بضعة معلمات للتحقق من أنها ستكون قابلة للتطبيق على جميع بروتوكولات التوجيه الخارجية الخاصة بواجهة التحكم في الوصول (ACI):
يستخدم هذا القسم مثالا على تجانس eBGP بين الاسترجاع في BL3، BL4، و R34 من المخطط في قسم النظرة العامة. BGP AS في R34 هو 65002.
تحقق من المعايير التالية عند إنشاء تجاور BGP.
سيكون رقم BGP AS الخاص بمستخدم L3Out تلقائيا هو نفسه BGP كما هو الحال بالنسبة ل infra-MP-BGP الذي تم تكوينه في سياسة عاكس مسار BGP. لا يكون تكوين "المحلي باسم" في ملف تعريف اتصال نظير BGP مطلوبا ما لم يحتاج المرء إلى إخفاء بروتوكول BGP لقائمة التحكم في الوصول (ACI) كما هو الحال في العالم الخارجي. وهذا يعني أن الموجهات الخارجية يجب أن تشير إلى BGP كما تم تكوينه في عاكس مسار BGP.
ملاحظة — السيناريو الذي يتطلب تكوين محلي AS هو نفسه الأمر NX-OS 'local-as' المستقل.
ال BGP البعيد كرقم مطلوب فقط ل eBGP حيث BGP المجاور مختلف من ACI BGP as.
تدعم واجهة التحكم في الوصول (ACI) توفير جلسة عمل BGP من واجهة الاسترجاع الموجودة أعلى نوع واجهة ACI L3Out النموذجية (موجه، واجهة فرعية، SVI).
عندما يحتاج BGP جلسة أن يكون sourced من loopback، شكلت ال BGP نظير موجز تحت ال منطقي عقدة ملف تعريف.
عندما يحتاج ال BGP جلسة أن يكون sourced من مسحاج تخديد/subinterface/SVI، شكلت ال BGP نظير موضح تحت ال منطقي قارن ملف تعريف.
عندما تكون عناوين IP النظيرة ل BGP عبارة عن إرتباطات، فتأكد من توفر إمكانية الوصول إلى عنوان IP للموجه الخارجي وشبكة BL. يمكن إستخدام المسارات الثابتة أو OSPF للحصول على إمكانية الوصول إلى عناوين IP النظيرة.
يتم تجميع مخرجات واجهة سطر الأوامر (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 مع النظير بعد. في مثل هذا السيناريو، تحقق من التالي وانتقل إلى الخطوة التالية.
2. التحقق من تفاصيل جار BGP (ملف تعريف اتصال نظير BGP)
يعرض الأمر التالي المعلمات التي هي مفتاح لإنشاء جار 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 بين BL3 و BL4 و R34 من المخطط في قسم "نظرة عامة" مع OSPF AreaID 1 (NSSA).
ما يلي هي المعايير الشائعة للتحقق من إنشاء تجاور OSPF.
يجب أن يتطابق معرف منطقة OSPF والنوع مع أي جهاز توجيه. تتضمن بعض القيود الخاصة بواجهة برمجة التطبيقات (ACI) على تكوينات معرف منطقة OSPF:
على الرغم من أنه لا يلزم أن يكون معرف OSPF هو العمود الفقري 0، إلا أنه في حالة توجيه النقل يكون مطلوبا بين فتحتي OSPF L3out على نفس الورقة، ويجب أن يستخدم أحدهما المنطقة 0 من OSPF لأن أي تبادل للمسار بين مناطق OSPF يجب أن يكون من خلال المنطقة 0 من OSPF.
تكون وحدة الحد الأقصى للنقل (MTU) الافتراضية على قائمة التحكم في الوصول (ACI) 9000 بايت، بدلا من 1500 بايت، وهو عادة الإعداد الافتراضي المستخدم على أجهزة التوجيه التقليدية. تأكد من تطابق وحدة الحد الأقصى للنقل (MTU) مع الجهاز الخارجي. عندما يفشل إنشاء جار OSPF بسبب MTU، فإنه يعلق في Exchange/DROTHER.
وهذا يعادل 'ip router ospf <tag> area <area id>' على تكوين NX-OS مستقل لتمكين OSPF على الواجهة. وبدون ذلك، لن تنضم الواجهات الطرفية إلى OSPF.
يتطلب OSPF توفر وحدات توقيت Hello و Dead لمطابقتها على كل جهاز مجاور. ويتم تكوين هذه في ملف تعريف واجهة OSPF.
تأكد من تطابق نوع شبكة واجهة OSPF مع الجهاز الخارجي. عندما يستخدم الجهاز الخارجي كتابة من نقطة إلى نقطة، يحتاج جانب واجهة التحكم في الوصول (ACI) إلى تكوين من نقطة إلى نقطة بشكل صريح أيضا. ويتم تكوين هذه أيضا في ملف تعريف واجهة 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 هو عامل التصفية الأكثر شمولا.
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 بين BL3 و BL4 و R34 من المخطط في قسم "نظرة عامة" مع EIGRP AS 10.
فيما يلي المعايير المشتركة لإنشاء تجاور EIGRP.
وهذا يعادل تكوين 'ip router eigrp <as>' على جهاز NX-OS مستقل. بدون هذا، لن تنضم الواجهات الطرفية إلى EIGRP.
وعلى الرغم من أنه لا يلزم أن يتوافق ذلك مع مجرد إنشاء منطقة جوار EIGRP، فقد تصبح حزم تبادل مخطط EIGRP أكبر من الحد الأقصى لوحدة الحد الأقصى للنقل (MTU) المسموح به على الواجهات بين الأقران، ونظرا لأنه غير مسموح بتجزئة هذه الحزم، يتم إسقاطها ونتيجة لذلك سترفرف منطقة جوار 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،:
وبالإضافة إلى ذلك، من الممكن أيضا التحكم في إعلان مجال Bridge باستخدام ملفات تعريف مسار التصدير التي تمنع الحاجة إلى ربط L3Out. ومع ذلك، ما يزال يجب تحديد 'Advertising خارجيا'. هذه حالة إستخدام أقل شيوعا لذلك لن يتم مناقشتها هنا.
يلزم وجود علاقة العقد بين L3Out و EPG من أجل دفع مسار BD الثابت المتفشي إلى BL. تتم معالجة إعلان المسار الفعلي من خلال إعادة توزيع المسار الثابت إلى البروتوكول الخارجي. وأخيرا، سيتم تثبيت خرائط مسار إعادة التوزيع فقط داخل L3Out المرتبطة ب BD. بهذه الطريقة لا يتم الإعلان عن المسار عبر كل L3Out.
في هذه الحالة، تكون الشبكة الفرعية BD هي 192.168.1.0/24 ويجب الإعلان عنها عبر OSPF L3Out.
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 ب 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'. تمنع جميع البروتوكولات الخارجية إعادة توزيع هذه العلامة.
لم يتم اقتران 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>' على أي قوائم بادئات موجودة في خريطة المسار. قم بذلك في الخطوة التالية.
وكما تمت الإشارة مسبقا، ينتج عن هذه الخطوة قائمة البادئات التي تطابق شبكة 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. وبعد هذه النقطة، سيكون التحقق خاصا بالبروتوكول. على سبيل المثال:
بالنسبة لبروتوكول 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.
وكما هو الحال مع 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 العامل النهائي أدناه.
في هذه الحالة، يكون العرض النموذجي هو عدم الإعلان عن شبكة BD فرعية مكونة من خارج L3Out. اتبع سير العمل السابق لفهم أي مكون تم كسره.
ابدأ بالتكوين قبل الحصول على مستوى منخفض جدا عن طريق التحقق مما يلي:
السبب المحتمل: لم يتم نشر BD
تنطبق هذه الحالة في سيناريوهين مختلفين، مثل:
وفي كلتا الحالتين، لن يتم نشر 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 الخارجي والأعلام التي يتم تحديدها. هناك مثالين حيث أن هذا غير صحيح.
لكي يتم توزيع مسار خارجي على ورقة داخلية، يجب أن يحدث ما يلي:
إذا كان EPG/BD الداخلي في نفس VRF الخاص ب L3Out فإن الخطوات الثلاث المذكورة أعلاه هي كل ما هو مطلوب ل EPG/BD الداخلي لاستخدام المسارات الخارجية.
وفي هذه الحالة، فإن المسار الخارجي الذي ينبغي تعلمه على المحولين 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) مسارا (مسارات) خارجيا.
كما هو الحال دائما، تحقق أولا من الأساسيات. تأكد من:
إذا كانت المعايير المذكورة أعلاه صحيحة، ففيما يلي بعض الأمثلة الأكثر تقدما على ما يمكن أن يسبب المشكلة.
السبب المحتمل: لم يتم نشر 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 و 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، يجب تكوين أحد العناصر التالية:
ستؤدي التكوينات المذكورة أعلاه إلى الإعلان عن مسار النقل، ولكن لا يزال يتعين وجود سياسة أمان عليه للسماح بحركة مرور مستوى البيانات بالتدفق. كما هو الحال مع أي اتصال 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 الخاصة بالاستقبال والإعلان، يجب الإعلان عن المسار من خلال البنية باستخدام بروتوكول BGP. عندما تكون نقاط الوصول (BLs) متطابقة، يمكن إجراء إعادة التوزيع أو الإعلان مباشرة بين البروتوكولات الموجودة على الورقة.
وفيما يلي وصف موجز لكيفية تنفيذ ذلك:
يتضمن سيناريو أستكشاف الأخطاء وإصلاحها هذا المسارات التي يجب التعرف عليها من خلال خرج L3Out واحد ولا يتم إرسالها من خرج L3Out الآخر.
كالعادة، تحقق من الأساسيات قبل النظر إلى أي شيء خاص ب ACI.
إذا تم تكوين جميع عمليات التحقق من البروتوكول الأساسي بشكل صحيح، فيما يلي بعض الأسباب الشائعة الأخرى لموجه النقل الذي لا يتم الإعلان عنه.
السبب المحتمل: لا توجد منطقة OSPF رقم 0
إذا كانت الطوبولوجيا المتأثرة تتضمن عمليتي توصيل OSP L3Out على نفس ورقة الحدود، فيجب أن تكون هناك منطقة 0 للطرق التي يتم الإعلان عنها من منطقة إلى أخرى. انظر إلى النقطة المنسوبة أعلاه "توجيه النقل بين إثنين من OSPF L3Out على نفس الورقة" للحصول على مزيد من التفاصيل.
السبب المحتمل: منطقة OSPF عبارة عن كعب أو NSSA
وسيظهر هذا إذا تم تكوين OSPF L3Out باستخدام منطقة Stub أو NSSA التي لم يتم تكوينها للإعلان عن LSAs الخارجية. باستخدام بروتوكول فتح أقصر مسار أولا (OSPF)، لا يتم الإعلان أبدا عن إتفاقات منطقة التخزين الطويلة (LSA) الخارجية في مناطق كعب. ويتم الإعلان عنها في مناطق NSSA إذا تم تحديد "إرسال LSA التي تمت إعادة توزيعها في منطقة NSSA".
في هذا السيناريو، تكمن المشكلة في عدم تلقي بعض الموجهات المعلن عنها بواسطة ACI L3Out مرة أخرى في خرج L3آخر. يمكن تطبيق هذا السيناريو إذا كانت وحدات L3Out في بنيتين منفصلتين وكانت متصلة بموجهات خارجية أو إذا كانت وحدات L3Out في شبكات VRF مختلفة وكانت المسارات يتم تمريرها بين شبكات VRF بواسطة موجه خارجي.
السبب المحتمل: تم تكوين BL باستخدام معرف الموجه نفسه في شبكات VRF متعددة
من منظور تكوين، لا يمكن تكرار معرف الموجه داخل نفس VRF. مهما، هو عادة جيد أن يستعمل ال نفسه مسحاج تخديد-id في VRFs مختلف طالما الإثنان VRFs لا يربط إلى ال نفسه تحشد بروتوكول مجال.
تأملوا في الطوبولوجيا التالية:
المشكلة هنا أن 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).
ويمكن ملاحظة هذا السيناريو عندما يتم الإعلان عن طرق النقل من خلال مخرج 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).
في 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).
يكون المستخدم مسؤولا عن تحديد جدول EPG المستند إلى البادئة. ويتم القيام بذلك باستخدام نطاق الشبكة الفرعية 'الشبكة الفرعية الخارجية ل EPG الخارجي'. ستقوم كل مجموعة شبكات فرعية بهذا النطاق بإضافة إدخال في جدول ساكن إستاتيكي أطول تطابق للبادئة (LPM). ستشير هذه الشبكة الفرعية إلى قيمة pcTag التي سيتم إستخدامها لأي عنوان IP يقع ضمن تلك البادئة.
يمكن التحقق من جدول LPM للشبكات الفرعية EPG المستندة إلى البادئات على المحولات الطرفية باستخدام الأمر التالي:
vsh -c 'show system internal policy-mgr prefix'
ملاحظات:
السيناريو: 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
أولا، أضف الشبكة الفرعية إلى جدول البادئات.
دققت البرمجة من البادئة قائمة على الورقة مفتاح أن يتلقى ال 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.
تمديد على المثال السابق، في هذا السيناريو، يستقبل 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، عندئذ تظل بادئة السياسة فريدة وهي أسهل طريقة لالتقاط الكل.
في هذا السيناريو، توجد العديد من بروتوكولات L3Out EPG في نفس VRF.
ملاحظة: من منظور EPG القائم على البادئات، ينتج عن التكوينين التاليين إدخالات مكافئة لجدول بادئة LPM Policy-mgr:
في كلا السيناريوهين، يكون العدد الإجمالي لملقمات L3Out EPG 2. وهذا يعني أن كل واحد سيكون لديه PCtag الخاص به والشبكات الفرعية المرتبطة به.
يمكن عرض جميع علامات تمييز EPG الخاصة ب L3Out المحددة في واجهة المستخدم الرسومية (GUI) في 'Tenant>Operational > معرف الموارد > L3Out'
في هذا السيناريو، تتلقى بنية قائمة التحكم في الوصول (ACI) العديد من البادئات من الموجهات الخارجية ويكون تعريف EPG للخرج من 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 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.
يحتوي هذا السيناريو على الإعداد التالي:
سيتم إستخدام نفس بادئات PolicyMgr من المثال السابق:
البادئة الخاصة ب 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) | +---------+--------+--------+----------+----------------+---------+---------+------+----------+----------------------+
باستخدام تدفق 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
مع وصول حركة مرور 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 | +---------+--------+--------+----------+-----+--------+-------+------+--------+----------+ +---------+--------+--------+----------+-----+--------+-------+------+--------+----------+
السيناريو هو إعداد مماثل للمثال 3 (تعريفات L3Out و L3Out EPG)، ولكن الشبكة المعرفة على كل من L3Out EPGs هي 0.0.0.0/0.
تكوين العقد هو التالي:
قد يبدو هذا التكوين مثاليا في حالة ما إذا كانت الشبكة الخارجية تعلن عن العديد من البادئات، ولكن يوجد مجموعتان على الأقل من البادئات التي تتبع أنماط تدفق مسموح بها مختلفة. في هذا المثال، يجب أن تسمح بادئة واحدة فقط ب 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
أعيد فحص دفعتين أدناه. بناء على تكوين العقد أعلاه، من المتوقع ما يلي:
قم بتشغيل 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 باستخدام تدفق 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. ولابد الآن من تحليل قواعد تقسيم المناطق لكي نفهم السبب وراء ذلك.
فيما يلي قواعد تقسيم المناطق المقابلة للاختبارين الأخيرين:
+---------+--------+--------+----------+---------+---------+---------+-------+----------+----------------------+ | 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. يمكن التحقق من هذا في واجهة المستخدم:
يحدث التالي عندما تكون البادئة 0.0.0.0/0 قيد الاستخدام مع L3Out:
يعطي البرنامج النصي 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]
يعطي تطبيق مساعد ELAM طريقة أخرى لتأكيد PCtag المصدر والوجهة لتدفقات حركة المرور المباشرة.
تعرض لقطة الشاشة أدناه نتيجة ELAM لحركة المرور من pcTag 32771 إلى pcTag 49153.
يجب تعقب إستخدام 0.0.0.0/0 بعناية داخل VRF حيث سيرث كل L3Out باستخدام هذه الشبكة الفرعية العقود المطبقة على كل L3Out آخر يستخدمه. ومن المرجح أن يؤدي هذا إلى تدفقات تصاريح غير مخطط لها.
سيناقش هذا القسم كيفية أستكشاف أخطاء إعلان المسار وإصلاحها في تكوينات L3Out المشتركة. يشير مصطلح "L3Out مشترك" إلى السيناريو حيث L3Out يكون في VRF واحد ولكن EPG داخلي يتلقى عقد مع L3Out يكون في VRF آخر. باستخدام عمليات خروج L3المشتركة، يتم تسجيل الدخول إلى المسار داخليا إلى بنية واجهة التحكم في الوصول (ACI).
لن يدخل هذا القسم في تفاصيل عميقة حول أستكشاف أخطاء سياسة الأمان وإصلاحها. لذلك ارجع إلى فصل "السياسات الأمنية" في هذا الكتاب. لن يتحدث هذا القسم أيضا بالتفصيل عن تصنيف بادئات السياسة الخارجية لأغراض الأمان. أحلت ال "عقد و L3out" قسم في "إعادة توجيه خارجي" فصل.
يستخدم هذا القسم المخطط التالي لأمثالنا.
على مستوى عال، يجب أن تكون التكوينات التالية في مكانها ليعمل L3Out مشترك:
سيتطرق القسم التالي إلى تفاصيل حول كيفية الإعلان عن المسارات المسربة والتعلم منها في واجهة التحكم في الوصول (ACI).
يحدد هذا القسم مسار مسار مسار خارجي متعلم أثناء الإعلان عنه في البنية.
سيظهر هذا الأمر المسار الخارجي الذي تم تعلمه من 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.
يجب أن يكون المسار في فئة عنوان 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 التغشية.
كما هو الحال في الأقسام السابقة، تتم معالجة إعلان الشبكات الفرعية BD الداخلية من خلال L3Out المشتركة بواسطة ما يلي:
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 داخلي علاقة عقد معه.
يحتوي هذا السيناريو على نقاط وصول متعددة في VRF الخارجي ويحصل EPG داخلي على مسار من L3Out حيث لم يتم تعريف الشبكة باستخدام خيارات النطاق 'المشتركة'.
تأملوا في الشكل التالي:
يتم تطبيق خريطة إستيراد BGP مع قائمة البادئات المبرمجة من علامات الشبكة الفرعية للتحكم في المسار المشترك على مستوى VRF. إذا كان لواحد من L3Out في VRF1 شبكة فرعية مع "الشبكة الفرعية للتحكم في المسار المشترك"، فسيتم إستيراد جميع المسارات المستلمة على L3Out داخل VRF1 التي تطابق هذه الشبكة الفرعية للتحكم في المسار المشترك إلى VRF2.
يمكن أن يؤدي التصميم أعلاه إلى تدفقات حركة مرور غير متوقعة. في حالة عدم وجود عقود بين EPG الداخلي و EPG الخاص بالإعلان غير المتوقع L3Out، فحينئذ ستحدث حالات إسقاط حركة مرور البيانات.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
10-Aug-2022 |
الإصدار الأولي |