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

 

تفاوت و ویژگی های IPS و IDS

شما می توانید سنسور را به یکی از دو روش زیر برای آنالیز ترافیک در شبکه قرار دهید. روش اول استفاده در حالت inline است که در آن ترافیک شبکه باید از سنسور عبور کند که سنسور ترافیک را بررسی و سپس در صورت عدم مشکل آنرا ارسال می کند و به این ترتیب سنسور قادر است جلوی ترافیک مخرب را بگیرد. این روشی است که IPS از آن استفاده می کند. هر زمان که نام IPS را شنیدید بدانید که سنسور در مسیر جریان ترافیک قرار دارد و می تواند جلوی حملات را بگیرد. یک نکته منفی که در رابطه با IPS به خاطر inline بودن وجود دارد این است که اگر سنسور دچار مشکل شود و شما مسیر دیگر برای شبکه نداشته باشید تا زمانی که مشکل برطرف نشود کل شبکه شما دچار مشکل خواهد بود. برحسب نوع پلتفرمی که استفاده می کنید می توان سنسور را در حالت fail open تنظیم کنید که باعث می شود در صورت اینکه سنسور دچار مشکل شود کل ترافیک بدون اینکه بررسی شود شوند عبور داده شوند. همچنین می توانید سنسور را در حالت fail close تنظیم کنید که در این حالت در صورت بروز مشکل برای سنسور هیچ ترافیکی نتواند از دستگاه عبور کند. همچنین در روش inline به خاطر آنالیز ترافیک مقدار کمی تاخیر برای جریان ترافیک به وجود می آید.
حال (intrusion detection system (IDS چیست؟ برای درک IDS ، سنسور را در نظر بگیرید اما بجای اینکه دستگاه را به صورت inline در شبکه قرار دهید یک کپی از بسته های در حال عبور از شبکه را به آن ارسال می کنیم که به این حالت promiscuous گفته می شود در این روش نیز سنسور اقدام به آنالیز ترافیک می کند اما چون اصل ترافیک دست سنسور نیست نمی تواند جلوی ترافیک را بگیرد و تنها می تواند پیغام و هشدار تولید کند. به همین خاطر IDS تنها می تواند حملات را تشخیص دهد و نمی تواند جلوی این حملات را بگیرد. به صورت مختصر تفاوت بین IPS که در حالت inline قرار دارد و IDS که در حالت promiscuous قرار دارد این است که در حالت promiscuous کپی ترافیک مورد بررسی قرار می گیرد. از مزایای IDS می توان به عدم ایجاد تاخیر در ارسال ترافیک اشاره کرد و همچنین اگر برای IDS مشکل بوجود آید بروی عملکرد شبکه تاثیری به وجود نمی آید چون در مسیر ارسال ترافیک قرار ندارد. براساس عملکرد ، IDS نمی تواند اثر حملات را به صورت مستقیم کاهش دهد چون ترافیک اصلی دست آن نیست و نمی تواند مانع ورود ترافیک مخرب به شبکه شود.
تصویر زیر نحوی اجرای IDS در برابر IPS را نمایش می دهد.

Image

توانایی مقایسه و تشخیص این دو روش برای آزمون و همچنین در دنیای واقعی بسیار مهم است.

ویژگی های IDS :


  • محل قرارگیری نسبت به جریان ترافیک : در مسیر مستقیم جریان ترافیک قرار نمی گیرد و کپی ترافیک برای آن ارسال می شود.
  • حالت استقرار : promiscuous
  • تاخیر : چون در مسیر ترافیک اصلی قرار ندارد باعث تاخیر نمی شود.
  • تاثیر روی شبکه در صورت خرابی سنسور : چون اصل ترافیک در دست سنسور نیست مشکلی به وجود نمی آید.
  • توانایی در جلوگیری از ترافیک مخرب : در حالت promiscuous سنسور نمی تواند مانع عبور ترافیک شود چون اصل ترافیک را در اختیار ندارد. امکانی که وجود دارد این است که با کمک یک دستگاه دیگر مانع عبور ترافیک مخرب شود به طور مثال IDS می تواند درخواست بلاک کردن ترافیک را به یک روتر ارسال کند اما تضمینی برای جلوگیری از این حمله وجود ندارد و همینطور حداقل یک بسته از ترافیک مخرب وارد شبکه می شود سپس جلوی جمله گرفته می شود.
  • قابلیت نرمال سازی (Normalization) : چون IDS اصل بسته ها را در اختیار ندارد نمی تواند تغییری روی بسته ها انجام دهد.

 

ویژگی های IPS :


  • محل قرارگیری نسبت به جریان ترافیک : در مسیر مستقیم جریان ترافیک قرار می گیرد و ترافیک از سنسور عبور می کند.
  • حالت استقرار : inline
  • تاخیر : به دلیل اینکه اصل ترافیک را آنالیز می کند با مقدار کمی تاخیر ترافیک را ارسال می کند.
  • تاثیر روی شبکه در صورت خرابی سنسور : اگر سنسور دچار مشکل شود روی جریان ترافیک تاثیر گذاشته و ترافیک نمی تواند از سنسور عبور کند اما می توان سنسور را در حالت fail open تنظیم کرد که تاثیر منفی را کاهش داد.
  • توانایی در جلوگیری از ترافیک مخرب : IPS می تواند جلوی حملات را بگیرد چون اصل بسته ها را در دست دارد و در ابتدا بسته ها را آنالیز می کند و در صورت سالم بودن اقدام به ارسال بسته می کند.
  • قابلیت نرمال سازی (Normalization) : چون IPS اصل بسته ها را در اختیار دارد در نتیجه می تواند بسته ها را تغییر دهد.

پیاده سازی ٨٠٢.١x – بخش نهم

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

تعریف کاربران در Cisco Secure ACS :


مراحل زیر را دنبال کنید که در دیتابیس داخلی Cisco Secure ACS کاربر تعریف کنید.

  • روی گزینه User Setup در منوی سمت چپ کلیک کنید تا پنجره مربوطه باز شود.
  • یک نام منحصر به فرد در کادر User وارد کنید سپس کلید Add/Edit را بزنید تا پنجره مربوط به تنظیمات کاربر ظاهر شود.
  • در این قسمت یک پسورد برای کاربر در نظر بگیرد و همچنین آنرا عضو یک گروه کنید.
  • کلید Submit را بزنید.

در تصویر زیر بخش تنظیمات کاربر نمایش داده شده است :

Image

 

تولید فایل PAC :


این مرحله اختیاری است. اگر مسیر بین Supplicant و سرور AAA یک مسیر کاملا امن نیست پیشنهاد می شود عمل توزیع فایل PAC به صورت دستی انجام گیرد. برای اینکه اینکار به صورت دستی انجام گیرد باید در ابتدا فایل PAC باید تولید شود. در این مرحله نحوی تولید فایل PAC توضیح داده شده است به همین منظور مراحل زیر را دنبال کنید :

  • Command Prompt را در مسیر نصب Cisco Secure ACS با دسترسی Administrator باز کنید. همانند تصویر زیر :
Image

 

  • دستور CSUtil را با سوئیچ های –a و –t اجرا کنید تا فایل PAC تولید شود.
  • فایل تولید شده را روی تمام Supplicant ها کپی کنید.

نکته : اگر PAC فایل به صورت خودکار به Supplicant ها ارسال می شود این کار در طی اولین تایید هویت EAP-FAST انجام می گیرد.

تنظیم (Network Access Restrictions (NAR برای کاربران 802.1x :


این مرحله اختیاری است. اگر بخواهیم کاربر را برای تایید هویت تنها به یک RADIUS Clients محدود کنیم می توانیم از (Network Access Restrictions (NAR استفاده کنیم. در این مرحله نحوی تنظیم NAR نمایش داده شده است. برای اینکار مراحل زیر را دنبال کنید :

  • روی گزینه Group Setup از منوی سمت چپ کلیک کنید تا پنجره مربوطه باز شود.
  • گروهی که حاوی کاربر 802.1x است که می خواهیم آنرا محدود کنیم را انتخاب کنید سپس کلید Edit Settings را بزنید تا پنجره مربوطه باز شود.
  • در پنجره تنظیمات گروه به بخش Network Access Restrictions و چک باکس Define CLI/DNIS-based Access Restrictions را انتخاب کنید. در کادر AAA Client نام دستگاهی که می خواهید تایید هویت را انجام دهد را انتخاب کنید و مقدار کادر های Port ، CLI و DNIS را برابر * قرار دهید سپس کلید enter را کلیک کنید تا به لیست اضافه گردد.
  • کلید Submit + Restart را کلیک کنید.

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

Image

 

فعال کردن logging :


Cisco Secure ACS می تواند تایید هویت های موفق را نیز همانند تایید هویت های ناموفق برای کاربر را log گیری کند. Log گیری برای تایید هویت های موفق به صورت پیش فرض غیرفعال است. برای فعال کردن آن مراحل زیر را طی کنید:

  • روی کلید Network Configuration از منوی سمت چپ کلید کنید.
  • گزینه logging را انتخاب کنید تا صفحه مربوط به تنظیمات logging نمایش داده شود.
  • در جدول ACS Report روی گزینه Configure از ستون CSV و ردیف Passed Authentication کلیک کنید.
Image

 

  • در این صفحه چک باکس Log to CSV Passed Authentication Report را انتخاب کنید و کلید Submit را بزنید.

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

Image

تنظیم Cisco Secure ACS به اتمام رسیده است و در مرحله بعدی باید Supplicant تنظیم شود.

تنظیم Cisco Secure Service Client به عنوان Supplicant :


برای اینکه کلاینت برای تایید هویت از EAP-FAST استفاده کند باید (Cisco Secure Services Client (CSSC روی کلاینت نصب و تنظیم گردد. این به طور کلی شامل مراحل زیر است :

  • ساخت پروفایل CSSC Configuration با استفاده از CSSC Management Utility
  • ساخت پروفایل و Policy برای تایید هویت
  • تنظیم تایمرهای 802.1x
  • انتخاب متد تایید هویت (یوزر ، دستگاه یا هردو)
  • انتخاب متد EAP
  • ساخت پکیچ نصب CSSC حاوی Configuration Profile
  • نصب پکیچ CSSC در کلاینت

 

ساخت پروفایل CSSC Configuration با استفاده از CSSC Management Utility :


اولین مرحله ساخت پروفایل با استفاده از CSSC Management Utility است. خروجی CSSC Management Utility یک فایل XML است که شامل تنظیمات لازم برای Supplicant است. مراحل زیر را برای تنظیم پروفایل دنبال کنید :

  • CSSC Management Utility را دانلود کنید و از حالت فشرده خارج کنید سپس فایل sscManagementUtility را اجرا کنید که صفحه اصلی ظاهر شود.
  • گزینه Create New Configuration Profile را در صفحه اصلی انتخاب کنید.
Image

 

  • نسخه CSSC که می خواهید استفاده کنید را انتخاب کنید. که در اینجا ما از نسخه 5.1 استفاده می کنیم.

 

ساخت پروفایل و Policy برای تایید هویت :


در مرحله بعد یک پروفایل مربوط به شبکه کابلی در پروفایل CSSC Configuration ایجاد می کنیم. مراحل زیر را دنبال کنید :

  • اگر فقط گزینه Allow Wired انتخاب شود نیاز به لایسنس ندارد اما اگر بخواهید هر دو شبکه کابلی و وایرلس را استفاده کنید باید لایسنس را در کادر provide license وارد کنید.
  • گزینه Attempt Connection After User Login را در بخش Connection Setting انتخاب کنید.
  • گزینه Allow Wired Media را انتخاب کنید سپس کلید Next را بزنید.
Image

 

  • در صفحه Authentication Policy گزینه EAP FAST را در قسمت Allowed Authentication Modes انتخاب کنید و کلید Next را بزنید.
Image

 

  • در صفجه Network کلید Add Network را بزنید.
Image

 

  • تنظیمات مربوط به صفحه Network Media را بدون تغییر Next بزنید.
  • یک نام برای پروفایل جدید در صفحه Wired Network Settings در نظر بگیرید. در بخش Security Level گزینه authenticating network را انتخاب کنید سپس کلید Next را بزنید.
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 درخدمت شما عزیزان هستیم با ما همراه باشید.

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

Image

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

Image

 

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 برقرار است.

مکانیزم (Dynamic ARP Inspection (DAI و نحوی جلوگیری از حملات ARP spoofing و ARP poisoning

پروتکل ARP برای تبدیل آدرس IP به آدرس MAC مورد استفاده قرار می گیرد به طور مثال ، Host B می خواهد اطلاعاتی را برای Host A ارسال کند اما MAC آدرس Host A را ندارد به منظور پیدا کردن MAC آدرس Host A یک بسته Broadcast برای تمام دستگاه های آن broadcast domain ارسال می کند تا MAC آدرس مربوط به IP آدرس Host A را بدست آورد. تمام دستگاه های این broadcast domain این بسته را دریافت می کنند و Host A به آن پاسخ می دهد و MAC آدرس خود را اعلام می کند.
احتمال حمله ARP spoofing و ARP cache poisoning وجود دارد چون این امکان وجود دارد که به جای دستگاه مورد نظر مهاجم پاسخ ARP را با اطلاعات مورد نظر خود ارسال کند یا حتی ARP اجازه ارسال gratuitous ARP را می دهد که در آن MAC آدرس دستگاه اعلام می شود بدون اینکه درخواستی برای آن صادر شده باشد. بعد از این حمله ، تمام ترافیک دستگاهی که به آن حمله شده است از طریق دستگاه مهاجم جریان پیدا می کند یعنی ابتدا ترافیک به دست دستگاه مهاجم می رسد سپس از طریق دستگاه مهاجم به روتر ، دستگاه و … ارسال می شود.
حمله ARP cache poisoning می تواند ARP caches دستگاه های متصل به subnet مثل hosts ، switches و routers را آلوده کند و به این شکل ترافیک به یک دستگاه دیگر در subnet هدایت می شود. در تصویر زیر یک نمونه از این حمله نمایش داده شده است.

Image

Host A و Host B و Host C به اینترفیس های سوئیچ متصل هستند و همه آنها در یک subnet قرار دارند. IP و MAC آدرس آنها در پرانتز مشخص شده است به طور مثال Host A از IP آدرس IA و MAC آدرس MA استفاده می کند. زمانی که Host A بخواهد با Host B در ارتباط برقرار کند یک درخواست ARP برای MAC آدرس مربوط به IP آدرس IB به صورت Broadcast ارسال می کند. زمانی که سوئیچ و Host B این درخواست ARP را دریافت می کنند IP آدرس IA و MAC آدرس MA را به ARP cache خود اضافه می کنند و در اینجا IP آدرس IA به MAC آدرس MA منتسب می شود. زمانی که Host B پاسخ می دهد سوئیچ و Host A به ARP cache خود IP آدرس IB و MAC آدرس MB را اضافه می کنند.
Host C می تواند با ارسال پاسخ ARP جعلی ARP caches سوئیچ را برای Host A و Host B آلوده کند و در این پاسخ IP آدرس IA یا IB به MAC ادرس MC منتسب می شود. دستگاهی که ARP cache آن آلوده شده است از MAC آدرس MC برای ارتباط با IP های IA و IB استفاده می کند. به معناست که Host C جریان ترافیک را تغییر داده است Host C می داند که MAC آدرس مرتبط با IP آدرس های IA و IB چیست و می تواند این ترافیک را به سمت این Host ها با استفاده از MAC آدرس درست هدایت کند. به این شکل Host C خود را در بین جریان ترافیک انتقالی بین Host A و Host B قرار داده است و به عنوان یک حمله man in the middle شناخته می شود.
DAI یک ویژگی امنیتی است که اعتبار بسته های ARP را در شبکه کنترل می کند. DAI بسته های ARP که انتصاب IP به MAC آنها مشکل دارد را drop می کند. این قابلیت باعث می شود که شبکه در برابر برخی از حملات man-in-the-middle محافظت شود.
DAI اعتبار بسته های ARP را براساس دیتابیس خود مورد بررسی قرار می دهد. که این دیتابیس DHCP Snooping می باشد. اگر قابلیت DHCP snooping فعال باشد این دیتابیس تشکیل می شود. اگر بسته ARP روی اینترفیس trusted دریافت شود بدون بررسی آنرا ارسال خواهد کرد اما روی اینترفیس ها untrusted تنها در صورتی که این بسته معتبر باشد ارسال خواهد شد.
در مثال زیر تنظمیات لازم برای اجرای DAI برای کاهش اثرات این حملات نمایش داده شده است.
فعال کردن DAI برای VLAN 10 :

SW(config)#ip arp inspection vlan 10

قرار دادن اینترفیس در حالت trust :

SW(config)#interface fastethernet 0/1
SW(config-if)#ip arp inspection trust

بررسی و کنترل تنظیمات :

SW#show ip arp inspection vlan 10
SW#show ip arp inspection interfaces

پیاده سازی 802.1x – بخش هشتم

در ادامه پیاده سازی 802.1x در خدمت شما دوستان عزیز هستم :

تنظیم RADIUS Server :


در این سناریو از EAP-FAST برای پیاده سازی 802.1x استفاده می شود.EAP-FAST به عنوان یک معماری امنیتی برای حفاظت از مذاکرات EAP به وسیله تانل (Transport Layer Security (TLS می باشد. این تانل به وسیله shared secrect ایجاد می شود و به آن (Protected Access Credentials (PAC گفته می شود.
تنظیم RADIUS Server برای 802.1x شامل چندین مرحله است که به شرح زیر است :

  • تنظیم Authenticator در سرور AAA
  • تنظیم EAP-FAST در سرور AAA
  • مشخص کردن دیتابیس کاربران در سرور AAA
  • (اختیاری) تولید فایل PAC
  • (اختیاری) تنظیم (Network Access Restrictions (NAR برای کاربران 802.1x
  • فعال کردن logging

 

انتخاب بین گزینه های موجود :


قبل از اجرا ، در چند بخش باید انتخاب هایی انجام شود که به شرح زیر است :

  • نیاز به استفاده از (Network Access Restrictions (NAR وجود دارد یا خیر؟ از NAR می توان برای اعمال محدودیت هایی اضافی برای کاربران قبل از اینکه کاربر هویت آن تایید شود استفاده کرد. به طور مثال ، شما می توانید دسترسی به یک محدوده خاص از شبکه را برای کاربران مشخص کنید. زمانی که از NAR استفاده می کنید گزینه های مختلفی برای استفاده وجود دارد.
  • انتخاب نحوی تهیه فایل (Protected Access Credential (PAC از اهمیت ویژه ای برخوردار است. اگر شبکه بین سرور AAA و سوئیچ یک مسیر کاملا امن است می توانید فایل PAC را به صورت خودکار ایجاد کنید. اگر مسیر امن نیست باید فایل PAC به صورت دستی ایجاد گردد.
  • یکی دیگر از انتخاب های مهم محل قرار گیری اطلاعات کاربران می باشد. می توان از دیتابیس داخلی Cisco Secure ACS یا یک دیتابیس خارجی استفاده کرد که ACS برای تایید هویت به آن مراجعه خواهد کرد. استفاده از دیتابیس خارجی مانند اکتیو دایرکتوری باعث سهولت در مدیریت می شود و همچنین ویژگی single sign-on برای کاربر فعال می شود.

 

تنظیم Cisco Secure ACS :


کلاینت هایی که پورت های سوئیچ متصل هستند نیاز به تایید هویت دارند. یوزر و پسورد با استفاده EAP-MSCHAPv2 توسط تانل EAP-FAST با سرور AAA تایید هویت انجام می شود. Authenticator که IOS سیسکو را اجرا کرده است و IP آدرس 192.168.1.1 به عنوان Management IP برای آ« مشخص شده است. VLAN 100 برای guest network استفاده می شود و تنها دسترسی به شبکه اینترنت در آن فراهم شده است. از Cisco Secure ACS 4.2 به عنوان RADIUS Server استفاده می شود که روی Windows Server با IP آدرس 10.1.1.1 اجرا شده است.

تنظیم Authenticator در ACS :


برای اینکه Cisco Secure ACS کلاینت های را تایید هویت کند باید Authenticator به عنوان یک AAA Client در ACS تعریف شود. مراحل زیر را برای تعریف یک Authenticator به عنوان AAA Client در ACS دنبال کنید :

  • مرحله 1 : از پنل سمت چپ ACS روی گزینه Network Configuration کلیک کنید.
  • مرحله 2 : روی کلید Add Entry زیر جدول AAA Client کلیک کنید.
  • مرحله 3 : یک نام در کادر AAA Client Hostname برای سوئیچ وارد کنید.
  • مرحله 4 : IP آدرس سوئیچ را در کادر AAA Client IP Address وارد نمایید.
  • مرحله 5 : مقدار کادر Key را برابر مقداری که در سوئیچ به عنوان key برای RADIUS Server در نظر گرفته اید قرار دهید.
  • مرحله 6 : از لیست Authenticate Using گزینه RADIUS (Cisco IOS/PIX) را انتخاب کنید.
  • مرحله 7 : روی کلید Submit + Restart کلیک کنید.

در تصویر زیر یک AAA Client با نام AP و IP آدرس 10.0.0.106 با کلید sharedsecret به Cisco Secure ACS اضافه شده است. نوع ارتباط بین Cisco Secure ACS و سوئیچ را (RADIUS (Cisco IOS/PIX تعیین شده است.
نکته : اگر Authenticator را به عنوان AAA Client در Cisco Secure ACS اضافه نکنید درخواست های تایید هویت که توسط Authenticator به Cisco Secure ACS ارسال شوند پاسخ داده نخواهند شد.

Image

 

تنظیم EAP-FAST در Cisco Secure ACS :


بخش دوم تنظیمات Cisco Secure ACS به فعال کردن EAP-FAST اختصاص دارد. مراحل زیر را برای فعال کردن EAP-FAST در ACS دنبال کنید :

  • مرحله 1 : از پنل سمت چپ ACS گزینه System Configuration را انتخاب کنید.
  • مرحله 2 : روی گزینه Global Authentication Setup کلید کنید.
  • مرحله 3 : روی گزینه EAP-FAST Configuration کلیک کنید و در صفحه باز شده چک باکس Allow EAP-FAST را انتخاب کنید تا EAP-FAST فعال شود.
  • مرحله 4 : در کادر Authority ID Info یک نام منحصربه فرد وارد کنید. در اینجا نام Cisco برای آن در نظر گرفته شده است.
  • مرحله 5 : اگر مسیر برای انتقال فایل PAC امن است چک باکس Allow Anonymous In-band PAC Provisioning را انتخاب کنید در غیر اینصورت این گزینه را انتخاب نکنید و به صورت دستی انتقال فایل PAC را انجام دهید.
  • مرحله 6 : در قسمت Allowed inner methods گزینه EAP-MSCHAPv2 را انتخاب کنید.
  • مرحله 7 : روی کلید Submit + Restart کلیک کنید.
Image

 

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 انجام نخواهد شود و تنها از یکی از این لینک ها استفاده خواهد شد. که باعث می شود از تمام توان شبکه استفاده نشود.