میزبان خاموش EVPN هرگز حل نمی‌شود: ARP را تا اتصال دنبال کنید

نقطه انتهایی متصل است، پورتش فعال است و میزبان پایش هنوز نمی‌تواند به آن برسد. کسی از سمت مقابل ping اجرا می‌کند و کار شروع می‌شود، که باعث می‌شود مشکل متناوب به نظر برسد و fabric بی‌گناه جلوه کند. این الگو امضای یک میزبان خاموش است: به‌ندرت ارسال می‌کند، پس رفتار کشف و بازآوری fabric مهم‌تر از وضعیت اتصال آن است. با یک IP، MAC و bridge domain موردنظر شروع کنید و تبادل حل بعدی را دنبال کنید.

تبادل ARP یا ND بعدی را دنبال کنید

برای IPv4، تبادل ARP میزبان درخواست‌کننده را تماشا کنید؛ برای IPv6، Neighbor Solicitation و Advertisement را دنبال کنید. تأیید کنید که درخواست وارد بخش محلی موردنظر و VNI موردنظر می‌شود، زیرا درخواستی که هرگز به bridge domain درست نمی‌رسد را هیچ پروکسی نمی‌تواند پاسخ دهد.

سپس ببینید fabric درباره هدف چه می‌داند. یک مسیر فقط MAC می‌تواند مقصد Layer 2 را شناسایی کند، در حالی که پروکسی هنوز هیچ اتصال IP-to-MAC برای آن ندارد. اینها رکوردهای جداگانه‌اند و بررسی یکی چیزی درباره دیگری نمی‌گوید.

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

دو رکورد که باید همخوان باشند

مسیر MAC پاسخ می‌دهد که نشانی Ethernet کجاست. جدول پروکسی پاسخ می‌دهد که کدام IP به کدام MAC نگاشته می‌شود. میزبانی که اخیراً صحبت نکرده می‌تواند مسیر MAC کاملاً خوبی داشته باشد و هیچ ورودی پروکسی قابل استفاده‌ای نداشته باشد، و این دقیقاً همان حالتی است که شکست حل را روی یک اتصال سالم پدید می‌آورد.

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

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

استاندارد در واقع چه چیزی را فرض می‌کند

RFC 9161 یادگیری پویای پروکسی و flooding پیش‌فرض درخواست‌های ناشناخته ARP و ND را توصیف می‌کند. مهار کامل آن flooding به استقرارهایی محدود است که فرض‌های یادگیری یا تأمین آنها را ایمن می‌کند، که شرطی محدودتر از آن است که بیشتر راهنماهای پیکربندی القا می‌کنند.

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

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

بازآوری، کهنگی و جایگزین ایستا

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

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

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

پیش از تیکت بعدی چه چیزی را ثبت کنیم

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

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