تأمین کنندگان عزیز ، ویژگی های EVPN از مسیر “وبلاگ ippace.net

یک داستان وحشتناک دیگر از بایگانی کد: ما نمی توانیم تصمیم بگیریم که آیا برخی از ویژگی ها واجب یا اختیاری هستند.

وقتی اشتباهات را برطرف کردم باکله الگوهای پیکربندی SR-COOS ، من نتوانستم EVPN را بر اساس EBGP دریافت کنم ، با برگهای همپوشانی مانند اعداد برای کار. من مسیرهای EVPN را در جدول BGP SR-CA دیدم ، اما دستگاه از استفاده از آنها امتناع ورزید. من نتیجه گرفتم (نادرست) که باید در کد SR-AOS EVPN عجیب و غریب وجود داشته باشد و ادامه یابد.

با این حال ، هنگامی که من تست های کامل ادغام را برای همه سیستم عامل های تحت تأثیر نسخه 25.06 انجام دادم ، AUBACX و DELL OS10 همان آزمایشات را شکستند ، حتی اگر قبلاً آنها را پشت سر گذاشته بودند. من یاد گرفتم (راه دشوار) که با رویکردم “ببینید چه چیزی تغییر کرده است” برای عیب یابی بسیار مراقب باشم ^{و در پایان فهمیدم که تنها چیزی که تغییر کرد صدور نرم افزار Broning که من برای سایر دستگاه ها در آزمون ادغام استفاده کردم.}

قبل از اینکه خود را در جزئیات غوطه ور کنید ، در اینجا بررسی سریع توپولوژی آزمایشگاهی وجود دارد:

• VXLAN با هواپیمای کنترل EVPN برای گسترش یک VLAN منفرد بین دو سوئیچ برگ (L1 ، L2) استفاده می شود
• سوئیچ های برگ به یک سوئیچ ستون فقرات (L1 → ستون فقرات → L2) وصل می شوند.
• سه سوئیچ EVPN را از طریق جلسات EBGP مستقیم متصل (تنظیم SANE EBGP) اجرا می کنند
• سوئیچ های برگ همان شماره ها را دارند و باید از چیزی شبیه به آن استفاده کنند اجازه برای غیرفعال کردن چک های مسیر.

بیایید از دست بدهیم سفر قهرمان منابع مربوط به عیب یابی و مستقیم به نتایج بروید. بازتولید همان آزمایشگاه با سه گره FRR (نسخه 10.3) ، بیایید دو مسیر EVPN Type-3 را بررسی کنیم ^{تولید شده توسط L1 و L2 سوئیچ ستون فقرات:}

مسیرهای EVPN Type-3 در سوئیچ ستون فقرات

spine# show bgp l2vpn evpn route detail type multicast
Route Distinguisher: 10.0.0.2:1000
BGP routing table entry for 10.0.0.2:1000:[3]:[0]:[32]:[10.0.0.2]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  l1(10.1.0.1) l2(10.1.0.5)
  Route [3]:[0]:[32]:[10.0.0.2]
  65200
    10.0.0.2(l1) from l1(10.1.0.1) (10.0.0.2)
      Origin IGP, valid, external, bestpath-from-AS 65200, best (First path received)
      Extended Community: RT:65000:1000 ET:8
      Last update: Fri Jun 13 15:05:59 2025
      PMSI Tunnel Type: Ingress Replication, label: 1000
Route Distinguisher: 10.0.0.3:1000
BGP routing table entry for 10.0.0.3:1000:[3]:[0]:[32]:[10.0.0.3]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  l1(10.1.0.1) l2(10.1.0.5)
  Route [3]:[0]:[32]:[10.0.0.3]
  65200
    10.0.0.3(l2) from l2(10.1.0.5) (10.0.0.3)
      Origin IGP, valid, external, bestpath-from-AS 65200, best (First path received)
      Extended Community: RT:65000:1000 ET:8
      Last update: Fri Jun 13 15:05:59 2025
      PMSI Tunnel Type: Ingress Replication, label: 1000

مسیرها قانونی به نظر می رسند. آنها همچنین تقریباً یکسان هستند ، اما می توان انتظار داشت ، درست است؟ حال بیایید به همان مسیرهای L1 نگاه کنیم. یکی از مسیرها توسط L1 تولید می شود ، دیگری توسط L2 تبلیغ می شود و توسط ستون فقرات از طریق جلسات EBGP توزیع می شود. آیا می توانید تفاوت (نادیده گرفتن RD ، AS-PATH و موارد مشابه) را مشاهده کنید؟

مسیرهای EVPN نوع 3 در L1

l1# show bgp l2vpn evpn route detail type multicast
Route Distinguisher: 10.0.0.2:1000
BGP routing table entry for 10.0.0.2:1000:[3]:[0]:[32]:[10.0.0.2]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  spine(10.1.0.2)
  Route [3]:[0]:[32]:[10.0.0.2] VNI 1000
  Local
    10.0.0.2(l1) from 0.0.0.0 (10.0.0.2)
      Origin IGP, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received)
      Extended Community: ET:8 RT:65000:1000
      Last update: Fri Jun 13 15:05:56 2025
      PMSI Tunnel Type: Ingress Replication, label: 1000
Route Distinguisher: 10.0.0.3:1000
BGP routing table entry for 10.0.0.3:1000:[3]:[0]:[32]:[10.0.0.3]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  spine(10.1.0.2)
  Route [3]:[0]:[32]:[10.0.0.3]
  65100 65200
    10.0.0.3(spine) from spine(10.1.0.2) (10.0.0.1)
      Origin IGP, valid, external, bestpath-from-AS 65100, best (First path received)
      Extended Community: RT:65000:1000
      Last update: Fri Jun 13 15:06:01 2025
      PMSI Tunnel Type: Ingress Replication, label: 1000

آیا این جزئیات کوچک را متوجه شدید؟

مسیر محلی

      Extended Community: ET:8 RT:65000:1000

این مسیر در دو جلسه EBGP توزیع می شود

      Extended Community: RT:65000:1000

ویژگی ET از مسیر EVPN از راه دور وجود ندارد.

مرحله بعدی: تلاش برای یافتن این که شاعر هنگام نوشتن ET چیست (احتمالاً این یکی نیست). حفر جوامع گشاد شده BGP که در RFC 8365 شرح داده شده است ، سرانجام کشف کردم محاصره BGP از یک جامعه گسترده با تونل نوع ویژگی کپسول BGP جایی که یک مقدار 8 به معنی vxlan است^حرف

خلاصه کردن

• FRR نسخه 10.3 چوب BGP Encapsulation = VXLAN جامعه گسترده به مسیرهای EVPN
• FRR Release 10.2 این جامعه را به سایر همسایگان EBGP توزیع می کند در حالی که FRR Release 10.3 آن را منتشر می کند. دلیل خوبی برای انجام این کار وجود ندارد ، زیرا BGP هاپ بعدی بدون تغییر است. دستگاه خسته کننده جامعه گسترده در مسیر داده VXLAN نیست (این فقط یک تغییر مسیر IP است) و بنابراین هیچ کاری برای تصمیم گیری برای استفاده از چه محاصره ای ندارد.
• Aubacx ، Dell OS10 و Nokia SR-AM هنگام پیکربندی برای استفاده از محاصره VXLAN با هواپیمای کنترل EVPN ، از استفاده از مسیرهای EVPN امتناع می ورزند BGP Encapsulation جامعه
• به نظر می رسد که تمام تبدیل های EVPN دیگر که ما برای آنها تحقق یافته ایم اجازه عملکرد (Cumulus ، EOS ، Nexus OS ، SR Linux ، Vyos) فقدان این جامعه را نادیده می گیرد و با خوشحالی از مسیرها بدون آنها استفاده می کند.

خوب ، مجموعه ای از تأمین کنندگان باید اشتباه باشند ، درست است؟ به دنیای فوق العاده نامشخص EVPN خوش آمدید. در اینجا چند الاغ برای انتخاب از این RFC فوق العاده وجود دارد:

بخش 5.1.3: در صورت عدم وجود جامعه محصور سازی BGP گسترش یافته ، MPLS گرفته می شود یا محصور می شود ، یا یک محاصره پیکربندی شده استاتیک.

من موارد فوق را به عنوان “جامعه اختیاری است” خواندم ، اما “همه شرط بندی ها مستثنی هستند”.

بخش 6: NVE ورودی فقط می تواند یک قاب را به NVE خروجی ارسال کند اگر مجموعه کپسول تبلیغ شده توسط خروجی NVE یک تقاطع غیر خالی با مجموعه کپسول پشتیبانی شده توسط ورودی ورودی ایجاد کند.

اکنون به نظر می رسد که جامعه محصور سازی BGP یک ضرورت است. با این حال ، همان پاراگراف شامل این گوهر است:

اگر هیچ جامعه محصور سازی BGP در دسترس نیست ، کپسول پیش فرض یا کپسوله سازی محلی پیکربندی شده گرفته می شود

سرانجام ، یک گیلاس فوق العاده مبهم روی کیک که به پایان می رسد بخش 6:

مسئولیت یک اپراتور EVI اطمینان از این است که تمام NV های موجود در این EVI حداقل یک کل محاصره را پشتیبانی می کنند. اگر این بیماری مختل شود ، این ممکن است منجر به وقفه در سرویس یا عدم موفقیت شود. استفاده از جامعه Extended BGP Encapsulation ، روش تشخیص را در هنگام نقض این بیماری فراهم می کند ، اما اقدامات انجام شده به صلاحدید اپراتور است و خارج از محدوده این سند است.

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