سلامی گرم خدمت دوستان گرامی در این قسمت قصد بر این داریم تا در رابطه با پروتکل Simple Network Management Protocol یا به اختصار SNMP صحبت کنیم و این پروتکل رو مورد بررسی قرار بدیم.
Simple Network Management Protocol (SNMP) :
پروتکل SNMP یک پروتکل مورد استفاده برای مدیریت شبکه می باشد.
این پروتکل برای جمع آوری اطلاعات از Configuration دستگاه های شبکه مانند سرور ها،روترها،سوئیچ و پرینتر و تمامی دستگاهی هایی که در داخل شبکه بر روی پروتکل IP فعالیت میکنند.
پروتکل SNMP شامل دو بخش میباشد :
SNMP Manager :
سیستم مدیریت شبکه که از SNMP برای نظارت و دریافت داده ها از هرتعداد از دستگاه های شبکه استفاده میکند.SNMP Manager معمولا برنامه ای است که در یک مکان مرکزی اجرا میشود.
SNMP Agent :
یک فرایند که برروی دستگاه های شبکه که تحت نظارت هستند اجرا میشود. تمامی داده ها و دیتاها توسط خود دستگاه جمع آوری شده و در یک پایگاه داده محلی ذخیره میشوند. سپس Agent میتواند به Query های SNMP با اطلاعات از دیتابیس محلی خود پاسخ دهد و میتواند Alert و Trap هارا به SNMP Manager ارسال کند.
هر سوئیچ در شبکه بصورت خودکار دیتاهای مربوط به خودش و تمامی اینترفیس هایش را جمع آوری میکند.
این دیتاها در محلی به نام Management Information Base (MIB) در Memory ذخیره شده و بصورت Real Time آپدیت میشوند.
این MIB در ساختار Hierarchical یک ساختار درختی را ایجاد میکند.بصورت ساده تمام MIB مجموعه ای از متغییر ها می باشد که در MIB های جداگانه ذخیره میشوند این این MIB ها شاخه های این درخت را تشکیل میدهند.
هر MIB براساس زبان Abstract Syntax Notation 1 (ASN.1) میباشد.هر متغییر در MIB با یک شناسه به نام object identifier(OID) وجود دارد که یک رشته ی طولانی که مسیر Root Tree تا مکان دقیق متغییر دنبال میکند.
برای دیدن هریک از اطلاعات MIB باید SNMP Manager یک SNMP Poll و یا Query را به سو.یچ ارسال کند.
این Query حاوی OID متغییری است که SNMP Manager درخواست کرده تا Agent در حال اجرا بر روی سوییچ متوجه میشود که چه اطلاعاتی برای بازگشت وجود دارد.
حال SNMP Manager میتواند با استفاده از یکسری از مکانیزم ها با SNMP Agent ارتباط برقرار کند و همچنین تمامی این ارتباط بر روی پروت UDP 161 میباشد. :
Get Request :
یک مقدار (Value) خاص MIB مورد نیاز می باشد.
Get Next Request :
مقدار بعدی از درخواست اولیه ی دریافتی مورد نیاز می باشد.
Get Bulk Request :
جدول کامل و یا لیست مقادیر در یک متغییر MIB مورد نیاز می باشد.
Set Request :
یک متغییر خاص MIB باید به یک مقدار تنظیم شود.
بعد از متوجه شدن نوع برقراری ارتباط بین SNMP Manager و SNMP Agent حال بین این دو اطلاعاتی رد و بدل میشود.
پیام های SNMP Poll و یا Request ها معمولا بصورت دوره ای توسط SNMP Manager ارسال میشوند.این مشکلاتی از قبیل سخت شدن مانتیورینگ میشود زیرا تا بازه ی بعدی متوجه مشکلات نمیشود.
با این حال SNMP Agent میتواند Alert های ناخواسته را به SNMP Managerبصورت Real-Time ارسال کند این Alert ها میتواند با مکانیزم های زیر بر روی پورت UDP 162 ارسال شوند :
SNMP Trap :
اخبار مربوط به Event های (تغییر وضعیت اینترفیس ها که UP/DOWN شدن یا خیر ،Device Failure و ...هرچیزی) بدون هیچ Ack ای که بگه این Alert ها دریافت شدن.
Informs Request :
اخبار یک Event به SNMP Manager ارسال میشود و Manager باید به Agent یک Ack مبنی بر تایید کردن اینکه اون اطلاعات دریافت شده بفرستد.
پروتکل SNMP در سه ورژن موجود می باشد :
SNMP Version 1 :
از یک متغییر ساده Get و Set Request همراه با یک SNMP Trap ساده استفاده میکند. SNMP Manager با تطبیق یک Community text String میتواند به SNMP Agent ها دسترسی پیدا کند.
هنگامی که Manager میخواد یک متغییر MIB را در یک دستگاه بخواند و یا آنرا بنویسد یک Community String به عنوان بخشی از Request ارسال میکند.
در تئوری اینگونه بیان شده که Manager و Agent تنها به شرط یکسان بودن Community ها میتونن باهم ارتباط برقرار کنند. اما در عمل و واقعیت هردستگاه توانایی خواندن و نوشتن متغییرها به دیتایس MIB یه Agent با ارسال رشته ی Community درست و مناسب بدونه اینکه ایا اون دستگاه SNMP Manager است یا خیر که این یک حفره ی امنیتی بزرگ در SNMP ایجاد میکند.
SNMP Version 2 :
Simple Network Management Protocol (SNMP) :
پروتکل SNMP یک پروتکل مورد استفاده برای مدیریت شبکه می باشد.
این پروتکل برای جمع آوری اطلاعات از Configuration دستگاه های شبکه مانند سرور ها،روترها،سوئیچ و پرینتر و تمامی دستگاهی هایی که در داخل شبکه بر روی پروتکل IP فعالیت میکنند.
پروتکل SNMP شامل دو بخش میباشد :
SNMP Manager :
سیستم مدیریت شبکه که از SNMP برای نظارت و دریافت داده ها از هرتعداد از دستگاه های شبکه استفاده میکند.SNMP Manager معمولا برنامه ای است که در یک مکان مرکزی اجرا میشود.
SNMP Agent :
یک فرایند که برروی دستگاه های شبکه که تحت نظارت هستند اجرا میشود. تمامی داده ها و دیتاها توسط خود دستگاه جمع آوری شده و در یک پایگاه داده محلی ذخیره میشوند. سپس Agent میتواند به Query های SNMP با اطلاعات از دیتابیس محلی خود پاسخ دهد و میتواند Alert و Trap هارا به SNMP Manager ارسال کند.
هر سوئیچ در شبکه بصورت خودکار دیتاهای مربوط به خودش و تمامی اینترفیس هایش را جمع آوری میکند.
این دیتاها در محلی به نام Management Information Base (MIB) در Memory ذخیره شده و بصورت Real Time آپدیت میشوند.
این MIB در ساختار Hierarchical یک ساختار درختی را ایجاد میکند.بصورت ساده تمام MIB مجموعه ای از متغییر ها می باشد که در MIB های جداگانه ذخیره میشوند این این MIB ها شاخه های این درخت را تشکیل میدهند.
هر MIB براساس زبان Abstract Syntax Notation 1 (ASN.1) میباشد.هر متغییر در MIB با یک شناسه به نام object identifier(OID) وجود دارد که یک رشته ی طولانی که مسیر Root Tree تا مکان دقیق متغییر دنبال میکند.
برای دیدن هریک از اطلاعات MIB باید SNMP Manager یک SNMP Poll و یا Query را به سو.یچ ارسال کند.
این Query حاوی OID متغییری است که SNMP Manager درخواست کرده تا Agent در حال اجرا بر روی سوییچ متوجه میشود که چه اطلاعاتی برای بازگشت وجود دارد.
حال SNMP Manager میتواند با استفاده از یکسری از مکانیزم ها با SNMP Agent ارتباط برقرار کند و همچنین تمامی این ارتباط بر روی پروت UDP 161 میباشد. :
Get Request :
یک مقدار (Value) خاص MIB مورد نیاز می باشد.
Get Next Request :
مقدار بعدی از درخواست اولیه ی دریافتی مورد نیاز می باشد.
Get Bulk Request :
جدول کامل و یا لیست مقادیر در یک متغییر MIB مورد نیاز می باشد.
Set Request :
یک متغییر خاص MIB باید به یک مقدار تنظیم شود.
بعد از متوجه شدن نوع برقراری ارتباط بین SNMP Manager و SNMP Agent حال بین این دو اطلاعاتی رد و بدل میشود.
پیام های SNMP Poll و یا Request ها معمولا بصورت دوره ای توسط SNMP Manager ارسال میشوند.این مشکلاتی از قبیل سخت شدن مانتیورینگ میشود زیرا تا بازه ی بعدی متوجه مشکلات نمیشود.
با این حال SNMP Agent میتواند Alert های ناخواسته را به SNMP Managerبصورت Real-Time ارسال کند این Alert ها میتواند با مکانیزم های زیر بر روی پورت UDP 162 ارسال شوند :
SNMP Trap :
اخبار مربوط به Event های (تغییر وضعیت اینترفیس ها که UP/DOWN شدن یا خیر ،Device Failure و ...هرچیزی) بدون هیچ Ack ای که بگه این Alert ها دریافت شدن.
Informs Request :
اخبار یک Event به SNMP Manager ارسال میشود و Manager باید به Agent یک Ack مبنی بر تایید کردن اینکه اون اطلاعات دریافت شده بفرستد.
پروتکل SNMP در سه ورژن موجود می باشد :
SNMP Version 1 :
از یک متغییر ساده Get و Set Request همراه با یک SNMP Trap ساده استفاده میکند. SNMP Manager با تطبیق یک Community text String میتواند به SNMP Agent ها دسترسی پیدا کند.
هنگامی که Manager میخواد یک متغییر MIB را در یک دستگاه بخواند و یا آنرا بنویسد یک Community String به عنوان بخشی از Request ارسال میکند.
در تئوری اینگونه بیان شده که Manager و Agent تنها به شرط یکسان بودن Community ها میتونن باهم ارتباط برقرار کنند. اما در عمل و واقعیت هردستگاه توانایی خواندن و نوشتن متغییرها به دیتایس MIB یه Agent با ارسال رشته ی Community درست و مناسب بدونه اینکه ایا اون دستگاه SNMP Manager است یا خیر که این یک حفره ی امنیتی بزرگ در SNMP ایجاد میکند.
SNMP Version 2 :
نسخه ی دوم SNMP برای رفع برخی ضعف های امنیتی و نگرانی ها بوجود اومد.
بطور مثال در SNMP V1 شمارنده ی متغییر (Variable Counters) یکم معنی کردنشون سخته :) 32 بیتی بود که در SNMP V2 به 64 بیت تغییر کرد.
علاوه بر این SNMP V2 یک Request یعنی Bulk Request را نیز عرضه میکند که در SNMP V1 وجود نداشت و با استفاده از آن میتوان متغییر های MIB را با یک Request مجزا در یک فرم بزرگ بازیابی کرد. همچنین Event های ارسال شده از یک SNMP Agent میتواند به شکل SNMP Trap و یا Inform Request اطلاع رسانی شوند.(توجه داشته باشید که Inform Request نیاز به Ack از سمته SNMP Manager دارد که تایید کند پیام دریافت شده)
نکته : در SNMP V2 هیچ یک از مشکلات امنیتی در SNMP V1 رفع نشده است. همچنین پیاده سازی های دیگری از SNMP V2 وجود داشت که با SNMP V2C ناسزگار بودند که این دو مانع از گسترش این ورژن و دلیلی برای عرضه ی ورژن جدید تر شدند.
SNMP Version 3 :
اخرین ورژن SNMP که در حال حاضر از آن استفاده میشود SNMP V3 می باشد.
در این ورژن تمامی مشکلات امنیتی که در ورژن های قبل موجود بود را رفع شده است.
ورژن 3 SNMP میتواند با استفاده از Username (نام کاربری) SNMP Manager هارا Authenticate (تایید) کند.
هنگامی که بر روی SNMP Agent ها Username کانفیگ شود میتوان آنهارا در گروه های SNMP V3 سازماندهی کرد.
همچنین دسترسی به اطلاعات هر MIB را میتوان بر اساس هر گروه کنترل کرد.میتوان تایید کرد که کدام مقدار های MIB از Tree را میتوان خواند یا نوشت.
هر گروه SNMPv3 با یک سطح امنیتی تعریف شده است که از میزان مشخصی از داده های SNMP محافظت می کند.
پکت های داده ها میتوانند Authenticate شوند برای حفظ یکپارچگی و همچنین میتوانند Encrypt شوند برای رمزگذاری داده ها و یا هردوی آنها.
ممکن است در دیدن نام آنها گیج شوید در طرح نام گذاری Auth همان Authentication و Priv همان Encryption می باشد.
حال نگاهی به این سطح های امنیتی بی اندازیم :
noAuthNoPriv :
پکت های SNMP نه Authenticate و نه Encrypt میشوند.
AuthNoPriv :
پکت های SNMP احراز هویت Authenticate میشوند اما Encrypt نمیشوند.
AuthPriv :
پکت های SNMP هم Authenticate و هم Encrypt میشوند.
به عنوان Best Practice باید از SNMP V3 برای استفاده از ویژگی های امنیتی استفاده شود.
خب دوستان این هم یک بررسی اجمالی در رابطه با پروتکل SNMP امیدوارم مفید بوده باشه.
#Simple_Network_Management_Protocol
#SNMP
#version1_version2_version3
🆔 @Notrobit
بطور مثال در SNMP V1 شمارنده ی متغییر (Variable Counters) یکم معنی کردنشون سخته :) 32 بیتی بود که در SNMP V2 به 64 بیت تغییر کرد.
علاوه بر این SNMP V2 یک Request یعنی Bulk Request را نیز عرضه میکند که در SNMP V1 وجود نداشت و با استفاده از آن میتوان متغییر های MIB را با یک Request مجزا در یک فرم بزرگ بازیابی کرد. همچنین Event های ارسال شده از یک SNMP Agent میتواند به شکل SNMP Trap و یا Inform Request اطلاع رسانی شوند.(توجه داشته باشید که Inform Request نیاز به Ack از سمته SNMP Manager دارد که تایید کند پیام دریافت شده)
نکته : در SNMP V2 هیچ یک از مشکلات امنیتی در SNMP V1 رفع نشده است. همچنین پیاده سازی های دیگری از SNMP V2 وجود داشت که با SNMP V2C ناسزگار بودند که این دو مانع از گسترش این ورژن و دلیلی برای عرضه ی ورژن جدید تر شدند.
SNMP Version 3 :
اخرین ورژن SNMP که در حال حاضر از آن استفاده میشود SNMP V3 می باشد.
در این ورژن تمامی مشکلات امنیتی که در ورژن های قبل موجود بود را رفع شده است.
ورژن 3 SNMP میتواند با استفاده از Username (نام کاربری) SNMP Manager هارا Authenticate (تایید) کند.
هنگامی که بر روی SNMP Agent ها Username کانفیگ شود میتوان آنهارا در گروه های SNMP V3 سازماندهی کرد.
همچنین دسترسی به اطلاعات هر MIB را میتوان بر اساس هر گروه کنترل کرد.میتوان تایید کرد که کدام مقدار های MIB از Tree را میتوان خواند یا نوشت.
هر گروه SNMPv3 با یک سطح امنیتی تعریف شده است که از میزان مشخصی از داده های SNMP محافظت می کند.
پکت های داده ها میتوانند Authenticate شوند برای حفظ یکپارچگی و همچنین میتوانند Encrypt شوند برای رمزگذاری داده ها و یا هردوی آنها.
ممکن است در دیدن نام آنها گیج شوید در طرح نام گذاری Auth همان Authentication و Priv همان Encryption می باشد.
حال نگاهی به این سطح های امنیتی بی اندازیم :
noAuthNoPriv :
پکت های SNMP نه Authenticate و نه Encrypt میشوند.
AuthNoPriv :
پکت های SNMP احراز هویت Authenticate میشوند اما Encrypt نمیشوند.
AuthPriv :
پکت های SNMP هم Authenticate و هم Encrypt میشوند.
به عنوان Best Practice باید از SNMP V3 برای استفاده از ویژگی های امنیتی استفاده شود.
خب دوستان این هم یک بررسی اجمالی در رابطه با پروتکل SNMP امیدوارم مفید بوده باشه.
#Simple_Network_Management_Protocol
#SNMP
#version1_version2_version3
🆔 @Notrobit
Media is too big
VIEW IN TELEGRAM
آموزش صوتی و تصویری LAN Network Design
مدرس: مهندس محمد طاهری
پارت: دوم
زمان اموزش: 20 دقیقه
🔎#Scenario
🆔 @Notrobit
💠Manager: @taheri1990
🔎 #Video
مدرس: مهندس محمد طاهری
پارت: دوم
زمان اموزش: 20 دقیقه
🔎#Scenario
🆔 @Notrobit
💠Manager: @taheri1990
🔎 #Video
🔠 : در سوییچ های شرکت سیسکو بصورت پیش فرض چه مدت زمانی یک Mac Address در جدول Mac Address Table باقی میماند و بعد از آن زمان از بین میرود؟
300 ثانیه – 64
👍👍👍👍👍👍👍 96%
150 ثانیه – 2
▫️ 3%
500 ثانیه – 1
▫️ 1%
100 ثانیه
▫️ 0%
👥 67 people voted so far. Poll closed.
300 ثانیه – 64
👍👍👍👍👍👍👍 96%
150 ثانیه – 2
▫️ 3%
500 ثانیه – 1
▫️ 1%
100 ثانیه
▫️ 0%
👥 67 people voted so far. Poll closed.
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