التحقق من سلوك مزامنة جدول Nexus 9000 Series ARP و MAC

المقدمة

يصف هذا المستند سلوك مزامنة محدد تم ملاحظته في جداول عناوين ARP و MAC للمحولات من السلسلة Cisco Nexus 9000. 

المتطلبات الأساسية

المتطلبات

للاستفادة بشكل كامل من المناقشات في هذا المستند، يمكن أن يكون لدى القارئ فهم أساسي لعدة مفاهيم وتقنيات رئيسية:

1. قناة المنفذ الظاهري (vPC): الإلمام بإعداد أجهزة الكمبيوتر الافتراضية وتهيئتها وإدارتها التشغيلية، لأنها جزء لا يتجزأ من فهم سيناريوهات الشبكة الموضحة.

2. ميزة عبارة نظير قناة المنفذ الظاهري NX-OS: معرفة كيفية عمل ميزة بوابة النظير داخل إعداد vPC، بما في ذلك دورها في إعادة توجيه حركة المرور وآليات التكرار.

3. نظام تشغيل Cisco Nexus (NX-OS): فهم عملي لنظام تشغيل NX-OS، مع التركيز على واجهة سطر الأوامر والتكوينات النموذجية ذات الصلة بمحولات Nexus 9000 Series Switches.

المكونات المستخدمة

• نماذج المحولات: محولات السلسلة Nexus 3000 و Nexus 9000 (الجيل الأول فقط)، التي تعد أساسية لتوضيح سلوك جدول ARP و MAC المحدد بسبب قيود ASIC الفريدة الخاصة بها.

• قناة المنفذ الظاهري (vPC): تم تكوينها لاختبار سلوكيات المزامنة عبر الأجهزة المرتبطة. 

• ميزة عبارة النظير vPC: تم تنشيطها ضمن مجال vPC للتحقق من تأثيرها على مزامنة ARP و MAC.

• خط اتصال الطبقة 2 غير PC: يستخدم لتوصيل أجهزة نظير Nexus.

• واجهات المحولات الظاهرية (SVIs) غير المرتبطة بالكمبيوتر: تم تكوينها لاستكشاف السلوكيات عند عدم إستخدام عناوين MAC المعرفة من قبل المستخدم، مما يسلط الضوء على المعالجة الافتراضية لمزامنة عناوين ARP و MAC.

• نظام التشغيل: NX-OS، الإصدار 7.0(3)I7(5).

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

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

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

تكون مشاكل مزامنة عنوان ARP و MAC المفصلة في هذا المستند محددة لتكوينات معينة لمحولات Cisco Nexus 9000 Series Switches. وتنشأ هذه القضايا في ظل شرطين رئيسيين:

1. عند تكوين واجهات المحولات الظاهرية (SVIs) دون عناوين MAC المعرفة من قبل المستخدم.

2. عند تنشيط ميزة عبارة النظير عبر قناة المنفذ الظاهري (vPC) داخل إعدادات مجال vPC.

هذا السلوك المحدد مهم لأنه يؤثر على كيفية الحفاظ على إدخالات ARP بالرغم من إدخالات عنوان MAC المطابقة التي من المحتمل أن تتقادم أو يتم إزالتها بشكل صريح من جدول عناوين MAC. قد يؤدي ذلك إلى عدم تناسق إعادة توجيه الحزم وعدم إستقرار الشبكة.

علاوة على ذلك، من المهم ملاحظة أن هذا السلوك يرجع إلى قيود أجهزة ASIC الموجودة فقط في محولات الجيل الأول من سلسلة Nexus 9000. لا يمتد هذا القيد إلى طرازات مقياس سحابة Nexus 9300 (إصدارات EX و FX و GX و C) التي تم تقديمها لاحقا. تم التعرف على المشكلة وفهرتها تحت تصحيح الأخطاء من Cisco IDCSCuh94866.

المخطط

نظرة عامة

ضع في الاعتبار سيناريو الشبكة التي يتم فيها تكوين شبكة VLAN 150 كشبكة VLAN غير خاصة بالكمبيوتر، كما أن كلا من جدولي عنوان ARP و MAC فارغة في البداية بين المضيف-A و Nexus 9000 المحول B (N9K-B)، ويتم بدء إختبار الاتصال من المضيف-A إلى N9K-B.

Host-A# ping 192.0.2.3
PING 192.0.2.3 (192.0.2.3): 56 data bytes
36 bytes from 192.0.2.100: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.0.2.3: icmp_seq=1 ttl=254 time=1.011 ms
64 bytes from 192.0.2.3: icmp_seq=2 ttl=254 time=0.763 ms
64 bytes from 192.0.2.3: icmp_seq=3 ttl=254 time=0.698 ms
64 bytes from 192.0.2.3: icmp_seq=4 ttl=254 time=0.711 ms

--- 192.0.2.3 ping statistics ---
5 packets transmitted, 4 packets received, 20.00% packet loss
round-trip min/avg/max = 0.698/0.795/1.011 ms

يطالب إختبار الاتصال هذا المضيف-A لإرسال طلب ARP مستهدف في N9K-B. يتم بث هذا الطلب من قناة المنفذ 21 (Po21) على المحول Nexus 9000 Switch A (N9K-A)، المسؤول عن فيضان شبكة VLAN. وفي الوقت نفسه، يتم أيضا إنشاء قنوات الطلب عبر خدمات البنية (CFS) من Cisco عبر قناة المنفذ 20 (Po20). وكنتيجة مباشرة، يتم تحديث جدول عناوين MAC على N9K-B لتضمين الإدخال الصحيح ل Host-A، كما يتم إنشاء إدخال ARP في جدول ARP الخاص ب N9K-B، بالإشارة إلى Po21- شنطة الطبقة 2 غير الخاصة بالكمبيوتر - كواجهة لعنوان MAC الخاص بالمضيف A (0223.e957.6a3a).

N9K-B# show ip arp 192.0.2.100

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry
       D - Static Adjacencies attached to down interface

IP ARP Table
Total number of entries: 1
Address         Age       MAC Address     Interface       Flags
192.0.2.100   00:01:07  0223.e957.6a3a  Vlan150         

N9K-B# show mac address-table address  | i i 6a3a
*  150     0223.e957.6a3a   dynamic  0         F      F    Po21

N9K-B# show ip arp detail | i 3a
192.0.2.100   00:03:22  0223.e957.6a3a  Vlan150          port-channel21   <<<< Expected port-channel

يمكن رؤية المشكلة عند إزالة عنوان MAC الخاص بالمضيف-A من جدول عناوين MAC الخاص ب N9K-B. يمكن أن تحدث هذه الإزالة لمجموعة متنوعة من الأسباب، بما في ذلك عملية التقادم الطبيعية لعنوان MAC، واستلام بروتوكول الشجرة المتفرعة (STP)، وإعلامات تغيير المخطط (TCNs)، أو التدخلات اليدوية مثل تنفيذ الأمر الديناميكي لجدول عناوين CLEAR.

N9K-B# show ip arp 192.0.2.100

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry
       D - Static Adjacencies attached to down interface

IP ARP Table
Total number of entries: 1
Address         Age       MAC Address     Interface       Flags
192.0.2.100   00:00:29     0223.e957.6a3a  Vlan150             <<< ARP remains populated

N9K-B# show mac address-table address 0223.e957.6a3a
Legend: 
        * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
        age - seconds since last seen,+ - primary entry using vPC Peer-Link,
        (T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
   VLAN     MAC Address      Type      age     Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------

    
     
    
N9K-B# ping 192.0.2.100
PING 192.0.2.100 (192.0.2.100): 56 data bytes
64 bytes from 192.0.2.100: icmp_seq=0 ttl=253 time=1.112 ms
64 bytes from 192.0.2.100: icmp_seq=1 ttl=253 time=0.647 ms
64 bytes from 192.0.2.100: icmp_seq=2 ttl=253 time=0.659 ms
64 bytes from 192.0.2.100: icmp_seq=3 ttl=253 time=0.634 ms
64 bytes from 192.0.2.100: icmp_seq=4 ttl=253 time=0.644 ms

--- 192.0.2.100 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.634/0.739/1.112 ms

وعلى الرغم من عمليات الحذف هذه، فمن الجدير بالذكر أن حركة مرور ping لا تزال ناجحة. ومع ذلك، يشير إدخال ARP للمضيف-A على N9K-B بشكل غير متوقع إلى قناة 20 للمنفذ (Po20—ال vPC Peer Link)، بدلا من قناة 21 للمنفذ (Po21)، والذي هو خط الاتصال المعين من الطبقة 2 بخلاف VPC. يقع هذا إعادة توجيه رغم VLAN 150 يكون شكلت ك VLAN غير VPC، أي يؤدي إلى عدم تناسق في متوقع حركة مرور flow.

N9K-B# show ip arp detail | i i 6a3a

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry

IP ARP Table for context default
Total number of entries: 2
Address         Age       MAC Address     Interface        Physical Interface  Flags
192.0.2.100   00:15:54   0223.e957.6a3a    Vlan150          port-channel20   <<< Not Po21 once the issue is triggered.

يمكنك إستخدام أمر show ip arp internal event-history على كل من محولات Nexus 9000 لبيان أن الحزم يتم إنشاء قنوات لها عبر خدمات البنية (CFS) من Cisco:

N9K-B# show ip arp internal event-history event | i i tunnel
    [116] [27772]: Tunnel Packets came with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677
    [116] [27772]: Received tunneled packet on iod: Vlan150, physical iod: port-channel20

N9K-A# show ip arp internal event-history event | i i tunnel
    [116] [28142]: Tunnel Packets sent with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677
    [116] [28142]: Tunnel it to peer destined to remote SVI's Gateway MAC. Peer Gateway Enabled

يمكنك أيضا إستخدام سلسلة debug ip arp من أوامر تصحيح الأخطاء على 9K-B لتفصيل هذا السلوك أيضا:

N9K-B# debug logfile TAC_ARP
N9K-B# debug ip arp packet 
N9K-B# debug ip arp event 
N9K-B# debug ip arp error 

N9K-B# show debug logfile TAC_ARP | beg "15:31:23"
2018 Oct 11 15:31:23.954433 arp: arp_send_request_internal: Our own address 192.0.2.3 on interface Vlan150,sender_pid =27661 
2018 Oct 11 15:31:23.955221 arp: arp_process_receive_packet_msg: Received tunneled packet on iod: Vlan150, physical iod: port-channel20 
2018 Oct 11 15:31:23.955253 arp: arp_process_receive_packet_msg: Tunnel Packets came with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677 
2018 Oct 11 15:31:23.955275 arp: (context 1) Receiving packet from Vlan150, logical interface Vlan150 physical interface port-channel20, (prty 6) Hrd type 1 Prot type 800 Hrd len 6 Prot len 4 OP 2,  Pkt size 46 
2018 Oct 11 15:31:23.955293 arp: Src 0223.e957.6a3a/192.0.2.100 Dst 00be.758e.5677/192.0.2.3 
2018 Oct 11 15:31:23.955443 arp: arp_add_adj: arp_add_adj: Updating MAC on interface Vlan150, phy-interface port-channel20, flags:0x1 
2018 Oct 11 15:31:23.955478 arp: arp_adj_update_state_get_action_on_add: Different MAC(0223.e957.6a3a) Successful action on add Previous State:0x10, Current State:0x10 Received event:Data Plane Add, entry: 192.0.2.100, 0000.0000.0000, Vlan150, action to be taken send_to_am:TRUE, arp_aging:TRUE 
2018 Oct 11 15:31:23.955576 arp: arp_add_adj: Entry added for 192.0.2.100, 0223.e957.6a3a, state 2 on interface Vlan150, physical interface port-channel20, ismct 0. flags:0x10, Rearp (interval: 0, count: 0), TTL: 1500 seconds update_shm:TRUE 
2018 Oct 11 15:31:23.955601 arp: arp_add_adj: Adj info: iod: 77, phy-iod: 91, ip: 192.0.2.100, mac: 0223.e957.6a3a, type: 0, sync: FALSE, suppress-mode: ARP Suppression Disabled flags:0x10

يصل رد ARP من Host-A أولا إلى المحول Nexus 9000 Switch A (N9K-A) ثم يتم إنشاء قنوات له إلى المحول Nexus 9000 Switch B (N9K-B). وعلى وجه الخصوص، تقوم N9K-A بإعادة توجيه رد ARP إلى مستوى التحكم الخاص بها، مما يعمل على زيادة تحسين مجال vPC لعبارة النظير. يمكن هذا التكوين N9K-A من معالجة توجيه الحزمة ل N9K-B، وهي عملية لا يتم توقعها عادة في إعداد شبكة VLAN بخلاف VPC.

N9K-A# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:32:47.378648 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3 <<<< 
2018-10-11 15:32:47.379262 02:23:e9:57:6a:3a -> 00:be:75:8e:56:77 ARP 192.0.2.100 is at 02:23:e9:57:6a:3a

للتحقق من سلوك الرد على ARP، يمكن إستخدام ميزة الإيثاناليزر على NX-OS. تؤكد هذه الأداة أن مستوى التحكم في N9K-B لا يراقب مباشرة الرد على ARP هذا، مبرزة المعالجة المتخصصة لحركة مرور ARP في تكوينات vPC.

N9K-B# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:33:30.053239 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3
2018-10-11 15:34:16.817309 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3
2018-10-11 15:34:42.222965 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.44?  Tell 192.0.2.43
<snip>

تحذير: وفقا لتسلسل الأحداث والظروف، قد تواجه فقدان الحزمة من N9K-B إلى Host-A.

N9K-B# ping 192.0.2.100
PING 192.0.2.100 (192.0.2.100): 56 data bytes
36 bytes from 192.0.2.3: Destination Host Unreachable
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out

--- 192.0.2.100 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss

الخاتمة والحل البديل

يقع السلوك الذي تم ملاحظته، حيث تشير إدخالات ARP بشكل غير صحيح إلى إرتباط نظير vPC بدلا من خط الاتصال غير PC المتوقع، عادة تحت ظروف محددة: عندما لا يتم تكوين عناوين MAC المعرفة من قبل المستخدم على الواجهات الظاهرية لمحول غير vPC (SVIs)، حتى إذا لم يتم إستخدام منافذ SVIs هذه لتوجيه التجاور عبر جهاز كمبيوتر شخصي.

ينطبق هذا السلوك فقط على محولات Nexus 9000 من الجيل الأول.

للحد من هذه المشكلة، من المستحسن تكوين عناوين MAC يدويا ل SVIs المتأثرة. يمكن أن يؤدي تغيير عناوين MAC إلى منع حدوث الإتجاه الخاطئ ل ARP، مما يضمن عمل الشبكة كما هو متوقع دون الاعتماد على إرتباط نظير vPC في سيناريوهات لا تتعلق بأجهزة الكمبيوتر الشخصي. 

نموذج حل بديل أدناه:

N9K-A(config)# interface Vlan150
N9K-A(config-if)# mac-address 0000.aaaa.0030
N9K-A(config-if)# end

N9K-B(config)# interface Vlan150
N9K-B(config-if)# mac-address 0000.bbbb.0030
N9K-B(config-if)# end

ملاحظة: نظرا للحد من الأجهزة، لا يمكنك أن يكون لديك سوى 16 عنوانا من عناوين MAC المعرفة من قبل المستخدم تم تكوينها لكل جهاز في وقت واحد. يتم توثيق هذا ضمن دليل تكوين واجهات NX-OS من السلسلة Cisco Nexus 9000 Series لأن المحول له حد 16 عنوانا MAC معرفة من قبل المستخدم (MEv6/Static). يمكن أن يؤدي التكوين خارج هذا الحد إلى مشاكل موثقة في معرف تصحيح الأخطاء من Cisco CSCux84428

بعد تطبيق الحل البديل، يمكن إستخدام ميزة Ethanalyzer على NX-OS للتحقق من أن Nexus 9000 Switch A (N9K-A) لم يعد يرسل رد ARP إلى مستوى التحكم الخاص به، مما يؤكد المعالجة الصحيحة لاستجابات ARP في الشبكة.

N9K-A# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:36:11.675108 00:00:bb:bb:00:30 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3

معلومات ذات صلة

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