چرا یک MAC مربوط به QFX در EVPN دیده می‌شود اما در جدول ارسال نه

یافتن یک MAC در پایگاه داده EVPN اثبات می‌کند که به‌عنوان مسیر اعلام یا دریافت شده است و نه چیزی بیشتر. جدول ارسال ساختاری متفاوت است که بعداً برنامه‌ریزی می‌شود، بنابراین همان MAC می‌تواند در یکی ظاهر شود و در دیگری غایب باشد، در حالی که هر پروتکلی درست کار می‌کند. برخورد با این دو خروجی به‌عنوان رونوشت یکدیگر، مهندسان را دنبال یک خطای BGP می‌فرستد، در حالی که شکاف واقعی یک سیاست ورود یا یک پرش بعدی حل‌نشده است. پرسشی که ارزش پرسیدن دارد این نیست که آیا fabric آن MAC را می‌داند، بلکه در کدام مرحله انتقال آن متوقف شد.

دو جدول که به دو پرسش متفاوت پاسخ می‌دهند

در Junos EVPN پایگاه داده آدرس‌های MAC را به تفکیک نمونه و همچنین نحوه رسیدن هر یک فهرست می‌کند: یادگرفته از پورت دسترسی، دریافت‌شده در یک مسیر Type 2، یا علامت‌گذاری‌شده به‌عنوان بخشی از یک گروه چندهسته‌ای. مرجع Juniper show evpn database فیلترهای به تفکیک MAC و نمونه را پوشش می‌دهد که نما را خوانا می‌کند. این خلاصه‌ای از صفحه کنترل با کلید نمونه و MAC است، نه جدولی که سخت‌افزار با آن فریم‌ها را سوئیچ می‌کند.

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

یک مسیر Type 2 آدرس MAC، یک IP اختیاری، یک برچسب یا VNI، یک متمایزکننده مسیر و یک پرش بعدی که VTEP دور را نام می‌برد حمل می‌کند. چهار چیز می‌توانند میان کابل و آن مسیر بشکنند: میزبان هرگز یاد گرفته نمی‌شود، مسیر هرگز اعلام نمی‌شود، در ورود رد می‌شود، یا پرش بعدی آن حل نمی‌شود. هر شکست مجموعه‌ای متفاوت از جدول‌های پر را بر جای می‌گذارد، و همین دلیل آن است که اصلاً می‌توان این توالی را عیب‌یابی کرد.

یادگیری محلی همچنان نخست رخ می‌دهد

فرض رایج این است که EVPN یادگیری MAC را برمی‌گیرد، پس پایگاه داده خالی باید به معنای مشکل overlay باشد. یادگیری محلی همچنان در سمت دسترسی اجرا می‌شود، دقیقاً مانند پیش از وجود VXLAN: سوئیچ MAC مبدأ یک فریم مجاز را در VLAN و سرویس درست یاد می‌گیرد و تنها پس از آن یک Type 2 برای آن ایجاد می‌کند. میزبانی که هیچ فریم مرتبطی نفرستاده چیزی برای اعلام ندارد. میزبانی که فریم‌هایش به‌دلیل عضویت VLAN، یک فیلتر یا عضو غیرفعال یک تجمیع کنار گذاشته می‌شوند، از دید overlay یکسان به نظر می‌رسد.

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

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

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

کجا یک MAC دور گم می‌شود

یک MAC دور در جهت مخالف شکست می‌خورد، و بی‌صدا. مسیر Type 2 می‌رسد، اما تنها زمانی به یک نمونه وارد می‌شود که هدف مسیر و VNI آن با پیکربندی محلی مطابقت داشته باشد، و تنها زمانی قابل استفاده می‌شود که پرش بعدی به یک VTEP قابل دسترس حل شود. ناسازگاری هدف مسیر، مسیر معتبری را در جدول BGP بر جای می‌گذارد که هیچ نمونه‌ای هرگز آن را نمی‌خواهد.

سه نما را به ترتیب بخوانید: وجود مسیر، ورودی پایگاه داده، ورودی ارسال. فرمان‌های زیر در هر مرحله همان MAC را می‌پرسند، و آدرس نمونه خروجی‌ها را قابل مقایسه نگه می‌دارد.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

آن خروجی‌ها به سه پرسش جدا پاسخ می‌دهند. مسیری در bgp.evpn.0 بدون ورودی پایگاه داده به سیاست ورود، هدف مسیر یا پیکربندی نمونه اشاره می‌کند. ورودی پایگاه داده بدون ورودی ارسال به برنامه‌ریزی پلتفرم اشاره می‌کند که به مسیر ارتقای دیگری تعلق دارد. مسیر فعالی که پرش بعدی آن حل نمی‌شود یک مشکل انتقال یا برچسب است، و هیچ مقدار عیب‌یابی MAC آن را درست نمی‌کند.

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

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

پیش از هر پنجره نگهداری، چیزی را که راه‌اندازی مجدد پاک خواهد کرد ثبت کنید. همین سه فرمان برای مقایسه پیش و پس کافی است و چیزی را روی دستگاه تغییر نمی‌دهد.

show evpn database instance blue
show route table bgp.evpn.0
show version

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

چهار مشاهده که بیشتر موارد را حل می‌کند

چهار مشاهده تقریباً هر مورد را پوشش می‌دهند: نقطه اتصال و سرویس آن، MAC به‌عنوان مقدار نمونه، وضعیت مسیر و پایگاه داده، و نسخه‌ای که در حال استفاده است. MACای را انتخاب کنید که آشکارا نمونه باشد تا کسی آن را با آدرس تولید اشتباه نگیرد: اکتت نخست 02 یک آدرس unicast با مدیریت محلی را نشان می‌دهد، اکتت‌های باقی‌مانده آزادند، و بنابراین 02:00:00:00:00:5c جای‌نگهدار امنی است.

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