أستكشاف أخطاء إدارة قائمة التحكم في الوصول (ACI) والخدمات الأساسية وإصلاحها - سياسات Pod
المحتويات
المقدمة
يصف هذا المستند الخطوات اللازمة لفهم سياسات ACI Pod واستكشاف أخطائها وإصلاحها.
معلومات أساسية
استخرجت المادة من هذا المستند من أستكشاف أخطاء البنية الأساسية المرتكزة على التطبيقات من Cisco وإصلاحها، الإصدار الثاني ، وتحديدا الخدمات الإدارية والأساسية - سياسات POD - BGP RR/ التاريخ والوقت / SNMP الفصل.
نظرة عامة على سياسات POD
يتم تطبيق خدمات الإدارة مثل BGP RR و Date & Time و SNMP على النظام باستخدام مجموعة نهج PoD. وينظم فريق للسياسات المتعلقة بود مجموعة من السياسات المتعلقة بود فيما يتصل بالمهام الأساسية لنسيج من الهياكل القائمة على التطبيقات. تتعلق سياسات POD هذه بالمكونات التالية، والتي يتم توفير الكثير منها في بنية قائمة التحكم في الوصول (ACI) بشكل افتراضي.
سياسات POD
| نهج POD |
تتطلب التكوين اليدوي |
| التاريخ والوقت |
نعم |
| عاكس مسار BGP |
نعم |
| SNMP (بروتوكول إدارة شبكة الخادم) |
نعم |
| إيزيس |
لا |
| كوب |
لا |
| الوصول إلى الإدارة |
لا |
| ماك سيك |
نعم |
حتى في بنية واحدة خاصة بالبنية الأساسية المرتكزة على التطبيقات (ACI)، يلزم تكوين "مجموعة سياسات Pod" و"ملف تعريف Pod". ولا يقتصر ذلك على نشر متعدد الأجهزة أو حتى النشر متعدد المواقع. ينطبق المتطلب على جميع أنواع نشر ACI.
يركز هذا الفصل على سياسات Pod الأساسية وكيفية التحقق من تطبيقها بشكل صحيح.
نهج التاريخ والوقت
تؤدي مزامنة الوقت دورا بالغ الأهمية في بنية قائمة التحكم في الوصول (ACI). من التحقق من صحة الشهادات، إلى الحفاظ على اتساق الطوابع الزمنية للسجل في APICs والمحولات، من أفضل الممارسات مزامنة العقد في بنية ACI إلى مصدر وقت واحد أو أكثر يمكن الاعتماد عليه باستخدام NTP.
لجعل العقد متزامنة بشكل صحيح مع موفر خادم NTP، هناك تبعية لتعيين عقد ذات عناوين إدارة. يمكن القيام بذلك تحت مستأجر الإدارة باستخدام عناوين إدارة العقدة الثابتة أو مجموعات اتصال عقدة الإدارة.
أستكشاف أخطاء سير العمل وإصلاحها
1. التحقق من تعيين عناوين إدارة العقد لجميع العقد
مستأجر الإدارة - عناوين إدارة العقد
2. التحقق من تكوين خادم NTP كموفر NTP
إذا كان هناك العديد من موفري بروتوكول وقت الشبكة (NTP)، فقم بوضع علامة على واحد منهم على الأقل كمصدر الوقت المفضل باستخدام خانة الاختيار "المفضل" وفقا للرقم أدناه.
موفر/خادم NTP ضمن نهج POD للتاريخ والوقت
3. التحقق من تنسيق التاريخ والوقت ضمن إعدادات النظام
يوضح الشكل التالي مثالا تم من خلاله تعيين تنسيق التاريخ والوقت على UTC.
إعداد التاريخ والوقت ضمن إعدادات النظام
4. التحقق من حالة المزامنة التشغيلية لموفر NTP لجميع العقد
كما هو موضح في الشكل أدناه، يجب أن يظهر عمود حالة المزامنة 'مزامنة إلى خادم NTP البعيد'. كن على علم بأن الأمر قد يستغرق عدة دقائق حتى يتم تجميع حالة المزامنة بشكل صحيح إلى .المزامنة إلى خادم NTP البعيد. الحالة.
حالة مزامنة موفر/خادم NTP
بدلا من ذلك، يمكن إستخدام طرق واجهة سطر الأوامر (CLI) على بطاقات واجهة برمجة التطبيقات (APICs) والمحولات للتحقق من مزامنة الوقت الصحيحة مقابل خادم NTP.
APIC - NX-OS CLI
يظهر العمود 'refId' أدناه مصدر خوادم NTP في المرة التالية وفقا للطبقة.
apic1# show ntpq
nodeid remote refid st t when poll reach auth delay offset jitter
------ - ------------------------------ -------------------------- -------- -- -------- -------- -------- ---- -------- -------- --------
1 * 10.48.37.151 192.168.1.115 2 u 25 64 377 none 0.214 -0.118 0.025
2 * 10.48.37.151 192.168.1.115 2 u 62 64 377 none 0.207 -0.085 0.043
3 * 10.48.37.151 192.168.1.115 2 u 43 64 377 none 0.109 -0.072 0.030
apic1# show clock
Time : 17:38:05.814 UTC Wed Oct 02 2019
APIC - Bash
apic1# bash
admin@apic1:~> date
Wed Oct 2 17:38:45 UTC 2019
تبديل
أستخدم الأمر 'show ntp peers' للتأكد من دفع تكوين موفر NTP بشكل صحيح إلى المحول.
leaf1# show ntp peers
-----------------------------------------------------------------------------
Peer IP Address Serv/Peer Prefer KeyId Vrf
-----------------------------------------------------------------------------
10.48.37.151 Server yes None management
leaf1# show ntp peer-status
Total peers : 1
* - selected for sync, + - peer mode(active),
- - peer mode(passive), = - polled in client mode
remote local st poll reach delay vrf
--------------------------------------------------------------------------------
*10.48.37.151 0.0.0.0 2 64 377 0.000 management
الحرف '*' ضروري هنا حيث إنه يحكم ما إذا كان خادم NTP قيد الاستخدام بالفعل للمزامنة.
تحقق من عدد الحزم التي تم إرسالها/استقبالها في الأمر التالي للتأكد من إمكانية الوصول إلى عقد قائمة التحكم في الوصول (ACI) إلى خادم NTP.
leaf1# show ntp statistics peer ipaddr 10.48.37.151
...
packets sent: 256
packets received: 256
...
سياسة عاكس مسار BGP
تستخدم بنية قائمة التحكم في الوصول (ACI) بروتوكول BGP متعدد البروتوكولات (MP-BGP)، وبشكل أكثر تحديدا، بروتوكول iBGP VPNv4 بين العقد الطرفية والعمود الفقري لتبادل مسارات المستأجرين المستلمة من الموجهات الخارجية (المتصلة بموجهات L3Out). لتجنب مخطط نظير iBGP كامل الشبكة العنكبوتية، تعكس عقد العمود الفقري بادئات VPNv4 التي يتم استقبالها من ورقة إلى عقد طرفية أخرى في البنية.
بدون سياسة عاكس مسار BGP (BGP RR)، لن يتم إنشاء مثيل BGP على المحولات ولن يتم إنشاء جلسات عمل BGP VPNv4. في النشر متعدد البروتوكولات، يتطلب كل Pod عمودا رئيسيا واحدا على الأقل تم تكوينه على هيئة BGP RR وأكثر من عمود أساسي للتكرار.
ونتيجة لذلك، تعد سياسة إسترداد بيانات بروتوكول BGP جزءا أساسيا من التكوين في كل بنية قائمة على التحكم في الوصول (ACI). كما تحتوي سياسة BGP RR أيضا على ASN الخاص ببنية قائمة التحكم في الوصول (ACI) المستخدمة لعملية BGP على كل محول.
أستكشاف أخطاء سير العمل وإصلاحها
1. التحقق مما إذا كانت سياسة BGP RR تحتوي على ASN وعمود أساسي واحد على الأقل تم تكوينه
يشير المثال التالي إلى نشر Pod واحد.
سياسة عاكس مسار BGP ضمن إعدادات النظام
2. التحقق من تطبيق سياسة BGP RR ضمن مجموعة نهج Pod
تطبيق نهج BGP RR افتراضي ضمن مجموعة نهج Pod. حتى إذا كان الإدخال فارغا، فسيتم تطبيق نهج BGP RR الافتراضي كجزء من مجموعة نهج Pod.
سياسة عاكس مسار BGP المطبقة ضمن مجموعة سياسة Pod
3. التحقق من تطبيق مجموعة نهج POD ضمن ملف تعريف POD
مجموعة نهج POD المطبقة ضمن ملف تعريف POD
4. قم بتسجيل الدخول إلى العمود الرئيسي والتحقق من تشغيل عملية BGP باستخدام جلسات عمل نظير VPN4 المنشأة
spine1# show bgp process vrf overlay-1
BGP Process Information
BGP Process ID : 26660
BGP Protocol Started, reason: : configuration
BGP Protocol Tag : 65001
BGP Protocol State : Running
BGP Memory State : OK
BGP asformat : asplain
Fabric SOO : SOO:65001:33554415
Multisite SOO : SOO:65001:16777199
Pod SOO : SOO:1:1
...
Information for address family VPNv4 Unicast in VRF overlay-1
Table Id : 4
Table state : UP
Table refcount : 9
Peers Active-peers Routes Paths Networks Aggregates
7 6 0 0 0 0
Redistribution
None
Wait for IGP convergence is not configured
Additional Paths Selection route-map interleak_rtmap_golf_rtmap_path_advertise_all
Is a Route-reflector
Nexthop trigger-delay
critical 500 ms
non-critical 5000 ms
Information for address family VPNv6 Unicast in VRF overlay-1
Table Id : 80000004
Table state : UP
Table refcount : 9
Peers Active-peers Routes Paths Networks Aggregates
7 6 0 0 0 0
Redistribution
None
Wait for IGP convergence is not configured
Additional Paths Selection route-map interleak_rtmap_golf_rtmap_path_advertise_all
Is a Route-reflector
Nexthop trigger-delay
critical 500 ms
non-critical 5000 ms
...
Wait for IGP convergence is not configured
Is a Route-reflector
Nexthop trigger-delay
critical 500 ms
non-critical 5000 ms
وكما هو موضح أعلاه، يحمل بروتوكول MP-BGP بين العقد الطرفية والعمود الفقري فقط عائلات عناوين VPNv4 و VPNv6. يتم إستخدام عائلة عناوين IPv4 في MP-BGP فقط على العقد الطرفية.
كما يمكن ملاحظة جلسات عمل BGP VPNv4 و VPNv6 بين العمود الرئيسي وعقد الوحدات الطرفية بسهولة باستخدام الأمر التالي.
spine1# show bgp vpnv4 unicast summary vrf overlay-1
BGP summary information for VRF overlay-1, address family VPNv4 Unicast
BGP router identifier 10.0.136.65, local AS number 65001
BGP table version is 15, VPNv4 Unicast config peers 7, capable peers 6
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.136.64 4 65001 162 156 15 0 0 02:26:00 0
10.0.136.67 4 65001 154 154 15 0 0 02:26:01 0
10.0.136.68 4 65001 152 154 15 0 0 02:26:00 0
10.0.136.69 4 65001 154 154 15 0 0 02:26:01 0
10.0.136.70 4 65001 154 154 15 0 0 02:26:00 0
10.0.136.71 4 65001 154 154 15 0 0 02:26:01 0
spine1# show bgp vpnv6 unicast summary vrf overlay-1
BGP summary information for VRF overlay-1, address family VPNv6 Unicast
BGP router identifier 10.0.136.65, local AS number 65001
BGP table version is 15, VPNv6 Unicast config peers 7, capable peers 6
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.136.64 4 65001 162 156 15 0 0 02:26:11 0
10.0.136.67 4 65001 155 155 15 0 0 02:26:12 0
10.0.136.68 4 65001 153 155 15 0 0 02:26:11 0
10.0.136.69 4 65001 155 155 15 0 0 02:26:12 0
10.0.136.70 4 65001 155 155 15 0 0 02:26:11 0
10.0.136.71 4 65001 155 155 15 0 0 02:26:12 0
لاحظ العمود 'up/down' من الإخراج أعلاه. يجب أن يسرد فترة زمنية تشير إلى وقت إنشاء جلسة BGP. لاحظ أيضا في المثال أن عمود 'PfxRcd' يوضح 0 لكل نظير BGP VPNv4/VPNv6 حيث أن بنية واجهة التحكم في الوصول هذه لا تحتوي على L3Out تم تكوينها حتى الآن ومن ثم لا توجد مسارات/بادئات خارجية هي عمليات تبادل بين عقد الأوراق والعمود الأساسية.
5. قم بتسجيل الدخول إلى إحدى الأوراق والتحقق من تشغيل عملية BGP باستخدام جلسات عمل نظير VPN4 المنشأة
leaf1# show bgp process vrf overlay-1
BGP Process Information
BGP Process ID : 43242
BGP Protocol Started, reason: : configuration
BGP Protocol Tag : 65001
BGP Protocol State : Running
...
leaf1# show bgp vpnv4 unicast summary vrf overlay-1
BGP summary information for VRF overlay-1, address family VPNv4 Unicast
BGP router identifier 10.0.136.64, local AS number 65001
BGP table version is 7, VPNv4 Unicast config peers 2, capable peers 2
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.136.65 4 65001 165 171 7 0 0 02:35:52 0
10.0.136.66 4 65001 167 171 7 0 0 02:35:53 0
تظهر مخرجات الأمر أعلاه كمية من جلسات BGP VPNv4 تساوي عدد عقد العمود الرئيسي الموجودة في بنية واجهة التحكم في الوصول (ACI). وهذا يختلف عن عقد العمود الفقري لأنها تنشئ جلسات لكل ورقة وعقد العمود الفقري لعاكس المسار الأخرى.
SNMP
من المهم توضيح من البداية أي مجموعة فرعية محددة من وظائف SNMP يغطي هذا القسم. وظائف SNMP في بنية قائمة التحكم في الوصول (ACI) إما مرتبطة بوظيفة السير على بروتوكول SNMP أو وظيفة ملائمة بروتوكول SNMP. التمييز المهم هنا هو أن سير SNMP يحكم مدخل حركة مرور SNMP على منفذ UDP 161 بينما تحكم مصيدة SNMP تدفقات حركة مرور SNMP الصادرة باستخدام خادم SNMP Trap الاستماع على منفذ UDP 162.
تتطلب حركة مرور إدارة الدخول على عقد ACI وجود EPGs لإدارة العقد (إما داخل النطاق الترددي أو خارج النطاق الترددي) لتوفير العقود الضرورية للسماح بحركة المرور بالتدفق. مثل هذا يطبق أيضا على مدخل SNMP حركة مرور.
سيغطي هذا القسم تدفقات حركة مرور SNMP عند الدخول (مسارات SNMP) إلى عقد واجهة التحكم في الوصول (ACI) (وحدات APIC والمحولات). لن يغطي تدفقات حركة مرور SNMP الخاصة بالمنفذ (إختبارات SNMP) حيث إن ذلك من شأنه توسيع نطاق هذا القسم في مراقبة السياسات ومراقبة تبعيات السياسة (مثل مراقبة نطاق السياسة وحزم المراقبة، وما إلى ذلك).
لا يغطي هذا القسم أيضا قواعد معلومات الإدارة (MIB) ل SNMP التي يتم دعمها بواسطة واجهة التحكم في الوصول (ACI). تتوفر هذه المعلومات على موقع Cisco CCO على الويب في الارتباط التالي: https://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/mib/list/mib-support.html
أستكشاف أخطاء سير العمل وإصلاحها
1. نهج SNMP Pod — التحقق من تكوين "نهج مجموعة العملاء"
تأكد من تكوين عميل SNMP واحد على الأقل كجزء من "نهج مجموعة العملاء" حسب لقطات الشاشة أدناه.
سياسات POD — سياسة SNMP — سياسات مجموعة العملاء
سياسات POD — سياسة SNMP — سياسات مجموعة العملاء
2. سياسة SNMP Pod — التحقق من تكوين سياسة مجتمعية واحدة على الأقل
سياسات POD - سياسة SNMP - سياسات المجتمع
3. نهج SNMP Pod — التحقق من تعيين حالة الإدارة على "تمكين"
4. مستأجر الإدارة — تحقق مما إذا كان EPG OOB يوفر عقد OOB يسمح بمنفذ UDP 161
يحكم ال OOB EPG الموصولية في ال APIC والمحولات OOB إدارة ميناء. على هذا النحو، فإنه يؤثر على جميع تدفقات حركة المرور التي تدخل المنافذ خارج النطاق (OOB).
تأكد من أن العقد المقدم هنا يتضمن جميع خدمات الإدارة الضرورية بدلا من بروتوكول SNMP فقط. على سبيل المثال: يحتاج أيضا إلى تضمين SSH على الأقل (منفذ TCP 22). ومن دون هذا، لا يمكن تسجيل الدخول إلى المحولات باستخدام SSH. الرجاء ملاحظة أن هذا لا ينطبق على APICs نظرا لأن لديها آلية للسماح ل SSH و HTTP و HTTPS لمنع المستخدمين من التأمين بشكل كامل.
5. مستأجر الإدارة — تحقق مما إذا كان عقد OOB موجودا ولديه عامل تصفية يسمح بمنفذ UDP 161
مستأجر الإدارة — EPG OOB — تم توفير عقد OOB
في الشكل أدناه، ليس إجباري أن يسمح فقط UDP ميناء 161. العقد الذي يحتوي على عامل تصفية يسمح بمنفذ UDP 161 بأي طريقة صحيح. يمكن أن يكون هذا موضوع عقد مع عامل التصفية الافتراضي من المستأجر العام. في المثال، لأغراض التوضيح، تم تكوين عامل تصفية محدد لمنفذ UDP 161 فقط.
6. مستأجر الإدارة — تحقق مما إذا كان ملف تعريف مثيل شبكة الإدارة الخارجية موجودا مع شبكة فرعية صالحة تستهلك عقد OOB
يمثل ملف تعريف مثيل شبكة الإدارة الخارجية (ExtMgmtNetInstP) المصادر الخارجية التي تم تعريفها بواسطة "الشبكات الفرعية" الموجودة هناك والتي تحتاج إلى إستهلاك الخدمات التي يمكن الوصول إليها عبر EPG OOB. وبالتالي، يستهلك ExtMgmtNetInstP نفس عقد خارج النطاق الذي توفره EPG خارج النطاق. هذا هو العقد الذي يسمح بمنفذ UDP 161. بالإضافة إلى ذلك، يحدد ExtMgmtNetInstP أيضا نطاقات الشبكة الفرعية المسموح بها التي قد تستهلك الخدمات المقدمة بواسطة EPG الخاص ببروتوكول OOB.
مستأجر الإدارة — ExtMgmtNetInstP مع عقد خارج النطاق (OOB) المستهلك والشبكة الفرعية
كما هو موضح في الشكل أعلاه، يلزم تدوين الشبكة الفرعية المستندة إلى توجيه المجال التبادلي دون فئات (CIDR). يوضح الشكل شبكة فرعية /24 معينة. متطلب أن تغطي إدخالات الشبكة الفرعية إدخالات عميل SNMP كما تم تكوينها في نهج SNMP Pod (ارجع إلى نهج Figure Pod — سياسة SNMP — سياسات مجموعة العملاء).
كما تمت الإشارة مسبقا، يرجى توخي الحذر لتضمين جميع الشبكات الفرعية الخارجية المطلوبة لمنع منع منع خدمات الإدارة الضرورية الأخرى من القفل.
7. سجل الدخول إلى محول وقم بإجراء عملية تفريغ لملاحظة ما إذا كانت حزم المشي عبر بروتوكول SNMP - منفذ UDP 161 - يتم ملاحظتها
إذا كانت حزم السير على بروتوكول SNMP تدخل محول من خلال المنفذ OOB، فهذا يعني أنه تم تكوين جميع السياسات/المعلمات الضرورية المستندة إلى بروتوكول SNMP و OOB بشكل صحيح. وبالتالي، فهي طريقة تحقق صحيحة.
تعمل تقنية Tcpdump على العقد الطرفية على زيادة فعالية طبقة Linux وأجهزة شبكة Linux الخاصة بها. وبالتالي، من الضروري التقاط الحزم على الواجهة 'eth0' وفقا للمثال أدناه. في المثال، يقوم عميل SNMP بتنفيذ طلب SNMP Get مقابل OID .1.0.8802.1.1.2.1.1.1.0.
leaf1# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether f4:cf:e2:28:fc:ac brd ff:ff:ff:ff:ff:ff
inet 10.48.22.77/24 brd 10.48.22.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::f6cf:e2ff:fe28:fcac/64 scope link
valid_lft forever preferred_lft forever
leaf1# tcpdump -i eth0 udp port 161
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:18:10.204011 IP 10.155.0.153.63392 > 10.48.22.77.snmp: C=my-snmp-community GetNextRequest(28) .iso.0.8802.1.1.2.1.1.1.0
22:18:10.204558 IP 10.48.22.77.snmp > 10.155.0.153.63392: C=my-snmp-community GetResponse(29) .iso.0.8802.1.1.2.1.1.2.0=4
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
08-Aug-2022 |
الإصدار الأولي |
التعليقات