چرا L2VPN شما LSP مبتنی بر RSVP-TE را که همین حالا ساخته‌اید نادیده می‌گیرد

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

یکی برچسب یک سرویس را نام می‌برد، دیگری بسته را جابه‌جا می‌کند

برچسب pseudowire که با LDP هدفمند علامت‌دهی می‌شود و در RFC 4447 توصیف شده است، به لبه ارائه‌دهنده گیرنده می‌گوید کدام مدار اتصال باید فریم را دریافت کند. درباره این‌که فریم چگونه به آنجا رسیده چیزی نمی‌گوید. برچسب زیرین به انتقال تعلق دارد و آن پشته را هر چیزی می‌سازد که دسترس‌پذیری را برای loopback همتا اعلام کرده باشد، خواه LDP باشد، خواه RSVP-TE یا مسیری هدایت‌شده با قطعه. چون دو لایه را پروتکل‌های متفاوت علامت‌دهی می‌کنند، ممکن است یکی سالم و دیگری کهنه باشد. همین جدایی تمام سرچشمه سردرگمی است.

ارزش دارد صریح گفته شود: pseudowire خودش LSP را انتخاب نمی‌کند. فریم را به انتقال می‌سپارد و انتقال بر پایه آدرس مقصدی که گرفته تصمیم می‌گیرد.

به همین دلیل هم یک ping پاک از روی LSP جدید چیز بسیار کمی را ثابت می‌کند. ممکن است LSP فعال، برچسب‌دار و حامل سرویس‌های دیگر باشد، در حالی که pseudowire شما همچنان از یک گام بعدی دیگر تجزیه می‌شود. تا زمانی که پیوند را نخوانید، این دو واقعیت به هم مربوط نیستند.

گزینه الف: pseudowire را به انتقالی برگزیده قفل کنید

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

هزینه‌اش دامنه است. خط‌مشی‌ای که روی آدرس یک همتا منطبق می‌شود بر هر سرویسی که به آن همتا اشاره دارد اثر می‌گذارد، نه فقط بر pseudowire‌ای که در ذهن داشتید.

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

گزینه ب: بگذارید IGP انتخاب کند و ببینید چه می‌شود

رها کردن سرویس طراحی مشروعی است و اغلب بهتر. pseudowire همان تجزیه‌ای را دنبال می‌کند که هر ترافیک دیگری به loopback همتا دارد، پس همگرایی IGP، سرکوب پیشوند و هر افزونگی‌ای را که هسته از پیش عرضه می‌کند به ارث می‌برد. خط‌مشی کمتر یعنی جاهای کمتری که یک تطابق کهنه در آن پنهان شود. معامله این است که دیگر کنترل نمی‌کنید سرویس کدام مسیر را می‌رود، فقط این را که مسیری وجود دارد.

چندمسیری با هزینه برابر این معامله را بیش از آنچه در نگاه اول به نظر می‌رسد تیز می‌کند. درهم‌سازی بر پایه جریان است، پس دو گفت‌وگو درون یک pseudowire می‌توانند با برچسب‌های بیرونی متفاوت خارج شوند.

پیش از اعتماد به هر یک، ارسال نصب‌شده را بخوانید

با آدرس همتا شروع کنید نه با سرویس. در Junos، show route 203.0.113.1 detail گام بعدی انتخاب‌شده و عملیات برچسب را چاپ می‌کند و show route table mpls.0 برچسب ورودی را به همان عملیات نگاشت می‌کند. در IOS XR، show mpls l2transport vc 100 detail وضعیت pseudowire را همراه با پشته تحمیل‌شده می‌دهد.

LSP‌ای را که انتقال واقعاً استفاده می‌کند تأیید کنید، نه آن را که سند طراحی شما نام می‌برد. traceroute mpls ipv4 203.0.113.1/32 در IOS XR مسیر سوئیچ‌شده با برچسب را می‌پیماید و برچسب‌ها و رابط‌های خروجی را در طول آن فهرست می‌کند، که نزدیک‌ترین چیز به خودِ تماشای مسیر است. سپس تمرین را از لبه ارائه‌دهنده دوردست تکرار کنید، چون جهت بازگشت مستقل تجزیه می‌شود و عدم تقارن پس از استقراری جزئی خط‌مشی رایج است. مسیری که در یک جهت درست و در جهت دیگر غلط باشد بدتر از مسیری است که در هر دو جهت غلط است، چون نیمی از آزمون‌های شما قبول می‌شوند.

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

بر پایه حالت خرابی انتخاب کنید، نه سلیقه

قفل‌کردن به سرویس‌هایی می‌خورد که قیدی دارند که IGP نمی‌تواند بیان کند، و به تیم‌هایی که می‌توانند خط‌مشی را در هر تغییر نگه دارند. واگذاری به IGP به سرویس‌هایی می‌خورد که باید هر خرابی منفرد را بدون حضور انسان در حلقه دوام بیاورند.

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