أستكشاف أخطاء الموجه وإصلاحها على شبكة المؤسسة
المحتويات
المقدمة
يوضح هذا المستند كيفية تحديد مشاكل زمن الوصول في شبكات المؤسسات التي تستخدم موجهات Cisco واستكشاف أخطائها وإصلاحها وحلها.
المتطلبات الأساسية
المتطلبات
لا توجد متطلبات أساسية أو متطلبات خاصة لهذا المستند.
المكونات المستخدمة
لا يقتصر هذا المستند على إصدار برنامج معين ونوع الجهاز، ولكن الأوامر تنطبق على موجهات Cisco IOS® XE مثل عائلات ASR 1000 و ISR 4000 و Catalyst 8000.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
يصف هذا وثيقة دليل أساسي أن يفهم، يعزل ويستكشف مشاكل زمن الوصول العام، يعطي أمر/تصحيح أخطاء مفيد أن يكتشف الأسباب الجذرية وأفضل الممارسات. ضع في اعتبارك أنه لا يمكن أخذ جميع المتغيرات والسيناريوهات المحتملة في الاعتبار، وأن التحليل الأكثر عمقا يعتمد على حالات محددة.
تعريف زمن الانتقال
بشكل عام، ونقلا عن التعريف المقيد لأجهزة التخزين وإعادة التوجيه (على RFC 1242)، يمثل زمن الوصول الفترة الزمنية التي تبدأ عندما تصل آخر وحدة بت من إطار الإدخال إلى منفذ الإدخال وتنتهي عند رؤية وحدة بت الأولى من إطار الإخراج على منفذ الإخراج.
يمكن أن يشير زمن وصول الشبكة ببساطة إلى التأخير في نقل البيانات عبر الشبكة. بالنسبة للقضايا العملية، هذا التعريف هو مجرد نقطة البداية، تحتاج إلى تعريف مشكلة زمن الوصول التي تتحدث عنها في كل حالة محددة، على الرغم من أنها تبدو واضحة، الخطوة الأولى اللازمة لحل مشكلة، وتصبح مهمة حقا، هي تعريفها.
إستخدام زمن الوصول
تتطلب العديد من التطبيقات زمن وصول أقل للاتصال في الوقت الفعلي وعمليات الشركة؛ ومع إدخال تحسينات على الأجهزة والبرامج كل يوم، يتوفر المزيد من التطبيقات لعمليات الحوسبة الحيوية للمهام وتطبيقات الاجتماعات عبر الإنترنت والدفق بين تطبيقات أخرى؛ وبنفس الطريقة، تستمر حركة مرور البيانات عبر الشبكة في النمو، كما تتزايد الحاجة إلى تصميمات محسنة للشبكة وأداء أفضل للأجهزة أيضا.
إلى جانب توفير تجربة مستخدم أفضل وتوفير الحد الأدنى المطلوب للتطبيقات التي يمثل زمن الوصول فيها أمرا حيويا، يمكن أن يساعد تحديد مشاكل زمن الوصول على الشبكة وتقليلها بشكل فعال على توفير الكثير من الوقت والموارد التي تمثل قيمة عالية على الشبكة.
معالجة مشاكل زمن الانتقال
الجزء الأصعب من هذا النوع من القضايا هو عدد المتغيرات التي يجب عليك أخذها بعين الإعتبار زائد لا يمكن أن يكون هناك نقطة فشل واحدة. وبالتالي تعريف زمن الوصول يصبح مفتاحا مهما لحله، وبعض الجوانب التي يجب أخذها بعين الإعتبار للحصول على وصف مفيد للمشكلة هي الجوانب التالية.
1 - التوقع والكشف
ومن المهم التمييز بين زمن الانتقال المطلوب، وزمن الوصول المتوقع أو زمن الوصول الأساسي للعمل، والتأخر الحالي. بناء على التصميم أو الموفرين أو الأجهزة الموجودة على الشبكة، قد لا تتمكن في بعض الأحيان من تحقيق زمن الوصول المطلوب، إنه إجراء جيد لقياس زمن الوصول الحقيقي في الظروف العادية ولكن يجب أن تكون متسقا على طرق القياس لتجنب الأرقام المضللة، كما يمكن أن تساعد إتفاقيات مستوى الخدمة (SLA) الخاصة ب IP وأدوات محلل الشبكة في هذا الصدد.
يعد بروتوكول ICMP أو إختبار الاتصال أحد الأدوات الأساسية الأكثر إستخداما لتحديد زمن الوصول بواسطة التطبيقات أو حتى بروتوكول IP SLA:
Router#ping 198.51.100.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 198.51.100.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 2/109/541 ms
بالإضافة إلى التحقق من إمكانية الوصول، يخبر إختبار الاتصال وقت جولة الذهاب (RTT) من المصدر إلى الوجهة؛ الحد الأدنى (2) والمتوسط (109) والحد الأقصى (541) بالمللي ثانية. وهذا يعني، المدة التي يبدأ عندها الموجه بإرسال الطلب إلى عندما يستلم الرد من وجهة الجهاز. ومع ذلك، فهي لا تظهر عدد الخطوات أو المعلومات الأعمق ولكنها طريقة سهلة وسريعة لاكتشاف المشكلة.
2. العزل
مثل ping، traceroute يستطيع كنت استعملت كنقطة بداية للعزل، هو يكتشف شنطة و RTT لكل خطوة:
Router#traceroute 198.51.100.1 Type escape sequence to abort. Tracing the route to 198.51.100.1 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.3.1 5 msec 6 msec 1 msec 2 10.0.1.1 1 msec 1 msec 1 msec 3 10.60.60.1 1 msec 1 msec 1 msec 4 10.90.0.2 362 msec 362 msec 362 msec <<<< you can see the RTT of the three probes only on both hops 5 10.90.1.2 363 msec 363 msec 183 msec 6 10.90.7.7 3 msec 2 msec 2 msec
يعمل Traceroute عن طريق إرسال حزمة ذات مدة البقاء (TTL) من 1. تقوم الخطوة الأولى بإرسال رسالة خطأ ICMP تشير إلى أنه لا يمكن إعادة توجيه الحزمة لأن TTL انتهت صلاحيته و RTT تم قياسه، ثم تقوم الحزمة الثانية باستعادة TTL من 2، وتعيد الخطوة الثانية انتهاء صلاحية TTL. تستمر هذه العملية حتى يتم الوصول إلى الوجهة.
على سبيل المثال، يمكنك الآن تضييق الخناق إلى مضيفين محددين ويمكنك البدء من هناك في عزلتنا.
على الرغم من أن هذه الأوامر مفيدة ويمكنها التعرف على مشكلة بسهولة، إلا أنها لا تأخذ في الاعتبار متغيرات أخرى مثل البروتوكولات وعلامات الحزم والأحجام (على الرغم من أنه يمكنك تعيينها كخطوة ثانية)، ومصادر IP المختلفة، والوجهات بين عوامل متعددة.
يمكن أن يكون قول زمن الوصول مفهوما واسعا جدا وغالبا ما ترى فقط العرض الموجود على التطبيق أو الاستعراض أو الاتصال أو مهام معينة. أحد أول الأشياء التي يجب الحد منها هي فهم التأثير وتعريف المشكلة بمزيد من التفصيل، والإجابة على الأسئلة والعناصر التالية يمكن أن تساعد في هذا البعد:
- هل يؤثر زمن الوصول على نوع معين فقط من حركة المرور أو التطبيق؟ مثال: فقط UDP و TCP و ICMP...
- إذا كان الأمر كذلك، هل تحتوي حركة المرور هذه على معرفات فريدة؟ مثال: تمييز جودة خدمة محدد، أحجام حزم محددة فقط، خيارات IP...
- كم عدد المستخدمين أو المواقع التي تأثرت؟ على سبيل المثال: شبكة فرعية واحدة محددة أو جهازان مضيفان نهائيان أو موقع كامل متصل بجهاز واحد أو عدة أجهزة...
- هل هناك طوابع زمنية محددة محددة؟ على سبيل المثال: هل يحدث هذا أثناء ساعات الذروة فقط، أو في أي نمط زمني أو في حالة عشوائية كاملة...
- جوانب التصميم. على سبيل المثال: حركة المرور التي تمر عبر جهاز معين، ربما العديد من الأجهزة ولكن مع الاتصال بمزود واحد فقط، حركة المرور التي تقوم بتوازن التحميل ولكنها تؤثر على مسار واحد...
هناك العديد من الاعتبارات الأخرى، ولكن تجاوز الإجابات المختلفة (وحتى الاختبارات التي يمكن القيام بها للإجابة عليها) يمكن أن يعزل ويحد بشكل فعال من المجال للمضي في عملية أستكشاف الأخطاء وإصلاحها. وعلى سبيل المثال، لم يؤثر إلا تطبيق واحد (حركة مرور من النوع نفسه) على جميع الفروع التي تمر عبر مقدمي خدمات مختلفين وتنتهي في نفس مركز البيانات في ساعات الذروة. في هذه الحالة، لا تبدأ التحقق من جميع محولات الوصول في جميع الفروع، وبدلا من ذلك، تركز على جمع المزيد من المعلومات حول مركز البيانات وتفحص المزيد على ذلك الجانب،
إن أدوات المراقبة وبعض الأتمتة التي يمكنك الحصول عليها على الشبكة تساعد كثيرا على هذه العزلة أيضا، حقيقة تعتمد على الموارد المتاحة لديك والظروف الفريدة.
أستكشاف الأسباب الشائعة وإصلاحها
ما إن يحد أنت مجال من يتحرى، أنت يستطيع بدأت يفحص سبب خاص، مثلا، على ال traceroute مثال يزود، أنت يستطيع عزلت إلى إثنان خطوة مختلف وبعد ذلك، تضييق إلى سبب ممكن.
ذو صلة بالنظام الأساسي
وحدة المعالجة المركزية (CPU) المرتفعة
يمكن أن يكون أحد الأسباب الشائعة جهاز به وحدة معالجة مركزية (CPU) عالية تتسبب في تأخير معالجة جميع الحزم. للموجهات، فإن الأمر الأكثر فائدة والأساسي للتحقق من الموجهات هو
الأداء الإجمالي للموجه:
Router#show platform resources **State Acronym: H - Healthy, W - Warning, C - Critical Resource Usage Max Warning Critical State ---------------------------------------------------------------------------------------------------- RP0 (ok, active) H Control Processor 1.15% 100% 80% 90% H DRAM 3631MB(23%) 15476MB 88% 93% H bootflash 11729MB(46%) 25237MB 88% 93% H harddisk 1121MB(0%) 225279MB 88% 93% H ESP0(ok, active) H QFP H TCAM 8cells(0%) 131072cells 65% 85% H DRAM 359563KB(1%) 20971520KB 85% 95% H IRAM 16597KB(12%) 131072KB 85% 95% H CPU Utilization 0.00% 100% 90% 95% H Crypto Utilization 0.00% 100% 90% 95% H Pkt Buf Mem (0) 1152KB(0%) 164864KB 85% 95% H Pkt Buf CBlk (0) 14544KB(1%) 986112KB 85% 95% H
من المفيد أن ترى إستخدام الذاكرة ووحدة المعالجة المركزية (CPU) في آن واحد، ويتم تقسيمهما على مستوى التحكم ومستوى البيانات (QFP) مثل حدود كل منهما. لا تقوم الذاكرة نفسها بإنشاء مشكلة زمن وصول، ومع ذلك، في حالة عدم وجود المزيد من ذاكرة DRAM لمستوى التحكم، يتم تعطيل إعادة التوجيه السريع من Cisco (CEF) وتحث على إستخدام عال لوحدة المعالجة المركزية (CPU) والذي يمكن أن ينتج زمن وصول، ولهذا السبب من المهم الحفاظ على الأرقام في حالة صحية. خرج الدليل الأساسي لاستكشاف أخطاء الذاكرة وإصلاحها من النطاق ولكنه ارجع إلى إرتباط مفيد في قسم المعلومات ذات الصلة.
إذا تم الكشف عن وحدة معالجة مركزية (CPU) عالية المستوى لمعالج التحكم أو وحدة معالجة مركزية (CPU) خاصة ب QFP أو إستخدام التشفير، يمكنك إستخدام الأوامر التالية:
لمستوى التحكم:
إظهار معالجة وحدة المعالجة المركزية التي تم فرزها
Router#show processes cpu sorted CPU utilization for five seconds: 99%/0%; one minute: 13%; five minutes: 3% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 65 1621 638 2540 89.48% 1.82% 0.41% 0 crypto sw pk pro 9 273 61 4475 1.56% 0.25% 0.05% 0 Check heaps 51 212 64 3312 0.72% 0.21% 0.05% 0 Exec 133 128 16 8000 0.60% 0.08% 0.01% 0 DBAL EVENTS 473 25 12 2083 0.48% 0.04% 0.00% 0 WSMAN Process 84 1173 353 3322 0.36% 0.07% 0.02% 0 IOSD ipc task 87 23 12 1916 0.24% 0.02% 0.00% 0 PuntInject Keepa 78 533 341 1563 0.12% 0.29% 0.07% 0 SAMsgThread 225 25 1275 19 0.12% 0.00% 0.00% 0 SSS Feature Time 386 4 4 1000 0.12% 0.00% 0.00% 0 Crypto WUI 127 204 18810 10 0.12% 0.02% 0.00% 0 L2 LISP Punt Pro
إذا كانت وحدة المعالجة المركزية لمستوى التحكم عالية (هذا المثال هو 99٪ بسبب العمليات)، فيجب عزل العملية، وبناء على ذلك، المتابعة في العزل (يمكن توجيه الحزم لنا مثل ARP أو حزم شبكة التحكم، يمكن أن تكون أي بروتوكول توجيه أو بث متعدد أو NAT أو DNS أو حركة مرور التشفير أو أي خدمة).
يعتمد على تدفق حركة المرور، قد يؤدي ذلك إلى حدوث مشكلة في المعالجة الإضافية، إذا لم تكن حركة المرور موجهة إلى الموجه يمكنك التركيز على مستوى البيانات:
لمستوى البيانات:
عرض إستخدام قاعدة بيانات QFP النشطة للأجهزة الأساسية [ملخص]
Router#show platform hardware qfp active datapath utilization
CPP 0: Subdev 0 5 secs 1 min 5 min 60 min
Input: Priority (pps) 0 0 0 0
(bps) 0 0 0 0
Non-Priority (pps) 231 192 68 6
(bps) 114616 95392 33920 3008
Total (pps) 231 192 68 6
(bps) 114616 95392 33920 3008
Output: Priority (pps) 0 0 0 0
(bps) 0 0 0 0
Non-Priority (pps) 3 2 2 0
(bps) 14896 9048 8968 2368
Total (pps) 3323 2352 892 0
(bps) 14896 9048 8968 2368
Processing: Load (pct) 3 3 3 3
Crypto/IO
Crypto: Load (pct) 0 0 0 0
RX: Load (pct) 0 0 0 0
TX: Load (pct) 1 1 0 0
Idle (pct) 99 99 99 99
إذا كان مستوى البيانات مرتفعا (محدد من خلال معالجة رقم الحمل الذي يصل إلى 100٪)، يلزم رؤية مقدار حركة المرور التي تمر عبر الموجه (إجمالي الحزمة في الثانية ووحدات البت في الثانية) وأداء إخراج النظام الأساسي (يمكنك وضع فكرة على ورقة بيانات محددة).
لتحديد ما إذا كانت حركة المرور هذه متوقعة أو غير متوقعة، يمكن إستخدام التقاط الحزمة (EPC) أو أي ميزة مراقبة مثل NetFlow لمزيد من التحليل، بعض التحققات هي:
- هل حركة المرور صالحة ومن المتوقع تمريرها؟
- حدد تدفقات حركة المرور غير الطبيعية أو المعدلات الأعلى.
- إذا كان لديك حزمة عالية لكل أرقام ثانية، فابحث عن حجم الحزم. حدد ما إذا كان من المتوقع أن يظهر هذا أو إذا كان لديك مشكلة تجزئة.
إذا كانت جميع حركات المرور متوقعة، فيمكنك الوصول إلى تحديد للنظام الأساسي، ثم ابحث عن الميزات التي يتم تشغيلها على الموجه لديك كجزء ثان للتحليل عبر show running-config، غالبا على الواجهات، وقم بتعريف أي ميزات غير ضرورية وتعطيلها أو موازنة حركة المرور لتحرير دورات وحدة المعالجة المركزية.
ومع ذلك، إذا لم يكن هناك أي مؤشر على حد النظام الأساسي، فإن الأداة المفيدة الأخرى لدعم ما إذا كان الموجه يضيف تأخيرا على الحزم هي تتبع FIA، فيمكنك رؤية وقت العملية الذي يتم قضاؤه لكل حزمة والسمات التي تأخذ معظم المعالجة. يقع أستكشاف أخطاء وحدة المعالجة المركزية (CPU) وإصلاحها بشكل كامل خارج نطاق هذا المستند ولكن ارجع إلى إرتباطات في قسم المعلومات ذات الصلة.
حركة المرور ذات الصلة
وحدة الحد الأقصى للنقل (MTU) والتجزئة
Maximum Transmission Unit (MTU) هو الحد الأقصى لطول الحزمة التي يتم إرسالها والتي تعتمد على عدد الأنظمة الثمانية التي يمكن أن تنقلها الارتباطات المادية.عندما تقوم بروتوكولات الطبقة العليا بإرسال البيانات إلى IP الأساسي، والطول الناتج لحزمة IP أكبر من المسار MTU، يتم تقسيم الحزمة إلى أجزاء. تتسبب هذه الأحجام الأقل في الشبكة في المزيد من المعالجة ومعالجة مختلفة لبعض الحالات، ولهذا السبب يجب عليك تجنب ذلك قدر الإمكان.
بالنسبة لبعض الميزات مثل NAT أو جدار الحماية القائم على المنطقة، يلزم إعادة التجميع الظاهري "للحصول على الحزمة بأكملها"، وتطبيق ما هو مطلوب، وإعادة توجيه الأجزاء الخاصة بها، وتجاهل النسخة المعاد تجميعها. تضيف هذه العملية دورات وحدة المعالجة المركزية (CPU) وهي عرضة للأخطاء.
لا تعتمد بعض التطبيقات على التجزئة، وأحد أكثر الاختبارات الأساسية للتحقق من وحدة الحد الأقصى للنقل (MTU) هو إختبار الاتصال باستخدام خيار بدون تجزئة واختبار أحجام حزم مختلفة: رقم حجم ip-address df-bit ping. إذا لم ينجح إختبار الاتصال، فقم بإصلاح MTU عبر المسار عند حدوث الإسقاط ويسبب المزيد من المشاكل.
يمكن أن تؤدي الميزات، مثل التوجيه المستند إلى السياسة والمسار المتعدد ذي التكلفة المتساوية على شبكة ذات حزم مجزأة، إلى مشاكل تأخير والمزيد من الأخطاء معظمها على معدلات البيانات العالية، مما يؤدي إلى تحديد أوقات تجميع عالية ومعرفات متكررة وحزم تالفة، إذا تم تحديد بعض هذه المشاكل، فيرجى البحث عن حل هذه التجزئة قدر الإمكان. هناك أمر واحد للتحقق من وجود أجزاء وأي مشاكل محتملة هو show ip traffic:
Router#show ip traffic
IP statistics:
Rcvd: 9875429 total, 14340254 local destination
0 format errors, 0 checksum errors, 0 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options, 0 with options
Opts: 0 end, 0 nop, 0 basic security, 0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump
0 other, 0 ignored
Frags: 150 reassembled, 0 timeouts, 0 could not reassemble
0 fragmented, 600 fragments, 0 could not fragment
0 invalid hole
Bcast: 31173 received, 6 sent
Mcast: 0 received, 0 sent
Sent: 15742903 generated, 0 forwarded
Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency
0 no route, 0 unicast RPF, 0 forced drop, 0 unsupported-addr
0 options denied, 0 source IP address zero
<output omitted>
من الإخراج أعلاه، يشير قسم الكلمات الجريئة في الإطارات إلى:
- المعاد تجميعها: عدد الحزم المعاد تجميعها.
- حالات انتهاء المهلة: في كل مرة تنتهي فيها مدة إعادة تجميع جزء من الحزمة.
- تعذر إعادة التجميع: عدد الحزم التي تعذر إعادة تجميعها.
- مجزأة: عدد الحزم التي تتجاوز MTU وموضوع التجزئة.
- الأجزاء: عدد الأجزاء التي تمت تجزئة الحزم إليها.
- تعذر التجزئة: عدد الحزم التي تتجاوز MTU ولكن تعذر تجزئتها.
إذا تم إستخدام التجزئة وكانت لديك حالات انتهاء المهلة الزمنية أو تعذر عليك إعادة تجميع العدادات، فإن إحدى طرق تأكيد المشاكل التي تتسبب فيها المنصة، تكون عبر عمليات إسقاط QFP، باستخدام الأمر نفسه كما هو موضح لاحقا في قسم عمليات الإسقاط: إظهار إسقاط الإحصائيات النشطة لأجهزة QFP الخاصة بمنصات العمل. ابحث عن أخطاء مثل TCPbadfrag أو ipFragErr أو FragTailDrop أو ReassDrop أو ReassFragTooBig أو ReassTooManyFrags أو ReassTimeout أو الأخطاء ذات الصلة. يمكن أن يكون لكل حالة أسباب مختلفة مثل عدم الحصول على جميع الأجزاء، والمضاعفات، وازدحام وحدة المعالجة المركزية (CPU) بين حالات أخرى. ومرة أخرى، يمكن للأدوات المفيدة لمزيد من التحليل والإصلاح المحتمل أن تكون تتبع FIA والتحقق من التكوين.
يقدم TCP آلية الحد الأقصى لحجم المقطع (MSS) لحل هذه المشكلة ولكنه يمكن أن يستحث زمن وصول إذا كان غير صحيح أو لم يتم التفاوض مع MSS أو تم اكتشاف MTU للمسار الخاطئ.
بما أن UDP لا يحتوي على آلية التجزئة هذه، يمكنك الاعتماد على التنفيذ اليدوي ل PMTD أو أي حل طبقة تطبيق، يمكنك تمكينهم (عند تطبيقه) لإرسال حزم أقل من 576 بايت وهي وحدة الحد الأقصى للنقل الفعالة الأصغر لإرسال الرقم وفقا ل RFC1122 في المساعدات لتجنب التجزئة.
ذو صلة بالتصميم
أكثر من اقتراح أستكشاف الأخطاء وإصلاحها، يصف هذا القسم بإيجاز مكونين رئيسيين إضافيين يمكن أن يضفا إلى مشاكل زمن الوصول وهما يتطلبان إجراء مناقشة وتحليل مستفيضين خارج نطاق هذا المستند.
التوجيه دون الأمثل
يشير التوجيه دون الأمثل في الشبكة إلى حالة لا يتم فيها توجيه حزم البيانات من خلال المسار الأكثر فعالية أو الأقصر المتاح في الشبكة. وبدلا من ذلك، تسلك هذه الحزم مسارا أقل كفاءة، مما قد يؤدي إلى زيادة زمن الوصول أو الازدحام أو التأثير على أداء الشبكة. تختار بروتوكولات العبارة الداخلية دائما أفضل المسارات، مما يعني تكلفة أقل، ولكنها لا تكون بالضرورة أرخص مسار أو أقل مسار تأخير (يمكن أن يكون الأفضل هو مسار عرض نطاق أكبر).
يمكن أن يحدث التوجيه دون الأمثل للمشاكل المتعلقة ببروتوكولات التوجيه، إما التكوين أو أي حالة مثل ظروف العرق، التغييرات الديناميكية (تغييرات المخطط أو فشل الارتباط)، هندسة حركة المرور المقصودة استنادا إلى سياسات الشركة أو تكلفتها، عمليات التكرار أو تجاوز الفشل (الانتقال إلى مسار النسخ الاحتياطي تحت حالة معينة) من بين حالات أخرى.
ويمكن أن تساعد أدوات مثل traceroutes أو جهاز المراقبة على تحديد هذه الحالة لتدفقات معينة، إذا كان هذا هو الحال، وتعتمد على العديد من العوامل الأخرى، ويمكن أن تتطلب تلبية متطلبات التطبيقات وتقليل التأخير إعادة تصميم التوجيه أو هندسة حركة مرور البيانات.
جودة الخدمة (QoS)
من خلال تكوين جودة الخدمة (QoS)، يمكنك توفير معاملة تفضيلية لأنواع محددة من حركة المرور على حساب أنواع حركة المرور الأخرى. من دون جودة الخدمة في المثال التالي توفر خدمة أفضل جهد لكل حزمة، بغض النظر عن محتويات الحزمة أو حجمها. يعرض الأمر في المثال التالي إرسال الحزم دون أي ضمان للموثوقية أو حدود التأخير أو سعة المعالجة.
إذا كانت جودة الخدمة في موضعها، فسيصبح من المهم للغاية تحديد ما إذا كانت علامات الموجه، أو إعادة وضع العلامات، أو مجرد تصنيف الحزم، والتحقق من التكوين وعرض خريطة السياسة [name_of_policy_map | جلسة | interface_id] يساعد على فهم الفئات المتأثرة بارتفاع المعدلات أو حالات السقوط أو الحزم المصنفة بشكل غير صحيح.
تنفيذ جودة الخدمة هو مهمة شاقة تتطلب تحليلا جادا وهي خارج نطاق هذا المستند، ولكن يوصى بشدة بالنظر في هذا الأمر لتحديد أولوية التطبيقات الحساسة للوقت وحل العديد من مشاكل زمن الوصول والتطبيقات أو منعها.
مشاكل أخرى تتعلق بالأداء
ظروف أخرى يمكن أن تضيف بطء، إعادة توصيل جلسة العمل أو أداء سيئ عام تحتاج إلى فحصه، بعضها:
عمليات السقوط
المشكلة المرتبطة مباشرة بالمعالجة على الجهاز هي عمليات إسقاط الحزم، يلزمك التحقق من جانب الإدخال والإخراج من منظور الواجهة:
Router#sh interfaces GigabitEthernet0/0/1
GigabitEthernet0/0/1 is up, line protocol is up
Hardware is vNIC, address is 0ce0.995d.0000 (bia 0ce0.995d.0000)
Internet address is 10.10.1.2/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, link type is auto, media type is Virtual
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:19, output 00:08:33, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/6788/0 (size/max/drops/flushes); Total output drops: 18263
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 114000 bits/sec, 230 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
193099 packets input, 11978115 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
1572 input errors, 12 CRC, 0 frame, 1560 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
142 packets output, 11822 bytes, 0 underruns
Output 0 broadcasts (0 IP multicasts)
0 output errors, 0 collisions, 0 interface resets
23 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Router#
على جانب الإدخال لديك:
- عمليات إسقاط قائمة انتظار الإدخال: تمتلك كل واجهة قائمة انتظار إدخال (هذه هي مخزن مؤقت للبرامج يمكن تعديله) يتم وضع الحزم الواردة في انتظار المعالجة بواسطة معالج التوجيه (RP). إذا تجاوز معدل الحزم الواردة الموضوعة على قائمة انتظار الإدخال المعدل الذي يمكن به ل RP معالجة الحزم التي يمكن أن تحصل على زيادة في عدد مرات السقوط. ومع ذلك، يجب أن تكون على دراية بأنه لا يتم وضع سوى حزم التحكم لحركة المرور "لنا"، وبالتالي، إذا تم ملاحظة زمن الوصول على المرور، حتى إذا كنت قد حصلت على حالات سقوط متقطعة، فيجب ألا يكون ذلك سببا.
- التجاوز: يحدث ذلك عندما يتعذر على جهاز المستلم تسليم الحزم المستلمة إلى مخزن مؤقت للجهاز لأن معدل الإدخال يتجاوز قدرة جهاز الاستقبال على معالجة البيانات. يمكن أن يشير هذا الرقم إلى مشكلة في معدل وأداء الموجه، وميزة التقاط حركة مرور البيانات فقط لهذه الواجهة والبحث عن زيادات حركة مرور البيانات. أحد الحلول الشائعة هو تمكين التحكم في التدفق ولكن يمكن أن يضيف هذا إلى تأخير الحزم. ويمكن ان يكون ذلك أيضا دليلا على الاختناقات والافراط في الاشتراك.
- CRCs: يحدث بسبب مشاكل مادية، تحقق من الكابلات والمنافذ ووحدات SFP المتصلة بشكل صحيح ومن الوظيفة المناسبة.
على جانب المخرجات لدينا:
- عمليات إسقاط قائمة انتظار الإخراج: تمتلك كل واجهة قائمة انتظار إخراج يتم فيها وضع الحزم الصادرة التي سيتم إرسالها على الواجهة. في بعض الأحيان يتجاوز معدل الحزم الصادرة التي يتم وضعها في قائمة انتظار الإخراج بواسطة RP المعدل الذي يمكن أن تقوم به الواجهة بإرسال الحزم، قد يتسبب ذلك في حدوث مشاكل في الأداء وزمن الوصول في حالة عدم وجود جودة خدمة، وإلا، يمكنك زيادة هذا الرقم بسبب تطبيق سياسة معينة وتقديم المشورة لفحص أو تنفيذ تكوين جودة الخدمة لحماية حركة المرور المقصودة أو الحرجة وتأمينها.
أخيرا، ترتبط عمليات السقوط على QFP مباشرة بالمعالجة العالية التي يمكن أن تتسبب في زمن انتقال، تحقق عبر show platform hardware qfp عملية إسقاط الإحصائيات:
Router#show platform hardware qfp active statistics drop Last clearing of QFP drops statistics : never ------------------------------------------------------------------------- Global Drop Stats Packets Octets ------------------------------------------------------------------------- Disabled 2 646 Ipv4NoAdj 108171 6706602 Ipv6NoRoute 10 560
تعتمد الأسباب على التعليمات البرمجية، ويساعد تتبع FIA على تأكيد أو تجاهل حركة المرور المتأثرة بزمن الوصول عند هذه النقطة.
إعادة إرسال TCP
إعادة إرسال TCP هي عرض أو يمكن أن تكون نتيجة بسبب مشكلة أساسية مثل فقدان الحزمة. يمكن أن تؤدي هذه المشكلة إلى بطء الأداء وسوء الأداء عند التطبيق.
يستخدم بروتوكول التحكم في الإرسال (TCP) مؤقت إعادة الإرسال لضمان تسليم البيانات في غياب أي ملاحظات من مستقبل البيانات البعيد. ويشار إلى مدة هذا المؤقت باسم RTO (مهلة إعادة الإرسال). عند انتهاء صلاحية مؤقت إعادة الإرسال، يرسل المرسل المقطع الأقدم الذي لم يتم الاعتراف به من قبل مستقبل TCP ويتم زيادة RTO.
ولا يمكن القضاء تماما على بعض عمليات إعادة النقل، إذا كانت في حدها الأدنى، فإنها لا يمكن أن تعكس مشكلة. ومع ذلك، كما يمكنك إستنتاج ذلك، تمت مشاهدة المزيد من عمليات إعادة الإرسال والمزيد من التأخير في جلسة عمل TCP ويلزم معالجتها.
يمكن أن يدعم التقاط الحزمة الذي تم تحليله في Wireshark المشكلة على سبيل المثال التالي:
التقاط محادثة TCP
إذا كانت هناك عمليات إعادة إرسال، فاستخدم طريقة الالتقاط نفسها على مدخل الموجه واتجاه الخروج للتحقق من جميع الحزم التي يتم إرسالها واستقبالها. بالطبع، قد يمثل القيام بهذا على كل خطوة جهدا هائلا، لذا يلزم إجراء تحليل مفصل حول التقاط بروتوكول TCP، بالنظر إلى محولات TTL، والأوقات من الإطارات السابقة على نفس تدفق بروتوكول TCP لفهم أي إتجاه (الخادم أو العميل) لديك هذا التأخير أو عدم الاستجابة لتوجيه أستكشاف الأخطاء وإصلاحها.
الاكتتاب الزائد والاختناقات
يحدث زيادة الاشتراك عندما تكون الموارد المطلوبة (النطاق الترددي) أكبر من الموارد المتاحة الفعلية. غطيت الأوامر أن يعين إن أنت تتلقى هذا مشكلة على مسحاج تخديد بالفعل على قسم سابق.
ونتيجة لهذا الموقف، يمكن حدوث أختناقات عند إبطاء تدفقات حركة المرور بسبب عدم كفاية عرض النطاق الترددي أو سعة الأجهزة. ومن المهم تحديد ما إذا كان هذا يحدث في فترة زمنية قصيرة أو أن تطبيق الحلول هو وضع طويل الأجل.
لا توجد نصيحة خاصة لحل هذه المشكلة ولكن بعض الخيارات هي توازن حركة المرور إلى نظام أساسي مختلف أو تقسيم الشبكة أو الترقية إلى أجهزة أقوى استنادا إلى الاحتياجات الحالية وتحليل النمو في المستقبل.
معلومات ذات صلة
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
11-Oct-2023 |
الإصدار الأولي |
التعليقات