در تونل GRE در صورتی که یکی از طرفین ارتباط تونل قطع شود، طرف مقابل قادر به تشخیص قطعی تونل و down کردن line protocol نیست و لذا ترافیک ها روی مسیر تونل ارسال می شود اما ترافیک تونل هیچگاه به مقصد نمی رسد. 

Down کردن line protocol، در صورتی که انتهای تونل در دسترس نیست، ضروری است تا مسیرهایی که اینترفیس خروجی آنها tunnel است از جدول مسیریابی پاک شده و مسیرهای جایگزین در جدول مسیریابی قرار گیرد.

جالب است بدانید که اینترفیس GRE Tunnel در صورتی که شرایط زیر وجود داشته باشد UP می شود بدون آنکه حتی طرف مقابل اینترفیس Tunnel در دسترس باشد.

  • آدرس مبدا تونل معتبر و اینترفیس آن UP باشد
  • مسیری برای مقصد تونل در جدول مسیریابی وجود داشته باشد

بنابراین در شرایطی که طرف مقابل Tunnel دیده نمی شود و ارتباط Tunnel قطع است، line protocol اینترفیس تونل down نمی شود و مسیرهای غلط از جدول مسیریابی حذف نخواهند شد و مسیریابی ترافیک با مشکل مواجه خواهد شد حتی اگر مسیر جایگزین وجود داشته باشد.

راه حل این مشکل GRE keep-alive است. با واژه keep-alive در پروتکل های مختلف آشنا هستید. اینکه هر یک از طرفین ارتباط بسته کوچکی را به صورت دوره ای به طرف مقابل ارسال می کند و چنانچه هر یک از طرفین قادر به دریافت بسته keep-alive در چند بازه زمانی نباشد، line protocol اینترفیس مربوطه را down می کند.

ارسال Keep-alive در پروتکل GRE کمی با دیگر پروتکل ها و اینترفیس ها متفاوت است. در پروتکل GRE حتی اگر یکی از طرفین ارتباط GRE مکانیزم keep-alive را فعال نکرده باشد، طرف مقابل، که مکانیزم keep-alive روی آن فعال است، قادر به ارسال و  دریافت keep-alive خواهد بود. مکانیزم بدین صورت است که محتویات بسته keep-alive، پاسخی است که قرار است طرف مقابل به ما ارسال نماید. بدین معنی که وقتی طرف مقابل بسته GRE را دریافت می کند و آن را باز می کند، محتویات آن بسته GRE دیگری است که قرار است به ما پاسخ دهد و بنابراین برای پاسخ دادن نیازی نیست تا مکانیزم keep-alive روی آن فعال شده باشد. طرف مقابل ارتباط تونل به محض باز کردن بسته keep-alive با بسته دیگری مواجه می شود که فقط آن را ارسال می کند و از آنجایی که این بسته، بسته پاسخ keep-alive ارسالی است به صورت اتوماتیک به ما بر می گردد.

برای درک بهتر به شکل زیر توجه کنید که در آن ارتباط تونل بین دو روتر A و B برقرار شده است که آدرس دو سر تونل به ترتیب 129.9.9.9 و 128.8.8.8 است. بسته keep-alive در زیر شکل نشان داده شده است. آدرس مبدا و مقصد بسته GRE بیرونی، که همان keep-alive است، به ترتیب روتر A و B هستند. اما محتویات این بسته، بسته GRE دیگری است که آدرس مبدا و مقصد آن بر عکس است. یعنی آدرس مبدا روتر B و آدرس مقصد روتر A است. همچنین مقدار فیلد PT صفر است. وقتی روتر A بسته keep-alive را روی تونل GRE به روتر B ارسال می کند. اگر روتر B بسته مورد نظر را دریافت کند، همانند همه دیگر بسته های دریافتی روی تونل، آن را باز کرده و ارسال می نماید. بسته ارسالی همان پاسخ keep-alive است که به فرستنده بر می گردد. بنابراین طرف مقابل بدون استفاده از مکانیزم keep-alive پاسخ را به فرستنده ارسال نموده است. اگر به هر دلیلی پاسخ برنگردد به معنی down بودن طرف مقابل ارتباط تونل GRE است. بنابراین چنانچه در چند بازه زمانی، فرستنده keep-alive پاسخ را دریافت نکند، line protocol اینترفیس Tunnel خود را down می کند.

GRE

 ساختار GRE keep-alive

با توجه به توضیحات فوق متوجه می شویم که فعال سازی keep-alive در دو طرف ارتباط تونل ضروری نیست. هر طرفی که مکانیزم keep-alive روی آن فعال شده باشد، قادر به تشخیص قطعی ارتباط تونل در طرف مقابل خواهد بود. به عنوان مثال در توپولوژی hub-and-spoke فعال سازی keep-alive در spoke پیشنهاد می شود تا در صورت در دسترس نبودن tunnel در روتر hub، روتر spoke بلافاصله اینترفیس tunnel خود را قطع نماید و مسیر جایگزین به hub پیدا کند. اما فعال سازی keep-alive در طرف hub خیلی مهم نیست. زیرا اگر اینترفیس tunnel در spoke قطع شود و hub متوجه آن نشود، فقط ترافیک hub به مقصد آن spoke خاص با مشکل مواجه می شود.

نکته دیگری که در مورد مکانیزم keep-alive در GRE قابل تامل است اینکه ضرورتی ندارد تا مقادیر زمانی ارسال و دریافت بسته keep-alive در طرفین ارتباط تونل یکسان باشد و مقادیر تنظیم شده روی اینترفیس tunnel تاثیر محلی دارد. در پیکربندی ذیل روتر هر 10 ثانیه روی اینترفیس تونل بسته keep-alive ارسال می کند و چنانچه در مدت زمان 30 ثانیه پاسخ را دریافت نکند، اینترفیس خودش را down می کند.

interface Tunnel0

  keepalive 10  3

فعال سازی keep-alive روی اینترفیس GRE

شکل زیر بسته keep-alive ارسالی از روتر A به روتر B و پاسخ آن را نشان می دهد.

GRE2

نوشتن دیدگاه


تصویر امنیتی
تصویر امنیتی جدید