GNS3 Network Simulation Guide.pdf
5 MB
@Notrobit
راهنمای کار با شبیه ساز شبکه GNS3
راهنمای کار با شبیه ساز شبکه GNS3
لینک عضویت در گروه تخصصی شبکه های کامپیوتری :
سیسکو
مایکروسافت
میکروتیک
و....
https://news.1rj.ru/str/joinchat/BfCO1EF8EebwBdsVUJcOQA
سیسکو
مایکروسافت
میکروتیک
و....
https://news.1rj.ru/str/joinchat/BfCO1EF8EebwBdsVUJcOQA
Notrobit via @vote
🔠 : در سوییچ های شرکت سیسکو بصورت پیش فرض چه مدت زمانی یک Mac Address در جدول Mac Address Table باقی میماند و بعد از آن زمان از بین میرود؟ 300 ثانیه – 64 👍👍👍👍👍👍👍 96% 150 ثانیه – 2 ▫️ 3% 500 ثانیه – 1 ▫️ 1% 100 ثانیه ▫️ 0% 👥 67 people voted so far. Poll…
#پاسخ : 300 ثانیه
توضیحات :
فرایند Switching به دو بخش Learning و Forwarding تقسیم میشود :
Learning :
اون بخشی که جدل Mac Address ساخته میشه.
Forwarding :
اون قسمتی که قرار هست از روش تصمیم گیری که بسته باید به کجا ارسال شه.
بخش اول یعنی Learning در جدول Mac Address Table بصورت Dynamic همزمان با بحث Forwarding انجام میشه.
یعنی زمانی که بسته وارد سوییچ میشه سوییچ همون لحظه از روی Source Mac یاد میگیره که این بسته روی کدوم پورت دریافت شده، به محض اینکه این اتفاق میوفته یک تایمری ست میشه که این تایمر بصورت دیفالت 300 ثانیه هستش.
هرزمان در Session ای که برقرار شده بسته ها پشت هم ارسال و دریافت شن این تایمر همیشه روی 300 میمونه اما به محض اینکه این جریان ترافیک قطع شه و یا به عبارت بهتر Session بسته شه (مثلا یک فایل داشته ارسال میشده که ارسال شده بطور کامل) و دیگه بسته ای پشت سرش ارسال نشه این شمارنده که روی 300 بود شروع میکنه به کم شدن و تا زمانی که این 300 ثانیه تموم نشده این رکورد Mac Address در جدول مک Learn شده باقی میماند و به محض تمام شدن زمان اون رکورد Discard میشه.
با دستور زیر میتوان این تایمر را که بصورت پیش فرض 300 ثانیه می باشد تغییر داد :
switch (config)# mac address-table aging-tine (seconds)
🆔 @Notrobit
توضیحات :
فرایند Switching به دو بخش Learning و Forwarding تقسیم میشود :
Learning :
اون بخشی که جدل Mac Address ساخته میشه.
Forwarding :
اون قسمتی که قرار هست از روش تصمیم گیری که بسته باید به کجا ارسال شه.
بخش اول یعنی Learning در جدول Mac Address Table بصورت Dynamic همزمان با بحث Forwarding انجام میشه.
یعنی زمانی که بسته وارد سوییچ میشه سوییچ همون لحظه از روی Source Mac یاد میگیره که این بسته روی کدوم پورت دریافت شده، به محض اینکه این اتفاق میوفته یک تایمری ست میشه که این تایمر بصورت دیفالت 300 ثانیه هستش.
هرزمان در Session ای که برقرار شده بسته ها پشت هم ارسال و دریافت شن این تایمر همیشه روی 300 میمونه اما به محض اینکه این جریان ترافیک قطع شه و یا به عبارت بهتر Session بسته شه (مثلا یک فایل داشته ارسال میشده که ارسال شده بطور کامل) و دیگه بسته ای پشت سرش ارسال نشه این شمارنده که روی 300 بود شروع میکنه به کم شدن و تا زمانی که این 300 ثانیه تموم نشده این رکورد Mac Address در جدول مک Learn شده باقی میماند و به محض تمام شدن زمان اون رکورد Discard میشه.
با دستور زیر میتوان این تایمر را که بصورت پیش فرض 300 ثانیه می باشد تغییر داد :
switch (config)# mac address-table aging-tine (seconds)
🆔 @Notrobit
سلام خدمت دوستان عزیز در این بخش قصد داریم بریم به سراغ یکی از بخش های جذاب شبکه یعنی روتینگ پروتکل ها در ابتدا بصورت سطحی در رابطه با آنها صحبت خواهیم کرد و در آینده به درون این روتینگ پروتکل ها رفته و بصورت جزئی و دقیق آنهارا بررسی خواهیم کرد.
Routing Protocol Categories :
روتینگ پروتکل ها به دسته های مختلف تقسیم میشوند که هرکدام ویژگی هایی دارند و سعی شده در هر دسته معایب دسته ی دیگر برطرف شده و بهبود یابد.
دسته های مختلف پروتکل ها به این اشاره دارند که چگونه اطلاعات را دریافت،ارسال و نگهداری میکنند.
Distance Vector :
پروتکلهای Distance Vector تمام جدول روتینگ (Routing Table) خود را به همسایه ای که بصورت Directly بهش متصل است ارسال می کند.
بصورت دوره ای این Advertisement ها صورت میگیرد حال یعنی چی؟
یعنی هر مدت زمان یکبار یک روتر تمام جدول روتینگ خود را به همسایه اش ارسال میکند حتی اگر هیچ تغییری صورت نگرفته باشد نیز هنگامی که تایم دوره به پایان برسد تمام جدول روتینگ را ارسال می کنند.
خب میبینم که اگر این Advertisement ها در هربار حتی زمانی که تغییری رخ نداده بصورت کامل جدول روتینگ ارسال شود بسیار ناکارآمد خواهد بود چرا که دقیقا همسایه همان جدول را دارد و این کار تنها ریسورس های روتر را درگیر میکند و پهنای باند زا اشغال میکند.
پس حالت ایده آل میتواند این باشد که تنها زمانی که تغییری رخ میدهد و فقط همان تغییر ارسال شود نه همه ی جدول روتینگ.
پروتکل های Distance Vector معمولا به دو روش از ایجاد Loop جلوگیری میکنند :
Split Horizen :
این ویژگی اینگونه بیان میکند که اگز بر روی یک لینک Update ای دریافت شود و یا به عبارت ساده تر بر روی یک لینک یه شبکه ای یاد گرفته شود از ارسال اون Update بر روی همان لینک جلوگیری میشود.
یعنی اگر بطور مثال شبکه ی 10.10.10.0/24 بر روی لینک فست اترنت 0/2 یاد گرفته شود دیگر این شبکه بر روی همان لینک به روتر دیگری یاد داده نمیشود.
Poison Revers :
این ویژگی اینگونه بیان میکند که مسیری که بر روی یک اینترفیس دریافت میشود اگر از همان اینترفیس بخواهد تبلیغ شود متریک آن به بینهایت سِت میشود و روتر آنرا Discard میکند.
تا به اینجا با دسته پورتکلهای Distance Vector آشنا شدیم در قسمت بعد میپردازیم به پروتکل هایی که در این دسته قرار دارند و هرکدام را بررسی میکنیم امیدوارم که مفید بوده باشد.
#Routing_Protocol
#Category
#Distance_Vector
🆔 @Notrobit
Routing Protocol Categories :
روتینگ پروتکل ها به دسته های مختلف تقسیم میشوند که هرکدام ویژگی هایی دارند و سعی شده در هر دسته معایب دسته ی دیگر برطرف شده و بهبود یابد.
دسته های مختلف پروتکل ها به این اشاره دارند که چگونه اطلاعات را دریافت،ارسال و نگهداری میکنند.
Distance Vector :
پروتکلهای Distance Vector تمام جدول روتینگ (Routing Table) خود را به همسایه ای که بصورت Directly بهش متصل است ارسال می کند.
بصورت دوره ای این Advertisement ها صورت میگیرد حال یعنی چی؟
یعنی هر مدت زمان یکبار یک روتر تمام جدول روتینگ خود را به همسایه اش ارسال میکند حتی اگر هیچ تغییری صورت نگرفته باشد نیز هنگامی که تایم دوره به پایان برسد تمام جدول روتینگ را ارسال می کنند.
خب میبینم که اگر این Advertisement ها در هربار حتی زمانی که تغییری رخ نداده بصورت کامل جدول روتینگ ارسال شود بسیار ناکارآمد خواهد بود چرا که دقیقا همسایه همان جدول را دارد و این کار تنها ریسورس های روتر را درگیر میکند و پهنای باند زا اشغال میکند.
پس حالت ایده آل میتواند این باشد که تنها زمانی که تغییری رخ میدهد و فقط همان تغییر ارسال شود نه همه ی جدول روتینگ.
پروتکل های Distance Vector معمولا به دو روش از ایجاد Loop جلوگیری میکنند :
Split Horizen :
این ویژگی اینگونه بیان میکند که اگز بر روی یک لینک Update ای دریافت شود و یا به عبارت ساده تر بر روی یک لینک یه شبکه ای یاد گرفته شود از ارسال اون Update بر روی همان لینک جلوگیری میشود.
یعنی اگر بطور مثال شبکه ی 10.10.10.0/24 بر روی لینک فست اترنت 0/2 یاد گرفته شود دیگر این شبکه بر روی همان لینک به روتر دیگری یاد داده نمیشود.
Poison Revers :
این ویژگی اینگونه بیان میکند که مسیری که بر روی یک اینترفیس دریافت میشود اگر از همان اینترفیس بخواهد تبلیغ شود متریک آن به بینهایت سِت میشود و روتر آنرا Discard میکند.
تا به اینجا با دسته پورتکلهای Distance Vector آشنا شدیم در قسمت بعد میپردازیم به پروتکل هایی که در این دسته قرار دارند و هرکدام را بررسی میکنیم امیدوارم که مفید بوده باشد.
#Routing_Protocol
#Category
#Distance_Vector
🆔 @Notrobit
سلام خدمت دوستان عزیز در قسمت قبل در رابطه با دسته بندی پروتکل ها شروع به صحبت کردیم و با دسته ی Distance Vector ها آشنا شدیم و در رابطه با نوع عملکرد آن و ویژگی هایش صحبت کردیم در این بخش قصد داریم تا بپردازیم به پروتکلهایی که در این دسته قرار میگیرند.
نکته : دوستان توجه کنید که تنها یک نگاه اجمالی به پروتکل های موجود در دسته بندی ها می اندازیم نه بصورت Advance و Detail وار.
پروتکل هایی که در دسته پروتکلهای Distance Vector قرار میگیرند عبارتند از :
Routing Information Protocol (RIP) :
این پروتکل برای Metric از معیاری به نام Hop-Count استفاده میکند.
بین دو روتر حداکثر باید 15 Hop قرار گرفته باشد و اگر تعداد Hop ها به 16 یا بیشتر برسی به عنوان Metric بی نهایت در نظر گرفته میشود برای جلوگیری از ایجاد Loop.
این پروتکل آپدیت های خودش را بصورت دوره ای هر 30 ثانیه یکبار انجام میدهد و در هر دوره تمامی جدول روتینگ را به همسایه ی خودش ارسال میکند حال اگر روتری از همسایه اش به مدت 180 ثانیه آپدیتی دریافت نکند آن همسایه را بصورت مارک کرده در نظر میگیرد اما انرا از جدول روتینگ حذف نمیکند و 240 ثانیه صبر میکند اگر بازهم آپدیتی دریافت نکرد آنگاه از جدول روتینگ نیز آن همسایه را حذف میکند.
این پروتکل در 3 ورژن عرضه شده است که هرکدام معایب ورژن قبل را پوشش میدهد :
RIP Version 1 :
ورژن اولیه ی پروتکل RIP که امروزه منسوخ شده است چراکه محدودیت و مشکلاتی در آن وجود داشت :
این پروتکل تنها بر روی ip های Classfull کار میکرد و از /CIDRVLSM پشتیبانی نمیکرد.
مشکل بعدی این پروتکل این بود که از Summarization پشتیبانی نمیکرد.
از طرفی این پروتکل برای ارسال آپدیت هایش از Broadcast ارسال میکرد.
و همچنین از Authentication پشتیبانی نمیکرد.
به دلیل مشکلات موجود در RIP Version 1 نسخه ی دیگری از آن عرضه شد تا مشکلات آن رفع شود.
RIP Version 2 :
در این ورژن سعی بر این شد تا مشکلات ورژن قبلی رفع گردد :
این پروتکل یک پروتکل Classless می باشد که از VLSM/CIDR پشتیبانی میکند.
همچنین دیگر ارسال آپدیت ها در این ورژن بصورت Broadcast نمی باشد و آپدیت های روترهای RIP V2 بصورت مالتی کست با آدرس 224.0.0.9 انجام میشود.
از طرف دیگر این ورژن از Authentication پشتیبانی میکند.
و همچنین از Summarization پشتیبانی میکند.
اما این پروتکل تنها از آدرس های IPV4 پشتیبانی میکند و نمیتواند بر روی ادرس های IPV6 کار کند به همین علت نسخه ی بعدی عرضه شد تا این مشکل را رفع کند.
RIP Version 3 (Rip Next Generation (RIPNG)) :
این ورژن بر روی ipv6 کار میکند که با نام Rip Next Generation و یا به اختصار RIPng شناخته میشود
این ورژن از Summarization پشتیبانی نمیکند زیرا در IPV6 چیزی به نام Summarization معنی ندارد و هیچ کلاس بندی IP نداریم.
و آپدیت های خودش را به ادرس مالتی کست FF02::9 ارسال میکند.
مابقی چیز ها همانند RIP V2 میباشد.
دوستان در این بخش در رابطه با RIP که یکی از پروتکلهای دسته ی Distance Vector ها میباشد صحبت کردیم و در قسمت بعدی با پروتکل دیگری از این دسته یعنی EIGRP آشنا میشویم.
#Distance_Vector
#RIP
#Version1_2_3
🆔 @Notrobit
نکته : دوستان توجه کنید که تنها یک نگاه اجمالی به پروتکل های موجود در دسته بندی ها می اندازیم نه بصورت Advance و Detail وار.
پروتکل هایی که در دسته پروتکلهای Distance Vector قرار میگیرند عبارتند از :
Routing Information Protocol (RIP) :
این پروتکل برای Metric از معیاری به نام Hop-Count استفاده میکند.
بین دو روتر حداکثر باید 15 Hop قرار گرفته باشد و اگر تعداد Hop ها به 16 یا بیشتر برسی به عنوان Metric بی نهایت در نظر گرفته میشود برای جلوگیری از ایجاد Loop.
این پروتکل آپدیت های خودش را بصورت دوره ای هر 30 ثانیه یکبار انجام میدهد و در هر دوره تمامی جدول روتینگ را به همسایه ی خودش ارسال میکند حال اگر روتری از همسایه اش به مدت 180 ثانیه آپدیتی دریافت نکند آن همسایه را بصورت مارک کرده در نظر میگیرد اما انرا از جدول روتینگ حذف نمیکند و 240 ثانیه صبر میکند اگر بازهم آپدیتی دریافت نکرد آنگاه از جدول روتینگ نیز آن همسایه را حذف میکند.
این پروتکل در 3 ورژن عرضه شده است که هرکدام معایب ورژن قبل را پوشش میدهد :
RIP Version 1 :
ورژن اولیه ی پروتکل RIP که امروزه منسوخ شده است چراکه محدودیت و مشکلاتی در آن وجود داشت :
این پروتکل تنها بر روی ip های Classfull کار میکرد و از /CIDRVLSM پشتیبانی نمیکرد.
مشکل بعدی این پروتکل این بود که از Summarization پشتیبانی نمیکرد.
از طرفی این پروتکل برای ارسال آپدیت هایش از Broadcast ارسال میکرد.
و همچنین از Authentication پشتیبانی نمیکرد.
به دلیل مشکلات موجود در RIP Version 1 نسخه ی دیگری از آن عرضه شد تا مشکلات آن رفع شود.
RIP Version 2 :
در این ورژن سعی بر این شد تا مشکلات ورژن قبلی رفع گردد :
این پروتکل یک پروتکل Classless می باشد که از VLSM/CIDR پشتیبانی میکند.
همچنین دیگر ارسال آپدیت ها در این ورژن بصورت Broadcast نمی باشد و آپدیت های روترهای RIP V2 بصورت مالتی کست با آدرس 224.0.0.9 انجام میشود.
از طرف دیگر این ورژن از Authentication پشتیبانی میکند.
و همچنین از Summarization پشتیبانی میکند.
اما این پروتکل تنها از آدرس های IPV4 پشتیبانی میکند و نمیتواند بر روی ادرس های IPV6 کار کند به همین علت نسخه ی بعدی عرضه شد تا این مشکل را رفع کند.
RIP Version 3 (Rip Next Generation (RIPNG)) :
این ورژن بر روی ipv6 کار میکند که با نام Rip Next Generation و یا به اختصار RIPng شناخته میشود
این ورژن از Summarization پشتیبانی نمیکند زیرا در IPV6 چیزی به نام Summarization معنی ندارد و هیچ کلاس بندی IP نداریم.
و آپدیت های خودش را به ادرس مالتی کست FF02::9 ارسال میکند.
مابقی چیز ها همانند RIP V2 میباشد.
دوستان در این بخش در رابطه با RIP که یکی از پروتکلهای دسته ی Distance Vector ها میباشد صحبت کردیم و در قسمت بعدی با پروتکل دیگری از این دسته یعنی EIGRP آشنا میشویم.
#Distance_Vector
#RIP
#Version1_2_3
🆔 @Notrobit
لینک عضویت در گروه نوتروبیت
https://news.1rj.ru/str/joinchat/BfCO1EF8EebwBdsVUJcOQA
لینک عضویت در کانال آموزشی نوتروبیت
https://telegram.me/Notrobit
https://news.1rj.ru/str/joinchat/BfCO1EF8EebwBdsVUJcOQA
لینک عضویت در کانال آموزشی نوتروبیت
https://telegram.me/Notrobit
Telegram
مرکز آموزش های تخصصی نوتروبیت
گروه تخصصی شبکه.
پرسش و پاسخ سیسکو مایکروسافت و .....
پرسش و پاسخ سیسکو مایکروسافت و .....
دیتاسنتر پیونن در باهنهون سوئد قرار دارد که قبلا به عنوان پناهگاه ضد اتمی زیر کوه بنا شده بود و اینک به عنوان بزرگترین سرویس دهنده خدمات اینترنتی در سوئد به کاربران خود خدمات میدهد
❗️در دهه 1970 علیه شوروی سابق ساخته شد که بعدا در سال 2007بازسازی شده و تبدیل به دیتا سنتر با سرورهای غول پیکر شد
❗️موتورهای زیر دریایی قدرت برقی معادل1.5 مگاوات را برای این مرکز داده تولید می کنند
❗️این محل بسیار مجهز و ایمن بوده و درب ورودی ضخامتی معادل40 سانت دارد، دارای جنگل و آبشار مصنوعی است و مه غلیظی نیز این محیط را فرا گرفته است
🆔 @Notrobit
http://ow.ly/yYQF30gIRjO
❗️در دهه 1970 علیه شوروی سابق ساخته شد که بعدا در سال 2007بازسازی شده و تبدیل به دیتا سنتر با سرورهای غول پیکر شد
❗️موتورهای زیر دریایی قدرت برقی معادل1.5 مگاوات را برای این مرکز داده تولید می کنند
❗️این محل بسیار مجهز و ایمن بوده و درب ورودی ضخامتی معادل40 سانت دارد، دارای جنگل و آبشار مصنوعی است و مه غلیظی نیز این محیط را فرا گرفته است
🆔 @Notrobit
http://ow.ly/yYQF30gIRjO
کدام یک از آدرس های IPV6 زیر کوتاه ترین آدرس درست : FE80:0000:0000:0000:0010:0000:0000:0123 می باشد ؟
FE80::10:0:0:123 – 41
👍👍👍👍👍👍👍 68%
FE80::10::123 – 11
👍👍 18%
FE80:0:0:0:10::123 – 6
👍 10%
FE8::1::123 – 2
▫️ 3%
👥 60 people voted so far. Poll closed.
FE80::10:0:0:123 – 41
👍👍👍👍👍👍👍 68%
FE80::10::123 – 11
👍👍 18%
FE80:0:0:0:10::123 – 6
👍 10%
FE8::1::123 – 2
▫️ 3%
👥 60 people voted so far. Poll closed.
Notrobit via @vote
کدام یک از آدرس های IPV6 زیر کوتاه ترین آدرس درست : FE80:0000:0000:0000:0010:0000:0000:0123 می باشد ؟ FE80::10:0:0:123 – 41 👍👍👍👍👍👍👍 68% FE80::10::123 – 11 👍👍 18% FE80:0:0:0:10::123 – 6 👍 10% FE8::1::123 – 2 ▫️ 3% 👥 60 people voted so far. Poll closed.
#پاسخ
به دلیل اینکه بیان حجم ادرس های ipv6 رو کم کنن اومدن یکسری قوانین تعریف کردن که این قوانین کمک میکرد تا حجم ادرس های ipv6 را کوتاه کنیم :
1. صفر های قبل از هر عدد در یک Quartet حذف میشوند.
2. صفر های متوالی مثله (0000:0000) و ... را میتوان حذف کرد و جایشان (::) گذاشت اما فقط میتوان یکبار اینکار را انجام داد.
پس در نتیجه ادرس IPV6 ای که در سوال مطرح شده به دو صورت میتوان با این قوانین کوتاه کرد :
FE80::10:0:0:123
FE80:0:0:0:10::123
و همانطور که مشاهده میکنید ادرس اول کوتاه تر است و پاسخ مورد نظر نیز ادرس اول می باشد.
🆔@Notrobit
به دلیل اینکه بیان حجم ادرس های ipv6 رو کم کنن اومدن یکسری قوانین تعریف کردن که این قوانین کمک میکرد تا حجم ادرس های ipv6 را کوتاه کنیم :
1. صفر های قبل از هر عدد در یک Quartet حذف میشوند.
2. صفر های متوالی مثله (0000:0000) و ... را میتوان حذف کرد و جایشان (::) گذاشت اما فقط میتوان یکبار اینکار را انجام داد.
پس در نتیجه ادرس IPV6 ای که در سوال مطرح شده به دو صورت میتوان با این قوانین کوتاه کرد :
FE80::10:0:0:123
FE80:0:0:0:10::123
و همانطور که مشاهده میکنید ادرس اول کوتاه تر است و پاسخ مورد نظر نیز ادرس اول می باشد.
🆔@Notrobit
سلام خدمت دوستان در قسمت قبل در رابطه با یکی از روتینگ پروتکل های دسته ی Distance Vector ها صحبت کردیم و با ویژگی ها و انوا ورژن اون آشنا شدیم در این قسمت قصد داریم بپردازیم به یکی دیگه از روتیتگ پروتکل های موجود در این دسته به نام EIGRP .
Enhanced interior gateway routing protocol :
این پروتکل تا قبل از سال 2013 یک پروتکل اختصاصی برای دیوایس های شرکت سیسکو و یا به عبارت بهتر یک پروتکل Cisco Proprietary بود اما بعد از سال 2013 به عنوان پروتکل استاندارد ایجاد وندور های مختلف نیز حق استفاده از اون داشتند که میتونین به RFC 7868 برای اطلاعات بیشتر مراجعه کنید.
این پروتکل بر خلاف RIP که برای متریک از معیاری به نام Hop-Count استفاده میکرد دیدگاهش نسبت به متریک کمی گسترده تر است و چندین معیار برای انتخاب بهترین مسیر دارد معیار های متریک در پروتکل EIGRP عبارتند از :
K1 =Bandwidth
K2 =load
K3 = Delay
K4 = Reliability
K5 = MTU
ّصورت پیش فرض k1 وk3 در فرمول محاسبه ی متریک قرار دارند.
البته نکته ای که وجود داره این هست که MTU در انتخاب مسیر یا به عبارت بهتر در متریک نقشی ندارد و تنها به عنوان یک Tie Breaker استفاده میشود که اگر فرمول کامل محاسبه ی متریک را نگاه کنید 4 پارامتر و پنج ضریب میبینید و MTU جزء پارامتر ها نیست و تنها زمانی که دو مسیر متریک یکسان داشته باشند اون مسیری الویت داره که MTU بزرگتری داره.
همچنین برخلاف پروتکل RIP که هر 30 ثانیه یکبار تمام جدول روتینگ خود را به همسایه اش ارسال میکرد در EIGRP تنها اولین بار که دو روتر همسایه میشوند بین یکدیگر Full Udate انجام میدهند و بعد از اون تنها در صورت رخ دادن تغییر فقط همون تغییر رو به همسایه ارسال میکنند (Partial Update) و نه تمام جدول را.
پروتکل EIGRP نیز همانند پروتکل RIP برای جلوگیری از RIP از Split Horizen استفاده می کند.
از طرفی این پروتکل یک پروتکل Classless می باشد و از VLSM/CIDR پشتیبانی میکند.
همچنین میدانیم که روتینگ پروتکل ها بر روی مسیر های یکسان میتواند Load Balance کنند اما روتینگ پروتکل EIGRP پاشو فراتر میذاره و میتونه Unequal path load balancing با استفاده از فیچری به نام Variance داشته باشه.
پروتکل EIGRP تنها از Authentication بصورت MD5 پشتیبانی میکند.
در پروتکل EIGRP روتر ها بصورت پیش فرض هر 5 ثانیه یکبار به هم دیگر پیام های Hello ارسال میکنند تا متوجه شوند که همسایگی ها پایدار است اما اگه روتری 15 ثانیه بگذرد و از همسایه اش هیچ Hello ای دریافت نکند اون همسایه رو Fail می بیند و تمامی اطلاعات اون همسایه رو از جدول روتینگش پاک میکند.
این تایم ها با نام Hello Interval و Hold Interval شناخته میشوند که میتوان انهارا تغییر داد.
خب دوستان این هم یک نگاه اجمالی به پروتکل EIGRP در رابطه با پروتکل IGRP صحبت نکردیم چرا که یک پروتکل منسوخ شده می باشد در قسمت بعد میپردازیم به دسته ی دیگر از روتینگ پروتکل ها یعنی Link-State ها.
امیدوارم که مفید بوده باشه .
#EIGRP
#Distance_Vector
🆔 @Notrobit
Enhanced interior gateway routing protocol :
این پروتکل تا قبل از سال 2013 یک پروتکل اختصاصی برای دیوایس های شرکت سیسکو و یا به عبارت بهتر یک پروتکل Cisco Proprietary بود اما بعد از سال 2013 به عنوان پروتکل استاندارد ایجاد وندور های مختلف نیز حق استفاده از اون داشتند که میتونین به RFC 7868 برای اطلاعات بیشتر مراجعه کنید.
این پروتکل بر خلاف RIP که برای متریک از معیاری به نام Hop-Count استفاده میکرد دیدگاهش نسبت به متریک کمی گسترده تر است و چندین معیار برای انتخاب بهترین مسیر دارد معیار های متریک در پروتکل EIGRP عبارتند از :
K1 =Bandwidth
K2 =load
K3 = Delay
K4 = Reliability
K5 = MTU
ّصورت پیش فرض k1 وk3 در فرمول محاسبه ی متریک قرار دارند.
البته نکته ای که وجود داره این هست که MTU در انتخاب مسیر یا به عبارت بهتر در متریک نقشی ندارد و تنها به عنوان یک Tie Breaker استفاده میشود که اگر فرمول کامل محاسبه ی متریک را نگاه کنید 4 پارامتر و پنج ضریب میبینید و MTU جزء پارامتر ها نیست و تنها زمانی که دو مسیر متریک یکسان داشته باشند اون مسیری الویت داره که MTU بزرگتری داره.
همچنین برخلاف پروتکل RIP که هر 30 ثانیه یکبار تمام جدول روتینگ خود را به همسایه اش ارسال میکرد در EIGRP تنها اولین بار که دو روتر همسایه میشوند بین یکدیگر Full Udate انجام میدهند و بعد از اون تنها در صورت رخ دادن تغییر فقط همون تغییر رو به همسایه ارسال میکنند (Partial Update) و نه تمام جدول را.
پروتکل EIGRP نیز همانند پروتکل RIP برای جلوگیری از RIP از Split Horizen استفاده می کند.
از طرفی این پروتکل یک پروتکل Classless می باشد و از VLSM/CIDR پشتیبانی میکند.
همچنین میدانیم که روتینگ پروتکل ها بر روی مسیر های یکسان میتواند Load Balance کنند اما روتینگ پروتکل EIGRP پاشو فراتر میذاره و میتونه Unequal path load balancing با استفاده از فیچری به نام Variance داشته باشه.
پروتکل EIGRP تنها از Authentication بصورت MD5 پشتیبانی میکند.
در پروتکل EIGRP روتر ها بصورت پیش فرض هر 5 ثانیه یکبار به هم دیگر پیام های Hello ارسال میکنند تا متوجه شوند که همسایگی ها پایدار است اما اگه روتری 15 ثانیه بگذرد و از همسایه اش هیچ Hello ای دریافت نکند اون همسایه رو Fail می بیند و تمامی اطلاعات اون همسایه رو از جدول روتینگش پاک میکند.
این تایم ها با نام Hello Interval و Hold Interval شناخته میشوند که میتوان انهارا تغییر داد.
خب دوستان این هم یک نگاه اجمالی به پروتکل EIGRP در رابطه با پروتکل IGRP صحبت نکردیم چرا که یک پروتکل منسوخ شده می باشد در قسمت بعد میپردازیم به دسته ی دیگر از روتینگ پروتکل ها یعنی Link-State ها.
امیدوارم که مفید بوده باشه .
#EIGRP
#Distance_Vector
🆔 @Notrobit