مسائل ARP در طراحی مسیریابی متمرکز EVPN « وبلاگ ipSpace.net

افزودن IRB به MAC-VRF های EVPN (روش فانتزی گفتن VLAN های کشیده شده) به نظر غیرممکن است:
- آدرس های IP را به رابط های VLAN اضافه کنید
- به صورت اختیاری یک دروازه اشتراکی anycast اضافه کنید
- اعلام کنید که ماموریت انجام شده است (و سعی کنید تماس تلفنی اجتناب ناپذیر 2 صبح یکشنبه شب را نادیده بگیرید)
کار در یک محیط چند فروشنده حتی سرگرم کننده تر است، همانطور که متأسفانه هنگام ایجاد آزمایشگاه های EVPN یا تلاش برای کشف علت شکست برخی از پیاده سازی های EVPN کشف کردم netlab تست های یکپارچه سازی EVPN
تلاش برای توضیح این مسائل از ابتدا در یک محیط IRB نامتقارن از قبل پیچیده احتمالا شما را گیج می کند، بنابراین تصمیم گرفتم با یک سناریوی ساده تر شروع کنم: مسیریابی مرکزی روی یک سوئیچ ستون فقرات.
ارسال بسته در یک طراحی مسیریابی متمرکز
در اینجا حدس های ما آمده است:
- L1، L2، و Spine با EVPN کار می کنند و مسیرهای نوع 2 (MAC-IP) و نوع 3 (تکثیر ورودی) را تبلیغ می کنند.
- L1 و L2 به عنوان پل عمل می کنندو یک EVPN MAC-VRF داشته باشید.
- Spine دارای دو نمونه EVPN MAC-VRF و یک آدرس IP است که در هر نمونه MAC-VRF پیکربندی شده است. ما به دلایل واضح این آدرس های IP را SIPB و SIPR می نامیم. آدرس های MAC اولیه SMACB و SMACR هستند.
- HB1 و HR1 مسیرهای ثابتی دارند که از آدرس IP مجاور Spine به عنوان پرش بعدی استفاده می کنند.
هر کسی که ادعا می کند کمی در مورد مسیریابی IP می داند باید بتواند تلاوت کند وقتی HB1 سعی می کند اولین بسته را به HR1 ارسال کند چه اتفاقی می افتد:
- HB1 یک جستجوی جدول مسیریابی انجام می دهد و SIPB را به عنوان پرش بعدی پیدا می کند.
- HB1 یک درخواست پخش ARP برای SIPB ارسال می کند
- SIPB با یک پاسخ ARP unicast ارسال شده توسط SMACB پاسخ می دهد
- HB1 بسته HR1 را با استفاده از SMACB به عنوان آدرس MAC مقصد به Spine ارسال می کند
- Spine یک جستجوی جدول مسیریابی انجام می دهد و متوجه می شود که VLAN قرمز مستقیماً متصل است.
- Spine یک درخواست پخش ARP برای HR1 از SMACR ارسال می کند.
- HR1 با یک پاسخ ARP unicast ارسال شده به SMACR پاسخ می دهد.
- Spine اکنون می تواند بسته دریافتی از HB1 را با استفاده از آدرس MAC HR1 به HR1 ارسال کند.
بی اهمیت به نظر می رسد، درست است؟ چه چیزی می تواند اشتباه باشد؟ از کجا شروع کنم و چقدر وقت دارید؟
اول آسان: چندین پیاده سازی EVPN آدرس های IP/MAC VLAN خود را بدون برخی آدرس های جدی تبلیغ نمی کنند. چرخاندن بازو دکمه نرد وقتی HB1 یک بسته اترنت را به SMACB می فرستد، L1 نمی داند SMACB کجاست (زیرا سوئیچ Spine هرگز مسیر MAC-IP را برای SMACB/SIPB تبلیغ نکرده است)، بنابراین تمام ترافیک بین زیرشبکه ها سیل شده است (جزئیات بیشتر).
در سناریوی سه سوئیچ ما خیلی بد نیست، اما یک فاجعه بزرگ در یک شبکه در مقیاس بزرگ با دهها سوئیچ در همان VLAN (اوه، مثال MAC-VRF).
درس شماره 1: سوئیچ ستون فقرات باید آدرس MAC/IP VLAN خود را به عنوان مسیر MAC-IP EVPN تبلیغ کند.
حتی بدتر از آن، برخی از پیادهسازیهای EVPN درخواستهای ARP دریافتشده از طریق VXLAN را رسیدگی نمیکنند (زیرا فروشنده معتقد است شخص دیگری باید آنها را مدیریت کند)، که باعث میشود مسیریابی متمرکز بدون یک دکمه geek دیگر کار نکند: پراکسی ARP.
این پیاده سازی ها انتظار دارند سوئیچ های لایه ورودی 2 به درخواست های ARP پاسخ دهند از طرف روترهای پشت سر آنها بر اساس اطلاعات دریافتی در مسیرهای MAC-IP. دستگیره های بیشتر برای چرخاندن سوئیچ های سطح 2 (L1/L2)
درس شماره 2: گاهی اوقات برای مقابله با روترهایی که به ARP-over-VXLAN گوش نمی دهند، نیاز دارید که پروکسی ARP را در سوئیچ های لایه 2 EVPN فعال کنید.
لطفاً توجه داشته باشید که پراکسی ARP (به درخواست های ARP پاسخ می دهد از طرف شخص دیگری در همان زیرشبکه) با پروکسی ARP (پاسخ دادن به درخواست های ARP) یکسان نیست برای آدرس های IP خارج از زیرشبکه ای که درخواست ARP در آن دریافت شده است).
بله، گاهی اوقات ما اصطلاحات را درک می کنیم دقیقا همانطور که باید باشد 🤦♂️
اما صبر کنید، این همه چیز نیست. برخی از پیاده سازی ها از ارسال درخواست های ARP از طریق VXLAN خودداری می کنند. در مورد ما، Spine هرگز درخواست ARP را به HR1 ارسال نمی کند و تمام بسته ها را از HB1 به HR1 حذف می کند.
این پیادهسازیها انتظار دارند سوئیچهای EVPN لایه 2 (L1 و L2) بستههایی را که میتوانند نگاشتهای MAC-to-IP (ARP، ND، DHCP، گاهی اوقات حتی ترافیک IP ساده) را آشکار کنند و آن اطلاعات را به عنوان یک مسیر EVPN نوع 2 (MAC-IP) تبلیغ کنند، تماشا کنند. سپس روتر مرکزی از این اطلاعات برای ساخت حافظه پنهان ARP خود استفاده می کند و نیاز به درخواست های ARP را از بین می برد.
درس شماره 3: اگر پیادهسازی EVPN شما از ارسال درخواستهای ARP از طریق VXLAN امتناع میکند، Snooping ARP (یا هر چیزی که نامیده میشود) را روی سوئیچهای لایه ۲ پیکربندی کنید.
فهمیدن اینکه چگونه میتوان جستجوی ARP را با میزبانهای بیصدا کار کرد، به عنوان تمرینی برای خواننده باقی میماند. در صورت لزوم، از مخاطبین فنی فروشنده خود در مورد این جزئیات جزئی بپرسید و به تکان خوردن آنها نگاه کنید.
گاهی اوقات یک پیاده سازی EVPN می تواند از تنظیمات پیش فرض برای انجام کارها استفاده کند فقط کار کن در یک محیط تک فروشنده. اگر بدشانس باشید، ارائهدهنده شما به قدرتهای جادویی مسیرهای نوع 5 اعتقاد دارد و انتظار دارد همه IRB متقارن انجام دهند (زمان دیگری در مورد آن صحبت خواهیم کرد). با کمی شانس و دانش مخفیانه در مورد دستگیرههای geeky، ممکن است بتوانید برخی از این تبدیلها را عملی کنید. اگر واقعاً بدشانس هستید، گیر کردهاید و حتی نمیتوانید از مولد تون DMTF دستی مانند ما در روزهای خوب قدیمی سیگنالدهی SIP غیرمنطبق استفاده کنید.
آن را امتحان کنید
توپولوژی آزمایشگاهی که در این پست وبلاگ استفاده کردم در مخزن نمونه های netlab GitHub است. اگر می خواهید آن را امتحان کنید:
- محیط آزمایشگاه خود را تنظیم کنید (می توانید از فضای کدهای رایگان GitHub استفاده کنید)
- تغییر دایرکتوری به
EVPN/central-routing - اعدام نت لب بالا و کشف کنید



