مهندسی ترافیک در شبکه های MPLS که MPLS Traffic Engineering گفته می شود، در آن Fast Reroute و Node Protection، حفاظت از لینک و Node را بر عهده دارند. مهندسی ترافیک حفاظت از لینک را با عبور Backup Tunnelها از یک لینک Label-Switched Path یا LSP واحد و حفاظت از Node را با عبور Backup Tunnelها از Nodeهای Hop بعدی در طول LSPها، فراهم می‌کنند.
ویژگی‌های MPLS Traffic Engineering Fast Reroute و Node Protection
- پشتیبانی از Backup Tunnel
- حفاظت از پهنای باند Backup
- پروتکل Resource Reservation Protocol (RSVP) Hellos
بررسی مفاهیم کاربردی در MPLS Traffic Engineering
درک مفاهیم زیر برای پیکربندی MPLS Traffic Engineering ،Fast Reroute و Node Protection لازم است:
Fast Reroute یا مسیریابی مجدد سریع چیست؟
Fast Reroute یا FRR مکانیزمی است برای حفاظت از LSPهای MPLS Traffic Engineering در مقابل خرابی‌های Link و Node. این کار با ترمیم LSPها در نقطه‌ی خرابی به صورت Local انجام می‌شود و این توانایی را ایجاد می‌کند که وقتی Headendهای روتر آن‌ها سعی در ایجاد LSPهای End-To-End دارند تا جایگزین آن‌ها شوند، داده‌ها کماکان در آن‌ها جریان داشته باشند. FRR با تغییر مسیر LSPهای حفاظت شده ازBackup Tunnelهایی که از لینک یا Node خراب عبور می‌کنند، به صورت Local آن‌ها را ترمیم می‌کند.
برای مشاوره رایگان و یا طراحی و اجرای زیرساخت شبکه و SDWAN با کارشناسان شرکت APK تماس بگیرید. |
Link Protection چیست و چگونه از LSPها محافظت می کند؟
Backup Tunnelهایی که فقط از یک لینک واحد از مسیر LSPها عبور می‌کنند، سبب حفاظت از لینک می‌شوند. آن‌ها در صورت از کار افتادن لینکی که در مسیرشان قرار دارد، با تغییر مسیر ترافیک LSP به Hop بعدی، از LSPها محافظت می‌کنند (عبور از لینک خراب). این Backup Tunnelها، Next-Hop (NHOP) نامیده می‌شوند، زیرا در Next-Hop متعلق به LSP بعد از نقطه خرابی خاتمه می‌یابند. شکل زیر یک Backup Tunnel NHOP را نشان می‌دهد.
Node Protection یا حفاظت از Node در مسیرهایی که Node از کار افتاده است
FRR حفاظت از Node را برای LSPها فراهم می‌کند. Backup Tunnelها که در طول مسیر LSP، از Nodeهای Hop بعدی عبور می‌کنند، Backup Tunnelهای Next-Next-Hop یا NNHOP نامیده می‌شوند. در Next-Hop Node مسیرهای LSP خاتمه می‌یابند و درنتیجه از Next-Hop Node عبور می‌کنند. اگر Nodeی در مسیر آن‌ها از کار بیفتد، با فعال کردن Node Upstream خرابی برای تغییر مسیر LSPها و ترافیک آن‌ها در مسیر Node از کارافتاده به Next-Next-Hob، از LSPها محافظت می‌کنند. FRR برای تسریع در تشخیص خرابی Node، استفاده از RSVP Helloها را پشتیبانی می‌کند. Backup Tunnelهای NNHOP از خرابی‌های لینک نیز محافظت می‌کنند، زیرا از لینک خراب و Node عبور می‌نمایند. شکل زیر NNHOP Backup Tunnel را نشان می‌دهد.
اگر در زمان استفاده‌ی LSP از Backup Tunnel تغییراتی ایجاد شود به طوری که LSP دیگر برای Backup Tunnel مناسب نباشد، LSP از کار خواهد افتاد. این تغییرات به شرح زیر است:
• پهنای باند Backup از Backup Tunnel کاهش یابد.
• پهنای باند پشتیبانِ Backup Tunnel به نوعی تغییر یابد که با LSP اولیه ناسازگار باشد.
• LSP اولیه به گونه‌ای تغییر یابد که FRR غیرفعال شود (دستور no mpls Traffic-eng fast-reroute وارد شود).
حافظت از پهنای باند
از Backup Tunnelهای NHOP و NNHOP میتوان برای محافظت از پهنای باند LSPهای تغییر مسیر یافته استفاده کرد که به آن پهنای باند Backup گفته می‌شود. میتوان پهنای باند Backup را با Backup Tunnelهای NHOP یا NNHOP مرتبط کرد. این امر، میزان پهنای باند Backupی که یک Backup Tunnel خاص می‌تواند از آن محافظت کند را به روتر اطلاع می‌دهد. هنگامی که روتر LSPها را به Backup Tunnelها Map می‌کند، حفاظت از پهنای باند موجب می‌شود که LSP فقط در صورت وجود حفاظت کافی از پهنای باند Backup، از Backup Tunnel مشخص شده، استفاده کند. روتر انتخاب می‌کند که LSPها از کدام Backup Tunnelها استفاده کنند تا حداکثر حفاظت از پهنای باند را داشته باشند. یعنی روتر بهترین روش را برای Map کردن LSPها روی Backup Tunnelها تعیین می‌کند تا تعداد LSPهای قابل محافظت را به حداکثر برساند.
LSPهایی که مجموعه بیت حفاظت از پهنای باند مورد نظر را دارند از شانس بیشتری در انتخاب Backup Tunnelهایی که از پهنای باند محافظت می‌کنند، برخوردار هستند و این بدین معنی است که این LSPها می‌توانند نسبت به LSPهای دیگری که آن مجموعه بیت را ندارند، حق تقدم داشته باشند.
عملیات RSVP Hello و کمک به تشخیص خرابی Node-To-Node
RSVP Hello ،Nodeهای RSVP را قادر می‌سازد تا غیر قابل دسترس بودن Neighboring Node را تشخیص دهند. این امرتشخیص خرابی Node-To-Node را نیز ممکن می‌سازد. وقتی چنین خرابی تشخیص داده شود، به روشی مشابه با خرابی Link-Layer Communication مدیریت می‌شود.
در صورت عدم اطلاع از خرابی Link-Layer (برای مثال با Ethernet) یا زمانی که مکانیسم‌های تشخیص خرابی ارائه شده توسط Link-Layer برای تشخیص به موقع خرابی Node کافی نباشد، FRR می‌تواند از RSVP Hello استفاده کند.
Nodeی که با Hello اجرا می‌شود، یک درخواست Hello به Neighboring Node ارسال می‌کند. اگر Node دریافت کننده Hello را اجرا کند، با Hello Ack پاسخ می‌دهد. اگر چهار دوره‌ی زمانی بگذرد و Node ارسال کننده Ack دریافت نکند یا پیام بدی دریافت کند، Node ارسال کننده اعلام می‌کند که Neighbor قطع است و FRR را مطلع می‌سازد.
دو پارامتر قابل تنظیم عبارت‌اند از:
- دوره‌ی زمانی Hello با استفاده از دستور ip rsvp signalling hello refresh interval
- تعداد پیام‌های تصدیق که قبل از اینکه Node ارسال شده دریابد که Neighbor از کار افتاده، به آن‌ها پاسخی داده نشود میتوان ازدستور ip rsvp signalling hello refresh misses استفاده کرد.
بررسی Hello Instance در MPLS Traffic Engineering
یک Hello Instance ،RSVP Hello را برای روتر و IP Address Remote معینی پیاده سازی می‌کند. به همین علت تعداد زیادی درخواست Hello فرستاده می‌شوند و این امر ببار زیادی را بر روتر تحمیل می نماید. بنابراین، فقط در صورت لزوم باید Hello Instance را ایجاد کرد و در صورت عدم نیاز باید آن را حذف نمود.
انواع Hello Instance
Active Hello instance
زمانی که LSP برای تغییر مسیر سریع آماده است، اگر Neighbor غیرقابل دسترسی باشد، به یک Active Hello instance نیاز است. در این حالت باید یک Active Hello instance با حداقل یک LSP برای هر Neighbor ایجاد شود.
Active Hello instanceها به صورت دوره‌ای پیام‌های درخواست Hello را ارسال می‌کنند و برای پاسخ، انتظار پیام‌های Hello Ack را دارند. اگر پیام Ack مورد انتظار دریافت نشود، Active Hello instance اعلام می‌کند كه Neighbor یا همان Remote IP Address، غیرقابل دسترسی یا Lost شده است. LSPهایی که از آن Neighbor عبور می‌کنند ممکن است به سرعت تغییر مسیر پیدا کنند.
اگر یک Hello Instance بدون LSP برای Neighbor غیرقابل دسترسی موجود باشد، Hello Instance نباید حذف شود. Active Hello instance باید به یک Hello Instance از نوع Passive تبدیل شود، زیرا ممکن است یک Active Hello instance در روتر Neighbor وجود داشته باشد که درخواست Hello را به این نمونه ارسال کند.
Passive Hello instance
Hello Instanceهای Passive با ارسال پیام‌های Ack به پیام‌های در خواست Hello پاسخ می‌دهند، اما ارسال پیام‌های درخواست Hello را شروع نمی‌کنند و باعث تغییر مسیر سریع LSP نمی‌شوند. روتر با چندین رابط می‌تواند چندین Hello Instance را برای Neighborهای مختلف یا برای یک Neighbor اجرا نماید.
Instance Hello از نوع Passive وقتی ایجاد می‌شود که یک درخواست Hello از یک Neighbor با جفتِ آدرس IP مبدأ و IP آدرس مقصد در IP Header دریافت می‌شود که Instance Helloی برای آن وجود ندارد. در صورت عدم دریافت پیام Hello برای این Instance درعرض 10 دقیقه، passive instances باید حذف شود.
