دستکاری مسیر BGP: Route Map ها و Community ها برای مهندسی ترافیک

الگوریتم انتخاب بهترین-مسیر پایه BGP، که پیش‌تر در این مجموعه پوشش داده شد، از یک توالی ثابت از ویژگی‌ها پیروی می‌کند، اما شبکه‌های واقعی نیاز دارند به‌طور فعال روی اینکه کدام مسیر انتخاب می‌شود تأثیر بگذارند به‌جای پذیرش منفعلانه نتیجه پیش‌فرض. این مقاله توضیح می‌دهد route map ها چگونه اطلاعات مسیریابی BGP را فیلتر و تغییر می‌دهند، Local Preference و MED را به‌عنوان دو اهرم اصلی برای تأثیرگذاری روی انتخاب مسیر پوشش می‌دهد، و community های BGP را به‌عنوان یک مکانیزم تگ‌گذاری انعطاف‌پذیر برای هماهنگی سیاست در سراسر کل شبکه معرفی می‌کند.

Route Map های BGPLocal Preference و MEDCommunity های BGP

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

چرا انتخاب مسیر منفعلانه همیشه کافی نیست

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

Route Map ها: ابزاری برای فیلترکردن و تغییر مسیرها

یک Route Map، که به‌طور مختصر پیش‌تر در این مجموعه درباره جلوگیری از حلقه توزیع‌مجدد معرفی شد، یک توالی از عبارات match-and-set است که هم مشخص می‌کند کدام مسیرها تحت‌تأثیر قرار می‌گیرند و هم ویژگی‌های خاص آن مسیرهای منطبق‌شده را تغییر می‌دهد -- ابزار اصلی مورد استفاده در سراسر پیکربندی سیاست BGP.

Router(config)# route-map SET-LOCAL-PREF permit 10
Router(config-route-map)# match ip address prefix-list CUSTOMER-ROUTES
Router(config-route-map)# set local-preference 200

Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 route-map SET-LOCAL-PREF in

-- این route map را روی مسیرهای دریافت‌شده
-- از این همسایه خاص اعمال می‌کند (جهت "in")،
-- و Local Preference را به 200 برای هر مسیری
-- که با لیست پیشوند مشخص‌شده تطبیق دارد تنظیم می‌کند

Local Preference: تأثیرگذاری روی ترافیک خروجی

با یادآوری سلسله‌مراتب ویژگی مسیر BGP که پیش‌تر در این مجموعه بحث شد، Local Preference دوم ارزیابی می‌شود، بلافاصله پس از Weight، و در سراسر یک AS از طریق iBGP به اشتراک گذاشته می‌شود -- که آن را به ابزار اصلی برای تأثیرگذاری روی اینکه کدام نقطه خروج ترافیک خروجی خود یک سازمان استفاده می‌کند وقتی چند مسیر به‌سمت همان مقصد خارجی وجود دارد تبدیل می‌کند.

سناریو: یک سازمان دو اتصال اینترنتی دارد،
یک لینک اصلی پهنای‌باند-بالا و یک لینک
پشتیبان پهنای‌باند-پایین‌تر

Router(config)# route-map PREFER-PRIMARY permit 10
Router(config-route-map)# set local-preference 200

Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 route-map PREFER-PRIMARY in
-- اعمال‌شده روی روتر متصل به لینک اصلی،
-- تنظیم یک Local Preference بالاتر (200 در
-- مقابل پیش‌فرض 100) تضمین می‌کند همه
-- روترها در این AS خروج از میان لینک اصلی
-- را ترجیح دهند

از آنجا که Local Preference از طریق iBGP در سراسر کل AS به اشتراک گذاشته می‌شود، این یک تغییر پیکربندی واحد روی یک روتر روی انتخاب مسیر خروجی هر روتر دیگر درون همان AS تأثیر می‌گذارد -- روشی قدرتمند و متمرکز برای هدایت ترافیک خروجی خود یک سازمان.

MED: تأثیرگذاری روی ترافیک ورودی از یک AS همسایه

MED (Multi-Exit Discriminator) هدف مخالف را خدمت می‌کند: به‌جای تأثیرگذاری روی ترافیک خروجی خود این AS، پیشنهاد می‌دهد به یک AS همسایه که کدام‌یک از چند نقطه ورودی به این AS باید برای ترافیک ورودی ترجیح داده شود.

سناریو: یک سازمان دو اتصال به همان ISP دارد،
و می‌خواهد ترافیک ورودی ورود از میان لینک
اصلی را ترجیح دهد

Router(config)# route-map SET-MED permit 10
Router(config-route-map)# set metric 50

Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 route-map SET-MED out
-- اعمال‌شده خروجی به‌سمت AS همسایه، یک مقدار
-- MED پایین‌تر ترجیح داده می‌شود، پس تنظیم
-- 50 روی لینک اصلی (در مقابل یک مقدار
-- پیش‌فرض بالاتر روی پشتیبان) پیشنهاد می‌دهد
-- AS همسایه باید لینک اصلی را برای ترافیک
-- مقصدش این AS ترجیح دهد

یک محدودیت حیاتی برای درک: برخلاف Local Preference، MED فقط یک پیشنهاد به AS همسایه گیرنده است، که کاملاً آزاد است آن را بر اساس سیاست محلی خودش کاملاً نادیده بگیرد -- MED تأثیر می‌گذارد، اما تضمین نمی‌کند، رفتار ترافیک ورودی، چون تصمیم در نهایت متعلق به پیکربندی BGP خود سازمان همسایه است.

Community های BGP: یک سیستم تگ‌گذاری انعطاف‌پذیر

یک BGP Community (کامیونیتی BGP) یک ویژگی اختیاری و انتقالی است که یک مسیر را با یک مقدار عددی دلخواه تگ می‌کند، که اجازه می‌دهد روترهای در سراسر یک شبکه (یا حتی در سراسر مرزهای AS، وقتی به‌طور مناسب پیکربندی شود) سیاست سازگاری را بر اساس آن تگ اعمال کنند، به‌جای نیاز به تطبیق در برابر پیشوند خاص مسیر در هر جایی که آن سیاست نیاز دارد اعمال شود.

Router(config)# route-map TAG-CUSTOMER permit 10
Router(config-route-map)# match ip address prefix-list CUSTOMER-ROUTES
Router(config-route-map)# set community 65001:100

Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 route-map TAG-CUSTOMER in
Router(config-router)# neighbor 203.0.113.2 send-community

کلیدواژه send-community فراموش‌کردنش آسان و ضروری است: بدون آن، مقادیر community اصلاً به همسایه فرستاده نمی‌شوند، حتی اگر به‌نظر برسد route map آن‌ها را به‌درستی پیکربندی می‌کند -- یک منبع رایج سردرگمی وقتی سیاست مبتنی‌بر-community بی‌سروصدا روی یک روتر دوردست تأثیر نمی‌گذارد.

چرا Community ها سیاست را در مقیاس ساده می‌کنند

بدون community ها:
هر روتری که نیاز دارد سیاست خاصی روی "مسیرهای
مشتری" اعمال کند باید به‌طور مستقل در برابر
لیست پیشوند واقعی مسیرهای مشتری تطبیق دهد،
که نیازمند نگهداری و هم‌گام‌نگه‌داشتن آن لیست
پیشوند در سراسر هر روتر در شبکه است

با community ها:
مسیرها یک‌بار، نزدیک به منبع، با یک مقدار
community مانند 65001:100 که یعنی "مسیر مشتری"
تگ می‌شوند -- هر روتر دیگر در سراسر شبکه سپس
می‌تواند صرفاً روی این مقدار community واحد
تطبیق دهد، بدون نیاز به کپی خودش از لیست
پیشوند واقعی

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

مقادیر Community شناخته‌شده

NO-EXPORT: مسیرهای تگ‌شده با این community
  نباید به هیچ همسایه eBGP تبلیغ شوند، و
  کاملاً درون AS محلی (یا کنفدراسیون) محدود بمانند

NO-ADVERTISE: مسیرهای تگ‌شده با این community
  اصلاً نباید به هیچ همسایه BGP تبلیغ شوند،
  داخلی یا خارجی

Router(config-route-map)# set community no-export

این مقادیر community استانداردشده و شناخته‌شده سیگنال‌های سیاست مشترک و به‌طور جهانی درک‌شده‌ای فراهم می‌کنند که به‌طور سازگار در سراسر تجهیزات فروشندگان مختلف کار می‌کنند، متمایز از مقادیر community خاص سازمانی سفارشی مانند 65001:100 استفاده‌شده در مثال‌های قبلی.

تأیید اعمال Community و ویژگی

Router# show ip bgp 192.168.5.0

BGP routing table entry for 192.168.5.0/24
  Local
    203.0.113.2 from 203.0.113.2 (10.0.0.2)
      Origin IGP, localpref 200, metric 50, valid, external, best
      Community: 65001:100

این خروجی جزئی هر-مسیر دقیقاً تأیید می‌کند کدام ویژگی‌ها واقعاً به یک مسیر خاص اعمال شده‌اند -- گام تأیید ضروری پس از پیکربندی هر سیاست مبتنی‌بر-route-map، که تأیید می‌کند مقادیر Local Preference، MED، و community مورد نظر واقعاً تأثیر گذاشته‌اند به‌جای فرض اینکه پیکربندی همان‌طور که مورد نظر بود کار کرده.

چرا تسلط بر این ابزارها مهارت پیشرفته BGP را متمایز می‌کند

پیکربندی پایه BGP، که پیش‌تر در این مجموعه پوشش داده شد، اتصال را برقرار می‌کند و مسیرها را با استفاده از رفتار پیش‌فرض پروتکل تبادل می‌کند. Route map ها، Local Preference، MED، و community ها چیزهایی هستند که به یک سازمان اجازه می‌دهند به‌طور فعال سیاست کسب‌وکاری و مهندسی-ترافیک خودش را روی آن اتصال پایه بیان کند -- مهارت‌هایی که در لحظه‌ای که یک شبکه بیش از یک مسیر به همان مقصد خارجی دارد و واقعاً نیاز دارد کنترل کند، نه صرفاً مشاهده، اینکه آن انتخاب مسیر واقعاً چگونه رخ می‌دهد، ضروری می‌شوند.

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

مقالات مرتبط

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

هر پروتکل و فناوری‌ای که در سراسر این مجموعه پوشش داده شد فقط زمانی مفید است که یک مسئله شامل آن واقعاً بتواند تحت فشار دنیای واقعی به‌طور کارآمد تشخیص و رفع شود. این مقاله یک روش‌شناسی عیب‌یابی سیستماتیک ساخته‌شده حول لایه‌های 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 را مرور می‌کند، و مبادلات خاصی که هر انتخاب طراحی شامل می‌شود را پوشش می‌دهد.

ادامه