آیا VPNv4 به MPLS در هسته نیاز دارد؟ لزوماً نه
BGP VPNv4 یک زمینه توزیع مسیر را مذاکره میکند، نه مسیر ارسال را. واردکردن، حل هپ بعدی و کپسولهسازیای را که میتوانید اجرا کنید جدا کنید.
فعالکردن خانواده آدرس VPNv4 بین دو روتر تنها یک زمینه توزیع مسیر میسازد و بس. نه مسیر ارسالی نصب میکند و نه میگوید کدام کپسولهسازی بسته مشتری را به نقطه پایانی دور میبرد. وقتی این دو واقعیت جدا شوند، پرسش «آیا این در هسته به MPLS نیاز دارد» به پرسشی باریکتر و پاسخپذیر درباره صفحه دادهای که پلتفرم پشتیبانی میکند تبدیل میشود.
خانواده آدرس در واقع چه چیزی را مذاکره میکند
BGP چندپروتکلی اطلاعات دسترسی لایه شبکه VPNv4 را زیر AFI 1 و SAFI 128 حمل میکند و هر ورودی یک متمایزکننده مسیر را با یک پیشوند و یک برچسب جفت میکند. نشست مذاکره میکند که هر دو طرف میتوانند آن اطلاعات را رمزگذاری و رمزگشایی کنند. آنچه مذاکره نمیکند صفحه داده است. هر چیزی پس از این بند به ارسال مربوط است و هیچیک از آنها با بالا آمدن نشست روشن نمیشود.
پس یک نشست موفق شاهدی بر توانایی صفحه کنترل است، نه ارسال. یک روتر میتواند هزاران ورودی VPNv4 را نگه دارد و باز هم هر بسته مشتری را دور بریزد، و همین است که این دو دسته خرابی از ابتدا با هم اشتباه گرفته میشوند.
به برچسب در NLRI توجه کنید. این یک برچسب سرویس است که به پیشوندی درون VRF بسته شده و هنگامی که بسته به نقطه پایانی خروجی برسد نقش ارسالی دارد. اینکه هیچ دستگاه عبوری آن را بخواند یا نه، تصمیم طراحی جداست.
دریافت، واردکردن و ارسال سه گام هستند
دریافت یک مسیر، اجازه استفاده از آن و توانایی ارسال با آن را بخشهای مختلف دستگاه انجام میدهند. BGP آنچه را میشنود ذخیره میکند؛ سیاست واردکردن و تطبیق هدف مسیر تعیین میکند کدام VRF میتواند آن را در نظر بگیرد؛ سپس صفحه ارسال باید هپ بعدی اعلامشده را به چیزی تبدیل کند که واقعاً بتواند روی سیم بفرستد.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
درست همین گام میانی است که شگفتانگیزترین خرابیها در آن زندگی میکنند. مسیر میتواند در جدول BGP حاضر، معتبر و حتی بهترین باشد، درحالیکه جدول مسیر VRF خالی میماند چون هیچ هدف مسیری با فهرست واردکردن تطبیق نکرده است. هیچ چیز خطای پروتکل ثبت نمیکند، چون هیچ خطای پروتکلی رخ نداده است.
گام آخر جایی است که پشتیبانی پلتفرم خود را نشان میدهد. هپ بعدیای که در لایه زیرین قابل دسترسی است بهطور خودکار بهعنوان انتقال سرویس VPN حل نمیشود و دستگاه ممکن است نوع تونل مشخص، عملیات برچسب مشخص یا هر دو را بخواهد. خواندن وضعیت حل شدن از خواندن تعداد مسیرها آگاهانهتر است.
یک هسته IP میتواند پشتهای را حمل کند که هرگز آن را سوئیچ نمیکند
تمایزی که ارزش نگهداشتن دارد میان «هسته MPLS اجرا نمیکند» و «هیچ برچسبی در هیچ کجای سرویس وجود ندارد» است. اینها ادعاهای متفاوتی هستند و تنها اولی درباره دستگاههای عبوری است. RFC 4023 حمل MPLS از طریق تونلهای IP یا GRE را تعریف میکند و همین سازوکار است که ادعای دوم را روی هستهای کاملاً IP ممکن میکند.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningful
روترهای عبوری بر اساس مقصد IP بیرونی ارسال میکنند و نه به پیشوندهای مشتری نیاز دارند و نه به سوئیچ برچسب بومی. در انتهای دور، تونل بیرونی برداشته میشود و برچسب سرویس کار خود را از سر میگیرد. هسته یک بار مفید مبهم جابهجا کرد، که دقیقاً همان کاری است که شبکه IP در آن خوب است.
آنچه این طراحی به شما نمیدهد یک تضمین جهانی است. این اثبات آن نیست که هر روتر هر هپ بعدی VPNv4 را از هر رابط GRE حل میکند، و دلیلی برای حذف یک پیکربندی MPLS بومی کارآمد نیست. این یک مثال نقض برای ادعای جهانی است و پرسش عملی محلی پلتفرم میماند. آن پرسش را بهعنوان محدودیت پلتفرم ثبت کنید نه قاعده پروتکل.
زنجیره را روی دستگاه قدم بزنید تا بشکند
از مسیر دریافتشده شروع کنید و در نخستین گامی که شکست میخورد بایستید، زیرا گامهای بعدی تا زمانی که گام پیشین شکسته است قابل تشخیص نیستند. چهار فرمان بیشتر آن را در یک پیادهسازی معمول پوشش میدهد.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A
آنها را بهعنوان یک توالی بخوانید نه چهار بررسی مستقل. نخستین تأیید میکند که خانواده فعال است و همتا مسیرها را مبادله میکند؛ دومی نشان میدهد آیا پیشوند با هپ بعدی قابل استفاده رسیده است؛ سومی شایستگی واردکردن را اثبات میکند؛ چهارمی نشان میدهد آیا صفحه ارسال برچسب یا تونلی به آن بسته است.
سپس مسیر بار کاری را در هر دو جهت بیازمایید، با MTU ای که کپسولهسازی را تحمل کند. GRE بایتهای سرآیند اضافه میکند و مسیری که کاوشهای کوچک را میگذراند ممکن است در بستههای اندازه کامل فقط در یک جهت شکست بخورد، که مانند نقص برنامه به نظر میرسد نه انتقال.
دو یادداشت عملیاتی حلقه را میبندند. GRE کپسولهسازی است، نه محرمانگی، بنابراین یک شبکه عبوری غیرقابل اعتماد به یک ترتیب امنیتی پشتیبانیشده در بالا نیاز دارد نه یک فرض. و پیش از بازبینی طراحی ثبت کنید پلتفرم واقعاً کدام کپسولهسازی را پشتیبانی میکند، چون همان یک پاسخ تعیین میکند که هسته فقط IP یک انتخاب معتبر است یا طرحی که نمیتواند ارسال کند.