في بعض الأحيان عندما تمر حركة المرور عبر نفق تضمين التوجيه العام (GRE)، يمكنك إستخدام الأمر ping وبرنامج Telnet بنجاح، ولكن لا يمكنك تنزيل صفحات الإنترنت أو نقل الملفات باستخدام بروتوكول نقل الملفات (FTP). يشرح هذا المستند سببا مشتركا لهذه المشكلة، ويقدم عدة حلول بديلة.
يتطلب هذا المستند وجود فهم أساسي لمعيار GRE. ارجع إلى هذه المستندات لمعرفة المزيد حول GRE:
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
استعملت الأمر lookup أداة (يسجل زبون فقط) أن يجد كثير معلومة على الأمر يستعمل في هذا وثيقة.
راجع اصطلاحات تلميحات Cisco التقنية للحصول على مزيد من المعلومات حول اصطلاحات المستندات.
يستخدم هذا المستند الرسم التخطيطي للشبكة كمثال:
في الرسم التخطيطي أعلاه، عندما يريد العميل الوصول إلى صفحة على الإنترنت، فإنه يؤسس جلسة TCP مع خادم الويب. أثناء هذه العملية، يقوم العميل وخادم الويب بالإعلان عن الحد الأقصى لحجم المقطع (MSS) الخاص بهما، مما يشير لبعضهما البعض إلى إمكانية قبول مقاطع TCP التي يصل حجمها إلى هذا الحجم. عند إستلام خيار MSS، يقوم كل جهاز بحساب حجم المقطع الذي يمكن إرساله. يسمى هذا حجم مقطع الإرسال الأقصى (SMSS)، ويعادل الأصغر من إثنين MSS. لمزيد من المعلومات حول الحد الأقصى لحجم مقطع TCP، راجع RFC 879 .
وللوسيطة، فلنقل أن خادم الويب في المثال أعلاه يحدد أنه يمكنه إرسال حزم يصل طولها إلى 1500 بايت. لذلك فإنه يرسل حزمة 1500 بايت إلى العميل، و، في رأس IP، يضبط بت "عدم التجزئة" (DF). عندما تصل الحزمة إلى R2، يحاول الموجه تضمينها في حزمة النفق. في حالة واجهة نفق GRE، تكون وحدة الحد الأقصى لإرسال IP (MTU) أقل ب 24 بايت من IP MTU الخاص بواجهة الصادر الحقيقية. بالنسبة لواجهة الإيثرنت الصادرة التي تعني أن IP MTU على واجهة النفق ستكون 1500 ناقص 24، أو 1476 بايت.
يحاول R2 إرسال حزمة IP سعة 1500 بايت إلى واجهة IP MTU سعة 1476 بايت. وبما أن هذا غير ممكن، يحتاج R2 إلى تجزئة الحزمة، وإنشاء حزمة واحدة من 1476 بايت (البيانات ورأس IP) وحزمة واحدة من 44 بايت (24 بايت من البيانات ورأس IP جديد من 20 بايت). ثم يقوم R2 بتضمين كل من هذه الحزم للحصول على حزم سعة 1500 و 68 بايت، على التوالي. يمكن إرسال هذه الحزم الآن من الواجهة الصادرة الحقيقية، والتي تحتوي على وحدة الحد الأقصى للنقل (MTU) ل IP سعة 1500 بايت.
على أي حال، تذكر أن الحزمة التي تم استقبالها من قبل R2 تحتوي على مجموعة بت DF. لذلك، لا يمكن أن يجزئ R2 الحزمة، وبدلا من ذلك، يحتاج إلى توجيه خادم الويب لإرسال حزم أصغر. وهو يقوم بذلك عن طريق إرسال حزمة من بروتوكول رسائل التحكم في الإنترنت (ICMP) النوع 3 الرمز 4 (الوجهة التي يتعذر الوصول إليها؛ التجزئة المطلوبة ومجموعة DF). تحتوي رسالة ICMP هذه على وحدة الحد الأقصى للنقل (MTU) الصحيحة التي يجب إستخدامها من قبل خادم الويب، والذي يجب أن يستقبل هذه الرسالة ويضبط حجم الحزمة وفقا لذلك.
ملاحظة: ارجع إلى معلومات مهمة عن أوامر تصحيح الأخطاء قبل أن تستخدم أوامر debug.
يمكنك عرض رسائل ICMP التي يتم إرسالها بواسطة R2 بتمكين الأمر debug ip icmp:
ICMP: dst (10.10.10.10) frag. needed and DF set unreachable sent to 10.1.3.4
تحدث مشكلة شائعة عند حظر رسائل ICMP على طول المسار إلى خادم الويب. وعندما يحدث ذلك، لا تصل حزمة ICMP أبدا إلى خادم الويب، وبالتالي تمنع البيانات من المرور بين العميل والخادم.
لابد أن يحل أحد هذه الحلول الأربعة المشكلة:
اكتشف أين يتم حظر رسالة ICMP على المسار، وانظر ما إذا كان يمكنك الحصول عليها بشكل مسموح به.
قم بتعيين وحدة الحد الأقصى للنقل (MTU) على واجهة شبكة العميل إلى 1476 بايت، مما يفرض على SMSS أن تكون أصغر، لذلك لن يتعين تجزئة الحزم عندما تصل إلى R2. ومع ذلك، إذا قمت بتغيير وحدة الحد الأقصى للنقل (MTU) للعميل، فيجب عليك أيضا تغيير وحدة الحد الأقصى للنقل (MTU) لجميع الأجهزة التي تشارك الشبكة مع هذا العميل. على مقطع إيثرنت، قد يكون هذا عدد كبير من الأجهزة.
أستخدم خادم وكيل (أو محرك ذاكرة التخزين المؤقت للويب بشكل أفضل) بين R2 وموجه البوابة، وأدع خادم الوكيل يطلب كافة صفحات الإنترنت.
إذا كان نفق GRE يعمل عبر إرتباطات يمكن أن تحتوي على وحدة الحد الأقصى للنقل (MTU) أكبر من 1500 بايت بالإضافة إلى رأس النفق، فعندئذ سيكون هناك حل آخر لزيادة وحدة الحد الأقصى للنقل (MTU) إلى 1524 (1500 بالإضافة إلى 24 للزيادة الفائقة لمعدل نقل البيانات (GRE)) على جميع الواجهات والروابط بين موجهات نقاط النهاية ل GRE.
إذا لم تكن الخيارات المذكورة أعلاه ممكنة، يمكن أن تكون هذه الخيارات مفيدة:
أستخدم توجيه السياسة لمسح وتعيين بت DF في حزمة IP للبيانات (المتاحة في برنامج Cisco IOS® الإصدار 12.1(6) والإصدارات الأحدث).
interface ethernet0 ... ip policy route-map clear-df !--- This command is used to identify a route map !--- to use for policy routing on an interface, !--- use the ip policy route-map command in !--- interface configuration mode. route-map clear-df permit 10 match ip address 101 set ip df 0 !--- This command is used to change the Don't Fragment (DF) !--- bit value in the IP header, use this command !--- in route-map configuration mode. access-list 101 permit tcp 10.1.3.0 0.0.0.255 any
وهذا سيسمح بتجزئة حزمة IP للبيانات قبل أن يتم تضمين GRE لها. يجب على المضيف الطرفي المتلقي بعد ذلك إعادة تجميع حزم IP للبيانات. عادة لا تكون هذه مشكلة.
قم بتغيير قيمة خيار TCP MSS على حزم SYN التي تجتاز الموجه (المتاحة في IOS 12.2(4)T والإصدارات الأعلى). وهذا يقلل قيمة خيار MSS في حزمة TCP syn حتى تكون أصغر من القيمة في الأمر ip tcp adjust-mss value، في هذه الحالة 1436 (MTU ناقص حجم رؤوس IP و TCP و GRE). يرسل المضيفون النهائيون الآن حزم TCP/IP التي لا يزيد حجمها عن هذه القيمة.
interface tunnel0 ... ip tcp adjust-mss 1436 !--- This command is used to adjust the maximum segment size (MSS) !--- value of TCP SYN packets going through the router. !--- The maximum segment size is in the range from 500 to 1460.
الخيار النهائي هو زيادة IP MTU على واجهة النفق إلى 1500 (متوفر في IOS 12.0 والإصدارات الأحدث). ومع ذلك، تتسبب زيادة IP MTU النفق في تجزئة حزم النفق لأن بت DF من الحزمة الأصلية لا يتم نسخه إلى رأس حزمة النفق. في هذا السيناريو، يجب أن يقوم الموجه على الطرف الآخر من نفق GRE بإعادة تجميع حزمة نفق GRE قبل أن يتمكن من إزالة رأس GRE وإعادة توجيه الحزمة الداخلية. تتم إعادة تجميع حزمة IP في وضع محول العملية وتستخدم الذاكرة. وبالتالي، يمكن أن يقلل هذا الخيار بشكل كبير من معدل نقل الحزمة عبر نفق GRE.
interface tunnel0 ... ip mtu 1500 !--- This command is used to set the maximum transmission unit (MTU) !--- size of IP packets sent on an interface. The minimum size !--- you can configure is 128 bytes; the maximum depends on the interface medium.
وفي الختام، يرجع السبب الأكثر شيوعا لعدم التمكن من إستعراض الإنترنت عبر نفق GRE إلى مشكلة التجزئة المذكورة أعلاه. ويكون الحل هو السماح لحزم ICMP أو العمل حول مشكلة ICMP باستخدام أي من الحلول المذكورة أعلاه.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
10-Aug-2005 |
الإصدار الأولي |