جعفر قنبری شوهانی
مهندس و مدرس زیرساخت و امنیت و مدیر ارشد وب سایت توسینسو

MPLS چیست و چگونه کار می کند؟ کاملترین مرجع آموزش پروتکل MPLS

MPLS چیست؟ ام پی ال اس چیست؟ MPLS چگونه کار می کند؟ پروتکل MPLS شامل چه اجزایی می شود؟ LDP چیست و چه ماهیتی در MPLS دارد؟ تفاوت معماری MPLS و ATM در چیست؟ ... همه این سوالات و تشریح کامل پروتکل MPLS بصورت کامل در این مقاله جامع آموزش داده شده است.

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران

MPLS چیست؟

MPLS چیست؟ MPLS چگونه کار می کند؟ MPLS چگونه راه اندازی می شود؟ Multiprotocol Label Switching) MPLS) یک تکنولوژی انتقال است این تکنولوژی چندین سال است که به یک تکنولوژی معروف و محبوب تبدیل شده است. MPLS از یک مکانیزم Label زدن یا برچسب زدن برای ارسال بسته ها در شبکه استفاده می کند. در این مقاله می خواهیم این تکنولوژی MPLS را مورد بحث قرار دهیم.

وب سایت توسینسو

به طور کلی اگر بخواهیم عملکرد MPLS را شرح دهیم عمل سوئچینگ را با استفاده از مکانیزم Label گذاری در بستر روتینگ انجام می دهد. یعنی یک بسته در هنگام ورود به شبکه MPLS براساس آدرس IP مقصد label گذاری می شود و در طول مسیر در لایه دوم و براساس این label هدایت می شود تا به مقصد برسد.MPLS در یک لایه خاص از OSI قرار نمی گیرد و عملکرد آن بین لایه دوم (Data link) و لایه سوم (Network) قرار می گیرد به همین خاطر آنرا به عنوان یک پروتکل لایه 2.5 معرفی می کنند.

همانطور که اشاره شده MPLS از مکانیزم Label گذاری روی بسته استفاده می کند. Label های MPLS بین روترها پخش می شوند و روترها با استفاده از این labelها می توانند یک نقشه از labelهای شبکه بدست آورند. این labelها به بسته های IP متصل می شوند و روترها را قادر می سازد که با استفاده از این labelها بدون در نظر گرفتن آدرس IP اقدام به ارسال بسته ها کنند. در MPLS بسته ها به وسیله Label switching بجای IP switching ارسال می شوند.

تکنولوژی label switching یک تکنولوژی جدید نیست و شبکه های Frame Relay و ATM برای ارسال فریم ها و cell ها از آن استفاده می کرده اند. در Frame Relay و ATM ، در هر hop از شبکه label تغییر می کند و این تفاوت عمده این دو تکنولوژی با ارسال در IP Packet است. زمانی که روتر یک بسته IP را ارسال می کند هیچ تغییری در آدرس مقصد بسته نمی کند. در واقعیت labelهای MPLS برای ارسال بسته های مورد استفاده قرار می گیرد و از آدرس IP استفاده نمی شود.

استفاده از MPLS چه مزایایی دارد؟

در اینجا به صورت خلاصه مزایای استفاده MPLS را در شبکه عنوان می کنیم :

  • استفاده از یک زیرساخت شبکه یکپارچه
  • بهتر از IP over ATM است
  • Border Gateway Protocol (BGP)-free core
  • بهینه شدن جریان ترافیک
  • مهندسی ترافیک
  • مدل peer-to-peer برای MPLS VPN

زیرساخت شبکه یکپارچه

در MPLS ترافیک در هنگام ورود براساس مقصد label گذاری می شوند و از یک بستر عمومی عبور داده می شوند و این ویژگی یکی از مزایای بزرگ MPLS می باشد. یکی از دلایلی که IP به عنوان پروتکل شبکه جهانی انتخاب شد این است که بسیاری از تکنولوژی های دیگر را می توان از آن عبور داد.

استفاده از MPLS به همراه IP این امکان را به ما می دهد که هر چیزی را که بخواهیم منتقل کنیم. اضافه کردن label به بسته ها باعث می شود که بتوانیم در یک بستر MPLS پروتکل های غیر IP را منتقل کنیم. MPLS میتواند IPv4 ، IPv6 ، Ethernet ، HDLC ، PPP و دیگر تکنولوژی های لایه دو برای برای ما منتقل کند.

به ویژگی که هر نوع فریم لایه دو در بستر MPLS منتقل گردد Any Transport Over MPLS یا AToM گفته می شود. روترهای که ترافیک AToM را منتقل می کنند نیاز به اطلاع از محتوای آن ندارند و برای ارسال آن تنها نیاز به خواندن Label آن دارند.

به زبان ساده می توان MPLS را یک روش ساده برای ارسال ترافیک پروتکل های مختلف در یک شبکه نامید.به توجه به تعاریف بالا MPLS این امکان را به Service Provider می دهد که انواع پروتکل های مورد نیاز مشتریان خود را با استفاده از یک شبکه واحد انتقال دهد.

Better IP over ATM Integration

در دهه 90 میلادی پروتکل IP توانست از سایر پروتکل های لایه سوم مانند AppleTalk ، IPX ، و DECnet پیشی بگیرد. IP یک پروتکل نسبتا ساده و فراگیر است. ATM به عنوان یک پروتکل لایه دوم نتوانست مطابق انتظار ظاهر شود و بیشترین موفقیت آن در استفاده به عنوان یک پروتکل WAN برای Service Provider ها بود.روش های مختلف برای ادغام ATM با IP ارائه شد اما پیاده سازی و خطایابی این روش ها بسیار سنگین و پیچیده بود. یکی از دلایل بوجود آمدن MPLS جایگزینی یک روش جدید و بهتر برای IP over ATM بود.

BGP-Free Core

زمانی که شبکه Service Provider می خواهد ترافیک را منتقل کند هر روتر باید به مقصد بسته نگاه کند. اگر بسته ها به خارج از شبکه Service Provider بخواهد ارسال شود این آدرس های خارجی باید در جدول مسیریابی همه روترها وجود داشته باشد. این آدرس های خارجی توسط BGP حمل می شوند مانند آدرس های شبکه مشتریان یا آدرس های شبکه اینترنت. این به این معناست که همه روترهای Service Provider باید BGP را اجرا کنند.

اما MPLS این امکان را می دهد که ارسال بسته به جای بررسی آدرس IP براساس Label صورت گیرد. این label اطلاعاتی است که به روترهای میانی نشان می دهد که بسته باید به کدام روتر edge ارسال شود. در نتیجه روترهای Core نیازی به داشتن اطلاعات IP برای ارسال بسته ها ندارند و این باعث می شود روتر های Core نیازی به اجرای BGP نداشته باشند.اما روتر های لبه یا همان Edge Router ها همچنان برای ارسال بسته ها نیار به بررسی آدرس IP دارند در نتیجه این روترها باید BGP را اجرا کنند.شکل زیر یک شبکه MPLS را نسان می دهد که روترهای Edge آن BGP را اجرا کرده اند :

وب سایت توسینسو

یک ISP را در نظر بگیرد که دارای 200 روتر است بدون MPLS باید روی تمام این روتر BGP را اجرا کند اما اگر در این شبکه MPLS پیدا سازی شود تنها روتر های Edge که به طور مثال 50 تا هستند نیاز به اجرای BGP دارند.در شبکه های MPLS تمام روتر های Core ارسال بسته ها را بدون در نظر گرفتن آدرس IP و تنها با بررسی label بسته انجام می دهند

و این باعث می شود که از بار اجرای BGP و پیچیدگی های آن رها شوند. جدول مسیریابی اینترنت یک جدول سنگین می باشد که عدم اجرای آن در روترهای Core باعث می شود که روتر به RAM و CPU کمتری نیاز داشته باشد.در بخش بعدی مقاله سایر مفاهیم را مورد بحث قرار می دهیم.

مفاهیم مهم در MPLS

بهینه شدن جریان ترافیک (Optimal Traffic Flow) : با توجه به اینکه سوئیچ های Frame Relay یا ATM یک دستگاه لایه دو هستند روترها برای اتصال از یک مدار مجازی استفاده می کنند. هر روتر برای ارسال ترافیک به صورت مستقیم به هر روتر Edge دیگر باید یک مدار مجازی بین آنها ایجاد گردد.

ایجاد این مدارهای مجازی کار خسته کننده ای است. حال اگر در این شبکه نیاز باشد همه سایت ها به یکدیگر ارتباط داشته باشند باید توپولوژی Full Mesh را به وسیله مدار مجازی بین سایت ها ایجاد کنیم که یک کار سنگین و هزینه بر می باشد. اگر سایت ها مطابق شکل زیر (non-Fully Meshed) به یکدیگر متصل باشند ترافیک از CE1 به CE3 از CE2 عبور می کند.

وب سایت توسینسو

نتیجه این می شود که ترافیک یک مسیر انحرافی را دوبار طی می کند که باعث هدر رفتن پهنای باند و درگیر شدن روتر CE2 می شود.اما زمانی که MPLS در این شبکه پیاده سازی شود ترافیک به صورت مستقیم بین سایت ها جریان پیدا می کند و باعث بهینه شدن جریان ترافیک بین سایت های مشتریان می گردد.

مهندسی ترافیک (Traffic Engineering)

بحث مهندسی ترافیک به منظور استفاده بهینه از زیرساخت شبکه است به این معنا که مهندسی ترافیک بتواند امکان هدایت ترافیک در شبکه را از مسیرهای مختلف غیر از بهترین مسیر را فراهم سازد. بهترین مسیر براساس کمترین هزینه توسط IP Routing انتخاب می شود.

این هزینه توسط پروتکل های داینامیک مسیریابی برای پیدا کردن کوتاه ترین و بهترین مسیر محاسبه می گردد. با استفاده از مهندسی ترافیک MPLS که در شبکه پیاده سازی شده باشد شما می توانید ترافیک با مقصد خاص یا QoS خاص را از نقطه A به نقطه B از مسیری غیر از بهترین مسیر عبور دهید. در نتیجه ترافیک روی همه لینک های موجود تقسیم می شود و باعث می شود از همه توانایی شبکه به بهترین شکل استفاده شود در شکل زیر یک نمونه نمایش داده شده است.

وب سایت توسینسو

همانطور که در تصویر می بینید شما می توانید ترافیک را از نقطه A به B از مسیر پایین انتقال دهید در این مثال مسیر بالا بهترین مسیر بین نقطه A و B است چون مسیر بالا نسبت به مسیر پایین کوتاه تر است. در نتیجه برای ارسال ترافیک ما از مسیری استفاده کرده ایم که کمتر مورد استفاده قرار می گیرد و باعث استفاده بهتر از توان زیرساخت شبکه می شود. یک نمونه دیگر در تصویر زیر نمایش داده شده است.

وب سایت توسینسو

اگر شبکه فوق را یک شبکه IP در نظر بگیریم شما نمی توانید تنها با تنظیم روتر A روتر C را مجبور به ارسال ترافیک از طریق مسیر پایین کنید و این روتر C است که تصمیم می گیرد که ترافیک را از مسیر بالا یا پایین ارسال کند. اما اگر مهندسی ترافیک MPLS را در این شبکه اجرا کنیم می توانیم ترافیک را از روتر A به روتر B از طریق مسیر پایین ارسال کنیم. مهندسی ترافیک روتر C را مجبور به ارسال ترافیک A به B از مسیر پایین می کند. این کار توسط MPLS امکان پذیر است چون از مکانیزم Label زدن استفاده می کند.

در این مثال روتر A به عنوان نقطه ورودی شبکه MPLS ما است در نتیجه این روتر مسیر عبور ترافیک را مشخص می کند این عمل Source-Based Routing نیز نامیده می شود. Label که به بسته تویط روتر A زده می شود باعث می شود که بسته از مسیری که توسط روتر A مشخص کرده عبور کند و دیگر روترهای میانی نمی توانند مسیر آنرا تغییر دهند.

یکی دیگر از مزایای استفاده از مهندسی ترافیک MPLS امکان سریع مسیریابی مجدد یا (Fast ReRouting (FRR می باشد. FRR این قابلیت را به ما می دهد که در صورت بروز قطعی در لینک یا از دسترس خارج شدن روتر ، ترافیک label زده شده را دوباره مسیردهی کنیم این مسیریابی مجدد در کمتر از 50 ms صورت می گیرد که از سایر استانداردهای روز بسیار سریع تر است.

VPN Model

VPN یک شبکه خصوصی مجازی است که روی یک بستر عمومی ایجاد می گردد. این شبکه خصوصی باید بتواند تمام سایت های مشتری را به یکدیگر متصل کند و به صورت کامل از VPNهای مرتبط با سایر مشتریان جدا باشد. معمولا هر VPN به یک سازمان که دارای چند سایت است اختصاص دارد و سایت های سازمان را از طریق VPN روی بستر عمومی Service Provider به یکدیگر متصل می کند.Service Providerها می توانند دو نوع عمده VPN را به مشتریان خود ارائه دهند :

  1. Overlay VPN Model
  2. Peer-to-Peer VPN Model

Overlay VPN Model

Service Provider در Overlay VPN بین روترهای مشتری در شبکه خود سرویس Point to Point یا مداری مجازی (Virtual Circuits) فراهم می کند. روت ها بین روترهای مشتری توسط لینک های ارائه شده توسط Service Provider تبادل می شود. روترها و سوئیچ های Service Provider داده های مشتری را در سرتاسر شبکه خود حمل می کنند و هیچگونه تبادل Route بین روتر مشتری و روتر Service Provider انجام نمی گیرد و این باعث می شود که روترهای Service Provider هرگز Routeهای مشتری را نبینند.

سرویس Point to Point می تواند در لایه یک ، دو و یا سه باشد. نمونه لایه یک آن TDM ، E1 ، E3 ، Sonet و SDH می باشد و نمونه لایه دو X.25 ، ATM و Frame Relay می باشد.در تصویر زیر یک شبکه Overlay را نشان می دهد که بر روی بسته Frame Relay ایجاد شده است. سوئیچ های Frame Relay در شبکه Service Provider برای ایجاد مدار مجازی بین روترهای مشتری که در لبه شبکه Frame Relay قرار دارد تنظیم می گردند.

وب سایت توسینسو

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

وب سایت توسینسو

شبکه Overlay را می توان در لایه سوم ارائه داد و معمولا از GRE Tunnel برای ایجاد شبکه Overlay روی پروتکل IP استفاده می شود. این تونل ترافیک را با هدر GRE و یک هدر IP کپسوله می کند. هدر GRE برای مشخص شدن پروتکل انتقال استفاده می شود و هدر IP برای هدایت بسته ها در شبکه Service Provider مورد استفاده قرار می گیرد. در تصویر زیر یک شبکه Overlay با GRE Tunnel را نشان می دهد. یکی از مزایای استفاده از GRE Tunnel امکان هدایت ترافیک غیر IP است.

وب سایت توسینسو
  • نکته : امکان استفاده از IPsec در GRE Tunnel وجود دارد که با رمزنگاری داده ها باعث تامین امنیت آنها می شود.

در بخش بعدی Peer-to-Peer VPN Model را مورد بحث قرار می دهیم. موفق ، پیروز و itpro باشید.

Peer to Peer VPN 

Peer-to-Peer VPN Model : روترهای Service Provider در مدل Peer to Peer VPN داده های مشتری را در شبکه خود حمل می کنند و همچنین در مسیریابی ترافیک مشتری شرکت می کند. در تعریف دیگر ، روترهای Service Provider برای مسیریابی ترافیک با روترهای مشتری همکاری می کنند که نتیجه آن ایجاد یک رابطه همسایگی بین روترهای مشتری و Service Provider است. در شکل زیر نمونه این شبکه نمایش داده شده است :

وب سایت توسینسو

قبل از اینکه MPLS به وجود آید برای ایجاد شبکه Peer to Peer VPN ، مسیریابی IP با Peer کردن روترهای مشتری و Service Provider انجام می گرفت. همچنین این شبکه نیاز داشت که حریم خصوصی و ایزوله کردن را برای مشتریان انجام دهد که این کار توسط فیلتر کردن بسته (ACL) برای کنترل داده های مشتریان انجام می شد. راه دیگر برای اینکار استفاده از فیلتر کردن Routeها بود یا هر دو روش در کنار هم مورد استفاده قرار می گرفت.

قبل از ارائه MPLS استفاده از مدل Overlay VPN توسط Service Providerها معمول تر از مدل Peer to Peer VPN بود. مدل Peer to Peer VPN نیاز به تدارکات زیادی داشت چون اضافه کردن یک سایت مشتری نیاز به تنظیمات فراوانی در بسیاری از سایت ها به وجود می آورد. یکی از کاربرد های MPLS VPN این است که باعث می شود مدل Peer to Peer VPN به سادگی پیاده سازی گردد.

با استفاده از MPLS امکان حذف و اضافه کردن سایت های مشتری به سادگی قابل تنظیم است و نتیجه آن کاهش زمان و حجم تنظمیات است. در MPLS VPN یک روتر مشتری که به آن روتر (Customer Edge (CE گفته می شود با حداقل یک روتر Service Provider که به آن (Provider Edge (PE گفته می شود در لایه سوم با هم Peer می شوند.

حریم خصوصی در MPLS VPN با استفاده از (Virtual routing/forwarding (VRF و ارسال بسته ها در Backbone شبکه Service Provider با استفاده از label بدست می آید. با استفاده VRF از جدا نگه داشتن اطلاعات مسیریابی مشتریان مختلف از یکدیگر اطمینان حاصل پیدا می کنیم و در Backbone شبکه مطمئن می شویم که ارسال بسته ها براساس اطلاعات label صورت می گیرد نه اطلاعات آدرس IP.شکل زیر مفهوم VRF و ارسال براساس Label در Backbone شبکه در MPLS VPN نمایش داده شده است :

وب سایت توسینسو

در شکل زیر شبکه Peer to Peer VPN در MPLS VPN نمایش داده شده است :

وب سایت توسینسو

در MPLS VPN برای اضافه کردن یک سایت مشتری ، فقط روتر PE با CE باید Peer شوند و دیگر نیاز به ایجاد Virtual Circuit در مدل Overlay VPN یا فیلتر کردن بسته ها یا Routeها در مدل Peer to Peer VPN نیست این یک مزیت بزرگ برای Service Provider ها محسوب می شود.

اکثر مشتریان Service Provider ها نیاز به یک شبکه Hub and Spoke دارند و بعضی از مشتریان نیاز به یک شبکه full mesh دارند و بعضی دیگر یک شبکه بین این دو حالت نیاز دارند. مزیت MPLS VPN برای مشتری زمانی ملموس می شود که مشتری دارای یک شبکه Full Mesh است.دو تصویر زیر را با یکدیگر مقایسه کنید. در تصویر اول مشتری یک شبکه full mesh روی بستر frame relay دارد و تصویر دوم مشتری یک شبکه full mesh روی بستر MPLS VPN دارد.

وب سایت توسینسو
وب سایت توسینسو

در تصویر اول هر روتر لبه مشتری باید به همه روترهای لبه دیگر خود Peer شود که تعداد آن n-1 می شود اما در تصویر دوم هر روتر لبه مشتری تنها با یک روتر لبه Service Provider باید Peer شود.مزیت دیگر برای Service Provider این است که تنها باید یک link بین روتر PE و CE ایجاد کند در صورتی که Service Provider در مدل Overlay باید بین همه سایت های مشتری link یا virtual circuit ایجاد کند.

در روش MPLS VPN پیش بینی ترافیک و فراهم کردن پهنای باند مورد نیاز برای ترافیک برای یک سایت خیلی راحت تر از پیش بینی ترافیک برای کل سایت ها انجام می شود.تنها معایب روش Peer to Peer VPN نسبت به روش Overlay VPN به شرح زیر است :

  • مشتری باید در مسیریابی با Service Provider شریک شود.
  • دستگاه های لبه Service Provider بار بیشتری را متحمل می شوند.

اولین عیب روش Peer to Peer VPN این است که باعث می شود که مشتری برای مسیریابی با Service Provider باید Peer شود و این باعث می شود که مشتری کنترل کاملی روی شبکه خودش نداشته باشد در اینجا منظور مسیریابی در لایه سوم است چون بخشی از این کار توسط Service Provider انجام می گیرد و مشتری روی آن کنترلی ندارد.

دومین عیب این روش به Service Provider برمی گردد افزایش بار برای شبکه Service Provider باعث اضافه شدن وظایف روترهای PE می شود. Service Provider در قابل گسترش و تبادل اطلاعات مسیریابی مشتریان مسئول است و این روترهای PE هستند که وظیفه حمل بموقع دیتا مشتریان را دارند.

برداشت اشتباه

یکی از دلایل اولیه برای استفاده از label switching نیاز به سرعت بیشتر بوده است چون سرعت IP switching نسبت به label switching پایین تر است. در IP switching روتر بسته های IP را با استفاده از آدرس مقصد بسته که در header بسته قرار دارد و پیدا کردن بهترین مسیر از جدول مسیریابی خود برای آن مقصد ارسال می کند. اجرای این مراحل به برند و عملکرد روتر بستگی دارد. به هر حال چون آدرس IP می تواند به صورت unicast یا multicast باشد و از چهار octets تشکیل شده است بررسی آن می تواند پیچیده باشد.

منظور از پیچیده ، این است که تصمیم گیری برای ارسال بسته های IP می تواند زمانبر باشد.اگرچه برخی از مردم تصور می کنند که بررسی یک برچسب ساده نسبت به آدرس بررسی IP می تواند خیلی سریعتر باشد اما در واقع اشتباه است و روتر برای ارسال بسته از ASICs استفاده می کند که باعث می شود سرعت ارسال همانند label سریع باشد. در نتیجه سرعت بالاتر MPLS یک برداشت اشتباه می باشد.

  • نکته : قبل از MPLS ، معروفترین پروتکل WAN را می توان ATM و Frame Relay نام برد.
  • نکته : اندازه فیلدی که در فریم ، label را نگه داری می کند 32 بیت است.

بررسی نحوه عملکرد MPLS

در مقالات قبلی با MPLS و ویژگی های آن آشنا شدیم و در این مقاله می خواهیم نحوی عملکرد آن را مورد بحث قرار دهیم.

Label Switch Router

یک Label Switch Router یا LSR روتری است که از MPLS پشتیبانی می کند. این روترها قادر هستند که Label های MPLS را درک کنند و بسته های label زده را در لایه دو (دیتا لینک) ارسال یا دریافت کنند. در شبکه MPLS چند نوع LSR داریم که به شرح زیر هستند :

  • Ingress LSR : این نوع روترهای LSR ، بسته هایی که دارای Label نیستند را دریافت می کنند و به آنها label می زنند و آنها را در شبکه MPLS ارسال می کنند. این روترها در لبه شبکه MPLS قرار دارند.
  • Egress LSR : این نوع روترهای LSR ، بسته هایی که دارای label هستند را از شبکه MPLS دریافت می کنند و سپس آنها را ارسال می کنند. این روترها در لبه شبکه MPLS قرار دارند.
  • Intermediate LSR : این نوع LSR ، بسته های label زده شده را دریافت می کند عملیاتی را روی آن انجام می دهد سپس آنرا ارسال می کند. این نوع LSR ، روترهای میانی شبکه MPLS می باشند.
  • نکته : روترهای ingress LSR و egress LSR به عنوان Edge LSR شناخته می شوند.
  • نکته : در MPLS VPN روترهای egress LSR و ingress LSR به عنوان provider edge (PE) Router معرفی می شوند. روترهای میانی به عنوان Provider (P) Router معرفی می شوند. این نام ها خیلی معروف شده اند به همین خاطر حتی در شبکه های MPLS از این نام ها استفاده می شود.
  • نکته : یک بسته می تواند چند label داشته باشد و آنها را در label sack قرار می دهد. Label stack یک پشته است.

LSRها باید بتوانند سه عمل زیر را انجام دهند :

  • Pop : حذف label را pop گویند.
  • Push : اضافه کردن label را push گویند.
  • Swap : جایگزینی label جدید با label که در بالای label stack قرار دارد را swap گویند.

روترهای LSR باید بتوانند قبل از ارسال بسته ها ، label را pop کنند همچنین باید بتوانند به بسته های دریافتی یک label را push کنند. اگر بسته دریافتی دارای label باشد LSR ، label مورد نظر را به label stack اضافه می کند و بعد آنرا ارسال می کند.

همچنین اگر بسته label نداشت LSR این label stack را ایجاد می کند و label مورد نظر را به آن push می کند. غیر از موارد فوق LSR باید بتواند swap را نیز انجام دهد. زمانی که یک بسته label زده به دست روتر LSR برسد label که در بالای label stack قرار دارد با label جدید جایگزین می شود.

LSR که به بسته ای که هنوز label نخورده label بزند imposing LSR گفته می شود چون اولین LSR است که label را به بسته می زند. اینکار توسط ingress LSR انجام می شود. LSR که label های یک بسته را خالی می کند و بسته بدون label می کند را disposing LSR گفته می شود. اینکار توسط egress LSR انجام می گیرد.

Label Switched Path

Label Switched Path یا LSP رشته ای از LSR ها است که بسته label زده را از میان شبکه MPLS عبور می دهند. در واقع LSP مسیری است از میان شبکه MPLS که بسته ها آنرا طی می کنند. اولین LSR برای LSP همان ingress LSR می باشد و همچنین اخرین LSP برای LSP نیز egress LSR می باشد و تمام LSR های بین ingress LSR و egress LSR در LSP همان Intermediate LSR می باشند.

  • نکته : LSP یکطرفه می باشند به همین خاطر بین دو edge LSR دو LSP می توانند مسیرهای متفاوتی از یگدیگر داشته باشند.

در شکل زیر ، فلش بالای تصویر جهت LSP را از چپ به راست نشان می دهند.

وب سایت توسینسو

Ingress LSR در یک LSP همیشه به عنوان اولین روتر که به بسته label زده نمی تواند باشد و شاید قبلا توسط یک LSR دیگر label زده شده باشد. نمونه آن LSP تو در تو یا همان nested LSP می باشد که یک LSP در LSP دیگر قرار می گیرد. در شکل زیر نمونه آنرا در شبکه MPLS می بینید.

نقطه شروع LSP دوم از سومین LSR می باشد و نقطه پایان آن LSR ماقبل آخر است در نتیجه زمانی که بسته به ingress LSR این LSP برسد از قبل label خورده است. ingress LSR در LSP دوم دومین label را به بسته push می کند و باعث می شود که label stack ما در اینجا دارای دو label باشد. Label بالایی متعلق به LSP دوم یا همان LSP تودرتو و label پایینی متعلق به LSP اول می باشد.

وب سایت توسینسو

Forwarding Equivalence Class

Forwarding Equivalence Class یا به اختصار FEC گروهی یا جریانی از بسته ها هستند که به یک مسیر خاص متعلق دارند و دارای شرایط یکسانی هستند. همه بسته های که به یک FEC تعلق دارند دارای label یکسان هستند. اما داشتن label یکسان دلیل بر یکسان بودن FEC نمی باشد.

چون مقادیر و عوامل دیگری برای تعیین FEC یکسان وجود دارد. شرایط و رفتار متفاوت در ارسال نیاز به داشتن FEC های متفاوت است. روتری که تصمیم می گیرد که هر بسته به کدام FEC تعلق دارد ingress LSR می باشد چون ingress LSR است که به بسته های ورودی label می زند و آنها را دسته بندی می کند.برخی از نمونه های FEC به شرح زیر هستند :

  • بسته هایی که آدرس لایه سه مقصد آنها یعنی IP Address با یک شبکه خاص یکی است. مقصد همه آنها یک شبکه است.
  • بسته های Multicast که به یک گروه خاص تعلق دارند.
  • بسته های دارای DSCP یکسان
  • فریم های لایه دو که روی یک VC یا Subinterface در ingress LSR دریافت می شوند و در شبکه MPLS منتقل می گردند و از طریق یک VC یا Subinterface در egress LSR حمل می شوند.
  • بسته هایی که IP Address مقصد آنها با یک شبکه که متعلق به BGP است مطابقت پیدا می کنند و همه آنها دارای BGP next hop یکسانی هستند.

نمونه آخر که برای FEC نام برده شد در رابطه با BGP است و یک نمونه قابل توجه است به همین خاطر آنرا بررسی می کنیم. همانطور که گفتیم در ingress LSR تمام بسته هایی که IP Address مقصد آنها با یک مسیر در جدول مسیریابی مربوط به BGP مطابقت پیدا کند و BGP next hop یکسانی داشته باشد به یک FEC تعلق دارد. به این معنی که همه بسته های ورودی به شبکه MPLS براساس BGP next hop خود label می خورند. در شکل زیر یک شبکه MPLS را نشان می دهد که Edge LSR های آن iBGP را اجرا کرده اند.

وب سایت توسینسو

IP Address مقصد بسته ها هنگام ورود به ingress LSR بررسی می شود. آدرس مقصد همه این بسته ها به شبکه های که توسط BGP شناخته شده اند تعلق دارند. بسیاری از این شبکه ها دارای BGP next hop یکسانی هستند یا به عبارتی دارای egress LSR یکسانی هستند. همه بسته هایی که دارای BGP next hop یکسانی هستند در یک FEC قرار می گیرند و همینطور که قبلا گفته شد همه بسته هایی که به یک FEC تعلق دارند به آنها label یکسانی در ingress LSR تعلق می گیرد.در قسمت بعدی سایر مباحث مربوط به عملکرد MPLS را تشزیح خواهیم کرد. موفق ، پیروز و itpro باشید.

Label Distrbution 

اولین label که توسط ingress LSR به بسته زده می شود به یک LSP تعلق دارد و همچنین مسیری که بسته از میان شبکه MPLS طی می کند مربوط به یک LSP است. Ingress LSR یک یا چند label به بسته می زند و LSR های میانی label بالایی بسته دریافتی را با یک label دیگر swap می کنند و سپس آنرا ارسال می کنند و در نهایت label های LSP توسط egress LSR حذف شده و بسته را ارسال می کند.به طور مثال IPv4 over MPLS را به عنوان یک نمونه ساده از شبکه MPLS در نظر بگیرد.

IPv4 over MPLS شبکه ای است که LSR های آن یک پروتکل مسیریابی IGP مانند EIGRP یا OSPF را اجرا کرده اند. Ingress LSR به آدرس IP مقصد بسته نگاه می کند و براساس مقصد به آن label زده و آنرا ارسال می کند. LSR بعدی و سایر LSR های میانی ، بسته label خورده را دریافت کرده label آنرا به یک label جدید swap می کنند

و سپس آنرا ارسال می کنند و در انتها egress LSR بسته را دریافت می کند label آن را pop می کند و سپس روی لینک خروجی خود آنرا ارسال می کند. برای اینکه این شبکه کار کند باید LSR های مجاور قبول کنند که برای هر شبکه IGP از چه label استفاده کنند.

بنابراین هر LSR میانی بتواند تشخیص دهد label هر بسته ورودی با چه label باید swap شود. این به این معنی است که باید ماکنیزمی داشته باشیم که به روترهای بگویم برای یک بسته از کدام label استفاده کند. Label ها به صورت محلی بین هر جفت روتر مجاور تعیین می شوند و چیزی به عنوان Golobal label در سرتاسر شبکه نداریم.

برای این روترهای مجاور سر اینکه برای هر شبکه از چه label استفاده شود توافق کنند باید یک ارتباط بین آنها تشکیل شود. به عبارت دیگر روترها نمی دانند که برای ارسال هر بسته که دریافت کرده اند از چه label استفاده کنند و این باعث می شود به پروتکل های label distribution نیاز پیدا کنیم.

به دو روش امکان پخش کردن label ها وجود دارد :

  • سوار کردن label ها روی پروتکل مسیریابی موجود
  • داشتن پروتکل مستقل برای پخش label ها

سوار کردن label ها روی پروتکل مسیریابی موجود

مزیت اول روش این است که شما نیاز به یک پروتکل جدید در LSR ها ندارید اما پروتکل مسیریابی موجود برای حمل label ها نیاز به گسترش دارند و همیشه این کار آسانی نیست. مزیت بزرگ حمل label ها توسط پروتکل مسیریابی این است که همیشه مسیریابی و label distribution با هم sync هستند

و به این معنی است که که شما هیچ وقت labelی ندارید که شبکه آن از بین رفته یا برعکس همیشه برای همه شبکه ها ، label دارید. اجرای پروتکل های مسیریابیdistance vector ساده است. چون هر روتر برای هر شبکه ، به همسایه خود مسیر اعلام می کند و روتر برای هر شبکه یک label در نظر می گیرد.

پروتکل مسیریابی link state مانند OSPF به این صورت عمل نمی کنند. در پروتکل های link state به جای اعلام مسیر ، وضعیت لینک ها اعلام می شود و روترها براساس این اطلاعات به صورت مستقل برای انتخاب مسیر تصمیم گیری می کنند و این باعث می شود که برای عملکرد MPLS مشکل ایجاد شود.

بنابراین پروتکل های link state نیاز دارند که برای هر شبکه یک label تولید کنند و برای اینکار نیاز به بهینه سازی دارد. از استفاده از یک پروتکل مستقل برای پخش label ها نسبت به این روش ارجحیت دارد.BGP به عنوان یک پروتکل مسیریابی قادر است که پخش label ها را انجام دهد. از این پروتکل عمدتا جهت پخش label ها در MPLS VPN استفاده می شود.

داشتن پروتکل مستقل برای پخش label ها

در روش دوم برای پخش label ها از یک پروتکل مستقل استفاده می شود و مزیت آن مستقل بودن از پروتکل های مسیریابی است. در این روش هر پروتکل مسیریابی می تواند استفاده شود چه بتواند label را پخش کند یا نتواند ، چون یک پروتکل مستقل وظیفه پخش label ها را برعهده دارد و پروتکل مسیریابی وظیفه پخش شبکه ها را برعهده دارد.

تنها عیب این روش نیاز به اجرای یک پروتکل جدید در LSR ها می باشد.پروتکلی که پخش label ها را برای ما انجام می دهد label distribution protocol یا به اختصار LDP نام دارد. البته این تنها پروتکل برای پخش label نیست. چند نمونه از پروتکل های label به شرح زیر هستند :

  • (Tag Distribution Protocol (TDP
  • (Label Distribution Protocol (LDP
  • (Resource Reservation Protocol (RSVP

TDP که از LDP قدیمی تر است و اولین پروتکل برای پخش label می باشد که توسط سیسکو بکار گرفته شد و اختصاصی این شرکت می باشد. بعدا LDP توسط IETF ارائه شد و به لحاظ عملکرد شبیه TDP است اما دارای قابلیت های بیشتری است. LDP به سرعت توسط سیسکو جایگزین TDP شد و باعث شد TDP منسوخ گردد به همین خاطر در این تنها به LDP اشاره خواهیم کرد.RSVP تنها در MPLS TE بکار می رود.

پخش Label ها با LDP

برای هر شبکه IGP که در جدول مسیریابی وجود دارد هر LSR برای آن به صورت local یک label در نظر می گیرد. سپس LSR این label ها را برای همسایه های LDP خود ارسال می کند. سپس همسایه که این label ها را دریافت کرده است label های local و remote را در یک جدول مخصوص به نامlabel information base (LIB) نگه داری می کند.

هر LSR برای هر شبکه تنها یک label به صورت local دارد یا برای هر شبکه و اینترفیس یک label به صورت Local دارد. اما LSR به طور معمولا بیشتر از یک همسایه دارد در نتیجه بیشتر از یک remote label خواهد داشت.برای هر شبکه می توان چندین remote label داشت اما LSR باید از بین آنها یکی را برای ارسال انتخاب کند که جدول مسیریابی تعیین می کند hop بعدی برای این شبکه کدام است.

از remote label ارسالی توسط LSR که در جدول مسیریابی به عنوان hop بعدی برای این شبکه مشخص شده است استفاده می شود. از این اطلاعات برای ساخت جدول label forwarding information base استفاده می شود با استفاده از این جدول label برای بسته ها مشخص می گردد. در شکل زیر نحوی پخش label ها توسط LDP بین LSR ها برای شبکه 10.0.0.0/8 نمایش داده شده است.

وب سایت توسینسو

به شکل زیر توجه کنید یک بسته IPv4 به مقصد شبکه 10.0.0.0/8 توسط ingress LSR وارد شبکه MPLS می شود و به آن label 129 می زند و به LSR بعدی ارسال می کند. LSR دوم label 129 بسته دریافتی را با label 17 عوض کرده و آنرا به سمت LSR سوم ارسال می کند. LSR سوم label 17 بسته دریافتی را با label 33 عوض کرده و آنرا به سمت LSR سوم ارسال می کند و اینکار تا خروج بسته از شبکه MPLS ادامه پیدا می کند.

وب سایت توسینسو

(Label Forwarding Instance Base (LFIB

از جدول LFIB جهت label زدن بسته ها و ارسال آنها استفاده می شود. این جدول با label های ورودی و خروجی سروکار دارد. بسته ورودی دارای یک label از نوع local می باشد که توسط LSR همسایه مورد استفاده قرار گرفته است. بسته با یک remote label از بین remote label های موجود توسط LSR ارسال می شود. تمام remote label ها در LIB قرار دارند که از بین تمام label های موجود در LIB تنها یک label انتخاب و در LFIB قرار می گیرد و انتخاب label به بهترین مسیر موجود در جدول مسیریابی بستگی دارد.

در مثال IPv4 over MPLS برای هر شبکه IPv4 یک label در نظر گرفته شده است. همچنین LFIB می تواند با label هایی کار کند که توسط LDP مشخص نشده باشند به طور مثال در MPLS TE که توسط پروتکل RSVP اینکار انجام می شود یا MPLS VPN که پخش label ها توسط BGP انجام می شود. اما در کل LFIB همیشه برای label بسته ها مورد استفاده قرار می گیرد و مهم نیست به چه روشی این LFIB ایجاد شده است.

  • نکته : LFIB در هنگام فعال شدن MPLS ایجاد می گردد و از آن به بعد برای ارسال بسته از LFIB استفاده می شود.

سناریو عملی MPLS

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

  • سناریو

برای درک بهتر مباحث گفته شده یک سناریو را با هم حل می کنیم. به تصویر زیر دقت کنید روترهای R1 تا R5 به عنوان روترهای شبکه MPLS هستند روترهای R1 و R5 به عنوان روترهای Edge LSR نقش ایفا می کنند و سایر روترها به عنوان LSR های میانی هستند. در این شبکه می خواهیم از PC بسته ای را به سرور که در شبکه 10.0.0.0/8 است ارسال کنیم و نحوی ارسال و label زدن بسته را مورد بررسی قرار دهیم.

وب سایت توسینسو

جهت توزیع label ها از پروتکل LDP استفاده شده است و بین روترها از پروتکل مسیریابی EIGRP بهره گرفته ایم. با در نظر گرفتن شرایط یکسان لینک ها بین روتر ها ، مسیر پایین به عنوان بهترین مسیر برای ارسال بسته ها از R1 به R5 می باشد و به عنوان LSP انتخاب می شود.در ابتدا local label توسط هر روتر برای شبکه ها موجود در جدول مسیریابی تعیین می گردد این کار توسط خود روتر انجام می شود در این مثال شماره label های انتخاب شده توسط هر روتر برای شبکه 10.0.0.0/8 به شرح زیر است :

وب سایت توسینسو
  • نکته : روترها می توانند برای یک شبکه label های یکسان داشته باشند.

در مرحله بعدی این local label ها توسط پروتکل LDP به همسایه ها اعلام می شود به طور مثال R1 به R2 و R3 اعلام می کند که label 19 را برای شبکه 10.0.0.0 انتخاب کرده است و R2 به R1 و R4 اعلام می کند که label 20 را برای شبکه 10.0.0.0 انتخاب کرده است. و اینکار توسط سایر روترها نیز انجام می گیرد. سپس هر روتر local label و remote label هایی را که از همسایه های خود دریافت کرده است را در جدولی تحت عنوان LIB ذخیره می کند. با هم جدول LIB روترها را ببینیم :

وب سایت توسینسو

نکته : روتر R5 به عنوان روتر egress LSR برای شبکه 10.0.0.0/8 می باشد در نتیجه اگر بسته ای برای این شبکه به آن برسد label آنرا pop کرده و بسته را بدون label ارسال می کند. با توجه به این ویژگی می توان بسته را در hop ما قبل آخر بدون زدن label ارسال کرد چون درصورتی که label هم داشته باشد روتر R5 آنرا pop می کند. در این مثال روترهای R3 و R4 می تواند بسته های شبکه 10.0.0.0 را برای R5 بدون label ارسال کنند.

حالا R3 و R4 از کجا متوجه شوند که hop ما قبل آخر هستند؟ اخرین روتر که در اینجا R5 است به همسایه های خود یعنی R2 و R4 اعلام می کند که آخرین روتر است در نتیجه از این به بعد R2 و R4 بسته های مربوط به این شبکه را بدون label ارسال خواهند کرد. به این عمل (penultimate hop popping (PHP گفته می شود.

بعد از اینکه LIB تشکیل شد باید LFIB ایجاد شود. همانطور که قبلا اشاره شد برای ایجاد LFIB از LIB و جدول مسیریابی استفاده می کنیم. به این صورت که برای هر شبکه ما چند label در LIB داریم. برای انتخاب یک label از بین label های موجود ، جدول مسیریابی را بررسی می کنیم و hop بعدی برای رسیدن به این شبکه را پیدا می کنیم و از label که توسط آن برای ما ارسال شده است استفاده می کنیم.

در این مثال R1 در جدول LIB خود 2 عدد remote label دارد که از روترهای R2 و R3 آنها را دریافت کرده است. برای انتخاب یکی از این دو به جدول مسیریابی خود مراجعه می کند و همانطور که قبلا گفتیم مسیر پایین که از روتر R3 می گذرد بهترین مسیر است. در نتیجه label 20 را که از R3 دریافت کرده است را برای LFIB در نظر می گیرد و اینکار توسط سایر روترها نیز انجام می شود.جدول LFIB روترها به شرح زیر است :

وب سایت توسینسو

جدول LFIB ما تشکیل شده است و روترها می توانند براساس label بسته ها را به مقصد ارسال کنند. برای بررسی دقیق تر یک بسته از PC به Server ارسال می کنیم و عملکرد شبکه را در قبال آن بررسی می کنیم : بسته ارسالی از PC به دست R1 می رسد.

R1 بسته را تا لایه شبکه باز می کند و IP مقصد بسته را بررسی می کند. با دیدن آدرس 10.0.0.1 و مقایسه آن با جدول مسیریابی متوجه می شود که بسته را باید به روتر R3 ارسال کند. سپس با استفاده از جدول LFIB متوجه می شود که باید به بسته Label 20 زده و آنرا ارسال کند.

در اینجا روتر R1 به عنوان ingress LSR شناخته می شود. در تصویر زیر خروجی R1 به R3 توسط نرم افزار وایرشارک capture شده است و همانطور که می بینید یک بسته ICMP از آدرس 192.168.1.2 به سمت 10.0.0.1 با label 20 در حال ارسال است.

وب سایت توسینسو

بسته ارسالی به دست روتر R3 می رسد بسته تا لایه دوم باز شده و با دیدن label 20 آنرا با جدول LFIB خود مقایسه می کند و متوجه می شود که بسته را باید به روتر R5 ارسال کند و چون روتر R5 خود را به عنوان اخرین hop معرفی کرده است label 20 را pop کرده و بسته را بدون label به سمت روتر R5 ارسال می کند.

حالا بسته به دست R5 بدون label می رسد و R5 آنرا تا لایه سوم باز می کند و با دیدن IP مقصد و مقایسه آن با جدول مسیریابی آنرا ارسال می کند.یکبار دیگر این مراحل را بررسی کنیم اما اینبار مسیر بالا را به عنوان بهترین مسیر در نظر می گیریم.با همان روش قبل جدول LFIB را پر می کنیم که به صورت زیر تغییر می کند :

وب سایت توسینسو

بسته ارسالی از PC به دست R1 می رسد. R1 بسته را تا لایه شبکه باز می کند و IP مقصد بسته را بررسی می کند. با دیدن آدرس 10.0.0.1 و مقایسه آن با جدول مسیریابی متوجه می شود که بسته را باید به روتر R2 ارسال کند. سپس با استفاده از جدول LFIB متوجه می شود که باید به بسته Label 20 زده و آنرا ارسال کند. بسته ارسالی به دست روتر R2 می رسد بسته تا لایه دوم باز شده و با دیدن label 20 آنرا با جدول LFIB خود مقایسه می کند و متوجه می شود که بسته را باید به روتر R4 ارسال کند.

در نتیجه label بسته را با label 20 ، swap می کند و آنرا برای R4 ارسال می کند.بسته ارسالی به دست روتر R4 می رسد بسته تا لایه دوم باز شده و با دیدن label 20 آنرا با جدول LFIB خود مقایسه می کند و متوجه می شود که بسته را باید به روتر R5 ارسال کند و

چون روتر R5 خود را به عنوان اخرین hop معرفی کرده است label 20 را pop کرده و بسته را بدون label به سمت روتر R5 ارسال می کند. حالا بسته به دست R5 بدون label می رسد و R5 آنرا تا لایه سوم باز می کند و با دیدن IP مقصد و مقایسه آن با جدول مسیریابی آنرا ارسال می کند.در تصویر زیر جدول مسیریابی روتر R1 را مشاهده می کنید :

وب سایت توسینسو

در تصویر زیر LIB روتر R1 را مشاهده می کنید :

وب سایت توسینسو

در تصویر زیر جدول LFIB روتر R1 را مشاهده می کنید :

وب سایت توسینسو

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

Labels و Payload

MPLS Payload چیست؟ MPLS label فیلد Network Level Protocol identifier ندارند. این فیلد در فریم های لایه دو وجود دارد و مشخص می کند پروتکل مورد استفاده در لایه سوم چیست. چگونه LSR ها متوجه می شوند که چه پروتکلی پشت label Stack قرار گرفته است یا به عبارتی چگونه LSR ها متوجه می شوند MPLS payload چیست؟

اکثرا LSR ها نیاز به دانستن MPLS Payload ندارند چون آنها یک بسته label خورده را دریافت کرده label بالایی label stack را swap کرده و بسته را روی لینک خروجی خود ارسال می کنند که اینکار مربوط به intermediate LSR یا P Router ها است.

intermediate LSR یا همان LSR های میانی نیاز به دانستن MPLS payload ندارند چون کلیه اطلاعات مورد نیاز برای سوئیچ کردن بسته ها را با نگاه کردن به label بالایی label stack بدست می آورد. اگر label stack بیشتر از یک label داشته باشد ، label های زیر label بالای label stack شاید توسط LSR اختصاص داده نشده باشند

و شاید intermediate LSR هیچ شناختی از آنها نداشته باشند و علاوه بر آن LSR شاید نداند که چه MPLS payload در حال انتقال است. چون intermediate LSR تنها به label بالای label stack نگاه می کنند و برای ارسال تصمیم گیری می کنند و این عملکرد هیچ مشکلی به وجود نمی آورد. این روش درست برای ارسال ، براساس label بالایlabel stack است و روترهای میانی باید label از نوع local و remote برای label بالایی بسته دریافتی داشته باشند.

اما egress LSR که تمام label های بسته را حذف می کند باید MPLS payload را بداند. چون باید بسته را براساس MPLS payload بعد از حذف label ها ارسال کند. Egress LSR باید بداند از چه مقدار برای فیلدNetwork Level Protocol identifier برای فریم های خروجی خود استفاده کند.

Egress LSR است که local binding را انجام می دهد به این معنی اختصاص local label به یک FEC توسط این LSR انجام می شود و از این label به عنوان label ورودی بسته ها استفاده می کند. بنابراین egress LSR با نگاه کردن به label متوجه می شود که MPLS payload چیست چون این egress LSR است که label برای FEC در نظر می گیرد و متوجه می شود که FEC چیست.

MPLS Label Spaces

در شکل زیر ، LSR A می تواند label L1 را برای FEC 1 به LSR B اعلام کند و label L1 را برای FEC 2 به LSR C اعلام کند. اما در چه صورتی LSR A می تواند تشخیص دهد که بسته با label L1 را از کدام LSR دریافت کرده است. در این مثال LSR B و LSR C به صورت مستقیم به LSR A توسط یک لینک Point to Point متصل هستند که باعث می شود به سادگی توسط MPLS تشخیص داده شود.

با توجه به دریافت بسته روی اینترفیس خاص ، این label توسط اینترفیس منحصر به فرد می شود که به آن per-interface label space گفته می شود. اگر per-interface label space مورد استفاده قرار گیرد بسته فقط براساس label ارسال نمی شود و در واقع براساس label و اینترفیس ورودی عمل ارسال انجام می گیرد.

وب سایت توسینسو

احتمال دیگر این است که label توسط interface منحصربفرد نمی شود. این حالت per-platform label space نامیده می شود. به تصویر زیر توجه کنید در این مثال ، label L1 توسط LSR A برای FEC1 به LSR A,B اعلام می شود. LSR A برای FEC 2 باید Label غیر از label L1 در نظر بگیرد. در صورت استفاده از per-platform label space بسته ها بودن در نظر گرفتن اینترفیس وردوی تنها براساس label ارسال می شوند.

وب سایت توسینسو

در IOS سیسکو از per-interface label space برای cell mode و از per-platform label space برای farme mode استفاده می کند.

  • Different MPLS Modes

عملیات مربوط به label ها در MPLS به بخش های مختلفی تقسیم می شود که عملکرد LSR ها را در این سه بخش مورد بحث قرار می دهیم :

  • Label distribution mode
  • Label retention mode
  • LSP control mode

هر روش ویژگی های خاص خودش را دارد که به آنها می پردازیم.

Label Distribution Modes

معماری MPLS برای پخش label دو روش دارد:

  • Downstream-on-Demand (DoD) label distribution mode
  • Unsolicited Downstream (UD) label distribution mode

در روش DoD ، هر LSR در یک LSP از Next-hop LSR خود یک label برای FEC در خواست می کند. Next-hop LSR را Downstream LSR می نامند و همان Next-hop Router در جدول مسیریابی است.در روش UD ، هر LSR به LSR های همسایه خود label ها را اعلام می کند بودن اینکه برای آنها درخواستی شده باشد. در این روش LSR از همسایه های خود remote label دریافت می کند.در صورت استفاده از روش DoD در LIB تنها یک remote label می بینید در صورتی که در روش UD ، در LIB احتمالا بیش از یک remote label خواهید دید. روش پخش label به اینترفیس و نحوی عملکرد آن بستگی دارد.

Label Retention Modes

این بخش به نحوی نگه داری label ها می پردازد و دو Label Retention Modes وجود دارد :

  • Liberal Label Retention (LLR) mode
  • Conservative Label Retention (CLR) mode

در روش LLR ، یک LSR همه remote label دریافتی را در LIB نگه داری می کند. این remote label ها در LFIB مورد استفاده قرار می گیرند اما فقط یک remote label مورد استفاده قرار می گیرد. در نتیجه تمام این remote label ها مورد استفاده قرار نمی گیرند. پس دلیل نگه داری از remote label هایی که مورد استفاده قرار نمی گیرند چیست؟ مسیریابی در شبکه بصورت پویا است و هر زمان احتمالا تغییر در توپولوژی مسیریابی شبکه وجود دارد.

به طور مثال ، قطع شدن یک لینک ارتباطی یا خراب شدن یک روتر باعث تغییر در توپولوژی مسیریابی می شود که نتیجه آن احتمال تغییر next-hop برای یک FEC می شود. در این زمان remote label برای next-hop جدید در LIB وجود دارد و LFIB به سرعت بروز می شود و label جدید برای خروجی مشخص می شود.

در روش CLR ، یک LSR همه remote label را در LIB نگه داری نمی کند و تنها remote lable که به یک FEC اختصاص داده را نگه داری می کند.به طور خلاصه ، روش LLR امکان تطبیق سریع با جدول مسیریابی را می دهد در حالیکه روش CLR تعداد کمتری label نگه داری می کند که نتیجه آن مصرف کمتر از حافظه روتر می باشد.

LSP Control Modes

این قسمت به نحوی ساخت local label می پردازد که از دو طریق قابل انجام است :

  • Independent LSP Control mode
  • Ordered LSP Control mode

LSR می تواند local label را برای FEC به صورت مستقل از سایر LSR ها ایجاد کنند. که به آن Independent LSP Control mode گفته می شود. در این روش به محض اینکه هر LSR یک FEC را تشخیص دهد برای آن remote label ایجاد می کند.

معمولا زمان اضافه شدن یک شبکه به جدول مسیریابی اینکار انجام می شود.در Ordered LSP Control mode یک LSR فقط زمانی local label برای یک FEC درست می کند که تشخیص دهد برای آن FEC به عنوان egress LSR است یا LSR از next-hop این FEC یک remote label برای آن دریافت کند.

اشکال روش Independent LSP Control این است که LSR ها قبل از اینکه تنظیمات LSP کامل شده باشد شروع به label زدن و ارسال بسته ها می کنند در نتیجه بسته ها به طریقی که باید ارسال شوند ارسال نمی شوند. اگر تنظیمات LSP کامل نشده باشد امکان دارد بسته ها به روشی که ما مد نظرمان است ارسال نشوند و یا حتی اصلا به مقصد نرسیده و drop شوند.

یک مثال برای این دو روش ، به LDP به عنوان روش پخش label ها برای یک شبکه IGP توجه کنید. اگر LSR از روش Independent LSP Control mode استفاده کند باید به هر شبکه موجود در جدول مسیریابی خود یک local label اختصاص دهد. اگر LSR از روش Ordered LSP Control mode استفاده کند.

LSR در صورتی به شبکه های IGP جدول مسیریابی خود local label اختصاص می دهد که آن شبکه به عنوان Connected خود در جدول مسیریابی مشخص شده باشد یا برای آن شبکه ، از روتر next-hop آن ، remote lablel دریافت کند. IOS سیسکو از Independent LSP Control mode استفاده می کند.منتظر قسمت های بعدی باشید. موفق ، پیروز و itpro باشید.

Forwarding Labeled Packets

Forwarding Labeled Packets : در بخش های قبلی به MPLS label پرداختیم و فهمیدیم label چیست و چگونه مورد استفاده قرار می گیرد و حالا در این بخش می خواهیم نحوی ارسال بسته های label خورده را مورد بررسی قرار دهیم. نحوی ارسال بسته های label خورده نسبت به ارسال بسته های IP کاملا متفاوت است و فقط به بررسی label در LIFB به جای جدول مسیریابی بر نمی گردد. در بحث ارسال بسته های label خورده ، عملیات هایی روی label stack مانند pop ، push و swap انجام می گیرد. که در این قسمت به این عملیات ها می پردازیم.

Label Operation

امکان اجرای سه عمل pop ، swap و push روی بسته های label خورده وجود دارد. که در تصویر زیر این عمل ها نمایش داده شده است.

وب سایت توسینسو

LSR با نگاه کردن به label بالای label stack بسته دریافتی و مقایسه آن با مقادیر LFIB متوجه می شود که بسته را چگونه باید ارسال کند. در اینجا LSR مشخص می کند که چه عملیاتی (pop , push , swap) روی بسته باید انجام گیرد و next hop بعدی که بسته باید به آن ارسال شود چیست؟

اگر عمل swap تعیین شود به این معنی است که یک label جدید جایگزین label بالای label stack می شود. در عمل push یک label جدید جایگزین label بالای label stack می شود و یک یا چند label دیگر به بالای label stack اضافه می شود. عمل pop باعث حذف label بالای label stack می شود.

  • نکته : LSR هنگام دریافت یک بسته label خورده 20 بیت اول label بالای label stack را نگاه می کند و مقدار بدست آمده را با local labels موجود در LFIB مقایسه می کند.

IP Lookup در برابر Label Lookup

زمانی که روتر یک بسته IP دریافت کند برای بسته IP lookup انجام می دهد. در IOS سیسکو به این معنی است که آدرس مقصد IP در جدول CEF جستجو می شود. زمانی که روتر یک بسته label خورده دریافت می کند جستجو در LFIB روتر انجام می گیرد.

روتر با نگاه کردن به فیلد پروتکل در هدر لایه دو متوجه می شود که بسته ای که دریافت کرده یک بسته IP یا یک بسته label خورده است. اگر بسته با هر یک از دو روش ( Cisco Express Forwarding (CEF یا LFIB ارسال شده باشد می تواند بعد از دریافت توسط روتر با label یا بدون label از روتر خارج شود. در تصویر زیر تفاوت بین CEF و LFIB نمایش داده شده است.

وب سایت توسینسو

اگر ingress LSR یک بسته IP دریافت کند آنرا lable زده و ارسال می کند که به آن IP-to-label گفته می شود. اگر egress LSR یک بسته label خورده را دریافت کند label آنرا حذف کرده و به عنوان یک بسته IP آنرا ارسال می کند که به آن label-to-IP گفته می شود.

حالت دیگر این است که LSR یک بسته label خورده را دریافت و به صورت label زده آنرا ارسال می کند که به آن label-to-label گفته می شود.در تصویر زیر حالت IP-to-label نمایش داده شده است که ارسال براساس جدول CEF انجام می شود.

وب سایت توسینسو

بسته های IP به مقصد 10.200.254.4 که وارد LSR شوند با label 18 از پورت ethernet0 خارج می شوند. Next-hop برای این بسته ها 10.200.200.2 می باشد. در اینجا IP-to-label انجام می شود. در IOS سیسکو فقط از CEF Switching برای label بسته ها می توان استفاده کرد

و از سایر روش های IP Switching مانند fast switching نمی توان استفاده کرد چون fast switching حافظه ای برای نگه داری اطلاعات مربوط به label ندارد و CEF switching تنها روش IP switching است که قابلیت پشتیبانی از MPLS را دارد به همین خاطر زمانی که از MPLS استفاده می کنیم باید CEF را در روترهای مورد نظر فعال کنیم.تصویر زیر محتویات LFIB را با دستور show mpls forwarding-table نمایش داده است.

وب سایت توسینسو

Local label توسط LSR ایجاد و به سایر LSR ها ارسال می شود. به طور مثال این LSR انتظار دارد که بسته های دریافتی یکی از این label ها را در بالای label stack خود داشته باشند. اگر این LSR یک بسته با label 22 دریافت کند آنرا با label 17 جایگزین کرده (swap) و روی پورت Ethernet 0 ارسال می کند.

که در این حالت label-to-label انجام می گیرد.اگر LSR یک بسته با label 16 دریافت کند تمام label های آنرا حذف می کند (pop) چون untag (بودن label) به عنوان label خروجی برای این label در LFIB در نظر گرفته شده است.

که label-to-IP انجام می گیرد. اگر LSR یک بسته با label 18 دریافت کند label بالای label stack را حذف می کند و آنرا ارسال می کند اگر این label تنها label موجود label stack باشد بسته به عنوان یک بسته IP ارسال می شود در غیر اینصورت به عنوان یک بسته label خورده ارسال می شود. در تصویر زیر یک عمل push نمایش داده شده است که یک در اینجا label 20 بسته جایگزین label 23 می شود و label 16 به بسته push می شود.

وب سایت توسینسو

برای مشاهده تمام تغییرات ایجاد شده در label بسته از دستور show mpls forwarding-table [network] detail می توانید استفاده کنید. در تصویر بالا تفاوت خروجی دستور در صورت استفاده از کلید detail را مشاهده می کنید. در صورت استفاده از کلید detail ، تمام تغییرات در label stack را می توانید مشاهده کنید.

از سمت چپ به راست ، می توانید اولین label را ببینید label 20 جایگزین label 23 می شود و سپس label 16 به label stack اضافه می شود. اما بدون کلید detail تنها label 16 را می بینیم که به label stack اضافه می شود.غیر از سه عملی که قبلا آنها را شرح دادیم یک عمل دیگر تحت عنوان aggregate وجود دارد.

زمانی که شما یک تجمیع یا summarization در یک LSR انجام می دهید LSR برای این شبکه های تجمیع شده یک label خاص منتشر می کند اما aggregate در LFIB به عنوان label خروجی نمایش داده می شود چون LSR یک رنج از شبکه ها را تجمیع کرده است و بسته های label خورده دریافتی را نمی تواند با swap کردن label ارسال کند.

Label خروجی Aggregate نمایش داده می شود که به این معنی است که LSR باید label بسته دریافتی را حذف کرده و IP lookup برای دقیق تر مشخص کردن شبکه انجام دهد تا بسته ارسال شود. در تصویر زیر محتوای LFIB را در یک روتر egress PE در شبکه MPLS VPN نمایش می دهد.Egress LSR یک بسته با label 23 دریافت می کند و باید label آنرا حذف کرده و براساس ادرس مقصد IP بسته برای آن IP lookup انجام دهد.

وب سایت توسینسو

حالا شما متوجه شدید که چگونه یک next-hop خاص را برای یک بسته label خورده تعیین کنید. جدول CEF adjacency نحوی کپسوله کردن در لایه data link را مشخص می کند. این جدول اطلاعات لازم برای ارسال بسته ها در لایه دوم برای LSR بعدی را فراهم می کند.در تصویر زیر این جدول در یک LSR نمایش داده می شود. این جدول اطلاعات لازم برای ارسال فریم ها را در خود نگه می دارد.

وب سایت توسینسو

خلاصه ای از عملیات هایی که روی label انجام می شود :

  • Pop : در اینجا label بالای label stack حذف می شود و بسته با label یا بدون آن به عنوان یک بسته IP ارسال می شود.
  • Swap : در اینجا label بالای label stack با یک label جدید جایگزین می شود.
  • Push : در اینجا label بالای label stack با یک label جدید جایگزین می شود و یک یا چند label به بالای label stack اضافه می شود.
  • Untagged/No Label : در اینجا label stack حذف شده و بسته بدون label ارسال می شود.
  • Aggregate : در اینجا label stack حذف شده و برای بسته IP lookup انجام می گیرد.

Load Balanced Labels

Load Balancing Labeled Packets : اگر برای یک شبکه IPv4 چند مسیر با هزینه یکسان وجود داشته باشد در IOS سیسکو این امکان وجود دارد که بسته های label خورده را بین این مسیرها تقسیم کنید یا به عبارتی Load Balancing را انجام دهید. در تصویر زیر خروجی LFIB یک روتر LSR را می بینید. همانطور که در تصویر می بینید برای بسته های ورودی با label 17 , 18 دو پورت خروجی وجود دارد. اگر بسته های label خورده load-balance شوند می توانند label خروجی یکسانی داشته باشند اما با یکدیگر متفاوت هستند.

اگر دو لینک بین یک جفت روتر و هر دو لینک به یک platform label space تعلق داشته باشند Label خروجی یکسان خواهد بود. اگر چندین next-hop LSR داشته باشیم معمولا label خروجی برای هر مسیر متفاوت خواهد بود چون هر next-hop LSR به صورت مستقل برای هر شبکه label در نظر می گیرد.

وب سایت توسینسو

اگر یک شبکه از طریق مجموعه ای از مسیرهای با مکانیزم label زنی و مسیر های بدون مکانیزم label زنی (IP) قابل دسترسی باشد در IOS سیسکو برای load-balancing مسیرهای بدون مکانیزم label زنی را در نظر نمی گیرد. چون ترافیک از طریق مسیر بدون مکانیزم label زنی به مقصد نخواهد رسید.

در شبکه های IPv4-over-MPLS اگر بسته در مقطعی از شبکه بدون label ارسال شود بسته به مقصد می رسد. در زمانی که بسته در لینکی که MPLS روی آن فعال نیست بدون label شود با توجه به اینکه در این شبکه IPv4 فعال است باید بتواند به مقصد برسد.

ولی در شبکه های MPLS VPN و AToM در صورتی که در شبکه MPLS ، بسته بدون label ارسال شود به مقصد نخواهد رسید.MPLS Payload در شبکه MPLS VPN یک بسته IPv4 است. اما P Router به صورت معمول روتینگ VPN را ندارند در نتیجه نمی توانند بسته را به مقصد برسانند.MPLS Payload در حالت AToM یک فریم لایه دو است. بنابراین اگر بسته ، label stack خود را در P Router از دست دهد ، P Router اطلاعات لازم برای ارسال این فریم لایه دو را ندارد.

این مواردی که عنوان شد دلایلی هستند که load-balancing در هر دو حالت label و بودن (label (IP استفاده نمی شود. به طور کلی نحوی ارسال و تصمیم گیری در روتر های Edge LSR یا همان PE Router انجام می گیرد درنتیجه در اکثر موارد P Router نمی توانند بسته های بدون label را ارسال کنند.

در تصویر زیر load balancing را توسط دو مسیر نمایش می دهد. سپس روی یکی از لینک های خروجی (Label Distribution Protocol (LDP غیرفعال می گردد و به عنوان next-hop از LFIB حذف می شود. از دستور no mpls ip برای غیرفعال کردن LDP در یک اینترفیس استفاده می شود.

وب سایت توسینسو

Unknown Label

در حالت نرمال LSR باید بسته های label خورده دریافت کند و label بالای label stack را بشناسد و چون قبلا توسط خود LSR این label ها به همسایه های خود اعلام شده است. به هر حال این امکان وجود دارد که در شبکه MPLS مشکلی بوجود آید و LSR بسته هایی را دریافت کند که label بالای label stack آنرا در LIFB پیدا نکند.

از نظر تئوری LSR در این مواقع می تواند دو کار انجام دهد: label بسته را حذف کرده و برای ارسال بسته تلاش کند یا اینکه بسته را drop کند. در سیسکو LSR ها بسته را drop می کنند این یک تصمیم درست است چون label بالای label stack توسط این LSR مشخص نشده است و این LSR نمی داند که پشت label چه نوع بسته ای قرار دارد.

این بسته می تواند یک بسته IPv4 ، IPv6 ، فریم لایه دو یا سایر موارد باشد. LSR می تواند با بررسی MPLS Payload تلاش کند که بفهمد بسته از چه نوعی است اما امکان به وجود آمدن مشکلات دیگر که در بخش قبلی آنها را شرح دادیم به وجود آید :

LSR اگر label بسته را حذف کند به احتمال زیاد قادر به ارسال بسته براساس مقصد آن نخواهد بود. حتی اگر LSR بسته را ارسال کند تضمینی وجود ندارد که این بسته توسط سایر روترها drop نشود. بهترین کار برای بسته های که دارای label ناشناخته هستند drop کردن آنهاست.

Reserved Labels

Label شماره 0 الی 15 به عنوان label های رزور شده شناخته می شوند و LSR نمی تواند از این label ها برای عملیات معمول خود استفاده کند. LSR برای هر یک از این label ها یک عملکرد خاص در نظر گرفته است. label 0 به عنوان explicit NULL label می باشد. Label 1 به عنوان router alert label استفاده می شود. Label 3 به عنوان implicit NULL label می باشد. Label 14 به عنوان OAM alert label استفاده می شود. سایر label های بین 0 تا 15 هنوز وظیفه ای برای آنها مشخص نشده است.

Implicit NULL Label

implicit NULL label با مقدار 3 مورد استفاده قرار می گیرد.یک egress LSR اگر نخواهد به یک FEC یک label اختصاص دهد از implicit NULL label برای آن FEC استفاده می کند در نتیجه از LSR های مجاور خود درخواست می کند که label بسته ها را pop کرده و به سمت او ارسال کنند.

در شبکه IPv4-over-MPLS ، در حالتی که LDP وظیفه پخش label ها را برعهده دارد egress LSR که IOS سیسکو را اجرا می کند implicit NULL label را برای شبکه های connected و summarized در نظر می گیرد. اگر egress LSR برای این FEC ها یک label در نظر بگیرد باعث می شود که بسته هایی دریافت کند که دارای یک label می باشند و برای این بسته ها باید دو lookup انجام دهد.

اولین lookup مربوط به label می شود که باید آنرا با LFIB مقایسه کند و متوجه شود که باید label حذف شود. دومین lookup مربوط به IP lookup می باشد. اگر دقت کنیم lookup اول لازم نیست انجام شود چون نتیجه حذف label است.

  • راه حل : egree LSR اخرین LSR یک LSP می باشد در اینجا egress LSR باید به LSR یکی مانده به آخر در LSP (همسایه egress LSR) اعلام کند که بسته ها را بدون label برای او ارسال کند. برای اینکار از implicit NULL label استفاده می کند تا LSR همسایه را متوجه این موضوع کند و این باعث می شود که egress LSR بسته های IP دریافت کرده و تنها نیاز به IP lookup برای ارسال بسته ها داشته باشد. این عمل باعث بهبود عملکرد در egress LSR می شود.استفاده از implicit NULL label در انتهای یک LSP را (penultimate hop popping (PHP می نامند. عمل pop در LFIB در روتر PHP در نظر گرفته می شود. نمونه آنرا در تصویر زیر می بینید.
وب سایت توسینسو
  • نکته : در IOS سیسکو PHP به صورت پیش فرض فعال است و در شبکه IPv4-over-MPLS شبکه های Connected و summarized را با implicit NULL label به سایر همسایه ها اعلام می کند.

استفاده از implicit NULL label بسیار گسترده است و تنها محدود به مثال بالا نمی باشد. اینکار برای یک بسته که دارای چند label است نیز استفاده می شود به این صورت که label بالای label stack حذف شده و بسته به صورت label خورده و با یک label کمتر ارسال می شود در نتیجه egress LSR نیاز به انجام دوبار label lookup ندارد. استفاده از implicit NULL label به این معنی نیست که تمام label ها در label stack باید حذف شوند بلکه فقط یک label حذف می شود.

در هر حالتی استفاده از implicit NULL label باعث می شود که egress LSR نیاز نداشته باشد که دوبار lookup انجام دهد. هر چند که مقدار 3 به عنوان label برای implicit NULL label مورد استفاده قرار می گیرد اما هرگز این مقدار به عنوان label در label stack مشاهده نمی شود و به این دلیل است که به آن implicit NULL label گفته می شود.منتظر قسمت های بعدی باشد. موفق ، پیروز و itpro باشید.

Explicit Null Label

Explicit NULL Label : استفاده از implicit NULL label باعث افزایش بهره وری در ارسال بسته ها می شود. در این حالت بسته توسط LSR یکی مانده به اخر در یک LSP با یک label کمتر ارسال می شود. در کنار این label ، اطلاعات فیلد EXP نیز نگه داری می شود. زمانی که label حذف شود.

فیلد EXP نیز به همراه آن حذف می شود. فیلد EXP برای مباحث (quality of service (QoS مورد استفاده قرار می گیرد و با حذف label این ویژگی همراه آن حذف می شود. در بعضی مواقع ما می خواهیم اطلاعات مربوط به QoS را داشته باشیم و همراه این اطلاعات بسته را تحویل egress LSR دهیم. در این حالت نمی توان از implicit NULL label استفاده کرد.

راه حل برای این مشکل استفاده explicit NULL label می باشد. در این روش egress LSR به همسایه های خود explicit NULL label را که دارای مقدار 0 است را اعلام می کند. سپس egress LSR بسته هایی با label 0 دریافت خواهد کرد. LSR با نگاه کردن به مقدار 0 و مقایسه آن با LFIB نمی تواند آنرا ارسال کند چون این مقدار می تواند به چند FEC اختصاص داده شده باشد.

درنتیجه اینجا LSR فقط explicit NULL label را حذف می کند. بعد از اینکه explicit NULL label توسط LSR حذف شد یک lookup دیگر انجام می دهد اما مزیت آن وجود اطلاعات QoS در بسته دریافتی برای روتر می باشد. از اطلاعات EXP می توان برای QoS استفاده کرد یا در صورت داشتن چند label اطلاعات EXP را به label جدید که در بالای label stack قرار گرفته اضافه کرد.

  • نکته : مقدار explicit NULL label برای IPv6 مقدار 2 است.

Router Alert Label

Router Alert label دارای مقدار 1 است. این label می تواند در هر جایی از label stack ، غیر پایین آن قرار بگیرد. در صورتی که این عدد در بالای lable stack باشد به LSR هشدار می دهد که این بسته نیاز به نگاه دقیق تر دارد. بنابراین این بسته مانند سایر بسته ها ارسال نمی شود و روی آن پردازش هایی انجام می گیرد.

زمانی که این بسته بخواهد ارسال شود label 1 آن حذف می شود. سپس label بعدی آن در lable stack با جدول LFIB مقایسه می شود تا نحوی ارسال مشخص گردد سپس عملیات مورد نظر مانند (pop , swap , push) روی آن انجام می گیرد و مجدد label 1 را در بالای label stack قرار می دهد.در تصویر زیر خروجی دستور debug mpls packet نمایش داده شده است که بسته دارای Router Alert label است :

وب سایت توسینسو

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

OAM Alert Label

Label با مقدار 14 به عنوان Operation and Maintenance (OAM) Alert label شناخته می شود. OAM برای تشخیص خطا و کنترل عملکرد مورد استفاده قرار می گیرد. بسته های OAM با بسته های نرمال کاربران تفاوت دارد. IOS سیسکو عملیات MPLS OAM را انجام می دهد اما از label 14 استفاده نمی کند.

Unreserved Labels

غیر از label های 0 الی 15 از تمام label برای ارسال بسته ها می توانید استفاده کنید. با توجه به 20 بیتی بودن فیلد شماره label مقداری که می توان به عنوان label برای ارسال بسته ها استفاده کرد از 16 تا 1,048,575 می باشد. به صورت پیش فرض در IOS سیسکو از 16 تا 100000 به عنوان label استفاده می شود و این مقدار نیاز شما را برای شبکه های IGP تامین خواهد کرد. اما برای شبکه های BGP این مقدار قابل توجهی نیست و می توانید با دستور mpls label range min max این مقدار را تغییر دهید.در تصویر زیر این تغییرات توسط دستور mpls label range نمایش داده شده است:

وب سایت توسینسو

TTL در بسته های Label خورده

در هدر IP فیلد 8 بیتی با نام (Time To Live (TTL وجود دارد و با استفاده از آن طول عمر مجاز بسته در شبکه مشخص می شود. زمانی که یک بسته ارسال می شود به طور معمول مقدار این فیلد 255 می باشد و به ازای عبور از هر hop در شبکه این یک واحد از این مقدار کم می شود و اگر مقدار به صفر برسد بسته drop می شود.

در این صورت روتری که بسته با TTL 0 را drop کند یک پیام (Internet Control Message Protocol (ICMP با کد 0 و type 11 به مبدا بسته ارسال می کند. با معرفی MPLS ، به هدر بسته ها label اضافه شد. در اینجا مقدار TTL هدر IP در label stack کپی می شود تا مطمئن شویم که بسته برای همیشه در شبکه MPLS قرار نگیرد و طول عمر برای آن وجود داشته باشد.

  • نکته : در هنگامی که بسته بدون label می شود و یا از شبکه MPLS خارج می شود. مقدار TTL از label stack به هدر IP کپی می شود.

رفتار TTL در بسته های label خورده

در MPLS ، استفاده از فیلد TTL مشابه فیلد TTL در هدر IP است. زمانی که یک بسته IP وارد شبکه MPLS می شود مانند ingress LSR که به عنوان ورودی به شبکه MPLS محسوب می شود مقدار TTLدر هدر IP بعد از کسر یک واحد به عنوان MPLS TTL برای آن بسته در نظر گرفته می شود.

Label در egress LSR حذف می شود و هدر IP مجدد مورد استفاده قرار می گیرد در اینجا نیز مقدار MPLS TTL بسته بعد از کسر یک واحد در فیلد TTL در هدر IP کپی می شود. در IOS سیسکو ، برای حفاظت از routing loop احتمالی مقدار TTL هدر IP را با MPLS TTL مقایسه می کند و اگر مقدار MPLS TTL از TTL هدر IP بزرگتر بود آنرا کپی نمی کند.در تصویر زیر نحوی تغییرات TTL در شبکه MPLS نمایش داده شده است :

وب سایت توسینسو

رفتار TTL در Label-to-Label

اگر عمل swap برای یک بسته label خورده در LSR در نظر گرفته شود مقدار TTL یک واحد کم شده و مقدار آن در label جدید قرار می گیرد. اگر یک یا چند label به یک بسته push شود از مقدار TTL یک واحد کم شده و مقدار آن برای label که جایگزین شده و label های جدید در نظر گرفته می شود.

اگر یک label را pop کنیم از TTL آن یک واحد کم شده و مقدار آن در label که بالای label stack قرار می گردید کپی می شود مگر اینکه مقدار TTL از TTL این label بزرگتر باشد که در این حالت کپی انجام نمی شود.در تصویر زیر تغییر TTL را در عملیات های pop ، push و swap نشان داده شده است :

وب سایت توسینسو
  • نکته : intermediate LSR یا همان LSR های میانی تنها مقدار TTL را در label بالای label stack تغییر می دهند و نمی توانند TTL هدر IP یا TTL مربوط به label های پایین label stack را تغییر دهند.
  • نکته : رفتار و عملکرد TTL را که در اینجا توضیح داده شد در IOS سیسکو TTL operation نامیده می شود.

TTL Expiration و MTU

TTL Expiration : زمانی که یک بسته label خورده با TTL 1 دست LSR می رسد LSR آنرا drop می کند و یک بسته ICMP با پیام time exceede به مبدا بسته ارسال می کند. رفتار نسبت به بسته label خورده که TTL آن صفر شده با رفتار نسبت به یک بسته IP که TTL آن صفر شده است یکسان است.

هرچند که پیام ICMP بلافاصله به مبدا بسته ارسال نمی شود چون این امکان وجود دارد که LSR مسیر رسیدن به آدرس مبدا بسته IP را نداند. در نتیجه پیام ICMP را براساس LSP که بسته را روی آن دریافت کرده است ارسال می کند.در تصویر زیر نحوی ارسال پیام ICMP به آدرس میدا بسته IP در یک شبکه IP نمایش داده شده است.

وب سایت توسینسو

در تصویر زیر نحوی ارسال پیام ICMP را براساس LSP به سمت مبدا بسته نمایش داده شده است.

وب سایت توسینسو

دلیل ارسال پیام ICMP براساس LSP مربوط به بسته که TTL آن منقضی شده است این است که LSR نمی داند چگونه پیام ICMP را به مبدا بسته برساند. یک نمونه آن در شبکه MPLS VPN ، روترهای P اطلاعی از اینکه پیام ICMP را چگونه به مبدا بسته ارسال کنند ندارد چون هیچ مسیری برای ارسال پیام ICMP به مبدا بسته ندارد.

(به طور معمولا روترهای P مسیرهای VPN را در خود نگه داری نمی کنند) از این رو P Router پیام ICMP براساس LSP بسته ارسال می کند. زمانی که این پیام به انتهای LSP برسد می تواند به سمت مبدا بسته برگشت داده شود. در شبکه های MPLS VPN پیام ICMP توسط egress PE یا CE که به PE متصل است برگشت داده می شود چون این روترها مسیر درست به مبدا بسته را دارند.

در P Router جایی که TTL بسته منقضی می شود ضروری است که بداند که MPLS payload چیست. payload بسته توسط P Router چک می شود که بسته IPv4 یا IPv6 هست یا خیر . اگر بسته IPv4 یا IPv6 باشد پیام ICMP را برای آن ایجاد می کند و براساس LSP آنرا ارسال می کند.

اما اگر payload بسته IPv4 یا IPv6 نبود P Router نمی تواند بسته ICMP برای آن ایجاد کند. بنابراین در همه حالت ها P router بسته را drop می کند و پیام ICMP تولید نمی کند غیر از حالت IPv4 یا IPv6. حالتی که LSR بسته با TTL منقضی را فقط drop می کند AToM است.

MPLS payload در AToM یک فریم لایه دو است نه یک بسته IP ، از این رو اگر TTL یک بسته AToM در یک P Router منقضی شود تنها کاری که P Router می تواند نسبت به آن انجام دهد drop کردن آن است چون نمی تواند برای آن IP lookup انجام دهد. همچنین تنها در صورتی که P Router از نسخه های جدید IOS سیسکو (IOS که از IPv6 پستیبانی کند) استفاده کنند می توانند ICMP IPv6 تولید کنند و به مبدا بسته آنرا برگشت دهند در غیر اینصورت بسته را drop می کند.

MPLS MTU

با (Maximum transmission unit (MTU به عنوان یک پارامتر در دنیای IP آشنا هستید. MTU حداکثر سایز یک بسته IP را که امکان ارسال آن بدون تکه تکه کردن وجود دارد را مشخص می کند. در شبکه MPLS نیز یک MTU مشخص برای بسته های label خورده وجود دارد.

در یک شبکه MPLS که روی یک شبکه IPv4 اجرا شده است هر بسته IPv4 یک یا چند label دارد که باعث می شود که بسته های label خورده از بسته های IP کمی بزرگتر باشند. چون برای هر label ، 4 بایت به بسته اضافه می شود بنابراین اگر n تعداد label ها باشد مقدار n*4 به سایز بسته زمانی که label می خورد اضافه می شود.

دستور MTU در اینترفیس مشخص می کند که یک بسته می تواند حداکثر چه سایزی داشته باشد و بدون تکه تکه کردن بتواند در data link ارسال شود. در Ethernet به صورت پیش فرض مقدار MTU برابر 1500 است. به هر حال زمانی که label به تعداد n به بسته اضافه می شود و سایز بسته به مقدار n*4 بایت افزایش پیدا می کند و باعث می شود که اندازه بسته از مقدار MTU مشخص شده بیشتر شود و بسته نیاز به تکه تکه شدن داشته باشد.

در IOS سیسکو با استفاده از دستور mpls mtu در اینترفیس مورد نظر خود می توانیم حداکثر اندازه بسته label خورده را مشخص کنیم. به طور مثال اگر بدانیم که بسته در هنگام ارسال در شبکه MPLS حداکثر دو عدد label خواهد داشت می توانیم با دستور بالا مقدار mtu را 1508 مشخص کنیم. در نتیجه همه بسته ها با حداکثر دو label می توانند بودن نیاز به تکه تکه شدن ارسال شوند. مقدار پیش فرض MPLS MTU با MTU اینترفیس برابر است.در تصویر زیر نحوی تغییر MTU نمایش داده شده است:

وب سایت توسینسو

زمانی که بسته label می خورد به همان نسبت حجم آن افزایش پیدا می کند. اگر بسته IP از حداکثر میزان MTU استفاده کرده باشد در زمان ارسال با توجه به اینکه به بسته label می خورد حجم بسته کمی افزایش پیدا می کند. در نتیجه فریم لایه دو به یک فریم بزرگ تر تبدیل می شود و نیاز به تکه شدن دارد. به این فریم ها Baby Giant Frames گفته می شود.

به طور مثال در Ethernet : بسته می تواند که حداکثر 1500 بایت باشد و اگر بسته از کل 1500 بایت استفاده کرده باشد و label به آن اضافه شود. بسته برای ارسال کمی بزرگ می باشد. این امکان وجود دارد این چند بایت نادیده گرفته شود و بسته ارسال شود با اینکه اینکار با مشخصات Ethernet مطابقت ندارد و این بسته ها باید drop شوند. این کار تنها در صورتی امکان پذیر است که کلیه روترها و سوئیچ های در شبکه Ethernet امکان ارسال و دریافت بسته هایی با چند بایت بیشتر از حداکثر ظرفیت را MTU داشته باشند.

در Ethernet در LSR شما می توانید که MPLS MTU را برابر 1508 بایت قرار دهید که به شما اجازه می دهد بسته IP با سایز 1500 و حداکثر دو label داشته باشید. در این حالت اگر روتر این سایز از بسته را پشتیبانی نکند و یا یک سوئیچ در بین راه وجود داشته باشد بسته drop خواهد شد. در اینصورت با کم کردن MTU به 1492 قادر به ارسال بسته خواهید بود.

  • نکته : در برخی از نسخه های سیسکو شما نمی توانید MPLS MTU را از MTU اینترفیس بزرگتر در نظر بگیرد.

در سوئیچ می توان تغییراتی در MTU اعمال کرد که بتواند فریم های بزرگتر را حمل کند. در تصویر زیر نحوی فعال سازی jumbo Ethernet frames نمایش داده شده است.

وب سایت توسینسو

MPLS Maximum Recieve 

MPLS Maximum Receive چیست؟ (Maximum receive unit (MRU پارامتری است که توسط IOS سیسکو مورد استفاده قرار می گیرد و برای LSR مشخص می کند که بسته های label خورده مربوط به یک FEC با چه سایزی می توانند توسط LSR دریافت شوند و بتوانند بدون تکه تکه شدن ارسال شوند.این مقدار برای هر FEC یا شبکه مشخص می شود و فقط براساس اینترفیس نمی باشد و دلیل آن labelهایی است که در LSR به بسته اضافه یا حذف می شوند.

به عنوان مثال یک روتر را که MTU همه اینترفیس های آن برابر 1500 است را در نظر بگیرد. که به این معناست بزرگترین بسته ای که می تواند روی یک اینترفیس ارسال و دریافت شود 1500 بایت می باشد و با فرض اینکه بسته حداکثر می تواند دو label داشته باشد در نتیجه MPLS MTU بسته 1508 می شود

که در کلیه اینترفیس ها این مقدار یکسان می باشد. و بسته های label خورده با سایز 1508 بایت می توانند روی همه لینک ها ارسال شوند. اگر عمل pop برای بسته دریافتی در نظر گرفته شده باشد بسته باید 4 بایت یا یک label بزرگتر باشد(1512 بایت) چون بسته قبل از ارسال باید یک label آن حذف شود

اگر عمل push برای بسته در نظر گرفته شده باشد و یک label به بسته اضافه خواهد شد بسته دریافتی باید 1504 بایت باشد تا با اضافه شدن label اندازه آن 1508 بایت شود.همین طور که دیدید عملیات روی label ها در تعیین MRU نقش دارند.

چون عملیات روی label ها براساس FEC یا شبکه مشخص می شود MRU نیز براساس FEC یا شبکه مشخص می شود. به تصویر زیر توجه کنید که در آن MRU براساس شبکه و نسبت به عملی که روی بسته می خواهد انجام شود تغییر می کند. مقدار MRU را به ازای هر شبکه در تصویر زیر می بینید.

وب سایت توسینسو

MRU برای شبکه 10.200.254.2/32 برابر 1512 می باشد. بسته دریافتی می تواند 1512 بایت باشد چون بسته قبل از ارسال pop خواهد شد. MRU برای شبکه 10.200.254.3 برابر 1508 می باشد و اندازه بسته تغییر نخواهد کرد چون عمل swap روی بسته انجام می شود. MRU برای شبکه 10.200.254.4 برابر 1504 می باشد چون بسته دریافتی 1504 بایت خواهد بود و یک label به آن push خواهد شد و اندازه بسته 4 بایت افزایش خواهد یافت.

Fragmentation of MPLS Packets

اگر LSR یک بسته label خورده دریافت کند که اندازه آن برای ارسال در data link بزرگ باشد بسته باید تکه تکه شود. این تکه کردن مشابه بسته های IP است. اگر یک بسته label خورده دست LSR برسد و LSR متوجه شود که این بسته نسبت به MTU آن بزرگ است باید آنرا تکه تکه کند که در ابتدا label stack را از روی بسته بر می دارد بسته IP را تکه تکه می کند بعد از اینکه روی label stack عمل مورد نیاز(pop , push , swap) را انجام داد. این label stack را به تمام تکه ها اضافه می کند و این تکه ها را ارسال می کند.

تنها در صورتی که فیلد (Don’t Fragment (DF در هدر IP استفاده شده باشد LSR آنرا تکه نخواهد کرد و بسته را Drop کرده و یک پیام ICMP error با محتوای اینکه بسته نیاز به تکه تکه شدن دارد و از فیلد (Don’t Fragment (DF استفاده نشود (ICMP type 3, code 4) به مبدا بسته ارسال می کند.

همانند پیام (ICMP message “time exceeded” (type 11, code 0 که در زمان انقضای TTL تولید و براساس LSP ارسال میشد این پیام نیز براساس LSP ارسال می شود تا به مبدا خود برسد.در طور معمول تکه تکه کردن یا fragmentation روی کارایی اثر منفی می گذارد و باید از آن اجتناب کرد. یک روش برای اجتناب از تکه تکه کردن استفاده از Path MTU Discover است که در ادامه آنرا شرح می دهیم.

Path MTU Discovery

یک روش برای اجتناب از fragmentation استفاده از Path MTU Discovery می باشد. در این روش فیلد (Don’t Fragment (DF در بسته های IP مورد استفاده قرار می گیرد و بسته ها ارسال می شود. زمانی که بسته به یک روتر برسد که آن روتر بسته را بدون fragmentation نتواند ارسال کند روتر بسته را drop می کند و یک پیام (ICMP error message Fragmentation needed and do not fragment bit set (ICMP type 3, code 4 به فرستنده بسته مبنی بر عدم استفاده از فیلد DF ارسال می کند.

فرستنده بسته IP اینبار بسته را با سایز کوچکتری ارسال می کند و اگر دوباره این مشکل بوجود آمد مجدد سایز بسته را کم کرده و آنرا ارسال می کند. اینکار تا زمانی که مبدا ، پیام ICMP error دریافت نکند ادامه می یابد. اندازه اخرین بسته که با موفقیت ارسال شده است به عنوان اندازه بسته در نظر گرفته می شود و از آن برای ارسال بسته ها بین این مبدا و مقصد استفاده می شود. از این رو به آن MTU مسیر گفته می شود.

  • نکته : تضمینی برای اینکه Path MTU Discovery در همه شرایط کار کند وجود ندارد. در بعضی مواقع پیام های ICMP error به مبدا بسته برگشت داده نمی شوند. نرسیدن پیام های ICMP error به مبدا بسته می تواند علل مختلف داشته باشد که می توان به وجود فایروال ، استفاده از Access Control List و یا مشکلات مسیریابی اشاره کرد.منتظر قسمت های بعدی باشد. موفق ، پیروز و itpro باشید.

LDP چیست؟

Label Distribution Protocol  چیست؟ داستان کلی MPLS به بسته های label خورده که توسط (label switching router (LSR ارسال می شوند برمی گردد و به این معناست که در همه حالت ها ، label ها باید پخش و توزیع شوند. که می توان به دو روش اینکار را انجام داد :

سوارکردن label ها روی پروتکل مسیریابی موجود یا استفاده از یک پروتکل جدید برای توزیع label . اگر بخواهید (Interior Gateway Protocol (IGP مانند OSPF ، ISIS یا EIGRP را برای حمل label ها تنظیم کنید باید اینکار را برای همه پروتکل های مسیریابی انجام دهید چون همه این پروتکل ها در شبکه های امروزی مورد استفاده قرار می گیرند.

اگر از ابتدا یک پروتکل جدید بنویسید باید بتواند به صورت مستقل مسیریابی کند و همچنین بتواند با IGP کار کند. دلیل اصلی به وجود آمدن (Label Distribution Protocol (LDP حمل label ها مربوط (Forwarding Equivalence Classes (FECs در شبکه MPLS می باشد.به عنوان یک استثناء پروتکل مسیریابی (Border Gateway Protocol (BGP می تواند label ها را برای ما حمل کند چون BGP مسیرهای خارجی را حمل می کند و استفاده از آن برای حمل labelها کارامدتر است.

دلیل دیگر انتخاب BGP برای حمل label ها این است که BGP تنها پروتکلی است که می تواند مسیرها را بین (autonomous systems (AS حمل کند که باعث می شود به عنوان یک پروتکل مورد اعتماد بین کمپانی های مختلف مورد استفاده قرار گیرد.

این مواردی که عنوان شد دلایلی هستند که در IOS سیسکو از LDP برای پخش label های مربوط به شبکه های IGP استفاده می شود از پروتکل BGP برای پخش label های مربوط به شبکه های BGP استفاده می شود. در بخش های قبلی به صورت خلاصه به LDP و نحوی تبادل label ها پرداختیم و همچنین دلایل نیاز به (label information base (LIB و (label forwarding information base (LFIB و نحوی ایجاد آنها گفته شد.

برخی از اصول مانند عملیات روی label نیز شرح داده شد. اما لازم است که عملیات LDP به صورت دقیق تر و عمیق تر مورد بررسی قرار گیرد.به تصویر زیر توجه کنید این شبکه در این بخش مورد استفاده قرار می گیرد :

وب سایت توسینسو

LDP Overview

برای دریافت بسته ها در همه (label switched path (LSP ها در شبکه MPLS باید همه LSR ها LDP را اجرا کنند و label ها را مبادله کنند. زمانی که همه LSR ها برای همه FEC ها label داشته باشند بسته ها می توانند در LSP ها به وسیله label switching توسط هر LSR ارسال شوند.

عملیات روی label ها مانند swap ، push و pop نیز با استفاده از LFIB مشخص می شود. LFIB اطلاعات برای ارسال بسته ها را از LIB بدست می آورد و LIB اطلاعات و label ها را از طریق LDP ، Resource Reservation Protocol (RSVP) ، MP-BGP یا از طریق label هایی که به صورت static مشخص شده اند بدست می آورد.

با توجه به اینکه از RSVP برای پخش label های در MPLS TE استفاده می شود و همچنین MP-BGP برای پخش label های مربوط به شبکه های BGP مورد استفاده قرار می گیرد در نتیجه برای شبکه های داخلی (IGP Route) باید از LDP برای پخش label ها استفاده کنید.

بنابراین LSR هایی که به صورت مستقیم به هم متصل هستند باید رابطه همسایگی LDP با یکدیگر برقرار کنند و با استفاده از این رابطه همسایگی بسته های LDP را بین یکدیگر منتقل می کنند. label mapping یا label binding اختصاص label برای یک FEC می باشد. FEC مجموعه ای از بسته ها است که به یک LSP مشخص تعلق دارند و روی این LSP در شبکه MPLS ارسال می شود. در این بخش می خواهیم به label bindings برای شبکه های IGP پردازیم. LDP دارای چهار بخش اصلی است :

  • پیدا کردن LSR هایی که LDP را اجرا کرده اند.
  • برای ارتباط و نگه داری از آن
  • ارسال label mappings
  • نگه داری از اطلاعات

زمانی که دو LSR که LDP را اجرا کرده اند و بین آنها یک یا چند لینک وجود دارد برای پیدا کردن یکدیگر از مفهوم بسته های Hello استفاده می کنند. مرحله دوم برای آنها برقراری یک ارتباط TCP بین آنهاست. در این ارتباط TCP ، بسته های label mapping توسط LDP بین این LSR ها ارسال می شوند.

این بسته های label mapping برای جمع آوری و تغییر label binding مورد استفاده قرار می گیرد. LDP ها می توانند به وسیله ارسال و اعلام برخی بسته های خطا به همسایه های خود هشدار دهد.با توجه به اهمیت پروتکل LDP در بخش بعدی مقاله چهار بخش اصلی LDP که در اینجا مطرح را به صورت دقیق و عمیق مورد بررسی قرار می دهیم تا با عملکرد این پروتکل بیشتر آشنا شویم. موفق ، پیروز و itpro باشید.

معرفی اجزای اصلی LDP

LDP چگونه کار می کند؟در این بخش به بررسی چهار بخش اصلی LDP که در بخش قبلی مقاله عنوان شد می پردازیم.

  • پیدا کردن LSR هایی که LDP را اجرا کرده اند

LSR هایی که LDP را اجرا کرده اند روی همه لینک هایی که LDP روی آنها فعال شده است بسته های LDP Hello ارسال می کنند و این لینک هایی است که روی آنها MPLS با استفاده از دستور mpls ip در آن اینترفیس تنظیم شده است. اما در ابتدا باید CEF با استفاده از دستور ip cef در global mode فعال شده باشد سپس LDP به صورت globally با استفاده از دستور mpls ip فعال شود. در تصویر زیر دستورات فعال کردن LDP نمایش داده شده است :

وب سایت توسینسو

LDP Hello بسته های UDP می باشند که روی لینک ها برای همه روترهای آن subnet به صورت Multicast ارسال می شوند و از آدرس 224.0.0.2 به عنوان آدرس multicast استفاده می کند و همچنین از پورت UDP 646 استفاده می کند. LSR که بسته LDP Hello را روی یک پورت خود دریافت کند متوجه می شود که از طریق این پورت به یک روتر که LDP را اجرا کرده است می رسد. بسته های Hello حاوی Hold time هستند و اگر قبل از انقضای زمان Hold time ، بسته hello از آن LSR دریافت نکند LSR را از جدول همسایه های LDP خود حذف می کند.

برای اینکه مشاهده کنید که LSR بسته های LDP Hello ارسال یا دریافت کرده اند و همچنین مشاهده Hello interval و Hold time می توانید از دستور show mpls ldp discovery [detail] استفاده کنید. اگر روی یک اینترفیس ارسال و دریافت بسته های LDP Hello رخ دهد نشان دهنده ایجاد همسایگی بین دو LSR که LDP را اجرا کرده اند می باشد. در تصویر زیر خروجی دستور فوق نمایش داده شده است :

وب سایت توسینسو

با استفاده از دستور show mpls interfaces می توانید خیلی سریع اینترفیس هایی که روی آنها LDP اجرا شده است را ببینید. خروجی این دستور به صورت زیر است :

وب سایت توسینسو

برای تغییر زمان بین ارسال بسته های Hello و یا تغییر زمان Hold time از دستور mpls ldp discovery {hello {holdtime | interval} می توانید استفاده کنید.مقدار پیش فرض برای hold time برابر 15 ثانیه می باشد و هر 5 ثانیه یکبار بسته hello ارسال می شود.

در تصویر بالا سه همسایه LDP شناسایی شده اند که دارای IP های 10.200.254.1 ، 10.200.254.3 و 10.200.254.5 می باشند. همانطور که می بینید LSR 10.200.254.1 از طریق دو اینترفیس Ethernet 0-1-3 و Ethernet 0-1-4 شناسایی شده است و مقدار پیش فرض برای Hello interval و Hold time یعنی 5 و 15 ثانیه تعیین شده است.

اگر دو همسایه LDP دارای مقدار Hold times متفاوت باشند مقدار کمتر به Hold times در نظر گرفته می شود. IOS سیسکو مقدار Hello interval را تغییر می دهد تا بتواند حداقل سه بسته LDP Hello قبل از انقضای زمان Hold time ارسال کند. اگر زمان Hold time برای یک لینک منقضی شود آن لینک از لیست LDP حذف می شود. اگر اخرین لینک مربوط به همسایه LDP حذف شود ارتباط همسایگی بین آن LSR های نیز خاتمه می یابد.

در صورتی که مقدار Hello interval و Hold times را برای LDP تغییر دادید مطمئن شوید که مقدار در نظر گرفته شده خیلی بزرگ یا کوچک نباشد. اگر مقدار Hold time خیلی کوچک در نظر گرفته شود باعث می شود که در زمانی که تعداد کمی از بسته ها به دلایل مختلف (مانند حجم بالایی ترافیک) از بین برود این رابطه همسایگی نیز از بین برود.

اگر مقدار Hold time خیلی نیاز در نظر گرفته شود ممکن است که رابطه همسایگی برای یک مدت طولانی برقرار باشد در صورتی که یک مشغول جدی در ارتباط وجود داشته باشد و عکس العمل نسبت به آن دیر انجام شود و نتیجه آن از دست رفتن حجم زیادی از بسته می باشد.

توجه داشته باشید که هر LSR که LDP را اجرا کرده است دارای یک شناسه یا LDP ID می باشد. این LDP ID یک فیلد 6 بایتی است که 4 بایت آن مشخص کننده شناسه منحصر به فرد LSR می باشد و 2 بایت آن مشخص کننده label space می باشد که اگر این دو بایت برابر صفر باشد نشان دهنده perplatform label space بودن آن می باشد و اگر مقدار آن چیزی غیر از صفر باشد نشان دهنده per-interface label space می باشد. در برخی از حالت ها می توان از چند LDP ID استفاده کرد.

که در این LDP ID ها مقدار چهار بایت اول برابر می باشد اما مقدار دو بایت دیگر متفاوت می باشد. به طور مثال per-interface label space را در نظر بگیرد. مقدار 4 بایت اول LDP ID یک آدرس IP است که از روی یکی از اینترفیس های روتر گرفته شده است.

اگر اینترفیس loopback وجود داشته باشد بزرگترین IP متعلق به اینترفیس loopback برای 4 بایت اول LDP ID در نظر گرفته می شود. اگر اینترفیس loopback وجود نداشته باشد بزرگترین IP اینترفیس ها برای این 4 بایت LDP ID در نظر گرفته می شود.

در تصویر بالا مقدار LDP ID برابر 10.200.254.2:0 می باشد که 10.200.254.2 نشان دهنده بزرگترین IP و 0 نشان دهنده perplatform label space می باشد. شما می توانید مقدار LDP ID را با استفاده از دستور mpls ldp router-id interface [force] تغییر دهید.

در صورت استفاده از کلید force مقدار LDP ID بلافاصله تغییر می کند در غیر این صورت مقدار LDP ID در زمانی بعد که نیاز به تعیین LDP ID باشد براساس این دستور تعیین می گردد و آن زمانی است که اینترفیسی که در حال حاضر به عنوان LDP ID استفاده می شود shutdown شود.

در IOS سیسکو ، LDP ID باید در جدول مسیریابی همسایه LDP وجود داشته باشد در غیر این صورت ارتباط LDP و همسایگی آن ایجاد نمی گردد. بنابراین آدرس IP که به عنوان LDP ID مورد استفاده قرار می گیرد باید در جدول مسیریابی وجود داشته باشد.

اگر برای این آدرس IP در جدول مسیریابی هیچ مسیری وجود نداشته باشد ارتباط و همسایگی LDP برقرار نمی شود. در تصویر زیر آدرس 10.200.254.3 در جدول مسیریابی LSR لندن وجود ندارد. در نتیجه بین LSR لندن و LSR روم هیچ ارتباط و همسایگی LDP برقرار نمی شود و این به خاطر LDP ID با مقدار 10.200.254.3 می باشد.

وب سایت توسینسو

نحوه ارتباط با LDP

برقراری ارتباط LDP و نگه داری از آن : اگر دو LSR یکدیگر را با استفاده از LDP Hello پیدا کردند آنها برای برقراری یک ارتباط LDP بین یکدیگر تلاش می کنند. یکی از LSR ها سعی می کند که یک ارتباط TCP با شماره پورت 646 با LSR دیگر ایجادکند. اگر این ارتباط TCP برقرار شود ، هر دو LSR با استفاده تبادل پیام های LDP بر سر پارامترهای ارتباط LDP مذاکره می کنند. این پارامترها به شرح زیر هستند :

  • Timer values
  • Label distribution method
  • (Virtual path identifier (VPI)/virtual channel identifier (VCI) ranges for Label Controlled ATM (LC-ATM
  • Data-link connection identifier (DLCI) ranges for LC-Frame Relay

اگر هر دو LDP پارامترهای ارتباط را قبول کنند ، آنها این ارتباط TCP را بین خود نگه می دارند. اگر این توافق انجام نگیرد بعد از یک توقف ، مجدد برای برقراری ارتباط مذاکره می کنند. در IOS سیسکو ، با استفاده از دستور LDP backoff این توقف را کنترل می کند.

Mpls ldp backoff initial-backoff maximum-backoff 

پارامتر initial-backoff می تواند مقدار 5 تا 2,147,483 بگیرد و به صورت پیش فرض مقدار آن 15 ثانیه است. پارامتر maximum-backoff می تواند مقدار 5 تا 2,147,483 بگیرد و به صورت پیش فرض مقدار آن 120 ثانیه است. این دستور باعث می شود زمانی که دو همسایه LDP بین آنها توافق انجام نشود سرعت تلاش برای برقراری ارتباط مجدد را کاهش می دهد.

اگر تلاش برای برقراری ارتباط با شکست مواجه شود اقدام بعدی برای برقراری ارتباط بعد از یک بازه زمانی انجام می گیرد و این کار تا زمانی که به زمان maximum backoff برسد ادامه پیدا می کند. یک مثال ، در LC-ATM یک جفت LDP بر سر پارامترها با هم توافق نمی کنند و ارتباط LDP برقرار نمی شود. جایی که مقادیر متفاوتی برای VPI/VCI استفاده شده است.

بعد از اینکه ارتباط LDP برقرار شد به وسیله بسته های LDP یا بسته های Keepalive از این ارتباط نگه داری می کنند. هر وقت که LDP یک بسته LDP یا بسته Keepalive دریافت کند تایمر keepalive مربوط به آن LDP را reset می کند. تایمر keepalive یا همان Hold time برای نگه داری ارتباط LDP را می توان تنظیم کرد. که برای اینکار از دستور mpls ldp holdtime استفاده می کنیم.

مقداری که برای Hold time می توان در نظر گرفت بین 15 تا 2,147,483 می باشد که مقدار پیش فرض آن 180 ثانیه می باشد. تصویر زیر یک ارتباط LDP را با LDP ID 10.200.254.2 نشان می دهد. پورت لوکال TCP 646 می باشد و پورت ریموت TCP 11537 می باشد. تایمر Hold time برابر 180 ثانیه می باشد و بسته های Keepalive در بازه های 60 ثانیه ای ارسال می شوند.

وب سایت توسینسو

همچنین با دستور show mpls ldp parameters تایمر های ارتباط (Session) و شناسایی همسایه (Discovery) را می توانید ببینید.

وب سایت توسینسو

ارتباط LDP از نوع TCP می باشد که بین دو آدرس IP از LSR ها برقرار می شود. معمولا این آدرس های IP برای ساخت LDP ID مورد استفاده قرار می گیرد. اما اگر شما بخواهید از این آدرس های IP برای برقرای ارتباط LDP استفاده نکنید می توانید آنرا تغییر دهید.

برای تغییر این آدرس IP از دستور {mpls ldp discovery transport-address {interface | ipaddress در اینترفیس مورد نظر برای برقراری ارتباط LDP استفاده می شود. این transport IP Address با استفاده از بسته LDP Hello روی اینترفیس هایی که LDP روی آن فعال است انتشار پیدا می کند.

  • نکته : زمانی که روتر به یک روتر LDP دیگر از طریق چند لینک متصل است باید روی همه این لینک هاtransport address یکسان تعیین شود.

در تصویر زیر دو روتر از طریق دو لینک Ethernet به یکدیگر متصل شده اند. در روتر نیویورک transport address به آدرس loopback 1000 تغییر داده شده است.

وب سایت توسینسو

به تصویر زیر توجه کنید آدرسی که برای ارتباط TCP استفاده می شود از LDP ID موجود به آدرس 10.200.255.1 که مربوط به loopback 1000 تغییر داده شده است.

وب سایت توسینسو

نکته : زمانی که یک روتر با یک روتر LDP دیگر از طریق چند لینک ارتباط دارد و دارای transport address های متفاوتی روی این لینک ها هستند بازهم ارتباط TCP برقرار می شود اما در این حالت یک لینک در روتر دیگراز دست خواهد رفت. در مثال قبل ارتباط LDP برقرار خواهد شد اما در خروجی روتر لندن یکی از لینک های Ethernet 0-1-3 یا Ethernet 0-1-4 از بین خواهد رفت و آنرا نخواهیم دید.

همچنین روی ترافیک ارسالی از روتر لندن به روتر نیویورک load-balancing انجام نخواهد شود و تنها از یکی از این لینک ها استفاده خواهد شد. که باعث می شود از تمام توان شبکه استفاده نشود.

تعداد Session های LDP

تعداد LDP Sessions : شاید شما فکر کنید که یک ارتباط LDP برای یک جفت LSR برای اینکه کار خود را انجام دهند کافی است. در اکثر موارد حق با شما است زمانی که per-platform label space به عنوان تنها label space بین یک جفت LSR مورد استفاده قرار می گیرد یک ارتباط LDP کافی است.

به این دلیل است که تنها یک مجموعه از Label binding بین دو LSR مبادله می شود و مهم نیست چندتا لینک بین آنها وجود دارد. اساسا ، زمانیکه از per-platform label space استفاده می شود اینترفیس ها می توانند یک مجموعه یکسان از label ها را به اشتراک بگذارند و دلیل آن این است که همه label binding مربوط به تمام لینک های بین این دو LSR است

چون آنها به label space یکسان تعلق دارند زمانی اینترفیس ها به per-platform label space تعلق دارند که اینترفیس در حالت frame mode قرار دارد. اینترفیس هایی که در حالت frame mode قرار ندارند مانند اینترفیس های LC-ATM ، دارای per-interface label space هستند.

در per-interface label space هر label binding تنها به آن اینترفیس ارتباط دارد. بنابراین برای هر اینترفیس که دارای per-interface label space است یک ارتباط LDP بین یک جفت LSR نیاز است. به تصویر زیر توجه کنید در این تصویر تعداد ارتباط های LDP بین یک جفت LSR نمایش داده شده است.

وب سایت توسینسو

برای همه لینک های frame mode تنها یک ارتباط LDP نیاز است که label ها را در per-platform label space مبادله کند. برای هر لینک LC-ATM یک ارتباط LDP برای تبادل label ها در per-interface label space نیاز است. در بخش 1 تصویر بالا شما سه لینک frame بین دو LSR می بینید که تنها به یک ارتباط LDP بین دو LSR نیاز است.

در بخش 2 تصویر بالا شما یک لینک frame و یک لینک LC-ATM بین دو LSR می بینید چون لینک LC-ATM ارتباط LDP خاص خودش را نیاز دارد درنتیجه به دو ارتباط LDP نیاز است. در بخش 3 تصویر بالا سه لینک LC-ATM وجود دارد بنابراین تعداد ارتباط های LDP مورد نیاز سه می باشد. در بخش 4 تصویر بالا دو لینک frame و سه لینک LC-ATM وجود دارد که برای دو لینک frame یک ارتباط LDP و برای سه لینک LC-ATM سه ارتباط LDP نیاز است در نتیجه برای این بخش چهار ارتباط LDP نیاز است.

Advertising of Label Mappings

تبلیغ(اعلام) label mappings یا label bindings هدف اصلی LDP می باشد. در قسمت های قبلی سه بخش اصلی مربوط به عملیاتی که LSR ها روی label ها انجام می دهد را توضیح دادیم که شامل Advertisement ، label retention و LSP control mode می باشد. که هر بخش دارای دو احتمال است ، که منجر به حالت های زیر می شود :

  • (Unsolicited Downstream (UD در مقابلDownstream-on-Demand (DoD) advertisement mode
  • (Liberal Label Retention (LLR در مقابل Conservative Label Retention (CLR) mode
  • Independent LSP Control در مقابل Ordered LSP Control mode

مهم نیست که یک جفت LDP در چه حالتی عمل می کنند چون هدف تبلیغ label binding است. در حالت UD ، به صورت ناخواسته LDPها label binding را برای LDP دیگر منتشر می کنند. Label binding مجموعه ای از LDP Identifier و label به ازای هر شبکه است.

یک روتر LDP چند label binding برای هر شبکه دریافت می کند. تمام این label bindings در LIB ذخیره می گردند و از بین آنها تنها یک LSR به عنوان LSR پایین دست (next hop) برای آن شبکه در نظر گرفته می شود ، هرچند اگر load balancing وجود داشته باشد امکان داشتن چند LSR پایین دست وجود دارد.

LSR پایین دست را با استفاده از Next hop موجود در جدول مسیریابی برای آن شبکه ، می توان پیدا کرد. تنها remote binding که مرتبط با next hop LSR است برای LFIB قابل استفاده است. به این معناست که تنها یک label از بین تمام label هایی که توسط همسایه ها برای آن ارسال شده است توسط LSR به عنوان label خروجی برای آن شبکه در LFIB مورد استفاده قرار می گیرد. مشکلی که وجود دارد این است که label binding که ارسال می شود بدون آدرس IP اینترفیس است.

به این معنا است که برای پیدا کردن label خروجی برای یک شبکه خاص شما باید LDP Identifier را به ادرس IP اینترفیس در LSR پایین دست map کنید. شما تنها در صورتی می توانید اینکار را انجام دهید که جفت های LDP تمام آدرس های IP خود را اعلام کرده باشند.

این آدرس های IP توسط جفت LDP به وسیله Address messages و Withdraw Address messages اعلام می شود. شما می توانید این آدرس ها را با نگاه کردن به جفت LDP پیدا کنید. این آدرس ها را bound addresses برای جفت LDP می نامند. در تصویر زیر bound addresses برای جفت 10.200.254.2 (london) در LSR نیویورک نمایش داده شده است.

وب سایت توسینسو

هر LSR برای هر شبکه IGP که در جدول مسیریابی خود دارد یک label لوکال در نظر می گیرد. این لوکال label binding است. این local binding در LIB روتر نگه داری می شود. هر یک از این label ها و شبکه های مربوط به آنها توسط LDP به تمام جفت های LDP اعلام می شوند. این label bindings در جفت LDP به عنوان remote binding در LIB نگه داری می شوند. تصویر زیر LIB را در یک LSR نمایش می دهد.

وب سایت توسینسو

همانطور که می بینید برای هر شبکه ، LSR همیشه یک local binding و یک remote binding به ازای هر جفت LDP دارد. در تصویر زیر با استفاده از یک دستور دیگر محتوای LIB را در LSR می بینیم. مقدار in label به local binding اشاره دارد. و مقدار out label به remote binding اشاره دارد. شما می توانید label و LDP Identifier مربوط به LSR که این remote bindings را ارسال کرده است را ببینید.

وب سایت توسینسو

مزیت استفاده از دستور show mpls ip binding این است که نشان می دهد کدام label از بین تمام remote binding های موجود برای ارسال ترافیک استفاده می شود. Inuse نشان می دهد که کدام label برای آن شبکه در LFIB مورد استفاده قرار می گیرد.به تصویر زیر توجه کنید تا ارتباط میان RIB ، bound addresses از جفت LSR ، LIB و LFIB را ببینید.

وب سایت توسینسو

تصویر بالا یک مثال برای ساخت LFIB را برای FEC مرتبط به شبکه 10.200.254.4/32 را نشان می دهد. Label های local برای شبکه ها به صورت مستقیم در LIB وجود دارد اما label خروجی را از طریق RIB ، bound addresses از جفت LDP و LIB می توان یافت.

توجه داشته باشید LDP به تمام شبکه ها local label اختصاص می دهد و آنها را به تمام جفت های LDP خود اعلام می کند. در اینجا مفهوم split horizon وجود ندارد. یک جفت LDP برای یک شبکه local label خود را اختصاص می دهند و آنرا به جفت LDP خود اعلام می کند.

حتی اگر جفت LDP صاحب آن شبکه باشد یا آن LDP به عنوان LSR پایین دست باشد. به تصویر زیر توجه کنید که در آن یک شبکه ساده با دو LSR نمایش داده شده است. روتر لندن صاحب شبکه 10.200.254.2 است که مرتبط به loopback 0 می باشد.

این روتر label binding خود را برای این شبکه به روتر روم اعلام می کند. Label اعلام شده از نوع label implicit NULL می باشد. روتر لندن نیز به نوبه خود برای شبکه 10.200.254.2 از روتر روم remote binding دریافت می کند حتی اگر روتر لندن صاحب این شبکه باشد.

وب سایت توسینسو

به تصویر زیر توجه کنید که در آن label binding برای شبکه 10.200.254.2 در روتر های لندن و روم نمایش داده شده است.

وب سایت توسینسو

Label Withdrawing

Label Withdrawing چیست؟ زمانی یک جفت LDP برای یکدیگر label binding را ارسال می کنند این label binding را تا زمانی نگه داری می کنند که ارتباط LDP وجود داشته باشد یا درخواست پس گرفتن برای آن دریافت نکنند. اگر local label تغییر کند احتمال پس گرفتن آن وجود دارد.

احتمال تغییر local label وجود دارد به طور مثال ، یک اینترفیس با یک شبکه مشخص down شود اما یک LSR دیگر هنوز در حال اعلام آن شبکه است. بنابراین local label برای آن شبکه باید از implicit NULL به یک non-reserved label تغییر کند. اگر این اتفاق بیافتد implicit NULL label بلافاصله با ارسال پیام Label Withdraw به جفت LDP پس گرفته می شود و label جدید توسط label mapping اعلام می شود.

در مثال زیر اینترفیس Ethernet با آدرس شبکه 10.200.210.0/24در LSR لندن down می شود . به همین دلیل روتر لندن این شبکه را با label implicit NULL پس می گیرد. LSR نیویورک همچنان این شبکه را اعلام می کند با فرض وجود یک سوئیچ لایه دو بین لندن و نیویورک ، این نتیجه حاصل می شود که نیویورک سمت دیگر لینک Ethernet است و همچنان up است. LSR لندن یک label جدید به این شبکه اختصاص می دهد (در اینجا label 27 در نظر گرفته شده است) و این label را با استفاده از پیام label mapping به LSR مادرید اعلام می کند.

وب سایت توسینسو

در IOS های قدیمی تر سیسکو (نسخه های قبل از 12.0(21)ST) به صورت پیش فرض قبل از ارسال label جدید برای FEC پیام Label Withdraw برای پس گرفتن label ارسال نمی شود. Label جدید که اعلام می شود یک implicit label withdraw می باشد.

اگر بخواهید رفتار قدیمی را حفظ کنید باید از دستور mpls ldp neighbor neighbor implicit-withdraw استفاده شود. در تصویر زیر نشان می دهد که چه اتفاقی در زمان ارسال label جدید برای شبکه 10.200.210.0/24 با تنظیمات implicitwithdraw در جفت LDP لندن می افتد. پیام label withdraw از خروجی debug حذف می شود. مزیت استفاده از این دستور این است که از ارسال پیام Label Withdraw اجتناب می کند که باعث می شود سربار کمتری ایجاد شود.

وب سایت توسینسو

Housekeeping by Means of Notification

پیام های Notification برای نگه داری از ارتباط های LDP مورد نیاز است. پیام های notification رویدادهای قابل توجهی برای جفت LDP می باشند. این رویدادها می توانند خطاهای رخ داده یا اطلاعات ساده مشاوره ای باشد. اگر یک خطا رخ دهد بلافاصله LSR ارسال کننده و دریافت کننده این رویداد ارتباط LDP را قطع می کنند. Notifications مشاوره ای برای ارسال اطلاعات در مورد ارتباط LDP یا دریافت پیام از جفت استفاده می شود. رویدادهای زیر را با استفاده از پیام های notification می توان اعلام کرد :

  • Malformed protocol data unit (PDU) or message
  • (Unknown or malformed type-length-value (TLV
  • Session keepalive timer expiration
  • Unilateral session shutdown
  • Initialization message events
  • Events resulting from other messages
  • Internal errors
  • Loop detection
  • Miscellaneous events

ارتباط هدف دار LDP

به طور معمول ، ارتباط LDP بین LSR هایی که به صورت مستقیم به یکدیگر متصل هستند تنظیم می شود. در شبکه هایی که مسیرهای IGP نیاز به label خوردن دارد این عمل برای آنها کافی است چون label switching برای بسته هاپ به هاپ انجام می شود.

بنابراین اگر label bindings به صورت هاپ به هاپ برای مسیرهای IGP اعلام شود LSP تشکیل می شود. اما در بعضی شرایط نیاز به ارتباط LDP هدف دار یا remote است. این ارتباط LDP بین LSR هایی برقرار می شود که به صورت مستقیم به یکدیگر متصل نیستند. نمونه این ارتباط هدف دار LDP در شبکه های AToM و TE tunnel در یک شبکه MPLS VPN می باشد.

در حالت AToM یک ارتباط LDP باید بین هر جفت روتر PE وجود داشته باشد. این ارتباط LDP به صورت remote زمانی تشکیل می شود که از دستور xconnect در روترهای PE شبکه AToM استفاده شود. در حالت TE tunnel در یک شبکه MPLS VPN ، در روترهای P که نقطه پایانی TE tunnel می باشند نقطه ابتدایی و پایانی TE tunnel نیاز به یک ارتباط هدف دار LDP دارد تا بتواند ترافیک MPLS VPN را با label درست از طریق شبکه MPLS VPN دریافت کند.

برای همسایه هایی که به صورت مستقیم به یکدیگر متصل هستند تنها کاری که شما باید برای آنها انجام دهید این است که ip mpls را در اینترفیس مورد نظر فعال کنید سپس این همسایه ها یکدیگر را پیدا می کنند و ارتباط LDP از نوع TCP بین آنها ایجاد می گردد. همسایگی LDP در حالتی که آنها به صورت مستقیم به یکدیگر متصل نیستند باید به صورت دستی در هر دو روتر با استفاده از دستور mpls ldp neighbor targeted انجام شود.Syntax دستور به صورت زیر است :

mpls ldp neighbor [vrf vpn-name] ip-addr targeted [ldp | tdp]

در اینجا VRF به (Carrier’s Carrier (CsC اشاره دارد که کدام ارتباط LDP از طریق اینترفیس VRF برقرار است

LDP Authentication

وضعیت زمان convergence در حالت ارتباط هدف دار در مقایسه با ارتباط توسط لینک مسقیم عملکرد بهتری دارد. در حالت ارتباط با لینک مستقیم ، زمانی که لینک بین دو LSR قطع می شود ارتباط LDP نیز از بین می رود اما در ارتباط هدف دار LDP با یک مسیر جایگزین را در نظر بگیرد که بسته های TCP ارتباط LDP از یک LSR به LSR دیگر ارسال می شوند اگر در این حالت یک لینک بین دو LSR قطع شود همچنان ارتباط LDP باقی می ماند

و از طریق لینک جایگزین این ارتباط ادامه خواهد داشت. اگر ارتباط LDP باقی بماند label ها نیز حفظ می شوند و باعث بهبود وضعیت قرار گرفتن label ها از LIB به LFIB هم در زمان قطع شدن لینک و هم در زمان up شدن لینک می شود.برای تغییر زمان LDP hello interval و Hold time برای ارتباط هدف دار LDP می توانید از دستور زیر استفاده کنید :

mpls ldp discovery {hello {holdtime | interval} seconds | targeted-hello {holdtime |interval} seconds | accept [from acl]}

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

و روتر دیگر را تنظیم کنیم که ارتباط هدف دار از یک LDP روتر خاص را قبول کند. اینکار را با دستور [mpls ldp discovery targeted-hello accept [from acl می توان انجام داد. برای جلوگیری از اینکه هر روتری بتواند با این روتر ارتباط LDP برقرار کند از یک ACL استفاده می کنیم که اجازه برقراری ارتباط LDP را تنها به روترهای خاص می دهد.

وب سایت توسینسو

در مثال های زیر تنظمیات مورد نیاز برای برقراری ارتباط هدف دار LDP بین روتر های نیویورک و سیدنی نمایش داده شده است.

وب سایت توسینسو
وب سایت توسینسو

در تصویر زیر خروجی دستور show mpls ldp neighbor برای ارتباط هدف دار LDP نمایش داده شده است.

وب سایت توسینسو

LDP Authentication

ارتباط LDP یک ارتباط TCP است. ارتباط TCP می تواند به وسیله Spoof (جعل) TCP segment مورد حمله قرار گیرد. برای حفاظت از LDP در برابر این حملات ، می توان از احراز هویت به وسیله (Message Digest 5 (MD5 استفاده کرد. MD5 یک Signature که به آن MD5 digest گفته می شود به TCP Segment اضافه می کند.

MD5 digest برای هر TCP segment با استفاده از پسوردی که در هر دو سمت تعیین شده است محاسبه می شود. پسورد MD5 که تعیین می شود هیچ وقت ارسال نمی شود. این باعث می شود که هکر نتواند بهTCP sequence numbers و پسورد DM5 دسترسی پیدا کند. در IOS سیسکو ، با استفاده از دستور زیر می توانید MD5 را برای LDP تنظیم کنید. این تنظیمات باید در هر دو جفت LDP انجام شود.

mpls ldp neighbor [vrf vpn-name] ip-addr password [0-7] pswd-string

MD5 به هر TCP segment که خارج می شود یک digest اضافه می کند. این digest تنها توسط هر دو جفت LDP که پسورد برای آنها تنظیم شده است قابل بررسی است. اگر MD5 در یک LSR برای یک LDP تنظیم شده باشد و برای LSR دیگر اینکار انجام نشده باشد پیام زیر به صورت log نمایش داده می شود :

TCP-6-BADAUTH: No MD5 digest from 10.200.254.4(11092) to 10.200.254.3(646) 

اگر هر دو LDP پسورد برای MD5 داشته باشند اما پسوردها با هم مطابقت نداشته باشند پیام زیر به صورت log نمایش داده می شود :

TCP-6-BADAUTH: Invalid MD5 digest from 10.200.254.4(11093) to 10.200.254.3(646)

کنترل ارسال Labels ها توسط LDP

LDP این اجازه را می دهد که بتوانید روی ارسال label ها کنترل داشته باشید. شما می توانید LDP را تنظیم کنید که بعضی از labelها را به بعضی از جفت های LDP خود ارسال کند یا ارسال نکند. سپس شما می توانید از label های local که اختصاص داده اید و آنها را برای جفت های LDP ارسال کرده اید به عنوان label خروجی برای آن LSR ها استفاده کنید. Syntax برای این دستور به صورت زیر است :

mpls ldp advertise-labels [vrf vpn-name] [interface interface|for prefix-access-list [to peer-access-list]]

prefix-access-list یک access list استاندارد با شماره 1 تا 99 یا یک access list با نام است که به وسیله آن مشخص می کنید label کدام شبکه باید ارسال شود. همچنین peer-access-list یک access list استاندارد با شماره 1 تا 99 یا یک access list با نام است که به وسیله آن مشخص می کنید کدام جفت LDP باید label ها را دریافت کند. اگر چهار بایت اول LDP router ID جفت LDP با access list مطابقت پیدا کند. در بسیاری از موارد استفاده از این دستور برای محدود کردن تعداد label های ارسالی است

و تنها label های شبکه هایی که برای ارسال ترافیک در شبکه MPLS مورد استفاده قرار می گیرند را در این access list قرار می دهیم. به طور مثال شبکه MPLS VPN را در نظر بگیرد ، BGP nexthop prefixes به عنوان شبکه مهم برای گرفتن ترافیک مشتری و انتقال آن از شبکه MPLS است که معمولا اینترفیس loopback در روتر PE هستند. در این حالت شما می توانید label bindings را برای شبکه های متعلق به سایر اینترفیس ها در روترهای P یا PE را ارسال نکنید.

  • نکته : برای اعمال دستور mpls ldp advertise-labels لازم نیست همسایگی LDP را پاک کنید.

LDP Autoconfiguration

شما نمی توانید روی label های ارسالی توسط LDP برای شبکه های LC-ATM به وسیله دستور mpls ldp advertise-labels کنترل داشته باشید. چون شبکه های LC-ATM از DoD بجای UD برای ارسال label ها استفاده می کند. DoD دستور خاص خودش را برای محدود کردن ارسال label ها توسط LDP را دارد.

برای شبکه های LC-ATM از دستور mpls ldp request-labels بجای mpls ldp advertiselabels استفاده می شود.در تصویر زیر یک شبکه را می بینید. روتر سیدنی تنها شبکه loopback 0 خود را و شبکه 10.200.254.3 را از روتر روم به جفت LDP خود یعنی روتر مادرید با router ID 10.200.254.5 ارسال می کند.

وب سایت توسینسو

تنظیمات مورد نیاز برای اینکار در تصویر نمایش داده شده است. استفاده از دستور no mpls ldp advertise-label را فراموش نکنید اگر تنها دستور mpls ldp advertiselabels for prefix-access-list to peer-access-list را استفاده کنید LSR سیدنی همچنان label های تمام شبکه ها را توسط LDP ارسال خواهد کرد.

وب سایت توسینسو

تنها شبکه های 10.200.254.3 و 10.200.254.4 به جفت LDP یعنی روتر مادرید ارسال خواهد شد. در تصویر زیر binding در روتر سیدنی بعد از اعمال فیلترینگ نمایش داده شده است.

وب سایت توسینسو

به مثال زیر توجه کنید تمام دیگر شبکه هایی که از روتر سیدنی به روتر مادرید ارسال شده اند دارای remote binding نیستند.

وب سایت توسینسو

در LFIB روتر مادرید دو شبکه 10.200.254.3 و 10.200.254.4 دارای label خروجی درست هستند و برای سایر شبکه ها No label به عنوان label خروجی برای آنها مشخص شده است. LFIB در روتر مادرید را در مثال زیر می توانید مشاهده کنید.

وب سایت توسینسو

IOS سیسکو در پیاده سازی LDP این اجازه را می دهد که بیشتر از یک دستور mpls ldp advertiselabels for prefix-access-list to peer-access-list را استفاده کنید. این ویژگی باعث انعطاف پذیری بیشتر می شود جایی که به وسیله آن می توانید مشخص کنید که کدام label binding به کدام جفت LDP ارسال شود.

تصویر زیر همانند مثال قبل است با این تفاوت که یک دستور mpls ldp advertiselabels for prefix-access-list to peer-access-list به آن اضافه شده است و باعث می شود که روتر سیدنی تنها label های مربوط به دو شبکه 10.200.254.3 و 10.200.254.4 را به 10.200.254.5 ارسال کند و به سایر جفت های LDP خود تمام label binding ها را ارسال کند.

وب سایت توسینسو

فیلترکردن Label Binding ورودی

شما می توانید label binding های ورودی از یک همسایه LDP خود را فیلتر کنید. در واقع این ویژگی برخلاف کنترل ارسال label هاست که در آن از ارسال label جلوگیری می شد که در بخش قبلی مورد بحث قرار گرفت. زمانیکه شما نمی توانید روی ارسال label ها توسط یک LDP کنترل داشته باشید می توانید از فیلترکردن Label Binding ورودی برای آن LDP استفاده کنید.

این ویژگی این امکان را به ما می دهد که تعداد label bindings که در LIB روتر ذخیره می شوند را محدود کنیم. به طور مثال شما می توانید همه label binding های دریافتی از جفت های LDP را فیلتر کنید غیر از label binding که مربوط اینترفیس loopback روترهای PE در یک شبکه MPLS VPN است. معمولا این اینترفیس های loopback دارای آدرس BGP next-hop IP هستند و LSR ها با استفاده از label اختصاص یافته به این شبکه ها می تواند ترافیک VPN مشتری را ارسال کند.برای فعال کردن فیلترینگ label های ورودی از دستور زیر استفاده می کنیم :

mpls ldp neighbor [vrf vpn-name] nbr-address labels accept acl

در تصویر زیر نشان می دهد که LSR مادرید فیلترینگ label های ورودی برای جفت LDP خود با ID 10.200.254.4 انجام داده است. این باعث می شود که تنها label binding برای شبکه های 10.200.254.3 و 10.200.254.4 که مربوط به شبکه های loopback روترهای PE است را قبول کند.

با دستور show mpls ldp bindings شما می توانید ببینید که LSR فقط از جفت LDP مشخص ، برای شبکه هایی که توسط access list اجازه پیدا کرده اند remote label bindings دارد. نتیجه اجرای فیلترینگ ورودی برای label ها مشابه کنترل ارسال label ها است که در قسمت قبلی توضیح داده شد.

وب سایت توسینسو

LDP Autoconfiguration

LDP در اینترفیس با استفاده از دستور mpls ip که در اینترفیس زده می شود فعال می گردد. در یک LSR معمولا LDP روی تمام اینترفیس های IGP فعال می گردد. استفاده از Autoconfiguration برای فعال کردن LDP در IGP بسیار راحت تر از استفاده از دستور mpls ip روی همه اینترفیس ها است. استفاده از Autoconfiguration باعث می شود LDP برای تمام اینترفیس های IGP فعال گردد. برای فعال کردن LDP Autoconfiguration در روتری که OSPF را اجرا کرده است از دستور زیر استفاده می کنیم :

mpls ldp autoconfig [area area-id]

همانطور که می بینید LDP رو می توان در یک OSPF area مشخص فعال کرد. همینطور می توان آنرا در یک اینترفیس خاص غیر فعال کرد. برای غیر فعال کردن LDP Autoconfiguration در یک اینترفیس از دستور زیر استفاده می شود :

no mpls ldp igp autoconfig

به تصویر زیر توجه کنید Interface config نشان می دهد که LDP به وسیله دستور mpls ip فعال شده است. IGP config نشان می دهد که LDP به وسیله دستور mpls ldp autoconfig فعال شده است.

وب سایت توسینسو

LDP-IGP Synchronization

MPLS LDP-IGP Synchronization چیست؟ یک مشکل با شبکه MPLS این است که LDP با IGP شبکه هماهنگ نیست. هماهنگی به این معناست که ارسال بسته به خارج از یک اینترفیس تنها در حالتی اتفاق می افتد که IGP و LDP هر دو قبول کنند که این اینترفیس به عنوان لینک خروجی مورد استفاده قرار گیرد.

به طور معمول مشکل زمانی که شبکه MPLS از LDP استفاده می کند رخ می دهد که یک ارتباط LDP در یک لینک از بین رود و IGP هنوز آن لینک را به عنوان لینک خروجی در نظر می گیرد بدین ترتیب بسته ها همچنان روی این لینک ارسال می شوند. این اتفاق به این دلیل اتفاق می افتد که IGP بهترین مسیر را برای هر شبکه در جدول مسیریابی قرار می دهد.

بنابراین ترافیک برای یک شبکه با این لینک که ارتباط LDP در آن از بین رفته است بدون label ارسال خواهد شد. این مشکل بزرگی برای شبکه هایی که فقط IPv4-over-MPLS را اجرا کرده اند نیست چون در مقطعی که ارتباط LDP از بین رفته است بسته ها بدون label ارسال می شوند و ترافیک در اینجا به عنوان بسته های IPv4 تا LSR بعدی ارسال می شوند و از آنجا به بعد مجدد با label ارسال می شوند.

اما برای حالت های غیر IPv4-over-MPLS این یک مشکل می باشد. در شبکه های (MPLS VPN ، AToM ، Virtual Private LAN Switching (VPLS یا IPv6 over MPLS بسته های در حین ارسال نباید بدون label شوند. اگر این بسته ها بدون label شوند LSR نمی تواند بسته ها را ارسال کند درنتیجه آنها را drop می کند.

بسته ها در حالت MPLS VPN بسته های IPv4 هستند اما باید براساس VRF مسیریابی شوند. این جدول خصوصی برای یک مشتری می باشد و در edge LSR یا روترهای PE ارائه می شوند. بنابراین زمانی که بسته های MPLS VPN در core LSRs (P Router)، بدون label می شوند آنها drop می شوند.

مشابه این اتفاق برای ترافیک AToM و IPv6 می افتد و core LSRs نمی تواند آنها را بدون label ارسال کنند. اگر یک ارتباط LDP قطع شود در حالی که همسایگی IGP بین دو LSR همچنان up است می تواند باعث مشکل بزرگی شود چون ترافیک زیادی از بین می رود. تصویر زیر یک ارتباط قطع شده LDP بین دو LSR در MPLS core را نشان می دهد و بسته های label خورده drop می شوند.

وب سایت توسینسو

LSR زمانی که restart می شود مشابه این مشکل بوجود می آید. IGP می تواند همسایگی را سریعتر نسبت به ارتباط LDP برقرار کند. این به این معناست که IGP ارسال بسته ها را شروع می کند قبل از اینکه LFIB با اطلاعات لازم برای ارسال براساس label تشکیل شود. در این زمان بسته ها به شکل صحیح ارسال نمی شوند (بدون label) یا تا زمان برقراری ارتباط LDP بسته ها drop می شوند.

راه حل برای این مشکلات ، LDP-IGP Synchronization در MPLS است. این ویژگی مطمئن می شود در زمانی که ارتباط LDP قطع است از لینک بدون label استفاده نشود. بنابراین ترافیک از طریق یک لینک دیگر که در آن ارتباط LDP برقرار است ارسال می شود.

این مشکل که به وسیله LDP-IGP Synchronization حل می شود در BGP و label distributionاتفاق نمی افتد. چون BGP از label binding و control plane برای IP routing محافظت می کند و باعث می شود از بروز مشکل ذکر شده جلوگیری شود. همچنین این امکان وجود دارد که همسایگی IGP برقرار باشد در حالی که ارتباط LDP قطع است. اما BGP یا up است یا Down. به این معناست که قرار گرفتن بهترین مسیر در جدول مسیریابی توسط BGP به label binding مرتبط است.

  • LDP-IGP Synchronization چگونه کار می کند

زمانی که LDP-IGP synchronization برای یک اینترفیس فعال می گردد IGP آن لینک را تا زمانی که synchronization انجام شود یا ارتباط LDP در آن اینترفیس برقرار گردد با حداکثر متریک اعلام می کند. حداکثر متریک برای لینک در OSPF برابر 65536 می باشد.

هیچ مسیری از این اینترفیس (جایی که ارتباط LDP قطع شده) استفاده نمی کند مگر اینکه تنها مسیر موجود باشد. بعد از اینکه ارتباط LDP برقرار شد و label bindings مبادله شد IGP لینک را با متریک نرمال آن اعلام می کند. در این لحظه ترافیک به صورت label switch در اینترفیس می باشد. در واقع OSPF قبل از برقراری ارتباط LDP روی این لینک همسایگی برقرار نمی کند (OSPF روی این لینک بسته های Hello ارسال نمی کند).

تا زمانی که ارتباط LDP برقرار است یا تا زمانی که تایمر synchronization منقضی نشده باشد همسایگی OSPF برقرار نخواهد شد. در اینجا منظور از Synchronized این است که label binding های local روی ارتباط LDP برای جفت LDP ارسال می شوند.

اما زمانی که synchronization در روتر A فعال می گردد و این روتر تنها یک لینک به روتر B دارد و هیچ ارتباط IP دیگری با روتر B از طریق لینک دیگری ندارد (به این معنا که از طریق هیچ روتر دیگری این ارتباط وجود ندارد) همسایگی OSPF هرگز up نخواهد شد.

OSPF منتظر می ماند تا ارتباط LDP برقرار شود اما ارتباط LDP برقرار نمی شود چون روتر A نمی تواند مسیری در جدول مسیریابی خود برای LDP router ID روتر B داشته باشد. همسایگی OSPF و LDP در این وضعیت می تواند برای همیشه down باشد اگر روتر A فقط روتر B را به عنوان همسایه خود داشته باشد LDP router ID روتر B در دسترسی نخواهد بود به این معناست که مسیری برای آن در جدول مسیریابی روتر A وجود ندارد.

در این حالت LDP-IGP synchronization تشخیص می دهد که جفت در دسترس نیست و اجازه می دهد که همسایگی OSPF برقرار شود. در این حالت لینک با حداکثر متریک اعلام می شود تا زمانی که synchronization انجام شود. این باعث می شود مسیر از طریق این لینک اخرین گزینه باشد.

در بعضی مواردی مشکل ارتباط LDP همیشگی است بنابراین جالب نیست که منتظر باشیم تا همسایگی IGP برقرار شود. راه حل برای این مشکل ، تنظیم Holddown تایمر برای synchronization است. اگر قبل از اینکه ارتباط LDP برقرار شود تایمر منقضی شود همسایگی OSPF برقرار خواهد شد.

اگر همه چیز در رابطه با LDP در لینک درست باشد LDP ارتباط خود را در لینک برقرار می کند. تا زمانی که LDP synchronizes شود OSPF منتظر است تا همسایگی آن تشکیل شود و تا آن زمان وضعیت OSPF در حالت down است و OSPF روی آن لینک بسته های hello ارسال نمی کند

LDP-IGP Synchronization

تنظیم MPLS LDP-IGP Synchronization چیست؟ MPLS LDP-IGP Synchronization برای یک IGP Process فعال می شود. به این معناست که برای یک IGP تنظیم می شود و به تمام اینترفیس هایی که IGP روی آنها فعال است اعمال می شود.

از دستور mpls ldp sync برای فعال کردن در یک IGP استفاده می شود و در router process استفاده می شود. با استفاده از دستور no mpls ldp igp sync می توان MPLS LDP-IGP Synchronization را روی یک اینترفیس غیرفعال کرد. به صورت پیش فرض ، اگر synchronization انجام نشود IGP تا ابد منتظرم می ماند که همسایگی آن برقرار شود.

شما می توانید این ویژگی را با استفاده از دستور mpls ldp igp sync holddown msecs به صورت globally تغییر دهید استفاده از این دستور باعث می شود که IGP فقط برای مدت زمان مشخص شده منتظر بماند و بعد از این زمان IGP همسایگی خود را روی لینک برقرار می کند.

تا زمانی که همسایگی IGP برقرار است و ارتباط LDP هنوز synchronized نشده است IGP با حداکثر متریک لینک های خود را advertises می کند.زمانی که OSPF منتظر است که LDP synchronize شود گفته می شود که “Interface is down and pending LDP.”

در این حالت OSPF همسایگی را برقرار نمی کند. زمانی که OSPF همسایگی خود را برقرار کند ولی LDP هنوز اینکار را نکرده باشد گفته می شود “Interface is up and sending maximum metric.” در این حالت اینترفیس برای ارسال ترافیک استفاده نمی شود مگر اینکه تنها لینک خروجی LSR باشد. در مثال زیر تنظیمات برای MPLS LDP-IGP Synchronization نمایش داده شده است.

وب سایت توسینسو

در مثال زیر خروجی دستور show ip ospf mpls ldp interface نمایش داده شده است زمانی که یک اینترفیس بعد از down شدن دوباره up شده است اما LDP مشکل دارد و ارتباط LDP برقرار نشده است. در نتیجه OSPF همسایگی را برقرار نمی کند و در حقیقت اینترفیس OSPF در وضعیت down قرار دارد.

وب سایت توسینسو

برای اینکه OSPF تا ابد منتظر نماند که LDP ارتباطش برقرار شود شما می توانید برای آن Holddown timer مشخص کنید. بعد از اینکه این تایمر منقضی شود OSPF بدون در نظر گرفتن برقراری ارتباط LDP همسایگی خود را برقرار می کند. نمونه این تنظمیات در تصویر زیر نمایش داده شده است.

وب سایت توسینسو

بعد از اینکه تایمر منقضی شود همسایگی OSPF برقرار می شود و همچنان ارتباط LDP قطع می باشد چون یک مشکل مداوم روی لینک وجود دارد. تا زمانی که این وضعیت وجود دارد OSPF لینک ها را با حداکثر متریک که 65535 می باشد اعلام می کند. در تصویر زیر این مورد نمایش داده شده است. وضعیت sync را “sync not achieved.” نمایش داده شده است.

وب سایت توسینسو

نتیجه اعلام لینک ها با حداکثر متریک این است که LSR نمی تواند از آن برای ارسال بسته ها استفاده کند. اگر یک بسته MPLS AToM ، IPv6 ، VPLS یا هر بسته ای که بیش از دو label داشته باشد به روتر مادرید برسد و نیاز باشد که روی اینترفیس سریال 4/0 ارسال شود

در حالی که LDP قطع است و LDP-IGP Synchronization نیز وجود نداشته باشد این بسته ها drop خواهند شد. در صورت وجود LDP-IGP Synchronization این بسته ها از طریق یک اینترفیس دیگر که در آنجا ارتباط LDP برقرار است ارسال خواهند شد.دستور debug زیر برای LDP synchronization مورد استفاده قرار می گیرد:

debug mpls ldp sync [interface <name>] [peer-acl <acl>]

نمونه زیر خروجی دستور debug mpls ldp igp sync را نمایش می دهد.

وب سایت توسینسو

براساس چیزی که در تصویر زیر می بینید اگر جفت در دسترس نباشد به هر شکل IGP همسایگی را تشکیل می دهد تا به LDP فرصت ایجاد ارتباط LDP روی لینک را بدهد. زمانی این اتفاق می افتد که این لینک تنها مسیر موجود بین جفت روتر باشد.

وب سایت توسینسو
  • MPLS LDP Session Protection

یکی از مشکلات عمومی شبکه لینک های flapping است. لینک های flapping می تواند چند علت داشته باشد که خارج از اهداف این مبحث می باشد که بخواهیم به صورت دقیق تر به آن بپردازیم. لینک های Flapping تاثیر مهمی در Convergence شبکه دارند.

چون همسایگی IGP و ارتباط LDP روی لینک برقرار است زمانی که لینک قطع می شود آنها نیز قطع می شوند. این مایه تاسف است بخصوص که لینک به طور معمول برای مدت زمان طولانی قطع نمی ماند. در اینجا تاثیر بسیار زیاد است چون برقرار ارتباط همسایگی پروتکل مسیریابی و LDP زمان می برد. LDP ارتباط خود را مجدد برقرار می کند و باید دوباره Label binding را مبادله کنند.

برای اجتناب از برقراری دوباره ارتباط LDP می توانیم از آن محافظت کنیم. زمانی که یک ارتباط LDP بین دو LSR که به صورت مستقیم به یکدیگر متصل هستند محافظت می شود یک ارتباط هدف دار LDP بین دو LSR تشکیل می شود. زمانی که لینک مستقیم بین دو LSR قطع می شود ارتباط هدف دارLDP تا زمانی که یک مسیر جایگزین بین دو LSR وجود داشته باشد up می ماند.

زمانی که لینک قطع می شود ارتباط LDP از طریق آن لینک از بین می رود ولی ارتباط هدف دار LDP همچنان up نگه داشته می شود. زمانی که لینک دوباره up می شود LSR دیگر نیازی به برقراری مجدد ارتباط LDP ندارد. بنابراین وضعیت convergence بهتر می شود. دستور برای محافظت از ارتباط LDP به شرح زیر می باشد که به صورت globally استفاده می شود.

mpls ldp session protection [vrf vpn-name] [for acl] [duration seconds]

استفاده از ACL این امکان را به شما می دهد که مشخص کنید کدام جفت LDP باید محافظت شوند. LDP Router Identifier مربوط به همسایه LDP که قرار است محافظت شود را باید نگه داری کرد. ِduration مدت زمانی است که بعد از اینکه لینک همسایگی LDP قطع می شود برای محافظت در نظر گرفته می شود. به صورت پیش فرض مقدار آن بی نهایت در نظر گرفته می شود.برای اینکه محافظت عمل کند باید روی هر دو LSR فعال شود.

اگر این امکان وجود ندارد و فقط می توانید روی یک LSR آنرا فعال کنید و LSR دیگر می تواند hello ارتباط هدف دار را با استفاده از دستور mpls ldp discovery targeted-hello accept قبول کند.به تصویر زیر توجه کنید. محافظت از ارتباط LDP روی هر چهار روتر فعال شده است. LSR مادرید دو ارتباط LDP دارد یکی با لندن و دیگری با سیدنی. زمانی که لینک مادرید سیدنی قطع می شود ارتباط هفت دار up نگه داشته می شود و از مسیر مادرید لندن روم سیدنی استفاده می شود.

وب سایت توسینسو

در مثال زیر ارتباط LDP مادرید به روتر سیدنی قبل از قطع شدن لینک نمایش داده شده است. بعد لینک مادرید سیدنی قطع می شود و شما می تواند log آنرا برای ارتباط LDP زمانی که لینک قطع می شود و زمانی که دوباره up می شود ببینید. اولین log نشان می دهد که ارتباط LDP در حالت محافظت شده قرار می گیرد و دومین log نشان می دهد که ارتباط LDP با موفقیت ریکاوری شده است.

وب سایت توسینسو

در نهایت ، یک ویژگی LDP که بسیار کاربردی است LDP Graceful Restart می باشد که یک مکانیزم برای جفت های LDP می باشد که باعث می شود که MPLS وضعیت ارسال خود را در زمانی که ارتباط LDP قطع می شود را حفظ کند. به طور مثال ، ترافیک در زمانی که ارتباط LDP ری استارت می شود می تواند همچنان ارسال شود.مباحث مرتبط با LDP به اتمام رسید

معماری MPLS و ATM

معماری MPLS و ATM چیست؟ ATM یک پروتکل connection-oriented است که توسط ITU-T ارائه شده است. به این دلیل connection-oriented است که ترافیک ATM براساس مدارهای مجازی (virtual circuits) حمل می شوند. ترافیک ATM شامل Cell هایی با اندازه ثابت 53 بایت می باشند که از این 53 بایت ، 5 بایت آنرا هدر cell و 48 بایت دیگر را دیتای cell تشکیل می دهد. بیشترین موفقیت ATM در شبکه WAN می باشد. بسیاری از فروشندگان سوئیچ های ATM ساختن که می توانست virtual circuits را در شبکه WAN ایجاد کند. مزایای ATM به شرح زیر است:

  • اندازه ثابت بسته که باعث می شود انتقال با کمترین jitter انجام شود.
  • تضمین QoS
  • انعطاف پذیری بالا

موفقیت ATM محدود به استفاده در شبکه های WAN می باشد. از زمانی که IP به پروتکل استاندارد شبکه تبدیل شد و تقریبا همه از آن استفاده کردند تلاش زیادی صورت گرفت که ترافیک IP روی شبکه ATM قابل دریافت باشد. به این منظور چندین طرح ارائه شد :

  • Encapsulation according to RFC 1483
  • (Lane Emulation (LANE
  • (Multiprotocol over ATM (MPOA

RFC 1483 (براساس RFC 2684 که منسوخ شده است ایجاد شد) مشخص می کند که چگونه چندین route و پروتکل های bridge را روی ATM adaptation layer (AAL) 5 کپسوله کرد. LANE مشخص می کرد چگونه فریم های Ethernet روی شبکه ATM حمل شود.

MPOA یکپارچه سازی IP روی ATM را فراهم می کرد اما یک روش پیچیده بود. هیچ کدام از این راه حل ها نتوانست تناسب و یکپارچگی مناسبی بین ATM و IP ایجاد کند. یکی از دلایل بکار رفتن MPLS تناسب و یکپارچگی با IP می باشد. با MPLS سوئیچ های ATM نیاز دارند که یک پروتکل مسیریابی IP را اجرا کنند و همچنین به یک پروتکل label distribution برای تبادل label های شبکه بین خودشان و روترها نیاز دارند. نتیجه این خواهد بود که مدل overlay از IP over ATM دیگر مورد نیاز نیست. با MPLS ، مدل peer خواهد بود.

  • معرفی مختصر ATM

یک ATM cell متشکل شده است از 5 بایت هدر و 48 بایت دیتا که در تصویر زیر نمایش داده شده است :

وب سایت توسینسو

فرمت cell که در تصویر نشان داده شده است یک (User-Network Interface (UNI می باشد. هدر (Network Node Interface (NNI مشابه این cell است فقط فیلد GFC آن متفاوت است که این فیلد حذف شده است. در عوض 12 بیت اول را فیلد VPI اشغال کرده که باعث شده 4 بیت بزرگتر شود و سوئیچ های ATM بتوانند مقدار بزرگ تری را به (virtual path identifiers (VPI اختصاص دهند.در جدول زیر نام و معنی هر یک از فیلدهای هدر ATM cell نمایش داده شده است.

وب سایت توسینسو

فیلد GFC یک تابع local برای ATM cell فراهم می کند. منظور از local این است که از ابتدا تا انتها متغییر می باشد و سوئیچ های میانی در هنگام ارسال این فیلد را تغییر می دهند. تابع local ممکن است به معنای کنترل جریان و شناسایی موقعیت های مختلف در یک اینترفیس ATM باشد.فیلدهای VPI و VCI با یکدیگر استفاده می شوند و برای شناسایی مقصد بعدی ATM cell مورد استفاده قرار می گیرد :

سه بیت فیلد PT به شرح زیر تعریف می شوند :

  • بیت اول مشخص می کند که cell حاوی دیتا کاربر است یا کنترلی
  • بیت دوم وضعیت ازدحام را نشان می دهد
  • بیت سوم نشان می دهد که cell اخرین cell از یک فریم AAL5 است یا خیر

ATM می تواند PVC به صورت static داشته باشد یا (private network-network interface (PNNI می تواند به صورت دینامیک به virtual circuits اختصاص یابد. PNNI یک پروتکل مسیریابی سلسله مراتبی link state است virtual circuits را در سرتاسر شبکه ATM ایجاد می کند. برای اینکه cell ها به صورت درست تبدیل شوند و توسط پروتکل های لایه بالاتر مورد استفاده قرار گیرند ، ITU-T یک لایه بین لایه ATM و لایه بالاتر مشخص کرده است.

این لایه AAL نامیده می شود و دارای 5 دسته است. AAL1 به صورت connection-oriented است و برای سرویس هایی که به delay حساس هستند مورد استفاده قرار می گیرد. AAL2 نیز connection-oriented است و برای سرویس هایی با نرخ متغییر استفاده می شود.

AAL3/4 به صورت connectionless است و برای SMDS قدیمی تر مورد استفاده قرار می گیرد. AAL5 می تواند به صورت connection-oriented یا connectionless باشد و برای تقاضای bit rate متفاوت مورد استفاده قرار میگیرد. معمولا برای IP و LANE استفاده می شود

Label Encoding 

برای حمل ترافیک IP از طریق شبکه ATM روترهای لبه شبکه ATM از طریق PVC به یکدیگر متصل می شوند. برای اتصال روترها در بهترین حالت ، باید روترها را به صورت مستقیم از طریق PVC به یکدیگر متصل کنیم. همچنین ترافیک نباید دوبار از شبکه ATM عبور نکند.

بنابراین روترها باید به صورت Full meshed به یکدیگر متصل شوند. این حالت را overlay model می نامند چون همه روترها دارای همسایگی IGP با یکدیگر از طریق شبکه ATM هستند. در تصویر زیر یک شبکه Overlay از روترها روی شبکه ATM نمایش داده شده است.

وب سایت توسینسو

در نتیجه این شبکه n-1)*2) عدد (virtual circuits (VCs برای n روتر که به شبکه ATM متصل هستند نیاز است. MPLS این مشکل را حل می کند. زمانی که سوئیچ های ATM اگاهانه مسیریابی را انجام می دهند ، آنها می توانند همسایگی IGP را میان خود و روترها تشکیل دهند.

دیگر نیاز نیست هر روتر همسایگی IGP با سایر روترها تشکیل دهد و تنها با نزدیکترین سوئیچ ATM اینکار را انجام می دهد. در تصویر زیر سوئیچ های ATM شبکه ATM را که تبدیل به (label switching routers (LSRs شده اند را نشان می دهد. به این معناست که آنها تبدیل به MPLS شده اند. این حالت peer model نامیده می شود چون روترها (edge LSR) تنها با نزدیکترین سوئیچ (ATM (LSR جفت می شوند.

وب سایت توسینسو

برای اینکه ترافیک به درستی از طریق ATM LSR ارسال شوند ترافیک باید به صورت MPLS کپسوله شوند و مقدار MPLS label باید براساس VPI/VCI مقدار دهی شود. چون سوئیچ های ATM همچنان سوئچینگ ATM cells را روی virtual circuits انجام می دهند. چون سوئیچ های ATM نیاز دارند که MPLS label را براساس VC مقداردهی کنند آنها باید در ابتدا مقدار این label ها را فرا گیرند. از این رو سوئیچ های ATM باید label distribution protocol را اجرا کنند. یک ATM LSR شامل مورد زیر است :

  • یک routing protocol در control plane
  • یک label distribution protocol در control plane
  • سوئیچینگ ATM cells در data plane

سوئیچ های ATM سیسکو از (Open Shortest Path First (OSPF به عنوان پروتکل مسیریابی و از LDP به عنوان label distribution protocol پشتیبانی می کند. ATM LSR سیسکو مسیرها را در OSPF و label bindings مرتبط به مسیرها را توسط LDP توزیع می کند.

Label های ورودی و خروجی براساس VPI/VCI ورودی و خروجی مقدار دهی می شوند. نتیجه این است که در data plane سوئیچ ATM تنها نیاز دارد که سوئیچنگ cells را از virtual circuit ورودی به virtual circuit خروجی انجام دهد.(دقیقا براساس عملکرد ATM برای ارسال) سوئیچ های ATM هرگز بسته های IP را ارسال نمی کنند. اگر اینکار نیاز شد باید سوئیچ ATM در ابتدا ATM cells را در فریم reassemble کند. هر سوئیچ ATM در طول مسیر باید اینکار را انجام دهد. این یک دلیل برای عملکرد نامطلوب است.

  • Label Encoding چیست؟

سوئیچ های ATM که MPLS را اجرا کرده اند همچنان سوئیچینگ ATM cells را انجام می دهند. به این ترتیب آنها نمی توانند فریم های label خورده را ارسال کنند. اما MPLS label براساس VCs در شبکه ATM مقدار دهی شده است ، مقدار MPLS label براساس VPI-VCI جفت می باشد. اگر بسته label خورده دارای label stack با بیش از یک label باشد ، تنها label بالای label stack براساس VPI-VCI مقدار دهی می شود. تصویر زیر مقدار دهی MPLS label براساس مقدار VPI/VCI نمایش داده شده است.

وب سایت توسینسو

زمانی که edge ATM LSR یک فریم دریافت می کند فریم را در cell ها تکه تکه می کند. تنها مقدار label بالای label stack براساس VPI-VCI مقداردهی می شود. باقی label ها در label stack برای ارسال cell ها مورد نیاز نیستند. با این حال ، label stack به صورت کامل در فریم قرار می گیرد و همراه آن تکه تکه می شود

و فریم برای ارسال خارج از شبکه ATM ، برای MPLS به این label stack نیاز خواهد داشت. Label بالای label stack براساس فیلد VPI-VCI مقداردهی می شود و در هر ATM LSR تغییر می کند و مقدار label در label بالای label stack برابر صفر می شود.

Label بالای label stack به خاطر سه فیلد دیگر یعنی TTL ، EXP و End-of-Stack نگه داشته می شود. TTL موجود در label بالای label stack ، مقدار TTL خروجی را مشخص می کند زمانی که در egress edge ATM LSR بسته reassemble می شود. همچنین EXP برای QoS بسته در egress edge ATM LSR مورد استفاده قرار می گیرد.

حتی اگر label stack تنها شامل یک label باشد همچنان توسط شبکه ATM در اولین cell حمل می شود. این ویژگی egress ATM LSR را قادر می سازد تا بفهمد که بسته دارای label stack بوده است یا خیر.

چون مقدار VCI برابر 16 بیت است می تواند 216 یا 65536 ، label وجود داشته باشد. با توجه به اینکه تعداد VC ها در سوئیچ های ATM محدود است این مقدار به تنهایی باید برای label های مورد نیاز یک اینترفیس کفایت کند. مقدار VPI برابر 12 بیت است بنابراین می تواند 212 یا 4096 ، label وجود داشته باشد

Label Advertisement چیست؟

Label Advertisement چیست؟ IGP و LDP نمی توانند به صورت مستقیم روی اینترفیس ATM مربوط به ATM LSR اجرا شوند و همسایگی خود را برقرار کنند. یک control VC برای IGP و LDP بین دو ATM LSR مورد نیاز است . زمانی که همسایگی IGP شکل می گیرد IGP می تواند شبکه های IP را مبادله کند.

بعد از اینکه LDP ارتباط خود را از طریق control VC ایجاد کرد می تواند label bindings را مبادله کند. این کار باعث می شود که ATM LSRs بتوانند LIB خود را با این binding ها پر کنند. همین طور که در قسمت های قبلی عنوان شد یک binding متشکل از یک شبکه و label اختصاص یافته به آن می باشد.

هر شبکه IGP در جدول مسیریابی باید یک label به آن اختصاص داده شود. مقدار هر label براساس مقدار VPI/VCI مقداردهی می شود و برای هر label یک virtual circuit تشکیل می شود. این نوع virtual circuit را (label switched controlled virtual circuit (LVC یا (tag switching controlled virtual circuit (TVC نامیده می شود.

برای ساخت این LVC ها باید اینترفیس ATM را در سوئیچ های ATM و روترها تنظیم کرد که اینترفیس (Label Switching Controlled-ATM (LC-ATM شوند. هر اینترفیس LC-ATM باید control virtual circuit داشته باشد. در روترها و سوئیچ های ATM که IOS سیسکو را اجرا می کنند به صورت پیش فرض virtual circuit 0-32 است و نوع encapsulation برای آن باید LLC-SNAP باشد. تصویر زیر یک نمونه شبکه MPLS با ATM LSRs در core آن نمایش داده شده است.

وب سایت توسینسو

نکته : به هر کدام از سه ATM LSRs (شامل washington-atm ، denver-atm و brussels-atm) یک روتر با یک اینترفیس ATM متصل است. هر شش دستگاه در یک OSPF area قرار دارند. MPLS در اینترفیس های ATM بین سوئیچ های ATM با استفاده از دستور mpls ip فعال شده است

و این اینترفیس ها IP unnumbered شده اند ( به loopback 0 اینترفیس). LDP روی اینترفیس های ATM در حال اجرا است و ارتباط LDP بین ATM LSRs روی control VC تشکیل شده است. در اینترفیس روترها که به سمت ATM LSRs هستند subinterfaces با MPLS و IP unnumbered به اینترفیس loopback 0 وجود دارد. تصویر زیر نمونه تنظیمات در ATM LSR دنور و LSR دنور نمایش داده شده است.

وب سایت توسینسو
  • نکته : ATM subinterface که در انتهای دستور آن با کلمه mpls نمایش داده شده است نشان دهنده LC-ATM subinterface در یک روتر LSR است.

به تصویر زیر توجه کنید تا ببینید چگونه می توانید وضعیت LDP روی اینترفیس ATM و استفاده از control VC 0/32 را بررسی کنید.

وب سایت توسینسو

OSPF در ATM LSRs و edge LSRs در حال اجرا است. همسایگی OSPF از طریق لینک های ATM تشکیل می شود و جدول مسیریابی براساس شبکه های موجود ایجاد می گردد. چون تمام LSR ها تنها یک loopback 0 با یک آدرس IP دارند جدول مسیریابی تنها یک شبکه را بابت هر LSR در شبکه MPLS نمایش می دهد. تصویر زیر نحوی بررسی همسایگی OSPF و جدول مسیریابی را نشان می دهد.

وب سایت توسینسو

control VC 0-32 بین تمام دستگاه ها تنظیم شده است. OSPF و LDP رو این control VC در تمام اینترفیس های ATM بین دستگاه ها در حال اجرا است. تصویر زیر نحوی بررسی وجود control VC در اینترفیس ها را نمایش می دهد.

وب سایت توسینسو

برای تغییر LDP control VC از 0-32 به یک جفت VPI-VCI دیگر می توانید از دستور زیر در اینترفیس استفاده کنید:

mpls atm control-vc vpi vci 

تصویر زیر یک مثال برای نحوی تغییر control VC برای LDP نمایش داده شده است. بدیهی است که این تنظیمات باید در هر دو LDP انجام شود.

وب سایت توسینسو

در ATM LSR شما می توانید رنج VPI-VCI که MPLS برای LVCs به ازای ATM interface استفاده می کند را تغییر دهید. مقدار پیش فرض VPI که برای MPLS استفاده می شود 1 می باشد. IOS سیسکو برای تغییر رنج VPI-VCI از دستور زیر در اینترفیس استفاده می کند :

mpls atm vpi vpi [- vpi] [vci-range low - high]

تصویر زیر نشان می دهد که مقدار VPI به 2 تغییر کرده و رنج VCI به 33-2000 تغییر کرده است.

وب سایت توسینسو

این نکته را به یاد داشته باشید که هر شبکه که در جدول مسیریابی وجود دارد یک virtual circuit از طریق شبکه ایجاد می کند. بنابراین در راستای مقایس پذیری ، بهتر است که تعداد شبکه های جدول مسیریابی را محدود کنیم. یک راه برای اینکار که بسیار توصیه می شود این است که ATM interfaces را به عنوان IP unnumbered interfaces داشته باشیم. شما به اینترفیس loopback در هر صورت به عنوان LDP router ID و IGP router ID نیاز دارید و اینترفیس های IP unnumbered می توانند به آن اشاره کنند.

زمانی که شما از IP unnumbered استفاده نمی کنید شما به هر شبکه IP که روی یک لینک تنظیم شده باشد یک label و virtual circuit اختصاص می دهید. این شبکه های بی اهمیت ترافیک را از طریق شبکه ATM ارسال نمی کنند بنابراین LVC های بلاستفاده تشکیل می شود

Downstream-on-Demand

Downstream-on-Demand Label Advertisement چیست؟ برای پرهیز از ارسال label های عیر ضروری برای شبکه ها در جدول مسیریابی ، ATM LSR در حالت Unsolicited Downstream (UD) label advertisement mode عمل نمی کند. بلکه در حالت Downstream-on-Demand (DoD) label advertisement mode عمل می کند.

به این معناست که label تنها زمانی توسط یک ATM LSR ارسال می شوند که برای آن درخواست شده باشد. LSR بالادست برای یک شبکه خاص از LSR پایین دست درخواست label می کند. LSR بالادست با توجه به جدول مسیریابی خود و next hop برای آن شبکه ، می فهمد که LSR پایین دست کدام است.

ATM LSR ( و روترها با اینترفیس LCATM) از Ordered LSP Control mode ( در بخش های قبلی مورد بحث قرار گرفت) به صورت پیش فرض استفاده می کند در حالی که روترها (non-LC-ATM interfaces) از Independent LSP Control mode استفاده می کنند.

در حالت Ordered LSP Control mode برای اینکه یک ATM LSR پایین دست یک label را به عنوان پاسخ ارسال کند باید خود این LSR از LSR پایین دست خود برای آن شبکه label دریافت کرده باشد. Egress LSR در انتهای LSP اولین (label (local را به این شبکه اختصاص می دهد و این label را به LSR بالا دست ارسال می کند. در تصویر زیر یک مثال برای ATM LSRs و DoD Label Advertisement mode با Ordered LSP Control mode نمایش داده شده است.

وب سایت توسینسو
وب سایت توسینسو

زمانی که یک شبکه جدید توسط روتر بروسل شناخته می شود روتر دنور و واشینگتون یک درخواست LDP label برای ATM LSR پایین دست خود ارسال می کنند و در خواست label برای آن شبکه را می کنند. سپس این LSR ها با دریافت این درخواست ، خود نیز به LSR پایین دست خود درخواست label برای این شبکه را می دهند. این روند ادامه پیدا می کند تا درخواست به دست edge ATM LSR بروسل برسد. این روتر label اختصاص داده شده به این شبکه را به LSR بالا دست خود ارسال می کند.

این LSR بالادست نیز این label را برای LSR بالا دست خود ارسال می کند و این روند ادامه پیدا می کند تا به edge ATM LSR برسد. در اینجا هر ATM LSR برای مقصد label binding را دارد. چون ATM LSRs در حالت DoD در حال اجرا هستند آنها تنها از next hop که در جدول مسیریابی مشخص است درخواست label می کنند. بنابراین label retention در حالت conservative برای LSR هایی که DoD label advertisement mode را اجرا کرده اند خواهد بود.

زمانیکه همسایگی مسیریابی برقرار می شود شبکه های مبادله می شوند و جدول مسیریابی در LSR ها تشکیل می شود و LDP رابطه همسایگی LDP را تشکیل می دهد و label bindings برای شبکه ها را اعلام می کند ATM LSR می تواند LVC ها بین آنها ایجاد کند.به مثال زیر توجه کنید اگر ترافیک IP بخواهد از edge LSR دنور به edge LSR بروسل ( به مقصد 10.200.253.6 ) برود ، LVC زیر را خواهیم داشت :

  • 1/42 خروجی در denver
  • 142 ورودی و 136 خروجی در denver-atm
  • 136 ورودی و 133 خروجی در brussels-atm
  • 1/33 ورودی در Brussels

برای دیدن ATM LDP bindings از دستور show mpls atm-ldp bindings استفاده کنید. در مثال زیر نحوی استفاده از این دستور برای دیدن مسیر LVCs از طریق ATM LSR نمایش داده شده است.

وب سایت توسینسو
وب سایت توسینسو

به مثال زیر توجه کنید تا اطلاعات کامل (label information base (LIB مربوط به ATM LSR دنور را ببینید. شما می توانید در جدول مسیریابی به ازای هر شبکه یک ورودی ببینید. یک ATM Switch می تواند در LSP سه موقعیت داشته باشد. tail end switch ، transit یا head end switch این سه موقعیت می باشند.

head end switch به این معناست که ATM LSR به عنوان ingress LSR است ، tail end switch به این معناست که ATM LSR به عنوان egress LSR است و transit LSR به عنوان ATM LSR های مابین ingress LSR و egress LSR در LSP می باشند.

ورودی Tailend Switch در مثال زیر به عنوان ورودی برای شبکه 10.200.253.1/32 می باشد چون این شبکه مستقیم به LSR denver-atm متصل است. یه مقدار ورودی وجود دارد چون ATM LSR denver-atm دارای سه ATM LSR بالا دست برای این شبکه است Denver ، washington-atm و brussels-atm سه ATM LSR بالادست می باشند.

وب سایت توسینسو

این LDP label bindings منجر به تنظیم LVCs در مثال زیر می شود.

وب سایت توسینسو

همینطور که می بینید label هایی که از طریق LDP فرا گرفته شده است همان مقادیر VPI/VCI هستند و VC ها به عنوان نتیجه فرا گرفتن MPLS labels در data plane تنظیم می شوند. دستور show mpls ip binding یک نمایش خوب از label bindings برای هر شبکه به ما نشان می دهد. در مثال زیر خروجی این دستور نمایش داده شده است.

وب سایت توسینسو
  • MPLS چیست و به چه دردی میخورد؟

    ام پی ال اس یا MPLS که مخفف کلمه های Multiprotocol Label Switching است یک تکنولوژی هدایت و ارسال داده است که سرعت و کیفیت انتقال داده ها را به نسبت تکنولوژی های قبل تر از خودش در زیرساخت های شبکه بالا برده است. شما در تکنولوژی MPLS به جای درگیر شدن با انبوهی از جدولهای مسیریابی در هر مرحله از عبور از روترها ، از مکانیم برچسب گذاری برای انتقال داده سریعتر استفاده می کنید.
  • MPLS در ایران چه کاربردی دارد؟

    از MPLS می توان برای راه اندازی شبکه های WAN سازمانی ، استفاده در تماس های صوتی و تصویری در بستر اختصاصی MPLS استفاده کرد

جعفر قنبری شوهانی
جعفر قنبری شوهانی

مهندس و مدرس زیرساخت و امنیت و مدیر ارشد وب سایت توسینسو

جعفر قنبری شوهانی ، مهندس و مدرس شبکه ، آشنایی من با شبکه برمی گرده به سال 1382 که دوره NT و Novel رو گذروندم و الان بیشتر از 10 ساله سابقه اجرایی در سطح Enterprise (بانک ها ، موسسه مالی ، ادارات دولتی ، سرویس پروایدر) را دارم و در حال حاضر به عنوان مهندس شبکه در شرکت توزیع برق مشهد و به عنوان مدیر ارشد و مدرس شبکه در سایت ToSinSo مشغول به کار هستم. در اکثرا حوزه های شبکه کار کردم و تجربه دارم اما تخصص اصلیم رو در حوزه زیرساخت و امنیت اون میدونم

نظرات