EIGRP پیشرفته: تعادل بار هزینه-نابرابر و خلاصه‌سازی مسیر

پیکربندی پایه EIGRP، که پیش‌تر در این مجموعه پوشش داده شد، فقط سطح آنچه پروتکل می‌تواند انجام دهد را می‌خراشد -- EIGRP می‌تواند ترافیک را در سراسر مسیرهایی با هزینه‌های واقعاً متفاوت توزیع کند، و می‌تواند مسیرها را در هر نقطه دلخواهی از شبکه به‌جای فقط مرزهای ناحیه ثابت خلاصه کند. این مقاله تعادل بار هزینه-نابرابر مبتنی‌بر-variance EIGRP را توضیح می‌دهد، خلاصه‌سازی مسیر انعطاف‌پذیر در هر اینترفیس را پوشش می‌دهد، و مسیریابی stub EIGRP برای توپولوژی‌های hub-and-spoke را مرور می‌کند.

Variance EIGRPخلاصه‌سازی EIGRPمسیریابی Stub EIGRP

~7 دقیقه مطالعه · آخرین به‌روزرسانی ۲۱ شهریور ۱۴۰۵

فراتر از تعادل بار هزینه-برابر

هر پروتکل مسیریابی که تاکنون در این مجموعه پوشش داده شده، شامل OSPF و EIGRP پایه، که پیش‌تر در این مجموعه بحث شد، به‌طور خودکار فقط وقتی آن مسیرها هزینه دقیقاً برابر دارند در سراسر چند مسیر تعادل بار برقرار می‌کند. EIGRP چیز انعطاف‌پذیرتری ارائه می‌دهد: توانایی تعادل بار در سراسر مسیرهایی با هزینه‌های واقعاً متفاوت، و توزیع متناسب ترافیک بر اساس اینکه آن هزینه‌ها واقعاً چقدر نزدیک‌اند.

دستور Variance: فعال‌کردن تعادل بار هزینه-نابرابر

به‌یاد بیاورید از پیش‌تر در این مجموعه که الگوریتم DUAL EIGRP یک Feasible Successor را شناسایی می‌کند -- یک مسیر پشتیبان تضمین‌شده بدون‌حلقه، اما که طبق تعریف معیار بالاتری از successor دارد. دستور variance اجازه می‌دهد EIGRP واقعاً از یک یا چند feasible successor برای فوروارد‌کردن ترافیک هم‌زمان استفاده کند، نه فقط آن‌ها را به‌عنوان پشتیبان در ذخیره نگه دارد.

Router(config)# router eigrp 100
Router(config-router)# variance 2

-- این اجازه می‌دهد هر feasible successor که
-- معیارش حداکثر 2 برابر معیار successor باشد
-- نیز برای فوروارد‌کردن فعال استفاده شود

مثال: اگر معیار successor 1000 باشد،
یک feasible successor با معیار تا 2000
اکنون نیز واجد شرایط فوروارد‌کردن ترافیک می‌شود

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

Router# show ip route 192.168.2.0

Routing entry for 192.168.2.0/24
  Known via "eigrp 100", distance 90, metric 1000
  * 10.0.0.2, via GigabitEthernet0/1
    10.0.1.2, via GigabitEthernet0/2

-- هر دو مسیر نصب می‌شوند. EIGRP ترافیک را در
-- سراسر آن‌ها به نسبت معکوس معیارهایشان توزیع
-- می‌کند -- مسیر با معیار 1000 به‌طور متناسب
-- ترافیک بیشتری نسبت به مسیری با معیار 1500
-- دریافت می‌کند، به‌جای یک تقسیم برابر 50/50

این توزیع متناسب، به‌جای یک تقسیم برابر، یک تمایز مهم از تعادل بار هزینه-برابر ساده است: EIGRP ترافیک بیشتری را به‌سمت مسیر واقعاً بهتر می‌فرستد و به‌طور متناسب کمتر به‌سمت مسیر بدتر (اما همچنان بدون‌حلقه)، که استفاده کارآمد از هر دو لینک را بدون رفتار با یک مسیر پشتیبان به‌طور قابل‌توجه بدتر به‌عنوان به‌همان‌اندازه ترجیحی با مسیر اصلی امکان‌پذیر می‌کند.

ریسک تنظیم Variance به‌طور بیش‌ازحد بالا

Router(config-router)# variance 100

-- یک مقدار variance بیش‌ازحد بالا می‌تواند اجازه
-- دهد مسیرهایی با معیارهای به‌طور چشمگیر بدتر در
-- فوروارد‌کردن شرکت کنند -- برای مثال، یک لینک
-- پشتیبان ازدحام‌شده و کم-پهنای‌باند ممکن است
-- همراه با یک لینک اصلی پهنای‌باند-بالا واجد
-- شرایط شود، که بالقوه کارایی کلی ضعیفی ایجاد
-- می‌کند اگر ترافیک به‌طور متناسب به‌سمت یک مسیر
-- واقعاً نامناسب فرستاده شود

Variance باید عمداً بر اساس ویژگی‌های لینک واقعی در یک شبکه مشخص پیکربندی شود، به‌جای تنظیم به یک مقدار به‌طور دلخواه بالا صرفاً برای حداکثرکردن تعداد مسیرهای استفاده‌شده -- وجود یک feasible successor به‌طور خودکار به این معنا نیست که باید به‌طور فعال برای فوروارد‌کردن ترافیک استفاده شود.

خلاصه‌سازی مسیر دستی در هر اینترفیس

برخلاف OSPF، جایی که خلاصه‌سازی فقط در روترهای مرزی ناحیه قابل‌پیکربندی است، که پیش‌تر در این مجموعه بحث شد، EIGRP اجازه می‌دهد خلاصه‌سازی دستی اساساً در هر اینترفیس روی هر روتری پیکربندی شود.

Router(config)# interface gigabitethernet 0/1
Router(config-if)# ip summary-address eigrp 100 192.168.0.0 255.255.0.0

-- این روتر یک مسیر خلاصه‌شده /16 واحد را از
-- این اینترفیس خاص تبلیغ می‌کند، صرف‌نظر از
-- اینکه چند زیرشبکه /24 منفرد واقعاً پشتش
-- وجود دارند -- و این می‌تواند روی هر روتری
-- پیکربندی شود، نه فقط روترهای مرزی تعیین‌شده

این انعطاف‌پذیری یک مزیت واقعی نسبت به خلاصه‌سازی سخت‌گیرانه‌تر فقط-مرز-ناحیه OSPF است -- یک شبکه EIGRP می‌تواند مسیرها را دقیقاً در نقطه‌ای از توپولوژی که واقعاً منطقی است خلاصه کند، به‌جای اینکه محدود به خلاصه‌کردن فقط جایی باشد که یک مرز ناحیه اداری اتفاقاً وجود دارد.

مسیر Discard خودکار‌ساخته‌شده

Router# show ip route

D    192.168.0.0/16 is a summary, 00:05:12, Null0

-- هروقت یک مسیر خلاصه پیکربندی شود، EIGRP
-- به‌طور خودکار یک مسیر به Null0 (یک اینترفیس
-- discard) برای خود بازه خلاصه‌شده نصب می‌کند --
-- این از یک حلقه مسیریابی جلوگیری می‌کند:
-- اگر یک بسته مقصدش یک آدرس درون بازه
-- خلاصه‌شده باشد اما با هیچ زیرشبکه واقعی
-- خاص‌تری تطبیق نداشته باشد، در اینجا دور
-- ریخته می‌شود به‌جای اینکه به‌سمت هر روتری
-- که ابتدا خلاصه را تبلیغ کرده فرستاده شود،
-- که می‌توانست یک حلقه بی‌نهایت بین دو روتر
-- ایجاد کند

این مسیر discard خودکار یک مکانیزم ایمنی مهم است که نادیده‌گرفتنش آسان است -- بدون آن، یک بسته مقصدش یک آدرس درون بازه خلاصه تبلیغ‌شده اما واقعاً متناظر با هیچ زیرشبکه واقعی نباشد می‌توانست به‌طور بی‌پایان بین روترها بجهد، هرکدام باور دارند دیگری یک مسیر خاص‌تری دارد.

مسیریابی Stub EIGRP: بهینه‌سازی توپولوژی‌های Hub-and-Spoke

در یک توپولوژی hub-and-spoke، که پیش‌تر در این مجموعه درباره جایگزین WAN سنتی SD-WAN بحث شد، روترهای spoke معمولاً فقط یک مسیر واحد بازگشت به hub دارند و نیازی به عمل‌کردن به‌عنوان یک مسیر ترانزیت برای ترافیک بین سایر spoke ها ندارند. EIGRP Stub Routing (مسیریابی stub EIGRP) اجازه می‌دهد یک روتر spoke صراحتاً hub را از این محدودیت مطلع کند.

Spoke-Router(config)# router eigrp 100
Spoke-Router(config-router)# eigrp stub connected summary

-- این روتر را به‌عنوان یک stub اعلام می‌کند، و
-- فقط مسیرهای متصل و خلاصه را تبلیغ می‌کند، و
-- صراحتاً به روتر hub می‌گوید این spoke را
-- هنگام جستجوی یک مسیر جایگزین در طول همگرایی
-- پرس‌وجو نکند

بهره واقعی در اینجا مستقیماً به فرآیند query DUAL، که پیش‌تر در این مجموعه بحث شد، مربوط است: وقتی یک مسیر غیرقابل‌دسترسی می‌شود و هیچ feasible successor وجود ندارد، EIGRP باید همسایگان را برای یافتن یک مسیر جایگزین پرس‌وجو کند. بدون مسیریابی stub، hub ممکن است هر روتر spoke در یک توپولوژی hub-and-spoke بزرگ را پرس‌وجو کند، حتی اگر spoke ها از پیش شناخته‌شده باشند که هرگز یک مسیر ترانزیت معتبر فراهم نمی‌کنند -- مسیریابی stub این پرس‌وجوی غیرضروری را حذف می‌کند، و همگرایی را دقیقاً در این توپولوژی رایج سرعت می‌بخشد.

تأیید پیکربندی روتر Stub

Hub-Router# show ip eigrp neighbors detail

EIGRP-IPv4 Neighbors for AS(100)
H   Address     Interface   Hold  Uptime
0   10.0.0.2    Gi0/1        13   00:15:42
   Version 20.0/3.0, Retrans: 0, Retries: 0
   Stub Peer Advertising ( CONNECTED SUMMARY ) Routes

این خروجی روی روتر hub تأیید می‌کند به‌درستی spoke را به‌عنوان یک stub تشخیص می‌دهد و دقیقاً می‌داند از آن چه انواع مسیری انتظار داشته باشد -- تأیید ضروری هنگام عیب‌یابی اینکه چرا مسیرهای یک spoke آن‌طور که در جای دیگر توپولوژی انتظار می‌رفت ظاهر نمی‌شوند، یا هنگام تأیید اینکه ترافیک query به‌طور مناسب در طول یک رویداد همگرایی محدود می‌شود.

چرا این ویژگی‌های پیشرفته برای استقرارهای واقعی اهمیت دارند

تعادل بار هزینه-نابرابر، خلاصه‌سازی انعطاف‌پذیر، و مسیریابی stub دقیقاً نوعی رفتار پروتکل ظریف را نشان می‌دهند که شایستگی پیکربندی پایه EIGRP، پوشش‌داده‌شده پیش‌تر در این مجموعه، را از تخصص واقعی مسیریابی پیشرفته جدا می‌کنند. هر ویژگی یک محدودیت خاص دنیای واقعی را حل می‌کند: استفاده کامل از لینک‌های افزونه با پهنای‌باند-نابرابر، خلاصه‌کردن در هر نقطه از توپولوژی شبکه که واقعاً منطقی است به‌جای محدود‌بودن به مرزهای ناحیه، و بهینه‌سازی سرعت همگرایی به‌طور خاص برای الگوی طراحی به‌شدت رایج hub-and-spoke.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

عیب‌یابی سیستماتیک شبکه: یک روش‌شناسی که همه‌چیز را به هم پیوند می‌دهد

هر پروتکل و فناوری‌ای که در سراسر این مجموعه پوشش داده شد فقط زمانی مفید است که یک مسئله شامل آن واقعاً بتواند تحت فشار دنیای واقعی به‌طور کارآمد تشخیص و رفع شود. این مقاله یک روش‌شناسی عیب‌یابی سیستماتیک ساخته‌شده حول لایه‌های OSI ارائه می‌دهد، اعمالش روی یک مسئله اتصال واقع‌بینانه را مرور می‌کند، و نشان می‌دهد دستورات تأیید خاصی که در سراسر این کل مجموعه پوشش داده شدند چگونه در یک فرآیند تشخیصی ساختاریافته جا می‌گیرند.

ادامه

NETCONF، YANG، و پایتون: پیکربندی برنامه‌ای شبکه در مقیاس

REST API ها و فرمت‌های JSON/YAML که پیش‌تر در این مجموعه پوشش داده شدند یک رویکرد به اتوماسیون شبکه را نشان می‌دهند، اما NETCONF و YANG یک جایگزین ساختاریافته‌تر و مبتنی‌بر-استاندارد فراهم می‌کنند که به‌طور خاص برای پیکربندی دستگاه شبکه ساخته شده. این مقاله توضیح می‌دهد چه چیزی NETCONF را از یک REST API ساده متمایز می‌کند، اینکه مدل‌های YANG چگونه دقیقاً تعریف می‌کنند داده پیکربندی چگونه به‌نظر می‌رسد را پوشش می‌دهد، و استفاده از پایتون برای تعامل برنامه‌ای با دستگاه‌های شبکه را مرور می‌کند.

ادامه

اصول IPsec VPN: امن‌سازی ترافیک در سراسر شبکه‌های نامورد‌اعتماد

اتصال دو سایت در سراسر اینترنت عمومی ترافیک را در معرض رهگیری قرار می‌دهد مگر اینکه به‌درستی رمزگذاری شود، و IPsec چارچوب استانداردی برای ساخت تونل‌های امن و احراز‌هویت‌شده بین سایت‌ها فراهم می‌کند. این مقاله فرآیند مذاکره دومرحله‌ای IKE را توضیح می‌دهد، تمایز بین پروتکل‌های AH و ESP را پوشش می‌دهد، پیکربندی یک VPN سایت-به-سایت پایه IPsec را مرور می‌کند، و دستورات تأیید ضروری را پوشش می‌دهد.

ادامه

اصول MPLS: توضیح سوئیچینگ برچسب

مسیریابی IP سنتی نیازمند این است که هر روتر در طول یک مسیر یک جستجوی کامل جدول مسیریابی روی هر بسته انجام دهد، اما MPLS رویکردی اساساً متفاوت را با گرفتن آن تصمیم فوروارد‌کردن یک‌بار و متصل‌کردن یک برچسب ساده که هر روتر بعدی می‌تواند به‌جای آن استفاده کند اتخاذ می‌کند. این مقاله مفهوم اصلی سوئیچینگ-برچسب را توضیح می‌دهد، اینکه پروتکل توزیع برچسب چگونه جداول فوروارد‌کردن برچسبی که این را ممکن می‌کنند می‌سازد را مرور می‌کند، و بهره‌های عملی‌ای که MPLS در شبکه‌های ارائه‌دهنده واقعی فراهم می‌کند را پوشش می‌دهد.

ادامه

Route Reflector و Confederation های BGP: مقیاس‌دهی iBGP فراتر از Full Mesh

نیازمندی full-mesh iBGP، که به‌طور مختصر پیش‌تر در این مجموعه ذکر شد، با رشد یک سیستم خودمختار به یک مسئله جدی مقیاس‌دهی تبدیل می‌شود، که نیازمند تعدادی جلسه است که به‌طور درجه‌دوم با تعداد روتر افزایش می‌یابد. این مقاله دقیقاً توضیح می‌دهد چرا full mesh مقیاس‌پذیر نیست، اینکه route reflector ها چگونه این را با شل‌کردن قوانین معمول انتشار-مسیر BGP حل می‌کنند مرور می‌کند، و confederation ها را به‌عنوان یک رویکرد جایگزین که یک AS واحد را به سیستم‌های خودمختار زیرمجموعه کوچک‌تر تقسیم می‌کند پوشش می‌دهد.

ادامه

بررسی عمیق انواع ناحیه OSPF: Stub، Totally Stubby، و NSSA

طراحی OSPF چندناحیه‌ای پایه، که پیش‌تر در این مجموعه پوشش داده شد، از قبل اندازه پایگاه‌داده را با نگه‌داشتن LSA های جزئی نوع ۱ و ۲ محلی به ناحیه خودشان کاهش می‌دهد، اما انواع ناحیه تخصصی OSPF فراتر می‌روند، و به‌طور خاص LSA های خارجی نوع ۵ را هدف قرار می‌دهند. این مقاله انواع LSA که باید برای ساخت هر نوع ناحیه تخصصی سرکوب شوند را توضیح می‌دهد، پیکربندی نواحی stub، totally stubby، و not-so-stubby را مرور می‌کند، و مبادلات خاصی که هر انتخاب طراحی شامل می‌شود را پوشش می‌دهد.

ادامه