نکاتی در مورد rip

[farhadnia]

برای پروتکل RIP V1 هیچ گونه مکانیزم احراز هویتی پیش بینی نشده است. برای RIP V2 می توانیم با استفاده از key-chain کلید های متعدد با زمان های اعتبار مشخص تعریف کرد و با استفاده از الگوریتم hash md5 یک مکانیزم احراز هویت برای تصدیق update های رسیده از روتر های مجاور در اختیار داشت.

پروتکل RIPv1 از broadcast برای ارسال پیام های update استفاده می کند در حالی که RIP V2 از multicast 224.0.0.9 ، پروتکل RIP در لایه application کار می کند و برای ارسال update ها از پورت udp 520 بهره می برد ، برخلاف EIGRP و OSPF که در لایه network پیاده سازی شده اند.

در پروتکل RIP مقدار HOP Count به عنوان متریک استفاده می شود ، HOP count تعداد روتر های موجود بین مبدا و مقصد را مشخص می کند.

پروتکل RIP در هر بار ارسال update تنها می تواند 25 آدرس prefix را ارسال کند و این محدودیت بر می گردد به سایز بسته های UDP که نمی توانند بیشتر از 512 بایت باشد.

برای جلوگیری از ایجاد loop در پروتکل RIP مقدار hop count بین مبدا و مقصد محدود به عدد 15 شده است یعنی در پروتکل RIP مقدار 16 برای HOP Count یعنی مسیر معتبر نیست.

پروتکل RIP V1 یک پروتکل Classfull می باشد و از VLSM پشتیبانی نمی کند این پروتکل هیچ فیلدی جهت مشخص کردن subnet mask در پیام های update ندارد ، RIP V2 یک پروتکل Classless می باشد و از VLSM پشتیبانی می کند برای مشخص کردن نسخه مورد استفاده در روتر های سیسکو می توانیم از version [1/2] استفاده کنیم. به صورت پیش فرض نسخه یک فعال است.

پروتکل RIP از مکانیسم های split horizon, route poisoning و holddown جهت جلوگیری از انتشار اطلاعات نامعتبر استفاده می کند.
در زمان استفاده از اینترفیس های multipoint به همراه پروتکل RIP باید با استفاده از دستور no ip split-horizon مکانیسم split-horizon را بر روی اینترفیس multipoint غیر فعال کرد یا اینکه از اینترفیس های point-topoint استفاده کرد.

به صورت پیش فرض هر 30 ثانیه یکبار پیام های update پروتکل RIP که شامل کل اطلاعات جدول مسیر یابی می باشد بر روی اینترفیس های که RIP بر روی آنها فعال است ارسال می شود.

به صورت پیش فرض auto-summary در پروتکل RIP فعال است که با استفاده از دستور no auto-summary در تنظیمات پروتکل RIP می توان این خصوصیت را غیر فعال کرد.

در RIP V2 مکانیزمی به نام External route tags اضافه شده است که امکان متمایز کردن روت های داخلی از روت های redistribute شده در rip توسط الگوریتم های EGP را دارد.

در شکل زیر بسته update پروتکل RIP رو مشاهده می کنید:

در شکل فوق فیلد command می تواند بصورت زیر باشد:
Request با مقدار یک که درخواست برای full update یا partial update است.
Response با مقدار 2 که در حواب فرمان request ارسال می شود.

مقدار پیش فرض AD در پروتکل RIP برابر 120 می باشد که می توان با دستور distance در تنظیمات RIP این مقدار را تغییر داد.

با استفاده از offset-list می توانیم متریک مسیر هایی که از طریق rip یاد گرفته شده اند یا advertise می شوند را فزایش داد. برای این منظور ابتدا باید با استفاده از یک access-list مشخص کنیم که کدام prefix ها شامل این افزایش شوند و بعد در زیر مجموعه دستورات RIP فرمان زیر را وارد می کنیم:

Router(config-router)# offset-list [access-list-number | access-list-name] {in | out} offset [interface-type interface-number]

با استفاده از دستور ip rip send version 1 که بر روی اینترفیس زده می شود می توانیم ترتیبی دهیم تا بر روی آن اینترفیس update های RIP با نسخه خاصی ارسال شود ، با استفاده از این مکانیسم می توانیم RIP V1 را در کنار RIP V2 داشت.

فرمان Router(config-if)# ip rip receive version 1/2 کاری مشابه فرمان قبل در جهت دریافت update انجام می دهد.

ارسال periodic update بر روی اینترفیس های WAN توسط RIP ممکن است مشکلاتی از قبیل Congested شدن لینک بوجود بیاورد ، با استفاده از فرمان Router(config-if)# ip rip triggered که بر روی اینترفیس زده می شود می توان ترتیبی داد تا ارسال periodic اطلاعات روتینگ بر روی اینترفیس متوقف و در صورت وجود تغییری در جدول routing اطلاعات ارسال شود.

با استفاده از فرمان distribute-list می توان ترتیبی داد تا بخشی از شبکه توسط الگوریتم RIP برای روتر های دیگر advertise نشود به این کار route filtering می گویند. برای این کار ابتدا باید با استفاده از یک access-list یا prefix-list لیست prefix هایی که مایل به تبلیغ آنها هستیم یا در صورت استفاده از deny در اکسس لیست یا prefix list لیست prefix هایی که مایل به فیلتر کردن آنها هستیم را مشخص کنیم و بعد مقابل دستور distribute-list قرار دهیم مثال:

access-list 1 permit 1.0.0.0 0.255.255.255
access-list 2 permit 1.2.3.0 0.0.0.255
router rip
distribute-list 2 in ethernet 0
distribute-list 1 in

[Yousef Naimi]

1 - در حالت عادی می توان فقط یک global RIP process داشت ، اما می توانیم instanceهای مختلف پروتکل RIP را داشته باشیم ، به شرطی که به routing table های مختلف اختصاص داده شوند . لذا می توان یک process برای global routing table و چندین subprocess برای vrf tables داشته باشیم .

2 - دستور network فقط شبکه های classful را ساپورت می کند و RIP را روی هر اینترفیسی که در این محدوده باشد فعال می کند . حال اگر چند اینترفیس در محدوده یک major network داشته باشیم و نخواهیم RIP روی همه ی آنها فعال شود ، باید با استفاده از دستور passive-interface یا انواع فیلترینگ ، update ها را کنترل کنیم .

3 - اگر روی اینترفیس تنظیم کنیم که send & receive روی ورژن های 1و2 انجام شود ، در واقع update را دو برابر کرده ایم . زیرا روتر برای آن اینترفیس یک بار با version1 و یک بار دیگر هم با version2 آپدیت ها را ارسال می نماید .

4 - اگر آدرس host را تبلیغ کنیم (network a.b.c.d 255.255.255.255 ) ، هر ورژنی از RIP که باشد ، آدرس را به صورت /32 ارسال می کند .

5 - توجه کنید که تمامی timer ها از زمانی که updateرا دریافت کردند ، شروع به شمارش می کنند .

6 - اگر holddown timer را صفر کنیم ، به این معناست که هرگز holddown نمی شود .

7 - زمان های invalid و flush قاعدتا نباید کمتر از زمان update باشند .

8 - با توجه به خروجی debug ، می بینیم که زمان های نشان داده شده برای timer ها برابر با آن چیزی که کانفیگ کردیم نیستند و کمی اختلاف دارند . علت این امر random jitter هستند که IOS به این علت از آنها استفاده می کند که روتر های مختلف روی یک subnet بطور همزمان periodic update های خود را sync نکنند . RIPv2 jitter برابر با 15% یا 1/6 است .

9 - چنانچه از ما خواستند که بین دو روتر update ها فقط و فقط بصورت unicast ردوبدل شوند ، باید هر دو دستور زیر را با هم بزنیم .

Router(config-router)# neighbor A.B.C.D
Router(config-router)# passive-interface serial 0/0

دستور اول unicast update را فعال می کند و دستور دوم multicast/broadcast update را غیر فعال می نماید .

10 - توجه نمایید که در پروتکل های EIGRP و OSPF ، چنانچه یک اینترفیس را passive کنیم ، پروتکل روی آن اینترفیس غیر فعال می شود . اما در RIP اینگونه نیست و تنها multicast/broadcast update غیر فعال می شوند .

11 - هدف از unicast update اینست که سایر روتر های یک subnet نتوانند Control Plain Update ها را دریافت نمایند .

12 - در حالت broadcast ، همه ی update ها به آدرس 255.255.255.255 ارسال می گردند .
چنانچه بخواهیم آپدیت ها را به آدرس broadcast خاصی ارسال کنیم

Router(config-if)# ip directed-broadcast
Router(config-if)# ip broadcast-address A.B.C.D

اما این یک مشکل امنیتی بوجود می آورد و می توان با استفاده از RIP یک حمله ی DoS انجام داد .
به این ترتیب که فرض کنیم دو روتر R1 و R2 به ترتیب آدرس های 1.1.1.0 و 2.2.2.0 را به درون RIP تبلیغ کرده اند . حال اگر ما از روی Switch3 مثلا یک اینترفیس loopback با آدرسی در محدوده ی یکی از آدرس های بالا بسازیم (مثلا 2.2.2.5) ، سپس از آنجا یک پینگ به مقصد R1 بزنیم ، R1 پاسخ را به R2 می فرستد . لذا با دستور زیر

Switch3# ping 1.1.1.1 source 2.2.2.5 repeat 99999999 timeout 0

به ازای هر host روی این لینک ، یک Reply به R2 ارسال می گردد که این باعث بار زیاد روی R2 و از مدار خارج شدن آن می شود .
این نوع حمله ، بسته به UDP یا ICMP بودن آن ، به ترتیب Fraggle Attack یا Smurf Attack (بخوانید اسمارف) نام دارد .

13 - از offset-list برای فیلتر کردن مسیرها می توان استفاده کرد .
توجه کنید که access-list 0 به معنای تمامی مسیرهاست .
ایراد offset-list اینست که فقط می تواند standard access-list ها را ساپورت کند . زیرا standard ACL ها فقط می توانند بخش آدرس را match کنند و prefix را match نمی کنند .

14 - همیشه قبل از ایجاد ACL یا prefix-list یا route-map ، از دستورات زیر استفاده کنید تا مطمئن شوید همنام آنها وجود ندارد که باعث ایجاد اختلال و مشکل شود .

Router#show access-lists
Router#show ip prefix-list
Router#show route-map

15 - یک تفاوت اساسی بین Authentication و Encryption وجود دارد .
Authentication فقط برای validate کردن update هایی که از سمت همسایه می آیند به کار می رود . لذا payload ها در پروتکل هایی چون RIP یا OSPF فقط authenticate می شوند و encrypt نمی شوند . لذا افراد در میانه ی راه می توانند log ها را ببینند .
اما در IPv6 اینگونه نیست و مثلا در OSPFv3 علاوه بر authentication ، عملیات encryption نیز انجام می شود .

16 - در RIP Authentication ، هنگام وارد کردن پسورد باید خیلی دقت کرد .

چنانچه مثلا به صورت بالا پسورد را وارد کرده و پس از آن یک space و سپس علامت سوالی بزنیم تا بقیه دستور را ببینیم و بعد هم enter کنیم ، آن space وارد شده نیز جزء پسورد به حساب می آید که به سختی قابل تشخیص است و می تواند ایجاد مشکل کند .
البته در خروجی دستور زیر ، پسورد درون “” قرار داده می شود که space قابل مشاهده است .

اما چنانچه از دستور زیر استفاده کنید ، پسورد در کولن قرار نمی گیرد .

البته اگر از Secure CRT استفاده می کنید ، می توانید خروجی را با موس انتخاب کنید تا متوجه فاصله شوید .

17 - در RIP می توان summarization را انجام داد ، اما توجه کنید که نمی توان یک شبکه را کمتر از Major network آن خلاصه کرد . یعنی مثلا اگر یک آدرس متعلق به Class B باشد ، حداکثر می توان تا /16 خلاصه سازی کرد ، اما /15 یا /13 را نمی توان داشت .
برای حل این مشکل ، می توان یک static route به null0 نوشت و سپس آن را redistribute کرد .

[omid-sysad]

با سلام. خیلی خوب توضیح دادی. یه سوال داشتم و اینکه یه شبکه ای که توی packet tracer طراحی کردیم و rip رو هم در اون فعال کردیم. اما با اینکه rip رو فعال کردیم. بازم نمیتونیم از روترها ping بگیریم؟؟!! و اینکه چراروترها همدیگرو تو rip ی که فعال کردیم همدیگرو شناسایی نمیکنن و پینگ نمیدن!