نوشته‌ها

MPLS چگونه کار می کند؟ – بخش بیستم

در ادامه سری مقالات MPLS درخدمت شما عزیزان هستیم با ما همراه باشید.

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 می شوند.

Image

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 ارسال نمی کند.

MPLS چگونه کار می کند؟ – بخش نوزدهم

در ادامه سری مقالات MPLS درخدمت شما عزیزان هستیم با ما همراه باشید.

شما نمی توانید روی 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 ارسال می کند.

Image

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

Image

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

Image

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

Image

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

Image

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 ها را ارسال کند.

Image

 

فیلترکردن 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 ها است که در قسمت قبلی توضیح داده شد.

Image

 

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 فعال شده است.
Image

 

MPLS چگونه کار می کند؟ – بخش هجدهم

در ادامه سری مقالات MPLS درخدمت شما عزیزان هستیم با ما همراه باشید.

وضعیت زمان 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 را تنها به روترهای خاص می دهد.

Image

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

Image

 

Image

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

Image

 

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 را پاک کنید.

MPLS چگونه کار می کند؟ – بخش شانزدهم

در ادامه مباحث MPLS در خدمت شما عزیزان هستیم.

تعداد 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 نمایش داده شده است.

Image

برای همه لینک های 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 نیویورک نمایش داده شده است.

Image

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

Image

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

Image

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

Image

تصویر بالا یک مثال برای ساخت 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 دریافت می کند حتی اگر روتر لندن صاحب این شبکه باشد.

Image

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

Image

MPLS چگونه کار می کند؟ – بخش پانزدهم

در ادامه سری مقالات MPLS در خدمت شما عزیزان هستیم.

برقراری ارتباط 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 ثانیه ای ارسال می شوند.

Image

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

Image

ارتباط 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 تغییر داده شده است.

Image

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

Image

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

MPLS چگونه کار می کند؟ – بخش چهاردهم

در ادامه سری مقالات MPLS در خدمت شما دوستان عزیز هستیم.

LDP Operation :


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

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


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

Image

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 را اجرا کرده اند می باشد. در تصویر زیر خروجی دستور فوق نمایش داده شده است :

Image

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

Image

برای تغییر زمان بین ارسال بسته های 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 می باشد.

Image

 

MPLS چگونه کار می کند؟ – بخش سیزدهم

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

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 به صورت دقیق تر و عمیق تر مورد بررسی قرار گیرد.
به تصویر زیر توجه کنید این شبکه در این بخش مورد استفاده قرار می گیرد :

Image

 

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 باشید.

MPLS چگونه کار می کند؟ – بخش دوازدهم

با یک مقاله دیگه از سری مقالات MPLS در خدمت شما دوستان عزیز هستیم:

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 را به ازای هر شبکه در تصویر زیر می بینید.

Image

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 و یا مشکلات مسیریابی اشاره کرد.

MPLS چگونه کار می کند؟ – بخش دهم

با یک مقاله دیگه از سری مقالات MPLS در خدمت شما دوستان عزیز هستیم:

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 است :

Image

در تصویر بالا دو فرمت خروجی وجود دارد که 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 نمایش داده شده است:

Image

 

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 نمایش داده شده است :

Image

 

رفتار 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 نشان داده شده است :

Image

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

MPLS چگونه کار می کند؟ – بخش نهم

با یک مقاله دیگه از سری مقالات MPLS در خدمت شما دوستان عزیز هستیم:

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 در نظر می گیرد.

Image

اگر یک شبکه از طریق مجموعه ای از مسیرهای با مکانیزم 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 در یک اینترفیس استفاده می شود.

Image

 

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 در نظر گرفته می شود. نمونه آنرا در تصویر زیر می بینید.

Image

نکته : در 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 گفته می شود.