چرا یک مستأجر EVPN میتواند چند route distinguisher نشان دهد
دو RD در یک مستأجر تعارض نیست. از خروجی CLI تا MAC-VRF یا IP-VRF که مسیر را ساخته بروید، سپس وارد کردن RT و VNI را بررسی کنید.
جدول EVPN را برای یک مستأجر فیلتر میکنید و مسیرها دو route distinguisher متفاوت دارند. نخستین برداشت، تعارض در پیکربندی است و این برداشت معمولاً نادرست است. نام مستأجر یک برچسب تجاری است، نه یک شیء واحد در سطح کنترل، بنابراین بستر پلزنی و بستر مسیریابی درون آن میتوانند بهطور مشروع زیر شناسههای جداگانه اعلام شوند. هر بار یک مسیر را از خروجی به عقب تا شیء سرویس محلی که آن را ساخته دنبال کنید و RD دوم دیگر شبیه اشتباه به نظر نمیرسد.
از همان خروجی که گیجتان کرد شروع کنید
بهجای کل جدول یک مسیر را انتخاب کنید. نوع مسیر، RD، route targetهای صادرشده و گام بعدی آن را یادداشت کنید. همین چهار فیلد کافی است تا مشخص شود کدام شیء محلی آن را اعلام کرده و کدام سیاست دوردست باید آن را وارد کند.
روی دستگاهی به سبک NX-OS نمای جزئیات با این دستور بهدست میآید: show bgp l2vpn evpn route-type 2 detail یا show bgp l2vpn evpn route-type 5 detail. در Junos همان اطلاعات در اینجا قرار دارد: show route table bgp.evpn.0 detail. نحو متفاوت، همان فیلدها.
با یکسانکردن هر عدد نمایشدادهشده شروع نکنید. یکسانکردن RDها همان تغییری است که سیاست ورود را روی یک fabric در حال کار میشکند.
به هر شناسه کار خودش را بدهید
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF اطلاعات ارسال MAC را برای یک سرویس پل نگه میدارد. IP-VRF یک بستر مسیریابی IP برای سرویس مسیریابیشده فراهم میکند. یک مستأجر میتواند هر دو را در خود داشته باشد، به همین دلیل یک مستأجر میتواند بدون هیچ خطای پیکربندی بیش از یک RD تولید کند.
RFC 7432 شناسه RD مربوط به MAC-VRF اعلامکننده را به EVPN NLRI آن اختصاص میدهد و RDهای متمایز را در میان MAC-VRFها روی همان PE الزامی میکند. رویههای route-target جدا هستند: یک یا چند ویژگی RT را مجاز میدانند و برای عضویت به سیاست ورود تکیه میکنند. برابری RD چیزی نیست که عضویت مشترک ایجاد کند و برخورد اینچنینی با آن ریشه این سردرگمی است.
یک مسیر را از اعلام تا ورود دنبال کنید
مسیر را در یک جهت دنبال کنید. نوع مسیر، سرویس سازنده، RD، RTهای صادرشده و سپس سیاست ورود روی PE دریافتکننده را تأیید کنید. هر گام به پرسش متفاوتی پاسخ میدهد و شکست در هر گام مانند همان پیشوند گمشده در طرف مقابل دیده میشود.
وقتی مسیر حاضر شد، بستر ارسال نصبشده و نگاشت VNI را بررسی کنید. مطابقت VNI در دو سر نشان میدهد که سطح داده همنظر است؛ نشان نمیدهد که سطح کنترل مسیر را از طریق سیاست موردنظر وارد کرده است.
اگر مسیر روی PE دوردست ظاهر میشود اما ترافیکی جریان ندارد، مشکل از EVPN گذشته است. اتصال VNI به VLAN یا VNI به VRF و مسیر underlay را پیش از ویرایش دوباره route targetها بررسی کنید. از نگاشت شروع کنید، سپس underlay و تنها پس از آن سطح کنترل. برگرداندن یک تغییر route-target برای تعقیب یک نقص سطح داده، راهی مطمئن برای شکستن یک ورود در حال کار است.
پیشوندهای لایه 3 هنوز مسیرهای EVPN هستند
یک پیشوند IP در جدول EVPN، BGP معمولی IPv4-unicast نیست. مسیر EVPN IP Prefix نوع مسیر خودش را دارد، و اعلانهای MAC/IP بههمراه پیشوند IP در خانواده نشانی EVPN سفر میکنند که RFC 7432 آن را AFI 25 و SAFI 70 معرفی میکند.
این تفاوت وقتی مهم است که مسیری در جدول EVPN را با مسیری در جدول unicast مقایسه میکنید. میتوانند مقصد یکسانی را توصیف کنند و باز هم با سیاست متفاوت تولید، فیلتر و وارد شوند. خواندن یکی بهعنوان شاهد درباره دیگری همان چیزی است که یک fabric درست را در هنگام مهاجرت خراب نشان میدهد.
پیش از مقایسه اعداد، اشتقاق سازنده را بررسی کنید
RFC 9136 دامنه EVPN را با مسیرهای IP Prefix گسترش میدهد و مشخص میکند که RD قابلاعمال از بستر MAC-VRF میآید یا IP-VRF. به همین دلیل برچسب سرویس L2 و برچسب سرویس مسیریابیشده در یک خروجی باید در برابر اشیائی که به آنها تعلق دارند خوانده شوند، نه اینکه به یک RD برای هر مستأجر فروکاسته شوند.
اشتقاق خودکار RD و RT به سازنده وابسته است. مرجع سازنده مستقرشده را برای فرمول مورداستفاده بخوانید؛ مقداری که بهطور خودکار روی یک سوئیچ دیده میشود کدگذاری جهانی نیست و مقایسه اعداد دو سازنده بهندرت چیزی را اثبات میکند.
کار را با یک رد پای نوشتاری برای همان مسیری که با آن شروع کردید تمام کنید: نوع، شیء سازنده، RD، RT صادرشده، سیاست ورود، VNI نصبشده. شش فیلد اعلان را برای هر کسی که بار بعد تیکت را میخواند توضیح میدهد و هیچیک از آنها لازم نمیکند که اعداد مستأجر یکسان شوند.