EVPN بالا است اما سرویس نه: چهار نقطه بررسی

رسیدن به نشانی VTEP دور اثبات می‌کند که لایه زیرین بسته‌ها را حمل می‌کند و همین تنها چیزی است که اثبات می‌کند. سرویس مستأجر به یک نشست BGP EVPN با خانواده نشانی درست، یک VNI محلی متصل و عملیاتی، یک مسیر تولیدشده و یک واردکردن در انتهای دور نیاز دارد. این‌ها چهار نقطه بررسی جداگانه‌اند و هرکدام ترمیم متفاوتی دارند. در نظر گرفتن لایه زیرین سبز به‌عنوان آمادگی سرویس، رایج‌ترین دلیل گیرکردن راه‌اندازی EVPN است.

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

نقطه بررسی 1: انتقال تا VTEP

با دسترس‌پذیری میان نشانی‌های loopback که به‌عنوان منبع VTEP استفاده می‌شوند شروع کنید. مسیر باید در لایه زیرین وجود داشته باشد، مسیر باید مجاز باشد از جمله هر الزام کپسوله‌سازی، و مسیر بازگشت باید کار کند. مسیری که وجود دارد اما در یک جهت فیلتر می‌شود شکست نامتقارنی ایجاد می‌کند که متناوب به نظر می‌رسد. پیش از ادامه هر دو جهت را تأیید کنید.

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

نقطه بررسی 2: خانواده EVPN، نه تعداد نشست‌ها

یک نشست BGP برقرارشده به معنای مذاکره خانواده نشانی EVPN نیست. وضعیت مخصوص خانواده را برای همسایه ببینید: اینکه خانواده فعال است یا نه، آیا با همتای مقابل مذاکره شده و آیا نشست اصلاً آن را حمل می‌کند. نشستی که برای IPv4 unicast بالا است و هرگز EVPN را مذاکره نکرده، در خلاصه عمومی همسایه‌ها هیچ اشکالی نشان نمی‌دهد، و مشخصات لایه رویی EVPN رویه‌های سرویس و کنترل را موضوعاتی جدا از انتقال می‌داند.

نشانی مبدأ نشست را هم بررسی کنید. همتایی که بر پایه نشانی‌ای ساخته شده که منبع VTEP نیست، یک ناسازگاری طراحی است که منتظر است تا خطای ارسال را توضیح دهد.

نقطه بررسی 3: سرویس محلی متصل است

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

سپس تأیید کنید که دستگاه واقعاً چه چیزی تولید می‌کند: مسیر محلی برای همان VNI با route targetهایی که طراحی مشخص می‌کند. VNIای که متصل است اما اعلام نمی‌شود سرویسی می‌سازد که فقط محلی وجود دارد و جای دیگری نه.

نقطه بررسی 4: واردکردن در گیرنده

در دستگاه گیرنده، route targetهای صادرشده و واردشده را مقایسه کنید نه VNIهای عددی. تطابق شماره VNI ثابت نمی‌کند که نمونه گیرنده اعلام را وارد می‌کند و route target ناسازگار در فهرست VNI نامرئی است. پرش بعدی اعلام‌شده را از طریق لایه زیرین حل کنید پیش از اعتماد به ورودی ارسال. سپس وضعیت ارسال لایه رویی را برای سرویس بخوانید نه برای دستگاه به‌طور کلی.

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

یک سابقه که مسیر را می‌پیماید

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

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

چه زمانی VXLAN ایستا پاسخ درست است

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

همسایه IGP در لایه زیرین انتقال را فراهم می‌کند و نه بیشتر. وضعیت سرویس لایه رویی چیز جداگانه‌ای برای ساختن و چیز جداگانه‌ای برای بررسی است.