چرا یک L2VPN در Junos برچسب نشان می‌دهد اما چیزی را عبور نمی‌دهد

گزارش‌های مشتریان می‌رسد که می‌گویند اتصال L2VPN در وضعیت Up است، اتصال‌دهنده بالا است و هیچ فریمی عبور نمی‌کند. چراغ‌های وضعیت صادق‌اند؛ فریم در سرویسی دسته‌بندی می‌شود که در انتهای دور هیچ وضعیت ارسال قابل‌استفاده‌ای ندارد. در یک L2VPN نقطه‌به‌نقطه با سیگنال‌دهی BGP، نخستین تصمیم به اتصال‌دهنده تعلق دارد، نه به جست‌وجوی مسیر. فریم مشتری روی یک رابط منطقی می‌رسد و آن رابط نام اتصال و در نتیجه سایت دور را می‌آورد. هر چیزی پس از آن وضعیت ارسال مبتنی بر برچسب است که از آنچه همتاها اعلام کرده‌اند ساخته شده است.

فریم هرگز جست‌وجوی مسیر انجام نمی‌دهد

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

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

دو برچسب، دو جهت

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

show l2vpn connections instance CUST-A extensive

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

جست‌وجوی برچسب چه چیزی را اثبات می‌کند

وقتی مقدار ورودی را داشته باشید، جست‌وجوی محلی یک فرمان است:

show route label 160042

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

یک فریم را دنبال کنید

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

کپسوله‌سازی اتصال‌دهنده، تنظیم کلمه کنترل و MTU را همزمان بررسی کنید، چون این‌ها ویژگی‌های مذاکره‌شده‌اند نه رفتار هر گام.

مدل‌های سرویس را جدا نگه دارید

VPLS آدرس‌های MAC را یاد می‌گیرد و EVPN نقاط پایانی را اعلام می‌کند، در حالی که L2VPN نقطه‌به‌نقطه هیچ‌یک را انجام نمی‌دهد، بنابراین رویه‌های انتخاب فریمشان قابل‌تعویض نیستند هرچند بر همان زیرساخت BGP و MPLS سوار می‌شوند. برداشتن یک گام عیب‌یابی از یک مدل به مدل دیگر، نتیجه‌های مطمئن اما بی‌پایه تولید می‌کند.

برای مسیری که وجود ندارد، وضعیت اتصال هر دو همتا، اتصال‌دهنده، هر دو جهت برچسب، کپسوله‌سازی، تنظیم کلمه کنترل و MTU را ثبت کنید. آن ثبت آنچه اعلام شده را به آنچه سطح ارسال واقعاً انجام می‌دهد پیوند می‌دهد، که تنها پیوند مهم است و همان چیزی است که مهندس بعدی خواهد پرسید.