داستانی از دو کپسولاسیون EVPN/MPLS « وبلاگ ipSpace.net

من به این نتیجه رسیدم که وقت آن رسیده است که چند تست یکپارچه سازی Netlab EVPN/MPLS ایجاد کنم و می خواهم از همان رویکردی که برای EVPN/VXLAN استفاده کردم استفاده کنم:

• یکی از دستگاه های پلی اتیلن دستگاهی است که می خواهیم تست کنیم
• دستگاه پلی اتیلن دیگر دستگاهی است که کار می کند (به طور ایده آل یک ظرف FRRouting).
• اگر دستگاه PE دیگر بتواند داده های عملیاتی را با فرمت JSON تولید کند، امتیاز پاداش. استفاده از دستگاهی که قبلاً یک افزونه اعتبار سنجی برای آن داریم، تقریباً کامل است.
• یک روتر P در وسط اضافه کنید زیرا MPLS.
• چند میزبان را به دو دستگاه PE متصل کنید (ما دو MAC-VRF را در نسخه نهایی آزمایش آزمایش می کنیم)
• پس از تأیید اعتبار هر چیزی که به طور منطقی قابل تأیید است (جلسه OSPF، جلسه IBGP، EVPN AF در جلسه IBGP)، پینگ‌های انتها به انتها را انجام دهید و به بهترین‌ها امیدوار باشید.

این نمودار netlab ایجاد شده توسط توپولوژی آزمایشگاه است:

وقتی متوجه شدم که FRRouting از EVPN با کپسوله سازی MPLS پشتیبانی نمی کند، ایده عالی به سرعت از بین رفت. واقعاً مهم نیست؛ Arista EOS انجام می دهد. بیایید از Arista EOS به عنوان دستگاه PE شناخته شده استفاده کنیم.

ما قبلاً یک پیاده سازی EVPN-over-MPLS برای Arista EOS داشتیم و یک بار ساده آن را نوشتم پل روی EVPN/MPLS آزمایش، پیاده‌سازی Arista EOS آن را با رنگ‌های درخشان پشت سر گذاشت (تعجبی نیست زیرا هر دو روتر PE یک نرم‌افزار را اجرا می‌کنند).

مرحله بعدی: پیاده سازی EVPN-over-MPLS برای Cisco IOS/XE. هواپیمای کنترلی بلافاصله عملیاتی شد. همه مسیرهای مورد انتظار EVPN در جدول BGP قرار داشتند، اما ARP ها شکست خوردند.

من مشکلات مشابهی در گذشته داشتم، بنابراین می دانستم چه کار کنم: شروع رهگیری بسته ها. در اینجا درخواست ARP ارسال شده توسط H1 به H2 است:

17:26:58.138629 aa:c1:ab:ff:be:2f (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: 
  Ethernet (len 6), IPv4 (len 4), Request who-has 172.31.1.2 tell 172.31.1.1, length 28

و این چیزی است که H2 بدست آورده است:

17:26:58.139554 be:2f:08:06:00:01 (oui Unknown) > ff:ff:aa:c1:ab:ff (oui Unknown), ethertype IPv4 (0x0800), length 38: IP0 (invalid)

شبیه درخواست ARP نیست، اینطور نیست؟ مدتی طول کشید تا بفهمم که باید از ترافیک MPLS که فریم‌های اترنت را حمل می‌کند عکس بگیرم، اما زمانی که این کار را انجام دادم همه چیز (تا حدودی عجیب) منطقی بود. در اینجا درخواست ARP از H1 تا H2 است (که توسط Cisco IOS/XE کپسوله شده است):

17:29:39.637254 MPLS (label 16, exp 0, ttl 255)
	(label 1040999, exp 0, [S], ttl 255)
	0x0000:  ffff ffff ffff aac1 abff be2f 0806 0001  .........../....
	0x0010:  0800 0604 0001 aac1 abff be2f ac1f 0101  .........../....
	0x0020:  0000 0000 0000 ac1f 0102                 ..........

و در اینجا درخواست ARP از H2 به H1 است (که توسط Arista EOS کپسوله شده است):

17:30:26.071591 MPLS (label 16, exp 0, [S], ttl 255)
	0x0000:  0000 0000 ffff ffff ffff aac1 ab58 2fa5  .............X/.
	0x0010:  0806 0001 0800 0604 0001 aac1 ab58 2fa5  .............X/.
	0x0020:  ac1f 0102 0000 0000 0000 ac1f 0101 0000  ................
	0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................

آیا می توانید تفاوت را تشخیص دهید؟ اجازه دهید به شما کمک کنم: چهار بایت اصلی همه صفرها در بار MPLS ارسال شده توسط Arista EOS.

بعد از اتلاف وقت زیاد برای فهمیدن اینکه چه اتفاقی در حال رخ دادن است، پرینت Arista EOS MPLS LFIB قطعه روشن کننده ای بود که من به آن نیاز داشتم:

s2#show mpls route
MPLS forwarding table (Label [metric] Vias) - 4 routes
MPLS next-hop resolution allow default route: False
Metric Codes:
          A - Active metric
Via Type Codes:
          M - MPLS via, LP - LDP pseudowire via,
          I - IP lookup via, V - VLAN via,
          VA - EVPN VLAN aware via, ES - EVPN ethernet segment via,
          VF - EVPN VLAN flood via, AF - EVPN VLAN aware flood via,
          NG - Nexthop group via, BP - BGP pseudowire via,
          VP - VPWS pseudowire via, MSP - Static pseudowire via,
          EL - EVPN E-Tree Leaf Label via

 116384  A[1]
                via M, 10.1.0.5, pop
                    EgressACL: apply
                    directly connected, Ethernet1
                    aa:c1:ab:0d:c2:5e, vlan 1006
 116385  A[1]
                via M, 10.1.0.5, swap 17
                    EgressACL: apply
                    directly connected, Ethernet1
                    aa:c1:ab:0d:c2:5e, vlan 1006
 1040999  [0]
                via VF, vlan1000, control word present
 1047390  [0]
                via V, vlan1000, control word present

Arista EOS انتظار دارد از کلمه کنترل شبه در هنگام flood کردن یک LSP استفاده کند.

زمان برای شیرجه عمیق در RFC 7432 (BGP MPLS مبتنی بر اترنت VPN). در اینجا چیزی است که او در مورد آن می گوید کلمات کنترل در بخش 18 (آرایش قاب ها):

از آنجایی که دستگاه PE همان برچسب تکرار ورودی MPLS را برای همه همتایان در MAC-VRF یکسان تبلیغ می‌کند، می‌توان استدلال کرد که LSP‌های سیلابی MP2P LSP هستند و باید از کلمه کنترل استفاده کنند. یا فردی در تیم Cisco IOS/XE یادداشت را دریافت نکرده است، یا LSPهای flooding را به عنوان LSPهای P2P در نظر گرفته است، یا تصمیم گرفته است که نباید اجباری باشد.

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

هر بار که به سناریوی «EVPN SIP در شبکه است» اشاره می‌کنم، می‌شنوم که فروشندگان ادعا می‌کنند چقدر تست قابلیت همکاری EVPN انجام می‌دهند. اگرچه ممکن است شنیدن این حرف برایم آرامش بخش باشد، اما خیلی به من کمک نکرد. ظاهراً من خیلی احمق هستم که نمی‌توانم EVPN/MPLS MAC-VRF را بین Arista EOS و Cisco IOS/XE کار کنم. لطفا اگر چیزی را از قلم انداختم نظر بدهید.

اطلاعات مرجع

من از موارد زیر استفاده کردم netlab توپولوژی برای ایجاد آزمایشگاه:

---
mpls.ldp: True
evpn.transport: mpls
evpn.vlans: [ red ]
defaults.device: iol
provider: clab

groups:
  _auto_create: True
  hosts:
    members: [ h1, h2 ]
    device: linux
    provider: clab
  switches:
    members: [ dut, s2 ]
    module: [ vlan, mpls, ospf, bgp, evpn ]
    graph.rank: 1
  core:
    members: [ p ]
    module: [ ospf, mpls ]
    device: frr
    provider: clab
    graph.rank: 1
  x_switches:
    members: [ s2 ]
    device: eos
    provider: clab

bgp.as: 65000

vlans:
  red:
    mode: bridge
    prefix:
      ipv4: 172.31.1.0/24
    links: [ dut-h1, s2-h2 ]

links:
- interfaces: [ dut, p ]
- interfaces: [ p, s2 ]