آموزش CCNAآموزش شبکهسیسکو

آموزش CCNA : توضیح جامعی از پروتکل مسیریابی EIGRP یا Enhanced Interior Gateway Routing Protocol

ما در چند پست اخیر درباره Static Routing و همچنین Dynamic Routing ها و پروتکل مسیریابی RIP صحبت کردیم، حالا وقت صحبت درباره پروتکل مسیریابی EIGRP یا Enhanced Interior Gateway Routing Protocol می باشد

پروتکل EIGRP توسط سیسکو معرفی شده و افرادی که کمی پیگیر جریان پروتکل ها هستن خوب می دونن که نهایتا در ماه مه سال 2016، RFC 7868 تحت عنوان ” Cisco’s Enhanced Interior Gateway Routing Protocol – EIGRP” منتشر شد. به عقیده ی خیلیا این RFC معرفی کننده ی EIGRP اصیلی که روی دستگاه های شرکت سیسکو پیاده سازی شده نیست. اما قصد ما اینه که با رفتار این پروتکل متناسب با RFC آشنا بشیم اما اون بخشی از عملکرد این پروتکل که در RFC لحاظ نشده هم سعی می کنیم نهایتا با هم بررسی کنیم.

برای معرفی EIGRP باید به زمانی برگشت که توسعه دهندگان پروتکل IGRP که یک پروتکل اختصاصی شرکت سیسکو بود تصمیم بر توسعه ی این پروتکل گرفته و در صدد تبدیل آن به یک پروتکل Classless برآمدند. اما همزمان با تلاش برای بهبود قابلیت های عملکردی پروتکل IGRP، بر آن شدند تا از الگوریتم های آکادمیکی که در رابطه با بهبود زمان همگرایی بودند نیز در راستای این توسعه کمک گیرند. در نتیجه آن ها نه تنها به هدف خود یعنی ارتقای IGRP دست پیدا کردند بلکه سبب ایجاد پروتکل مسیریابی جدیدی شدند که با وجود برخی شباهت ها در رفتار به IGRP، یک پروتکل کاملا مجزا محسوب می شود.

EIGRP از یک سیستم محاسباتی جدید با نام Defusing Computation بهره می گیرد. از سوی دیگر  Distance Vector ها آپدیت های خود را به صورت دوره ای بعد از گذشت یک مدت زمان مشخص ارسال می کنند و نوع گزارش مسیرها نیز به صورت برداری از direction/distance می باشد. EIGRP هم از فرمول Direction/Distance برای گزارش مسیرها استفاده میکند اما آپدیت هایش دیگر به صورت دوره ای نیست بلکه دارای سه ویژگی است:

1- غیر دوره ای (یا همان non-periodic)
2- جزیی ( یا همان Partial)
3- محدود (یا همان Bounded)

اما منظور از هر کدام این موارد چیست؟ غیر دوره ای بودن آپدیت ها به معنی عدم ارسال آپدیت ها بعد از گذشت یک بازه زمانی مشخص می باشد، تنها زمانی که تغییری در توپولوژی رخ دهد، آپدیتی ارسال خواهد شد (خاطر نشان می گردد که هر تغییری نیز باعث ارسال آپدیت نخواهد شد و به این امر در قسمت های بعدی این مجموعه پرداخته می شود)

منظور از جزیی بودن آن است که برخلاف Distance Vector ها که کل جدول روت خود را به صورت دوره ای ارسال می کردند، EIGRP فقط مسیرهایی که دچار تغییری شده باشند، در قالب آپدیت ارسال می کند و منظور از محدود بودن آن است که آپدیت ها فقط برای روترهایی ارسال می شوند که تحت تاثیر تغییر رخ داده باشند.

با کمی تامل این گونه به نظر می آید که بسیاری از رفتارهای Distance Vector ها در EIGRP بهینه شده و اولین موضوعی که تا اینجا شاید بتوان  به آن اشاره نمود آن باشد که با این تغییرات در ارسال آپدیت، EIGRP پهنای باند کم تری نسبت به سایر Distance Vector ها مصرف می نماید.

مساله ی دیگر در رابطه با EIGRP که آن را از Distance Vector ها کمی متمایز می کند آن است که EIGRP برای لینک های کم سرعت هم راهکار ارائه می دهد به این صورت که EIGRP برای ارسال ترافیک خود تنها از 50 درصد bandwidth لینک استفاده می کند.

نکته ی بعدی در رابطه با EIGRP و تفاوتش با سایر Distance Vector ها آن است که، سایر Distance Vector ها برای به دست آوردن فاصله تا هر مقصد فقط به تعداد گام تا آن مقصد توجه می کنند.  یعنی هر مسیری که تعداد گام کم تری تا مقصد داشته باشد، دارای اولویت بیشتری است. حال تصور کنید که برای رسیدن به مقصدی مانند A دو راه وجود داشته باشد، یک مسیر با یک گام و از طریق یک لینک سریال و  مسیر دیگر با دو گام ولی هر دو گام از طریق لینک اترنت. Distance Vector ها مسیر از سمت لینک سریال را انتخاب می کنند، چرا که تعداد گام کم تری دارد در حالی که با این تصمیم گیری، پهنای باند قربانی تعداد گام می شود! شاید مسیر از سمت لینک اترنت دو گام دورتر باشد ولی باز هم پهنای باند بهتری نسبت به مسیر یک گامی لینک سریال دارد. در چنین شرایطی سایر Distance Vector ها با استفاده از روش های دیگر کاری می کنند که برای مسیر با پهنای باند کم تر و تعداد گام کم تر، متریک بیش تری  تبلیغ شود و در نتیجه مسیر با تعداد گام بیشتر به عنوان مسیر اصلی برای ارسال ترافیک انتخاب شود.

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

این پارامترها چه هستند و از کجا می آیند؟ از نظر EIGRP در تعیین مسیر بهتر، لینک مهم ترین نقش را دارد. پس برای انتخاب مسیر بهتر به پارامترهای وابسته به لینک توجه می کند. این پارامترها عبارتند از: Bandwidth، Delay، Load و Reliability. عده ای MTU یا همان حداکثر واحد انتقال لینک را نیز به عنوان یکی از پارامترهای محاسبه متریک عنوان می کنند اما دقت داشته باشید که درست است که این پارامتر به همراه سایر پارامترهای متریک (و همین طور Hop-Count) به همسایه ها گزارش داده می شود، اما هیچ نقشی در محاسبه متریک ندارد. از آن جایی که EIGRP از ترکیبی از چند پارامتر برای محاسبه ی متریک استفاده می کند، به این متریک اصطلاحا Composite metric گفته می شود. در اصل این روش محاسبه ی متریک را، EIGRP از جد خود یعنی IGRP به ارث برده است.

     K1 = Bandwidth  
     K2 = Load       
     K3 = Delay      
K4 & K5 = Reliability

EIGRP برای این که به یکسری از پارامترهای محاسبه ی متریک اولویت بیش تری نسبت به سایر موارد بدهد، از ضرایبی استفاده می کند که به آن ها K Value هاگفته می شود. از طرف دیگر برای این که متریک 24 بیتی که IGRP از آن استفاده می نموده، به یک متریک 32 بیتی مبدل شود، در فرمول، کل پارامترها در یک 256 نیز ضرب می شوند و به این ترتیب فرمول محاسبه ی Composite metric به صورت زیر در می آید:

metric = 256 * ({(K1*BW) + [(K2*BW)/(256-LOAD)] + (K3*DELAY)}*(K5/(REL+K4)))

eigrp metric formula
eigrp metric formula

به صورت پیش فرض EIGRP زمان محاسبه ی متریک فقط از Bandwidth و Delay استفاده می کند و برای آن که فقط این دو پارامتر در محاسبه ی متریک استفاده شوند، به ضریب K آنها مقدار یک داده و به ضرایب K سایر پارامترها مقدار 0 می دهد. منظور از Bandwidth در فرمول Composite metric، کوچکترین Bandwidth در بین Bandwidth ها در طول کل مسیر و منظور از Delay ، مجموع کل Delay های اینترفیس های خروجی در طول مسیر رسیدن به مقصد می باشد.

Bandwidth ای که در فرمول محاسبه ی متریک قرار می گیرد از تقسیم 107 تقسیم بر کوچکترین Bandwidth در طول کل مسیر به دست می آید. منظور از این Bandwidth ،Bandwidth حقیقی لینک نیست بلکه Bandwidth ای است که به صورت استاتیک به اینترفیس اختصاص داده شده و قابل تغییر می باشد. نکته ی دیگر آن که  Delay ها نیز به صورت استاتیک برای اینترفیس ها تعیین می شوند و قابل تغییر می باشند. زمان قرار گرفتن Delay اختصاص پیدا کرده به یک اینترفیس در فرمول محاسبه ی متریک، مقدار Delay تقسیم بر 10 شده و به این ترتیب مجموع Delay هایی که در رابطه ی محاسبه ی متریک قرار می گیرند بر حسب tens of microsecound خواهد شد. با تمام این توضیحات، اگر مقدار ضرایب K را به صورت پیش فرض در نظر بگیریم، نهایتا فرمول محاسبه ی متریک EIGRP به صورت زیر در خواهد آمد:

 metric = 256 * { [(10^7)/ BWmin] + [sum of delays]}

مشکلی که در رابطه با فرمول محاسبه ی متریک به این شیوه وجود دارد آن است که این رابطه جوابگوی لینک هایی با ‏bandwidth‏ بالا نیست (یعنی برای یک لینک ‏‎10G:256*107/107=256‎‏ و برای یک لینک ‏‎40G‎‏ هم ‏bandwidth EIGRP‏ برابر است با 256) و از سوی دیگر حداقل ‏delay‏ قابل پیکربندی برای هر اینترفیس با هر ‏bandwidth‏ ای هم 10 میکروثانیه است (یعنی لینک های ‏سریعتر هم همان ‏delay‏ ای را دارند که لینک هایی با سرعت کم تر دارند) به همین دلیل تصمیم بر آن شد که فرمول محاسبه ی متریک عوض شود. به این ترتیب به فرمولی که در بالا ذکر گردید متریک کلاسیک و به رابطه ی جدیدی که برای محاسبه ی متریک در ‏EIGRP‏ تعریف شده، ‏Wide ‎Metric‏ گویندبا این تغییر این امکان برای ‏EIGRP‏ فراهم شد تا هم جوابگوی لینک هایی با ‏Bandwidth‏ بالا باشد و هم ‏با محاسبه ی ‏delay‏ بر حسب ‏picosecond‏ مشکل حداقل ‏delay‏ برطرف شود.

EIGRP Wide Metric
EIGRP Wide Metric


پارامترهای اصلی شرکت کننده در فرمول Wide Metric عبارتند از:  minimum Throughput, latency, load, Reliability و Extended Attribute‏ ها. ‏علاوه بر این پارامترها مواردی مثل MTU و Hop-Count  نیز به همراه پارامترهای متریک به همسایه ها گزارش داده می شوند. منظور از Extended Attribute ها Jitter و Energy هستند که این پارامترها و نحوه ی محاسبه ی آنها از یک مبدا تا یک مقصد، فعلا در حال توسعه و بررسی می باشد و تنها ‏در صورتی در فرمول محاسبه ی متریک شرکت داده می شوند که روتر از این پارامترها پشتیبانی نماید.
تغییر دیگری که در فرمول ‏Wide Metric‏ ایجاد شد معرفی ضریب جدیدی به نام ‏K6‎‏ بود که در صورت پشتیبانی روتر از ‏Extended Attribute‏ ها از این ضریب برای شرکت این پارامترها در محاسبه ی متریک استفاده می شود.‏

به صورت پیش فرض ‏Wide metric‏ بر اساس حداقل ‏Throughputو مجموع ‏Latency‏ ها محاسبه می گردد. به عبارتی در ‏این فرمول جدید، ‏Bandwidth‏ به‏Throughput و ‏Delay‏ به ‏Latency‏ تبدیل شده است. برای محاسبه ی ‏Throughput‏ از ‏رابطه ی زیر استفاده می شود:‏

Throughput = K1 * (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE) / Interface Bandwidth (kbps)

که در این رابطه:

EIGRP_BANDWIDTH= 107
EIGRP_WIDE_SCALE= 65536‎

و برای محاسبه ی ‏Latency‏ نیز از رابطه ی زیر استفاده می شود:‏

Latency = K3 * (Delay * EIGRP_WIDE_SCAL)/(EIGRP_DELAY_PICO)

که در این رابطه:

EIGRP_WIDE_SCAL= 65536‎
EIGRP_DELAY_PICO= 106

به این ترتیب با فرض این که ضرایب ‏K1‎‏ تا ‏K6‎‏ مقادیر پیش فرض را داشته باشند و فقط ضرایب ‏K1‎‏ و ‏K3‎‏ در فرمول محاسبه متریک اثرگذار باشند، فرمول محاسبه ی ‏Wide Metric‏ به صورت زیر در خواهد آمد:‏

Metric = (K1 * min(Throughput)) + (K3 * sum(Latency))

این تغییرات در متریک سبب به وجود آمدن تغییراتی در قالب پکت های EIGRP شد که در قسمت های بعد به سراغ این تغییرات نیز خواهیم رفت. تا به اینجا با EIGRP و این که چه تغییراتی برای بهینه تر شدن آن نسبت به سایر Distance Vector ها انجام شده، کمی با هم آشنا شدیم. عملکرد EIGRP کلا در چهار مولفه ی اصلی خلاصه می شود:

Reliable Transport Protocol
Neighbor Discovery/Recovery
Finite State Machine
Route Management

Reliable Transport Protocol – RTP

 مدیریت تحویل و دریافت پیام های EIGRP و هم چنین رعایت ترتیب در تحویل پکت ها، برعهده ی RTP است. برای تضمین این تحویل، RTP از الگوریتم اختصاصی سیسکو با نام Reliable Multicast بهره می گیرد.

تصدیق تحویل پکت ها و تضمین حفظ ترتیب آن ها در هنگام دریافت، از طریق دو Sequence Number در هدر EIGRP صورت می گیرد. یکی از این Sequence Number ها توسط روتر دریافت کننده ی پکت مقداردهی می شود و می تواند هر مقداری داشته باشد و هر زمان که روتر پکت جدیدی تولید کند، مقدار این Sequence Number یک واحد افزایش می یابد.

Sequence Number دوم در واقع Sequence Number آخرین پکتی خواهد بود که روتر دریافت کرده و باید تصدیق دریافت آن ارسال شود. این Sequence Number دوم در فیلد Acknowledgment Number در هدر EIGRP قرار می گیرد. قالب هدر EIGRP به صورت زیر می باشد:

هدر پکت EIGRP
هدر پکت EIGRP

در EIGRP چندین پکت مختلف وجود دارد که بسته به نوع پکت، RTP از یکی از روش های Reliable Delivery یا Unreliable Delivery برای تحویل پکت ها استفاده می کند.

روش Reliable Delivery به این صورت است که پکتی که از این روش برای آن استفاده شده باشد حتما باید  Ack مربوط به دریافت شدن آن از طرف مقابل، دریافت گردد. در روش Unreliable Delivery نیازی به تصدیق دریافت پکت نیست.

اگر پکتی قرار نباشد به روش Reliable Delivery ارسال شود در فیلد Sequence Number آن مقدار صفر قرار می گیرد. اما EIGRP از چه پکت هایی استفاده می کند و برای هر کدام از این پکت ها از چه روشی استفاده می شود؟

به طور کلی EIGRP از پنج پکت زیر استفاده می کند که نوع پکت متناسب با مقداری که در فیلد Opcode قرار می گیرد مشخص خواهد شد:

  • Hello: به منظور تشخیص همسایه ها، حفظ ارتباطات همسایگی و تشخیص از دست رفتن یک همسایه (فرآیند Neighbor Discovery/Recovery) از این پکت ها استفاده می شود. این پکت ها به صورت Multicast ارسال می شوند و از روشUnreliable Delivery برای آن ها بهره گرفته می شود. هنگامی که در فیلد Opcode مقدار قرار داشته باشد، به این معناست که پکت از نوع Hello است.
  • Acknowledgment – Ack: این پکت ها در واقع همان پکت های Hello هستند تنها با این تفاوت که در آن ها هیچ داده ای وجود ندارد و همیشه به صورت Unicast ارسال شده و از روش Unreliable Delivery برای آن ها استفاده می شود.
  • Update: اطلاعات مسیرها از طریق این پیام منتقل می شوند. برخلاف پیام های Update در دیگر Distance Vector ها، این پکت ها فقط در صورت لزوم ارسال شده و تنها شامل اطلاعات ضروری می باشند هم چنین این پکت ها تنها برای روتری که این اطلاعات را درخواست کرده باشد، ارسال می شوند. زمانی که آپدیت ها تنها توسط یک روتر خاص تقاضا شده باشند، پیام آپدیت به صورت Unicast و فقط برای همان روتر ارسال می شود و زمانی که آپدیت ها توسط چندین روتر درخواست شده باشند، مثلا به محض تغییر متریک و یا رخ دادن تغییری در توپولوژی ، پیام های آپدیت به صورت Multicast ارسال می شوند. پیام های آپدیت همیشه از روش Reliable Delivery استفاده می کنند. اگر در فیلد Opcode مقدار قرار گرفته باشد، به این معنی است که پکت از نوع Update می باشد.
  • Query و Reply: این پیام ها توسط DUAL finite state machine (که در قسمت بعد به سراغ این موضوع خواهیم رفت) برای مدیریت diffusing computation مورد استفاده قرار می گیرند. Query ها می توانند به صورت Unicast یا Multicast ارسال شوند اما Reply ها همیشه به صورت Unicast ارسال می شوند. هر دو پیام Query و Reply از حالت Reliable delivery استفاده می کنند. اگر در فیلد Opcode مقدار 3 قرار داشته باشد، پکت از نوع Query و اگر مقدار 4 قرار داشته باشد، پکت Reply می باشد.

(در RFC 7868 گروه دیگری از پکت ها با نام پکت های Request نیز معرفی شده اند که البته این پکت ها هرگز به مرحله ی پیاده سازی نرسیدند).

EIGRP Packets - REQUEST Packets
EIGRP Packets – REQUEST Packets

EIGRP برای ارسال پکت های Multicast خود از آدرس رزرو شده ای در کلاس D یعنی 224.0.0.10 بهره می گیرد.

با توجه به آن چه تا کنون گفته شد بیایید با مثال هایی نحوه ی ارسال پکت ها به روش Reliable Delivery را بررسی کنیم. فرض کنید در ساختاری Point-to-Point که لینک ها دارای ثبات می باشند، روتر A در گام اول یک پکت Update را برای روتر B ارسال کند (در تصاویر زیر منظور از SEQ، فیلد Sequence Number و منظور از Ack فیلد Acknowledgment Number می باشد).

ارسال پیام آپدیت بر روی لینک های Point-to-Point با ثبات
تصویر 1 : ارسال پیام آپدیت بر روی لینک های Point-to-Point با ثبات

در تصویر بالا روتر B بعد از دریافت پیام آپدیت از جانب روتر A، تصدیق این دریافت را از طریق ارسال یک پکت Ack که در واقع پیام Hello ای خالی از داده و با Sequence Number ای با مقدار صفر و Acknowledgment Number ای برابر با مقدار فیلد SEQ پیام Update دریافت شده می باشد، انجام می دهد.

در گام بعد روتر A برای روتر B پکت Query ارسال می کند. این فرآیند در تصویر زیر مشخص گردیده است.

تصویر 2 :ارسال پیام Query بر روی لینک های Point-to-Point با ثبات
تصویر 2 : ارسال پیام Query بر روی لینک های Point-to-Point با ثبات

روتر B بعد از دریافت پیام Query از جانب A، پیام Reply که در فیلد Ack آن مقدار فیلد SEQ پکت Query دریافت شده از جانب A قرار گرفته، برای A ارسال می کند. A نیز بعد از دریافت این reply، پکت Ack ای را با SEQ، صفر و Ack برابر با مقدار فیلد SEQ پکت Reply برای B ارسال کرده و پکت Query را از لیست پکت های در انتظار ارسال مجدد، پاک می کند.

هر دو تصویر بالا مستقیما از RFC استخراج شده اند. اگر فرآیند ارسال Query و آپدیت  را بر روترهای سیسکو مورد بررسی قرار دهید، با کپچر پکت های ارسالی با دو تفاوت نسبت به آن چه در این مثال ها نشان داده شد رو به رو خواهید شد: اول آن که پیام های آپدیت و کوئری بر روی لینک های سریال همیشه به صورت Unicast و نه Multicast ارسال می شوند (کاملا برخلاف تصاویر نشان داده شده در بالا) و دوم آن که روتر دریافت کننده ی پکت Query ابتدا یک پیام Ack و سپس پیام Reply برای ارسال کننده ی پیام Query ارسال خواهد کرد. دلیل ذکر این موضوعات به این جهت می باشد که پیاده سازی یک پروتکل بر روی دستگاه های وندورها شاید کمی متفاوت تر از آن چه در RFC بیان شده، باشد.

ارسال پیام های آپدیت و Query در محیط Multi-access ای چون یک ساختار اترنت و در حالت ثبات به شکل تصاویر زیر خواهد بود.

ارسال پیام Update در محیط های Multiaccess
تصویر 3 : ارسال پیام Update در محیط های Multiaccess
ارسال پیام Query در محیط های Multiaccess
تصویر 4 : ارسال پیام Query در محیط های Multiaccess

تمام موارد ذکر شده در بالا برای حالت هایی است که لینک ها با ثبات و پایدار باشند. اما تصور کنید که لینک Point-to-Point ای بی ثبات باشد و پیام آپدیتی که به صورت مالتی کست ارسال شده، بنا به هر دلیلی به مقصد نرسیده و Ack آن دریافت نشود. در این صورت روتر به اندازه ی مدت زمانی که از آن با نام Retransmit Timer یاد می شود صبر کرده و سپس پکت را مجددا ارسال می کند. اما تفاوت در اینجاست که در هنگام این ارسال مجدد، پکت به جای ارسال مالتی کست، به صورت Unicast ارسال خواهد شد.

در محیط های Multi-access این روند کمی تفاوت دارد. اگر روتری در یک محیط مالتی کست بنا به هر دلیلی پیام Update ای را دریافت نکند و یا نتواند Ack مربوط به آن را ارسال کند و اگر روتر ارسال کننده ی پیام آپدیت قبل از ارسال این پیام به صورت Unicast، نیاز باشد تا پیام آپدیت جدیدی را به صورت مالتی کست ارسال کند، روتر دچار تاخیر، در حالی که  هنوز پیام یونیکست مربوط به آپدیت اول را دریافت نکرده، پیام مالتی کست بعدی را دریافت می کند و این امر بدین معناست که شرط حفظ ترتیب پکت ها در هنگام تحویل، رعایت نشده است. برای حل این مشکل از حالتی با نام Conditionally Receive Mode استفاده می شود.

به عنوان مثال، در تصویر 3 تصور کنید که روتر B نتواند بنا به هر دلیلی Ack مربوط به پیام آپدیت روتر A با SEQ=100 را پاسخ دهد. در چنین شرایطی روتر A متوجه می شود که در Retransmit List روتر B، هم چنان یک پیام آپدیت وجود دارد. به همین دلیل روتر A قبل از ارسال پکت آپدیت مالتی کست بعدی با SEQ=101، ابتدایک پکت Hello که در آن از Sequence TLV استفاده شده تولید و به صورت مالتی کست ارسال میکند. در واقع روتر A در این TLV آدرس IP تمام روترهایی که در Retransmit  List آن ها پکتی وجود داشته باشد، ذکر میکند.

روترهای C و D با دریافت این پیام Hello و پردازش Sequence TLV و عدم مشاهده ی آدرس IP خود در این TLV به حالت CR-Mode یا Conditionally Receive Mode می روند. به این معنی که اگر پیامی دریافت کنند که در آن از CR-Flag استفاده شده باشد باید آن پیام را دریافت و پردازش کنند. اما روتر B از آن جایی کهآدرس IP خود را در Sequence TLV پکت Hello دریافتی از جانب A مشاهده می کند، به حالت CR-Mode نرفته و در نتیجه اگر پکت آپدیت مالتی کستی از جانب A دریافت کند باید آن را discard نماید.

حال روتر A پکت آپدیتی که قرار بر ارسال آن بود، به صورت مالتی کست ارسال میکند فقط با این تفاوت که در این پیام آپدیت فیلد Flags مقدار 0x02 دارد به عبارتی اگر مقدار این فیلد 0x02 باشد یعنی از CR-Flag در این پیام استفاده شده است. روترهای C و D با مشاهده ی پکتی که در آن از CR-Flag استفاده شده، این پکت را پذیرفته و پردازش می کنند و Ack مربوط به آن را برای A ارسال می کنند. اما روتر B که به حالت Conditionally Receive نرفته و حق پردازش پکت هایی که در آن ها از CR-Flag استفاده شده باشد، ندارد، این پکت را discard کرده و هیچ Ack ای در قبال آن برای روتر A ارسال نمی کند.

به این ترتیب روتر A پیام آپدیت با SEQ=100 را مجددا به صورت Unicast برای روتر B ارسال می کند. از آن جایی که روتر B قبلا پکت آپدیت با SEQ=100 را دریافت کرده، پکت آپدیت یونیکست با SEQ=100 را discard کرده و فقط Ack آن را برای A ارسال می کند. A این پکت را از Retransmit List روتر B حذف می کند. سپس پکت آپدیت با SEQ=101 را برای روتر B به صورت یونیکست ارسال می کند. روتر B این آپدیت جدید را پذیرفته و Ack مربوط به آن را برای A ارسال می کند و به این ترتیب Retransmit List روتر B خالی می شود.

در نتیجه RTP با انجام این اعمال، تحویل پکت ها با ترتیب درست را تضمین می کند

Neighbor Discovery/Recovery

EIGRP باید قادر باشد تا از طریق روشی همسایه های خود را کشف کرده و از سوی دیگر از دست رفتن یک همسایه را تشخیص دهد. برای انجام این اعمال EIGRP از پکت های Hello استفاده می کند. به این صورت که به محض فعال شدن EIGRP بر روی یک لینک، پکت های Hello بر روی آن اینترفیس ارسال می شوند. در اکثر ساختارهای شبکه، پیام های Hello هر 5 ثانیه یکبار (منهای یک مقدار تصادفی برای جلوگیری از همزمانی) به صورت multicast ارسال می شوند.

پیام Hello ای که از جانب همسایه ای دریافت می شود شامل یک hold time است که این hold time در واقع برای روتر دریافت کننده ی پیام Hello، حداکثر تایم انتظار برای دریافت پکت Hello بعدی را مشخص می کند. اگر قبل از دریافت پکت Hello، تایمر hold time منقضی شود، همسایه Unreachable در نظر گرفته شده و DUAL این همسایگی را از دست رفته اعلام می کند. به صورت پیش فرض مقدار hold time، سه برابر hello-interval می باشد.

در پکت Hello مقدار Sequence Number همیشه صفر بوده و علاوه بر hold-time، شامل ضرایب شرکت کننده در معادله ی محاسبه ی متریک یعنی K-Value ها نیز می باشد.

هنگامی که قرار است برای اولین بار بین دو روتر ارتباط همسایگی برقرار شود، بعد از دریافت پکت Hello از جانب همسایه و چک یکسان بودن پارامترهای همسایگی، به منظور اطمینان از تحویل پکت های Unicast و Multicast، روتر یکپیام آپدیت خالی (بدون هیچ اطلاعات مسیری) برای همسایه ی تازه کشف شده ی خود ارسال می کند. به این پکت آپدیت اولیه اصطلاحا Null Update گویند که در آن فیلد Flags مقدار 0x01 داشته و این مقدار به معنی استفاده از INIT-Flag – Initial-Flag می باشد. INIT-Flag به این معنی است که روتر دریافت کننده ی چنین پکتی باید تمام مسیرهای خود را تبلیغ کند. 

یک کاربرد دیگر برای INIT-Flag غیر از تشکیل ارتباط اولیه بین دو همسایه، برای زمانی است که روتری در حین کار ریستارت شود ولی قبل از آن که همسایه اش از این down شدن چند لحظه ای آن باخبر شود، مجددا up گردد. در چنین شرایطی اگر تغییری رخ داده باشد باید روتر ریستارت شده نیز از این تغییرات آگاه شود. در نتیجه با ارسال یک پیام آپدیت که در آن از INIT-Flagاستفاده شده، از همسایه ی خود تقاضا میکند که آپدیتی شامل تمام مسیرهایی که شناسایی نموده، برایش ارسال کند.

فرض کنید بین روترهای A و B قرار است برای نخستین بار ارتباط همسایگی تشکیل شود. روتر A بعد از دریافت پکت Hello از جانب روتر B، یک پکت Null Update به صورت Unicast برای B ارسال کرده و وضعیت همسایگی روتر B را حالت pending (یا انتظار) تعیین میکند. روتر B با دریافت این Null Update بلافاصله یک پکت Null Update به صورت Unicast برای A ارسال می کند. روتر A با دریافت پکت Null Update از جانب روتر B، وضعیت آن را از pending به up تغییر داده و پیام آپدیتی حاوی کل اطلاعات توپولوژی که تاکنون شناسایی کرده، برای روتر B به صورت Unicast ارسال می کند. روتر B با دریافت این پیام آپدیت، ابتدا Ack آن را برای A ارسال کرده و سپس پیام آپدیتی حاوی کل اطلاعات موجود در Route Table خود به صورت Unicast برای روتر A ارسال می کند.

نکته ی حائز اهمیت در اینجا آن است که تا زمانی که پکت های Null Update از جانب هر دو همسایه ارسال و دریافت نگردند (یعنی همسایه در وضعیت pending باشد) هیچ پکت آپدیت (حاوی اطلاعات توپولوژی) یا Query اجازه ی ارسال نخواهند داشت.

Diffusing Update Algorithm – DUAL

 DUAL تضمین می کند که شبکه در هر لحظه حتی در هنگام رخ دادن تغییرات در توپولوژی و همگرایی مجدد ساختار، loop free باقی بماند. بر خلاف سایر پروتکل های Distance Vector که بر اساس الگوریتم Bellman-Ford فعالیت می کنند و در صورت بروز تغییری در توپولوژی، آپدیت ها به صورت ناهماهنگ توسط نودها در ساختار ارسال می شوند، DUAL برای آن که بتواند تنها در بخش هایی که تحت تاثیر تغییر واقع شده اند محاسبات یافتن بهترین مسیر جایگزین بعدی را انجام دهد، نیازمند آن است که از یک روش هماهنگ برای انتشار اطلاعات بین تمام نودها در ساختار استفاده کند که این روش diffusing computation نام دارد. بر اساس diffusing computation تنها روترهایی که تحت تاثیر تغییر باشند محاسبات مربوط به یافتن بهترین مسیر جدید بعدی که loop free باشد را انجام می دهند.

به بیان دیگر diffusing computation روند ارسال Query برای یافتن مسیری به مقصدی است که fail شده است. روترهایی که از مقصد مورد نظر اطلاعی نداشته باشند بلافاصله به Query دریافت کرده پاسخ می دهند و وارد جریان محاسبات diffusing computation نمی شوند. به این ترتیب روند انجام diffusing computation تنها در یک بخش خلاصه شده و در کوتاهترین زمان ممکن این روند خاتمه می یابد.

یکی از ویژگی های DUAL آن است که می توان با پنهان کردن اطلاعات reachability، دامنه ی نقاطی که diffusing computation باید در آن ها صورت گیرد، کاهش داد و به بیان بهتر مدیر شبکه این امکان را داشته باشد که با انجام اعمالی چون Summerization یا فیلترینگ داخل یک AS بتواند، failure domain های کوچکتری ایجاد کرده و از این طریق زمان همگرایی را مدیریت کند.

اما قبل از بررسی دقیق تر قوانین diffusing computation، ابتدا باید برخی مفاهیم و اصطلاحات توضیح داده شوند.

زمانی که روتری برای نخستین بار همسایه ی EIGRP جدیدی پیدا می کند، بعد از طی روند شکل گیری همسایگی (که در بالاتر بیان گردید) اطلاعات مربوط به تمام مسیرهایی که تاکنون فراگرفته را در قالب پیام آپدیتی برای همسایه ی خود ارسال می کند. این اطلاعات شامل متریکی که آن روتر تا هر مقصد محاسبه کرده نیز می شود. روتر دریافت کننده ی این پیام آپدیت، بر اساس متریکی که همسایه تا یک مقصد خاص تبلیغ کرده که اصطلاحا به آن Reported Distance – RD  گفته می شود به علاوه ی Cost لینک تا آن همسایه، شروع به محاسبه ی متریک تا آن مقصد می کند.

اگر تا یک مقصد چندین مسیر تبلیغ شده باشد، به ازای هر مسیر متریک جداگانه ای محاسبه شده و کم ترین متریک محاسبه شده تا آن مقصد به عنوان Feasible Distance – FD برای آن مقصد در نظر گرفته می شود.

EIGRP برای یافتن بهترین مسیر بدون لوپ تا مقصد از شرطی استفاده میکند که اصطلاحا Feasibility Condition – FC نامیده می شود و در واقع بررسی کننده ی آن است که متریک تبلیغ شده از جانب یک همسایه از مقدار FD محاسبه شده کم تر است یا نه.

اگر همسایه ای مسیری را برای رسیدن به یک مقصد تبلیغ کند که مقدار متریک محاسبه شده توسط آن تا آن مقصد(RD) از مقدار FD محاسبه شده توسط روتر برای آن مقصد کم تر باشد، آن همسایه به عنوان Feasible Successor – FS در نظر گرفته می شود. اگر مقدار RD تبلیغی از جانب همسایه بیشتر یا حتی مساوی مقدار FD باشد، آن همسایه به عنوان Feasible Successor انتخاب نخواهد شد.

ممکن است چند همسایه به عنوان Feasible Successor انتخاب شوند. از بین همسایه هایی که به عنوان FS انتخاب شده اند، همسایه ای که برای رسیدن به مقصد، کم ترین متریک برای آن محاسبه شده باشد به عنوان Successor انتخاب می شود. Successor درواقع همان روتر next-hop برای ارسال پکت ها به مقصد می باشد. سایر FS ها در جدولی با نام Topology Table نگهداری می شوند و در حالت عادی تنها زمانی استفاده می شوند که Successor بنا به هر دلیلی fail شود.

دقت داشته باشید که متریک مسیر از سمت Successor می تواند برابر و یا کم تر از مقدار FD باشد. FD الزاما متریک محاسبه شده برای Successor نیست بلکه مقدار متریکی است که در لحظه ی گذار از وضعیت Active به Passive محاسبه شده است (در ادامه این دو وضعیت شرح داده شده اند).

مفاهیم Feasible Successor و Feasibility Condition در واقع عوامل اصلی جلوگیری از لوپ در EIGRP می باشند:

  • از آن جایی که مقدار متریک تبلیغی از جانب همسایه هایی که به عنوان FS انتخاب می شوند همواره باید کم تر از FD باشد، روتر هرگز مسیری را که نهایتا به خودش منتهی شود به عنوان FS انتخاب نخواهد کرد چرا که چنین مسیری قطعا متریکی بزرگتر از FD خواهد داشت.
  • از سوی دیگر وجود FS ها و ذخیره ی آن ها علاوه بر Successor این امکان را برای EIGRP فراهم می آورد که در صورت از دسترس خارج شدن Successor، در کوتاهترین زمان ممکن بهترین مسیر بعدی را جایگزین کرده و به همگرایی مجدد برسد.

EIGRP برای هر مسیری که برای رسیدن به هر مقصد محاسبه کرده دو وضعیت در نظر میگیرد: Passive و Active.

  • Passive: اگر به ازای مقصدی حداقل یک همسایه وجود داشته باشد که کوتاهترین مسیر ممکن loop free که شرط FC برای آن صدق کند، تبلیغ نماید آن مسیر در وضعیت Passive قرار خواهد گرفت. به بیان بهتر اگر برای رسیدن به یک مقصد حداقل یک FS وجود داشته باشد که کوتاهترین مسیر ممکن تا آن مقصد را تبلیغ نماید، آن مسیر به وضعیت Passive می رود. همانطور که در بالا نیز ذکر گردید FS ای که کوتاهترین مسیر loop free تا یک مقصد را تبلیغ نماید، Successor خطاب می شود. پس مسیر Passive مسیری با حداقل یک Successor می باشد. چنین مسیری قابل استفاده بوده و در جریان مسیریابی از آن استفاده می شود.
  • Active: برخلاف وضعیت Passive، مسیری در وضعیت Active قرار خواهد گرفت که هیچ FS ای (و متعاقبا هیچ Successor ای) برای آن وجود نداشته باشد. چنین مسیری نمی تواند در جریان مسیریابی شرکت کند و قابل استفاده نیست. روتر برای مسیری که در وضعیت Active قرار داشته باشد باید طی فرآیندی هماهنگ از همسایه های خود پرس و جو کرده تا بتواند کوتاهترین مسیر loop free برای آن مقصد را پیدا نماید.

مجموعه ای از قوانین که مشخص کننده ی آن هستند که چه زمان و چگونه مسیری از وضعیت Passive به Active منتقل می شود و بالعکس،DUAL Finite State Machine – DUAL FSM خطاب می شوند.

DUAL Finite State Machine

برای بررسی DUAL FSM ابتدا باید با این موضوع آشنا باشید که چه زمان Diffusing Computation انجام می شود.

زمانی که مسیرهای فرا گرفته شده از طریق EIGRP در وضعیت Passive باشند، محاسبات Diffusing Computation نیز صورت نمی گیرد. اما اگر برای مسیری تغییری حاصل شود که اصطلاحا به این تغییرات input event گفته می شود، روتر لیست FS های مسیری که برای آن input event رخ داده بررسی می کند. input event ها می توانند یکی از موارد زیر باشند:

  • تغییر در cost یک لینک directly connected
  • تغییر در وضعیت یک لینک directly connected – UP/Down شدن لینک
  • دریافت یک پکت Update/Query/Reply

اولین گام در ارزیابی مجدد FS ها انجام local computation می باشد. در واقع local computation محاسبه ی مجدد متریک تمام FS های موجود برای مسیری است که input event برای آن رخ داده باشد. بر اثر انجام local computation ممکن است یکی از موارد ذیل رخ دهد:

  • اگر distance (متریک) یک FS کم تر از distance محاسبه شده برای Successor فعلی گردد، FS جایگزین Successor فعلی می شود.
  • اگر distance محاسبه شده ی جدید کم تر از FD باشد، FD با این مقدار جدید به روزرسانی می شود.
  • اگر distance محاسبه شده ی جدید با distance موجود تفاوت داشته باشد، یک پیام آپدیت به تمام همسایه ها ارسال می شود.

تا زمانی که روتر در حال انجام local computation می باشد، مسیرها در وضعیتPassive باقی خواهند ماند. اگر FS  ای برای مسیر یافت شود، یک پیام آپدیت به همسایه ها ارسال شده و تغییری در وضعیت مسیرها حاصل نخواهد شد. اما اگر FS ای یافت نشود روتر اقدام به اجرای diffusing computation کرده و مسیری که برای آن diffusing computation اجرا شده به وضعیت Active می رود. تا زمانی که diffusing computation کامل نشود و مسیر به وضعیت Passive باز نگردد، روتر نمی تواند این اعمال را در قبال مسیر در وضعیت Active انجام دهد:

  • تغییر Successor
  • تغییر distance ای که برای آن مسیر تبلیغ کرده
  • تغییر FD آن مسیر
  • آغاز یک diffusing computation جدید برای آن مسیر

diffusing computation با ارسال Query آغاز می شود، به این صورت که روتر بر روی تمام لینک های خود به تمام همسایگان EIGRP خود Query ارسال خواهد کرد و تا زمانی که از تمام همسایه هایی که برای آن ها Query ارسال شده Reply ای دریافت نگردد، diffusing computation خاتمه نخواهد یافت، روتر برای آن که تشخیص دهد کدام یک از همسایگان، Reply مربوط به Query ارسال شده را برای آن ارسال کرده اند از پرچمی با نام reply status flag بهره می گیرد و به ازای هر همسایه که برای آن Query ارسال کرده مقدار این پرچم را یک می نماید. به محض دریافت Reply از جانب همسایه، مقدار این پرچم برای آن همسایه صفر می گردد.

از سوی دیگر ممکن است در حالی که مسیر به یک مقصد هم چنان در وضعیت Active قرار دارد، input event دیگری رخ دهد. به همین دلیل DUAL چندین حالت Active در نظر میگیرد و برای تشخیص آن که مقصد مورد نظر اکنون در کدام یک از این حالت های Active قرار دارد از پرچمی با نام query origin flag استفاده می کند.

در تصویر زیر وضعیت های DUAL FSM نمایش داده شده که شماره های بر روی فلش ها در واقع input event هایی هستند که سبب تغییر وضعیت یک مسیر می شوند.

DUAL FSM

توصیف input event هایی که سبب تغییر از یک وضعیت به وضعیت دیگر می شوند به شرح ذیل می باشد:

  1. اگر برای یک مقصد Query ای از جانب همسایه ای دریافت شود که آن همسایه Successor برای رسیدن به آن مقصد نباشد و هم چنین برای آن مقصد یک FS نیز وجود داشته باشد، در چنین صورتی مسیر به آن مقصد هم چنان در وضعیتPassive باقی خواهند ماند. از آن جایی که روتر برای آن مقصد حداقل یک FS دارد باید به Query دریافت شده پاسخ دهد. هر متریکی که از طریق این Query تبلیغ شده باشد باید در جدول توپولوژی ثبت شده و برای بررسی عدم تاثیر آن بر Successor فعلی، شرط FC برای آن بررسی شود.
  2. اگر وضعیت یک لینک directly connected تغییر کند (up/down یا تغییر cost) ویا Update یا Query ای دریافت شود که برای یک مقصد تغییری در متریک را تبلیغ کنند و در تمام این موارد، این تغییرات هیچ تاثیری بر Successor آن مقصد نداشته باشد و یا حتی در صورت اثر، برای آن مقصد یک FS وجود داشته باشد،مسیر به آن مقصد هم چنان در وضعیت Passive باقی خواهند ماند. در تمام این حالات باید با ارسال Update ای، متریک جدید به همسایه ها اطلاع داده شود.
  3. اگر برای یک مقصد از جانب Successor آن، Query دریافت شود و برای آن مقصد به غیر از Successor هیچ FS دیگری وجود نداشته باشد، مسیر به آن مقصد به وضعیت Active رفته و روتر به تمام همسایگان خود با رعایت قانون Split Horizon این Query را ارسال می کند. در چنین حالتی برای مسیر به آن مقصد query origin flag با مقدار 3 تنظیم شده و reply status flag مقدار 1 می گیرد.
  4. اگر لینک directly connected ای down شود و یا cost آن افزایش یابد و یاUpdate ای برای آن مقصد دریافت شود که در آن متریک به مقصد مورد نظر افزایش یافته باشد، اگر برای آن مقصد هیچ FS ای وجود نداشته باشد، مسیر به آن مقصد به وضعیت Active رفته و به تمام همسایگان Query ارسال می شود. در چنین حالتی query origin flag برای مسیر به آن مقصد مقدار 1 گرفته و reply status flag مقدار 1 می گیرد.
  5. اگر مسیر به مقصدی در وضعیت Active قرار داشته باشد و از Successor آن مسیر Query ای دریافت شود، مسیر هم چنان در وضعیت Active باقی خواهند ماند ولی origin flag برای آن مقدار 2 خواهد گرفت. reply status flag نیز هم چنان دارای مقدار یک خواهد بود. در چنین شرایطی متریک FS جدید با متریکی که سبب وضعیت Active برای مسیر شده، مقایسه می گردد.
  6. اگر مسیر به مقصدی در وضعیت Active باشد و از جانب همسایه ای که Successor برای آن مقصد نبوده، Query ای دریافت شود، مسیر هم چنان در وضعیت Active باقی می ماند و باید با ارسال یک Reply به Query دریافت شده پاسخ داده شود. هم چنین متریکی که از طریق Query جدید دریافت شده نیز باید ثبت شود.
  7. اگر مسیر به مقصدی در وضعیت Active باشد و cost لینک تغییر کند و یا Update ای با یک متریک تغییریافته ی جدید از همسایه ای که برای آن مقصد Successor نیست، دریافت شود، مسیر به آن مقصد هم چنان در وضعیتActive باقی می ماند. اطلاعات متریک موجود در این پیام آپدیت، ثبت می شوند.زمانی که مسیری در وضعیت Active باشد، هیچ آپدیت یا Query ای در رابطه با آن مسیر ارسال نخواهد شد.
  8. اگر مسیر به مقصدی در وضعیت Active باشد و Reply ای دریافت شود که از جانب همسایه یا روتری باشد که ارتباط با آن fail شده بوده، روتر دریافت Reply ای که به سبب آن Query ارسال شده ثبت می کند و reply status flag برای همسایه ای که Reply ارسال کرده صفر می گردد. اگر هنوز از تمام همسایه ها Reply دریافت نشده باشد، مسیر به مقصد مورد نظر هم چنان در وضعیت Activeباقی خواهند ماند.
  9. اگر زمانی که مسیر به مقصدی در وضعیت Active باشد، لینک بین روتر و Successor آن مقصد fail شود و یا cost آن افزایش یابد، روتر با این مورد همانند دریافت Reply از جانب Successor عمل می کند. اگر این اتفاق بعد از ارسال Query توسط روتر برای آن مقصد رخ داده باشد، روتر query origin flag را برای مسیر به آن مقصد صفر مقدار دهی می کند تا نشان دهنده ی آن باشد که تغییر دیگری در توپولوژی رخ داده و این مسیر هنوز در وضعیت Active قرار دارد.
  10. اگر زمانی که مسیر به مقصدی در وضعیت Active باشد، لینک بین روتر و Successor آن مقصد fail شود و یا cost آن افزایش یابد، روتر با این مورد همانند دریافت Reply از جانب Successor عمل می کند. اگر این اتفاق بعد از ارسال Query توسط Successor برای آن مقصد رخ داده باشد، روتر query origin flag را برای مسیر به آن مقصد 2 مقدار دهی می کند تا نشان دهنده ی آن باشد که تغییر دیگری در توپولوژی رخ داده و این مسیر هنوز در وضعیت Active قرار دارد.
  11. اگر مسیر به مقصدی در وضعیت Active باشد و cost لینک تا Successor افزایش یابد و این امر در شرایطی اتفاق بیافتد که Reply از تمام همسایه ها دریافت شده و هنوز FS ای وجود نداشته باشد، روتر باید هم چنان در وضعیتActive باقی بماند و باید مجددا به تمام همسایه ها Query ارسال شود و query origin flag نیز برای مسیر به آن مقصد 1 در نظر گرفته می شود.
  12. اگر مسیر به مقصدی به دلیل دریافت Query از Successor آن مقصد در وضعیت Active قرار گرفته باشد و آخرین Reply مورد انتظار نیز در قبال این Query دریافت شده باشد ولی باز هم هیچ FS ای یافت نشده باشد، مسیر به آن مقصد باید در وضعیت Active باقی بماند. در چنین شرایطی query origin flag برای مسیر به آن مقصد 3 در نظر گرفته می شود.
  13. اگر query origin flag برای مسیر به مقصدی مقدار 3 داشته باشد که نشان دهنده ی آن است که مسیر به آن مقصد به علت دریافت Query از جانب Successor آن به وضعیت Active رفته است، با دریافت تمام Reply ها از جانب تمام همسایه ها، مسیر دوباره به وضعیت Passive برگشته و به Successor آن Reply ای ارسال می گردد.
  14. اگر مقدار query origin flag برای مسیر به مقصدی 0 باشد که نشان دهنده ی آن است که مسیر به آن مقصد بر اثر تغییری در توپولوژی تا Successor در وضعیت Active قرار گرفته، نیازی به ارسال Reply به Successor قبلی نیست. اگر شرط FC رعایت شده باشد، مسیر دوباره به وضعیت Passive باز گردانده می شود.
  15. اگر مقدار query origin flag برای مسیر به مقصدی 1 باشد که نشان دهنده ی آن است که روتر یا خود تولید کننده ی Query بوده و یا با وجود دریافت Reply های مورد انتظار از تمام همسایه ها، شرط FC رعایت نشده بوده که مسیر به مقصد مورد نظر در وضعیت Active قرار گرفته است، مقدار FD بی نهایت در نظر گرفته شده و از بین متریک های دریافت شده توسط Reply ها، کم ترین مقدار متریک به عنوان FD جدید انتخاب می شود و مسیر به مقصد مورد نظر به وضعیت Passiveبازگردانده می شود و به Successor قبلی در صورتی که Query از آن دریافت شده باشد، Reply ای ارسال می گردد.
  16. اگر مقدار query origin flag، برای مسیر به مقصدی 2 باشد که نشان دهنده ی آن است که Query از جانب Successor آن مقصد دریافت شده و یا در حالی که مسیر در وضعیت Active بوده، متریک تا آن مقصد افزایش یافته است و سبب شده که مسیر به آن مقصد در وضعیت Active باشد، اگر تمام Reply های مورد انتظار از تمام همسایه ها دریافت شده باشد و برای آن مقصد FS ای نیز یافت شده باشد، مسیر به وضعیت Passive بازگشته و در پاسخ به Query ارسال شده از جانب Successor نیز Reply ای ارسال می گردد.

میدونم که این قسمت شاید کمی سخت و پیچیده و البته طولانی بود اما درک این که EIGRP چطور عمل میکنه مهم ترین بخش در شناخت این پروتکل محسوب میشه. اگر علاقه پیدا کردید که اولین بار این الگوریتم چه شکلی و توسط چه کسی مطرح شد، می تونید از طریق این لینک به الگوریتم اولیه ی DUAL دسترسی پیدا کنید.

Autonomous System و Autonomous System Number یا AS Number در سیسکو به چه معناست ؟

A complete table of 16-bits and 32-bits ASN available
A complete table of 16-bits and 32-bits ASN available

Autonomous System یا AS به مجموعه ای از شبکه ها گفته می شود که در یک حوزه مدیریتی واحد قرار دارند ، این مجموعه می تواند شبکه های موجود در یک سرویس دهنده اینترنتی یا ISP باشد یا یک شبکه WAN بزرگ سازمانی ، در این خصوص اصطلاحاتی است که شما حتما برای درک بهتر باید مفهوم آن را درک کنید ، اولین اصطلاح Interior Gateway Protocol یا IGP می باشد و به معنای Routing Protocol ای است که در شبکه هایی با یک Autonomous System مورد استفاده قرار می گیرد.

IGP ها شامل پروتکل هایی به نامRIP ، IGRP ، EIGRP و OSPF می شوند. Routing Protocol های دیگری نیز وجود دارند که به Exterior Gateway Protocol یا EGP معروف هستند ، با استفاده از این نوع پروتکل های EGP شما می توانید شبکه هایی با Autonomous Number های متفاوت را به هم متصل کنید.

BGP یکی از انواع پروتکل های EGP می باشد. BGP برای مسیریابی ترافیک بین شبکه های Backbone اینترنتی با Autonomous Number های متفاوت مورد استفاده قرار می گیرد.زمانیکه پروتکل BGP یا Border Gateway Protocol در حال توسعه و استاندارد سازی بود اعداد باینری 16 بیتی برای اولین بار برای استفاده در Autonomous System Number برای شناسایی شبکه های موجود در این پروتکل مورد استفاده قرار گرفتند.

به این عدد AS Number گفته می شد و به عنوان AS Number های 2 Octet ای هم مشهور بودند. با استفاده از 16 بیت باینری ما می توانستیم شبکه هایی به وسعت 2 به توان 16 یا 65536 شبکه را شماره گذاری کنیم.

منظور از Private ASN و Public ASN چیست ؟

اولین مقدار در Autonomous System Number یا ASN عدد 0 است که رزرو شده است و همچنین آخرین یا بزرگترین مقدار ASN عدد 65535 است که این مقدار نیز رزرو شده است و قابل استفاده نیست. مقادیر 1 تا 64511 برای استفاده در مسیریابی های اینترنتی استفاده می شوند و همچنین مقادیر 64512 تا 65534 نیز برای استفاده های شخصی یا سازمانی مورد استفاده قرار می گیرند. از سال 2011 ساختار ASN از 16 بیتی به 32 بیتی تغییر یافت و شما می توانید از دو به توان 32 بیت عدد برای AS های خود استفاده کنید. AS Number ها به دو دسته بندی کلی Private و Public تقسیم بندی می شوند. دقیقا مشابه آدرس های IP که Public و Private دارند شما نمی توانید از AS Number های Private در اینترنت استفاده کنید. مقادیری که در همین پاراگراف عنوان کردیم که برای استفاده شخصی و یا استفاده در مسیریابی اینترنتی استفاده می شوند دقیقا همان مفاهیم Public ASN و Private ASN را در بر دارند. شما می توانید با استفاده از Private ASN ها شبکه های بسیار بزرگ سازمانی را به AS های کوچکتر تقسیم کنید و آنها را با eBGP به هم متصل کنید. علاوه بر این اگر شما فقط یک ISP متصل شده اید شرکت ISP می تواند به شما برای استفاده از بهینه از ASN های Public یک ASN به شکل Private بدهند ، مشابه کاری که برای NAT انجام می شود. به هر حال شما اگر قرار باشد با شبکه های Internet ارتباط برقرار کنید بایستی ASN های Private خود را از شبکه های خود حذف کنید تا بتوانید به Global Mesh شبکه اینترنت بپیوندید ، توجه کنید که قرار دادن Private AS Number ها در صورتیکه شما از سرویس های چندین ISP مختلف استفاده می کنید پیشنهاد نمی شود. امیدوارم مورد توجه شما قرار گرفته باشد.

انجام یک سناریو EIGRP

خوب حالا وقت آن رسیده که یک سناریو انجام بدیم، کاری که ما میخواهیم انجام بدیم مانند شکل زیر است

سناریوی EIGRP
سناریوی EIGRP

تنظیمات اولیه روتر ها به شکل زیر می باشد:

R1(config)#interface serial 4/0
R1(config-if)#ip address 172.16.112.1 255.255.255.0
R1(config-if)#no shutdown

R1(config)#interface ethernet 0/0
R1(config-if)#ip address 172.16.12.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface serial 4/1
R1(config-if)#ip address 172.16.113.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface ethernet 0/1
R1(config-if)#ip address 172.16.13.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface serial 4/3
R1(config-if)#ip address 172.16.114.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface ethernet 0/2
R1(config-if)#ip address 172.16.14.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface serial 4/2
R1(config-if)#ip address 172.16.115.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface loopback 1
R1(config-if)#ip address 10.1.0.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface loopback 2
R1(config-if)#ip address 10.2.0.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface loopback 3
R1(config-if)#ip address 10.3.0.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface loopback 4
R1(config-if)#ip address 10.4.0.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface loopback 5
R1(config-if)#ip address 10.5.0.1 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#interface loopback 6
R1(config-if)#ip address 10.6.0.1 255.255.255.0
R1(config-if)#no shutdown

تا اینجا تمام اینترفیس های روتر اول را انجام دادیم، حال تنظیمات باقی روتر ها رو انجام می دهیم

R2(config)#interface serial 4/0
R2(config-if)#ip address 172.16.112.2 255.255.255.0
R2(config-if)#no shutdown

R2(config)#interface ethernet 0/0
R2(config-if)#ip address 172.16.12.2 255.255.255.0
R2(config-if)#no shutdown

R2(config-if)#interface ethernet 0/1
R2(config-if)#ip address 172.16.26.1 255.255.255.0
R2(config-if)#no shutdown

R2(config)#interface loopback 1
R2(config-if)#ip address 192.168.2.1 255.255.255.0
R2(config-if)#no shutdown

روتر سوم را تنظیم می کنیم:

R3(config)#interface serial 4/0
R3(config-if)#ip address 172.16.113.2 255.255.255.0
R3(config-if)#no shutdown

R3(config)#interface ethernet 0/0
R3(config-if)#ip address 172.16.13.2 255.255.255.0
R3(config-if)#no shutdown

R3(config-if)#interface ethernet 0/1
R3(config-if)#ip address 172.16.35.2 255.255.255.0
R3(config-if)#no shutdown

R3(config)#interface loopback 1
R3(config-if)#ip address 192.168.3.1 255.255.255.0
R3(config-if)#no shutdown

روتر چهارم را تنظیم می کنیم:

R4(config)#interface serial 4/0
R4(config-if)#ip address 172.16.114.2 255.255.255.0
R4(config-if)#no shutdown

R4(config)#interface ethernet 0/0
R4(config-if)#ip address 172.16.14.2 255.255.255.0
R4(config-if)#no shutdown

R4(config)#interface loopback 1
R4(config-if)#ip address 192.168.4.1 255.255.255.0
R4(config-if)#no shutdown

روتر پنجم را تنظیم می کنیم:

R5(config)#interface serial 4/0
R5(config-if)#ip address 172.16.115.2 255.255.255.0
R5(config-if)#no shutdown

R5(config)#interface ethernet 0/0
R5(config-if)#ip address 172.16.35.1 255.255.255.0
R5(config-if)#no shutdown

R5(config)#interface loopback 1
R5(config-if)#ip address 192.168.5.1 255.255.255.0
R5(config-if)#no shutdown

روتر ششم را تنظیم می کنیم:

R6(config)#interface ethernet 0/0
R6(config-if)#ip address 172.16.26.2 255.255.255.0
R6(config-if)#no shutdown

R6(config-if)#interface ethernet 0/1
R6(config-if)#ip address 172.16.67.1 255.255.255.0
R6(config-if)#no shutdown

R6(config)#interface loopback 1
R6(config-if)#ip address 192.168.6.1 255.255.255.0
R6(config-if)#no shutdown

و بلخره روتر آخر یعنی هفتم را نیز کانفیگ می کنیم:

R7(config)#interface ethernet 0/0
R7(config-if)#ip address 172.16.67.2 255.255.255.0
R7(config-if)#no shutdown

R7(config-if)#interface loopback 1
R7(config-if)#ip address 192.168.7.1 255.255.255.0
R7(config-if)#no shutdown

عملا از اینجا به بعد تازه شروع میکنیم به انجام تنظیمات eigrp بر روی تمام روتر ها، اولین کاری که باید انجام دهیم فعال کردن پروتکل و انتخاب یک Autonomous System یک سالن برای تمام روتر ها می باشد و سپس شبکه های هر روتر را به آن معرفی می کنیم.

Autonomous System: در بالای همین مقاله به آن اشاره کرده ایم، عددی که می توانیم استفاده کنیم از 1 تا 65535 می باشد.

wild card bits: ساده ترین توضیح که می توان برای wild card bits گفت این است که برعکس Subnet mask نوشته می شود که باغث دقت در مسیریابی می شود. در اینجا استفاده از wild card به صورت اختیاری می باشد و در صورت نیاز می توانید از آن استفاده کنید.

نکته: شما می توانید به صورت تک تک برای مثال 172.16.12.0 و wild card آن را وارد کنید و یا چون دو شبکه 172.16.12.0 و 172.16.112.0 داریم فقط از 172.16.0.0 استفاده کنیم. عملا در این سناریو با زدن 172.16.0.0 در روتر اول ما 7 شبکه متصل به روتر اول را برای آن مشخص کردیم نیاز نیست به صورت تک تک وارد کنیم.

نکته: ما در پست “آموزش CCNA : پروتکل مسیریابی RIP یا Routing Information Protocol چیست؟” درباره auto-summary صحبت کردیم، در این سناریو برای این که لازم نباشه تمام ای پی های رنج 10.0.0.0 روتر اول را به صورت دستی وارد کنیم ما با دستور no auto-summary قابلیت auto-summary را غیرفعال می کنیم تا فقط با معرفی 10.0.0.0 کل شبکه های آن معرفی شود.

حالا هر یک از روترها را به صورت زیر کانفیگ میکنیم

R1(config)#router eigrp 100
R1(config-router)#no auto-summary
R1(config-router)#network 172.16.0.0
R1(config-router)#network 10.0.0.0

R2(config)#router eigrp 100
R2(config-router)#network 192.168.2.0
R2(config-router)#network 172.16.0.0

R3(config)#router eigrp 100
R3(config-router)#network 192.168.3.0
R3(config-router)#network 172.16.0.0

R4(config)#router eigrp 100
R4(config-router)#network 192.168.4.0
R4(config-router)#network 172.16.0.0

R5(config)#router eigrp 100
R5(config-router)#network 192.168.5.0
R5(config-router)#network 172.16.0.0

R6(config)#router eigrp 100
R6(config-router)#network 192.168.6.0
R6(config-router)#network 172.16.0.0

R7(config)#router eigrp 100
R7(config-router)#network 192.168.7.0
R7(config-router)#network 172.16.0.0

به همین راحتی شبکه سناریوی ما باید بدون مشکل از پروتکل EIGRP استفاده کنید.

با استفاده از دستور زیر (passive-interface) ما مشخص کرده ایم که در AS 100 ما (router eigrp 100) و بر روی اینترفیس loopback 1 (یا هر اینترفیسی دیگر) دیگر پیغام HELLO فرستاده نشود.

R7(config)#router eigrp 100
R7(config-router)#passive-interface loopback 1

در آخر هم چنتا دستور پر کاربرد Show که به ما جهت رفع اشکال کمک می کند را قرار داده ایم

R1#show ip route

R1#show ip eigrp neighbors

R1#show ip eigrp topology

R1#show ip protocols

R1#show ip eigrp topology all-links

در صورتی که نیاز به سناریو های بیشتری دارید میتونید از فیلم های آموزش رایگان اینترنت استفاده کنید، برای نمونه من دو ویدیو در زیر قرار داده ام.

 

 

سناریوی IPv6 پروتکل EIGRP

سناریوی EIGRP IPv6
سناریوی EIGRP IPv6

به صورت پیش فرض بحث IPv6 در روتر های سیسکو غیرفعال می یاشد پس لازم است با دستور زیر روتینگ برای IPv6 فعال می شود.

تنظیمات اولیه روتر اول ما به شکل زیر انجام می شود

NEXTADMIN-R1(config)#ipv6 unicast-routing
NEXTADMIN-R1(config)#interface loopback 1
NEXTADMIN-R1(config-if)#ipv6 address 2001:1111:1111:1111::1/64
NEXTADMIN-R1(config-if)#no shutdown

NEXTADMIN-R1(config)#interface fastEthernet 1/0
NEXTADMIN-R1(config-if)#ipv6 address 2001:1212:1212:1212::/64 eui-64
NEXTADMIN-R1(config-if)#no shutdown

NEXTADMIN-R1(config)#interface fastEthernet 0/0
NEXTADMIN-R1(config-if)#ipv6 address 2001:1313:1313:1313::/64 eui-64
NEXTADMIN-R1(config-if)#no shutdown

نکته: با دستور ipv6 unicast-routing قابلیت روتینگ در IPv6 را فعال می کنیم

نکته: از قبل در دو پست “آموزش نتورک پلاس (+Network) – معرفی IPv4 و IPv6” و “آموزش CCNA : معرفی و دستورات IPv6 در سیسکو” درباره eui-64 صحبت کرده بودیم، با استفاده از eui-64 خود روتر آدرس Host ما را ایجاد می کند

سپس با دستورات زیر بحث eigrp را بر روی روتر خود فعال می کنیم

NEXTADMIN-R1(config)#ipv6 router eigrp 100
NEXTADMIN-R1(config-rtr)#eigrp router-id 1.1.1.1

NEXTADMIN-R1(config)#interface fastEthernet 1/0
NEXTADMIN-R1(config-if)#ipv6 eigrp 100

NEXTADMIN-R1(config)#interface fastEthernet 0/0
NEXTADMIN-R1(config-if)#ipv6 eigrp 100

NEXTADMIN-R1(config)#interface loopback 1
NEXTADMIN-R1(config-if)#ipv6 eigrp 100

eigrp router-id: یک شناسه unique 32-bit است که هر روتر باید یک آدرس داشته باشد، در ورژن ipv4 این ID به صورت خودکار انتخاب می شود ولی در IPv6 به صورت دستی آن را انتخاب میکنیم. در اینجا چون IPv4 نداشتیم مجبور به دادن آن به صورت دستی هستیم.

نکته: با دستور ipv6 eigrp 100 بر روی هر اینترفیس آن را به عنوان شبکه آن AS به eigrp معرفی می کنیم، این کار مانند معرفی network در ورژن IPv4 می باشد.

حال به روتر دوم می رویم و مانند روتر اول آن را کانفیگ می کنیم:

NEXTADMIN-R2(config)#ipv6 unicast-routing

NEXTADMIN-R2(config)#ipv6 router eigrp 100
NEXTADMIN-R2(config-rtr)#eigrp router-id 2.2.2.2

NEXTADMIN-R2(config)#interface loopback 2
NEXTADMIN-R2(config-if)#ipv6 address 2001:2222:2222:2222::2/64
NEXTADMIN-R2(config-if)#no shutdown
NEXTADMIN-R2(config-if)#ipv6 eigrp 100

NEXTADMIN-R2(config)#interface fastEthernet 0/0
NEXTADMIN-R2(config-if)#ipv6 address 2001:1212:1212:1212::/64 eui-64
NEXTADMIN-R2(config-if)#no shutdown
NEXTADMIN-R2(config-if)#ipv6 eigrp 100

NEXTADMIN-R2(config)#interface fastEthernet 1/0
NEXTADMIN-R2(config-if)#ipv6 address 2001:2323:2323:2323::/64 eui-64
NEXTADMIN-R2(config-if)#no shutdown
NEXTADMIN-R2(config-if)#ipv6 eigrp 100

حالا دقیقا مثل دو روتر قبل بر روی روتر سوم هم همان دستورات را وارد می کنیم:

NEXTADMIN-R3(config)#ipv6 unicast-routing
NEXTADMIN-R3(config)#ipv6 router eigrp 100
NEXTADMIN-R3(config-rtr)#eigrp router-id 3.3.3.3

NEXTADMIN-R3(config)#interface loopback 3
NEXTADMIN-R3(config-if)#ipv6 address 2001:3333:3333:3333::3/64
NEXTADMIN-R3(config-if)#no shutdown
NEXTADMIN-R3(config-if)#ipv6 eigrp 100

NEXTADMIN-R3(config)#interface fastEthernet 0/0
NEXTADMIN-R3(config-if)#ipv6 address 2001:1313:1313:1313::/64 eui-64
NEXTADMIN-R3(config-if)#no shutdown
NEXTADMIN-R3(config-if)#ipv6 eigrp 100

NEXTADMIN-R3(config)#interface fastEthernet 1/0
NEXTADMIN-R3(config-if)#ipv6 address 2001:2323:2323:2323::/64 eui-64
NEXTADMIN-R3(config-if)#no shutdown
NEXTADMIN-R3(config-if)#ipv6 eigrp 100

در آخر هم چنتا دستور پر کاربرد Show که به ما جهت رفع اشکال کمک می کند را قرار داده ایم

R1#show ipv6 route

R1#show ipv6 interface brief

R1#show ipv6 eigrp neighbors

R1#show ipv6 eigrp topology

R1#show ipv6 protocols

R1#show ipv6 eigrp topology all-links

در صورتی که نیاز به سناریو های بیشتری دارید میتونید از فیلم های آموزش رایگان اینترنت استفاده کنید، برای نمونه من دو ویدیو در زیر قرار داده ام.

 
 
 
IP Routing: EIGRP Command Reference, Cisco IOS XE Release 3SE (Catalyst 3850 Switches)
 

A

address-family (EIGRP) 
af-interface 
authentication key-chain (EIGRP) 
authentication mode (EIGRP) 
auto-summary (EIGRP) 
autonomous-system (EIGRP) 

B

bandwidth-percent 

D

default-information 
default-metric (EIGRP) 
distance (IPv6 EIGRP) 

E

eigrp event-log-size 
eigrp log-neighbor-changes 
eigrp log-neighbor-warnings 
eigrp router-id 
eigrp stub 
exit-address-family 
exit-af-interface 

H

hello-interval 
hold-time 

I

ip authentication key-chain eigrp 
ip authentication mode eigrp 
ip bandwidth-percent eigrp 
ip hello-interval eigrp 
ip hold-time eigrp 
ip next-hop-self eigrp 
ip split-horizon eigrp 
ip summary-address eigrp 

M

match extcommunity 
metric maximum-hops 
metric weights (EIGRP) 

N

neighbor (EIGRP) 
network (EIGRP) 
next-hop-self 
nsf (EIGRP) 

O

offset-list (EIGRP) 

P

passive-interface (EIGRP 

R

router eigrp 

S

set metric (EIGRP) 
set tag (IP) 
show eigrp address-family accounting 
show eigrp address-family events 
show eigrp address-family interfaces 
show eigrp address-family neighbors 
show eigrp address-family timers 
show eigrp address-family topology 
show eigrp address-family traffic 
show eigrp plugins 
show eigrp protocols 
show eigrp tech-support 
show ip eigrp accounting 
show ip eigrp events 
show ip eigrp interfaces 
show ip eigrp neighbors 
show ip eigrp topology 
show ip eigrp traffic 
show ip eigrp vrf accounting 
show ip eigrp vrf interfaces 
show ip eigrp vrf neighbors 
show ip eigrp vrf topology 
show ip eigrp vrf traffic 
shutdown (address-family) 
split-horizon (EIGRP) 
summary-address (EIGRP) 
summary-metric 

T

timers active-time 
timers graceful-restart purge-time 
timers nsf converge 
timers nsf route-hold 
timers nsf signal 
topology (EIGRP) 
traffic-share balanced 

V

variance (EIGRP)

 
Cisco IOS IP Routing: EIGRP Command Reference
 

A

add-paths
address-family (EIGRP)
af-interface
authentication key-chain (EIGRP)
authentication mode (EIGRP)
auto-summary (EIGRP)
autonomous-system (EIGRP)

B

bandwidth-percent
bfd (EIGRP)

C

clear eigrp address-family neighbors
clear ip eigrp neighbors
clear ip eigrp vrf neighbors
clear ipv6 eigrp

D

dampening-change
dampening-interval
default-information
default-metric
distance (IPv6 EIGRP)
distance eigrp
distribute-list prefix-list (IPv6 EIGRP)

E

eigrp
eigrp default-route-tag
eigrp event-log-size
eigrp interface
eigrp log-neighbor-changes
eigrp log-neighbor-warnings
eigrp router-id
eigrp stub
exit-address-family
exit-af-interface
exit-af-topology

F

fast-reroute load-sharing disable (EIGRP)
fast-reroute per-prefix (EIGRP)
fast-reroute tie-break (EIGRP)

H

hello-interval
hold-time

I

ip authentication key-chain eigrp
ip authentication mode eigrp
ip bandwidth-percent eigrp
ip hello-interval eigrp
ip hold-time eigrp
ip next-hop-self eigrp
ip split-horizon eigrp
ip summary-address eigrp
ipv6 authentication key-chain eigrp
ipv6 authentication mode eigrp
ipv6 bandwidth-percent eigrp
ipv6 eigrp
ipv6 hello-interval eigrp
ipv6 hold-time eigrp
ipv6 next-hop-self eigrp
ipv6 router eigrp
ipv6 split-horizon eigrp
ipv6 summary-address eigrp

L

log-neighbor-changes (EIGRP)
log-neighbor-changes (IPv6 EIGRP)
log-neighbor-warnings

M

match extcommunity
match tag list
maximum-prefix
metric holddown
metric maximum-hops
metric rib-scale
metric weights (EIGRP)

N

neighbor (EIGRP)
neighbor description
neighbor maximum-prefix (EIGRP)
network (EIGRP)
next-hop-self
nsf (EIGRP)

O

offset-list (EIGRP)

P

passive-interface (EIGRP)
populate

R

redistribute eigrp
redistribute maximum-prefix (EIGRP)
remote-neighbors source (EIGRP)
route-tag list
route-tag notation
router eigrp

S

set metric (EIGRP)
set tag (IP)
show eigrp address-family accounting
show eigrp address-family events
show eigrp address-family interfaces
show eigrp address-family neighbors
show eigrp address-family timers
show eigrp address-family topology
show eigrp address-family traffic
show eigrp plugins
show eigrp protocols
show eigrp tech-support
show ip eigrp
show ip eigrp accounting
show ip eigrp events
show ip eigrp interfaces
show ip eigrp neighbors
show ip eigrp traffic
show ip eigrp vrf accounting
show ip eigrp vrf interfaces
show ip eigrp vrf neighbors
show ip eigrp vrf topology
show ip eigrp vrf traffic
show ip route tag
show ipv6 eigrp events
show ipv6 eigrp interfaces
show ipv6 eigrp neighbors
show ipv6 eigrp topology
show ipv6 eigrp traffic
show ipv6 route tag
show route-tag list
shutdown (address-family)
split-horizon (EIGRP)
stub
summary-address (EIGRP)
summary-metric

T

timers active-time
timers graceful-restart purge-time
timers nsf converge
timers nsf route-hold
timers nsf signal
topology (EIGRP)
traffic-share balanced

V

variance (EIGRP)
vnet

    نویسندگان
    مینا رضائیجعفر قنبری شوهانیمحمد نصیری
    منبع
    ip.engineeringtosinso.com
    برچسب ها

    نوشته های مشابه

    دیدگاهتان را بنویسید

    نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

    دکمه بازگشت به بالا
    بستن
    بستن