بررسی مکانیزم Fragmentation در IPv4 و مبحث Tunneling

نویسنده: مهدی زمانی زاده
4 ماه پیش

بررسی مکانیزم Fragmentation در IPv4 و مبحث Tunneling

حداکثر سایز Protocol Data Unit (PDU) که یک لایه می تواند از خود عبور دهد را MTU گویند. مقدار MTU در هر پروتکل و هر رسانه انتقال می تواند متفاوت باشد. برای مثال در ذیل به چند نمونه از مقادیر MTU در تکنولوژی های مختلف اشاره شده است:

  • شبکه اترنت (Ethernet) برابر با 1500 بایت
  • شبکه Fiber Channel (FC) برابر با 2148 بایت
  • شبکه سریال برابر با 1500 بایت
  • شبکه Frame Relay برابر با 4470 بایت
  • و شبکه ATM برابر با 4470 بایت

Interface MTU

هر اینترفیس دارای MTU می باشد که حداکثر سایز بسته های ارسالی از آن اینترفیس را مشخص می کند. این مقدار بدون احتساب هدر لایه 2 است. سایز MTU مربوط به Interface نباید از 64 بایت کمتر باشد. تکنولوژی های مذکور در لیست فوق مثالی از این نوع از MTU می باشند.

IP MTU

حداکثر سایز بسته IP که می تواند وارد لایه 2 شود را مشخص می کند. نکته مهم این است اگر مقدار Interface MTU را تغییر دهیم مقدار IP MTU به صورت خودکار به همان مقدار مشخص شده برای Interface تغییر می کند. به عنوان مثال اگر مقدار Interface MTU و IP MTU در حالت پیش فرض باشد (1500 بایت) و ما مقدار Interface MTU را به مقدار جدیدی (به عنوان مثال 1470 بایت) تغییر دهیم آنگاه مقدار IP MTU نیز به صورت خودکار به 1470 بایت تغییر خواهد کرد.

لازم به ذکر است اگر مقدار IP MTU با Interface MTU متفاوت باشد، بسته های ارسالی بر اساس کمترین مقدار MTU ارسال خواهند گردید.

TCP MSS (Maximum Segment Size)

حداکثر مقدار داده ای (Payload) که توسط پروتکل TCP قابل ارسال می باشد را MSS گویند. مقدار MSS بدون در نظر گرفتن هدر لایه های 2، 3 و 4 می باشد. در شبکه اترنت که حداکثر مقدار MTU برابر با 1500 بایت است با کسر مقدار هدر لایه 3 و لایه 4، مقدار MSS برابر با 1460 بایت می باشد.

مکانیزم تعیین MSS در پروسه 3Way Hand Shaking در پروتکل TCP مشخص می گردد. هر کدام از طرفین مقدار MSS را به طرف مقابل اعلام می کنند. لذا هر طرف ارتباط با توجه به مقدار MSS اعلام شده از سمت مقابل Payload خود را در نظر می گیرند. لازم به ذکر است که این پروسه به صورت توافقی نیست و صرفا به طرف مقابل اعلام می گردد.

(IP Header= 20 Byte) – (TCP Header= 20 Byte) = 1460 Byte Payload

در شکل زیر می توانید ساختار MTU در هر لایه را مشاهده کنید:

TCP MSS (Maximum Segment Size)

تکه تکه شدن (Fragmentation) و سرهم بندی مجدد (Reassembly) بسته ها

در پروتکل IPv4 حداکثر سایز Payload می تواند 65535 بایت باشد، اما در اغلب موارد این مقدار توسط پروتکل IP به مقدار مشخص شده برای MTU محدود می شود. لذا برای مدیریت این موضوع در پروتکل IPv4، از تبدیل بسته ها به بسته هایی با سایز کوچکتر استفاده می کنند که به این عمل Fragmentation گفته می شود. بسته هایی که توسط مبدا Fragment می شوند باید بتوانند در سمت گیرنده مجدد Reassemble شوند برای انجام این کار از فیلد های Source ،Destination ،Identification،Total Length ،Fragment Offset  و بیت های Flag در هدر IPv4 استفاده می شود. در ادامه با ذکر مثال به تشریح این موارد خواهیم پرداخت.

در شکل زیر مثالی از Fragment کردن بسته با سایز 5140 بایت به چندین بسته با سایز های کوچکتر را مشاهده می کنیم.

Fragmentation

  • همه ی ترافیک های مربوط به یک Flow خاص از شماره Identifier یکسانی استفاده می کنند.
  • بیت (Don’t Fragment) DF اگر 1 باشد به این معنی می باشد که این بسته نباید Fragment شود.
  • بیت (More Fragment) MF اگر 1 باشد به این معنی است که بسته های بعدی نیز Fragment می باشد و اگر صفر باشد به معنی آخرین بسته Fragment شده می باشد.
  • فیلد Fragment Offset ترتیب بیت ها در Fragmentation را نشان می دهد.

مشکلات ناشی از Fragmentation

پروسه Fragmentation باعث ایجاد Overhead بر روی گیرنده بسته می شود، زیرا گیرنده باید تمامی بسته های Fragment شده را دریافت و سپس آن ها را با هم تلفیق کند که این کار نیاز به تخصیص منابع دارد.

نحوه کنترل کردن بسته هایی که Drop شده اند، یکی دیگر از مواردی است که در Fragmentation اهمیت دارد. اگر یکی از بسته های Fragment شده Drop شوند آن گاه تمامی دیتاگرم IPv4 باید مجددا ارسال شوند.

جلوگیری از Fragment شدن بسته ها با استفاده از TCP MSS

همانطور که قبلا نیز تشریح شد MSS حداکثر Payload ی است که از لایه Application می تواند دریافت شود که این مقدار در IPv4 می تواند حداکثر تا 65535 بایت باشد. در ادامه با ذکر مثال به تشریح این مورد که چگونه تغییر سایز TCP MSS می تواند باعث کنترل مقدار Payload دیتاگرام IPv4 و جلوگیری از Fragmentation شود خواهیم پرداخت.

به منظور جلوگیری از رخداد Fragmentation در دو سمت ارتباط TCP، پروسه انتخاب مقدار MSS از کوچکترین اندازه بافر، MTU اینترفیس و همچنین مقایسه آن با مقدار MSS اعمال شده از طرف مقابل می باشد. شیوه انتخاب MSS به این صورت می باشد که هر Host مقدار MTU اینترفیس خروجی خود را با مقدار بافر خروجی خود مقایسه می کند و سپس کمترین مقدار را انتخاب می کند. معمولا به دلیل سایز بالای بافر، مقدار MTU اینترفیس انتخاب می شود. در مرحله بعدی Host مقدار MSS ارسالی از سمت مقابل را با MTU اینترفیس خود مقایسه و کمترین مقدار را انتخاب می کند.

در مثال زیر به نحوه تصمیم گیری فرستنده برای جلوگیری از Fragmentation می پردازیم:

Fragmentation

مرحله اول: سیستم A بافر خود را با MTU اینترفیس خود مقایسه می کند و مقدار کمتر را به عنوان MSS در نظر می گیرد. (1500 – 40= 1460)

مر حله دوم: سیستم B مقدار MSS دریافتی از A را با مقدار MTU اینترفیس خود مقایسه می کند.

مرحله سوم: سیستم B کمترین مقدار را (1460) برای MSS خود در نظر می گیرد.

مرحله چهارم: سیستم B مقدار بافر خود را با MTU اینترفیس خود مقایسه می کند و کمترین مقدار را برای MSS خود انتخاب می کند. (4462 – 40= 4422)

مرحله پنجم: سیستم A مقدار MSS دریافتی از B را با مقدار MTU اینترفیس خود مقایسه می کند.

مرحله ششم: سیستم A کمترین مقدار را (1460) برای MSS خود در نظر می گیرد.

بررسی تاثیر Tunneling بر روی MTU و MSS

در ابتدا به بررسی هدر GRE خواهیم پرداخت تا مقدار Overhead ناشی از اضافه شدن هدر GRE را مشخص کنیم:

بررسی تاثیر Tunneling بروی MTU و MSS

به صورت پیش فرض هدر GRE دو فیلد اجباری دارد که هر کدام 2 بایت می باشند. فیلد Protocol Type مشخص کننده ی نوع بسته ای است که GRE آن را منتقل می کند و فیلد Flag نیز مشخص کننده این است که آیا از فیلدهای اختیاری استفاده شده است یا خیر.

فیلد های اختیاری GRE فیلدهای Sequence Number ،Checksum و Key می باشند که از فیلد Sequence Number برای Reorder کردن ترافیک های دریافتی از روی Tunnel، فیلد Checksum برای چک کردن سلامت بسته ها و از فیلد Key برای احراز هویت فرستنده بسته استفاده می شود.

سایز هدر GRE بدون در نظر گرفتن فیلدهای اختیاری 4 بایت و با در نظر گرفتن این فیلدها 16 بایت است که در مجموع با توجه به اضافه شدن هدر IP بیرونی، مقدار هدری که به بسته اصلی اضافه می شود حداقل 24 بایت (IP + GRE) و حداکثر 36 بایت (IP + GRE with Optional Header) می باشد.

بررسی تاثیر Tunneling بروی MTU و MSS

یکی از مشکلاتی که بعد از ایجاد Tunneling اتفاق می افتد، Overhead ناشی از اضافه شدن هدر GRE و IP بیرونی می باشد. لذا وقتی که ما GRE Tunnel را Config می کنیم مقدار Overhead ناشی از هدر GRE از MTU اینترفیس کاسته می شود تا با اضافه شدن هدر مقدار آن به 1500 برسد. لذا از این پس هر بسته ای به روتر برسد اگر سایز آن از (1500 – 36) 1464 بیشتر باشد بسته را Fragment می کند.

اما مشکلی که وجود دارد این است که برخی از اپلیکیشن ها با Set کردن بیت DF در هدر IP اجازه Fragment کردن را به روتر نمی دهند که در چنین حالتی اگر سایز بسته از مقدار MTU بیشتر باشد با مشکل مواجه می شود. در این صورت روتری که بسته با سایز بیشتر از MTU اینترفیس خود دریافت می کند با ارسال پیغام ICMP با Type 3 و Code 4 به فرستنده اعلام می کند که بسته نیازمند Fragment شدن است. حال راه حل چیست؟

راه حل اول: می توانیم سایز MTU تمامی سیستم های شبکه را از Overhead ناشی از Tunnel کسر کنیم اما عملا این کار به دلیل حجم زیاد سیستم های موجود در شبکه امکان پذیر نمی باشد.

راه حل دوم: در کل مسیر MTU را به مقدار Overhead ناشی از ایجاد (1536) Tunnel افزایش دهیم. این راه کار نیز با توجه به اینکه تمامی بستر ارتباطی در اختیار ما نمی باشد، عملا امکان پذیر نیست.

راه حل سوم: برای حل مشکل عدم Fragment شدن بسته می توانیم در اینترفیس ورودی روتر مبدا با استفاده از Route-Map مقدار بیت DF را برای ترافیک هایی که از Tunnel عبور می کنند تغییر دهیم تا روتر بتواند بسته را Fragment کند.

tunneling

راه حل چهارم: با استفاده از دستور ip tcp adjust mss 1424 در زیر اینترفیس Tunnel می توانیم دو طرف ارتباط TCP را وادار کنیم تا سایز بسته های خود را به مقدار (1460-36) 1424 کاهش دهند. بدیهی است که این روش فقط مناسب ارتباطات از نوع TCP می باشد.

مکانیزم Path MTU Discovery (PMTUD) جهت تشخیص MTU مسیر

با استفاده از تغییر TCP MSS می توانیم با کنترل سایز ترافیک ارسالی در دو سمت ارتباط TCP مانع از Fragmentation شویم. حال اگر در بین مسیر ارتباطی بین مبدا و مقصد، MTU اینترفیسی از مقدار MTU بسته کمتر بوده و نیاز به Fragment شدن داشته باشد چه باید کرد؟ چگونه می توان کمترین MTU مسیر را تشخیص داد و مانع از Fragment شدن بسته شد؟

مکانیزم PMTUD برای جلوگیری از Fragmentation در مسیر ارتباطی بین مبدا و مقصد استفاده می شود. این مکانیزم جهت تشخیص کمترین MTU مسیر به صورت خودکار مورد استفاده قرار می گیرد.

نکته: مکانیزم PMTUD فقط روی ترافیک های TCP و UDP کاربرد دارد.

مکانیزم PMTUD بدین صورت عمل می کند که روتر با تنظیم کردن بیت DF پیغام های TCP یا UDP، مسیر ارتباطی را بررسی می کند و هرگاه در مسیر با اینترفیسی مواجه شود که مقدار MTU اینترفیس از سایز بسته کمتر باشد آن گاه با ارسال پیغام ICMP با Type 3 و Code 4 به فرستنده اعلام می کند که بسته نیاز به Fragment شدن دارد. فرستنده با دریافت پیغام ICMP مقدار MSS خود را کاهش می دهد و همچنین یک Route /32 با مقدار MTU اعلام شده از جایی که پیغام ICMP دریافت کرده است وارد جدول Routing خود می کند. مکانیزم PMTUD در دو طرف ارتباط به صورت جداگانه باید فعال گردد. لازم به ذکر است که مکانیزم PMTUD به صورت متناوب در حال انجام می باشد، زیرا امکان دارد که MTU بین فرستنده و گیرنده تغییر کند. هرگاه فرستنده، پیغام ICMP از نوع “ Can’t Fragment ” دریافت کند جدول Routing خود را به روز می نماید.

نکته: یکی از شایع ترین مشکلاتی که در زمان استفاده از مکانیزم PMTUD ممکن است اتفاق بیافتد این است که روتر پیغام ICMP را ایجاد کند اما این پیغام در طول مسیر روتر تا فرستنده بسته، توسط روتر یا فایروال Drop شود.

مکانیزم PMTUD بر روی GRE Tunnel

همانطور که می دانیم GRE Tunnel از مکانیزم PMTUD پشتیبانی می کند که در ادامه با ذکر یک نمونه سناریو به تفصیل در مورد نحوه عملکرد این مکانیزم خواهیم پرداخت:

tunneling

مرحله اول: روتر بسته با سایز را 1500 دریافت می کند اما با توجه به اینکه Tunnel MTU برابر با (IP + GRE) 1476 می باشد لذا بسته توسط روتر Drop می شود.

مرحله دوم: روتر با ارسال پیغام (Type:3 , Code: 4) ICMP به فرستنده اعلام می کند که مقدار MTU برابر با 1476 می باشد.

مرحله سوم: فرستنده بسته را با سایز 1476 ارسال می کند و روتر نیز GRE Header را اضافه نموده و بسته را با سایز 1500 ارسال می کند .

مرحله چهارم: بسته با سایز 1500 نمی تواند از لینک با حداکثر سایز 1400 عبور کند و توسط روتر میانی Drop می شود.

مرحله پنجم: روتر میانی با ارسال پیغام (Type:3 , Code: 4) ICMP به روتر مبدا اعلام می کند حداکثر تا میزان 1400 بایت را می تواند ارسال کند. روتر مبدا مقدار MTU خود را به (1400 – 24) 1376 تغییر می دهد.

مرحله ششم: بسته با سایز 1476 از سمت فرستنده برای روتر ارسال می شود اما با توجه به اینکه Tunnel MTU به مقدار 1376 تغییر کرده است لذا بسته توسط روتر رد شده و Drop می شود.

مرحله هفتم: روتر GRE با ارسال پیغام (Type:3 , Code: 4) ICMP به فرستنده مقدار MTU را اعلام می کند.

مرحله هشتم: در مرحله آخر فرستنده مجددا بسته را با سایز 1376 ارسال می کند و با اضافه شدن هدر GRE مقدار آن با سایز 1400 ارسال می شود و به مقصد می رسد.

179
0
0
نظرات