أستكشاف الأخطاء وإصلاحها في تسرب المسار غير المتوقع في واجهة التحكم في الوصول (ACI)
المحتويات
نظرة عامة
تتعامل واجهة التحكم في الوصول (ACI) مع العديد من تكوينات التوجيه والتحويل المعقدة تقليديا من خلال نشر السياسات البسيطة. ومن بين هذه الوظائف القدرة على تسريب المسارات بين شبكات VRFS من أجل تسهيل الخدمات المشتركة. وبشكل تقليدي، تطلب هذا العديد من الخطوات مثل تحديد أهداف المسار، وإنشاء عائلات عناوين BGP، ومميزات المسار، ومحاكاة هذا التكوين عبر العديد من الأجهزة.
ضمن عملية تسريب مسار قائمة التحكم في الوصول (ACI) يتم التعامل معها عبر مجموعة من العقود وتعيين علامات مشتركة محددة على الشبكات الفرعية. يتم معالجة جميع التكوين التقليدي المطلوب لعمل تسريب المسار على الطرف الخلفي نتيجة لتكوين العقد والشبكات الفرعية المشتركة.
ومع ذلك، مع تجريد هذا التكوين، قد يصبح تحديد العقد الذي يتسبب في تسرب المسار بالفعل أكثر صعوبة. ويصدق هذا بشكل خاص في البيئات التي تحتوي على أعداد كبيرة من بروتوكولات EPG و VRFS والعقود. إذا كان يتم تسرب مسار بشكل غير متوقع بين VRFS كيف يمكن أن يحدد المسؤول أي تكوين (عقد) يتسبب في حدوث هذا؟
الغرض من هذا المستند هو توضيح كيفية تحديد علاقة العقد التي تتسبب في تسريب مسار في قائمة التحكم في الوصول (ACI) بين شبكات VRF. ومن المفيد أن يكون ملما بالفعل بالمفاهيم التقليدية لتسريب المسارات مثل أهداف المسار والإصدار الرابع من بروتوكول VPN لبروتوكول BGP.
البرامج المستخدمة
تستند جميع الأمثلة الواردة في هذا المستند إلى برنامج ACI 4.2(3j).
لماذا يتم تثبيت شبكة فرعية من VRF X لمجال Bridge / EPG في VRF Y؟
سيركز هذا القسم على السيناريو الذي يتم فيه تسريب شبكة BD أو EPG فرعية بشكل غير متوقع إلى VRF آخر. لكي يتم تسريب الشبكة الفرعية BD / EPG، يجب تكوين علامة "مشترك بين VRFs". الجزء الأكثر صعوبة هو فهم أي العقد يتسبب في تسريب هذا حتى هذا ما سيعالجه هذا القسم.
في المستوى العالي، هذا هو سير العمل لما يحدث عندما يتم تسريب شبكة BD / EPG فرعية بين VRFS.
شكل 1.
*لاحظ أن #3 يمكن تطبيقه فقط عند الإعلان عن خرج L3مشترك. يتم تطبيق #1 و #2 دائما بغض النظر عن ما إذا كان يتم إستخدام L3out مشترك أو كانت الخدمات المشتركة داخلية بالكامل.
أولا، كيف يمكن للمستخدم معرفة ما إذا كان المسار الذي تم تثبيته قد تم تسريبه كنتيجة لشبكة فرعية BD أو EPG؟
عند تشغيل <name>show ip route vrf" تشير علامة التوسيع" إلى أن المسار هو شبكة BD أو EPG فرعية.
على سبيل المثال، في الطوبولوجيا المذكورة أعلاه، يمكن ملاحظة ذلك على الورقة الحدودية في التردد اللاسلكي الخارجي (VRF1):
leaf103# show ip route 10.100.100.100 vrf jy:vrf1
IP Route Table for VRF "jy:vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%
' in via output denotes VRF
10.100.100.0/24, ubest/mbest: 1/0, attached, direct,
pervasive *via 10.3.144.68%overlay-1, [1/0], 21:29:54, static, tag 4294967292 recursive next hop: 10.3.144.68/32%overlay-1
بالإضافة إلى ذلك، يمكن عرض vrf للوجهة التي تم تسريب الشبكة الفرعية منها عن طريق تشغيل الأمر التالي:
leaf103# vsh -c "show ip route 10.100.100.100 detail vrf jy:vrf1"
IP Route Table for VRF "jy:vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%
' in via output denotes VRF
10.100.100.0/24, ubest/mbest: 1/0, attached, direct,
pervasive *via 10.3.144.68%overlay-1, [1/0], 21:34:16, static, tag 4294967292 recursive next hop: 10.3.144.68/32%overlay-1
vrf crossing information: VNID:0x258003 ClassId:0x18 Flush#:0x2
*(لاحظ أن معلومات مرور VRF تم تعيينها بغض النظر عما إذا كانت الوجهة VRF مختلفة عن البحث VRF).
في الإخراج أعلاه، يتم تعيين معرف فئة المورد (VRF) المتجاوز على 0x258003، أو الرقم العشري 2457603. كيف يمكن تحديد VRF الذي ينتمي إليه معرف فئة المورد (VNID) 2457603؟
من APIC قم بالاستعلام عن كائن FVctx وعامل التصفية استنادا إلى معرف الخادم.
apic1# moquery -c fvCtx -f 'fv.Ctx.seg=="2457603"' Total Objects shown: 1 # fv.Ctx name : vrf2 dn : uni/tn-jy/ctx-vrf2 pcEnfDir : ingress pcEnfPref : enforced pcTag : 49153 scope : 2457603 seg : 2457603
كما هو متوقع، يتم تعلم المسار من التردد اللاسلكي VRF2.
لا يزال غير معروف عند هذه النقطة أي العقد يتم إستخدامه بالإضافة إلى أي شركة EPG تقوم بتوفيره وأي شركة EPG تستهلكه لجعل هذا المسار يتم تثبيته. هناك بعض الاعتبارات التي يجب تذكرها فيما يتعلق بالعلاقة بين الموفر والمستهلك:
1. بالنسبة لعلاقة عقد بين مستويات التردد اللاسلكي (VRF)، يتم تثبيت العقد (وقاعدة تقسيم المناطق الناتجة) فقط في VRF الخاص بشركة المستهلك. ونتيجة لذلك، لن يعرض "show zoning-rule" في الموفر vrf العلاقة.
2. على الرغم من أن العقد مثبت فقط في VRF الخاص بالمستهلك، يجب أن يحصل الموفر VRF على مسار الشبكة الفرعية VRF BD للمستهلك، مما يعني أن الورقة يجب أن تحتوي على مرجع تكوين إلى العقد.
تحديد العقد عند تسريب المسار بشكل غير متوقع إلى VRF الخاص بالمستهلك
كائن ipCons على الورقة مثبت على الورقة التي تشير إلى...
أ) الطريق الذي يتم تسريبه للمستهلك
ب) العقد المنشئ للعلاقه
ج) شركات التوريد والمستهلكين المتخصصة في العلاقة.
في الناتج أدناه "jy:vrf1" هو VRF المستهلك أن الطريق يجري تسريبه إلى و "10.100.100.0/24" هو الطريق الذي يجري تسريبه.
leaf103# moquery -c ipCons -f 'ip.Cons.dn*"jy:vrf1/rt-\[10.100.100.0/24\]"' Total Objects shown: 1 # ip.Cons consDn : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no] subConsDn : childAction : dn : sys/ipv4/inst/dom-jy:vrf1/rt-[10.100.100.0/24]/rsrouteToRouteDef-[bd-[uni/tn-jy/BD-bd1]-isSvc-no/epgDn-[uni/tn-jy/ap-ap1/epg-epg1]/rt-[10.100.100.1/24]]/cons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]-sub-[] lcOwn : local modTs : 2019-12-23T12:50:51.440-05:00 name : nameAlias : rn : cons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]-sub-[] status :
من الإخراج أعلاه يكون اسم العقد "مشترك"، ويكون اسم المستهلك هو l3out epg "uni/tn-jy/out-jy-ospf/instP-all"، بينما يكون EPG الموفر "uni/tn-jy/ap-ap1/epg-epg1".
تحديد العقد عند تسريب المسار بشكل غير متوقع إلى الموفر VRF
تم تثبيت كائن consNode على الورقة في الموفر vrf. إنها تشير إلى شبكة BD الفرعية في VRF المستهلك التي يتم تسريبها، العقد، و EPG داخل العلاقة. قبل الاستعلام عن هذا الكائن، ابحث عن الشبكة الفرعية BD حيث تم تكوين المسار. يمكن القيام بذلك من خلال الاستعلام عن كائن fvSubnet على APIC:
apic1:~> moquery -c fvSubnet -f 'fv.Subnet.dn*"10.100.100"' # fv.Subnet ip : 10.100.100.1/24 dn : uni/tn-jy/BD-bd1/subnet-[10.100.100.1/24] preferred : no rn : subnet-[10.100.100.1/24] scope : public,shared
يتم تكوين المسار في مجال الجسر tn-jy/BD-bd1. أستخدم هذا ومعرف المورد VRF (الذي يتم تسريب المسار إليه) لتشغيل الأمر أدناه.
leaf103# moquery -c consNode -f 'cons.Node.dn*"2949122"' -f 'cons.Node.dn*"tn-jy/BD-bd1"' Total Objects shown: 1 # cons.Node consDn : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/ap-ap1/epg-epg1]-any-no] annotation : childAction : descr : dn : consroot-[bd-[uni/tn-jy/BD-bd1]-isSvc-no]-[sys/ctx-[vxlan-2949122]]/consnode-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]] extMngdBy : lcOwn : local modTs : 2019-12-23T12:25:36.153-05:00 name : nameAlias : rn : consnode-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]] status : uid : 0
من الإخراج أعلاه يكون اسم العقد "مشترك"، ويكون اسم المستهلك هو "uni/tn-jy/ap-ap1/epg-epg1"، ويكون عنوان الموفر هو l3out "tn-jy/out-jy-ospf/instP-all".
تحديد العقد عند تسريب المسار بشكل غير متوقع بواسطة عقد vzAny مستهلك
سيكون مثال vzAny مطابقا من منظور التحقق من الصحة إلى علاقة موفرة / مستهلك تقليدية. الأمثلة التالية ستوضح فقط كيف سيبدو هذا. لاحظ أن العقد بين شبكات VRF مدعوم فقط مع VZany كمستهلك.
vzAny مثال 1: تم تسريب المسار بشكل غير متوقع إلى VRF للمستهلك
مماثل للمثال الأول الذي تم النظر فيه حيث تم التحقق من الصحة في VRF المستهلك، فإن كائن ipCons سيتم إستخدامه مرة أخرى.
leaf103# moquery -c ipCons -f 'ip.Cons.dn*"jy:vrf1/rt-\[10.100.100.0/24\]"' Total Objects shown: 1 # ip.Cons consDn : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ctx-vrf1/any]/fr-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf1/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf1/any]-any-yes]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no] subConsDn : childAction : dn : sys/ipv4/inst/dom-jy:vrf1/rt-[10.100.100.0/24]/rsrouteToRouteDef-[bd-[uni/tn-jy/BD-bd1]-isSvc-no/epgDn-[uni/tn-jy/ap-ap1/epg-epg1]/rt-[10.100.100.1/24]]/cons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ctx-vrf1/any]/fr-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf1/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf1/any]-any-yes]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]-sub-[] lcOwn : local modTs : 2019-12-23T13:11:08.077-05:00 name : nameAlias : rn : cons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ctx-vrf1/any]/fr-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf1/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf1/any]-any-yes]/to-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]]-sub-[] status :
من الإخراج المذكور أعلاه، يكون اسم العقد "shared"، بينما يمثل عنوان EPG الخاص بالمستهلك معرف فئة المورد (VRF1) أي "tn-jy/ctx-vrf1/any"، بينما يكون عنوان ربط الموفر هو "uni/tn-jy/ap-ap1/epg-epg1".
vzAny مثال 2: تم تسريب المسار بشكل غير متوقع إلى الموفر VRF
مماثل للمثال الثاني نظر إلى حيث تم التحقق من الصحة في الموفر VRF، سيتم إستخدام كائن consNode مرة أخرى. تذكر أن تحصل على اسم BD حيث يتم تكوين الشبكة الفرعية المسربة و VNID الخاص ب VRF الذي تم تسريبه.
leaf103# moquery -c consNode -f 'cons.Node.dn*"vxlan-2949122"' -f 'cons.Node.dn*"tn-jy/BD-bd1"' Total Objects shown: 1 # cons.Node consDn : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf2/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf2/any]-any-yes] annotation : childAction : descr : dn : consroot-[bd-[uni/tn-jy/BD-bd1]-isSvc-no]-[sys/ctx-[vxlan-2949122]]/consnode-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf2/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf2/any]-any-yes]] extMngdBy : lcOwn : local modTs : 2019-12-23T13:06:09.016-05:00 name : nameAlias : rn : consnode-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/out-jy-ospf/instP-all]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]/to-[uni/tn-jy/brc-shared/any-[uni/tn-jy/ctx-vrf2/any]-type-cons_as_any/cons-[uni/tn-jy/ctx-vrf2/any]-any-yes]] status : uid : 0
من الإخراج المذكور أعلاه، يكون اسم العقد "shared"، بينما يمثل EPG المستهلك VRF2 vzAny "tn-jy/ctx-vrf2/any"، ويكون EPG الموفر هو l3out "tn-jy/out-jy-ospf/instP-all".
لماذا يتم تثبيت مسار خارجي من VRF Y في VRF X؟
على مستوى عال، هذا هو سير العمل لما يحدث عندما يتم تسريب مسار L3out-learned (خارجي) بين VRFS.
شكل 2.
كما يمكن رؤية ذلك أعلاه، يقوم بروتوكول VRF الداخلي (VRF2 في هذه الحالة) بتثبيت إستيراد مسار-هدف يتطابق مع VRF1. كما يقوم بتثبيت خريطة إستيراد على عملية BGP يجب أن تحتوي على إدخالات قائمة البادئات تطابق كل ما تم تعريفه في L3out الذي تم تحديد العلامة "الشبكة الفرعية للتحكم في المسار المشترك" به.
وبغض النظر عن أي EPG هو الموفر أو المستهلك، فإن خطوات التحقق هي نفسها لأن العقد سيكون مسؤولا دائما عن التسبب في إستيراد المسار-الهدف وقوائم البادئات المقابلة التي ستسرب المسارات ليتم تثبيتها.
بادئ ذي بدء، تأكد من أن المسار يتم تعلمه في الواقع من خلال l3out:
leaf101# show ip route 10.9.9.1 vrf jy:vrf2
IP Route Table for VRF "jy:vrf2"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%
' in via output denotes VRF
10.9.9.1/32, ubest/mbest: 1/0 *
via 10.3.248.4%
overlay-1, [200/5], 00:00:13,
bgp-65001, internal, tag 65001
في المثال السابق، حقيقة أنه تم تعلمه من عملية BGP من النسيج يشير إلى ورقة أخرى في التغشية تشير إلى أن هذا أتى من l3out.
قم بتشغيل المعلومات التالية للحصول على مزيد من المعلومات حول أي من الترجمات الافتراضية التي تم التعرف عليها:
leaf101# vsh -c "show ip route 10.9.9.1 detail vrf jy:vrf2"
IP Route Table for VRF "jy:vrf2"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%
' in via output denotes VRF
10.9.9.1/32, ubest/mbest: 1/0 *via 10.3.248.4%overlay-1, [200/5], 00:05:46, bgp-65001, internal, tag 65001 (mpls-vpn) MPLS[0]: Label=0 E=0 TTL=0 S=0 (VPN) client-specific data: 6b recursive next hop: 10.3.248.4/32%overlay-1 extended route information: BGP origin AS 65001 BGP peer AS 65001
rw-vnid: 0x2d0002 table-id: 0x17 rw-mac: 0
كما هو موضح في هذا المستند، فإن إعادة كتابة vnid 0x2d0002 / 2949122 هي vrf الوجهة. تشير قيمة rw-vnid التي يتم تعيينها على قيمة غير صفرية في مثال مسار خارجي إلى أنه قد تم التعرف على ذلك من VRF مختلف. قد يشير تشغيل moquery -c fvCtx -f 'fv.Ctx.seg="2949122"" على APIC إلى أن هذا ينتمي إلى VRF1.
بعد ذلك، ابحث عن واردات المسار-الهدف بالإضافة إلى خريطة مسار الاستيراد المرتبطة بعملية BGP.
leaf101# show bgp process vrf jy:vrf2
Information regarding configured VRFs:
BGP Information for VRF jy:vrf2
VRF Type : System
VRF Id : 23
VRF state : UP
VRF configured : yes
VRF refcount : 0
VRF VNID : 2457603
Router-ID : 10.100.100.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 : 101:2457603
VRF EVPN RD : 101:2457603
Information for address family IPv4 Unicast in VRF jy:vrf2
Table Id : 17
Table state : UP
Table refcount : 5
Peers Active-peers Routes Paths Networks Aggregates
0 0 2 2 0 0
Redistribution
None
Wait for IGP convergence is not configured
Import route-map 2457603-shared-svc-leak <-- bgpRtCtrlMapP
Export RT list:
65001:2457603
Import RT list:
65001:2457603
65001:2949122 <-- bgpRttEntry
Label mode: per-prefix
يقوم التردد اللاسلكي الداخلي أعلاه بتصدير واستيراد الهدف الخاص به للمسار (65001:2457603). وهي تستورد أيضا 65001:2949122. يماثل ال 2949122 RT ال VRF VNID أي هو يستورد (VRF1). BGPrtCtrlMapP هو اسم الكائن الخاص باستيراد خريطة المسار والذي يحتوي على قوائم البادئات. BGPrttEntry هو اسم الكائن الخاص باستيراد route-target.
بعد ذلك، باستخدام معرف vnid الخاص ب VRF الداخلي الذي يتعلم مسارات VRF الخارجية، يمكنك الاستعلام عن جميع قوائم البادئات التي يتم تثبيتها داخل خريطة مسار الخدمات المشتركة.
leaf101# moquery -c rtpfxEntry -f 'rtpfx.Entry.dn*"pfxlist-IPv4'.*'2457603-shared-svc-leak"' | egrep "criteria|dn|pfx|toPfxLen" # rtpfx.Entry criteria : inexact dn : sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak/ent-2 pfx : 0.0.0.0/0 toPfxLen : 32 # rtpfx.Entry criteria : exact dn : sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak/ent-3 pfx : 10.9.9.1/32 toPfxLen : 0 # rtpfx.Entry criteria : exact dn : sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak/ent-1 pfx : 10.9.9.0/24 toPfxLen : 0
يجب أن يتوافق كل إدخال مع شبكة فرعية خارجية. تشير السمة "exact / inexact" إلى ما إذا كان قد تم تعيين العلامة "aggregate shared" على الشبكة الفرعية الخارجية. تشير البادئة 0.0.0.0/0 ذات العلامة غير الدقيقة إلى أنها ستطابق جميع المسارات الأكثر تحديدا (كل المسارات بشكل فعال). تشير البادئة 10.9.9.0/24 ذات العلامة الدقيقة إلى أنها لن تطابق إلا ذلك /24.
العثور على الإدخال (أو الإدخالات) الذي يطابق المسار الذي يتم تسريبه بشكل غير متوقع. وفي هذه الحالة، تكون البادئة 10.9.9.1/32 مطابقة بالبندين ENT-2 و ENT-3 في النواتج المذكورة أعلاه.
باستخدام اسم قائمة البادئات، ابحث عن الرقم التسلسلي داخل خريطة المسار التي تطابق هذا الرقم.
leaf101# moquery -c rtmapRsRtDstAtt -f 'rtmap.RsRtDstAtt.tDn*"pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak"' Total Objects shown: 1 # rtmap.RsRtDstAtt tDn : sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak childAction : dn : sys/rpm/rtmap-2457603-shared-svc-leak/ent-1001/mrtdst/rsrtDstAtt-[sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak] forceResolve : yes lcOwn : local modTs : 2019-12-24T11:17:08.668-05:00 rType : mo rn : rsrtDstAtt-[sys/rpm/pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leak] state : formed stateQual : none status : tCl : rtpfxRule tSKey : IPv4-2949122-24-25-2457603-shared-svc-leak tType : mo
يوضح الإخراج أعلاه أن هذا هو إدخال خريطة المسار 1001. الجزء الأخير هنا هو فهم العقد الذي كان مسؤولا عن إنشاء إدخال خريطة المسار 1001 داخل خريطة المسار 2457603-shared-svc-leaks. يمكن الاستعلام عن هذا على الورقة من كائن fvAppEpGCons.
leaf101# moquery -c fvAppEpGCons -f 'fv.AppEpGCons.dn*"rtmap-2457603-shared-svc-leak/ent-1001"' Total Objects shown: 1 # fv.AppEpGCons consDn : cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ap-ap1/epg-epg1]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no] childAction : descr : dn : uni/ctxrefcont/ctxref-[sys/ctx-[vxlan-2457603]]/epgref-[uni/tn-jy/ap-ap1/epg-epg1]/epgpol-[sys/rpm/rtmap-2457603-shared-svc-leak/ent-1001]/epgcons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ap-ap1/epg-epg1]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]] lcOwn : local modTs : 2019-12-23T14:36:48.753-05:00 name : nameAlias : ownerKey : ownerTag : rn : epgcons-[cdef-[uni/tn-jy/brc-shared]/epgCont-[uni/tn-jy/ap-ap1/epg-epg1]/fr-[uni/tn-jy/brc-shared/dirass/prov-[uni/tn-jy/ap-ap1/epg-epg1]-any-no]/to-[uni/tn-jy/brc-shared/dirass/cons-[uni/tn-jy/out-jy-ospf/instP-all]-any-no]] status :
يوضح الإخراج الوارد أعلاه أن اسم العقد "مشترك"، ومزود epg هو "tn-jy/ap-ap1/epg-epg1" ومستهلك l3out هو "tn-jy/out-jy-ospf/instP-all"
ملخص
المسار المسرب من الشبكة الفرعية BD / EPG
إذا كان المسار المسرب تم تعيين العلامة "المنتشرة" في "show ip route"، فإنه يتم تسريبه من شبكة BD/EPG فرعية تم تكوينها. يمكن إستخدام الأمرين التاليين للتحقق من علاقة العقد التي تؤدي إلى تسريب هذا الأمر. يتم تشغيلها على الورقة حيث يتم تثبيت المسار بشكل غير متوقع.
إذا كان عامل VRF الذي تم فيه تسريب المسار بشكل غير متوقع هو المستهلك:
moquery -c ipCons -f 'ip.cons.dn*"jy:vrf1/rt-\[10.100.100.0/24\]"' <—jy:vrf1 هو اسم مسار vrf الذي تم تسريبه إلى، المسار هو 10.100.100.0/24
إذا كان VRF الذي يتم فيه تسريب المسار بشكل غير متوقع هو الموفر:
moquery -c consNode -f 'cons.node.dn*"2949122"' -f 'cons.node.dn*"tn-jy/BD-bd1"' <—2949122 هو معرف منفذ VRF الذي يتم تسريب المسار إليه، tn-jy/BD-1 هو اسم BD حيث يتم تكوين الشبكة الفرعية (داخل VRF يتم تسريب المسار من).
تم تسرب المسار من L3out
إذا تم التعرف على المسار المسرب من خلال عملية iBGP الخاصة بالنسيج الداخلي وعرض vsh -c "show ip route x.x.x.x/y detail vrf <name>" يظهر قيمة RW-vnid غير صفرية ثم يتم تعلم المسار من l3out في vrf آخر. يكون التحقق من الصحة هو نفسه بغض النظر عن أي EPG هو المستهلك وأيهم الموفر.
1. تحديد مخطط مسار إستيراد الخدمات المشتركة في عملية VRF الداخلية ل BGP:
show bgp process vrf jy:vrf2 | GREP "إستيراد خريطة الطريق" <—jy:vrf2 هو التردد اللاسلكي الداخلي الذي يتم تسريب المسار إليه
2. تحديد قائمة البادئات الموجودة ضمن خريطة مسار الخدمات المشتركة التي تطابق المسار المسرب:
moquery -c rtpfxEntry -f 'rtpfx.Entry.dn*"pfxlist-IPv4'.*'2457603-shared-svc-leaks"' | egrep "المعايير|dn|pfx|toPfxLen" <—2457603 هو معرف فئة المورد (VRF) الداخلي في هذا المثال
3. بعد العثور على قائمة (قوائم) البادئات التي تشير إلى المسار، قم بتحديد رقم تسلسل خريطة المسار الذي يشير إلى القائمة (القوائم):
moquery -c rtmapRsRtDstAtt -f 'rtmap.RsRtDstAtt.tDn*"pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leaks"' <— pfxlist-IPv4-2949122-24-25-2457603-shared-svc-leaks هو اسم قائمة البادئات
4. باستخدام خريطة الطريق ورقم الإدخال، قم بتشغيل الأمر التالي لمعرفة علاقة العقد التي دفعت إدخال خريطة المسار هذا:
moquery -c fvAppEpGCons -f 'fv.AppEpGCons.dn*"rtmap-2457603-shared-svc-leaks/ent-1001"' <— RTMAP-2457603-shared-svc-leaks/ent-1001 هو اسم خريطة المسار ورقم الإدخال من الخطوة 3.
التعليقات