استكشاف مشكلات DHCP وإصلاحها على وكلاء ترحيل Catalyst 9000 DHCP
المقدمة
يصف هذا المستند كيفية استكشاف حالات فشل تخصيص عناوين DHCP البطيئة أو المتقطعة وإصلاحها على مبدّلات Catalyst 9000 كوكلاء ترحيل DHCP.
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- بروتوكول تكوين الاستضافة الديناميكية (DHCP) ووكلاء ترحيل DHCP
- بروتوكول رسائل التحكم في الإنترنت (ICMP)
- تنظيم مستوى التحكم (CoPP)
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
- المحولات من السلسلة Catalyst 9000
- IOS® XE الإصدارات 16.x و 17.x من Cisco
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
المنتجات ذات الصلة
هذا وثيقة يستطيع أيضا كنت استعملت مع هذا جهاز وبرمجية صيغة:
- المحولات من السلسلة Catalyst 3650/3850 مع Cisco IOS XE 16.x
معلومات أساسية
يصف هذا وثيقة كيف أن يتحرى بطيء مضيف تشكيل بروتوكول (DHCP) عنوان توزيع أو متقطع DHCP عنوان إخفاق توزيع على مادة حفازة 9000 sery مفتاح ك DHCP ترحيل وكيل.
تعمل ميزة تنظيم مستوى التحكم (CoPP) على تحسين الأمان على جهازك من خلال حماية وحدة المعالجة المركزية (CPU) من هجمات حركة المرور غير الضرورية ومنع الخدمة (DoS). كما يمكنه حماية حركة مرور البيانات والتحكم في حركة مرور البيانات من حالات سقوط حركة المرور التي تتسبب فيها كميات كبيرة من حركة المرور الأخرى ذات الأولوية الأقل.
تتم تجزئة جهازك بشكل نموذجي إلى ثلاثة مستويات تشغيل، لكل منها هدفه الخاص:
- مستوى البيانات، لإعادة توجيه حزم البيانات.
- مستوى التحكم، لتوجيه البيانات بشكل صحيح.
- مستوى الإدارة، لإدارة عناصر الشبكة.
يمكنك إستخدام CoPP لحماية معظم حركة المرور المرتبطة بوحدة المعالجة المركزية وضمان إستقرار التوجيه وإمكانية الوصول وتسليم الحزم. والأهم من ذلك، يمكنك إستخدام برنامج CoPP لحماية وحدة المعالجة المركزية من هجوم رفض الخدمة (DoS).
يستخدم CoPP واجهة سطر الأوامر لجودة الخدمة (MQC) وقوائم انتظار وحدة المعالجة المركزية (CPU) القابلة لإضافة وحدات أخرى لتحقيق هذه الأهداف. يتم تجميع أنواع مختلفة من حركة مرور مستوى التحكم معا استنادا إلى معايير معينة، ويتم تعيينها إلى قائمة انتظار وحدة المعالجة المركزية. يمكنك إدارة قوائم انتظار وحدة المعالجة المركزية (CPU) هذه من خلال تكوين جهات تنظيم مخصصة في الأجهزة. على سبيل المثال، يمكنك تعديل معدل الشرطي لبعض قوائم انتظار وحدة المعالجة المركزية (نوع حركة مرور البيانات)، أو يمكنك تعطيل الشرطي لنوع معين من حركة مرور البيانات.
وعلى الرغم من تكوين الشرطات في الأجهزة، إلا أن CoPP لا يؤثر على أداء وحدة المعالجة المركزية أو أداء مستوى البيانات. ونظرا لأنه يحدد عدد الحزم الموجهة إلى وحدة المعالجة المركزية (CPU)، يتم التحكم في حمل وحدة المعالجة المركزية. وهذا يعني أن الخدمات التي تنتظر الحزم من الأجهزة يمكن أن ترى معدل أكثر تحكما لحزم الدخول (المعدل قابل للتكوين من قبل المستخدم).
المشكلة
يتم تكوين المحول Catalyst 9000 switch كعميل ترحيل DHCP عند تكوين الأمر ip helper-address على واجهة موجهة أو SVI. تكون الواجهة التي تم تكوين عنوان المساعدة فيها هي البوابة الافتراضية لعملاء تدفق البيانات من الخادم بشكل نموذجي. لكي يوفر المحول خدمات ترحيل DHCP ناجحة لعملائه، يجب أن يعالج رسائل اكتشاف DHCP الواردة. يتطلب هذا المحول أن يستقبل DHCP اكتشاف هذه الحزمة وإرسالها إلى وحدة المعالجة المركزية (CPU) الخاصة بها لمعالجتها. بمجرد إستلام اكتشاف DHCP ومعالجته، يقوم وكيل الترحيل بإنشاء حزمة بث أحادي جديدة تم الحصول عليها من الواجهة التي تم إستلام اكتشاف DHCP فيها وتخصيصها إلى عنوان IP كما هو محدد في تكوين مساعد عنوان IP. بعد إنشاء الحزمة، تتم إعادة توجيه الأجهزة وإرسالها إلى خادم DHCP حيث يمكن معالجتها وإرسالها مرة أخرى إلى وكيل الترحيل حتى يمكن متابعة عملية DHCP للعميل.
المشكلة الشائعة التي يتم إختبارها عندما تتأثر حزم معاملات DHCP في وكيل الترحيل بشكل غير مقصود بحركة المرور التي يتم إرسالها إلى وحدة المعالجة المركزية لأنها تخضع لسيناريو ICMP محدد، مثل إعادة توجيه ICMP أو رسالة وجهة ICMP التي يتعذر الوصول إليها. يمكن أن يظهر هذا السلوك نفسه حيث لا يمكن للعملاء تلقي عنوان IP من DHCP في الوقت المناسب، أو حتى فشل تعيين DHCP الإجمالي. وفي بعض السيناريوهات، يمكن ملاحظة هذا السلوك فقط في أوقات معينة من اليوم، مثل ساعات العمل القصوى عندما يتم زيادة العبء على الشبكة بشكل كامل.
كما هو مذكور في قسم الخلفية، تأتي محولات Catalyst 9000 series مع سياسة CoPP افتراضية تم تكوينها وتمكينها على الجهاز. تعمل سياسة CoPP هذه كسياسة جودة الخدمة (QoS) التي تقع في مسار حركة المرور التي يتم استقبالها على منافذ اللوحة الأمامية ويتم توجيهها إلى وحدة المعالجة المركزية (CPU) الخاصة بالجهاز. وهو معدل يحد من حركة المرور استنادا إلى نوع حركة المرور والعتبات المحددة مسبقا التي يتم تكوينها في السياسة. بعض الأمثلة على حركة المرور التي يتم تصنيفها وحدود المعدل بشكل افتراضي هي حزم التحكم في التوجيه (التي يتم تعليمها عادة باستخدام DSCP CS6)، وحزم التحكم في المخطط (STP BPDUs)، وحزم زمن الوصول المنخفض (BFD). يجب تحديد أولوية هذه الحزم لأن القدرة على معالجتها ينتج عنها بشكل موثوق في بيئة شبكة مستقرة.
قم بعرض إحصائيات منظم CoPP باستخدام أمر واضع سياسات وحدة المعالجة المركزية الداخلية show platform hardware fed للمحول النشط QoS queue.
تشترك قائمة انتظار إعادة توجيه ICMP (قائمة الانتظار 6) وقائمة انتظار البث (قائمة الانتظار 12) في نفس PlcIdx الخاصة ب 0 (فهرس واضع السياسات). وهذا يعني أن أي حركة مرور بث يجب أن تتم معالجتها بواسطة وحدة المعالجة المركزية الخاصة بالجهاز، مثل اكتشاف DHCP، تتم مشاركتها مع حركة مرور البيانات الموجهة أيضا إلى وحدة المعالجة المركزية الخاصة بالجهاز في قائمة انتظار إعادة توجيه ICMP. وقد يؤدي هذا إلى المشكلة المذكورة سابقا حيث تفشل معاملات DHCP لأن قائمة انتظار إعادة توجيه ICMP تقضي على حركة المرور التي يجب خدمتها بواسطة قائمة انتظار البث، والتي ينتج عنها إسقاط حزم البث الشرعية.
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
--------------------------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0 0
1 1 L2 Control Yes 2000 2000 0 0
2 14 Forus traffic Yes 4000 4000 0 0
3 0 ICMP GEN Yes 600 600 0 0
4 2 Routing Control Yes 5400 5400 0 0
5 14 Forus Address resolution Yes 4000 4000 0 0
6 0 ICMP Redirect Yes 600 600 0 0 <-- Policer Index 0
7 16 Inter FED Traffic Yes 2000 2000 0 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0 0
9 19 EWLC Control Yes 13000 13000 0 0
10 16 EWLC Data Yes 2000 2000 0 0
11 13 L2 LVX Data Pack Yes 1000 1000 0 0
12 0 BROADCAST Yes 600 600 0 0 <-- Policer Index 0
13 10 Openflow Yes 200 200 0 0
14 13 Sw forwarding Yes 1000 1000 0 0
15 8 Topology Control Yes 13000 16000 0 0
16 12 Proto Snooping Yes 2000 2000 0 0
17 6 DHCP Snooping Yes 500 500 0 0
18 13 Transit Traffic Yes 1000 1000 0 0
19 10 RPF Failed Yes 250 250 0 0
20 15 MCAST END STATION Yes 2000 2000 0 0
<snip>
يتم إسقاط حركة المرور التي تتجاوز السرعة الافتراضية للحزمة 600 في الثانية في سياسة CoPP قبل أن تصل إلى وحدة المعالجة المركزية:
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
--------------------------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0 0
1 1 L2 Control Yes 2000 2000 0 0
2 14 Forus traffic Yes 4000 4000 0 0
3 0 ICMP GEN Yes 600 600 0 0
4 2 Routing Control Yes 5400 5400 0 0
5 14 Forus Address resolution Yes 4000 4000 0 0
6 0 ICMP Redirect Yes 600 600 3063106173577 3925209161 <-- Dropped packets in queue
7 16 Inter FED Traffic Yes 2000 2000 0 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0 0
9 19 EWLC Control Yes 13000 13000 0 0
10 16 EWLC Data Yes 2000 2000 0 0
11 13 L2 LVX Data Pack Yes 1000 1000 0 0
12 0 BROADCAST Yes 600 600 1082560387 3133323 <-- Dropped packets in queue
13 10 Openflow Yes 200 200 0 0
14 13 Sw forwarding Yes 1000 1000 0 0
15 8 Topology Control Yes 13000 16000 0 0
16 12 Proto Snooping Yes 2000 2000 0 0
17 6 DHCP Snooping Yes 500 500 0 0
18 13 Transit Traffic Yes 1000 1000 0 0
19 10 RPF Failed Yes 250 250 0 0
20 15 MCAST END STATION Yes 2000 2000 0 0
<snip>
السيناريو 1: عمليات إعادة توجيه ICMP
ولنتأمل هنا هذا المخطط للسيناريو الأول:
تسلسل الأحداث هو:
1. يقوم المستخدم في 10.10.10.100 ببدء اتصال Telnet بالجهاز 10.100.100.100، وهو شبكة بعيدة.
2. الوجهة IP في شبكة فرعية مختلفة، لذلك يتم إرسال الحزمة إلى البوابة الافتراضية للمستخدمين، 10.10.10.15.
3. عندما يستقبل المادة حفازة 9300 هذه الحزمة إلى توجيه، هو يلكم الحزمة إلى وحدة المعالجة المركزية الخاصة بها لإنشاء إعادة توجيه ICMP.
يتم إنشاء إعادة توجيه ICMP لأنه من منظور المحول 9300 switch، سيكون من الأكثر فعالية للكمبيوتر المحمول أن يرسل ببساطة هذه الحزمة إلى الموجه على 10.10.10.1 مباشرة، نظرا لأن هذه هي الخطوة التالية لمادة حفازة 9300، وهي في شبكة VLAN نفسها التي يتواجد فيها المستخدم.
المشكلة هي أنه تتم معالجة التدفق بالكامل في وحدة المعالجة المركزية (CPU) نظرا لأنه يلبي معايير إعادة توجيه ICMP. إذا تم إرسال أجهزة أخرى حركة مرور تطابق سيناريو إعادة توجيه ICMP، فسيبدأ المزيد من حركة مرور البيانات في الحصول على وحدة المعالجة المركزية في قائمة الانتظار هذه، مما قد يؤثر على قائمة انتظار البث نظرا لأنها تشارك نفس منظم CoPP.
تصحيح أخطاء ICMP لعرض syslog لإعادة توجيه ICMP:
9300-Switch#debug ip icmp <-- enables ICMP debugs
ICMP packet debugging is on
9300-Switch#show logging | inc ICMP
*Sep 29 12:41:33.217: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:41:33.218: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:41:33.219: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:41:33.219: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:43:08.127: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:09.517: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:10.017: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1 <-- ICMP Redirect to use 10.10.10.1 as Gateway
*Sep 29 12:50:14.293: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:19.053: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:23.797: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:28.537: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:33.284: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
تحذير: نظرا لزيادة السعة بشكل كبير، يوصى بتعطيل تسجيل وحدة التحكم ومراقبة المحطة الطرفية قبل تمكين تصحيح أخطاء ICMP.
يظهر التقاط حزمة مدمج في وحدة المعالجة المركزية (CPU) من Catalyst 9300 نظام TCP الأولي لاتصال Telnet في وحدة المعالجة المركزية بالإضافة إلى إعادة توجيه ICMP التي يتم إنشاؤها.
يتم الحصول على حزمة إعادة توجيه ICMP من واجهة Catalyst 9300 VLAN 10 الموجهة إلى العميل وتتضمن رؤوس الحزم الأصلية حيث يتم إرسال حزمة إعادة توجيه ICMP لها.
الحل
في هذا السيناريو، يمكن منع الحزم التي يتم تثبيتها حتى وحدة المعالجة المركزية، وهو ما يوقف أيضا إنشاء حزمة إعادة توجيه ICMP. لا تستخدم أنظمة التشغيل الحديثة إستخدام رسائل إعادة توجيه ICMP لذلك فإن الموارد المطلوبة لإنشاء هذه الحزم وإرسالها ومعالجتها لا تعد إستخداما فعالا لموارد وحدة المعالجة المركزية على أجهزة الشبكة.
بدلا من ذلك، قم بتوجيه المستخدم إلى إستخدام البوابة الافتراضية 10.10.10.1، ولكن إستخدام هذه التكوينات يمكن أن يكون في موضعه لسبب ما وهو خارج نطاق هذا المستند.
ببساطة قم بتعطيل عمليات إعادة توجيه ICMP باستخدام واجهة سطر الأوامر no ip redirects:
9300-Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
9300-Switch(config)#interface vlan 10
9300-Switch(config-if)#no ip redirects <-- disable IP redirects
9300-Switch(config-if)#end
التحقق من تعطيل عمليات إعادة توجيه ICMP على واجهة:
9300-Switch#show ip interface vlan 10
Vlan10 is up, line protocol is up
Internet address is 10.10.10.15/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.102
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is BLOCK-TELNET
Proxy ARP is disabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are never sent <-- redirects disabled
ICMP unreachables are never sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
<snip>
يمكن العثور على مزيد من المعلومات حول عمليات إعادة توجيه ICMP ووقت إرسالها في هذا الارتباط: متى يتم إرسال عمليات إعادة توجيه ICMP
السيناريو الثاني: وجهات ICMP التي يتعذّر الوصول إليها
ضع في الاعتبار نفس المخطط الذي يقوم فيه المستخدم في 10.10.10.100 ببدء اتصال Telnet ب 10.100.100.100. هذه المرة تم تكوين قائمة وصول واردة على شبكة VLAN 10 SVI التي تمنع إتصالات Telnet.
9300-Switch#show running-config interface vlan 10
Building Configuration..
Current Configuration : 491 bytes
!
interface Vlan10
ip address 10.10.10.15 255.255.255.0
no ip proxy-arp
ip access-group BLOCK-TELNET in <-- inbound ACL
end
9300-Switch#
9300-Switch#show ip access-list BLOCK-TELNET
Extended IP access list BLOCK-TELNET
10 deny tcp any any eq telnet <-- block telnet
20 permit ip any any
9300-Switch#
تسلسل الأحداث هو:
1. يقوم المستخدم في 10.10.10.100 ببدء اتصال Telnet بالجهاز 10.100.100.100.
2. الوجهة IP في شبكة فرعية مختلفة، لذلك يتم إرسال الحزمة إلى البوابة الافتراضية للمستخدمين.
3. عندما يستلم المادة حفازة 9300 هذا ربط، هو قيمت ضد ال ACL قادم ويحظر.
4. نظرا لحظر الحزمة وتمكين IP الذي يتعذر الوصول إليه على الواجهة، يتم توقيع الحزمة على وحدة المعالجة المركزية حتى يمكن للجهاز إنشاء حزمة ICMP لوجهة يتعذر الوصول إليها.
debug ICMP لعرض وجهة ICMP الذي يتعذر الوصول إليه syslog:
9300-Switch#debug ip icmp <-- enables ICMP debugs
ICMP packet debugging is on
9300-Switch#show logging | include ICMP
<snip>
*Sep 29 14:01:29.041: ICMP: dst (10.100.100.100) administratively prohibited unreachable sent to 10.10.10.100 <-- packet blocked and ICMP message sent to client
تحذير: نظرا لزيادة السعة بشكل كبير، يوصى بتعطيل تسجيل وحدة التحكم ومراقبة المحطة الطرفية قبل تمكين تصحيح أخطاء ICMP.
يظهر التقاط حزمة مضمن في وحدة المعالجة المركزية (CPU) من Catalyst 9300 نظام TCP الأولي لاتصال Telnet في وحدة المعالجة المركزية بالإضافة إلى وجهة ICMP التي يتعذر الوصول إليها التي يتم إرسالها.
يتم الحصول على حزمة ICMP الوجهة التي يتعذر الوصول إليها من واجهة Catalyst 9300 VLAN 10 الموجهة إلى العميل وتتضمن رؤوس الحزم الأصلية حيث يتم إرسال حزمة ICMP لها.
الحل
في هذا السيناريو، قم بتعطيل السلوك الذي يتم فيه حظر الحزم المثقبة بواسطة قائمة التحكم في الوصول لإنشاء رسالة وجهة ICMP التي يتعذر الوصول إليها.
يتم تمكين وظائف IP التي يتعذر الوصول إليها بشكل افتراضي على الواجهات الموجهة على محولات Catalyst 9000 Series Switches.
9300-Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
9300-Switch(config)#interface vlan 10
9300-Switch(config-if)#no ip unreachables <-- disable IP unreachables
دققت هم معأق للقارن:
9300-Switch#show ip interface vlan 10
Vlan10 is up, line protocol is up
Internet address is 10.10.10.15/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.102
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is BLOCK-TELNET
Proxy ARP is disabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are never sent
ICMP unreachables are never sent <-- IP unreachables disabled
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
<snip>
السيناريو 3: تجاوز ICMP TTL
ولنتأمل هنا المخطط السابق المستخدم للسيناريوهين السابقين. هذه المرة، يحاول المستخدم في 10.10.10.100 الوصول إلى مورد في الشبكة التي تم سحبها منذ ذلك الحين. بسبب هذا، ال SVI و VLAN أن يستعمل أن يستضيف هذا شبكة لم يعد يتواجد على المادة حفازة 9300. مهما، المسحاج تخديد بعد يتلقى طريق ساكن إستاتيكي أن يشير إلى المادة حفازة 9300 VLAN 10 قارن بما أن التالي جنجل ل هذا شبكة.
بما أن المادة حفازة 9300 لم يعد يتلقى هذا شبكة يشكل هو لا يبدي ك مباشرة يربط وال 9300 يوجه أي ربط هو لا يتلقى مسار خاص ل إلى ساكن إستاتيكي تقصير ممر أن يشير إلى المسحاج تخديد على 10.10.10.1.
يقدم هذا السلوك حلقة توجيه في الشبكة عندما يحاول المستخدم الاتصال بمورد في مساحة العنوان 192.168.10.0/24. يتم تكرار الحزمة بين 9300 والموجه إلى أن تنتهي صلاحية TTL.
1. يحاول المستخدم الاتصال بمورد على الشبكة 192.168.10/24
2. يتم إستلام الحزمة بواسطة Catalyst 9300 ويتم توجيهها إلى المسار الافتراضي الخاص بها مع الخطوة التالية 10.10.10.1 ويخفض مدة البقاء (TTL) بمقدار 1.
3. يستقبل الموجه هذه الحزمة ويتحقق من جدول التوجيه للعثور على وجود مسار لهذه الشبكة مع الخطوة التالية 10.10.10.15. ويخفض مدة البقاء (TTL) بمقدار 1 ويوجه الحزمة مرة أخرى إلى 9300.
4. تستلم Catalyst 9300 الحزمة ثم تقوم مرة أخرى بتوجيهها مرة أخرى إلى 10.10.10.1 وترتيب مدة البقاء (TTL) بمقدار 1.
تستمر هذه العملية حتى تصل مدة البقاء (TTL) ل IP إلى صفر.
عندما يستلم المادة حفازة الربط مع ip ttl = 1، هو يلكم الربط إلى المعالجة المركزية ويولد ICMP TTL-Exceeded رسالة.
نوع حزمة ICMP هو 11 مع الرمز 0 (TTL انتهت صلاحيته أثناء النقل). يتعذر تعطيل نوع الحزمة هذا عبر أوامر CLI (واجهة سطر الأوامر)
تدخل المشكلة مع حركة مرور DHCP في هذا السيناريو لأن الحزم التي يتم تكليفها تخضع لإعادة توجيه ICMP لأنها تخرج الواجهة نفسها التي تم استقبالها عليها. كما تخضع الحزم المرسلة من المستخدم لإعادة توجيه ICMP. يمكن بسهولة تجويع حركة مرور DHCP من قائمة انتظار البث في هذا السيناريو. عند التطوير، سيكون هذا السيناريو أسوأ بسبب عدد الحزم التي يتم تثبيتها في قائمة انتظار إعادة التوجيه.
هنا يتم عرض عمليات إسقاط CoPP عبر 1000 إختبار اتصال بالشبكة 192.168.10.0/24 مع مهلة 0 ثوان بين كل عملية إختبار اتصال. يتم مسح إحصائيات CoPP على 9300 ويتم إسقاطها عند صفر بايت قبل إرسال إختبارات الاتصال.
9300-Switch#clear platform hardware fed switch active qos statistics internal cpu policer <-- clear CoPP stats
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer | i Redirect|Drop <-- verify 0 drops
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
6 0 ICMP Redirect Yes 600 600 0 0 <-- bytes dropped 0
<snip>
يرسل المستخدم حركة مرور البيانات إلى شبكة بعيدة:
User#ping 192.168.10.10 timeout 0 rep 1000 <-- User sends 1000 pings
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 192.168.10.10, timeout is 0 seconds:
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
....................
Success rate is 0 percent (0/1000)
تظهر تصحيح أخطاء ICMP عمليات إعادة التوجيه وحروف syslog التي تم تجاوز TTL بسبب تكرار التوجيه:
9300-Switch#debug ip icmp
ICMP packet deubgging is on
*Sep 29 16:33:22.676: ICMP: redirect sent to 10.10.10.100 for dest 192.168.10.10, use gw 10.10.10.1 <-- redirect sent
*Sep 29 16:33:22.678: ICMP: time exceeded (time to live) sent to 10.10.10.100 (dest was 192.168.10.10), topology BASE, dscp 0 topoid 0 <-- TTL exceeded observed
*Sep 29 16:33:22.678: ICMP: time exceeded (time to live) sent to 10.10.10.100 (dest was 192.168.10.10), topology BASE, dscp 0 topoid 0
*Sep 29 16:33:22.678: ICMP: time exceeded (time to live) sent to 10.10.10.100 (dest was 192.168.10.10), topology BASE, dscp 0 topoid 0
<snip>
تحذير: نظرا لزيادة السعة بشكل كبير، يوصى بتعطيل تسجيل وحدة التحكم ومراقبة المحطة الطرفية قبل تمكين تصحيح أخطاء ICMP.
يتم ملاحظة عمليات إسقاط CoPP بسبب مقدار حركة المرور التي يتم تثبيتها على وحدة المعالجة المركزية لإعادة التوجيه (هذا فقط لعميل واحد).
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
--------------------------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0 0
1 1 L2 Control Yes 2000 2000 0 0
2 14 Forus traffic Yes 4000 4000 0 0
3 0 ICMP GEN Yes 600 600 0 0
4 2 Routing Control Yes 5400 5400 0 0
5 14 Forus Address resolution Yes 4000 4000 0 0
6 0 ICMP Redirect Yes 600 600 15407990 126295 <-- drops in redirect queue
7 16 Inter FED Traffic Yes 2000 2000 0 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0 0
<snip>
الحل
يكمن الحل في هذا السيناريو في تعطيل عمليات إعادة توجيه ICMP، بنفس الطريقة الموجودة في السيناريو 1. تعد حلقة التوجيه أيضا مشكلة، لكن الكثافة يتم تجميعها لأن الحزم يتم انتقاؤها لإعادة التوجيه أيضا.
كما يتم فرض عقوبات على حزم ICMP TTL-Exceeded عندما يكون TTL هو 1 ولكن تستخدم هذه الحزم فهرس منظم CoPP مختلف ولا تشارك قائمة انتظار مع البث، لذلك لا تتأثر حركة مرور DHCP.
ببساطة قم بتعطيل عمليات إعادة توجيه ICMP باستخدام واجهة سطر الأوامر بدون ip redirects:
9300-Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
9300-Switch(config)#interface vlan 10
9300-Switch(config-if)#no ip redirects <-- disable IP redirects
9300-Switch(config-if)#end
معلومات ذات صلة
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
3.0 |
17-Jun-2026
|
تحديث التدقيق الإملائي والنحوي واللكمات والنص البديل والمسافات. |
2.0 |
20-Oct-2023
|
تقويم |
1.0 |
30-Sep-2021
|
الإصدار الأولي |
التعليقات