FRRouting نسخه 10.6 وعده داده شده استپشتیبانی BGP IPv6 VTEP“، با ادعای “استقرار EVPN را با استفاده از نقاط پایانی تونل IPv6 در حالی که سازگاری کامل با IPv4 VTEP حفظ می کند، فعال می کند.” البته باید آن را امتحان می‌کردم، و از آنجایی که ما قبلاً EVPN را روی IPv6 داریم که روی Arista EOS اجرا می‌شود (از نسخه Netlab نسخه 26.01)، تصمیم گرفتم یک آزمایشگاه ساده با یک دستگاه Arista cEOS با نسخه 4.35.2F و آخرین کانتینر FRRouting راه‌اندازی کنم.
وقتی کار نکرد، به خصوص تعجب نکردم. در حالی که Arista مسیرهای FRRouting EVPN را می پذیرفت، شبح FRRouting BGP مسیرهای ارسال شده توسط Arista EOS را رد می کرد:
پیام های خطا ایجاد شده توسط شبح FRRouting BGP
2026-04-02 15:04:10 [INFO] bgpd: [N9HHH-F8H1M] %ADJCHANGE: neighbor 2001:db8:0:1::1(Unknown) in vrf default Up
2026-04-02 15:04:10 [ERR!] bgpd: [ZYQP8-F7JMG][EC 33554440] Bad PMSI tunnel attribute length 21 for IR
2026-04-02 15:04:10 [WARN] bgpd: [RWQFK-BA2JR][EC 33554488] 2001:db8:0:1::1: Attribute PMSI_TUNNEL_ATTRIBUTE, parse error - treating as withdrawal
2026-04-02 15:04:10 [ERR!] bgpd: [QWG8G-NT6EJ][EC 33554455] 2001:db8:0:1::1(Unknown) rcvd UPDATE with errors in attr(s)!! Withdrawing route.
بررسی مسیرهای EVPN در جدول Arista EOS BGP جزئیات کثیف را نشان می دهد: رمزگذاری PMSI_TUNNEL_ATTRIBUTE بین دو پیاده سازی متفاوت است.
مسیرهای Arista EOS IMET
swe#show bgp evpn route-type imet detail
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 65000
BGP routing table entry for imet 2001:db8:0:1::1, Route Distinguisher: 10.0.0.1:1000
Paths: 1 available
Local
- from - (0.0.0.0)
Origin IGP, metric -, localpref -, weight 0, tag 0, valid, local, best
Extended Community: Route-Target-AS:65000:1000 TunnelEncap:tunnelTypeVxlan
VNI: 101000
PMSI Tunnel: Ingress Replication, MPLS Label: 101000, Leaf Information Required: false, Tunnel ID: 2001:db8:0:1::1
BGP routing table entry for imet 2001:db8:0:2::1, Route Distinguisher: 10.0.0.2:1000
Paths: 1 available
Local
2001:db8:0:2::1 from 2001:db8:0:2::1 (10.0.0.2)
Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, internal, best
Extended Community: Route-Target-AS:65000:1000 TunnelEncap:tunnelTypeVxlan
VNI: 101000
PMSI Tunnel: Ingress Replication, MPLS Label: 101000, Leaf Information Required: false, Tunnel ID: 0.0.0.0
همانطور که از چاپ مشاهده می کنید، Arista EOS از یک آدرس IPv6 به عنوان شناسه تونل PMSI (2001:db8:0:1::1) استفاده می کند، در حالی که FRRouting از آدرس IPv4 (0.0.0.0) استفاده می کند، حتی اگر پرش بعدی مسیر EVPN (آدرس IP VTEP) یک آدرس IPv6 باشد. این هنوز هم خوب است (حداقل Arista EOS این را تشخیص می دهد)، اما FRRouting در مسیر EVPN با یک پرش بعدی IPv6 پارس می کند. و IPv6 PMSI ID تونل و آن را رد می کند.
مشخصه PMSI Tunnel دقیقا چیست؟
ویژگی PMSI Tunnel (تعریف شده در RFC 6514) استفاده می شود. با IMET (نوع 3) مسیرهای EVPN تا به همسایگان EVPN بگوییم که دستگاه از کدام تکرار BUM استفاده می کند. مقادیر رایجی که در یک محیط EVPN/VXLAN خواهید دید عبارتند از 3/4 (برای تکرار چندپخشی) یا 6 (برای تکرار ورودی) (مقادیر معتبر را می توان در یک رجیستری IANA یافت).
فرمت ویژگی PMSI Tunnel در بخش 5 RFC 6514 تعریف شده است که شناسه تونل را به صورت تعریف می کند. با طول متغیر فیلد (که باعث می شود هر دو آدرس IPv4 و IPv6 مقادیر قابل قبولی داشته باشند). همچنین می گوید:
هنگامی که نوع تونل روی Inbound Replication تنظیم می شود، شناسه تونل آدرس IP نقطه پایانی تونل unicast PE محلی را حمل می کند، که باید آدرس نقطه پایانی مقصد آن PE برای تونل باشد.
یکی می تواند به کامل تبدیل شود فرشتگان روی سنجاق می رقصند حالت دهید و استدلال کنید که آیا مقدار 0.0.0.0 یک مقدار معتبر برای شناسه تونل است یا خیر، اما به نظر می‌رسد اکثر پیاده‌سازی‌ها یک رویکرد عقل سلیم دارند و می‌گویند: «اوم، احتمالاً به این معنی است آن را نادیده بگیرید(یا نمی‌توانیم از FRRouting به‌عنوان یک دستگاه کاوشگر در آزمایش‌های یکپارچه‌سازی EVPN-over-IPv4 استفاده کنیم). رد کردن IPv6 به‌عنوان یک ویژگی تونل PMSI هنگام اجرای EVPN از طریق IPv6 احتمالاً یک گام بسیار دور است، یا شاید من فقط یک دکمه geek را گم کرده‌ام، در این صورت می‌خواهم بخش‌های مربوطه را در مورد آن بشنوم. پیکربندی:
router bgp 65000
bgp router-id 10.0.0.2
no bgp default ipv4-unicast
bgp bestpath as-path multipath-relax
neighbor 2001:db8:0:1::1 remote-as 65000
neighbor 2001:db8:0:1::1 description swe
neighbor 2001:db8:0:1::1 update-source lo
use-underlays-nexthop-weight
!
address-family ipv6 unicast
network 2001:db8:0:2::/64
neighbor 2001:db8:0:1::1 activate
neighbor 2001:db8:0:1::1 next-hop-self
exit-address-family
!
address-family l2vpn evpn
neighbor 2001:db8:0:1::1 activate
advertise-all-vni
vni 101000
rd 10.0.0.2:1000
route-target import 65000:1000
route-target export 65000:1000
exit-vni
advertise-svi-ip
advertise ipv6 unicast
exit-address-family
exit
می خواهید آن را امتحان کنید؟
در اینجا توپولوژی آزمایشگاهی است که من استفاده کردم (فقط اگر بخواهید رفتار را بازتولید یا اصلاح کنید):
---
provider: clab
addressing:
loopback:
ipv6: 2001:db8::/48
ipv4: False
p2p:
ipv4: False
ipv6: True
bgp.as: 65000
defaults.vxlan.use_v6_vtep: True
vlans:
tenant.links: [ swe, swf ]
module: [ ospf, bgp, vlan, vxlan, evpn ]
nodes:
swe.device: eos
swf.device: frr
links: [ swe-swf ]
در نهایت، یک یادداشت به مهندسان بزرگی که FRRouting را توسعه می‌دهند: در روزهایی که دستگاه‌های شبکه رایگان برای دانلود به‌عنوان ماشین‌های مجازی یا کانتینر اجرا می‌شوند، لطفاً تست‌های قابلیت همکاری را روی ویژگی‌های جدید اجرا کنید. در برخی موارد، netlab ممکن است بتواند به کمک کند و پیکربندی های دستگاه لازم را در دستگاه های غیر FRR ایجاد کند.
