حل مشكلات تجزئة 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 = "يمكن أن يتجزء"، 1 = "لا تتجزء").

البت 2 هو بت MF (0 = "آخر جزء"، 1 = "المزيد من الأجزاء").

القيمة	بت 0 محجوز	بت 1 DF	بت 2 mf
0	0	مايو	الأخير
1	0	لا	أكثر

إذا تمت إضافة أطوال أجزاء 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)، مما يعني أن جزء البيانات من هذا الجزء يبدأ من 440 بايت في مخطط بيانات IPv4 الأصلي.

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

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

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

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

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

مشكلات تجزئة IPv4

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

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

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

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

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

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

لم يتم تصميم الموجه للاحتفاظ بالحزم لأي طول من الوقت.

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

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

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

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

وبالتالي، يبلغ مخطط بيانات NFS IPv4/UDP 8500 بايت تقريبا (والذي يتضمن رؤوس NFS و UDP و IPv4).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يجب على المضيفين A و Host B تجزئة مخططات بيانات IPv4 التي تكون أكبر من وحدة الحد الأقصى للنقل (MTU) للواجهة، ولكن أقل من وحدات الحد الأقصى للنقل (MSS) التي يتم إرسالها نظرا لتمرير مكدس TCP إلى الإصدار الرابع من بروتوكول الإنترنت (IP) بمقدار 16 ألف بايت أو 8 آلاف بايت من البيانات الموجودة أسفل المكدس.

في حالة المضيف B، تتم تجزئة الحزم للوصول إلى شبكة Token Ring المحلية ومرة أخرى للوصول إلى شبكة Ethernet LAN.

مثال 1

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

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

تكون أرقام MSS أقل من أرقام MTU بمقدار 40 بايت لأن 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

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

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

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

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

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

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

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

هنا مثال على رسالة ICMP "التجزئة المطلوبة ومجموعة DF" التي يتم رؤيتها على الموجه بعد تشغيل 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 حزم صغيرة ويرسل الخادم حزم كبيرة.

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

الحزم من العميل صغيرة (أقل من 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 للحصول على مزيد من المعلومات).

• معالجة 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) الخاصة بالروابط الطرفية. وتتمثل بعض الأسباب الشائعة لوجود هذه الروابط الأصغر لوحدة الحد الأقصى للنقل (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)

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

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

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

• بروتوكول النقل - البروتوكول المستخدم لحمل البروتوكول المغلف.

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

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

حزمة عادية

IPv4

TCP

Telnet

حزمة النفق

IPv4

GRE

IPv4

TCP

Telnet

• 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 في الإصدار 11.1 من Cisco IOS® وتم إدخال تحويل CEF في الإصدار 12.0.

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

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

• هناك أمن ومخطط إصدار عندما tunneling ربط. يمكن للأنفاق تجاوز قوائم التحكم في الوصول (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) ونفق GRE IPv4 MTU هو 1476 (1500 - 24).

مثال 1

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

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

IPv4	1480 بايت بروتوكول TCP + البيانات

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

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

IP0	1456 بايت بروتوكول TCP + البيانات

IP1	بيانات 24 بايت

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

ويبلغ طول هذين النوعين من مخططات البيانات الخاصة بالإصدار الرابع من بروتوكول الإنترنت (IPv4) الآن 1500 و 68 بايت، ويتم إعتبار مخططات البيانات هذه كمخططات بيانات خاصة بالإصدار الرابع من بروتوكول الإنترنت (IPv4)، وليس كأجزاء.

IPv4

GRE

IP0

1456 بايت بروتوكول TCP + البيانات

IPv4

GRE

IP1

بيانات 24 بايت

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

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

IP0	1456 بايت بروتوكول TCP + البيانات

IP1	بيانات 24 بايت

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

IPv4	1480 بايت بروتوكول TCP + البيانات

يوضح المثال 2 دور موجه إعادة التوجيه في سياق مخطط شبكة.

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

مثال 2

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

IPv4	1480 بايت بروتوكول TCP + البيانات

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

تنبه رسالة بروتوكول ICMP المرسل إلى أن وحدة الحد الأقصى للنقل (MTU) تبلغ 1476.

IPv4	ICMP MTU 1476

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

IPv4	1456 بايت بروتوكول TCP + البيانات

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

IPv4

GRE

IPv4

1456 بايت بروتوكول TCP + البيانات

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

IPv4	1456 بايت بروتوكول TCP + البيانات

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

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

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

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

يمكن أن يكون بت DF في هذه الحالة إما مضبوطا أو واضحا (1 أو 0).

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

مثال 3

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

IPv4	1456 بايت بروتوكول TCP + البيانات

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

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

IPv4

GRE

IPv4

1456 بايت بروتوكول TCP + البيانات

3. افترض وجود موجه بين مصدر النفق والوجهة مع إرتباط وحدة الحد الأقصى للنقل (MTU) بقيمة 1400.

يقوم الموجه بتقسيم حزمة النفق إلى أجزاء نظرا لأن بت DF واضح (DF = 0).

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

IP0

GRE

IP

1352 بايت TCP + البيانات

IP1	بيانات 104 بايت

4. يجب أن يعيد موجه وجهة النفق تجميع حزمة نفق GRE.

IP

GRE

IP

1456 بايت بروتوكول TCP + البيانات

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

IPv4	1456 بايت TCP + البيانات

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

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

مثال 4

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

IPv4	1456 بايت بروتوكول TCP + البيانات

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

تحتوي رأس GRE IPv4 هذه على مجموعة بت DF (DF = 1) حيث أن مخطط بيانات IPv4 الأصلي كانت به مجموعة بت DF.

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

IPv4

GRE

IPv4

1456 بايت TCP

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

لا يقوم هذا الموجه بتجزئة حزمة النفق لأن بت DF تم ضبطه (DF=1).

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

IPv4	ICMP MTU 1400

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

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

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

مثال 5

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

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

1. يرسل المرسل حزمة بحجم 1500 بايت (رأس IPv4 بحجم 20 بايت + 1480 بايت من حمولة TCP).
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 باستخدام tunnel path-mtu-discoveryالأمر، ويتم نسخ بت DF من الرأس الأصلي IPv4 إلى رأس GRE IPv4.

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

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

1. يستقبل الموجه حزمة بحجم 1500 بايت (رأس IPv4 بحجم 20 بايت + حمولة TCP رقم 1480)، ويقوم بإسقاط الحزمة. يقوم الموجه بإسقاط الحزمة لأنها أكبر من وحدة الحد الأقصى للنقل (MTU) ل IPv4 (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) وتعيين قيمة IPv4 MTU داخلية على واجهة شبكة 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. باستخدام وضع النقل (الذي تم تكوينه باستخدام الأمر الفرعي، mode transport، على تعريف التحويل)، يتم حماية حمولة حزمة IPv4 الأصلية فقط (مشفرة، أو مصادق عليها، أو كلا). يتم تضمين الحمولة بواسطة رؤوس ومقطورات 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

يصف هذا السيناريو تجزئة IPv4sec في الإجراء. في هذا السيناريو، تبلغ قيمة وحدة الحد الأقصى للنقل (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 في نقطة نهاية قسم نفق.

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

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

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

تستند وحدة الحد الأقصى للنقل (MTU) للوسائط إلى وحدة الحد الأقصى للنقل (MTU) الخاصة بواجهة الموجه الصادر وتقوم وحدة الحد الأقصى للنقل (PMTU) على الحد الأدنى لوحدة الحد الأقصى للنقل (MTU) التي يتم رؤيتها على المسار بين نظائر IPv4sec.

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

1. يستقبل الموجه حزمة سعة 1500 بايت ويسقطها لأن مصروفات خدمة IPv4sec، عند إضافتها، تجعل الحزمة أكبر من PMTU (1500).
2. يرسل الموجه رسالة ICMP إلى المضيف 1 يقول فيها أن الخطوة التالية MTU هو 1442 (1500 - 58 = 1442). يمثل هذا الرقم 58 بايت الحد الأقصى لنفقات IPv4sec عند إستخدام IPv4sec ESP و ESPauth. قد يكون مقدار المصروفات الإضافية الحقيقية لبروتوكول IPv4sec أقل من هذه القيمة بمقدار 7 بايت. يقوم المضيف 1 بتسجيل هذه المعلومات، عادة كمسار مضيف للوجهة (المضيف 2)، في جدول التوجيه الخاص به.
3. المضيف 1 يقلل PMTU الخاص به للمضيف 2 إلى 1442، لذلك يرسل المضيف 1 حزم (1442 بايت) أصغر عندما يرسل البيانات إلى المضيف 2. يستقبل الموجه الحزمة ذات 1442 بايت ويضيف IPv4sec 52 بايت من مساحة التشفير الإضافية بحيث تكون الحزمة IPv4sec الناتجة 1496 بايت. لأن هذه الحزمة لها DF Bit Set في رأسها يتم إسقاطها من الموجه الأوسط مع إرتباط MTU بحجم 1400 بايت.
4. يرسل الموجه الأوسط الذي قام بإسقاط الحزمة رسالة ICMP إلى مرسل حزمة IPv4sec (الموجه الأول) الذي يخبره بأن MTU في الخطوة التالية هي 1400 بايت. يتم تسجيل هذه القيمة في IPv4sec SA 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، مما يعني أنه لا يمكنك تشغيل بروتوكول توجيه ديناميكي عبر شبكة IPv4sec VPN.

تدعم أنفاق 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) المحددة	وحدة الحد الأقصى للنقل (MTU) الموصى بها
GRE + IPv4sec (وضع النقل)	1440 بايت	1400 بايت
GRE + IPv4sec (وضع النفق)	1420 بايت	1400 بايت

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

مثال 9

يتم نشر بروتوكول IPv4sec فوق GRE. تبلغ وحدة الحد الأقصى للنقل (MTU) الفعلية الصادرة 1500، بينما تبلغ IPv4sec PMTU 1500، وتبلغ GRE IPv4 MTU 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 بيانات + 20 رأس IPv4).
3. تتضمن GRE أجزاء IPv4، والتي تضيف 24 بايت إلى كل حزمة. وينتج عن ذلك حزمتان لبروتوكول GRE + IPv4sec بحجم 1500 (1476 + 24 = 1500) و 68 (44 + 24) بايت لكل منهما.
4. يقوم IPv4sec بتشفير الحزم، التي تضيف 52 بت (وضع نفق IPv4sec) من فوق عملية التضمين لكل منها، من أجل توفير حزمة بحجم 1552 بايت وحزمة بحجم 120 بايت.
5. تتم تجزئة الحزمة 1552 بايت IPv4sec بواسطة الموجه لأنها أكبر من وحدة الحد الأقصى للنقل (MTU) الصادرة (1500). يتم تقسيم الحزمة ذات 1552 بايت إلى أجزاء، وحزمة سعة 1500 بايت وحزمة سعة 72 بايت (52 بايت "الحمولة" بالإضافة إلى رأس IPv4 إضافي سعة 20 بايت للجزء الثاني). تتم إعادة توجيه الحزم الثلاث التي تتكون من 1500 بايت و 72 بايت و 120 بايت إلى نظير IPv4sec + GRE.
6. يقوم الموجه المتلقي بإعادة تجميع جزأي IPv4sec (1500 بايت و 72 بايت) للحصول على حزمة IPv4sec الأصلية التي تحتوي على 1552 بايت + GRE. لا يلزم القيام بأي شيء لحزمة IPv4sec + GRE ذات 120 بايت.
7. يقوم IPv4sec بفك تشفير كل من حزم IPv4sec ذات 1552 بايت و 120 بايت + GRE للحصول على حزم 1500 بايت و 68 بايت ل GRE.
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.

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

مثال 10

• يستقبل الموجه حزمة بحجم 1500 بايت. يتم إسقاط هذه الحزمة بواسطة GRE لأن GRE لا يمكنه تجزئة الحزمة أو إعادة توجيهها لأن بت DF تم تعيينه، ويتجاوز حجم الحزمة الواجهة الصادرة "ip mtu" بعد إضافة مصروفات GRE (24 بايت).
• يرسل الموجه رسالة ICMP إلى المضيف 1 لإعلامه بأن الخطوة التالية MTU هي 1476 (1500 - 24 = 1476).
• يقوم المضيف 1 بتغيير PMTU الخاص به للمضيف 2 إلى 1476 ويرسل الحجم الأصغر عند إعادة إرسال الحزمة. تقوم GRE بتضمينه وتسليم الحزمة ذات 1500 بايت إلى IPv4sec. يقوم IPv4sec بإسقاط الحزمة لأن GRE قام بنسخ بت DF (مجموعة) من الرأس الداخلي IPv4، ومع إرتفاع IPv4sec (الحد الأقصى 38 بايت)، تكون الحزمة كبيرة جدا لإعادة توجيه الواجهة المادية.
• يرسل IPv4sec رسالة ICMP إلى GRE والتي تشير إلى أن MTU في الخطوة التالية هي 1462 بايت (نظرا لأنه تتم إضافة 38 بايت كحد أقصى للتشفير والنفقات العامة ل IPv4). تسجل GRE القيمة 1438 (1462-24) على أنها "IP MTU" على واجهة النفق.
• ملاحظة: يتم تخزين هذا التغيير في القيمة داخليا ولا يمكن رؤيته في إخراج show ip interface tunnel<#>الأمر. سترى هذا التغيير فقط إذا قمت بتشغيل الأمرdebug tunnel.
• وفي المرة التالية التي يرسل فيها المضيف 1 الحزمة ذات 1476 بايت، تقوم GRE بإسقاطها.
• يرسل الموجه رسالة ICMP إلى المضيف 1 التي تشير إلى أن 1438 هو MTU الخطوة التالية.
• يقوم المضيف 1 بخفض PMTU للمضيف 2 وإعادة إرسال حزمة سعة 1438 بايت. وفي هذه المرة، تقبل GRE الحزمة، وتضمينها، وتوزعها على IPv4sec للتشفير.
• تتم إعادة توجيه حزمة IPv4sec إلى الموجه الوسيط وإسقاطها لأنها تحتوي على وحدة الحد الأقصى للنقل (MTU) للواجهة الصادرة بقيمة 1400.
• يرسل الموجه المتوسط رسالة ICMP إلى IPv4sec التي تخبره بأن الخطوة التالية MTU هي 1400. يتم تسجيل هذه القيمة بواسطة IPv4sec في قيمة PMTU الخاصة ب IPv4sec SA المقترن.
• عند قيام المضيف 1 بإرسال الحزمة ذات 1438 بايت، يقوم GRE بتضمينها وتسليمها إلى IPv4sec. يقوم IPv4sec بإسقاط الحزمة لأنه قام بتغيير PMTU الخاص به إلى 1400.
• يرسل IPv4sec خطأ ICMP إلى GRE والذي يشير إلى أن الخطوة التالية MTU هي 1362، ويسجل GRE القيمة 1338 داخليا.
• عندما يرسل المضيف 1 الحزمة الأصلية (لأنه لم يستلم إقرارا)، تقوم GRE بإسقاطها.
• يرسل الموجه رسالة ICMP إلى المضيف 1 التي تشير إلى أن الخطوة التالية MTU هي 1338 (1362 - 24 بايت). المضيف 1 يخفض PMTU الخاصة به للمضيف 2 إلى 1338.
• يرسل المضيف 1 ربط 1338-بايت، وهذه المرة هو يستطيع أخيرا قطعوا كل الطريق إلى المضيف 2.

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

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

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

وهذا يسمح بتجزئة حزمة GRE IPv4 حتى على الرغم من أن رأس البيانات المغلف IPv4 كان به مجموعة بت DF، والتي عادة لا تسمح بتجزئة الحزمة.

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

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

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

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

يسمح الأمر tunnel path-mtu-discovery بتقليل الحد أكثر من وحدة الحد الأقصى للنقل (MTU) الخاصة بنفق GRE للإصدار الرابع من بروتوكول الإنترنت (IPv4) في حالة وجود إرتباط منخفض لوحدة الحد الأقصى للنقل (MTU) عبر بروتوكول IPv4sec في المسار بين نظائر IPv4sec.

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

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

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

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

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