أستكشاف أخطاء TCP وإصلاحها على Nexus 9000 (NX-OS)

المقدمة

يوضح هذا المستند أساسيات بروتوكول TCP وتحليل حزمة Wireshark العميقة واستكشاف الأخطاء وإصلاحها عمليا لتحسين الأداء من نهاية إلى نهاية.

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

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• IP/TCP

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

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

• قياس سحابة Cisco Nexus 9000 مع Cisco NX-OS 10.6(X).

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

ما هو TCP

بروتوكول التحكم في الإرسال (TCP) هو بروتوكول طبقة نقل أساسي يعمل في الطبقة 4 من نموذج الاتصال المتبادل بين الأنظمة المفتوحة (OSI) ويوفر تسليم موثوق به، وتم طلبه، ويتم التحقق من الخطأ لتدفق من وحدات البايت بين التطبيقات التي تتصل عبر شبكة IP.

ثلاث فوائد رئيسية

1. الموثوقية: يتم توجيه TCP نحو الاتصال ويضمن التسليم من خلال طلب الإقرارات من المستقبل. إذا فقدت حزمة أو أفسدت أثناء الإرسال، يرسل TCP البيانات تلقائيا لضمان وصولها إلى الوجهة.
2. التسليم المطلوب: نظرا لأنه يمكن لحزم الشبكة الوصول خارج الترتيب، يقوم TCP بتعيين أرقام التسلسل لكل مقطع. وهذا يسمح للنظام المتلقي بإعادة تجميع البيانات بالترتيب الدقيق الذي أرسلت به في الأصل.
3. التحكم في التدفق والازدحام: يدير TCP معدل نقل البيانات بشكل ديناميكي لمطابقة سعة معالجة أجهزة الاستقبال وظروف الشبكة الحالية، مما يمنع فقدان البيانات الناجم عن تجاوز سعة التخزين المؤقت أو إزدحام الشبكة.

نظرة عامة على تضمين TCP/IP

يمثل المخطط مكدس بروتوكول TCP/IP حيث يتم تضمين مقطع TCP (الطبقة 4) داخل حزمة IP (الطبقة 3)، ثم داخل إطار إيثرنت (الطبقة 2) المعرف بواسطة IEEE 802.3. يضمن هذا النهج متعدد الطبقات الاتصال النمطي، حيث تضيف كل طبقة معلومات التحكم الخاصة بها (الرؤوس) لضمان التسليم والتوجيه وسلامة البيانات.

رأس إيثرنت (IEEE 802.3)

يكون رأس الإيثرنت في العادة 14 بايت، ويتكون من:

• غاية MAC عنوان (6 بايت)
• عنوان MAC المصدر (6 بايت)
• EtherType/الطول (2 بايت)

بالإضافة إلى ذلك، تتضمن إطارات الإيثرنت مقطورة لتسلسل التحقق من الإطارات (FCS) سعة 4 بايت للكشف عن الأخطاء في الطبقة 2. يحدد IEEE 802.3 الإطارات التي تحتوي على الحد الأدنى/الأقصى للأحجام وقيود التسليم المادية التي تؤثر بشكل مباشر على بروتوكولات الطبقة العليا مثل TCP.

رأس IP (IPv4)

يحتوي رأس IPv4 على حد أدنى للحجم يبلغ 20 بايت، ويمكن توسعته حتى 60 بايت باستخدام الخيارات. تتضمن الحقول الرئيسية ما يلي:

• عناوين IP المصدر والوجهة
• مدة البقاء (TTL)
• البروتوكول (يحدد TCP كحمولة)

تعد طبقة IP مسؤولة عن التوجيه والعنونة المنطقية عبر الشبكات، ولكنها لا تضمن الموثوقية.

بنية رأس TCP

يتراوح رأس TCP من 20 إلى 60 بايت حسب الخيارات. تتضمن الحقول الرئيسية ما يلي:

• منافذ المصدر/الوجهة
• رقم تسلسلي
• رقم الإقرار
• الأعلام (SYN و ACK و FIN و RST وما إلى ذلك)
• حجم النافذة
• المجموع الاختباري

يضيف بروتوكول TCP إمكانية تسليم موثوقة وتسلسل صحيح والتحكم في التدفق إلى إتصالات IP.

خيارات TCP (المشتركة 10)

تعمل خيارات بروتوكول TCP على توسيع البروتوكول الأساسي. ومن أكثر الأمور شيوعا ما يلي:

1. الحد الأقصى لحجم المقطع (MSS) - يحدد أكبر حمولة TCP يمكن للمضيف قبولها.
2. مقياس النافذة - يمدد نافذة الاستقبال إلى ما يتجاوز 65535 بايت.
3. السماح بالإشعار الانتقائي (السماح ب SACK) - تمكين إمكانية الإقرار الانتقائي.
4. الإقرار الانتقائي (SACK) - يحدد كتل البيانات المستلمة لتجنب عمليات إعادة الإرسال بالكامل.
5. الطوابع الزمنية - تستخدم لحساب RTT والحماية من أرقام السلاسل الملفوفة (PAWS).
6. عدم التشغيل (NOP) - الحشو لمحاذاة الخيارات.
7. نهاية قائمة الخيارات (EOL) - يحدد نهاية خيارات TCP.
8. فتح TCP السريع (TFO) - يسمح بتبادل البيانات أثناء المصافحة الأولية.
9. بروتوكول TCP متعدد المسارات (MPTCP) - يعمل على تمكين مسارات شبكة متعددة لجلسة عمل TCP واحدة.
10. خيار انتهاء مهلة المستخدم (UTO) - يتحكم في المدة التي يمكن أن تظل فيها البيانات المرسلة غير معروفة.

سلوك تسلسل TCP وإعلامه (بما في ذلك SYN/FIN)

تستهلك كل من علامتي SYN و FIN رقم تسلسل واحد، حتى في حالة عدم وجود حمولة. يعمل بروتوكول TCP باستخدام نموذج تسلسل موجه للبايت، حيث يتم إرسال كل بايت - وعلامات تحكم محددة - لتطوير مساحة التسلسل. هذا السلوك ضروري لتحليل TCP الدقيق في مجموعات الحزم وتشخيص التسلسلات أو حالات عدم تناسق الإقرار.

ACK = SEQ + طول الحمولة + (SYN ؟ 1: 0) + (FIN ؟ 1: 0)

حيث:

• SEQ = الرقم التسلسلي الأولي
• طول الحمولة = حجم البيانات بالبايت
• سين ؟ 1: 0 = إضافة 1 إذا تم تعيين علامة SYN، وإلا 0
• زعنفة ؟ 1: 0 = يضيف 1 إذا كانت علامة FIN معينة، وإلا 0
• ACK = البايت المتوقع التالي

مثال 1: SYN مع البيانات (فتح TCP السريع)

• م ع = 1000
• SYN = 1
• طول الحمولة = 200 بايت

حساب ACK:

• ACK = 1000 + 200 + 1 + 0 = 1201

ويعكس هذا سيناريو حيث يتم إرسال البيانات أثناء مصافحة TCP. تستهلك كل من الحمولة وعلامة SYN مساحة تسلسل.

مثال 2: FIN مع البيانات (إنهاء الاتصال)

• م ع = 3000
• زعنفة = 1
• طول الحمولة = 150 بايت

حساب ACK:

• ACK = 3000 + 150 + 0 + 1 = 3151

وهذا يوضح أنه يمكن أن يتضمن TCP البيانات أثناء خفض الاتصال، وأن كل من الحمولة وعلامة FIN تزيد من رقم التسلسل.

MSS وعلاقته ب MTU

يحدد الحد الأقصى لحجم المقطع (MSS) الحد الأقصى للحمولة التي يمكن ل TCP إرسالها في مقطع.

• وحدة الحد الأقصى للنقل (MTU) لشبكة إيثرنت النموذجية = 1500 بايت
• MSS = MTU − IP Header − TCP Header
• MSS القياسي = 1460 بايت (1500 − 20 − 20)

إذا كانت خيارات TCP موجودة، يتم خفض MSS وفقا لذلك. يتم التفاوض على MSS أثناء مصافحة TCP الثلاثية ومنع التجزئة في طبقة IP.

كيفية عمل تفاوض MSS في مصافحة TCP الثلاثية

يتم تبادل الحد الأقصى لحجم المقطع (MSS) أثناء مصافحة TCP الثلاثية باستخدام خيار MSS في حزم syn:

• المضيف A → المضيف B (SYN): الإعلان عن MSS الخاص به (على سبيل المثال، 1460)
• المضيف → B (SYN-ACK): الإعلان عن MSS الخاص به (على سبيل المثال، 1380)

وكل طرف يقول بفعالية:

هذه أكبر حمولة TCP مقبولة.

قاعدة المفتاح: MSS أتجاهي

لا يتم التفاوض على نظام الإدارة السليمة بيئيا كقيمة واحدة متفق عليها.

بدلا من ذلك:

• يستخدم كل مضيف MSS المعلن عنه من قبل الجانب الآخر.
• وهذا من شأنه أن يخلق حدودين مستقلين، واحد في كل إتجاه.

لذلك:

• يرسل A البيانات باستخدام MSS B.
• يرسل B البيانات باستخدام MSS ل A.

يمكن أن يرسل المصدر حمولة TCP أكثر من MSS الوجهة

في مكدس TCP يعمل بشكل صحيح: م

• يجب على المرسل إحترام MSS المعلن من قبل المستلم.
• قد يؤدي إرسال قطاعات أكبر إلى المخاطرة:
  • تجزئة IP (في حالة تجاوز MTU)
  • عمليات إسقاط الحزمة (إذا تم حظر التجزئة أو غير مدعوم)
• وهذا يؤدي إلى:
  • عمليات إعادة الإرسال
  • انخفاض الأداء
  • مشكلات مثل الثقوب السوداء ل PMTUD (مسار اكتشاف MTU)

رؤية عملية لاستكشاف المشكلات وحلها

• تحقق دائما من قيم MSS في مصافحة TCP ثلاثية الإتجاه (حزم SYN/SYN-ACK).
• التحقق من عدم التطابقات الناتجة عن:
  • أنفاق (VXLAN، GRE، IPsec)
  • جدران الحماية التي تعدل MSS (التشويش عبر MSS)
• على الأنظمة الأساسية مثل NX-OS من Cisco، غالبا ما يتم إستخدام ضبط MSS لمنع التجزئة عبر المسارات المدمجة

حجم النافذة (التحكم في التدفق)

يحدد "حجم النافذة" حجم البيانات التي يمكن أن يقبلها المستقبل دون إعلام.

ما هو:

• آلية التحكم في التدفق لمنع تجاوز سعة التخزين المؤقت.

القصد:

• يضمن عدم قيام المرسل بإرباك المستلم.

من اين تحصل عليها:

• مرئي في حزم الالتقاط (على سبيل المثال، Wireshark).
• مشتق من تكوين مكدس TCP لنظام التشغيل وحجم المخزن المؤقت.

متغير المورد/نظام التشغيل:

• عمليات تنفيذ مختلفة (Linux، Windows، NX-OS من Cisco) تستخدم القياس الديناميكي والضبط المؤقت، مما يؤدي إلى أحجام مختلفة للنافذة.

شرط النافذة الصفرية:

• عندما يكون حجم النافذة = 0، يكون المخزن المؤقت لجهاز الاستقبال ممتلئا.
• يقوم المرسل بإيقاف الإرسال مؤقتا وإرسال المستكشفات الدورية.

آليات Windows المتغيرة

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

أستكشاف الأخطاء وإصلاحها الاستخدام:

• عنق زجاجة → جانب المستقبل صغير أو منعدم في Windows (وحدة المعالجة المركزية والذاكرة والتطبيق).
• النوافذ الكبيرة ولكن ذات سعة معالجة منخفضة → مشكلات الشبكة (زمن الوصول والازدحام).
• تحليل سلوك النافذة أمر بالغ الأهمية لتشخيص مشاكل الأداء في جلسات عمل TCP.

أستكشاف أخطاء مستوى بيانات TCP وإصلاحها على Cisco Nexus 9000 (NX-OS)

يصف هذا القسم منهجية عملية لتشخيص ما إذا كان محول Cisco Nexus الذي يشغل NX-OS يؤثر على إعادة توجيه حركة مرور TCP أو يقدم مشاكل في الأداء. ويتم عرض هذا النهج من خلال سيناريو افتراضي.

عند ملاحظة زمن وصول TCP أو انخفاض الأداء، من الشائع في البداية الاشتباه في أن الشبكة تتسبب في ذلك. ومع ذلك، يجب التحقق من صحة هذا الافتراض من خلال التحليل الذي يستند إلى البيانات. الطريقة المخولة لاستكشاف أخطاء TCP وإصلاحها هي التقاط الحزم، ويتم تنفيذها بشكل مثالي:

• في وقت واحد في المصدر والوجهة
• قبل بدء حركة المرور

وهذا يضمن إمكانية الرؤية في عملية مصافحة TCP الثلاثية، حيث يتم التفاوض حول المعلمات الحيوية مثل MSS و Window Scale و SAACK ولا يتم تكرارها في وقت لاحق من الجلسة. إذا لم يكن من الممكن التقاط الصور المتزامنة، يمكن إجراء التحليل من خلال التقاط واحد، ولكن النتائج محدودة.

تعريف السيناريو

قام أحد المستخدمين بتحديد أن عملية النسخ الاحتياطي لمجموعة بيانات التطبيقات التي تبلغ سعتها 7.5 تيرابايت تقريبا، والتي تم إكمالها سابقا في غضون 9 ساعات تقريبا، تستغرق الآن حوالي 21 ساعة. على الرغم من أنه لا يزال يتم إنشاء جلسات عمل TCP بين العميل والخادم بنجاح، إلا أن الزيادة الكبيرة في مدة النسخ الاحتياطي تشير إلى حدوث انخفاض محتمل في سعة المعالجة أو أداء TCP الإجمالي. ونظرا لأن محول Nexus هو جهاز الشبكة الوحيد في المسار ويوفر أيضا وظيفة عبارة الطبقة 3، فيشك مسؤول الشبكة في أن محول Nexus هو سبب المشكلة.

• العميل: 10.93.19.8 (VLAN 10)
• الخادم: 10.91.2.35 (شبكة VLAN رقم 20)
• يعمل Nexus 9300 كبوابة افتراضية
• منفذ TCP رقم 445

التحقق الأولي (إمكانية الوصول)

• يتم إستخدام هذه الأوامر للتحقق من صحة مسار MTU (PMTU) بين المصدر والوجهة عن طريق إرسال حزم ICMP باستخدام مجموعة بت عدم تجزئة (DF). يساعد ذلك في تحديد الحد الأقصى لحجم الحزمة التي يمكن أن تجتاز الشبكة بدون تجزئة. يجب تنفيذ هذه العملية على كل من المصدر والوجهة.
• تحقق دائما من وحدة الحد الأقصى للنقل (MTU) للواجهة المادية على كل من المصدر والوجهة.
• في هذا السيناريو، يمكن الوصول فقط إلى المضيف المصدر، حيث تم تحديد وحدة الحد الأقصى للنقل (MTU) تبلغ 1500.

Linux: ping -c 10 -I 10.93.19.8 -s 1472 -M do 10.91.2.35

• -c 10 → يرسل 10 طلبات لصدى ICMP
• -I 192.168.10.10→ يستخدم هذا المصدر المحدد لبروتوكول IP/الواجهة
• -يعمل → الطراز 1472 على تعيين حجم حمولة ICMP إلى 1472 بايت
• -→ يضبط وحدة بت DF (لا تجزؤ)
• 192.168.20.20 → IP للوجهة

Windows: ping -n 10 -l 1472 -f 10.91.2.35

• -n 10 → يرسل 10 طلبات لصدى ICMP
• -يعمل → الطراز 1472 على تعيين حجم حمولة ICMP إلى 1472 بايت
• -f → يضبط علامة عدم التجزئة (DF)
• 192.168.20.20 → IP للوجهة

لماذا 1472 بايت؟

• حمولة ICMP = 1472 بايت
• عنوان IP = 20 بايت
• رأس ICMP = 8 بايت
• إجمالي حجم الحزمة: 1472 + 20 + 8 = 1500 بايت (وحدة الحد الأقصى للنقل (MTU) القياسية)
• هذا إختبار ما إذا كان المسار يدعم وحدة الحد الأقصى للنقل (MTU) ذات 1500 بايت بدون تجزئة. إذا حاولت إرسال 1500 بايت من حمولة ICMP، يمكن فشل إختبار الاتصال لأن إجمالي حجم الحزمة قد يتجاوز MTU القياسي بعد إضافة رؤوس IP و ICMP.

ما يمكن إستنتاجه

• إذا نجح إختبار الاتصال (بدون فقدان حزمة)، يدعم المسار وحدة الحد الأقصى للنقل (MTU) بسعة 1500 بايت على الأقل ولا يلزم وجود تجزئة.
  • → متابعة نتائج ICMP النظيفة لتحليل TCP
  • نجاح إختبار الاتصال المتقطع → فقد محتمل للحزم أو إزدحام عابر أو تحديد المعدل أو مشكلة إعادة توجيه؛ انتقل إلى تحليل فقدان الحزمة، نظرا لأن بروتوكول TCP يتطلب مسارا خاليا من الخسارة للعمل بكفاءة.
• إذا فشل إختبار الاتصال مع حدوث خطأ "التجزئة المطلوبة" أو أوقات الخروج، هناك إرتباط في المسار مع وحدات الحد الأقصى للنقل (MTU) أقل من 1500 بايت، لا يمكن إعادة توجيه الحزمة بسبب وحدة بت DF، وهذا يشير إلى وجود مشكلة في وحدة الحد الأقصى للنقل (MTU) للمسار.

كيفية إستخدام هذا الأمر لاستكشاف الأخطاء وإصلاحها

• قم بتخفيض حجم الحمولة تدريجيا (على سبيل المثال، 1472 → 1400 → 1300) لتحديد أكبر حجم ينجح.
• وبمجرد تحديدها، قم بحساب وحدة الحد الأقصى للنقل (MTU) باستخدام الصيغة MTU = الحمولة + 28 بايت (رؤوس IP + ICMP).

صلة عملية ب TCP

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

تعريف مسار حركة المرور (الواجهات)

لاستكشاف أخطاء أداء بروتوكول TCP بشكل فعال وإصلاحها على محول Cisco Nexus 9000 switch، فمن الضروري تحديد الواجهات التي تتلقى حركة مرور البيانات بين المصدر والوجهة وإعادة توجيهها.

في المخططات البسيطة، يمكن إستنتاج ذلك مباشرة من الاتصالات المادية. على سبيل المثال، إذا كان العميل متصلا بشبكة إيثرنت 1/1 والخادم بشبكة إيثرنت 1/2، فإن مسار حركة مرور البيانات يكون واضحا. ومع ذلك، في بيئات العالم الحقيقي التي تحتوي على العديد من الواجهات أو قنوات المنفذ أو تكوينات vPC، فإن هذا التعريف ليس دائما بسيطا.

في مثل هذه الحالات، يكون النهج الموصى به هو إستخدام وحدة محلل المنطق المضمنة (ELAM)، التي توفر إمكانية رؤية على مستوى أجهزة مستوى البيانات (ASIC).

تسمح لك ELAM بالتقاط حزمة أثناء معالجتها بواسطة خط أنابيب إعادة التوجيه وتكشف عن معلومات هامة مثل:

• واجهة الدخول
• واجهة الخروج
• قرار إعادة التوجيه (نتيجة البحث عن L2/L3)

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

من المهم ملاحظة أن ELAM يلتقط حزمة واحدة فقط في كل مرة، لذلك يجب تحديد معايير التصفية بدقة لتطابق حركة المرور المطلوبة (على سبيل المثال، مصدر IP، وجهة IP، منفذ TCP). إذا كانت عوامل التصفية واسعة للغاية، فهناك خطر التقاط حركة مرور غير مرتبطة مثل ICMP أو UDP بدلا من تدفق TCP المقصود.

وبالإضافة إلى ذلك، يجب تكرار هذه العملية لكل من إتجاهي حركة المرور:

• وجهة → المصدر
• مصدر → الوجهة

في البيئات التي تستخدم بروتوكول vPC أو ECMP، يمكن موازنة أحمال حركة مرور البيانات عبر مسارات متعددة. ونتيجة لذلك، يمكن لحركة مرور البيانات المقدمة والمرجعة عبور محولات أو واجهات مختلفة. في هذه السيناريوهات، يجب تنفيذ ELAM على كل محول من محولات Nexus ذات الصلة لضمان الرؤية الكاملة.

من خلال تحديد واجهات الدخول والخروج بشكل صحيح، يتم تقليل نطاق أستكشاف الأخطاء وإصلاحها بشكل كبير، مما يتيح التحقق المركز من عدادات الواجهة وسياسات جودة الخدمة وإعدادات وحدة الحد الأقصى للنقل (MTU) ونقاط الازدحام المحتملة على مسار إعادة التوجيه الدقيق.

تكوين ELAM (مقياس سحابة Nexus 9300)

يقوم هذا المثال بتصفية حركة المرور باستخدام مصدر IP 10.93.19.8، ووجهة IP 10.91.2.35، ومنفذ وجهة TCP 445.

إعداد ELAM

switch# debug platform internal tah elam 
switch(TAH-elam)# trigger init 
Slot 1: param values: start asic 0, start slice 0, lu-a2d 1, in-select 6, out-select 0
switch(TAH-elam-insel6)# set outer ipv4 src_ip 10.93.19.8
switch(TAH-elam-insel6)# set outer ipv4 dst_ip 10.91.2.35
switch(TAH-elam-insel6)# set outer l4 l4-type 0
switch(TAH-elam-insel6)# set outer l4 dst-port 445
switch(TAH-elam-insel6)# start 

بعد إنشاء حركة المرور، استرد النتيجة:

switch(TAH-elam-insel6)# report

التقاط حركة المرور العكسية (إلزامي لإمكانية الرؤية الكاملة)

للتحقق من صحة مسار الإرجاع، كرر التكوين عن طريق تبديل عناوين IP للمصدر والوجهة:

switch# debug platform internal tah elam 
switch(TAH-elam)# trigger init 
Slot 1: param values: start asic 0, start slice 0, lu-a2d 1, in-select 6, out-select 0
switch(TAH-elam-insel6)# set outer ipv4 dst_ip 10.93.19.8
switch(TAH-elam-insel6)# set outer ipv4 src_ip 10.91.2.35
switch(TAH-elam-insel6)# set outer l4 l4-type 0
switch(TAH-elam-insel6)# set outer l4 dst-port 445
switch(TAH-elam-insel6)# start 

ملاحظات عملياتية

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

المرجع

دليل ASIC ELAM الخاص بمقياس السحابة Cisco Nexus 9000

التحقق من صحة مستوى الواجهة

يضمن التحقق من صحة مستوى الواجهة عدم قيام محول Nexus بإدخال أي قيود أو شذوذ تؤثر على حركة مرور TCP. ويتم التركيز على تأكيد أن التكوين وحالة التشغيل وعدادات الأجهزة تتوافق مع السلوك المتوقع لإعادة توجيه مستوى البيانات عالي الأداء.

التحقق من صحة التكوين

• تحقق من عدم تطبيق أي قوائم تحكم في الوصول (ACL) تقييدية على الواجهات:

switch# show running-config interface ethernet1/1-2 | include access-group

• التحقق من عدم تأثير أي سياسات لجودة الخدمة غير المقصودة على حركة مرور البيانات (جودة الخدمة على مستوى الواجهة وعلى المستوى العالمي، بما في ذلك قوائم الانتظار ووضع السياسات وتشكيل الأشكال):

switch#show running-config interface ethernet1/1-2 | include service-policy
switch#show policy-map interface ethernet1/1-2

switch# show policy-map

switch# show class-map

switch# show class-map type network-qos

switch# show policy-map type network-qos 

switch# show policy-map system type network-qos 

switch# show queuing interface ethernet1/1-2

switch# show policy-map type queuing 

• تأكيد تكوين الطبقة 2 أو الطبقة 3 (switchport مقابل الواجهة الموجهة)، بما في ذلك عضوية شبكة VLAN وحالة بروتوكول الشجرة المتفرعة (STP) وعنونة IP:

switch#show running-config interface ethernet1/1-2

switch#show interface ethernet1/1-2 switchport

switch# show spanning-tree interface ethernet1/1-2

switch# show ip interface ethernet1/1-2

التحقق من حالة التشغيل

• تحقق من تناسق وحدة الحد الأقصى للنقل (MTU) وتأكد من مطابقتها للتكوين المتوقع (على سبيل المثال، 1500 أو 9000 بايت):

switch# show interface ethernet1/1-2 | include MTU

• تأكيد سرعة الواجهة وإعدادات الإرسال ثنائي الإتجاه:

switch# show interface ethernet1/1-2 | include speed|duplex

• التحقق من إستقرار الواجهة (لا يوجد إرتشاح أو انتقال متكرر للارتباطات):

switch# show interface ethernet1/1-2 | include rate|flap

التحقق من صحة عداد الأخطاء

• مسح العدادات قبل الاختبار:

switch# clear counters interface all 

• عدادات أخطاء المراقبة (قيم غير صفرية فقط):

switch# show interface counters errors non-zero | include Port|Eth1/1|Eth1/2 

التحقق من صحة ما بعد الاختبار

• أعد تشغيل إختبار حركة مرور TCP وراقب العدادات مرة أخرى:

switch# show interface counters errors non-zero | include Port|Eth1/1|Eth1/2 

• يجب عدم زيادة العدادات؛ تشير أي زيادة إلى مشاكل محتملة تتعلق بالطبقة 1 أو الأجهزة مثل أخطاء الارتباطات الفعلية أو أخطاء CRC/FCS أو تجاوز/إسقاط المخزن المؤقت.

التوجيه واستقرار ARP

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

معايير التحقق من الصحة

• يجب أن تكون إدخالات التوجيه للمصدر والوجهة موجودة ومستقرة ولا تتغير بشكل متكرر.
• يجب حل إدخالات ARP وعدم تحديثها أو فقدها بشكل مستمر.

switch# show ip route 10.93.19.8

switch# show ip route 10.91.2.35

switch# show ip arp detail | include 10.93.19.8

switch# show ip arp detail | include 10.91.2.35

التحقق من حركة المرور لم يتم انتقامها إلى وحدة المعالجة المركزية

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

أسلوب التحقق من الصحة

• التقط حركة مرور البيانات التي تصل إلى مستوى التحكم باستخدام الإيثاناليزر:

switch# ethanalyzer local interface inband display-filter "ip.addr==10.93.19.8 and ip.addr==10.91.2.35" limit-capture 0 

السلوك المتوقع

• لا يمكن ملاحظة حركة مرور بيانات مستوى بيانات TCP من المضيف إلى المضيف في وحدة المعالجة المركزية.

سلوك غير متوقع

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

تحديد زمن وصول إعادة توجيه الحزم

يعتمد زمن انتقال إعادة توجيه الحزم في محولات Nexus 9000 على حجم الحزمة ووضع إعادة التوجيه والميزات الممكنة. تشير مواصفات Cisco بشكل نموذجي إلى زمن الوصول للحزم ذات 64 بايت تحت إعادة التوجيه المباشر.

+----------------------+----------------------+-------------------------+-------------------------------+
| Switch Model         | ASIC / Architecture  | Ports (example config)  | Typical Forwarding Latency    |
|                      |                      |                         | (64B packet)                  |
+----------------------+----------------------+-------------------------+-------------------------------+
| Nexus 93180YC-EX     | Cloud Scale (EX)     | 48x25G + 6x100G         | ~1.0 – 1.2 microseconds       |
| Nexus 93180YC-FX     | Cloud Scale (FX)     | 48x25G + 6x100G         | ~0.9 – 1.0 microseconds       |
| Nexus 93180YC-FX2    | Cloud Scale (FX2)    | 48x25G + 6x100G         | ~0.8 – 0.9 microseconds       |
| Nexus 9364C          | Cloud Scale          | 64x100G                 | ~1.0 microsecond              |
| Nexus 9336C-FX2      | Cloud Scale (FX2)    | 36x100G                 | ~0.8 microseconds             |
| Nexus 93240YC-FX2    | Cloud Scale (FX2)    | 48x25G + 12x100G        | ~0.8 – 0.9 microseconds       |
| Nexus 92300YC        | Broadcom Trident II  | 48x10/25G + 6x40/100G   | ~2 – 3 microseconds           |
| Nexus 92160YC-X      | Broadcom Tomahawk    | 48x25G + 6x100G         | ~2 microseconds               |
+----------------------+----------------------+-------------------------+-------------------------------+

• إعادة التوجيه التفصيلي (الافتراضي في Nexus 9000):
  • يبدأ إعادة التوجيه قبل إستلام الحزمة الكاملة.
  • تقليل زمن الوصول إلى الحد الأدنى (من الثانية إلى µالثانية إلى الثانية تقريبا).
• التخزين وإعادة التوجيه:
  • يجب تلقي الحزمة بالكامل قبل إعادة التوجيه.
  • إضافة زمن وصول متناسب مع حجم الحزمة.

يمكن أن توفر الميزات الإضافية زمن وصول إضافي:

• تضمين/فك كبسلة VXLAN
• عمليات البحث في قائمة التحكم في الوصول (ACL) (معالجة TCAM)
• تصنيف جودة الخدمة وقوائم الانتظار
• Telemetry (NetFlow، ERSPAN، sFlow)
• التخزين المؤقت أثناء الازدحام

ومع ذلك:

• يتم تنفيذ هذه العمليات في خطوط أنابيب الأجهزة.

إن السيناريو الواقعي الوحيد الذي يزيد فيه زمن الوصول بشكل ملحوظ هو الازدحام:

• يتم تخزين الحزم مؤقتا في قوائم انتظار الخروج.
• يتوقف التأخير على:
  • عمق قائمة الانتظار
  • إستخدام الواجهة
  • سياسات جودة الخدمة

حتى في هذه الحالات:

• زمن الوصول يكون عادة في نطاق الميكروثانية إلى مئات من الميكروثانية منخفضة.
• يعني التأخير المستمر على مستوى المللي ثانية:
  • إزدحام شديد
  • فرط الاشتراك
  • جودة الخدمة (QoS) أو التخزين المؤقت غير المكون

فسحة بين دعامتين إلى وحدة المعالجة المركزية (التقاط الحزمة لمستوى البيانات)

وهذا يتيح نسخ حركة مرور مستوى البيانات في مستوى التحكم لالتقاط الحزمة وتصديرها إلى ملف .pcapng، مما يسمح بالتحليل التفصيلي في Wireshark.

التكوين

monitor session 1
 source interface ethernet1/1 both
 source interface ethernet1/2 both
 destination interface sup-eth0
 no shut

تنفيذ أسر

switch# ethanalyzer local interface inband mirror capture-filter "tcp port 445" limit-capture 0 write bootflash:tcp_capture.pcapng 

اعتبارات تقنية

• تخضع حركة المرور التي يتم عكسها على وحدة المعالجة المركزية (CPU) لتنظيم مستوى التحكم (CoPP).
• إذا تجاوزت حركة المرور CoPP:
  • يمكن إسقاط الحزم فقط في مستوى التحكم.
  • يؤدي هذا إلى ظهور نتائج إيجابية خاطئة أثناء التحليل.
• يوصى بفسحة بين دعامتين إلى وحدة المعالجة المركزية (CPU) لسيناريوهات حركة مرور البيانات المنخفضة إلى المتوسطة.
• للبيئات ذات الإنتاجية العالية:
  • استعملت فسحة بين دعامتين محلي (محلل خارجي)
  • إستخدام ERSPAN للالتقاط عن بعد

طريقة	الميزة	تحديد
شبر	دقيق، بدون تضمين	يتطلب اتصالا ماديا.
ERSPAN	إمكانية الالتقاط عن بعد	عرضة لازدحام الشبكة.

التحقق من صحة تحديد معدل مستوى التحكم

لضمان موثوقية التقاط فسحة بين دعامتين إلى وحدة المعالجة المركزية، من الضروري التحقق من أن مستوى التحكم لا يقوم بإسقاط الحزم المتطابقة بسبب تحديد المعدل.

أمر التحقق من الصحة

switch(config)# show hardware rate-limiter | i Allowed|span

Allowed, Dropped & Total: aggregated bytes since last clear counters

R-L Class     Config Allowed Dropped Total

span          50           0       0     0 <<<

span-egress   disabled     0       0     0

منهجية التحقق من الصحة

• قم بتنفيذ الأمر على فترات زمنية أقلها من 3 ثوان.
• راقبت الفسحة بين دعامتين متصل قارن إسقاط.

تأويل

• لا تشير أي زيادة في عدادات الإسقاط لفسحة بين دعامتين صف إلى التقاط يمكن الاعتماد عليه.
• تشير الزيادة في عدادات الإسقاط إلى فقدان الحزمة في مستوى التحكم، مما يجعل الالتقاط غير موثوق به.

إن لوحظ قطرات، الالتقاط طريقة ينبغي كنت غيرت أن يجسر أو ERSPAN.

التحقق من الصحة المستندة إلى ICMP قبل TCP

يوفر إختبار ICMP التحقق الأساسي من سلامة مستوى البيانات قبل إجراء تحليل TCP المعقد. نظرا لأن بروتوكول ICMP عديم الحالة وأبسط، فإنه يسمح بالكشف السريع عن فقدان الحزمة أو التكرار أو عدم تناسق المسار.

سلوك متوقع في فسحة بين دعامتين التقاط

• يمكن أن تظهر كل حزمة ICMP مرتين:
  • مرة عند الدخول
  • مرة عند الخروج
• للحصول على إختبار اتصال قياسي:
  • طلب → صدى 2 ربط
  • رد الارتداد → 2 حزم

وهذا يؤكد إعادة التوجيه الصحيحة وغياب فقدان الحزمة في مستوى البيانات.

سلوك شاذ

• تشير التكرارات المفقودة أو أعداد الحزم غير المتماثلة إلى وجود قيود محتملة على فقدان الحزم أو الالتقاط.
• تقترح فترات الانتظار المتقطعة مشاكل الطبقة 1، أو الازدحام، أو مشاكل المنبع.

إذا تم إعادة توجيه حركة مرور ICMP بشكل متناسق دون فقد، فهناك احتمال كبير بأنه يتم أيضا إعادة توجيه حركة مرور TCP بشكل صحيح في الطبقة 2/3.

تحديد زمن وصول إعادة توجيه محول Nexus باستخدام التقاط الحزمة

عندما قبض حركة مرور يستعمل فسحة بين دعامتين إلى CPU (أو فسحة بين دعامتين/ERSPAN)، كل ربط يستطيع كنت monitore مرتين: مرة واحدة على المدخل ومرة واحدة على المخرج. يمكن إستخدام هذا التكرار لتقدير زمن انتقال إعادة التوجيه الذي أدخله المحول Nexus عن طريق حساب فرق الوقت بين كلا المثيلين لنفس الحزمة.

عمليا، يمكن قياس هذا التأخير باستخدام حركة مرور ICMP التي تم التقاطها سابقا بمقارنة دلتا الوقت بين طلب الارتداد المضاعف وحزم الرد على الارتداد. وهذا يوفر قاعدة أساسية بسيطة وفعالة لأداء إعادة توجيه المحول. إذا كان مطلوبا تحليل أعمق، يمكن تطبيق نفس المنهجية على حركة مرور TCP من خلال التقاط التدفق وقياس فرق الوقت بين حزم TCP المكررة.

منهجية

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

تشكيل Wireshark

• تمكين عرض دلتا الوقت:

View > Time Display Format > Seconds Since Previous Displayed Packet

• إضافة عمود مخصص لدلتا الوقت:

Right-click on "Time Delta from Previous Displayed Packet" → Apply as Column

• تصفية حركة المرور ذات الصلة (مثال):

ip.addr==10.93.19.8 and ip.addr==10.91.2.35 and tcp

• فرز الحزم حسب الرقم التسلسلي أو تدفق TCP:

Right-click packet → Follow → TCP Stream

تأويل

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

المراجع

• أوراق بيانات سلسلة Cisco Nexus 9000
• أدلة تصميم المحولات Cisco Nexus 9000 Series
• الإدارة الذكية للمخزن المؤقت على سلسلة مبدلات Cisco Nexus 9000
  
  

تحليل حركة مرور TCP من التقاط حزمة المضيف المصدر

يوفر هذا القسم منهجية تفصيلية لتحليل التقاط حزمة TCP في Wireshark، بما في ذلك تكوين ملف التعريف، من خلال الحالة الافتراضية الموضحة مسبقا. وقد التقطت الصور التي عرضت مباشرة من موقع Wireshark. وعلى سبيل التذكير، فإن السيناريو هو:

قام أحد المستخدمين بتحديد أن عملية النسخ الاحتياطي لمجموعة بيانات التطبيقات التي تبلغ سعتها 6.5 تيرابايت تقريبا، والتي تم إكمالها سابقا في غضون 9 ساعات تقريبا، تستغرق الآن حوالي 21 ساعة. جهاز الشبكة الوحيد الذي يمكن الوصول إليه هو محول Cisco Nexus 9300 switch متصل بخادم المصدر (10.93.19.8). يبلغ حجم وحدة الحد الأقصى للنقل (MTU) التي تم تكوينها على واجهة المحول 9000 بايت (الإطارات كبيرة الحجم)، بينما لا تعرف وحدة الحد الأقصى للنقل (MTU) الموجودة على الخادم. يتوفر التقاط حزمة من خادم المصدر، وقد تم بالفعل إكمال جميع خطوات التحقق من صحة Nexus السابقة بدون اكتشاف أي حالات شاذة.

ثالثا - الملاحظات والقيود الرئيسية

• تم إستبعاد محول Nexus:
  • لا توجد عمليات إسقاط حزم
  • لا توجد أخطاء في الواجهة
  • لا تأثير على جودة الخدمة أو قائمة التحكم في الوصول (ACL)
  • تم تأكيد إعادة توجيه الأجهزة
• قارن تشكيل:
  • منفذ الوصول
  • وحدة الحد الأقصى للنقل: 9000 بايت
• البيانات المتوفرة:
  • التقاط الحزمة في المصدر
  • معرفة شاملة لوحدة الحد الأقصى للنقل (MTU)
    • اكتمل إختبار الاتصال بنجاح بدون تجزئة باستخدام حزمة سعة 1500 بايت مع 1472 بايت من البيانات.
• البيانات المفقودة:
  • رؤية الوجهة
  • لا يتوفر التقاط حزمة على الخادم الوجهة.

في Wireshark، يمكنك إنشاء ملفات تخصيص مخصصة مخصصة مخصصة لنوع معين من التحليل الذي تريد إجراؤه.

وصف العمود

• tcp.analysis.initial_rtt (iRTT): يقدر الوقت الأولي للرحلة ذهاب وإياب استنادا إلى مصافحة TCP الثلاثية.
• tcp.analysis.ack_rtt (ACK RTT): يقيس الوقت بين جزء TCP والإقرار المقابل له.
• tcp.window_size (نافذة): الإشارة إلى حجم نافذة TCP المعلن من قبل المستقبل قبل تطبيق القياس.
• tcp.options.wscale.multiplier (متعدد): يمثل عامل قياس النافذة المستخدم لحساب نافذة الاستلام الفعالة.
• tcp.seq (seq#): يعرض الرقم التسلسلي للبايت الأول في مقطع TCP.
• tcp.len (الحمولة): إظهار حجم حمولة TCP بالبايت لذلك المقطع.
• tcp.ack (ACK#): الإشارة إلى البايت المتوقع التالي من المرسل (الإقرار التراكمي).
• tcp.options.mss_val (MSS): يعرض الحد الأقصى لحجم المقطع المعلن عنه أثناء مصافحة TCP.
• ip.ttl (TTL): إظهار قيمة مدة البقاء، المفيدة لتحديد عدد الخطوات وسلوك التوجيه.
• tcp.analysis.bytes_in_flight (وحدات البايت في الرحلة): يمثل كمية البيانات غير المعترف بها التي يتم نقلها حاليا.

تحليل مصافحة TCP الثلاثية

يعد التقاط مصافحة TCP ثلاثية الإتجاه إلزاميا لأنه يحتوي على معلمات حساسة مثل MSS و Window Scale و SACK التي تعرف كيفية تصرف الجلسة.
بدون هذه المعلومات، يكون أي تحليل TCP غير كامل ويمكن أن يؤدي إلى إستنتاجات غير صحيحة حول الأداء أو السبب الجذري.

تحديد حركة المرور

من التقاط الحزمة:

• عنوان IP المصدر: 10.93.19.8
• غاية عنوان: 10.91.2.35

تحليل الوقت الأولي للسفر ذهابا وإيابا (iRTT)

يتم حساب RTT الأولي (iRTT) على النحو التالي:

• iRTT = 798 ميكروثانية

هذه القيمة مشتقة من:

• Packet 2 (Syn-ACK) ACK RTT: → µ وقت الوجهة للرد على SYN ل 750.
• Packet 3 (ACK) ACK RTT: 48 µ→ الوقت الذي يسمح فيه المصدر بالاعتراف ب SYN-ACK.

يوجد معظم زمن الوصول (~94٪) في المسار الأمامي (عميل → Client Server →)، بينما يكون وقت الاستجابة من المصدر أقل، مما يشير إلى عدم وجود وحدة المعالجة المركزية (CPU) أو تأخر التطبيق على العميل. 

التعرف على منفذ TCP

• غاية TCP ميناء: 445

يتوافق المنفذ 445 مع Microsoft Server Message Block (SMB)، المستخدم بشكل شائع لمشاركة الملفات ومحركات أقراص الشبكة وخدمات مصادقة Windows. يعد هذا البروتوكول حساسا لكل من زمن الوصول والإنتاجية، مما يجعله معتمدا بدرجة كبيرة على كفاءة TCP واستقرار الشبكة.

تحليل حجم نافذة TCP

• النافذة المصدر (مقاس): 64,240 بايت
• نافذة الوجهة: 65,535 بايت

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

يمكن تقدير أقصى خرج نظري باستخدام:

الخرج = حجم نافذة TCP / RTT

إستبدال القيم التي تمت ملاحظتها:

• حجم نافذة TCP = 64،240 بايت
• RTT = 798 ميكروثانية = 0.000798 ثانية

سعة المعالجة ≈ 64240 / 0.000798 ≈ 80.5 ميجابايت/الثانية (644 ميجابت في الثانية تقريبا)

يمثل هذا الحد الأعلى لمعدل نقل البيانات بافتراض:

• عدم فقدان الحزمة
• لا إعادة إرسال
• ظروف الشبكة المثالية

تحليل الخرج ووقت النقل والشروط المطلوبة

وبسرعة المعالجة الحالية التي تبلغ 644 ميجابت في الثانية، يستغرق نقل ملف بسعة 6.5 تيرابايت ما يقرب من 23.5 ساعة، مما يتوافق مع ميزة الانخفاض الملحوظ. لإنجاز إطار نقل لمدة 9 ساعات، يجب زيادة سعة المعالجة إلى 1.68 جيجابت في الثانية تقريبا، مما يتطلب إما نافذة TCP أكبر (زيادة حوالي 2.7 ×) أو RTT أقل بشكل ملحوظ (حوالي 291 µ).

في ظل الظروف الحالية (64 كيلوبايت من النافذة وحوالي 798 µمن RTT)، لا يمكن الوصول إلى هدف 9 ساعات، لأن خرج TCP مقيد بواسطة منتج تأخير النطاق الترددي. ودون زيادة حجم النافذة أو تقليل زمن الوصول، لا يمكن للبروتوكول إستخدام نطاق ترددي أكبر متاح، مما يجعل الهدف غير قابل للتحقيق.

السيناريو	سعة المعالجة	الوقت المقدر للنقل (6.5 تيرابايت)	إطار TCP المطلوب	RTT المطلوب
الحالة الحالية	644 ميجابت في الثانية (~80. 5 ميجابايت في الثانية)	~23.5 ساعة	64 كيلوبايت	798 µs
الهدف (9 ساعات)	~1683 ميجابت في الثانية (~210 ميجابايت في الثانية)	9 ساعات	~172 كيلوبايت	~291 µ

وقد تم ذلك سابقا، مما يشير إلى حدوث تغيير في الشبكة أو التطبيق أو المصدر أو الوجهة. ومن الأهمية بمكان أن نلاحظ أنه استنادا إلى هذا التحليل الأولي وحده يمكن بالفعل التوصل إلى إستنتاج هام: في ظل حجم نافذة TCP وشروط RTT الحالية، لا يمكن تحقيق هدف ال 9 ساعات.

تعرض الجداول مقارنة لكيفية تباين سعة المعالجة حسب زيادة أو نقصان حجم نافذة RTT و TCP.

تأثير RTT على سعة المعالجة (حجم النافذة الثابت = 64،240 بايت)

RTT	سعة المعالجة (ميجابايت/ثانية)	سعة المعالجة (ميجابت في الثانية)
200 µ (0.0002 ثانية)	~321 ميجابايت/ثانية	~2،568 ميجابت في الثانية
µ 798 (0.000798 s)	~80.5 ميغابايت/الثانية	~644 ميجابت في الثانية
2 مللي ثانية (0.002 ثانية)	~32.1 ميغابايت/الثانية	~257 ميجابت في الثانية
10 مللي ثانية (0.01 ثانية)	~6.4 ميجابايت/ثانية	~51 ميجابت في الثانية

تأثير حجم نافذة TCP (RTT الثابت = 798 µ)

حجم نافذة TCP	سعة المعالجة (ميجابايت/ثانية)	سعة المعالجة (ميجابت في الثانية)
16 كيلوبايت (16 384 مليا)	~20.5 ميغابايت/الثانية	~164 ميجابت في الثانية
64 كيلوبايت (64 240 مليا)	~80.5 ميغابايت/الثانية	~644 ميجابت في الثانية
256 كيلوبايت (262 144 مليا)	~328 ميجابايت/ثانية	~2،624 ميجابت في الثانية
1 ميغابايت (1،048،576 مليا)	~1،314 ميجابايت/ثانية	~10.5 جيجابت في الثانية

التفسير الفني

• يتناسب معدل نقل البيانات عكسيا مع زمن وصول RTT → العالي مما يقلل الأداء.
• يتناسب معدل نقل البيانات بشكل مباشر مع حجم نافذة TCP التي → تزيد من سعة النوافذ الأكبر.
• تعمل أحجام الإطارات الصغيرة على الحد بشدة من سعة المعالجة، حتى في البيئات التي يقل فيها زمن الوصول.
• تتطلب الشبكات فائقة السرعة (10G+) تطوير النافذة للاستفادة الكاملة من النطاق الترددي.

وهذا يوضح أن كلا من حجم نافذة RTT و TCP هما عاملان حاسمان في أداء TCP ويجب تحليلهما معا عند أستكشاف أخطاء الخرج وإصلاحها.

طول رأس IP و TCP

• طول رأس IP: 20 بايت
• طول رأس TCP: 32 بايت

يشير رأس IP بحجم 20 بايت إلى عدم وجود خيارات IP. يؤكد رأس TCP ذو 32 بايت أنه يتم إستخدام خيارات TCP، مع إضافة 12 بايت خارج الرأس الأساسي. تتضمن هذه الخيارات عادة MSS، قياس النافذة، و SACK المسموح به.

تحليل خيارات TCP و TTL

تم تمكين الإقرار الانتقائي (SACK) على نقطتي النهاية. هذا غير مرئي في الصورة. ويتيح SAACK للمتلقي أن يعترف بالكتل غير المتلاصقة من البيانات، وأن يبلغ المرسل على وجه التحديد بالأجزاء التي تم إستلامها بنجاح.

على سبيل المثال، إذا تم تلقي الأجزاء 1000-2000 و 3000-4000 ولكن تم فقدان 2000-3000، فيمكن أن يشير المستقبل إلى ذلك بشكل صريح. وفي غياب نظام SAACK فإن المرسل سوف يعيد إرسال كل البيانات بعد الفجوة؛ مع SAACK، فقط الجزء المفقود يتم إعادة نقله. يؤدي هذا إلى تحسين الأداء بدرجة كبيرة في البيئات التي تعاني من فقدان الحزم.

تحليل الحزمة 1 (SYN)

• سيق#: 0 (تم تطبيع Wireshark)
• الحمولة: 0 بايت
• ACK#: 0
• إم إس: 1460 بايت
• ttl: 128

يقوم Wireshark بتعميم الرقم التسلسلي إلى صفر من أجل إمكانية القراءة، على الرغم من أنه عمليا يمثل قيمة عشوائية كبيرة. من المتوقع عدم وجود حمولة أثناء إنشاء الاتصال. تشير قيمة MSS البالغة 1460 بايت إلى MTU بمقدار 1500 بايت (رأس IP بحجم 20 بايت + رأس TCP بحجم 20 بايت). يمكن أن تكون مدة البقاء (TTL) ل 128 مضيف مستند إلى Windows، ومشاهدة هذه القيمة في الالتقاط تشير إلى أن الالتقاط كان من المحتمل عند المصدر أو بالقرب منه جدا عبر الطبقة 2.

تحليل الحزمة 2 (SYN-ACK)

• ACK#: 1

قيمة ACK هي 1 لأن علم SYN يستهلك رقم تسلسل واحد، حتى عندما لا يوجد حمولة. لذلك، ACK = SEQ + 1.

• ttl: 59

وتشير مدة البقاء (TTL) التي تم رصدها البالغة 59 قدما إلى مدة البقاء (TTL) الأولية التي تبلغ 64، مما يعني أن الحزمة إجتازت ما يقرب من 5 نقلات توجيه (64 − 59 = 5). تقوم كل خطوة موجهة بخفض مدة البقاء (TTL) بمقدار واحد.

خطر التجزئة وأثر الشبكة

يؤدي وجود خمس نقلات توجيه تقريبا إلى فرض مخاطر محتملة على الأداء، خاصة فيما يتعلق بعدم تطابق وحدة الحد الأقصى للنقل (MTU) والتجزئة.

إذا كان لأي إرتباط متوسط وحدة الحد الأقصى للنقل (MTU) أقل من حجم الحزمة الأصلية، يمكن أن يحدث التجزئة. ويقودنا هذا إلى عواقب عديدة:

• زيادة زمن الوصول بسبب التجزئة ونفقات إعادة التجميع.
• احتمال أكبر لفقدان الحزمة، نظرا لأن فقدان جزء واحد يتطلب إعادة نقل الحزمة بالكامل.
• تقليل سعة المعالجة، نظرا لأن بروتوكول TCP يفسر الخسارة على أنها إزدحام ويقلل من معدل الإرسال الخاص بها.
• زيادة إستخدام وحدة المعالجة المركزية (CPU) على أجهزة الشبكة التي تعالج التجزئة.
• خطر حدوث حالات فشل في اكتشاف وحدة الحد الأقصى للنقل (MTU) للمسار (PMTUD) إذا تم حظر بروتوكول ICMP، مما يؤدي إلى عمليات إسقاط حزم صامتة.

وبالنظر إلى هذه العوامل، من الأهمية بمكان ضمان اتساق وحدة الحد الأقصى للنقل عبر المسار أو تنفيذ إجراءات التشدد في إطار نظام إدارة المواد الكيميائية عند الاقتضاء.

تحليل TCP RTT: ACK RTT مقابل RTT الأولي

عندما يكون ACK RTT أكبر من iRTT، فإنه يشير إلى أن زمن الوصول قد زاد مقارنة بالخط الأساسي الذي تم إنشاؤه أثناء مصافحة TCP.

هذا يعني أن الشبكة أو نقاط النهاية تتسبب في مزيد من التأخير خلال الجلسة، وذلك عادة بسبب:

• إزدحام الشبكة أو قوائم انتظار
• تأخيرات في معالجة العميل أو التطبيق
• الأجهزة الوسيطة (جدران الحماية، موازن التحميل)
• عمليات إعادة الإرسال

إذا إستمرت هذه الحالة طوال جلسة TCP، فإنها تؤدي إلى:

• معدل إخراج TCP منخفض
• إستخدام غير فعال للنافذة
• أداء محسن للتطبيقات

في Wireshark، من الممكن عرض عدد مرات حدوث الشرط ACK RTT > iRTT باستخدام ميزة رسم I/O البياني أدناه: Statistics → I/O Graph، تطبيق مرشح العرض (tcp.analysis.ack_rtt > tcp.analysis.initial_rtt)، تحديد نمط النبضات، إعداد المحور Y على الحزم، واستخدام فاصل مقداره 50 ميكرو ثانية.

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

ومن المهم أيضا تحديد المدة التي يتم فيها تجاوز معدل نقل البيانات، وليس مجرد عدد المرات. على الرغم من أن Wireshark لا يسمح بالطرح بين الحقول مباشرة، إلا أنه يمكن إجراء مقارنة مرئية باستخدام رسومات الإدخال/الإخراج البيانية:

• انتقل إلى رسومات → الإدخال/الإخراج الإحصائية
• الرسم البياني 1:
  • عامل تصفية العرض: tcp.analysis.ack_rtt > tcp.analysis.initial_rtt
  • النمط: بار
  • محور ص: متوسط
  • حقل ص: tcp.analysis.ack_rtt
  • الفاصل الزمني: 50 ميكروثانية
• الرسم البياني 2:
  • عامل تصفية العرض: tcp.analysis.initial_rtt
  • النمط: بار
  • محور ص: الحد الأقصى
  • حقل ص: tcp.analysis.initial_rtt
• ثم انقر بزر الماوس الأيمن على الرسم البياني وقم بتمكين قياس السجل.

في هذا العرض المرئي، يمثل الرسم البياني البنفسجي الشرط ACK RTT > iRTT، والذي يكون موجودا بشكل ثابت خلال جلسة TCP بأكملها. وتظهر البيانات تضخم زمن الانتقال المستمر، حيث تصل فترات ذروة متعددة إلى 11 مللي ثانية وترتفع الحد الأقصى إلى أكثر من 100 مللي ثانية، مما يمثل 11x إلى 100 ضعف الحد الأساسي ل iRTT.

ويؤكد هذا السلوك أن زيادة زمن الانتقال ليست عابرة بل مستمرة، مما يشير إلى مسألة منهجية تؤثر على الدورة على مر الزمن. ويشير هذا الانحراف المستمر بشدة إلى عوامل مثل إزدحام الشبكة أو التخزين المؤقت (Bufferbloat) أو تأخيرات معالجة نقطة النهاية.

عمليات إعادة إرسال بروتوكول TCP وتحليل عمليات إعادة الإرسال الزائفة

يقوم هذا القسم بتقييم موثوقية TCP من خلال تحليل عمليات إعادة الإرسال عبر الوقت، مما يتيح التحقق مما إذا كان فقدان الحزمة يساهم في انخفاض الأداء.

عمليات إعادة إرسال بروتوكول TCP عبر الوقت

يوضح الرسم البياني توزيع عمليات إعادة إرسال TCP عبر الوقت. ولوحظ ما مجموعه 42 إعادة إرسال، تمثل 0.00125 في المائة فقط من مجموع حركة المرور.

هذا المستوى من إعادة الإرسال تافه ويشير بوضوح إلى أن فقدان الحزمة ليس عاملا مساهما في هذا السيناريو.

تكوين Wireshark (عمليات إعادة إرسال TCP)

Statistics → I/O Graphs

• عامل تصفية العرض:

tcp.analysis.retransmission and !tcp.analysis.spurious_retransmission

• النمط: دفع أو شريط
• محور ص: الحزم
• الفاصل الزمني: 1 ثانية

عمليات إعادة إرسال TCP المزيفة

يوضح الرسم البياني عدد عمليات إعادة الإرسال المزيفة لبروتوكول TCP في فواصل زمنية مدتها 1 ثانية تم إنشاؤها بواسطة المصدر 10.93.19.8.

في Wireshark، يشير إعادة بث TCP الاحتيالي إلى أن المضيف أعاد إرسال مقطع لم يتم فقدانه بالفعل. وصلت الحزمة الأصلية إلى المستلم بنجاح، ولكن المرسل افترض الخسارة بشكل غير صحيح بسبب تقدير التوقيت غير الدقيق. لا يشير هذا السلوك إلى خسارة حقيقية للحزمة، بل إلى منطق إعادة الإرسال غير الفعال عند المرسل.

في هذا الالتقاط:

• يرسل المصدر 10.93.19.8 الحزم بعد حوالي 8 ميكروثانية فقط.
• بينما تكون مؤقتات إعادة الإرسال النموذجية في حدود 200 مللي ثانية تقريبا.

وهذا يؤكد أن سلوك إعادة الإرسال يتم التحكم فيه بالكامل بواسطة مكدس TCP المصدر، وليس بواسطة الشبكة.

ويبلغ العدد الإجمالي لعمليات إعادة الإرسال الزائفة التي تمت ملاحظتها 112 حالة، وهو ما يمثل 0.0332٪ من إجمالي حركة المرور التي تم الاستيلاء عليها.

تكوين Wireshark (عمليات إعادة إرسال TCP المزيفة)

Statistics → I/O Graphs

• عامل تصفية العرض:

tcp.analysis.spurious_retransmission and ip.src==10.93.19.8

• النمط: دفع أو شريط
• محور ص: الحزم
• الفاصل الزمني: 1 ثانية

التفسير الفني

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

كما يعزز هذا التحليل أن المشكلة لا تتعلق بموثوقية الشبكة، بل بسلوك TCP أو زمن الوصول أو أداء نقاط النهاية.

تحليل الإنتاج الفعال

تظهر الرسمة البيانية سعة المعالجة الفعالة، ويتم حسابها استنادا إلى حمولة بروتوكول TCP (البيانات الفعلية المنقولة) بالموجات في الثانية. يتذبذب الخرج الذي تم رصده بشكل أساسي بين 600 ميجابت/ثانية و 800 ميجابت/ثانية، مما يشير إلى أنه في حين تعمل الشبكة على نقل البيانات بشكل نشط، فإنها لا تصل إلى إمكانات عرض نطاق ترددي أكبر.

تكوين Wireshark (سعة معالجة فعالة)

Statistics → TCP Streams Graphs → Throughout

التفسير الفني

• يتوافق نطاق سعة المعالجة الذي يتراوح من 600 إلى 800 ميجابت في الثانية مع الحسابات السابقة استنادا إلى حجم نافذة TCP و RTT.
• تعكس الاختلافات في الإنتاجية:
  • ترددات RTT
  • تعديلات التحكم في إزدحام TCP
  • تخزين التطبيقات مؤقتا أو مؤقتا
• نظرا لأن سعة المعالجة لا تقترب من معدل الخط (على سبيل المثال، 10 جم)، فإن المحدودية ليست عرض النطاق الترددي المادي بل قيود كفاءة بروتوكول TCP.
• يؤكد هذا التحليل أن الإنتاجية التي تم ملاحظتها متوافقة مع قيود بروتوكول TCP (حجم النافذة وزمن الوصول)، مما يؤكد أن الاختناقات لا ترجع إلى فقدان الحزمة أو سعة الواجهة، ولكن بسبب سلوك طبقة النقل وظروف نقطة النهاية.

البيانات في تحليل الطيران (نافذة TCP)

يسلط الرسم البياني الضوء على سلوك حرج في جلسة عمل TCP بمقارنة سعة المتلقي مقابل البيانات الفعلية أثناء النقل (وحدات البايت أثناء الطيران).

• يمثل الخط الأخضر مقدار بيانات TCP التي يمكن ل 10.91.2.35 (المستقبل) قبولها (نافذة الاستلام الفعالة).
• يمثل الخط الأزرق مقدار بيانات TCP قيد التشغيل حاليا من 10.93.19.8 (المرسل).

وقمم البيانات التي تم رصدها في الرحلات الجوية نحو 1 ميغابايت، مع قمم إضافية تتراوح بين 8 كيلوبايت و 5 كيلوبايت، لكنها تتركز بالدرجة الأولى بين 1 كيلوبايت و 250 كيلوبايت.

وهذا يشير إلى أنه على الرغم من أن المتلقي قادر على معالجة كميات أكبر من البيانات، فإن المرسل لا يستخدم النافذة المتاحة باستمرار.

تكوين Wireshark (بيانات في الطيران مقابل النافذة)

Statistics → TCP Streams Graphs → Throughout 

التفسير الفني

• يعلن جهاز الاستقبال (10.91.2.35) عن نافذة أكبر بكثير، مما يدل على أنه قادر على تلقي مزيد من البيانات.
• المرسل (10.93.19.8) يقلل من إستخدام النافذة المتاحة، كما هو موضح من البيانات الأقل وغير المتناسقة في قيم الطيران.
  • يمكن للمرسل بشكل مثالي الاحتفاظ بالبيانات في قيم الرحلات الجوية بشكل أقرب إلى الإطار المعلن للمستقبلين (~1 ميغابايت) لزيادة الإنتاجية إلى الحد الأقصى.
  • يؤدي عدم القدرة على الحفاظ على مستويات بيانات عالية أثناء الطيران إلى الحد بشكل مباشر من الإنتاجية وهو مؤشر قوي على عدم كفاءة بروتوكول TCP من المصدر، وليس مشكلة تتعلق بقدرة الشبكة.

تحليل حمولة TCP مقابل MSS عبر الوقت

يساعد تحليل حجم حمولة TCP مقابل MSS عبر الوقت على تحديد ما إذا كان المرسل يستخدم كل مقطع TCP بكفاءة أم لا. يتم إجراء هذا التحليل من منظور عنوان IP المصدر (10.93.19.8).

في Wireshark، يتم تكوين الرسومات البيانية كما يلي:

• الرسم البياني 1 (الحزم بحجم MSS):
  • عامل تصفية العرض: ip.src==10.93.19.8 و tcp.len == 1460
  • النمط: شريط مكدس
  • محور ص: الحزم
  • الفاصل الزمني: ثانية واحدة
• الرسم البياني 2 (كافة الحزم ≤ MSS):
  • عامل تصفية العرض: ip.src==10.93.19.8 و tcp.len <= 1460
  • النمط: شريط مكدس
  • محور ص: الحزم
  • الفاصل الزمني: ثانية واحدة
• تطبيق القياس اللوغارتمي للحصول على رؤية أفضل

من التحليل:

• تصل معظم الحزم (>10000 حزمة في الثانية) بشكل ثابت إلى قيمة MSS وهي 1460 بايت.
• يحمل جزء أصغر من الحزم حمولة أقل بسبب سلوك TCP العادي (ACKs، أو التجزئة، أو بيانات نهاية الدفق).

تحليل السبب الجذري (RCA): انخفاض أداء TCP

يوضح هذا التحليل أن تحديد السبب الجذري لمسائل أداء بروتوكول TCP يتطلب نهجا شاملا ومتكاملا، بدلا من افتراض أن الشبكة هي المصدر الرئيسي للتدهور.

تم إجراء التحقق من الصحة بشكل مكثف على المحول Cisco Nexus 9300 switch، بما في ذلك عدادات الواجهة وسياسات جودة الخدمة والتوجيه واستقرار ARP والتحقق من وحدة المعالجة المركزية (CPU) والتقاط الحزم القائم على فسحة بين دعامتين والتحقق من إعادة توجيه مستوى ASIC باستخدام ELAM. أكدت جميع النتائج بشكل ثابت أن المحول كان يعمل ضمن المعلمات المتوقعة:

• لا توجد عمليات إسقاط حزم
• لا يوجد زمن وصول غير عادي (نطاق ميكروثانية)
• لا تأثير على جودة الخدمة أو مستوى التحكم
• إعادة توجيه الأجهزة الصحيحة

بالإضافة إلى ذلك، كشف تحليل بروتوكول TCP:

• تحويلات لا تذكر (0.00125٪)
• لا يوجد دليل على فقدان الحزمة
• إستخدام MSS متناسق في المصدر
• تمت محاذاة الخرج مع نافذة TCP وقيود RTT
• عدم إستخدام نافذة TCP المتوفرة بشكل كامل (البيانات الموجودة في تحليل الرحلة)
• الشبكة ليست عنق الزجاجة
• الخادم المصدر يحد من الأداء

القرار

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

الحل

قم بزيادة وحدة الحد الأقصى للنقل (MTU) على الخادم المصدر من 1500 إلى 9000 بايت لمحاذاتها مع الوجهة والبنية الأساسية للشبكة. الفوائد:

• تمكين شرائح TCP الأكبر
• تقليل مصروفات حزم البيانات
• تحسين الإنتاجية الإجمالية

انعكاس فني

ثمة فائدة أساسية يمكن إستخلاصها من هذا التحليل وهي أهمية تجنب الاستنتاجات السابقة لأوانها عند أستكشاف أخطاء أداء الشبكة وإصلاحها. في حين أنه من الشائع في البداية عزو المشاكل إلى الشبكة، فإن هذه الحالة توضح بوضوح أن الشبكة كانت تعمل بشكل صحيح عبر مسار مستوى البيانات بالكامل. لم يكن من الممكن التعرف بدقة على الاختناقات الحقيقية إلا من خلال إجراء تحليل TCP العميق من منظوري المصدر والوجهة على حد سواء - بما في ذلك معلمات مصافحة اليد وسلوك RTT واستخدام النافذة وإعادة الإرسال وكفاءة الحمولة.

إن أخذ الوقت الكافي لتحليل سلوك بروتوكول TCP بالتفصيل يمنع التشخيص الخاطئ، ويقلل من تغييرات الشبكة غير الضرورية، ويضمن توجيه جهود الإصلاح نحو السبب الجذري الفعلي.

محفوظات المراجعة

المراجعة	تاريخ النشر	التعليقات
2.0	07-May-2026	تم تحديث العنوان لكل طلب مؤلف.
1.0	06-May-2026	الإصدار الأولي