باند فعال-پشتیبان لینوکس روی EVPN تمام‌فعال: چه چیزی می‌شکند

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

باند فعال-پشتیبان با فریم ورودی چه می‌کند

حالت باندینگ 1 دقیقاً یک اسلیو را در مسیر ارسال نگه می‌دارد و تنها وقتی اسلیو فعلی از کار می‌افتد آن را عوض می‌کند. این بخش کاملاً شناخته‌شده است. آنچه اینجا اهمیت دارد سمت دریافت است: کرنل فریم را تنها وقتی به استک تحویل می‌دهد که از اسلیو فعال برسد، و فریم‌هایی که روی هر اسلیو دیگر ظاهر شوند را دور می‌ریزد. این all_slaves_active تنظیم دقیقاً برای شل کردن آن قاعده وجود دارد و به‌طور پیش‌فرض خاموش است. ip -d link show bond0 مقدار فعلی را کنار حالت چاپ می‌کند.

/proc/net/bonding/bond0 اسلیو فعال را نام می‌برد و وضعیت لینک هر اسلیو را گزارش می‌کند. آن فایل تنها منبع صادق برای این است که کدام پورت در حال حاضر ترافیک را حمل می‌کند.

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

مولتی‌هومینگ تمام‌فعال با یک هاپ بعدی دور چه می‌کند

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

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

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

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

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

چرا کابل پشتیبان همچنان سالم به نظر می‌رسد

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

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

تحویل را در هر دو جهت آزمایش کنید، نه وضعیت لینک را

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

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

طراحی را تنها وقتی بپذیرید که ماتریس تحویل دوسویه را از مسیری که در نظر داشتید نشان دهد. دو کابل با لینک بالا آن نتیجه نیست.