مسیریابی متمرکز EVPN با Arista EOS « وبلاگ ipSpace.net

یک ماه پیش من مسائل ARP را در طراحی مسیریابی متمرکز EVPN توضیح دادم و ناوین کومار دواراج به اندازه کافی مهربان بود تا جزئیاتی را در مورد پیاده سازی Arista EOS اضافه کند. امروز بیایید بررسی کنیم که Arista EOS چه مسیرهایی EVPN در این سناریو ایجاد می کند. ما از یک توپولوژی آزمایشگاهی بسیار ساده با سوئیچ ستون فقرات که به عنوان روتر عمل می کند استفاده خواهیم کرد. سوئیچ های برگ، سوئیچ های لایه 2 هستند.

هنگامی که آزمایشگاه شروع به کار می کند، همه سوئیچ ها مسیرهای IMET را برای VLAN های پیوست شده تبلیغ می کنند:

مسیرهای EVPN IMET که توسط سوئیچ های Arista EOS تبلیغ می شوند

l1#show bgp evpn
BGP routing table information for VRF default
Router identifier 10.0.0.2, local AS number 65000
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP
                    c - Contributing to ECMP, % - Pending best path selection
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  LocPref Weight  Path
 * >      RD: 10.0.0.1:1000 imet 10.0.0.1
                                 10.0.0.1              -       100     0       i
 * >      RD: 10.0.0.1:1001 imet 10.0.0.1
                                 10.0.0.1              -       100     0       i
 * >      RD: 10.0.0.2:1000 imet 10.0.0.2
                                 -                     -       -       0       i
 * >      RD: 10.0.0.3:1001 imet 10.0.0.3
                                 10.0.0.3              -       100     0       i

سوئیچ های برگ هر کدام یک مسیر IMET را تبلیغ می کنند (یک نمونه MAC-VRF دارند)، سوئیچ ستون فقرات دو مسیر IMET را تبلیغ می کند (دو نمونه MAC-VRF در یک نمونه IP-VRF وجود دارد).

سپس، بیایید دروازه پیش فرض (سوئیچ ستون فقرات) را از یکی از میزبان ها پینگ کنیم:

HB1 آدرس IP دروازه پیش فرض Spine را پینگ می کند

hb1:/# ip route
default via 192.168.121.1 dev eth0
10.0.0.0/24 via 172.16.1.1 dev eth1
10.1.0.0/16 via 172.16.1.1 dev eth1
10.2.0.0/24 via 172.16.1.1 dev eth1
172.16.0.0/16 via 172.16.1.1 dev eth1
172.16.1.0/24 dev eth1 scope link  src 172.16.1.4
192.168.121.0/24 dev eth0 scope link  src 192.168.121.104
hb1:/# ping 172.16.1.1 -c 3
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: seq=0 ttl=64 time=14.586 ms
64 bytes from 172.16.1.1: seq=1 ttl=64 time=2.449 ms
64 bytes from 172.16.1.1: seq=2 ttl=64 time=2.351 ms

قبل از اینکه HB1 بتواند یک بسته IP به Spine ارسال کند، باید یک درخواست ARP ارسال می کرد. وقتی به درخواست ICMP Echo پاسخ می‌دهد، Spine می‌تواند از جمع‌آوری ARP استفاده کند یا وضوح ARP مستقل را انجام دهد. صرف نظر از این جزئیات، حافظه پنهان ARP Spine از قبل حاوی ورودی برای HB1 است:

حافظه پنهان ARP برای HB1 در VRF مستاجر در ستون فقرات

spine#show arp vrf tenant
Legend:
 not learned: Associated MAC address is not present in the MAC address table
 -: Static (configuration or programmed by feature)
Address         Age (sec)  Hardware Addr   Interface
172.16.1.4        0:02:48  aac1.ab85.ab1f  Vlan1001, Vxlan1

ورودی ARP متعلق به رابط Vlan1001 است و از طریق VXLAN قابل دسترسی است. بدون هیچ شگفتی.

مسیرهای MAC-IP چطور؟ سوئیچ برگ، آدرس MAC HB1 را تبلیغ می کند. سوئیچ ستون فقرات چیزی را تبلیغ نمی کند زیرا آدرس IP HB1 از طریق رابط VXLAN آموخته می شود:

مسیرهای MAC-IP پس از درخواست های ARP اولیه

spine#show bgp evpn route-type mac-ip
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 65000
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP
                    c - Contributing to ECMP, % - Pending best path selection
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  LocPref Weight  Path
 * >      RD: 10.0.0.3:1001 mac-ip aac1.ab85.ab1f
                                 10.0.0.3              -       100     0       i

نتیجه گیری:

• روتر اصلی (سوئیچ ستون فقرات) مسیر MAC+IP را برای میزبان های متصل به VLAN خود تبلیغ نمی کند.
• در سناریوهایی با چندین روتر متصل به نمونه های MAC-VRF، هر روتر باید وضوح ARP خود را انجام دهد.

کنار:

• می‌توانید ARP Snooping را روی L1/L2 پیکربندی کنید تا آنها را به تبلیغ MAC+IP به جای مسیرهای MAC برای میزبان‌های متصل، وادار کنید. این به روتر مرکزی اطلاعات کافی می دهد تا مجبور نباشد خود رزولوشن ARP را انجام دهد.
• برخی از پیاده‌سازی‌های EVPN برای کار کردن نیاز به snooping ARP دارند (روتر مرکزی درخواست‌های ARP را از طریق VXLAN ارسال نمی‌کند).

در مورد جریان بسته چطور؟ همانطور که در پست اصلی وبلاگ اشاره کردم، اگر روتر اصلی آدرس MAC خود را تبلیغ نکند، سوئیچ برگ باید تمام ترافیک مسیریابی شده را سیل کند.^{. این دقیقاً همان چیزی است که هنگام استفاده از حداقل پیکربندی EVPN در Arista EOS اتفاق می‌افتد (به یاد داشته باشید: ما یک مسیر MAC/IP برای آدرس MAC دروازه پیش‌فرض ندیدیم):}

پیکربندی VLAN و EVPN یک سوئیچ Spine که Arista EOS را اجرا می کند

interface Vlan1000
   description VLAN red (1000) -> [hr1,l1]
   vrf tenant
   ip address 172.16.0.1/24
!
interface Vlan1001
   description VLAN blue (1001) -> [hb1,l2]
   vrf tenant
   ip address 172.16.1.1/24
!
router bgp 65000
   !
   vlan 1000
      rd 10.0.0.1:1000
      route-target import 65000:1000
      route-target export 65000:1000
      redistribute learned
   !
   vlan 1001
      rd 10.0.0.1:1001
      route-target import 65000:1001
      route-target export 65000:1001
      redistribute learned

یادداشت ها:

• پیکربندی بالا توسط netlab خروج 26.05. روتر مرکزی نیازی ندارد مطالب آموخته شده را دوباره توزیع کنید دستور بر روی نمونه های MAC-VRF از آنجایی که هیچ میزبانی به طور مستقیم متصل نیست.

اگر می‌خواهیم سیل ترافیک مسیریابی شده را متوقف کنیم، باید روتر مرکزی را طوری پیکربندی کنیم که حداقل آدرس MAC خود را تبلیغ کند (تبلیغ MAC+IP حتی بهتر است). در Arista EOS استفاده کنید توزیع مجدد سیستم روتر-مک فرمان ^{از نمونه های MAC-VRF برای تبلیغ فقط آدرس MAC دروازه پیش فرض یا آی پی سیستم روتر-مک را مجدداً اختصاص دهید برای تبلیغ مسیر MAC+IP EVPN نوع 2.}

هنگامی که این دستور را به دو نمونه MAC-VRF روی سوئیچ Spine اضافه می‌کنید، سوئیچ Spine شروع به تبلیغ آدرس‌های MAC VLAN و آدرس‌های IP پیش‌فرض دروازه می‌کند و در نتیجه یک پارچه EVPN به خوبی کار می‌کند.

مسیرهای EVPN MAC-IP بعد از اینکه سوئیچ Spine شروع به تبلیغ مسیرهای VLAN MAC/IP خود کرد

spine#show bgp evpn route-type mac-ip
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 65000
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP
                    c - Contributing to ECMP, % - Pending best path selection
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  LocPref Weight  Path
 * >      RD: 10.0.0.1:1000 mac-ip 001c.733a.3232 172.16.0.1
                                 -                     -       -       0       i
 * >      RD: 10.0.0.1:1001 mac-ip 001c.733a.3232 172.16.1.1
                                 -                     -       -       0       i
 * >      RD: 10.0.0.3:1001 mac-ip aac1.ab85.ab1f
                                 10.0.0.3              -       100     0       i

ماموریت انجام شد 😉

آن را امتحان کنید

توپولوژی آزمایشگاهی که من در این پست وبلاگ استفاده کردم در مخزن netlab-examples GitHub است. اگر می خواهید آن را امتحان کنید:

• محیط آزمایشگاهی خود را تنظیم کنید (می توانید از کدهای رایگان GitHub استفاده کنید)
• تغییر دایرکتوری به EVPN/central-routing
• اعدام نت لب بالا و کشف کنید