حل مشكلات تجزئة IPv4 ووحدة الإرسال القصوى (MTU) وMSS واكتشاف مسار MTU (PMTUD) باستخدام بروتوكولَي تضمين التوجيه العام (GRE) وIPsec

المقدمة

يصف هذا المستند كيفية عمل تجزئة IPv4 و"اكتشاف الحد الأقصى لوحدة الإرسال بالمسار (PMTUD)". 

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

تمت أيضًا مناقشة السيناريوهات التي تتضمن سلوك PMTUD عند دمجها مع مجموعات مختلفة من أنفاق IPv4.

تجزئة بروتوكول IPv4 وإعادة تجميعه

رغم أن الحد الأقصى لطول مخطط بيانات IPv4 هو 65535، إلا أن معظم روابط الإرسال تفرض حدًا أقصى أقل لطول الحِزمة، يُسمى وحدة الإرسال القصوى (MTU). تعتمد قيمة وحدة الإرسال القصوى (MTU) على رابط الإرسال.

يستوعب تصميم IPv4 اختلافات MTU لأنه يسمح للموجّهات بتجزئة مخططات بيانات IPv4 حسب الضرورة.

ومحطة الاستقبال (في هذا السياق) مسؤولة عن إعادة تجميع الأجزاء في مخطط بيانات IPv4 الأصلي والكامل الحجم.

تقسّم تجزئة IPv4 مخطط بيانات إلى قِطَع يمكن إعادة تجميعها لاحقًا.

يتم استخدام حقول مصدر IPv4 والوجهة والتعريف والطول الإجمالي وإزاحة الأجزاء، جنبًا إلى جنب مع علامتي "المزيد من الأجزاء" (MF) و"عدم التجزئة" (DF) في عنوان IPv4 الرئيسي، لتجزئة برتوكول IPv4 وإعادة تجميعه.

لمزيد من المعلومات حول آليات تجزئة IPv4 وإعادة تجميعه، اطّلع على RFC 791.

تشرح هذه الصورة تخطيط عنوان IPv4 رئيسي.

يكون التعريف بحجم 16 بت وهي قيمة يتم تعيينها من قِبل مُرسِل مخطط بيانات IPv4. وهذا يساعد في إعادة تجميع أجزاء مخطط البيانات.

تكون إزاحة التجزئة 13 بت وتشير إلى المكان حيث تنتمي تجزئة في مخطط بيانات IPv4 الأصلي. هذه القيمة من مضاعفات 8 بايت.

توجد 3 وحدات بِت لعلامات التحكُّم في حقل إشارات عنوان IPv4 الرئيسي. تحدّد وحدة البِت "عدم التجزئة" (DF) ما إذا كان مسموحًا بتجزئة الحِزمة أم لا.

يتم حجز وحدة البت 0 ويتم تعيينها دائمًا على 0.

وحدة البت 1 هي وحدة البت عدم التجزئة (DF) (0 = "can fragment", 1 = "do not fragment").

البت 2 هو وحدة بت الأجزاء الإضافية (MF)(0 = "last fragment," 1 = "more fragments").

في حال إضافة أطوال أجزاء IPv4، ستتجاوز القيمة الطول الأصلي لمخطط بيانات IPv4 بمقدار 60.

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

يحتوي الجزء الأول على إزاحة مقدارها 0، وطول هذا الجزء هو 1500؛ ويتضمن ذلك 20 بايت لرأس IPv4 الأصلي الذي تم تعديله بشكل طفيف.

والجزء الثاني له تعويض قدره 185 (185 × 8 = 1480)؛ يبدأ جزء البيانات الخاص بهذا الجزء من 1480 بايت في مخطط بيانات IPv4 الأصلي.

ويبلغ طول هذا الجزء 1500؛ ويتضمن ذلك رأس IPv4 الإضافي الذي تم إنشاؤه لهذا الجزء.

والجزء الثالث له تعويض قدره 370 (370 × 8 = 2960)؛ يبدأ جزء البيانات الخاص بهذا الجزء من 2960 بايت في مخطط بيانات IPv4 الأصلي.

ويبلغ طول هذا الجزء 1500؛ ويتضمن ذلك رأس IPv4 الإضافي الذي تم إنشاؤه لهذا الجزء.

يحتوي المقطع الرابع على إزاحة قدرها 555 (555 × 8 = 4440)، مما يعني أن جزء البيانات من هذا المقطع يبدأ بمقدار 4440 بايت في مخطط بيانات IPv4 الأصلي.

يبلغ طول هذا الجزء 700 بايت؛ ويتضمن ذلك رأس IPv4 الإضافي الذي تم إنشاؤه لهذا الجزء.

لا يمكن تحديد حجم مخطط بيانات IPv4 الأصلي إلا عند استلام المقطع الأخير.

تمنح إزاحة المقطع في المقطع الأخير (555) إزاحة بيانات قدرها 4440 بايت في مخطط بيانات IPv4 الأصلي.

مجموع وحدات البايت للبيانات من الجزء الأخير (680 = 700 - 20) يعطي 5120 بايت، وهي حصة البيانات من مخطط بيانات IPv4 الأصلي.

إضافة 20 بايت لعنوان IPv4 الرئيسي يساوي حجم مخطط بيانات IPv4 الأصلي (4440 + 680 + 20 = 5140) كما هو موضّح في الصور.

المشكلات المتعلقة بتجزئة بروتوكول IPv4

تتسبب تجزئة IPv4 في زيادة بسيطة في أعباء وحدة المعالجة المركزية (CPU) والذاكرة لتجزئة مخطط بيانات IPv4. وينطبق هذا على المرسِل وكذلك على موجّه في المسار ما بين مرسِل ومستلم.

ينطوي إنشاء الأجزاء على إنشاء عناوين رئيسية للأجزاء وينسخ مخطط البيانات الأصلي إلى الأجزاء.

وهذا يتم بشكل فعّال لأن المعلومات اللازمة لإنشاء الأجزاء متاحة في الحال.

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

لا تعتبر إعادة التجميع على مُضيف مشكلة لأن المُضيف لديه موارد الوقت والذاكرة المطلوب تخصيصها لهذه المهمة.

ومع ذلك، فإعادة التجميع غير فعّالة على موجّه تتمثل مهمته الأساسية في إعادة توجيه الحِزم في أسرع وقت ممكن.

والموجّه غير مصمم للاحتفاظ بالحِزم وقتًا مطولاً.

فالموجّه الذي يقوم بإعادة التجميع يختار أكبر وحدة تخزين مؤقت متاحة (18K)، لأنه لا توجد لديه طريقة لتحديد حجم حِزمة IPv4 الأصلية إلى أن يتم استلام الجزء الأخير.

تتمثل مشكلة أخرى للتجزئة في كيفية معالجة المقاطع التي تم إسقاطها.

إذا تم إسقاط مقطع واحد من مخطط بيانات IPv4، فيجب حينئذ أن يكون مخطط بيانات IPv4 الأصلي بالكامل موجودًا، وستتم تجزئته أيضًا.

ويُرى ذلك مع نظام ملفات الشبكة (NFS). حجم كتلة القراءة والكتابة في نظام ملفات الشبكة (NFS) يبلغ 8192. 

لذلك، يبلغ حجم مخطط بيانات UDP‏/IPv4 في نظام ملفات الشبكة (NFS) حوالي 8500 بايت (تشمل عناوين NFS وUDP وIPv4 الرئيسية).

يتعين على محطة الإرسال المتصلة بشبكة إيثرنت (MTU 1500) تجزئة مخطط البيانات سعة 8500 بايت إلى ستة (6) قطع؛ خمسة (5) أجزاء سعة 1500 بايت وجزء (1) سعة 1100 بايت.

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

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

قد تواجه جدران الحماية التي تقوم بتصفية الحِزم أو التعامل معها استنادًا إلى معلومات الطبقة 4 (L4) حتى الطبقة 7 (L7) مشكلةً في معالجة أجزاء IPv4 بطريقة صحيحة.

إذا كانت أجزاء IPv4 غير مُرتَّبة، فقد تحظر جدران الحماية الأجزاء غير الأولية لأنها لا تحمل المعلومات التي تتوافق مع عامل تصفية الحِزم.

وهذا يعني أنه قد تتعذر إعادة تجميع مخطط بيانات IPv4 الأصلي من قِبل المُضيف المستلِم.

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

تعمل أجهزة الشبكة مثل "محركات تبديل المحتوى" على توجيه الحِزم استنادًا إلى المعلومات من L4 إلى L7، وإذا كانت إحدى الحِزم تمتد عبر أجزاء متعددة، فقد يواجه الجهاز مشكلة في فرض سياساته.

تجنب تجزئة IPv4: كيفية عمل TCP MSS

يحدّد الحد الأقصى لحجم الجزء (MSS) لبروتوكول التحكم في الإرسال (TCP) الحد الأقصى لحجم البيانات التي يقبلها المُضيف في مخطط بيانات TCP‏/IPv4 واحد.

من المحتمَل أن تتم تجزئة مخطط بيانات TCP‏/IPv4 هذا في طبقة IPv4. لا يتم إرسال قيمة MSS كخيار عنوان TCP رئيسي إلا في عمليات تجزئة TCP SYN.

يقوم كل جانب من جوانب اتصال TCP بإبلاغ قيمة MSS الخاصة به إلى الجانب الآخر. قيمة MSS لا يتم التفاوض عليها بين الأجهزة المُضيفة.

يتطلب من المضيف المرسِل الحد من حجم البيانات في تجزئة TCP واحدة إلى قيمة أقل من قيمة MSS التي أبلغ عنها المضيف المستلِم أو مساوية لها.

في الأصل، كان MSS يعني مدى حجم وحدة تخزين مؤقت (أكبر من أو يساوي 65496 بايت) تم تخصيصها على محطة استقبال لتتمكن من تخزين بيانات TCP الموجودة في مخطط بيانات IPv4 واحد.

كان MSS يمثل الحد الأقصى لجزء البيانات الذي كان جهاز استقبال TCP مستعدًا لقبوله. قد يكون جزء TCP هذا كبيرًا بحجم يصل إلى 64K ويمكن تجزئته في طبقة IPv4 ليتم إرساله إلى المُضيف المستلِم.

سيقوم المضيف المستلِم بإعادة تجميع مخطط بيانات IPv4 قبل تسليم تجزئة TCP الكامل إلى طبقة TCP.

كيف يتم تعيين قيم MSS واستخدامها لتحديد أحجام أجزاء TCP ومخططات بيانات IPv4.

يوضّح المثال 1 الطريقة التي تم بها تنفيذ MSS لأول مرة.

يحتوي المضيف A على وحدة تخزين مؤقت قدرها 16 كيلو بايت والمضيف B على وحدة تخزين مؤقت قدرها 8 كيلو بايت. ويقومان بإرسال قيم MSS الخاصة بهم واستلامها وضبط قيم MSS المرسلة الخاصة بهم لإرسال البيانات إلى بعضهم البعض.

يتعين على المُضيف A والمُضيف B تجزئة مخططات بيانات IPv4 الأكبر من حجم MTU للواجهة، ولكنها أقل من قيمة MSS للإرسال لأن مجموعة TCP تمرّر 16 كيلو بايت أو 8 كيلو بايت من البيانات عبر المجموعة إلى IPv4.

في حالة المُضيف B، تتم تجزئة الحِزم للوصول إلى شبكة LAN لحلقة الرمز المميز ومرة أخرى للوصول إلى شبكة LAN للإيثرنت.

مثال 1

1. يرسل المضيف A قيمة MSS الخاصة به البالغة 16 كيلو بايت إلى المضيف B.
2. يستلم المضيف B قيمة MSS البالغة 16 كيلو بايت من المضيف A.
3. يقوم المضيف B بتعيين قيمة MSS الخاصة به المرسلة إلى 16 كيلو بايت.
4. يرسل المضيف B قيمة MSS الخاصة به البالغة 8 كيلو بايت إلى المضيف A.
5. يستلم المضيف A قيمة MSS البالغة 8 كيلو بايت من المضيف B.
6. يقوم المضيف A بتعيين قيمة MSS الخاصة به المرسلة إلى 8 كيلو بايت.

للمساعدة على تجنُّب تجزئة IPv4 عند الأجهزة الطرفية لاتصال TCP، تم تغيير تحديد قيمة MSS إلى الحد الأدنى لحجم وحدة التخزين المؤقت ووحدة الحد الأقصى للإرسال (MTU) الخاصة بواجهة الإرسال (- 40).

أرقام MSS أصغر بمقدار 40 بايت من أرقام MTU لأن MSS (حجم بيانات TCP) لا يشمل عنوان IPv4 الرئيسي بحجم 20 بايت وعنوان TCP الرئيسي بحجم 20 بايت.

يعتمد MSS على أحجام الرؤوس الافتراضية؛ يجب على مكدس المرسلين طرح القيم المناسبة لرأس IPv4 ويعتمد رأس TCP على خيارات TCP أو IPv4 المستخدمة.

ويعمل MSS حاليًا بأسلوب من خلاله يقارن كل مُضيف أولاً MTU الخاصة بواجهة الإرسال الخاصة به مع وحدة التخزين المؤقت الخاصة به ويختار القيمة الأدنى كقيمة MSS للإرسال.

ستقوم الأجهزة المضيفة بعد ذلك بمقارنة حجم MSS المستلَم مقابل MTU للواجهة الخاصة بها وستختار مرة أخرى القيمة الأدنى من بين القيمتَين.

المثال 2 يوضّح هذه الخطوة الإضافية التي يتخذها المرسِل لتجنب التجزئة على الشبكات السلكية المحلية والبعيدة.

تؤخَذ MTU الخاصة بالواجهة الصادرة في اعتبار كل مُضيف (قبل أن ترسل الأجهزة المُضيفة قيم MSS الخاصة بها لبعضها البعض. وهذا يساعد على تجنب التجزئة.

مثال 2

1. يقارن المضيف A بين وحدة التخزين المؤقت للحد الأقصى لحجم المقطع (MSS) (16 كيلو بايت) الخاصة به وبين وحدة الحد الأقصى للإرسال (MTU) الخاصة به (1500 - 40 = 1460) ويستخدم القيمة الأدنى كـ MSS (1460) لإرسالها إلى المضيف B.
2. يستلِم المُضيف B قيمة MSS للإرسال (1460) من المُضيف A ويقارنها بقيمة MTU للواجهة الصادرة الخاصة به - 40 (4422).
3. يقوم المضيف B بتعيين القيمة الأدنى (1460) كـ MSS لإرسال مخططات بيانات IPv4 إلى المضيف A.
4. يقارن المضيف B بين وحدة التخزين المؤقت للحد الأقصى لحجم المقطع (MSS) الخاصة به (8 كيلو بايت) وبين وحدة الحد الأقصى للإرسال (MTU) الخاصة به (4462-40 = 4422) ويستخدم 4422 كـ MSS لإرسالها إلى المضيف A.
5. يستلِم المُضيف A قيمة MSS للإرسال (4422) من المُضيف B ويقارنها بقيمة MTU للواجهة الصادرة الخاصة به - 40 (1460).
6. يقوم المضيف A بتعيين القيمة الأدنى (1460) كـ MSS لإرسال مخططات بيانات IPv4 إلى المضيف B.

1460 هي القيمة المختارة من كلا المضيفَين كقيمة MSS المرسلة لبعضهما البعض. غالبًا، ما تكون قيمة MSS للإرسال هي نفسها في كل نهاية اتصال TCP.

في المثال 2، لا تحدث التجزئة في الأجهزة الطرفية لاتصال TCP نظرًا لأن الأجهزة المُضيفة تأخذ في الاعتبار كلتا وحدتَي MTU للواجهة الصادرة.

ما يزال من الممكن أن تصبح الحِزم مجزّأة في الشبكة بين الموجّه A والموجّه B إذا واجهت رابطًا بقيمة MTU أدنى من تلك الخاصة بالواجهة الصادرة لأيّ من المُضيفَين.

ماهية تقنية اكتشاف مسار وحدة الإرسال القصوى (PMTUD)

يعالِج MSS الخاص ببروتوكول TCP التجزئة عند الجهازين الطرفيين لاتصال TCP، لكنه لا يتعامل مع الحالات التي يوجد فيها رابط MTU أصغر في المنتصف بين هذين الجهازَين الطرفيَين.

وقد تم تطوير PMTUD لتجنُّب التجزئة في المسار بين الأجهزة الطرفية. حيث يتم استخدامه لتحديد قيمة MTU الأدنى ديناميكيًا على طول المسار من مصدر الحِزمة إلى وجهتها.

ملاحظة: يتم دعم PMTUD بواسطة TCP و UDP فقط. أما البروتوكولات الأخرى فلا تدعمها. في حال تم تمكين PMTUD على مُضيف، سيتم تعيين وحدة البت DF لجميع حِزم TCP وUDP الواردة من المُضيف. 

عندما يرسل مضيف حِزمة بيانات MSS كاملة بإعداد وحدة البت DF، تعمل PMTUD على تقليل قيمة MSS المرسلة للاتصال إذا استلمت معلومات تفيد بأن الحِزمة تتطلب التجزئة.

يسجّل المضيف قيمة MTU الخاصة بوجهة ما نظرًا لأنه يقوم بإنشاء إدخال "مُضيف" (/32) في جدول التوجيه الخاص به باستخدام قيمة MTU هذه.

إذا حاول الموجّه إعادة توجيه مخطط بيانات IPv4 (مع تعيين وحدة البت DF) إلى رابط بقيمة MTU أقل من حجم الحِزمة، فسيُسقط الموجّه الحِزمة ويرجع برسالة "يتعذّر الوصول إلى الوجهة" لبروتوكول رسائل التحكُّم في الإنترنت (ICMP) إلى مصدر مخطط بيانات IPv4 مع الكود الذي يشير إلى "تعيين علامة التجزئة مطلوبة وعلامة DF" (النوع 3، الكود 4).

عندما تستلم محطة المصدر رسالة ICMP، ستقلّل قيمة MSS للإرسال، وعندما يُعيد TCP إرسال المقطع، سيستخدم حجم المقطع الأصغر.

إليك فيما يلي مثال على رسالة "تعيين علامة التجزئة مطلوبة وعلامة DF" لبروتوكول ICMP التي قد تراها على موجّه بعد تشغيل الأمر:debug ip icmp

ICMP: dst (10.10.10.10) frag. needed and DF set 
unreachable sent to 10.1.1.1

يوضّح هذا المخطط تنسيق عنوان ICMP الرئيسي لرسالة "التجزئة مطلوبة وإعداد DF" "تعذّر الوصول إلى الوجهة".

وفقًا لـ RFC 1191، يتعين أن يتضمن الموجّه الذي يُعيد رسالة ICMP التي تشير إلى أن "التجزئة مطلوبة وإعداد DF" على وحدة الحد الأقصى للإرسال (MTU) الخاصة بشبكة الخطوة التالية في 16 وحدة بت ذات الترتيب المنخفض من حقل عنوان ICMP الرئيسي الإضافي المُسمى "غير مستخدم" في مواصفات ICMP ‪RFC 792‬.

لم توفر عمليات تنفيذ RFC 1191 المبكرة معلومات MTU للخطوة التالية. وحتى عندما توفرت هذه المعلومات، تجاهلتها بعض الأجهزة المضيفة.

بالنسبة إلى هذه الحالة، يحتوي RFC 1191 أيضًا على جدول يسرد القيم المقترَحة التي يجب تقليل قيمة MTU على أساسها طوال تقنية PMTUD.

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

يتم تنفيذ PMTUD باستمرار على جميع الحِزم لأن المسار بين المرسِل والمستلِم يمكن أن يتغير ديناميكيًا.

في كل مرة يستلِم فيها المرسِل رسائل ICMP بعنوان "تعذّرت التجزئة"، سيقوم بتحديث معلومات التوجيه (حيث يقوم بتخزين PMTUD).

يمكن أن يحدث شيئان محتملان أثناء PMTUD:

1. من الممكن وصول الحِزمة إلى المستلم دون تجزئة.

ملاحظة: من أجل أن يحمي الموجه وحدة المعالجة المركزية من هجمات رفض الخدمة (DoS)، يكبح عدد رسائل ICMP الذي يتعذر الوصول إليه التي كان سيقوم بإرسالها، إلى رسالتين في الثانية. لذلك، في هذا السياق، إذا كان لديك سيناريو شبكة تتوقع فيه أن الموجّه سيتعين عليه أن يستجيب بأكثر من رسالتَي ICMP (النوع = 3، الكود = 4) في الثانية الواحدة (قد تكون الأجهزة المُضيفة مختلفة)، فعليك تعطيل خفض رسائل ICMP باستخدام الأمر .no ip icmp rate-limit unreachable [df] interface

2. يتلقى المرسِل رسائل ICMP بعنوان "تتعذّر التجزئة" من الخطوات بطول المسار إلى المستلِم.

يتم تنفيذ PMTUD بشكل مستقل لكلا الاتجاهين لتدفق TCP.

هناك حالات تقوم فيها تقنية PMTUD في اتجاه واحد لتدفق ما بتشغيل إحدى المحطات الطرفية لخفض قيمة MSS للإرسال بينما تحافظ المحطة الطرفية الأخرى على قيمة MSS للإرسال الأصلية لأنها لم ترسل مطلقًا مخطط بيانات IPv4 كبيرًا بما يكفي لتشغيل PMTUD.

والمثال على ذلك هو اتصال HTTP الموضح في المثال 3. يرسل عميل TCP حزم صغيرة ويرسل الخادم حزم كبيرة.

في هذه الحالة، لن يقوم بتشغيل PMTUD إلا الحِزم الكبيرة (الأكبر من 576 بايت) من الخادم.

تكون الحِزم من العميل صغيرة (أقل من 576 بايت) ولن تقوم بتشغيل PMTUD لأنها لا تتطلب التجزئة لتتمكّن من عبور رابط ‪576 MTU‬.

مثال 3

يوضّح المثال 4 مثالاً للتوجيه غير المتماثل حيث يقل الحد الأدنى لقيمة MTU لأحد المسارات عن الآخر.

يحدث التوجيه غير المتماثل عندما يتم اتخاذ مسارات مختلفة لإرسال البيانات واستلامها بين جهازين طرفيين.

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

تتدفق حركة مرور البيانات من عميل TCP إلى الخادم عبر الموجّه A والموجّه B، بينما تتدفق حركة مرور البيانات العائدة من الخادم إلى العميل عبر الموجّه D والموجّه C.

عندما يرسل خادم TCP حِزمًا إلى العميل، تقوم تقنية اكتشاف مسار وحدة الإرسال القصوى (PMTUD) بتشغيل الخادم لتقليل الحد الأقصى لحجم المقطع (MSS) للإرسال لأنه يتعين على الموجّه D تجزئة الحِزم بحجم 4092 بايت قبل أن يتمكن من إرسالها إلى الموجّه C.

وعلى الجانب الآخر، لن يستلم العميل أبدًا رسالة ICMP "تعذّر الوصول إلى الوجهة" مع الكود تشير إلى "تعيين علامة التجزئة مطلوبة وعلامة DF" لأن الموجّه A لا يتعين عليه تجزئة الحِزم عند إرسالها إلى الخادم عبر الموجّه B.

مثال 4

ملاحظة: يتم إستخدام الأمر ip tcp path-mtu-discovery من أجل تمكين اكتشاف مسار TCP MTU لاتصالات TCP التي تم بدؤها بواسطة الموجهات (BGP و Telnet على سبيل المثال).

المشكلات المتعلقة بتقنية اكتشاف مسار وحدة الإرسال القصوى (PMTUD)

هذه هي الأشياء التي يمكن أن تعطّل PMTUD.

• يمكن للموجّه إسقاط حِزمة وعدم إرسال رسالة ICMP. (غير شائع)

• يُنشئ الموجّه رسالة ICMP ويرسلها، ولكن يتم حظر رسالة ICMP من قِبل موجّه أو جدار حماية بين هذا الموجّه والمرسِل. (شائع)

• يُنشئ الموجّه رسالة ICMP ويُرسلها، لكن يتجاهلها المرسِل. (غير شائع)

التعدادان النقطيان الأول والأخير هنا عادةً ما يكونان ناتجَين عن خطأ، ولكن التعداد النقطي الأوسط يصف مشكلة شائعة.

يميل أولئك الذين يقومون بتنفيذ عوامل تصفية حِزم ICMP إلى حظر جميع أنواع رسائل ICMP بدلاً من حظر أنواع معينة فقط من رسائل ICMP.

من المحتمَل أن يقوم عامل تصفية الحِزمة بحظر جميع أنواع رسائل ICMP باستثناء تلك التي مفادها "يتعذّر الوصول" أو "تم تجاوز الوقت".

يتوقف نجاح أو فشل PMTUD على وصول رسائل ICMP "يتعذّر الوصول" إلى مرسل حِزمة TCP‏/IPv4.

تُعد رسائل ICMP "تم تجاوز الوقت" مهمة لمشكلات IPv4 الأخرى.

وفيما يلي مثال لعامل تصفية الحِزمة هذا، الذي تم تنفيذه على موجّه.

access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 deny icmp any any
access-list 101 permit ip any any

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

• امسح وحدة البت DF على الموجّه واسمح بالتجزئة. (ومع ذلك، فهذه ليست فكرة جيدة. للحصول على مزيد من المعلومات اطّلع على المشكلات المتعلقة بتجزئة IP).

• قم بمعالجة الحد الأقصى لحجم المقطع (MSS) لقيمة خيار TCP MSS باستخدام أمر الواجهة .ip tcp adjust-mss <500-1460>

في المثال التالي، الموجّه A والموجّه B موجودان في نفس المجال الإداري. يتعذّر الوصول إلى الموجّه C ويحظر ICMP، لذا يتم تعطيل تقنية اكتشاف مسار وحدة الإرسال القصوى (PMTUD).

الحل البديل لهذه الحالة هو مسح وحدة بت DF في كلا الاتجاهين على الموجّه B للسماح بالتجزئة. ويمكن تنفيذ ذلك من خلال توجيه السياسة.

تتوفر الصياغة لمسح وحدة بت DF في برنامج Cisco IOS®، الإصدار 12.1(6) والإصدارات اللاحقة.

interface serial0 
... 
ip policy route-map clear-df-bit 
route-map clear-df-bit permit 10 
	match ip address 111 
	set ip df 0 
 
access-list 111 permit tcp any any

وهناك خيار آخر وهو تغيير قيمة خيار TCP MSS على حِزم بروتوكول المزامنة (SYN) التي تجتاز الموجّه (تتوفر في برنامج Cisco IOS®، الإصدار 12.2(4)T والإصدارات اللاحقة).

وهذا يقلّل من قيمة خيار MSS في حِزمة TCP SYN بحيث تكون أصغر من القيمة (1460) في الأمر.ip tcp adjust-mss

وستكون النتيجة أن مرسِل TCP يرسل مقاطع لا يزيد حجمها عن هذه القيمة.

ويكون حجم حزمة IPv4 أكبر بمقدار 40 بايت (1500) عن قيمة MSS (1460 بايت) لحساب عنوان TCP الرئيسي (20 بايت) وعنوان IPv4 الرئيسي (20 بايت).

يمكنك ضبط الحد الأقصى لحجم المقطع (MSS) لحِزم TCP SYN باستخدام الأمر.ip tcp adjust-mss ستقلّل هذه الصياغة من قيمة MSS على مقاطع TCP إلى 1460.

يؤثر هذا الأمر على حركة مرور البيانات الواردة والصادرة على الواجهة serial0.

int s0 
ip tcp adjust-mss 1460

لقد أصبحت مشكلات تجزئة IPv4 أكثر انتشارًا منذ أن أصبحت أنفاق IPv4 منتشرة على نطاق أوسع.

تتسبب الأنفاق في المزيد من التجزئة لأن تضمين النفق يضيف "عبئًا" على حجم الحِزمة.

على سبيل المثال، تؤدي إضافة "تضمين الموجه العام (GRE)" إلى إضافة 24 بايت إلى الحِزمة، وبعد هذه الزيادة، قد تحتاج الحِزمة إلى التجزئة لأنها أكبر من وحدة الحد الأقصى للإرسال (MTU) الصادرة.

هياكل الشبكة الشائعة التي تحتاج إلى تقنية اكتشاف مسار وحدة الإرسال القصوى (PMTUD)

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

• الأجهزة المضيفة الطرفية المتصلة ببروتوكول الحلقة الرمزية (Token Ring) (أو الواجهة البينية للبيانات الموزعة بالألياف (FDDI)) باستخدام اتصال إيثرنت فيما بينها. حيث تكون وحدات MTU الطرفية لبروتوكول الحلقة الرمزية (Token Ring) (أو FDDI) أكبر من وحدة MTU الإيثرنت في المنتصف.

• يحتاج بروتوكول النقطة إلى النقطة عبر إيثرنت (PPPoE) (يستخدم عادة مع ADSL) إلى 8 بايت للعنوان الرئيسي الخاص به. وهذا يقلّل من وحدة الحد الأقصى للإرسال (MTU) الفعّالة للإيثرنت إلى 1492 بايت (1500 - 8).

كما تحتاج البروتوكولات النفقية مثل GRE وIPv4sec وL2TP إلى مساحة للعناوين الرئيسية والتذييلات المقابلة لكل منها. وهذا يقلّل أيضًا من وحدة الحد الأقصى للإرسال (MTU) الفعّالة لواجهة الإرسال.

قناة الاتصال

تُعد قناة الاتصال بمثابة واجهة منطقية على موجّه Cisco يوفر طريقة لتضمين حِزم بروتوكول المسافر داخل بروتوكول نقل.

فهي بنية مصمَّمة لتوفير الخدمات لتنفيذ نظام تضمين اتصال من نقطة إلى نقطة. تتضمن واجهات الأنفاق المكونات الأساسية الثلاثة التالية:

• بروتوكول المسافر (AppleTalk أو Banyan VINES أو CLNS أو DECnet أو IPv4 أو IPX)

• بروتوكول الناقل - أحد بروتوكولات التضمين هذه:

  • GRE - بروتوكول ناقل متعدد البروتوكولات من Cisco. اطّلع على RFC 2784 وRFC 1701  للحصول على مزيد من المعلومات.

  • IPv4 في أنفاق IPv4 - اطّلع على RFC 2003  للحصول على مزيد من المعلومات.

• بروتوكول النقل - وهو البروتوكول المُستخدم لحمل البروتوكول المُتضمَّن.

توضّح الحِزم المعروضة في هذا القسم مفاهيم اتصال IPv4 النفقي حيث GRE هو بروتوكول التضمين وIPv4 هو بروتوكول النقل.

بروتوكول الركاب هو أيضا IPv4. في هذه الحالة، IPv4 هو كل من بروتوكول النقل والركاب.

الحِزمة العادية

حِزمة النفق

• IPv4 بمثابة بروتوكول النقل.

• GRE بمثابة بروتوكول التضمين.

• IPv4 بمثابة بروتوكول المسافر.

يوضّح المثال التالي تضمين IPv4 وDECnet كبروتوكولَي مسافر مع GRE كبروتوكول الناقل.

وهذا يوضّح احتمالية أن بروتوكولات الناقل تقوم بتضمين بروتوكولات مسافر متعددة كما هو موضّح في الصورة.

قد يفكّر مسؤول شبكة في الاتصال النفقي في حالة وجود شبكتين بخلاف IPv4 غير متقاربتَين يفصلهما جزء IPv4 أساسي.

إذا كانت الشبكتان غير المتقاربتَين تقومان بتشغيل بروتوكول DECnet، فقد لا يرغب المسؤول في توصيلهما معًا من خلال تكوين DECnet في جزء الشبكة الأساسي.

وقد لا يرغب المسؤول في السماح بتوجيه DECnet لاستهلاك عرض النطاق الترددي للجزء الأساسي لأن هذا قد يتداخل مع أداء شبكة IPv4.

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

يوفر تضمين حركة مرور البيانات داخل بروتوكول آخر المزايا التالية:

• تستخدم الأجهزة الطرفية عناوين خاصة (RFC 1918) ولا تدعم جزء الشبكة الرئيسي توجيه هذه العناوين.

• اسمح بالشبكات الافتراضية الخاصة (VPN) عبر شبكات WAN أو الإنترنت.

• انضم معنا إلى الشبكات متعددة البروتوكولات غير المتقاربة عبر جزء شبكة رئيسي ذي بروتوكول فردي.

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

من الآن فصاعدًا، يتم استخدام IPv4 بصفته بروتوكول المسافر وIPv4 بصفته بروتوكول النقل.

الاعتبارات المتعلقة بواجهات الأنفاق

فيما يلي الاعتبارات أثناء الاتصال النفقي.

• تم طرح التبديل السريع لأنفاق GRE في برنامج Cisco IOS®، الإصدار 11.1 وتم طرح تبديل CEF في الإصدار 12.0.

• تم طرح تبديل CEF لأنفاق GRE متعددة النقاط في الإصدار 12.2(8)T.

• بينما كان كل من التضمين أو إلغاء التضمين في أجهزة النفق الطرفية بطيئين في الإصدارات السابقة من Cisco IOS ® بحيث كان يتم دعم تبديل العمليات فقط.

• تحدث مشكلات في الأمان والهيكل أثناء حِزم الاتصال النفقي. حيث يمكن للأنفاق تجاوز قوائم التحكم في الوصول (ACL) وجدران الحماية.

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

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

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

• يمكن للأنفاق من نقطة إلى نقطة استهلاك عرض النطاق الترددي على رابط مادي. عبر الأنفاق المتعددة من نقطة إلى نقطة، يوجد عرض نطاق ترددي لكل واجهة نفق وعرض نطاق ترددي لتلك الواجهة المادية التي يجري تشغيل النفق عبرها. على سبيل المثال، قُم بتعيين عرض النطاق الترددي للنفق على 100 كيلوبِت في حال وجود 100 نفق تعمل عبر رابط بسرعة 10 ميجابِت. عرض النطاق الترددي الافتراضي لنفق هو 9 كيلوبايت.

• قد تُفضّل بروتوكولات التوجيه نفقًا عبر رابط حقيقي لأن النفق يبدو بشكل مخادع رابطًا بخطوة واحدة بالمسار الأقل تكلفة، على الرغم من أنه يتضمن بالفعل المزيد من الخطوات ولذلك فهو أكثر تكلفة من مسار آخر. ويتم الحد من ذلك من خلال التكوين المناسب لبروتوكول التوجيه. فكِّر في تشغيل بروتوكول توجيه مختلف عبر واجهة النفق أفضل من بروتوكول التوجيه الذي يعمل على الواجهة المادية.

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

  %TUN-RECURDOWN Interface Tunnel 0
  temporarily disabled due to recursive routing

الموجّه كمشارك تقنية PMTUD في الجهاز الطرفي للنفق

للموجّه دوران مختلفان في تقنية PMTUD يقوم بهما عندما يكون هو الجهاز الطرفي لنفق.

• في الدور الأول، يكون الموجّه بمثابة جهاز إعادة توجيه لحِزمة مضيف. فيما يتعلق بمعالجة PMTUD، يحتاج الموجّه إلى التحقق من وحدة بت DF وحجم حِزمة البيانات الأصلية واتخاذ الإجراء المناسب عند الضرورة.

• ويحين الدور الثاني بعد تضمين الموجّه لحِزمة IPv4 الأصلية داخل حِزمة النفق. في هذه المرحلة، يعمل الموجّه بشكل أشبه كجهاز مضيف فيما يتعلق بتقنية PMTUD وفيما يتعلق بحِزمة النفق IPv4.

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

إذا شارك الموجّه كجهاز إعادة التوجيه لحِزمة جهاز مضيف، فسيقوم بإتمام الإجراءات التالية:

• التحقق مما إذا تم تعيين وحدة البِت DF

• التحقق من حجم الحِزمة التي يمكن أن يستوعبها النفق.

• التجزئة (إذا كانت الحزمة كبيرة جدا ولم يتم تعيين بت DF)، قم بتضمين الأجزاء وإرسالها؛  أو

• إسقاط الحِزمة (إذا كانت الحِزمة كبيرة للغاية ويتم تعيين وحدة البت DF) وإرسال رسالة ICMP إلى المرسِل.

• التضمين (إذا لم تكن الحِزمة كبيرة للغاية) والإرسال.

بشكل عام، هناك خيار للتضمين ثم التجزئة (إرسال مقطعي تضمين) أو التجزئة ثم التضمين (إرسال مقطعي مضمّنَين).

فيما يلي مُفصَّل في هذا القسم مثالان يعرضان تفاعل PMTUD والحِزم التي تجتاز الشبكات المعروضة كمثال.

يوضّح المثال الأول ما يحدث لحِزمة عندما يقوم الموجّه (عند مصدر النفق) بدور موجّه إعادة التوجيه.

لمعالجة PMTUD، يحتاج الموجّه إلى التحقق من وحدة البت DF وحجم الحِزمة لحِزمة البيانات الأصلية واتخاذ الإجراء المناسب.

تستخدم هذه الأمثلة تضمين GRE للنفق. يقوم GRE بالتجزئة قبل التضمين.

وتوضّح الأمثلة التالية السيناريوهات حيث يتم تنفيذ التجزئة بعد التضمين.

في المثال 1، لم يتم تعيين وحدة بت DF (DF = 0) وIPv4 MTU لنفق GRE هي 1476 (1500 - 24).

مثال 1

1. يستلم موجّه إعادة التوجيه (عند مصدر النفق) مخطط بيانات بحجم 1500 بايت مع مسح وحدة البت DF (DF = 0) من المضيف المرسِل.

يتكون مخطط البيانات هذا من عنوان IP رئيسي بحجم 20 بايت بالإضافة إلى حمولة TCP بحجم 1480 بايت.

 2. نظرًا لأن الحِزمة كبيرة للغاية بالنسبة إلى وحدة MTU الخاصة بـ IPv4 بعد إضافة عبء GRE (24 بايت)، يقسّم موجّه إعادة التوجيه مخطط البيانات إلى جزأين بحجم 1476 بايت (عنوان IPv4 الرئيسي بحجم 20 بايت + حمولة IPv4 بحجم 1456 بايت) وحجم 44 بايت (20 بايت لعنوان IPv4 الرئيسي + 24 بايت لحمولة IPv4)

بعد إضافة تضمين GRE، لا تكون الحزمة أكبر من MTU للواجهة المادية للإرسال.

 3. يضيف موجّه إعادة التوجيه تضمين GRE، والذي يتضمن عنوان GRE رئيسي بحجم 4 بايت بالإضافة إلى عنوان IPv4 رئيسي بحجم 20 بايت، إلى كل جزء من مخطط بيانات IPv4 الأصلي.

ويبلغ طول مخططي بيانات IPv4 الآن 1500 و68 بايت، ويُنظر إلى مخططات البيانات هذه على أنها مخططات بيانات IPv4 فردية، وليس كمقاطع.

4. يزيل موجّه وجهة النفق تضمين GRE من كل مقطع من مخطط البيانات الأصلي، مما يترك مقطعي IPv4 يبلغ طولهما 1476 و24 بايت.

وتتم إعادة توجيه مقاطع مخطط بيانات IPv4 هذه بشكل منفصل بواسطة هذا الموجّه إلى المضيف المستلم.

5. يعيد المضيف المستلم إعادة تجميع هذين المقطعين إلى مخطط البيانات الأصلي.

يصف المثال 2 دور موجّه إعادة التوجيه في سياق هيكل شبكة.

يلعب الموجّه نفس دور موجّه إعادة التوجيه، لكن هذه المرة يتم تعيين وحدة البِت DF ‏(DF = 1).

مثال 2

1. يستلم موجّه إعادة التوجيه عند مصدر النفق مخطط بيانات بحجم 1500 بايت مع وحدة البت DF = 1 من المضيف المرسِل.

2. نظرًا لتعيين وحدة البت DF، ولأنّ حجم مخطط البيانات (1500 بايت) أكبر من وحدة MTU الخاصة بـ IPv4 لنفق GRE (1476 بايت)، سيقوم الموجّه بإسقاط مخطط البيانات وإرسال رسالة ICMP بعنوان "تجزئة ICMP مطلوبة لكن تم تعيين وحدة البت DF" إلى مصدر مخطط البيانات.

تقوم رسالة ICMP بتنبيه المرسِل إلى أن قيمة MTU هي 1476.

3. يستلم المضيف المرسِل رسالة ICMP، وعندما يقوم بإعادة إرسال البيانات الأصلية، فإنه يستخدم مخطط بيانات IPv4 يبلغ حجمه 1476 بايت.

4. الآن أصبح طول مخطط بيانات IPv4 هذا (1476 بايت) مساويًا في القيمة مع وحدة IPv4 MTU لنفق GRE لذلك يضيف الموجّه تضمين GRE إلى مخطط بيانات IPv4.

5. يزيل الموجّه المستلم (عند وجهة النفق) تضمين GRE لمخطط بيانات IPv4 ويرسله إلى المضيف المستلم.

هذا ما يحدث عندما يقوم الموجّه بالدور الثاني كمضيف مرسِل فيما يتعلق بتقنية PMTUD وفيما يتعلق بحزمة IPv4 للنفق.

يأتي وقت لعب هذا الدور بعد تضمين الموجّه لحزمة IPv4 الأصلية داخل حزمة النفق.

ملاحظة: وبشكل افتراضي، لا يقوم الموجه بتنفيذ PMTUD على حزم نفق GRE التي يقوم بتوليدها. يمكن استخدام الأمر لتشغيل PMTUD لحِزم نفق GRE-IPv4.tunnel path-mtu-discovery

يوضح المثال 3 ما يحدث عندما يرسل المضيف مخططات بيانات IPv4 صغيرة بما يكفي لملائمة وحدة IPv4 MTU على واجهة نفق GRE.

في هذه الحالة، يمكن تعيين وحدة بت DF أو مسحها (1 أو 0).

لا تتضمن واجهة نفق GRE الأمر الذي تم تكوينه لذلك لن يقوم الموجّه بتنفيذ PMTUD على حزمة GRE-IPv4.tunnel path-mtu-discovery

مثال 3

1. يستلم موجّه إعادة التوجيه عند مصدر النفق مخطط بيانات بحجم 1476 بايت من المضيف المرسِل.

2. يقوم هذا الموجّه بتضمين مخطط بيانات IPv4 بحجم 1476 بايت داخل GRE للحصول على مخطط بيانات GRE IPv4 بحجم 1500 بايت.

يتم مسح وحدة البت DF في عنوان GRE IPv4 الرئيسي (DF = 0). ثم يقوم هذا الموجّه بإعادة توجيه هذه الحزمة إلى وجهة النفق.

3. لنفترض أن هناك موجّه بين مصدر النفق ووجهته مع رابط MTU بحجم 1400 بايت.

سيقوم هذا الموجّه بتجزئة حزمة النفق نظرًا لمسح وحدة البت DF ‏(DF = 0).

تذكر أن هذا المثال يقوم بتجزئة IPv4 الخارجي، لذا لن تظهر عناوين GRE وIPv4 الداخلي وTCP الرئيسية إلا في الجزء الأول.

4. يتعين على موجّه وجهة النفق إعادة تجميع حزمة نفق GRE.

5. بعد إعادة تجميع حزمة نفق GRE، يزيل الموجّه عنوان GRE IPv4 الرئيسي ويرسل مخطط بيانات IPv4 الأصلي في طريقه.

يوضح المثال 4 ما يحدث عندما يقوم الموجّه بدور مضيف مرسِل فيما يتعلق بتقنية PMTUD وفيما يتعلق بحزمة IPv4 النفقية.

في هذه المرة، يتم تعيين وحدة البت DF ‏(DF = 1) في عنوان IPv4 الرئيسي الأصلي وقد تم تكوين الأمر بحيث يتم نسخ وحدة البت DF من عنوان IPv4 الداخلي الرئيسي إلى عنوان (GRE + IPv4) الخارجي الرئيسي.tunnel path-mtu-discovery

مثال 4

1. يستلم موجّه إعادة التوجيه عند مصدر النفق مخطط بيانات بحجم 1476 بايت مع وحدة البت DF = 1 من المضيف المرسِل.

2. يقوم هذا الموجّه بتضمين مخطط بيانات IPv4 بحجم 1476 بايت داخل GRE للحصول على مخطط بيانات GRE IPv4 بحجم 1500 بايت.

تم تعيين وحدة البت DF ‏(DF = 1) لعنوان GRE IPv4 الرئيسي هذا نظرًا لتعيين وحدة البت DF لمخطط بيانات IPv4 الأصلي.

ثم يقوم هذا الموجّه بإعادة توجيه هذه الحزمة إلى وجهة النفق.

3. مرة أخرى، لنفترض أن هناك موجّه بين مصدر النفق ووجهته مع رابط MTU بحجم 1400 بايت.

لا يقوم هذا الموجّه بتجزئة حزمة النفق نظرًا لتعيين وحدة البت DF ‏(DF = 1).

يتعين على هذا الموجّه إسقاط الحزمة وإرسال رسالة خطأ ICMP إلى موجّه مصدر النفق، حيث إن هذا هو عنوان IPv4 للمصدر على الحزمة.

4. يستلم موجّه إعادة التوجيه عند مصدر النفق رسالة الخطأ "ICMP" هذه وسيقوم بخفض وحدة IPv4 MTU لنفق GRE إلى 1376 (1400 - 24).

في المرة القادمة التي يقوم فيها المضيف المرسِل بإعادة إرسال البيانات في حزمة IPv4 بحجم 1476 بايت، يمكن أن تكون هذه الحزمة كبيرة للغاية وسيرسل حينئذ هذا الموجّه رسالة خطأ "ICMP" إلى المرسِل بقيمة MTU تبلغ 1376.

عندما يقوم المضيف المرسِل بإعادة إرسال البيانات، سيرسلها في حزمة IPv4 بحجم 1376 بايت وتمر هذه الحزمة عبر نفق GRE إلى المضيف المستلم.

مثال 5

يوضح هذا المثال تجزئة GRE. يجب إجراء التجزئة قبل التضمين بالنسبة لـ GRE، ثم إجراء تقنية PMTUD لحزمة البيانات، ولا يتم نسخ وحدة البت DF عند تضمين حزمة IPv4 بواسطة GRE.

لا يتم تعيين وحدة البت DF. قيمة وحدة IPv4 MTU لواجهة نفق GRE، بشكل افتراضي، أقل بـ 24 بايت من الواجهة المادية IPv4 MTU، وبالتالي فإن وحدة IPv4 MTU لواجهة GRE هي 1476 بايت كما هو موضح في الصورة.

1. يرسل المرسِل حزمة بحجم 1500 بايت (عنوان IPv4 رئيسي بحجم 20 بايت + حمولة TCP بحجم 1480 بايت).
2. ونظرًا لأن وحدة MTU لنفق GRE بحجم 1476، يتم تقسيم الحزمة بحجم 1500 بايت إلى اثنين من أجزاء IPv4 بحجم 1476 بايت وحجم 44 بايت، بزيادة في كل منهما تحسبًا للـ 24 بايت الإضافية لعنوان GRE الرئيسي.
3. يتم إضافة 24 بايت لعنوان GRE الرئيسي إلى كل جزء IPv4. والآن يبلغ الجزأين 1500 بايت (1476 + 24) و68 (44 + 24) بايت لكل منهما.
4. تتم إعادة توجيه حِزم GRE + IPv4 التي تحتوي على جزأي IPv4 إلى موجّه نظير نفق GRE.
5. يزيل موجّه نظير نفق GRE عناوين GRE الرئيسية من الحزمتَين.
6. يقوم الموجّه هذا بإعادة توجيه الحزمتَين إلى مضيف الوجهة.
7. يقوم مضيف الوجهة بإعادة تجميع جزأي IPv4 مرة أخرى في مخطط بيانات IPv4 الأصلي.

مثال 6

يتشابه هذا المثال مع المثال 5، ولكن هذه المرة يتم تعيين وحدة البت DF. يتم تكوين الموجّه لإجراء تقنية PMTUD على حِزم نفق GRE + IPv4 باستخدام الأمر، ويتم نسخ وحدة البت DF من عنوان IPv4 الرئيسي الأصلي إلى عنوان IPv4 الرئيسي لـ GRE.tunnel path-mtu-discovery

إذا استلم الموجّه خطأ ICMP لحزمة GRE + IPv4، سيقلّل وحدة IPU4 MTU على واجهة نفق GRE.

يتم تعيين وحدة MTU لبروتوكول IPv4 لنفق GRE على حجم أقل من ذلك الخاص بوحدة MTU للواجهة المادية بـ 24 بايت بشكل افتراضي، لذا فيكون حجم وحدة MTU لبروتوكول IPv4 لـ GRE هنا 1476. يوجد رابط MTU بحجم 1400 في مسار نفق GRE كما هو موضح في الصورة.

1. يستلم الموجّه حزمة بحجم 1500 بايت (عنوان IPv4 الرئيسي بحجم 20 بايت + حمولة TCP بحجم 1480 بايت)، ويقوم بإسقاط الحزمة. يقوم الموجّه بإسقاط الحزمة لأنها أكبر من وحدة IPv4 MTU (1476) على واجهة نفق GRE.
2. يرسل الموجّه خطأ ICMP إلى المرسِل يفيد بأن وحدة MTU للخطوة التالية هي 1476. وسيقوم المضيف بتسجيل هذه المعلومات، عادةً كمسار مضيف للوجهة في جدول التوجيه الخاص بها.
3. يستخدم المضيف المرسِل حزمة بحجم 1476 بايت عندما يقوم بإعادة إرسال البيانات. يضيف موجّه GRE 24 بايت من تضمين GRE ويرسل حزمة بحجم 1500 بايت.
4. لا يمكن للحزمة البالغ حجمها 1500 بايت اجتياز رابط بحجم 1400 بايت، ولذلك يتم إسقاطها بواسطة الموجّه الوسيط.
5. يرسل الموجّه الوسيط رسالة ICMP (نوع = 3، رمز = 4) إلى موجّه GRE مع وحدة MTU للخطوة التالية بقيمة 1400. ويقلل موجّه GRE هذه القيمة إلى 1376 (1400 - 24) ويقوم بتعيين قيمة MTU IPv4 داخلية على واجهة GRE. يمكن ملاحظة هذا التغيير فقط عند إستخدام debug tunnel الأمر؛ ولا يمكن رؤيتها في مخرجات الأمرshow ip interface tunnel<#>.
6. في المرة القادمة التي يُعيد فيها المضيف إرسال الحزمة بحجم 1476 بايت، سيقوم موجّه GRE بإسقاط الحزمة، نظرًا لأنها أكبر من وحدة IPv4 MTU الحالية (1376) على واجهة نفق GRE.
7. يرسل موجّه GRE رسالة ICMP أخرى (النوع = 3، الكود = 4) إلى المرسِل مع وحدة MTU للخطوة التالية بحجم 1376 وسيقوم المُضيف بتحديث معلوماته الحالية بقيمة جديدة.
8. يُعيد المُضيف إرسال البيانات مرة أخرى، ولكن الآن في حزمة أصغر بحجم 1376 بايت ويضيف GRE حجم 24 بايت من التضمين ويُعيد توجيهها. هذه المرة ستصل الحزمة إلى نظير نفق GRE، حيث يتم إلغاء تضمين الحزمة وإرسالها إلى مضيف الوجهة.

ملاحظة: إذا tunnel path-mtu-discovery لم يتم تكوين الأمر على موجه إعادة التوجيه في هذا السيناريو، وتم تعيين وحدة بت DF في الحزم التي تمت إعادة توجيهها عبر نفق GRE، فإن المضيف 1 لا يزال ينجح في إرسال حزم TCP/IPv4 إلى المضيف 2، ولكن يتم تجزئتها في الوسط عند إرتباط 1400 MTU. كما سيتعين على نظير نفق GRE إعادة تجميعها قبل أن يتمكن من إلغاء تضمينها وإعادة توجيهها.

وضع "نفق بروتوكول IPsec" الخالص

يعد بروتوكول أمان IPv4 (IPv4sec) طريقة قائمة على المعايير توفر الخصوصية والتكامل والمصداقية للمعلومات المنقولة عبر شبكات IPv4.

يوفر بروتوكول IPv4sec تشفير طبقة شبكة IPv4. يقوم بروتوكول IPv4sec بإطالة حزمة IPv4 بإضافة عنوان IPv4 رئيسي واحد على الأقل (وضع النفق).

ويختلف العنوان الرئيسي (العناوين الرئيسية) المضاف (المضافة) في الطول حسب وضع تكوين IPv4sec لكنه لا يتجاوز ~ 58 بايت (حمولة أمان التضمين (ESP) ومصادقة ESP (ESPauth)) لكل حزمة.

لبروتوكول IPv4sec وضعان، وضع النفق ووضع النقل.

1. وضع النفق هو الوضع الافتراضي. مع استخدام وضع النفق، تتم حماية حزمة IPv4 الأصلية بالكامل (المشفّرة أو المصدّقة أو كلتيهما) وتضمينها بواسطة عناوين IPv4sec الرئيسية والتذييل. ثم يتم إضافة عنوان IPv4 رئيسي جديد إلى الحزمة، والذي يحدد أجهزة IPv4sec الطرفية (النظراء) كمصدر ووجهة. يمكن استخدام وضع النفق مع أي حركة مرور بيانات IPv4 أحادية البث ويتعين استخدامه إذا كان IPv4sec يحمي حركة مرور البيانات من الأجهزة المضيفة خلف نظراء IPv4sec. على سبيل المثال، يُستخدم وضع النفق مع الشبكات الافتراضية الخاصة (VPN) حيث تقوم الأجهزة المضيفة على شبكة محمية واحدة بإرسال حِزم إلى الأجهزة المضيفة على شبكة محمية مختلفة عبر زوج من نظراء IPv4sec. باستخدام الشبكات الافتراضية الخاصة (VPN)، يحمي وضع "النفق" لـ IPv4sec حركة مرور البيانات IPv4 بين الأجهزة المضيفة بتشفير حركة المرور هذه بين موجّهات نظير IPv4sec.
2. مع استخدام وضع النقل (الذي يتم تكوينه باستخدام الأمر الفرعي، ، في تعريف التحويل)، تتوفّر الحماية فقط لحمولة حزمة IPv4 الأصلية (المشفّرة، أو المصدّقة، أو كلتيهما).mode transport يتم تضمين الحمولة بواسطة عناوين IPv4sec الرئيسية والتذييل. تظل عناوين IPv4 الرئيسية الأصلية سليمة، باستثناء أن حقل بروتوكول IPv4 تم تغييره ليصبح بروتوكول ESP (50)، ويتم حفظ قيمة البروتوكول الأصلية في تذييل IPv4sec المطلوب استعادتها عند فك تشفير الحزمة. لا يُستخدم وضع النقل إلا عندما تكون حركة مرور بيانات IPv4 المطلوب حمايتها بين نظراء IPv4sec أنفسهم، وتكون عناوين IPv4 المصدر والوجهة على الحزمة هي نفس عناوين نظير IPv4sec. عادةً لا يُستخدم وضع نقل IPv4sec إلا عند استخدام بروتوكول أنفاق آخر (مثل GRE) لتضمين حزمة بيانات IPv4 أولاً، ثم يُستخدم IPv4sec لحماية حِزم نفق GRE.

أما IPv4sec فيقوم دائمًا بإجراء PMTUD لحِزم البيانات وحِزمه الخاصة. وتوجد أوامر تكوين IPv4sec لتعديل معالجة PMTUD لحزمة IPv4sec IPv4، ويمكن لـ IPv4sec مسح وحدة بت DF أو تعيينها أو نسخها من عنوان IPv4 الرئيسي الخاص بحزمة البيانات إلى عنوان IPv4sec IPv4 الرئيسي. ويسمى هذا بميزة "التجاوز التنفيذي بـ DF Bit".

ملاحظة: تجنب التجزئة بعد التضمين عند إجراء تشفير الأجهزة باستخدام IPv4sec. يمنحك تشفير المكونات المادية معدل إنتاجية يبلغ 50 ميجابت في الثانية تقريبًا ويعتمد ذلك على المكونات المادية، ولكن إذا تم تجزئة حزمة IPv4sec، فستفقد نسبة تتراوح ما بين 50 إلى 90 بالمائة من معدل الإنتاجية. ويرجع هذا الفقد إلى أن حِزم IPv4sec المجزأة يتم تبديلها بين العمليات لغرض إعادة التجميع ثم يتم تسليمها إلى محرك تشفير المكونات المادية لفك التشفير. وقد يؤدي هذا الفقد لمعدل الإنتاجية إلى خفض معدل إنتاجية تشفير المكونات المادية إلى مستوى أداء تشفير البرمجيات (2-10 ميجابِت في الثانية).

مثال 7

يصور هذا السيناريو تجزئة IPv4 وهي قيد التشغيل. في هذا السيناريو، تكون قيمة MTU على طول المسار بالكامل هي 1500. في هذا السيناريو، لم يتم تعيين وحدة بت DF.

1. يستلم الموجّه حزمة بحجم 1500 بايت (عنوان IPv4 الرئيسي بحجم 20 بايت + حمولة TCP بحجم 1480 بايت) متجهة إلى المضيف 2.
2. يتم تشفير الحزمة البالغ حجمها 1500 بايت بواسطة IPv4sec وإضافة 52 بايت من العبء (عنوان IPv4sec رئيسي، تذييل، عنوان IPv4 رئيسي إضافي). ويتعين الآن على IPv4sec إرسال حزمة بحجم 1552 بايت. وبما أن حجم MTU الصادرة هو 1500، فسيتعين تجزئة هذه الحزمة.
3. يتم إنشاء جزأين من حزمة IPv4sec. أثناء التجزئة، يُضاف عنوان IPv4 رئيسي إضافي بحجم 20 بايت للجزء الثاني، فينتج عن ذلك جزء بحجم 1500 بايت وجزء IPv4 بحجم 72 بايت.
4. يستلم موجّه نظير نفق IPv4sec الجزأين، ويزيل عنوان IPv4 الرئيسي الإضافي ويدمج جزأي IPv4 مرة أخرى في حزمة IPv4sec الأصلية. ثم يقوم IPv4sec بفك تشفير هذه الحزمة.
5. ثم يقوم الموجّه بإعادة توجيه حزمة البيانات بحجم 1500 بايت الأصلية إلى المضيف 2.

مثال 8

يتشابه هذا المثال مع المثال 6 باستثناء أنه في هذه الحالة يتم تعيين وحدة البت DF في حزمة البيانات الأصلية ويوجد رابط في المسار بين نظراء نفق IPv4sec بقيمة MTU أقل من الروابط الأخرى.

يوضح هذا السيناريو كيفية تنفيذ موجّه نظير IPv4sec لكلا دورَي PMTUD، وذلك على النحو الموضح في قسم الموجّه كمشارك في تقنية PMTUD في الجهاز الطرفي لنفق.

تتغيرPMTU لبروتوكول IPv4sec إلى قيمة أقل نتيجةً للحاجة إلى التجزئة.

يتم نسخ وحدة البت DF من عنوان IPv4 الرئيسي الداخلي إلى عنوان IPv4 الرئيسي الخارجي عندما يقوم IPv4sec بتشفير حزمة.

ويتم تخزين قيم MTU وPMTU للوسائط في ارتباط الأمان (SA) لـ IPv4sec.

وتعتمد MTU للوسائط على MTU لواجهة الموجّه الصادرة بينما تعتمد PMTU على الحد الأدنى لقيمة MTU المرئية على المسار بين نظراء IPv4sec.

يقوم IPv4sec بتضمين/تشفير الحزمة قبل أن يحاول تجزئتها كما هو موضح في الصورة.

1. يستلم الموجّه حزمة بحجم 1500 بايت ويقوم بإسقاطها لأن عبء IPv4sec، عند إضافته، يجعل الحزمة أكبر من حجم PMTU (1500).
2. يرسل الموجّه رسالة ICMP إلى المضيف 1 تفيد بأن قيمة MTU للخطوة التالية هي 1442 (1500 - 58 = 1442). هذا الحجم البالغ 58 بايت هو الحد الأقصى لعبء IPv4sec عند استخدامك ESPauth وESP لـ IPv4sec. يُحتمَل أن يكون عبء IPv4sec الحقيقي أقل بمقدار 7 بايت عن هذه القيمة. ويقوم المضيف 1 بتسجيل هذه المعلومات، عادةً كمسار مضيف للوجهة (Host 2)، في جدول التوجيه الخاص بها.
3. يقوم المضيف 1 بخفض PMTU الخاص به للمضيف 2 إلى 1442، لذلك يرسل المضيف 1 حزم أصغر (1442 بايت) عندما يرسل البيانات إلى المضيف 2. يستلم الموجه الحزمة 1442 بايت ويضيف IPv4sec 52 بايت من مصروفات التشفير بحيث تكون حزمة IPv4sec الناتجة 1496 بايت. ونظرًا لأن هذه الحزمة تحتوي على وحدة بت DF في عنوانها الرئيسي، يتم إسقاطها بواسطة الموجّه الأوسط مع رابط MTU بحجم 1400 بايت.
4. يرسل الموجّه الأوسط الذي أسقط الحزمة رسالة ICMP إلى مرسِل حزمة IPv4sec (الموجّه الأول) تفيد بأن قيمة MTU للخطوة التالية هي 1400 بايت. ويتم تسجيل هذه القيمة في ارتباط أمان (SA) IPv4sec لـ PMTU.
5. في المرة القادمة التي يعيد فيها المضيف 1 إرسال الحزمة بحجم 1442 بايت (ولم يستلم إقرارًا لها)، سيقوم IPv4sec بإسقاط الحزمة. يقوم الموجّه بإسقاط الحزمة لأن عبء IPv4sec، عند إضافته إلى الحزمة، يجعلها أكبر من حجم PMTU ‏(1400).
6. يرسل الموجه رسالة ICMP إلى المضيف 1 يقول فيها أن الخطوة التالية MTU هو الآن 1342. (1400 - 58 = 1342). يقوم المضيف 1 بتسجيل هذه المعلومات مرة أخرى.
7. عندما يقوم المضيف 1 بإعادة إرسال البيانات مرة أخرى، سيستخدم الحزمة الأصغر حجمًا (1342). ولن تتطلب هذه الحزمة إجراء التجزئة وستمر عبر نفق IPv4sec إلى المضيف 2.

بروتوكولا تضمين التوجيه العام (GRE) وIPv4sec معًا

تحدث تفاعلات أكثر تعقيدًا في التجزئة وتقنية PMTUD عند استخدام IPv4sec لتشفير أنفاق GRE.

يتم الجمع بين IPv4sec وGRE بهذه الطريقة لأن IPv4sec لا يدعم حِزم IPv4 متعددة البث، مما يعني أنه يتعذّر عليك تشغيل بروتوكول توجيه ديناميكي عبر شبكة VPN لـ IPv4sec.

كما أن أنفاق GRE تدعم بالفعل الحِزم متعددة البث، لذا يمكن استخدام نفق GRE لتضمين أولاً حزمة بروتوكول التوجيه الديناميكي متعددة البث في حزمة GRE IPv4 أحادية البث والتي يمكن تشفيرها بعد ذلك بواسطة IPv4sec.

عندما تفعل ذلك، غالبًا ما يتم نشر IPv4sec في وضع النقل فوق GRE لأن نظراء IPv4sec هي نفسها أجهزة نفق GRE الطرفية (الموجّهات)، وسيوفر وضع النقل 20 بايت من عبء IPv4sec.

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

في هذه الحالة، يرى بروتوكول IPv4sec حزمتي GRE ‏+ IPv4 مستقلتَين. وغالبًا في التكوين الافتراضي ما تكون إحدى هذه الحِزم كبيرة بما يكفي بحيث يتعين تجزئتها بعد أن يتم تشفيرها.

وسيتعين على نظير IPv4sec إعادة تجميع هذه الحزمة قبل فك التشفير. تعمل "التجزئة المزدوجة" هذه (مرة قبل GRE ومرة أخرى بعد IPv4sec) على الموجّه المرسِل على زيادة زمن الانتقال وتقليل معدل الإنتاجية.

يتم إجراء إعادة التجميع بمنهجية التبديل عبر العمليات، لذا يكون هناك ضغط على وحدة المعالجة المركزية (CPU) على الموجّه المستلم كلما يحدث ذلك.

يمكن تجنب هذا الموقف من خلال تعيين "ip mtu" على واجهة نفق GRE منخفضًا بما يكفي لمراعاة العبء لكلٍ من GRE وIPv4sec (بشكل افتراضي يتم تعيين واجهة نفق GRE "ip mtu" إلى وحدات بايت عبء الواجهة الحقيقية الصادرة MTU - GRE).

يسرد هذا الجدول قيم MTU المقترحة لكل مجموعة نفق/وضع، ويفترض أن الواجهة المادية للإرسال يبلغ حجم MTU بها 1500.

ملاحظة: يوصى بقيمة وحدة الحد الأقصى للنقل (MTU) التي تبلغ 1400 لأنها تغطي مجموعات أوضاع GRE + IPv4sec الأكثر شيوعا. كما لا يوجد جانب سلبي ملحوظ للسماح بإنفاق إضافي يبلغ 20 أو 40 بايت. وسيكون الأسهل تذكر قيمة واحدة وتعيينها وتغطي هذه القيمة جميع السيناريوهات تقريبًا.

مثال 9

يتم نشر IPv4sec فوق GRE. قيمة MTU المادية الصادرة هي 1500، وقيمة IPv4sec PMTU هي 1500، وقيمة IPv4 MTU لـGRE هي 1476 (1500 - 24 = 1476).

ولذلك، ستتم تجزئة حِزم TCP‏/IPv4 مرتين، مرة قبل GRE ومرة أخرى بعد IPv4sec.

تتم تجزئة الحزمة قبل تضمين GRE وتتم تجزئة إحدى حِزم GRE هذه مرة أخرى بعد تشفير IPv4sec.

قد يؤدي تكوين "ip mtu 1440" (IPv4sec في وضع النقل) أو "ip mtu 1420" (IPv4sec في وضع النفق) على نفق GRE إلى إزالة احتمالية التجزئة المزدوجة في هذا السيناريو.

1. يستلم الموجّه مخطط بيانات بحجم 1500 بايت.
2. قبل التضمين، يقوم GRE بتجزئة الحزمة البالغ حجمها 1500 بايت إلى جزأين، 1476 بايت (1500 - 24 = 1476) و44 بايت (بيانات بحجم 24 + عنوان IPv4 رئيسي بحجم 20).
3. يقوم GRE بتضمين جزأي IPv4 مما يضيف 24 بايت إلى كل حزمة. ينتج عن ذلك حزمتَي GRE + IPv4sec يبلغ حجمهما 1500 بايت (1476 + 24 = 1500) و68 بايت (44 + 24).
4. يقوم IPv4sec بتشفير الحزمتَين، ما يؤدي إلى إضافة 52 بايت (وضع النفق لـ IPv4sec) من عبء التضمين لكل حزمة، لإنتاج حزمة بحجم 1552 بايت وأخرى بحجم 120 بايت.
5. يتم تجزئة حزمة IPv4sec البالغ حجمها 1552 بايت بواسطة الموجّه لأنها أكبر من قيمة MTU الصادرة (1500). ويتم تقسيم الحزمة البالغ حجمها 1552 بايت إلى جزأين، حزمة بحجم 1500 بايت وحزمة بحجم 72 بايت (52 بايت "حمولة" بالإضافة إلى عنوان IPv4 رئيسي إضافي بحجم 20 بايت للجزء الثاني). يتم إعادة توجيه الحِزم الثلاث بحجم 1500 بايت و72 بايت و120 بايت إلى نظير IPv4sec + GRE.
6. يقوم الموجّه المستلم بإعادة تجميع جزأي IPv4sec (1500 بايت و72 بايت) للحصول على حزمة IPv4sec + GRE الأصلية بحجم 1552 بايت. لا يتعين فعل شيء لحزمة IPv4sec + GRE البالغ حجمها 120 بايت.
7. يقوم IPv4sec بفك تشفير كلاً من حزمتَي IPv4sec + GRE البالغ حجمهما 1552 بايت و120 بايت للحصول على حزمتَي GRE البالغ حجمهما 1500 بايت و68 بايت.
8. يقوم GRE بفك تضمين حزمتَي GRE البالغ حجمهما 1500 بايت و68 بايت للحصول على جزأي حزمة IPv4 البالغ حجمهما 1476 بايت و44 بايت. ويتم إعادة توجيه جزأي حزمة IPv4 هذين إلى مضيف الوجهة.
9. يقوم المضيف 2 بإعادة تجميع جزأي IPv4 هذين للحصول على مخطط البيانات IPv4 الأصلي بحجم 1500 بايت.

السيناريو 10 مشابه للسيناريو 8 باستثناء وجود رابط MTU أقل في مسار النفق. هذا هو أسوأ سيناريو للحزمة الأولى التي يتم إرسالها من المضيف 1 إلى المضيف 2. بعد الخطوة الأخيرة في هذا السيناريو، يحدد المضيف 1 وحدة المعالجة المركزية (PMTU) الصحيحة للمضيف 2 وجميعها جيدة لاتصالات TCP بين المضيف 1 والمضيف 2. يجب أن تمر تدفقات TCP بين المضيف 1 والمضيفين الآخرين (يمكن الوصول إليها عبر IPv4sec + نفق GRE) فقط عبر الخطوات الثلاث الأخيرة من السيناريو 10.

في هذا السيناريو، يتم تكوين الأمر في نفق GRE وتعيين وحدة البت DF على حِزم TCP‏/IPv4 التي تنشأ من المضيف 1.tunnel path-mtu-discovery

مثال 10

1. يستلم الموجّه حزمة بحجم 1500 بايت. يتم إسقاط هذه الحزمة بواسطة GRE لأنه يتعذّر على GRE تجزئة الحزمة أو إعادة توجيهها نظرًا لتعيين وحدة بت DF وتجاوز حجم الحزمة واجهة الإرسال "ip mtu" بعد إضافة عبء GRE (24 بايت).
2. يرسل الموجّه رسالة ICMP إلى المضيف 1 بهدف إعلامه بأن قيمة MTU للخطوة التالية هي 1476 (1500 - 24 = 1476).
3. يقوم المضيف 1 بتغيير قيمة PMTU الخاصة به للمضيف 2 إلى 1476 ويرسل الحجم الأصغر عندما يُعيد إرسال الحزمة. ويقوم GRE بتضمينها وتسليم الحزمة البالغ حجمها 1500 بايت إلى IPv4sec. يقوم IPv4sec بإسقاط الحزمة نظرًا لأن GRE نسَخ وحدة بت DF (التعيين) من عنوان IPv4 الرئيسي الداخلي، ومع عبء IPv4sec (الحد الأقصى 38 بايت)، تصبح الحزمة كبيرة للغاية بحيث لا يمكن إعادة توجيهها خارج الواجهة المادية.
4. يرسل IPv4sec رسالة ICMP إلى GRE تشير إلى أن MTU للخطوة التالية بحجم 1462 بايت (حيث ستتم إضافة 38 بايت كحد أقصى للتشفير وعبء IPv4). يقوم GRE بتسجيل القيمة 1438 (1462 - 24) على أنها "ip mtu" على واجهة النفق.

   ملاحظة: يتم تخزين هذا التغيير في القيمة داخليا ولا يمكن رؤيته في إخراج show ip interface tunnel<#>الأمر. ولن ترى هذا التغيير إلا في حال تشغيلك لاستخدام الأمر .debug tunnel

5. في المرة القادمة التي يقوم فيها المضيف 1 بإعادة إرسال الحزمة البالغ حجمها 1476 بايت، يقوم GRE بإسقاطها.
6. يرسل الموجّه رسالة ICMP إلى المضيف 1 والتي تشير إلى أن 1438 هي قيمة MTU للخطوة التالية.
7. يقوم المضيف 1 بتقليل قيمة PMTU للمضيف 2 ويعيد إرسال حزمة بحجم 1438 بايت. في هذه المرة يقْبل GRE الحزمة ويقوم بتضمينها وتسليمها إلى IPv4sec للتشفير.
8. يتم إعادة توجيه حزمة IPv4sec إلى الموجّه الوسيط وإسقاطها نظرًا لأنها تحتوي على قيمة MTU لواجهة الإرسال تبلغ 1400.
9. يرسل الموجّه الوسيط رسالة ICMP إلى IPv4sec تفيد بأن قيمة MTU للخطوة التالية هي 1400. ويتم تسجيل هذه القيمة بواسطة IPv4sec في قيمة PMTU الخاصة بـ IPv4sec SA المقترن.
10. عندما يقوم المضيف 1 بإعادة إرسال الحزمة البالغ حجمها 1438 بايت، فإن GRE يقوم بتضمينها وتسليمها إلى IPv4sec. ويقوم IPv4sec بإسقاط الحزمة لأنها قامت بتغيير قيمة PMTU الخاصة بها إلى 1400.
11. يرسل IPv4sec خطأ ICMP إلى GRE والذي يشير إلى أن قيمة MTU للخطوة التالية هي 1362، و يقوم GRE بتسجيل القيمة 1338 داخليًا.
12. عندما يقوم المضيف 1 بإعادة إرسال الحزمة الأصلية (لأنه لم يستلم إقرارًا بها)، يقوم GRE بإسقاطها.
13. يرسل الموجّه رسالة ICMP إلى المضيف 1  والتي تشير إلى أن قيمة MTU للخطوة التالية هي 1338 (1362 - 24 بايت). يقوم المضيف 1 بتقليل قيمة PMTU الخاصة به للمضيف 2 إلى 1338.
14. يقوم المضيف 1 بإعادة إرسال حزمة بحجم 1338 بايت، وهذه المرة يمكنها الوصول أخيرًا إلى المضيف 2.

المزيد من التوصيات

يمكن أن يساعد تكوين الأمر على واجهة نفق في تفاعل GRE وIPv4sec عند تكوينهما على نفس الموجّه.tunnel path-mtu-discovery

من دون تكوين الأمر ، سيتم دائمًا مسح وحدة البت DF في عنوان IPv4 الرئيسي لـ GRE.tunnel path-mtu-discovery

ويسمح ذلك بتجزئة حزمة IPv4 لـ GRE على الرغم من أن عنوان IPv4 الرئيسي للبيانات المُتضمّنة كان يحتوي على تعيين وحدة بت DF، والتي عادةً لا تسمح بتجزئة الحزمة.

إذا تم تكوين الأمر على واجهة نفق GRE:tunnel path-mtu-discovery

1. سيقوم GRE بنسخ وحدة البت DF من عنوان IPv4 الرئيسي للبيانات إلى عنوان IPv4 الرئيسي لـ GRE.
2. إذا تم تعيين وحدة البت DF في عنوان IPv4 الرئيسي لـ GRE وكانت الحزمة "كبيرة للغاية" بعد تشفير IPv4sec لـ IPv4 MTU على واجهة الإرسال المادية، فسيقوم IPv4sec بالتالي بإسقاط الحزمة وإعلام نفق GRE لتقليل حجم MTU IPv4 الخاص به.
3. يقوم IPv4sec بإجراء تقنية PMTUD على الحِزم الخاصة به وإذا تغيّرت PMTU لـ IPv4sec (في حال تقليله)، فإن IPv4sec لن يُعلِم GRE على الفور، ولكن عندما تعبر حزمة أخرى "كبيرة للغاية"، ومن ثمّ تحدث العملية الواردة في الخطوة 2.
4. أصبحت الآن IPv4 MTU لـ GRE أصغر، لذلك تقوم بإسقاط أي حِزم IPv4 للبيانات معيَّن بها وحدة البت DF والتي أصبحت الآن كبيرة للغاية وترسل رسالة ICMP إلى المضيف المرسِل.

يساعد الأمر على تعيين واجهة GRE لوحدة MTU لـ IPv4 الخاصة بها ديناميكيًا، بدلاً من تعيينها بشكل ثابت باستخدام الأمر .tunnel path-mtu-discovery ip mtu ويوصَى بالفعل استخدام كلا الأمرَين.

يُستخدَم الأمر لتوفير مساحة لعبء GRE وIPv4sec فيما يتعلق بوحدة IPv4 MTU لواجهة الإرسال المادية المحلية.ip mtu

بينما يسمح الأمر بتقليل IPv4 MTU الخاصة بنفق GRE على نحو إضافي إذا كان هناك رابط MTU لـ IPv4 أقل في المسار بين نظراء IPv4sec.tunnel path-mtu-discovery

فيما يلي بعض الأمور التي يمكنك القيام بها إذا واجهت مشكلات في إجراء PMTUD على شبكة حيث يتم تكوين أنفاق GRE + IPv4sec.

تبدأ هذه القائمة بالحل الأكثر طلبًا.

1. لا ينجح حل المشكلة المتعلقة بـ PMTUD، والذي يحدث عادةً بسبب موجّه أو جدار حماية يحظر ICMP.
2. استخدم الأمر على واجهات النفق بحيث يقلّل الموجّه من قيمة TCP MSS في حزمة TCP SYN.ip tcp adjust-mss وسيساعد هذا الجهازَين المضيفَين (مرسل ومستلم TCP) على استخدام حِزم صغيرة بما يكفي بحيث لا تكون هناك حاجة لـ PMTUD.
3. استخدم توجيه السياسة على واجهة الدخول الخاصة بالموجّه وقم بتكوين خريطة مسار لمسح وحدة بت DF في عنوان IPv4 الرئيسي للبيانات قبل وصولها إلى واجهة نفق GRE. ويسمح هذا بتجزئة حزمة IPv4 للبيانات قبل تضمين GRE.
4. قم بزيادة قيمة "ip mtu" على واجهة نفق GRE لتكون متساوية مع قيمة MTU لواجهة الإرسال. ويسمح هذا بتضمين حزمة IPV4 للبيانات بواسطة GRE دون تجزئتها أولاً. سيتم تشفير حزمة GRE بعد ذلك بواسطة IPv4sec ثم تجزئتها للانتقال إلى واجهة الإرسال المادية. في هذه الحالة لن تقوم بتكوين الأمر على واجهة نفق GRE.tunnel path-mtu-discovery ويمكن أن يقلّل هذا من معدل الإنتاجية بشكل كبير لأن إعادة تجميع حزمة IPv4 على نظير IPv4sec يتم في وضع إجراءات يتم التنقل بينها.

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

• صفحة دعم توجيه IP
• صفحة دعم IPSec (بروتوكول أمان IP)
• RFC 1191: اكتشاف مسار MTU
• RFC 1063: خيارات اكتشاف MTU لـ IP
• RFC 791: بروتوكول الإنترنت
• RFC 793: بروتوكول التحكم في الإرسال
• RFC 879: حجم جزء TCP الأقصى والموضوعات ذات الصلة
• RFC 1701: تضمين التوجيه العام (GRE)
• RFC 1241: مخطط لبروتوكول تضمين الإنترنت
• RFC 2003: تضمين IP داخل IP
• الدعم التقني والمستندات - Cisco Systems