دو تیم می‌توانند هم‌زمان درست بگویند وقتی مشتری گزارش می‌دهد که VPN قطع است و تیم حمل‌ونقل گزارش می‌دهد که تونل سالم است. یک LSP مهندسی‌شده ترافیک و یک MPLS L3VPN به پرسش‌های متفاوتی پاسخ می‌دهند: یکی بسته‌های برچسب‌دار را در هسته جابه‌جا می‌کند، دیگری تصمیم می‌گیرد بسته به کدام بافت مسیریابی تعلق دارد. وقتی این دو با هم اشتباه گرفته شوند، بحث دور می‌زند، چون هر طرف شیء متفاوتی را اندازه می‌گیرد و هر دو اندازه‌گیری معتبرند.

بالا بودن حمل‌ونقل و پایین بودن سرویس وضعیتی عادی است

یک LSP می‌تواند برپا باشد، ترافیک ببرد و در هر سامانه پایشی دیده شود، در حالی که سرویس مشتری غیرقابل‌استفاده بماند. هیچ چیز در این ترکیب متناقض نیست، چون تونل نظری درباره وجود یک پیشوند دوردست، پذیرش آن توسط سیاست ورود یا عبور فریم‌ها از مدار اتصال ندارد.

نشانه‌ای که معمولاً این سردرگمی را آشکار می‌کند نامتقارن است: پینگ از loopback تجهیز PE موفق می‌شود، در حالی که میزبان شبکه LAN مشتری چیزی دریافت نمی‌کند، یا برعکس. پیش از ساختن نظریه، بنویسید کدام نشانی‌ها کار کردند. وقتی متوجه شدید که دو شیء متفاوت را آزمون می‌کنید، گام بعدی خواندن پشته برچسب است، نه بحث درباره اینکه گراف چه کسی درست است. دو نشانی، دو مالک و معمولاً دو آدم متفاوت که هر یک باور دارد آن یکی چیزی را خراب کرده است.

پشته را دو مسئولیت بخوانید

برچسب پایین به سرویس و برچسب بالا به مسیر تعلق دارد. RFC 4364 توالی را ساده توصیف می‌کند: نخست برچسب مسیر VPN اعمال می‌شود، سپس آن بسته برچسب‌دار به سمت گام بعدی BGP تونل می‌شود و آنجاست که تونل مهندسی ترافیک برچسب خودش را روی آن می‌گذارد.

ObjectDecision it encodesWho owns it
Attachment and VRFWhich customer context receives the arriving packetEdge configuration
VPN route and service labelWhich remote forwarding context handles the destinationBGP VPN signalling
Transport LSP and tunnel labelHow the core carries the packet to the BGP next hopRSVP-TE or another tunnel mechanism

در PE دوردست، برچسب سرویس نحوه برخورد را انتخاب می‌کند که می‌تواند جست‌وجو در VRF یا تصمیم اتصال باشد. آن برچسب را نمی‌توان با برچسبی که فقط از هسته می‌گذرد عوض کرد، و این دو حتی وقتی هر دو در یک پشته روی یک واسط ظاهر شوند، جایگزین یکدیگر نیستند.

موفقیت RSVP چه چیزی را اثبات می‌کند و چه چیزی را نه

RSVP-TE مسیرهای LSP با مسیریابی صریح، با یا بدون رزرو منابع، برپا می‌کند که تضمینی مشخص و سودمند درباره مسیری است که بسته در هسته طی می‌کند. این یک گزاره درباره مسیرهای مشتری نیست و نام تونل پیکربندی‌شده به‌هیچ‌وجه مسیر نیست.

حضور RSVP هم وعده کارایی سرتاسری نمی‌دهد. رزرو پهنای باند روی یک LSP هیچ چیزی درباره مدار اتصال، خط دسترسی خود مشتری یا رفتار صف‌بندی در لبه دور نمی‌گوید. برخورد با آن به‌عنوان تضمین، پاسخ‌های مطمئن به پرسش‌هایی می‌دهد که کسی نپرسیده است. اگر نیاز واقعاً تعهد پهنای باند باشد، باید از قطعه‌هایی ساخته شود که واقعاً چنین تعهدی را اعمال می‌کنند، و LSP تنها میانه این زنجیره است.

به ترتیب بررسی کنید، سپس متوقف شوید

از حمل‌ونقل به سمت بیرون کار کنید و در نخستین گامی که شکست می‌خورد بایستید، چون هر گام بعدی فرض می‌کند گام‌های پیشین برقرار مانده‌اند. نخست تأیید کنید که LSP برپاست و ورودی ارسال برای پیشوند سرویس واقعاً به آن اشاره می‌کند. سپس تأیید کنید که مسیر VPN در جدول درست وجود دارد، اتصال برچسب آن حاضر است و سیاست ورود آن را پذیرفته است. سپس اتصال را تأیید کنید: واسط، کپسوله‌سازی و در جایی که کاربرد دارد، شناسه VLAN که به آن قرارداد تعلق دارد.

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

نحو دستورها بسته به سکو متفاوت است، پس آن چهار خط را چهار پرسش بدانید نه یک اسکریپت. بخش مهم این است که هر یک شیء متفاوتی را بازپرسی می‌کند و همین باعث می‌شود شکست به مالک مشخصی اشاره کند.

یک درخواست مجاز را دنبال کنید و شواهد خوب را نگه دارید

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

وقتی مرحله‌ای در ادامه شکست می‌خورد، مشاهده موفق LSP را حفظ کنید، نه اینکه حمل‌ونقل را از نو بسازید. ساختن دوباره یک تونل سالم نمی‌تواند پیشوند دوردست غایب، اتصال VRF نادرست یا قاعده دسترسی مقصد را اصلاح کند و شواهدی را نابود می‌کند که در ابتدا به شما گفته بود حمل‌ونقل سالم است.

مقالات مرتبط