مسابقه ۲ – اندر حکایات کار با مدیر بداخلاق!

سلام به همه‌ی همراهان عزیز.

بعد از مدتی تصمیم گرفته شد که مسابقه ی دیگه ای برپا بشه و مفاهیمی رو به همراه هم یادآوری و بررسی کنیم 🙂

این مسابقه به اتمام رسیده و پاسخ سوالات با توضیحات زیر هر سوال درج شده است.
جهت اطلاع از مسابقات آتی لطفاً عضو خبرنامه وبلاگ و کانال تلگرام شبکه‌ها! شوید.

داستان از جایی شروع میشه که شما به عنوان مدیر شبکه‌ی شعبه‌ی غرب استخدام میشین. در همون بدو ورود به سازمان، ادمین سازمان مرکزی که به شدت بد اخلاق و بی اعصاب هست، دو نکته رو به شما گوشزد میکنه، اول این که سازمان با صرف هزینه ای از شرکت دیگه ای خواسته که برای روتر مرزی شما QoS رو پیاده سازی کنن و دومین نکته ای که با شدت به شما گوشزد میکنه این هست که هر گونه اقدامی از جانب شما که منجر به بروز تغییرات ناخواسته ی مسیریابی یا به وجود اومدن هزینه ی اضافی برای سازمان بشه مساوی هست با اخراج شما!

با یک بررسی متوجه می شید که شما یک روتر مرزی دارین (R1) که با دو روتر PoP سازمان مرکزی (یعنی R2 و R3) از طریق یک نوع لینک ارتباطی مشابه ارتباط داره و روتینگ پروتکل بین اونها برای تبادل اطلاعات مسیریابی، EIGRP هست. وقتی به جدول روت نگاهی میندازید متوجه می‌شید که به تمام مسیرهای خارج از دامنه ی EIGRP، از طریق دو مسیر، یعنی هم از طریق R2 و هم R3 دسترسی دارید. یعنی برای ارسال ترافیک به خارج دامنه ی خودتون، داره لود بالانس (در اصل Load-sharing) انجام میشه. مورد دیگه ای که متوجه میشین این هست که همکار تازه کار و جوانی دارین که معلومات اندکی داره و در نبود شما مسئول شبکه اون هست!!!  😐

بعد از چند روز شما متوجه می شید که لینک بین روتر مرزی شما (R1) و R3 اصلا پایدار نیست و شما Packet loss فراوونی بر روی این لینک دارید. بنابراین تصمیم می گیرید که ترافیکتون رو به طور دایم از سمت روتر R2 ارسال کنین و از مسیر سمت R3 فقط در صورتی استفاده کنین که مسیر از سمت R2 بنا به هر دلیلی fail بشه.
در چنین شرایطی راهکار شما برای رسیدن به همچین هدفی چیه؟

لطفا راهکار و جواب خودتون رو با استدلال کامل (اما نه اضافی) در قسمت نظرات وارد کنید. برنده ی این مسابقه کسی خواهد بود که کاملترین و دقیق ترین و در عین حال ساده ترین استدلال رو برای چنین شرایطی ارایه بده.
نظرات پس از اتمام مسابقه منتشر خواهند شد.

منتظر نظرات و استدلالات ارزشمند شما هستیم 🙂

و اما جواب مسابقه:

با تشکر از همه ی عزیزانی که  لطف کردن و در مسابقه شرکت کردند. قبل از معرفی برنده، بیاید اول با هم روی این سناریو  یک بررسی کلی داشته باشیم:

در صورت سوال این سناریو چند تا نکته وجود داشت که با توجه به اون ها می شد به جواب و استدلال درست رسید:
1– پیاده سازی QoS بر روی لینک های روتر مرزی شعبه ی غرب
2 عدم به وجود اومدن تغییرات ناخواسته ی مسیریابی
3داشتن همکاری جوان و کم تجربه و معلومات کم که در نبود شما مسئول شبکه و تمام مشکلاتی که براش به وجود بیاد، اون هست

حالا می رسیم به بررسی راهکارهایی که میدونیم میشه استفاده کرد (بدون در نظر گرفتن شرایط):
1– استفاده از Policy Base Routing یا همون PBR
2– بنا به اقبال خوبتون با دستور offset-list هم آشنایی دارین.
3– شما می دونید که EIGRP برای محاسبه ی متریک تا مقصد مورد نظر به پارامترهای لینک نگاه می کنه و در بین این پارامترها، Bandwidth و Delay رو به صورت پیش فرض در محاسبات متریک استفاده می کنه.

با توجه به شرایط سناریو و با توجه به روش هایی که شما ازشون اطلاع دارین حالا اقدام به تصمیم گیری می کنید:
1- استفاده از PBR: روش خوبی هست اما در صورتی که هیچ سیاست دیگه ای غیر از همین یک مورد که یک مسیر بهتر و یک مسیر backup بشه، وجود نداشته باشه و از طرف دیگه با توجه به این که شما همکار جوانی دارین که در نبود شما مسئول شبکست و دانش اندکی هم داره، راه حل خوبی تلقی نمیشه. قطعا در صورت بروز هر مشکلی، تی شوت PBR برای چنین شخصی سخت خواهد بود. شما باید حتی الامکان با یک طراحی خوب و سنجیده انقد شبکتون رو بدور از هر پیچیدگی اضافی طراحی بکنید که حتی اگر نبودید و مشکلی رخ داد، همکار شما از پس اون مشکل بربیاد. نه این که ساعت ها درگیر بشه و نهایتا با شما تماس بگیرن و آیا مشکل حل بشه یا نه! در چنین شرایط ساده ای، استفاده از PBR فقط باعث پیچیدگی غیر ضروری خواهد شد.
2- دستور offset-list: مورد خوبی هست اما چرا offset-list؟ مگر offset-list چی کار میکنه؟ شما می دونید که offset-list مستقیما بر delay تاثیر میگذاره. خب تا اینجا offset-list خوب اما مورد بعدی رو هم بررسی کنیم ببینیم چی میشه.
3– پروتکل EIGRP برای محاسبه ی متریک تا یک مقصد از پارامترهای لینک و به صورت پیش فرض Bandwidth و Delay استفاده میکنه: خوب شما دوتا نکته رو میدونید، اول این که روی لینک های روتر مرزیتون از QoS استفاده شده و QoS هم از Bandwidth استفاده میکنه. نکته ی بعدی این که حتی اگر شما QoS هم نداشتید، به شما گوشزد شده که نباید باعث تغییرات ناخواسته ی مسیریابی باشید. شما میدونید پروتکلی مثل OSPF هم دقیقا از Bandwidth لینک در محاسبات Cost خودش استفاده میکنه، اگر در سازمان مرکزی از OSPF و متریک تایپ E1 برای دسترسی به مقاصدی که در شعبه ی شما قرار داده استفاده شده باشه چی؟ اینطوری تغییر Bandwidth مستقیما بر تصمیمات مسیریابی OSPF در سازمان مرکزی اثر میذاره! پس در نتیجه از هر دوی این جهات، Bandwidth اصلا گزینه ی مناسبی برای تغییر نیست!
اما Delay: پروتکل EIGRP تنها پروتکلی هست که از delay در محاسبات متریک خودش بهره میگیره. از طرف دیگه شرکتی مثل سیسکو وقتی دستوری مثل offset-list رو برای دستکاری متریک به یک مقصد پیشنهاد میکنه، کاری میکنه که این مقدار فقط بر روی دیلی تاثیر بذاره و نه bandwidth.
خوب با تمام این برداشت ها، تغییر ِdelay لینک، نه تنها روی عملکرد پروتکل مسیریابی سازمان مرکزی و QoS تاثیری نمیذاره بلکه خیلی ساده تر از پیاده سازی PBR یا حتی offset-list هست. پس  کافیه که delay لینک به سمت R3 فقط به قدری افزایش پیدا کنه که نسبت یه مسیر از سمت R2 متریک بدتری داشته باشه و مسیر R3 به عنوان مسیر بک آپ در توپولوژی  تیبل EIGRP باقی بمونه.

اما یه نکته رو همیشه به خاطر داشته باشبد:  در محاسبه ی متریک EIGRP، پارامترهای لینک هستن که شرکت داده میشن (این پارامترها  کامل در این قسمت از مطالب بلاگ معرفی شدند) و ضرایب K فقط برای وزن دادن به این پارامترها هستن که در واقع مشخص می کنن کدوم پارامترها اهمیت بیشتری در محاسبه ی متریک دارن. هرگز از K Value ها به عنوان پارامترهای متریک نام نبرید و نکته ی مهم در مورد این ضرایب این هست که تغییر این ضرایب، در صورتی که تنها در یک روتر انجام بشه، منجر به از بین رفتن همسایگی اون روتر با سایر همسایه های EIGRP اش خواهد شد. چرا که این ضرایب توسط پیام Hello برای همسایه ها ارسال میشن و در صورت برابر نبودن این ضرایب در دو سمت، یکی از شروط همسایگی رعایت نشده و همسایگی حتی اگر از قبل برقرار هم شده باشه، از بین خواهد رفت. از اونجایی که شما فقط به روتر مرزی خودتون در سازمان دسترسی دارید، به محض تغییر K value ها همسایگی شما با شعبه ی مرکزی از بین میره و خوب، منتظر تماس مدیر برای اخراج باشید! 🙂

نکته ی بعدی در رابطه با دستور offset-list هست. در توضیحاتی که در کانال ذکر شده بود، هدف، بررسی مساله فارغ از وندور بود. اما از اونجایی که نمیدونم باید بگم متاسفانه یا خوشبختانه، ذهن همه با دیدن EIGRP میره به سمت محصولات شرکت سیسکو، باز هم در جواب با یک دستور پیکربندی مواجه شدیم. شاید بگید خوب الان EIGRP فقط روی دیوایس های سیسکو هست. بله من این حرف شما رو تقریبا قبول دارم. اما بیاید منطق سیسکو در پشت استفاده از این دستور رو هم بدونیم. فرض کنیم ساختار بالا مشابه تصویر زیر می بود:

در چنین شرایطی، تغییر delay اینترفیس R1 به سمت R3، چون بر مجموع delay ها و متریکی که روترهای داخل شعبه ی غرب محاسبه می کنن، تاثیر میذاشت، راهکار خوبی نبود. شاید نمیخواستیم روترهای پایین دست ما در شعبه ی غرب دست خوش تغییر در محاسبه ی متریک بشن. در چنین شرایطی استفاده از offset-list برای مسیرهایی که از جانب R3 دریافت می شدن، شاید بهتر می بود.

به همین دلیل هم هست که شرکت سیسکو راهکاری ارایه میده که با تغییر دیلی به طور ضمنی، از این مشکلات احتمالی جلوگیری بشه (من همه ی این ها در حالتی درنظر گرفتم که در هنگام تعریف offset-list  جهت in مورد نظر هست. چون در جهت out به نوعی بر روی روتر بالادست یعنی روتر سازمان مرکزی تغییر شما حاصل میشه و بر اساس داکیومنت های خود سیسکو هم، اگر قرار بر استفاده از offset-list در جهت out باشه، بدترین نقطه برای انجام این کار روتر پایین دست و تبلیغ این تغییر برای روتر بالادستی هست.)

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

Network Designer note: When trying to manually influence EIGRP path selection though interface bandwidth/delay configuration, the modification of bandwidth is discouraged for following reasons:

The change will only affect the path selection if the configured value is the lowest bandwidth over the entire path.  Changing the bandwidth can have impact beyond affecting the EIGRP metrics.  For example, Quality of Service (QoS) also looks at the bandwidth on an interface.

EIGRP throttles its packet transmissions so it will only use 50% of the configured bandwidth.  Lowering the bandwidth can cause EIGRP to starve an adjacency, causing slow or failed convergence and control-plane operation.

Changing the delay does not impact other protocols, nor does it cause EIGRP to throttle back; changing the delay configured on a link only impacts metric calculation.

و اما برنده ی مسابقه:

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

باز هم سپاس فراوان از تمام عزیزانی که لطف کردن و در مسابقه شرکت کردن 🙂

نویسنده: مینا رضائی

محقق و همیشه در حال یادگیری، عاشق نقاشی، گاهی هم نویسندگی یا تألیف کتابای بزرگ :) (مسئولیت و صحت و سقم کلیه ی مطالب منتشر شده از جانب من تنها بر عهده ی خودم می باشد)

10 دیدگاه برای “مسابقه ۲ – اندر حکایات کار با مدیر بداخلاق!”

  1. با سلام
    به منظور رسیدن به این هدف روش هایی متعددی موجود است. برای مثال:
    • استفاده از SLA و محاسبه RTT و تنظیم Bandwidth بر روی لینک
    • استفاده از تکنیک PfR
    خب دو روش بالا برای Performance Routing استفاده میشه و به درد این سناریو که فقط باید یک لینک در یک زمان Active باشه نمیخوره
    بهترین و ساده ترین روش استفاده از امکانات موجود در EIGRP برای تغییر Metric هست که با دو روش تغییر Delay و Bandwidth امکان پذیر هست. از اونجایی که بر روی روتر مرزی QoS راه اندازی شده، تغییر در Bandwidth میتواند عملکرد QoS را دچار اختلال کند که در اینجا فقط کافیه Delay بر روی لینک متصل به R3 را افزایش داد تا این مسیر از Route Table خارج شود(دقت شود Delay تا حد معقولی افزایش داده شود تا به مشکل Infinite Metric مواجه نشویم که کلا این مسیر کنار گذاشته شود)

  2. سلام

    میتونیم از IP SLA برای چک کردن Connectivity استفاده کنیم و از (Policy Base Route(PBR برای overwrite کردن Routing Table استفاده کنیم تا Route هامون از مسیری که ما تعیین کردیم بره

  3. با استفاده از Delay باید Cost مسیر R1-R3 رو افزایش بدیم تا از FIB خارج بشه و در Topology Table EIGRP به صورت Successor باقی بمونه. استفاده از Bandwidth برای این کار به دلیل وجود تنظیمات QOS امکان پذیر نیست.

  4. پاسخ: تغییر delay اینترفیس برای تغییر متریک مسیر دلخواه.

    تغییر Bandwidth مناسب نیست چون qos از آن استفاده خواهد کرد.
    تغییر administrative distance مناسب نیست چون-مثلا اگر AD به ۹۵ تغییر پیدا کنه- route های تزریق شده از ospf بعدا ترجیح داده نخواهند شد.
    استفاده از ofset list هم زمانی مناسب است که شما بخواهید برای prefix های خاصی متریک را تغییر دهید.

  5. میشه با تغییر پارامترهای k فرمول محاسبه EIGRP؛ مقادیری را بدست اورد که مسیری که reliability بیشتری داره (مسیر بین r1,r2) به عنوان Successor در نظر گرفته بشه و خط بین r1,r3 به عنوان feasible successor 🙂
    البته به صورت پیشفرض delay , bandwidth در فرمول در نظر گرفته که با تغییر اونها روی اینترفیس ها میشه این کار را انجام داد‌
    نکته ای هم که باید بهش توجه بشه اینه که برای بدست اوردن مسیر feasible succor نیازه که پارامتر ها طوری تنظیم بشن که توی فرمول :
    feasible successor’s advertised distance < succor's feasible distance
    صادق باشن؛
    در این صورت میتونیم مسیر بین r1,r2 را successor و مسیر r1,r3 را feasible successor در نظر بگیریم تا در صورت دان شدن خط r1,r2 از مسیر feasible successor یا همون مسیر بکاپ استفاده بشه 🙂

  6. با توجه به اینکه ادمین سایت مرکزی تاکید کرده که از هر گونه تغییرات پروتکل مسیریابی خودداری شود و همچنین QOS هم در روتر لبه پیاده سازی شده است (در صورتی که اجازه تغییر مسیریابی را داشتیم می توانستیم از offset-list استفاده کرده و متریک روت یاد گرفته شده از مسیر روتر R3 را افزایش دهیم)، می توان برای سناریو مورد نظر که ترافیک همیشه از روتر R2 عبور کند و فقط در صورتی که لینک R2 قطع شد، ترافیک از R3 عبور داده شود، از Policy Based Routing استفاده کرد. برای این منظور ابتدا یک IP sla از نوع ICMP echo تعریف می کنیم که آدرس روتر R2 را به طور دائم Ping بگیرد و در ادامه یک Track تعریف می کنیم که این IP sla را دنبال کند. سپس یک ACL می نویسیم که Prefix های استفاده شده در سازمان مرکزی را در بر بگیرد، سپس باید یک Route-map نوشت که بسته های IP را با توجه به ACL نوشته شده، بررسی کند و آنهایی که با ACL برابر بودند را IP next-hop آنها را برابر روتر R2 ست کند و همچنین Track را هم دنبال کند و تنها در صورتی که Track موفقیت آمیز بود، ip next-hop را تغییر دهد. کانفیگ آن شبیه کانفیگ زیر می شود :

    access-list 101 permit ip any host 4.4.4.4
    فرض می کنیم که Prefix برابر ۴٫۴٫۴٫۴ مربوط به سازمان مرکزی بوده و آن را از هر دو روتر R2 و R3 یاد گرفته ایم

    ip sla monitor 1
    type echo protocol ipIcmpEcho 10.0.2.2
    فرض می کنیم که آدرس ۱۰٫۰٫۲٫۲ برابر آدرس روتر R2 می باشد.
    ip sla monitor schedule 1 life forever start-time now
    track 1 rtr 1 reachability
    route-map pbr permit 10
    match ip address 101
    set ip next-hop verify-availability 10.0.2.2 1 track 1
    در تعریف route-map از قابلیت Verify-availability استفاده می کنیم تا اگر مشکلی برای روتر R2، به وجود آمد، بسته ها بتوانند از مسیر روتر R3 به سازمان مرکزی ارسال شوند.

    interface FastEthernet1/0
    ip address 10.0.1.1 255.255.255.0
    ip policy route-map pbr
    و در نهایت Route-map نوشته شده را به اینترفیس LAN ای روتر R1 تخصیص می دهیم.
    دقت کنید که برای سناریو بالا می توانستیم از ابزار های خود پروتکل EIGRP (تغییر مقدار Bandwidth و Delay لینک و یا استفاده از Offset-list) استفاده کنیم و سناریو مورد نظر را پیاده سازی کرد ولی چون تاکید شده که از تغییر مسیریابی پرهیز شود، و همچنین QOS نیز پیاده سازی شده است (QOS به مقدار Bandwidth لینک حساس است) می توان از این روش استفاده کرد.

  7. با سلام و احترام
    بنظرم راهکار برای این کار IP SLA هست.
    باید IP SLA روی روتر R1 طوری Config بشه که به محض Fail شدن R2 ، ترافیک از طریق مسیری که R3 در اختیار R1 میگذاره عبور داده بشه و مجدد به محض بازگشت R2 ، ترافیک بر روی مسیر اصلی بیافته.

پاسخی بگذارید

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

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.