آزمایشگاه MPLS L3VPN پینگ نمی‌دهد؟ این پنج پرش را بررسی کنید

دو روتر مشتری، یک جفت دستگاه provider edge و یک پینگ که بدون پیام خطا می‌میرد. در یک آزمایشگاه کوچک MPLS L3VPN، ایراد تقریباً همیشه روی یکی از پنج نقطهٔ بررسی می‌نشیند و هر یک از آن‌ها فرمانی دارد که نشان می‌دهد وابستگی کار می‌کند یا غایب است. خطا این است که هر بار پینگ ناموفق می‌شود BGP را دوباره راه بیندازیم، به‌جای اینکه وابستگی‌ها را به ترتیب آزمون کنیم. اگر مستقیم به پیکربندی VRF بپرید، ممکن است یک ساعت را صرف مشکلی کنید که با یک پرش بعدی حل‌نشده در دو دستگاه آن‌سوتر آغاز شده است.

فهرست را از پایین به بالا کار کنید. نقطهٔ بررسی‌ای که می‌گذرد گذرا می‌ماند، و نخستین شکست همان چیزی است که ارزش اشکال‌زدایی دارد.

نقطهٔ بررسی نخست: PE‌ها به هم می‌رسند

هر PE به مسیری به loopback آن PE دیگر نیاز دارد، و آن مسیر باید از راه چیزی واقعی حل شود. interior gateway protocol راه معمول است، اما مسیر استاتیک هم کار می‌کند تا زمانی که جست‌وجوی بازگشتی روی یک adjacency زنده بنشیند. روی دستگاه‌های به سبک IOS، show ip route 10.0.0.2 و سپس show ip cef 10.0.0.2 نشان می‌دهد آیا پیشوند وجود دارد و آیا adjacency حل‌شده‌ای پشت آن هست. مسیری در جدول که adjacency پشت آن نیست، دسترسی‌پذیری نیست.

هر دو جهت را بررسی کنید. هزینه‌های نامتقارن IGP، passive interface در سمت اشتباه یا distribute list که loopback را پالایش می‌کند، هر یک فقط یک جهت را می‌شکند، و یک جهت برای کشتن نشست کافی است. اگر loopback‌ها پینگ می‌دهند اما نشست BGP در Active می‌ماند، پیش از دست‌زدن به هر چیز دیگر به update source نگاه کنید.

نقطهٔ بررسی دوم: مسیری از برچسب‌ها وجود دارد

یک مسیر IP به loopback دور ثابت نمی‌کند که انتقال برچسب می‌گذارد. در طراحی LDP تأیید کنید که loopback دور هم اتصال محلی و هم اتصال دور دارد و برچسب خروجی در جدول forwarding دیده می‌شود. show mpls ldp bindings 10.0.0.2 32 جفت‌های برچسب را نشان می‌دهد و show mpls forwarding-table 10.0.0.2 نشان می‌دهد line card واقعاً چه می‌گذارد. وقتی فرمان دوم هیچ برچسبی نشان نمی‌دهد یا به IP برمی‌گردد، انتقال ترافیک VPN را آن‌گونه که طراحی فرض می‌کند حمل نمی‌کند.

این تفاوت از نحوهٔ جداسازی forwarding state از پیشوندهای مقصد در MPLS می‌آید، همان مدلی که در RFC 3031 توصیف شده است. اگر آزمایشگاه شما به‌جای LDP از RSVP-TE یا برچسب‌های مجاور BGP استفاده می‌کند، وضعیت خود آن سازوکار را بررسی کنید; فرض اینکه LDP هر برچسب لایهٔ زیرین را توزیع می‌کند راه رایجی برای دنبال‌کردن یک باگ خیالی است. مسیر برچسب‌های شکسته معمولاً بعداً به‌صورت مسیر VPNی ظاهر می‌شود که وجود دارد اما بی‌فایده است.

نقطهٔ بررسی سوم: مسیر VPN سالم رسید

به مسیر VPNv4 یا VPNv6 برای پیشوند دقیق مشتری نگاه کنید، نه به خلاصهٔ نشست. show bgp vpnv4 unicast all 10.10.1.0/24 باید route distinguisher، next hop تنظیم‌شده روی loopback آن PE دور و یک برچسب را نشان دهد. اگر پیشوند غایب است، نخستین مظنون سیاست خروج روی PE مبدأ یا سیاست ورود روی PE گیرنده است، و route target‌ها مقصر معمول‌اند.

بررسی route target را جدا از دریافت BGP بخوانید. یک مسیر می‌تواند با next hop درست برسد و باز هم در VRF فرود نیاید چون importtarget مطابقت ندارد. روی PE گیرنده، show ip route vrf CUSTOMER 10.10.1.0 آزمونی است که اهمیت دارد; جدول BGP فقط ثابت می‌کند مسیر از صفحهٔ کنترل گذشته است.

نقطهٔ بررسی چهارم: interface درون VRF است

تعریف VRF با route distinguisher و route target‌ها هیچ interface‌ای را به آن منتقل نمی‌کند. interface سمت CE به تخصیص VRF نیاز دارد، و show ip vrf interfaces یا show ip interface brief باید آن را زیر نمونهٔ درست فهرست کند. این همان نقطهٔ بررسی‌ای است که پیکربندی کپی‌شده بیشترین خطا را در آن می‌کند، چون بلوک VRF کامل به نظر می‌رسد در حالی که interface هنوز در جدول سراسری نشسته است.

سپس تأیید کنید که PE پیشوند محلی مشتری را در آن VRF یاد گرفته است و CE مسیر بازگشتی از طریق اتصال دارد. یک default استاتیک روی CE که به PE اشاره می‌کند برای آزمایشگاه کافی است، به شرط اینکه VRF روی PE مسیری به LAN مشتری داشته باشد. اگر هر یک از دو نیمه غایب باشد، پینگ پیش از گذاشتن هیچ برچسبی شکست می‌خورد.

نقطهٔ بررسی پنجم: پاسخ راهی به خانه پیدا می‌کند

بستهٔ رفت و سپس بستهٔ بازگشت را ردیابی کنید، چون از جدول‌های متفاوتی استفاده می‌کنند. روی PE ورودی، مبدأ مشتری باید درون VRF به پیشوند دور با برچسب دور حل شود. روی PE خروجی، مقصد باید درون همان VRF به interface سمت CE حل شود. پینگی که از خود PE فرستاده شود مدرک نیست: ممکن است از جدول سراسری یا نشانی مبدأ دیگر بیرون برود، و به همین دلیل ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 آزمونی است که باید اجرا کنید.

فایروال‌های میزبان، reverse-path filtering و فهرست‌های دسترسی روی CE همچنان اعمال می‌شوند. اگر مسیر رفت کار می‌کند و پاسخ می‌میرد، مشکل مسیری یا پالایه‌ای در سمت بازگشت است، نه انتقال MPLS.

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