آشنایی با سیسکو VXLAN

از محدودیت VLAN تا فابریک Overlay دیتاسنتر

اگر روی سوئیچ قدیمی کاتالیست هنوز برای هر tenant یک VLAN می‌سازید و به سقف ۴۰۹۴ نزدیک شده‌اید، یا برای جابه‌جایی VM بین دو رک مجبورید STP و لینک‌های مسدود را تحمل کنید، همان جایی است که حرف از VXLAN جدی می‌شود. در یک دهه اخیر مراکز داده و شبکه‌های سازمانی عوض شده‌اند: به‌جای چند سرور فیزیکی، هزاران ماشین مجازی و کانتینر روی تعداد محدودی host؛ و بخش عمده ترافیک دیگر شمال–جنوب نیست — شرق–غرب بین خود سرورهاست. شبکه سنتی مبتنی بر VLAN و STP برای این دنیا طراحی نشده بود.

این مطلب همان آشنایی با سیسکو VXLAN است: تعریف و تاریخچه، پنج مشکلی که RFC صورت‌مسئله کرده، اصطلاحات، underlay و overlay، جزئیات بایت‌به‌بایت پکت و سربار IPv4/IPv6، مسیر گام‌به‌گام یک فریم، BUM (Multicast در برابر Ingress Replication)، کنترل‌پلن Flood-and-Learn در برابر EVPN، Anycast Gateway و Symmetric IRB، نقش spine/leaf، امنیت، تجهیزات سیسکو، کانفیگ نمونه کامل leaf+spine روی NX-OS و تفاوت‌های Catalyst 9300، عیب‌یابی از پایین به بالا، و مقایسه با FabricPath و OTV و Geneve — با منابع رسمی سیسکو و اسلایدهای Cisco Live، نه خلاصه وبلاگ.

در ایران هنوز خیلی‌ها VXLAN را با «VLAN روی IP» یکی می‌دانند و تمام. روی کاغذ درست است؛ در عمل بدون فهم VTEP، VNI، MTU underlay و تفاوت Flood-and-Learn با BGP EVPN، همان شبکه‌ای می‌سازید که east-west را قورت می‌دهد ولی troubleshootingش کابوس است. اگر قبلاً مطلب Cisco NX-OS – آشنایی با سیسکو NX-OS را خوانده‌اید، اینجا لایه بعدی همان داستان Nexus است. برای تصویر بزرگ‌تر SDN و ACI هم مسیر سیسکو SDN را ببینید.

VXLAN چیست؟

Virtual Extensible LAN (VXLAN) یک طرح overlay لایه ۲ روی زیرساخت لایه ۳ است. استاندارد IETF آن RFC 7348 است. ایده ساده است: فریم اترنت اصلی را داخل یک هدر VXLAN می‌گذارید، بعد داخل UDP و IP می‌فرستید — سیسکو به این می‌گوید MAC-in-UDP. نتیجه: می‌توانید یک VLAN منطقی را روی یک هسته IP (حتی بین دو سایت) بکشید، بدون اینکه کل هسته را به دامنه لایه ۲ و STP تبدیل کنید.

به زبان ساده: شبکه underlay یک بزرگراه IP است و هر فریم اترنت یک محموله. VXLAN محموله را داخل یک کانتینر استاندارد می‌گذارد، برچسب VNI می‌زند، و آدرس مبدأ و مقصد را روی کانتینر می‌نویسد. روترها و سوئیچ‌های مسیر فقط برچسب بیرونی را می‌خوانند و کاری به محتوای کانتینر ندارند.

بر اساس Overview رسمی Nexus 9000 NX-OS VXLAN Configuration Guide:

• شناسه سگمنت VXLAN بیست‌وچهار بیتی است (VNID / VNI)؛ تا حدود ۱۶ میلیون سگمنت در یک دامنه اداری، در برابر سقف حدود ۴۰۹۶ برای VLAN کلاسیک (۱۲ بیت).
• پکت‌های VXLAN روی underlay با هدر لایه ۳ جابه‌جا می‌شوند و می‌توانند از ECMP و aggregation استفاده کنند؛ برخلاف لایه ۲ کلاسیک که برای جلوگیری از loop مسیرها را block می‌کند.
• دستگاهی که encapsulate و decapsulate می‌کند VTEP (VXLAN Tunnel Endpoint) نام دارد.

سیسکو روی Nexus 9000 تأکید می‌کند که gateway سخت‌افزاری VXLAN با line-rate برای همه اندازه فریم کار می‌کند؛ یعنی این کار را نباید با تونل نرم‌افزاری کند روی CPU سوئیچ اشتباه گرفت.

ویژگی	مقدار
نام کامل	Virtual eXtensible Local Area Network
مرجع	RFC 7348 (Informational، اوت ۲۰۱۴)
روش کپسوله‌سازی	MAC-in-UDP (فریم لایه ۲ داخل UDP/IP)
شناسه سگمنت	VNI ۲۴ بیت (~۱۶ میلیون شبکه)
پورت UDP مقصد	4789 (تخصیص IANA)
اندازه هدر VXLAN	۸ بایت
سربار کل با underlay IPv4	~۵۰ بایت (با Outer 802.1Q حدود ۵۴)
Control Plane رایج	Flood & Learn یا MP-BGP EVPN

تاریخچه و استاندارد

VXLAN فناوری انحصاری سیسکو نیست. نویسندگان RFC 7348 از شرکت‌هایی مثل Cisco، VMware، Arista، Broadcom، Intel و Red Hat بودند و سند در اوت ۲۰۱۴ به‌صورت Informational منتشر شد — یعنی رسماً در مسیر Standards Track نیست؛ ولی امروز استاندارد عملی صنعت است و تقریباً همه تولیدکنندگان تجهیزات شبکه، هایپروایزرها و حتی هسته لینوکس از آن پشتیبانی می‌کنند.

خود RFC 7348 فقط data plane و روش یادگیری مبتنی بر multicast را تشریح می‌کند. کنترل‌پلن مدرن و استاندارد آن — یعنی BGP EVPN — در RFC 7432 و RFC 8365 تعریف شد و سیسکو آن را پایه فابریک‌های دیتاسنتری خود قرار داده است. روی کاغذ «هر دو استاندارد باز»؛ در عمل روی Nexus مسیر روزمره همان MP-BGP EVPN است، نه flood-and-learn خالص.

چرا VXLAN؟ پنج مشکل لایه ۲ سنتی

قبل از اینکه دستور feature nv overlay بزنید، باید بدانید چرا اصلاً آمده. VXLAN برای حل پنج مشکل مشخص شبکه‌های لایه ۲ سنتی ساخته شد — همان‌هایی که بخش Problem Statement در RFC 7348 برشمرده است:

1. سقف VLAN حدود ۴۰۹۴. شناسه VLAN در هدر 802.1Q فقط ۱۲ بیت است. در دیتاسنترهای مجازی‌شده و چندمستأجری، وقتی هر مستأجر چند VLAN می‌خواهد، این سقف خیلی زود پر می‌شود.
2. STP و لینک‌های بلااستفاده. Spanning Tree برای جلوگیری از لوپ، لینک‌های افزونه را مسدود می‌کند. یعنی برای پورت‌ها و لینک‌هایی هزینه می‌کنید که عملاً ترافیک از آن‌ها عبور نمی‌کند. در VXLAN بسته‌ها بر اساس هدر لایه ۳ جابه‌جا می‌شوند و با ECMP از همه مسیرهای موجود استفاده می‌کنند.
3. پر شدن جدول MAC در ToR. با مجازی‌سازی، به‌جای یک MAC به ازای هر سرور، ده‌ها یا صدها MAC داریم. اگر جدول MAC پر شود، سوئیچ فریم‌های مقصد نامعلوم را flood می‌کند. در VXLAN سوئیچ‌های هسته فقط آدرس IP تونل‌ها (VTEPها) را می‌بینند، نه تک‌تک MAC ماشین‌ها.
4. چندمستأجری و همپوشانی آدرس. مستأجرهای مختلف ممکن است MAC و حتی آدرس IP تکراری داشته باشند. هر VNI دامنه خودش را مشخص می‌کند؛ پس MACهای تکراری در دو VNI مختلف تداخلی با هم ندارند.
5. جابه‌جایی VM بین رک و pod. جابه‌جایی زنده ماشین مجازی (مثل vMotion) به یک شبکه لایه ۲ کشیده‌شده نیاز دارد. کشیدن لایه ۲ با VLAN و STP بین رک‌ها ریسک broadcast storm و دامنه خرابی بزرگ دارد. VXLAN لایه ۲ را روی یک زیرساخت پایدار لایه ۳ گسترش می‌دهد، بدون اینکه دامنه خرابی لایه ۲ به زیرساخت فیزیکی منتقل شود.

محدودیت شبکه سنتی	پاسخ VXLAN
سقف VLAN حدود ۴۰۹۴	VNI ۲۴ بیتی → مقیاس multi-tenant واقعی
STP و لینک‌های blocking در هسته L2 بزرگ	هسته IP با ECMP؛ همه لینک‌ها فوروارد می‌کنند
پر شدن جدول MAC در ToR / هسته	هسته فقط IP VTEP را می‌بیند
جابه‌جایی VM/Container بدون عوض کردن IP/MAC	سگمنت L2 روی underlay L3 کشیده می‌شود
جداسازی tenant روی یک سخت‌افزار مشترک	VNI + VRF روی همان فابریک فیزیکی

کتاب رسمی سیسکو A Modern, Open, and Scalable Fabric: VXLAN EVPN صریح می‌گوید VLAN و STP برای دیتاسنتر مدرن محدودکننده‌اند؛ VXLAN extensibility و انعطاف می‌آورد، ولی بدون کنترل‌پلن هوشمند (EVPN) همان flood-and-learn مقیاس را می‌خورد. پس VXLAN به‌تنهایی نصف راه‌حل است؛ نصف دیگر معمولاً MP-BGP EVPN است.

جدول VXLAN در برابر VLAN

معیار	VLAN (IEEE 802.1Q)	VXLAN
طول شناسه	۱۲ بیت	۲۴ بیت
تعداد سگمنت	~۴۰۹۴	~۱۶ میلیون
بستر انتقال	لایه ۲ اترنت	لایه ۳ (UDP/IP)
جلوگیری از لوپ	STP با مسدودسازی لینک	مسیریابی ECMP؛ همه لینک‌ها فعال
گستره	محدود به دامنه لایه ۲	هرجا IP برسد، حتی بین دیتاسنترها
یادگیری MAC	Flood & Learn	Flood & Learn یا BGP EVPN
چندمستأجری	محدود	VRF + VNI برای هر مستأجر

اصطلاحات کلیدی

قبل از ورود به جزئیات، این واژه‌ها را مرور کنید؛ در ادامه مدام با آن‌ها سروکار دارید. تعاریف بر پایه RFC 7348 و راهنمای پیکربندی VXLAN سیسکو است.

اصطلاح	معنی	نکته کاربردی
VNI / VNID	شناسه ۲۴ بیتی هر سگمنت overlay	معادل ID VLAN، اما سراسری در کل فابریک
VTEP	VXLAN Tunnel End Point؛ نقطه شروع و پایان تونل	کپسوله و دکپسوله می‌کند؛ سخت‌افزاری یا نرم‌افزاری
NVE / nve1	Network Virtualization Edge؛ اینترفیس منطقی VTEP در سیسکو	در NX-OS و IOS XE با interface nve1 ساخته می‌شود
Underlay	شبکه فیزیکی IP که بسته‌های VXLAN را جابه‌جا می‌کند	وظیفه اصلی: رساندن VTEPها به یکدیگر
Overlay	شبکه مجازی ساخته‌شده روی underlay	شامل تونل‌ها و کنترل‌پلن
Flood & Learn	یادگیری MAC از روی ترافیک داده	روش اولیه مبتنی بر RFC 7348؛ وابسته به multicast
MP-BGP EVPN	کنترل‌پلن مبتنی بر BGP برای پخش MAC و IP	روش استاندارد و توصیه‌شده امروز
Leaf / Spine	لایه دسترسی و هسته در معماری Clos	معمولاً leafها VTEP هستند؛ spine نه
Border Leaf / BGW	leaf متصل به بیرون فابریک / gateway بین سایت‌ها	ورود و خروج north-south و بین دیتاسنترها
Anycast Gateway	gateway پیش‌فرض با IP و MAC یکسان روی همه leafها	اولین hop هر سرور، leaf محلی‌اش است
L2VNI	VNI متناظر با یک VLAN / bridge domain	برای bridging داخل یک subnet
L3VNI	VNI متناظر با یک VRF (مستأجر)	برای routing بین subnetها در EVPN
BUM	Broadcast، Unknown unicast و Multicast	ترافیکی که باید به چند VTEP کپی شود

Underlay و Overlay ؛ دو لایه که باید جدا فکر کنید

این بخش را اگر قاطی کنید، کل طراحی می‌لرزد.

Underlay شبکه فیزیکی IP است: لینک‌های leaf به spine، آدرس‌دهی loopbackها، OSPF یا IS-IS یا eBGP، و MTU. کار underlay طبق سند سیسکو این است که reachability بین VTEPها را advertise کند و حمل قابل‌اعتماد برای ترافیک encapsulate‌شده فراهم کند. underlay معمولاً «ساده و سریع» طراحی می‌شود؛ tenant و MAC و VLAN مشتری داخلش نیستند.

Overlay شبکه مجازی روی همان underlay است: تونل‌های VXLAN + کنترل‌پلن که می‌گوید کدام MAC/IP پشت کدام VTEP است. فریم اصلی tenant داخل overlay زندگی می‌کند؛ underlay فقط IP بیرونی VTEP مبدأ و مقصد را می‌بیند. از دید سرور و ماشین مجازی، همان VLAN و subnet همیشگی است؛ هیچ تغییری در سرور لازم نیست.

ملاحظات کلیدی طراحی underlay طبق راهنمای رسمی سیسکو (Configuring the Underlay):

• مسیریابی unicast: هر پروتکل قابل‌استفاده است؛ OSPF، IS-IS یا eBGP. توصیه رایج سیسکو: یک IGP ساده (OSPF یا IS-IS) برای underlay و iBGP برای overlay.
• آدرس‌دهی: لینک‌های نقطه‌به‌نقطه با ماسک /30 یا /31، یا IP unnumbered که آدرس کمتری مصرف می‌کند.
• نوع شبکه OSPF: حتماً point-to-point تا انتخاب DR/BDR و LSA نوع ۲ حذف شود.
• MTU: مقدار ۹۰۰۰ تا ۹۲۱۶ روی تمام اینترفیس‌های مسیر بین VTEPها؛ این عدد برای سربار VXLAN کافی است و نیازی به fragmentation نمی‌ماند. MTU دو سر هر لینک باید یکسان باشد.
• Multicast (اختیاری): برای ترافیک BUM با PIM ASM و Anycast RP، یا BiDir PIM، یا بدون multicast با Ingress Replication.
• Loopbackها: معمولاً loopback0 برای Router-ID و BGP، و loopback1 آدرس VTEP (source-interface اینترفیس NVE).

موضوع	Underlay	Overlay
ماهیت	شبکه فیزیکی IP	شبکه‌های مجازی لایه ۲ و ۳
آدرس‌ها	Loopbackها و لینک‌های P2P	MAC و IP سرورها و VMها
پروتکل‌ها	OSPF / IS-IS / eBGP؛ در صورت نیاز PIM	VXLAN + MP-BGP EVPN
تغییرات	نادر؛ هنگام افزودن سوئیچ	مداوم؛ با هر VM، VLAN یا مستأجر جدید
دامنه خرابی	کوچک، مثل هر شبکه مسیریابی‌شده	محدود به هر VNI

جریان پکت از دید سیسکو:

1. سرور فریم را به VTEP مبدأ می‌دهد.
2. VTEP بر اساس MAC مقصد (و در سناریوی L3 بر اساس IP) تصمیم می‌گیرد next-hop کدام VTEP است.
3. فریم را با VXLAN encapsulate می‌کند و به شبکه IP می‌سپارد.
4. underlay پکت را با هدر بیرونی به VTEP مقصد می‌رساند (معمولاً از spine عبور می‌کند).
5. VTEP مقصد decapsulate می‌کند و فریم را به سرور می‌دهد.

نکته عملی: VTEPها خودشان عضو underlay هم هستند؛ اگر loopback VTEP در IGP نباشد، تونل بالا نمی‌آید ولو کانفیگ nve1 بی‌نقص باشد.

VTEP چیست و نقش Leaf / Spine / Border

هر VTEP دو وجه دارد: اینترفیس لایه ۲ به سمت endpoint محلی، و اینترفیس لایه ۳ به سمت transport با یک IP یکتا (معمولاً loopback). همان IP می‌شود آدرس مبدأ/مقصد encapsulate.

در فابریک leaf/spine رایج سیسکو:

• Leaf: جایی که سرور، firewall، و اکثر VTEPها می‌نشینند.
• Spine: interconnect بین leafها؛ در بسیاری طراحی‌ها spine فقط underlay است و VTEP نیست (به‌خصوص وقتی spine نقش route-reflector برای EVPN دارد).
• Border Leaf: خروجی فابریک به اینترنت، WAN، یا DCI.
• Service Leaf: اتصال فایروال و سرویس‌های لایه ۴ تا ۷ / load balancer.
• Border Gateway (BGW): اتصال چند سایت در معماری Multi-Site.

جزئیات پکت VXLAN ؛ از Outer MAC تا VNI

این بخش را خط‌به‌خط نگه دارید؛ در فیلد همان چیزی است که Wireshark و Ethanalyzer نشان می‌دهند. طبق اسلایدهای رسمی Cisco Live (BRKDCN-1621 / BRKDCN-1999) و Configuration Guide سیسکو، بسته VXLAN همان فریم اترنت اصلی است که چهار هدر جدید جلوی آن نشسته است.

فیلد	اندازه تقریبی	معنی عملی
Outer Ethernet (MAC SA/DA)	۱۴ بایت	فریم فیزیکی hop فعلی روی underlay
Outer 802.1Q (اختیاری)	۴ بایت	اگر لینک underlay tagged باشد
Outer IP (SA/DA)	۲۰ بایت (IPv4) / ۴۰ بایت (IPv6)	IP VTEP مبدأ و مقصد
Outer UDP	۸ بایت	مقصد استاندارد پورت ۴۷۸۹ (روی Nexus 9000 غیرقابل‌تغییر)
VXLAN Header	۸ بایت	شامل Flags و VNI ۲۴ بیتی
Inner Ethernet Frame	متغیر	فریم اصلی tenant (MAC داخلی + اختیاری 802.1Q + payload)

داخل هدر ۸ بایتی VXLAN (خلاصه Cisco Live و RFC 7348):

• Flags یک بایت: الگوی R R R R I R R R ؛ بیت I باید ۱ باشد تا VNI معتبر محسوب شود.
• یک بایت Reserved
• VNI سه بایت (۲۴ بیت) → ۱ تا ۱۶٬۷۷۷٬۲۱۵
• سه بایت Reserved پایانی (بعدها برای افزونه‌هایی مثل VXLAN-GPO / حمل SGT در سیسکو استفاده شد)

UDP سورس‌پورت معمولاً از هش هدر داخلی ساخته می‌شود (ترجیحاً در بازه ۴۹۱۵۲ تا ۶۵۵۳۵) تا ECMP در underlay بین چند مسیر leaf–spine پخش شود. اگر همه ترافیک یک سورس‌پورت ثابت بگیرند، ECMP عملاً یک مسیر می‌شود — دقیقاً همان چیزی که در عیب‌یابی «چرا فقط یک uplink داغ است» باید چک کنید. در IPv4 چک‌سام UDP معمولاً صفر ارسال می‌شود و گیرنده باید بسته با checksum صفر را بپذیرد.

جزء	Underlay IPv4	Underlay IPv6
Outer Ethernet	۱۴	۱۴
Outer IP	۲۰	۴۰
Outer UDP	۸	۸
VXLAN Header	۸	۸
مجموع سربار (بایت)	۵۰	۷۰
حداقل MTU underlay برای فریم ۱۵۰۰ بایتی	۱۵۵۰	۱۵۷۰

نکته حیاتی RFC: طبق RFC 7348، VTEP هرگز بسته VXLAN را fragment نمی‌کند و VTEP مقصد می‌تواند قطعه‌های fragment‌شده را بی‌صدا دور بیندازد. پس MTU ناکافی در underlay یعنی گم شدن بی‌صدای بسته‌های بزرگ. به همین دلیل سیسکو MTU بزرگ (۹۲۱۶) را روی تمام مسیر توصیه می‌کند. اگر Outer 802.1Q روی Ethernet بیرونی باشد، ۴ بایت دیگر اضافه می‌شود (~۵۴ بایت سربار IPv4).

معنی عملی در رک ایران: اگر underlay روی MTU ۱۵۰۰ مانده باشد و فریم مهمان نزدیک ۱۵۰۰ باشد، یا fragment می‌خورید یا drop. برای VXLAN معمولاً underlay را به ۹۰۰۰ یا حداقل ۱۵۵۰+ می‌برند؛ عدد دقیق را از طراحی و کارت‌خط خودتان بگذارید، نه از حافظه. علامت کلاسیک: ping کوچک موفق، انتقال فایل / HTTPS / backup قطع.

مسیر گام‌به‌گام پکت: Host-A تا Host-B

فرض کنید Host-A پشت Leaf-1 و Host-B پشت Leaf-2 هستند؛ هر دو در VLAN 10 و این VLAN روی هر دو leaf به VNI 10010 نگاشت شده است. VTEP Leaf-1 برابر 10.0.1.11 و VTEP Leaf-2 برابر 10.0.1.12 است. مسیر یک فریم unicast از A به B بر پایه RFC 7348 و راهنمای underlay سیسکو چنین است:

1. ارسال از سرور: Host-A یک فریم معمولی اترنت به MAC-B می‌فرستد. سرور هیچ اطلاعی از VXLAN ندارد.
2. تصمیم در VTEP مبدأ: Leaf-1 از روی VLAN ورودی، VNI 10010 را پیدا می‌کند؛ سپس در جدول خودش می‌بیند MAC-B پشت VTEP 10.0.1.12 است.
3. کپسوله‌سازی: Leaf-1 هدر VXLAN با VNI 10010، هدر UDP با پورت مقصد ۴۷۸۹ و پورت مبدأ هش‌شده، هدر IP با مبدأ 10.0.1.11 و مقصد 10.0.1.12، و در نهایت هدر اترنت بیرونی را اضافه می‌کند.
4. عبور از underlay: Spineها بسته را فقط بر اساس IP مقصد بیرونی مسیریابی می‌کنند. به کمک هش پورت مبدأ UDP، جریان‌های مختلف روی مسیرهای مختلف ECMP پخش می‌شوند. Spine فقط هدر IP بیرونی را می‌بیند.
5. دکپسوله‌سازی: Leaf-2 بسته را دریافت می‌کند، VNI را بررسی می‌کند، هدرهای بیرونی را برمی‌دارد و فریم اصلی را روی VLAN 10 به Host-B تحویل می‌دهد.
6. یادگیری: در روش Flood & Learn، Leaf-2 همین‌جا یاد می‌گیرد MAC-A پشت 10.0.1.11 است. در BGP EVPN این اطلاعات از قبل با BGP اعلام شده است.

اگر مقصد ناشناخته باشد؟ وقتی Host-A هنوز MAC-B را نمی‌شناسد، اول یک ARP Request (broadcast) می‌فرستد. این فریم باید به همه VTEPهای عضو VNI 10010 برسد. در روش کلاسیک، VTEP آن را داخل یک بسته multicast متناظر با VNI می‌فرستد. پاسخ ARP به‌صورت unicast برمی‌گردد و از آن به بعد مسیر مثل مراحل بالاست.

ترافیک BUM: Multicast در برابر Ingress Replication

BUM یعنی Broadcast، Unknown unicast و Multicast؛ ترافیکی که باید به همه VTEPهای یک VNI برسد. حتی با BGP EVPN فابریک، همچنان به روشی برای رساندن این ترافیک نیاز دارید (Configuring the Underlay سیسکو). دو روش اصلی وجود دارد.

روش ۱ — Multicast در underlay: هر VNI به یک گروه multicast نگاشت می‌شود و همه VTEPهای آن عضو گروه می‌شوند. VTEP مبدأ فقط یک نسخه می‌فرستد و شبکه underlay آن را روی درخت multicast تکثیر می‌کند. طبق RFC 7348، VTEPها از Join نوع (*,G) استفاده می‌کنند. رایج‌ترین گزینه PIM ASM با RP روی spineها و Anycast RP برای افزونگی؛ گزینه مقیاس‌پذیرتر BiDir PIM که state مبدأمحور نگه نمی‌دارد. توصیه طراحی سیسکو: RP روی spine، چند RP افزونه، و نگاشت VNIهای مختلف به گروه‌های مختلف برای پخش بار.

روش ۲ — Ingress Replication (Head-End Replication): در این روش underlay هیچ multicastی ندارد. VTEP مبدأ به ازای هر VTEP عضو آن VNI یک نسخه unicast جداگانه می‌سازد و می‌فرستد. فهرست VTEPها یا به‌صورت دستی (static) تعریف می‌شود یا به‌طور خودکار از EVPN Route Type 3 به دست می‌آید. سیسکو Ingress Replication را روی سری Nexus 9000 پشتیبانی می‌کند.

معیار	Multicast در Underlay	Ingress Replication
نیاز به PIM و RP	بله	خیر
تعداد نسخه‌ای که VTEP مبدأ می‌فرستد	یک	به تعداد VTEPهای مقصد
مصرف پهنای باند در لینک‌های leaf	کم	با تعداد VTEP رشد می‌کند
پیچیدگی عملیاتی	بیشتر	کمتر
مناسب برای	فابریک‌های بزرگ با BUM زیاد	فابریک‌های کوچک و متوسط، یا جایی که multicast ممکن نیست

قاعده سرانگشتی: اگر تعداد leafها کم است و در EVPN سرکوب ARP فعال است، Ingress Replication ساده‌ترین انتخاب است. در فابریک‌های بزرگ یا با ترافیک multicast سنگین مستأجرها، multicast در underlay کارایی بهتری دارد. مهاجرت از IR به multicast (یا برعکس) در فابریک در حال بهره‌برداری — به‌گفته سیسکو — پیچیده و همراه با قطعی است؛ پس این تصمیم را از روز اول درست بگیرید.

Control Plane: Flood-and-Learn در برابر BGP EVPN

VXLAN فقط data plane است. سؤال سخت این است: VTEP چطور بفهمد MAC ریموت پشت کدام peer است؟ سیسکو دو روش را پشتیبانی می‌کند؛ روش استاندارد و توصیه‌شده امروز MP-BGP EVPN است.

۱) Flood and Learn (مبتنی بر Multicast)

مدل اولیه RFC 7348: هیچ پروتکل کنترلی جداگانه‌ای نیست. کشف VTEPهای دیگر و یادگیری MACهای دوردست از روی ترافیک داده انجام می‌شود؛ درست مثل یک سوئیچ معمولی. برای هر VNI (یا گروهی از VNIها) یک multicast group در underlay. ترافیک BUM به آن گروه می‌رود؛ VTEPها با conversational learning جدول MAC می‌سازند. روی کاغذ ساده است؛ در مقیاس بزرگ، flooding و وابستگی به multicast underlay دردسر عملیاتی می‌آورد.

۲) MP-BGP EVPN (مسیر توصیه‌شده امروز)

در EVPN یادگیری MAC و IP میزبان‌ها از data plane به control plane منتقل می‌شود. هر VTEP میزبان‌های محلی خود را یاد می‌گیرد و آن‌ها را با address-family به نام l2vpn evpn در BGP اعلام می‌کند. VTEPهای دیگر این مسیرها را دریافت می‌کنند و مستقیم در جدول forwarding نصب می‌کنند — بدون flood.

مزایای رسمی سیسکو روی Nexus 9000:

• کاهش شدید flooding؛ تقریباً حذف پخش unknown unicast وقتی مسیرها با BGP پخش شوند
• ARP/ND suppression محلی روی leaf
• mobility برای VM وقتی MAC/IP روی leaf جدید دیده می‌شود
• Integrated Routing and Bridging (IRB)
• یک address-family واحد برای L2 و L3 overlay
• کشف و احراز هویت: فقط VTEPهایی که از طریق BGP شناخته شده‌اند در فهرست مجاز قرار می‌گیرند؛ ترافیک VXLAN از VTEPهای ناشناس دور ریخته می‌شود. نشست‌های BGP را هم می‌توان با MD5 احراز هویت کرد
• استاندارد باز (RFC 7432 / 8365) مستقل از یک کنترلر خاص

در عمل بیشتر فابریک‌های جدید Nexus در ایران اگر درست طراحی شوند، مسیر EVPN می‌روند نه flood-and-learn خالص. Flood-and-learn را بیشتر در لاب یا مهاجرت موقت می‌بینید.

Route Typeهای مهم EVPN

Route Type	نام	کاربرد در VXLAN
1	Ethernet Auto-Discovery	Multi-Homing استاندارد (ESI) و همگرایی سریع
2	MAC/IP Advertisement	اعلام هر میزبان همراه با MAC و IP؛ پایه ARP Suppression و Host Routing؛ شامل RD، L2VNI و L3VNI
3	Inclusive Multicast Ethernet Tag	اعلام عضویت VTEP در هر VNI؛ ساخت خودکار فهرست Ingress Replication
4	Ethernet Segment	انتخاب Designated Forwarder در Multi-Homing
5	IP Prefix	اعلام subnetها و مسیرهای خارجی (مثلاً از Border Leaf)

طبق راهنمای سیسکو، next-hop مسیر Type 2 همیشه آدرس VTEP مبدأ است و باید در طول مسیر دست‌نخورده بماند.

RD و RT ؛ چندمستأجری به سبک L3VPN

EVPN همان سازوکار آشنای MPLS L3VPN را به ارث برده است. Route Distinguisher (RD) مسیرهای یکسان در VRFهای مختلف را از هم جدا می‌کند. Route Target (RT) به‌صورت BGP Extended Community حمل می‌شود و تعیین می‌کند هر مسیر وارد کدام VRF شود. به همین دلیل ارسال Extended Community روی همه peerهای EVPN الزامی است (send-community extended).

در NX-OS، RD و RT می‌توانند خودکار ساخته شوند: RD از Router-ID و VNI، و RT به شکل AS:VNI. توصیه سیسکو: در فابریک تمام‌سیسکو از حالت خودکار استفاده کنید؛ در محیط چندبرندی و در طراحی eBGP با ASهای مختلف، RT را دستی تنظیم کنید.

Anycast Gateway و Symmetric IRB

تا اینجا درباره bridging در یک subnet صحبت کردیم. اما سرورها باید با subnetهای دیگر و بیرون از فابریک هم ارتباط داشته باشند. EVPN این مسئله را با سه ابزار حل می‌کند: Distributed Anycast Gateway، مدل Symmetric IRB، و Border Leaf. همه جزئیات این بخش از راهنمای طراحی MP-BGP EVPN سیسکو است.

Distributed Anycast Gateway: در شبکه سنتی، gateway یک subnet روی یک یا دو سوئیچ هسته می‌نشیند (با HSRP یا VRRP) و همه ترافیک مسیریابی‌شده باید تا آنجا برود. در EVPN، همه leafهای همان subnet با IP و MAC مجازی کاملاً یکسان gateway هستند. نتیجه: ترافیک هر سرور در اولین hop — یعنی leaf محلی خودش — مسیریابی می‌شود؛ بدون رفت‌وبرگشت اضافه. وقتی VM به leaf دیگری منتقل می‌شود، gateway همان است و حتی لازم نیست دوباره ARP بفرستد. MAC مجازی Anycast Gateway باید روی همه VTEPهای دامنه یکسان باشد.

fabric forwarding anycast-gateway-mac 2020.0000.00aa
interface Vlan10
  vrf member TENANT-A
  ip address 192.168.10.1/24
  fabric forwarding mode anycast-gateway

Symmetric در برابر Asymmetric IRB: در Symmetric IRB دو مفهوم جدید داریم. اول L3VNI: هر VRF مستأجر یک VNI اختصاصی دارد که باید روی همه VTEPها یکسان باشد و تعیین می‌کند بسته در کدام VRF مسیریابی شود. دوم Router MAC: هر VTEP یک MAC سیستمی دارد که با BGP اعلام می‌شود و در بسته‌های مسیریابی‌شده به‌عنوان MAC مقصد داخلی نوشته می‌شود.

مسیر یک بسته بین دو subnet در Symmetric IRB:

1. سرور بسته را به MAC مجازی Anycast Gateway روی leaf محلی می‌فرستد.
2. Leaf مبدأ در VRF مستأجر lookup لایه ۳ انجام می‌دهد؛ MAC مقصد داخلی را به Router MAC leaf مقصد تغییر می‌دهد و بسته را با L3VNI کپسوله می‌کند.
3. Leaf مقصد پس از دکپسوله می‌بیند MAC مقصد متعلق به خودش است؛ در VRF مشخص‌شده با L3VNI دوباره lookup می‌کند و بسته را به سرور مقصد تحویل می‌دهد.

معیار	Asymmetric IRB	Symmetric IRB
Lookup در VTEP مبدأ	Bridging و Routing	Bridging و Routing
Lookup در VTEP مقصد	فقط Bridging	Routing و Bridging
VNI داخل هدر بسته مسیریابی‌شده	L2VNI مقصد	L3VNI مخصوص VRF
آنچه هر VTEP باید داشته باشد	همه L2VNIهای فابریک	فقط VNIهای محلی + L3VNI
مقیاس‌پذیری جدول ARP/MAC	ضعیف	خوب
پیاده‌سازی سیسکو (NX-OS)	—	✔ (مسیر استاندارد)

ارتباط با بیرون (Border Leaf): Border Leaf داخل فابریک مثل هر VTEP دیگر در EVPN صحبت می‌کند و در هر VRF مستأجر با روتر یا فایروال لبه با eBGP یا OSPF مسیر رد و بدل می‌کند (معمولاً VRF-lite با subinterface برای هر مستأجر). مسیرهای بیرونی به‌صورت EVPN Route Type 5 به داخل فابریک اعلام می‌شوند. سیسکو توصیه می‌کند مسیرهای بیرونی تا حد امکان summarize شوند یا فقط یک default به داخل اعلام شود، و در جهت مخالف فقط prefixها (نه host routeهای /32) به بیرون فرستاده شوند.

معماری Spine-Leaf و طراحی فابریک

فابریک مبتنی بر VXLAN BGP EVPN معمولاً یک Clos سه‌مرحله‌ای (Leaf و Spine) است؛ در مقیاس خیلی بزرگ با لایه Super-Spine پنج‌مرحله‌ای. هر leaf به همه spineها وصل است و هیچ leafی به leaf دیگر مستقیم وصل نیست. نتیجه: هر دو leaf دقیقاً دو hop از هم فاصله دارند (Fundamental Design and Implementation Guide سیسکو).

Spine هیچ اطلاعاتی از VLAN، MAC، ARP یا VRF مستأجرها نگه نمی‌دارد و فقط مسیرهای EVPN را منعکس می‌کند. به همین دلیل پیکربندی آن ساده است. سیسکو توصیه می‌کند نقش‌های Border Gateway از Spine جدا شوند تا طراحی ماژولار، عیب‌یابی ساده‌تر و ریسک تغییرات کمتر باشد.

• برای پورت بیشتر: leaf اضافه کنید.
• برای پهنای باند بیشتر: spine اضافه کنید؛ هر spine جدید یک مسیر ECMP تازه و نسبت oversubscription پایین‌تر می‌آورد.
• برای افزودن امن spine جدید در OSPF: از max-metric router-lsa استفاده کنید تا سوئیچ تا پایان تست در مسیر ترافیک قرار نگیرد؛ معادل آن در IS-IS دستور set-overload-bit on-startup است.

IGP یا eBGP برای underlay؟ توصیه صریح سیسکو: IGP (OSPF یا IS-IS) در underlay و iBGP برای overlay. دلیل: جدا بودن وظایف دو پروتکل باعث می‌شود خرابی یکی دیگری را از کار نیندازد. طراحی تمام‌eBGP هم کاملاً پشتیبانی می‌شود؛ در آن صورت هر leaf AS جدا دارد، spineها next-hop را تغییر نمی‌دهند، و دستور retain route-target all روی spine لازم است.

vPC و Anycast VTEP (خلاصه): برای اتصال دوطرفه سرورها، دو leaf به‌صورت vPC کار می‌کنند. اینترفیس NVE متصل به loopback دو آدرس دارد: یک IP primary یکتا برای هر سوئیچ و یک IP secondary مشترک (VIP یا Anycast VTEP). بقیه فابریک این جفت را یک VTEP واحد می‌بیند. نکات کلیدی: loopback مربوط به BGP/Router-ID (loopback0) از loopback مربوط به NVE (loopback1) جدا باشد؛ نگاشت VLAN به VNI و آدرس secondary روی هر دو عضو vPC یکسان باشد؛ در غیر این صورت سوئیچ secondary اینترفیس NVE را خاموش می‌کند. جایگزین استاندارد vPC، روش EVPN Multi-Homing با ESI است که با Route Typeهای ۱ و ۴ کار می‌کند.

Use caseهای واقعی

سناریو	مسئله	نقش VXLAN / راهکار سیسکو
دیتاسنتر leaf/spine و ابر خصوصی	رشد سرورها، VLAN زیاد، STP	لایه ۲ و ۳ مجازی روی underlay مسیریابی‌شده؛ Nexus 9000 با VXLAN BGP EVPN و NDFC
جابه‌جایی زنده VM (vMotion)	بین رک و pod نیاز به لایه ۲ مشترک	کشیدن subnet روی کل فابریک با Distributed Anycast Gateway
چندمستأجری / Colocation	هر مستأجر شبکه و آدرس مستقل می‌خواهد	VNI برای لایه ۲ + L3VNI/VRF برای لایه ۳؛ MP-BGP EVPN با RD و RT
DCI و DR بین دیتاسنترها	اتصال چند سایت با حفظ ایزولاسیون خرابی	VXLAN EVPN Multi-Site با Border Gateway؛ جایگزین مدرن OTV/VPLS
پردیس نرم‌افزارمحور (SD-Access)	سگمنت کاربران، IoT و مهمان در کل پردیس	data plane مبتنی بر VXLAN-GPO همراه SGT روی Catalyst 9000
سگمنت امنیتی	جداسازی تجهیزات حساس، BMS، مهمان	VRF برای macro-segmentation و SGT/GPO برای micro-segmentation
مهاجرت از شبکه قدیمی	سرورهای موجود روی VLAN هستند	نگاشت VLAN به VNI روی leaf؛ VXLAN Gateway پل می‌زند
کانتینر و Kubernetes	شبکه pod بین nodeهای مختلف	VTEP نرم‌افزاری روی node (مثل Calico/Flannel) و یکپارچه‌سازی با NX-OS VXLAN

در پردیس، Cisco SD-Access کنترل‌پلن مبتنی بر LISP و data plane مبتنی بر VXLAN با افزونه Group Policy Option دارد؛ شناسه شبکه مجازی (VN یا همان VRF) و برچسب گروه امنیتی (SGT) در همان هدر VXLAN-GPO حمل می‌شود. حتی ترافیک بی‌سیم در حالت Fabric Wireless مستقیماً از Access Point با VXLAN به فابریک تحویل داده می‌شود.

کی VXLAN نخرید / نسازید: دفتر بیست‌نفره با یک سوئیچ Access و PoE. آنجا Catalyst و VLAN معمولی کافی است. VXLAN پیچیدگی underlay، MTU، و عملیات می‌آورد؛ فایده‌اش وقتی است که مقیاس و east-west و tenant واقعی دارید.

مزایا و محدودیت‌ها

خلاصه ارزش VXLAN در یک جمله: انعطاف لایه ۲ را با پایداری و مقیاس‌پذیری لایه ۳ یکجا به دست می‌آورید — به‌خصوص با VXLAN BGP EVPN.

قابلیت / مزیت	توضیح
مقیاس سگمنت‌ها	حدود ۱۶ میلیون VNI به‌جای حدود ۴۰۹۴ VLAN
استفاده از همه لینک‌ها	ECMP در underlay؛ هیچ لینکی توسط STP مسدود نمی‌شود
همگرایی سریع	همگرایی پروتکل مسیریابی به‌جای همگرایی STP
جابه‌جایی آزاد workload	قرار دادن VM در هر رک، pod یا حتی دیتاسنتر دیگر بدون تغییر IP
مسیریابی بهینه	Anycast Gateway روی هر leaf؛ مسیریابی در اولین hop
کاهش flooding	پخش MAC و IP با BGP و پاسخ محلی ARP
چندمستأجری داخلی	VRF و L3VNI جداگانه برای هر مستأجر با امکان همپوشانی آدرس
امنیت کنترل‌شده‌تر	پذیرش ترافیک فقط از VTEPهای شناخته‌شده در EVPN؛ احراز هویت BGP؛ micro-segmentation با GPO
کارایی سخت‌افزاری	کپسوله و دکپسوله با سرعت line-rate در سوئیچ‌های Nexus 9000
استاندارد و چندبرندی	RFC 7348 و EVPN IETF هستند و با تجهیزات دیگر تعامل دارند
خودکارسازی	فابریک منظم Spine-Leaf به‌راحتی با NDFC یا Ansible خودکار می‌شود

VXLAN جادو نیست و بدون طراحی درست، مشکلات تازه‌ای می‌سازد:

• MTU: سربار ۵۰ بایتی و ممنوعیت fragmentation یعنی کوچک‌ترین ناهماهنگی MTU در مسیر، بسته‌های بزرگ را بی‌صدا حذف می‌کند.
• پیچیدگی مفهومی: تیم باید هم‌زمان BGP، VRF، RD/RT، multicast یا IR، و مفاهیم EVPN را بلد باشد. بدون آموزش، عیب‌یابی سخت می‌شود.
• وابستگی به سخت‌افزار: برای VTEP سخت‌افزاری، ASIC باید کپسوله و مسیریابی VXLAN/EVPN را پشتیبانی کند. همه پلتفرم‌های سیسکو Routing VXLAN را پشتیبانی نمی‌کنند؛ انتخاب سخت‌افزار باید بر اساس نقش باشد.
• منابع جدول‌ها: هر میزبان یک ورودی MAC، ARP و مسیر BGP مصرف می‌کند. ظرفیت جدول‌ها باید پیش از خرید محاسبه شود.
• ترافیک BUM با IR: VTEP مبدأ به تعداد VTEP مقصد کپی می‌سازد؛ برای multicast سنگین مثل ویدئو پهنای باند و پردازش زیادی مصرف می‌کند.
• امنیت ذاتی: VXLAN رمزنگاری و احراز هویت داخلی ندارد.
• دید و عیب‌یابی: ابزارهای مانیتورینگ قدیمی فقط هدر بیرونی را می‌بینند؛ برای دید کامل به ابزارهایی نیاز است که هدر داخلی VXLAN را هم تحلیل کنند.

بیشتر این چالش‌ها با سه اقدام مهار می‌شوند: طراحی مکتوب پیش از اجرا، استفاده از قالب‌های استاندارد یا NDFC، و آموزش تیم عملیات.

امنیت در VXLAN

مهم‌ترین نکته امنیتی: VXLAN به‌خودی‌خود هیچ رمزنگاری یا احراز هویتی ندارد. RFC 7348 صراحتاً می‌گوید حمل ترافیک لایه ۲ روی IP سطح حمله را به‌طور قابل‌توجهی گسترش می‌دهد و خود پروتکل راهکار مشخصی برای آن ندارد.

تهدیدهای اصلی: تزریق بسته VXLAN (هر کسی که بتواند بسته UDP با پورت مقصد ۴۷۸۹ به آدرس یک VTEP بفرستد، می‌تواند فریم جعلی را داخل یک VNI تزریق کند یا MAC دیگری را جعل کند)؛ VTEP جعلی در Flood & Learn (با عضویت در گروه multicast یک VNI ترافیک broadcast را دریافت کند)؛ شنود ترافیک داخل تونل که به‌صورت متن ساده عبور می‌کند؛ و حملات کلاسیک لایه ۲ مثل ARP spoofing و DHCP جعلی که همچنان داخل هر VNI ممکن است.

لایه	اقدام	منبع / ابزار
Underlay	ایزوله کردن underlay؛ هیچ مسیری از بیرون به loopbackهای VTEP وجود نداشته باشد	طراحی شبکه
لبه فابریک	مسدود کردن UDP/4789 ورودی از بیرون روی ACL و فایروال Border	RFC 7348؛ پنج‌تایی روی سوئیچ‌ها
Control Plane	استفاده از EVPN تا فقط VTEPهای شناخته‌شده در BGP مجاز باشند؛ احراز هویت MD5 روی نشست‌های BGP	راهنمای EVPN سیسکو
انتقال بین سایت‌ها	رمزنگاری با CloudSec در EVPN Multi-Site، یا IPsec / MACsec روی لینک‌ها	NX-OS: Secure VXLAN EVPN Multi-Site Using CloudSec
داخل VNI	DHCP Snooping، Dynamic ARP Inspection، First Hop Security، Private VLAN	NX-OS: First Hop Security و PVLAN
بین گروه‌ها	Micro-Segmentation با VXLAN GPO یا SGT	NX-OS GPO و Cisco SD-Access
بین مستأجرها	عبور ترافیک بین VRFها از فایروال (Border/Service Leaf)، نه Route Leaking آزاد	طراحی فابریک

یک اصل را همیشه به خاطر داشته باشید: VRF و VNI ابزار جداسازی هستند، نه سیاست امنیتی. تصمیم اینکه چه کسی با چه کسی حرف بزند باید در فایروال یا سیاست گروه‌محور (SGT و GPO) گرفته شود.

تجهیزات سیسکو که VXLAN را پشتیبانی می‌کنند

همیشه Platform Support Matrix همان نسخه NX-OS / IOS XE را چک کنید؛ جدول زیر تصویر کلی است نه مجوز خرید کور.

خانواده	مدل‌ها / سیستم‌عامل	نقش رایج در VXLAN
Nexus 9000	سری 9300 و 9500 با کارت‌لاین Cloud Scale؛ NX-OS	پلتفرم اصلی VXLAN BGP EVPN؛ Leaf، Spine، Border Leaf و BGW با کپسوله line-rate
Nexus 9000 در ACI mode	همان سخت‌افزار با سیستم‌عامل ACI	فابریک مبتنی بر VXLAN داخلی با کنترلر APIC؛ CLI VXLAN کلاسیک نیست
Nexus 3000	مدل‌های منتخب؛ NX-OS	Leaf در فابریک‌های کوچک‌تر (بر اساس Platform Matrix)
Nexus 7000/7700 و 5600	نسخه‌ها و ماژول‌های پشتیبانی‌کننده؛ NX-OS	فابریک‌های قدیمی‌تر؛ در این سری‌ها multicast در underlay الزامی‌تر است
Catalyst 9300 / 9400 / 9500 / 9600	خانواده Catalyst 9000؛ IOS XE	BGP EVPN VXLAN در Leaf و Spine پردیس؛ در SD-Access نقش Fabric Edge / Border / Control Plane
روترهای IOS XE	ASR 1000، Catalyst 8500، Catalyst 8000V	BGP EVPN VXLAN لایه ۲ و ۳؛ اتصال فابریک به WAN و DCI (با محدودیت فیچر در بعضی نسخه‌ها)
Nexus Dashboard (NDFC)	نرم‌افزار کنترلر	خودکارسازی و مدیریت فابریک‌های NX-OS با قالب‌های آماده

نکات مهم: Nexus 9000 سوئیچ مرجع VXLAN در سیسکو است و gateway سخت‌افزاری را با line-rate انجام می‌دهد. Catalyst 9000 فقط VXLAN با کنترل‌پلن مبتنی بر BGP را پشتیبانی می‌کند؛ اگر host-reachability protocol bgp تنظیم نشود، تونل به حالت static می‌رود که روی این سری پشتیبانی نمی‌شود. برای Access اداری و PoE همان مسیر سویچ سیسکو سری ۹۲۰۰ است؛ VXLAN را روی ۹۲۰۰ به‌عنوان ToR دیتاسنتر ۱۰/۲۵گیگ تصور نکنید. هسته شاسی‌دار پردیس را در سویچ سیسکو سری ۹۶۰۰ ببینید.

پیکربندی نمونه کامل NX-OS (Leaf + Spine)

در این بخش یک فابریک کوچک ولی کامل می‌سازیم: دو Spine به‌عنوان Route Reflector، دو Leaf به‌عنوان VTEP، یک L2VNI با Anycast Gateway، و یک VRF مستأجر با L3VNI. الگوی پیکربندی بر پایه راهنمای طراحی فابریک و راهنمای underlay سیسکو در NX-OS است. این پیکربندی برای آموزش و آزمایشگاه است؛ پیش از استفاده در شبکه عملیاتی، نسخه نرم‌افزار، ظرفیت‌ها و الزامات امنیتی خود را بررسی کنید.

توپولوژی و پارامترها

مؤلفه	مقدار
BGP AS (iBGP)	65000
Underlay	OSPF، لینک‌های IP unnumbered، ناحیه 0، MTU 9216
loopback0	Router-ID و Peering برای BGP
loopback1	آدرس VTEP (منبع NVE)
Spine-1 / Spine-2	Lo0: 10.0.0.1 / 10.0.0.2
Leaf-1	Lo0 10.0.0.11 · Lo1 10.0.1.11
Leaf-2	Lo0 10.0.0.12 · Lo1 10.0.1.12
VLAN 10 ↔ L2VNI	10010؛ شبکه 192.168.10.0/24؛ Gateway 192.168.10.1
L3VNI ↔ VRF مستأجر	50000 ↔ TENANT-A (VLAN 3900)
ترافیک BUM	Ingress Replication با BGP (بدون Multicast)

Host-A و Host-B در یک subnet هستند اما پشت دو leaf متفاوت؛ VXLAN آن‌ها را در یک شبکه لایه ۲ قرار می‌دهد.

نمونه الف: Leaf-1 روی Nexus 9000 (NX-OS)

! ===== 1) Features =====
feature ospf
feature bgp
feature interface-vlan
feature vn-segment-vlan-based
feature nv overlay
feature fabric forwarding
nv overlay evpn

! ===== 2) Underlay =====
router ospf UNDERLAY
  router-id 10.0.0.11

interface loopback0
  description Router-ID / BGP
  ip address 10.0.0.11/32
  ip router ospf UNDERLAY area 0.0.0.0

interface loopback1
  description VTEP (NVE source)
  ip address 10.0.1.11/32
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  description to Spine-1
  no switchport
  mtu 9216
  medium p2p
  ip unnumbered loopback0
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0
  no shutdown
! Ethernet1/50 to Spine-2: same config

! ===== 3) Tenant VRF + L3VNI =====
vlan 3900
  vn-segment 50000

vrf context TENANT-A
  vni 50000
  rd auto
  address-family ipv4 unicast
    route-target both auto
    route-target both auto evpn

interface Vlan3900
  no shutdown
  mtu 9216
  vrf member TENANT-A
  ip forward

! ===== 4) L2VNI + Distributed Anycast Gateway =====
fabric forwarding anycast-gateway-mac 2020.0000.00aa

vlan 10
  vn-segment 10010

interface Vlan10
  no shutdown
  vrf member TENANT-A
  ip address 192.168.10.1/24
  fabric forwarding mode anycast-gateway

evpn
  vni 10010 l2
    rd auto
    route-target import auto
    route-target export auto

! ===== 5) VTEP (NVE) =====
interface nve1
  no shutdown
  host-reachability protocol bgp
  source-interface loopback1
  member vni 10010
    suppress-arp
    ingress-replication protocol bgp
  member vni 50000 associate-vrf

! ===== 6) Overlay: iBGP EVPN to Spines (RR) =====
router bgp 65000
  router-id 10.0.0.11
  neighbor 10.0.0.1
    remote-as 65000
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
  neighbor 10.0.0.2
    remote-as 65000
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
  vrf TENANT-A
    address-family ipv4 unicast
      advertise l2vpn evpn

! ===== 7) Access port =====
interface Ethernet1/1
  switchport
  switchport mode access
  switchport access vlan 10
  mtu 9216
  no shutdown

Leaf-2 دقیقاً همین پیکربندی را دارد و فقط آدرس‌ها عوض می‌شوند: loopback0 = 10.0.0.12، loopback1 = 10.0.1.12، و Router-ID متناظر. Gateway و MAC مجازی Anycast Gateway روی هر دو یکسان است.

نمونه ب: Spine-1 روی Nexus 9000 (Route Reflector)

feature ospf
feature bgp
nv overlay evpn

router ospf UNDERLAY
  router-id 10.0.0.1

interface loopback0
  ip address 10.0.0.1/32
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/1
  description to Leaf-1
  no switchport
  mtu 9216
  medium p2p
  ip unnumbered loopback0
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0
  no shutdown
! لینک به Leaf-2 مشابه

router bgp 65000
  router-id 10.0.0.1
  address-family l2vpn evpn
  template peer VTEP-PEERS
    remote-as 65000
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
      route-reflector-client
  neighbor 10.0.0.11
    inherit peer VTEP-PEERS
  neighbor 10.0.0.12
    inherit peer VTEP-PEERS

طبق توصیه سیسکو، روی Spineی که فقط نقش Spine دارد فعال کردن قابلیت‌هایی مثل feature nv overlay لازم نیست؛ فعال شدن nv overlay evpn برای Address Family مربوط به EVPN کافی است.

جدول معنی دستورات کلیدی

دستور	کاربرد
feature vn-segment-vlan-based	امکان نگاشت VLAN به VNI
feature nv overlay	فعال‌سازی VXLAN و اینترفیس NVE
nv overlay evpn	فعال‌سازی Control Plane مبتنی بر EVPN
vn-segment 10010	نگاشت VLAN 10 به VNI 10010
vni 50000 در vrf context	تعیین L3VNI برای VRF مستأجر
ip forward روی Vlan3900	فعال‌سازی مسیریابی روی SVI مربوط به L3VNI بدون آدرس IP
fabric forwarding mode anycast-gateway	فعال کردن Distributed Anycast Gateway روی SVI
host-reachability protocol bgp	استفاده از EVPN به‌جای Flood & Learn
suppress-arp	پاسخ محلی به ARP از روی اطلاعات EVPN
ingress-replication protocol bgp	کپی ترافیک BUM بر اساس فهرست VTEPهای Route Type 3
associate-vrf	اتصال L3VNI به اینترفیس NVE
send-community extended	ارسال Route Target؛ بدون آن مسیرها Import نمی‌شوند

تفاوت‌های Catalyst 9300 (IOS XE) + نمونه کوتاه

در پردیس، همین منطق روی Catalyst 9000 با نحو کمی متفاوت پیاده می‌شود. نمونه زیر بر پایه مثال رسمی BGP EVPN VXLAN برای Catalyst 9300 است.

hostname C9300-LEAF-1
!
vrf definition TENANT-A
 rd 10.0.0.21:1
 !
 address-family ipv4
  route-target export 65000:50000
  route-target import 65000:50000
  route-target export 65000:50000 stitching
  route-target import 65000:50000 stitching
 exit-address-family
!
ip routing
system mtu 9150
!
l2vpn evpn
 replication-type ingress
 router-id Loopback0
 default-gateway advertise
!
l2vpn evpn instance 10 vlan-based
 encapsulation vxlan
!
vlan configuration 10
 member evpn-instance 10 vni 10010
vlan configuration 3900
 member vni 50000
!
interface Loopback0
 ip address 10.0.0.21 255.255.255.255
 ip ospf 1 area 0
!
interface Vlan3900
 description L3VNI core SVI
 vrf forwarding TENANT-A
 ip unnumbered Loopback0
 no autostate
!
interface Vlan10
 description L2VNI 10010 gateway
 vrf forwarding TENANT-A
 ip address 192.168.10.1 255.255.255.0
!
interface nve1
 no ip address
 source-interface Loopback0
 host-reachability protocol bgp
 member vni 10010 ingress-replication
 member vni 50000 vrf TENANT-A
!
router bgp 65000
 bgp router-id interface Loopback0
 no bgp default ipv4-unicast
 neighbor 10.0.0.1 remote-as 65000
 neighbor 10.0.0.1 update-source Loopback0
 !
 address-family l2vpn evpn
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 send-community both
 exit-address-family
 !
 address-family ipv4 vrf TENANT-A
  advertise l2vpn evpn
  redistribute connected
 exit-address-family

تفاوت‌های کلیدی با NX-OS:

• نگاشت VLAN به VNI با vlan configuration و member evpn-instance انجام می‌شود، نه vn-segment.
• SVI مربوط به L3VNI با ip unnumbered و no autostate ساخته می‌شود.
• Anycast Gateway با MAC یکسان روی SVIها، یا با تنظیم دستی، یا با default-gateway advertise (MAC Aliasing) پیاده می‌شود.
• Route Targetهای EVPN برای VRF با کلیدواژه stitching تعریف می‌شوند.
• روی Catalyst 9000، VXLAN حتماً باید با host-reachability protocol bgp پیکربندی شود.

عیب‌یابی از پایین به بالا

عیب‌یابی VXLAN همیشه از پایین به بالا انجام می‌شود: اول Underlay، بعد BGP EVPN، بعد تونل‌ها و در آخر میزبان‌ها. اگر Underlay سالم نباشد، بررسی لایه‌های بالاتر وقت تلف کردن است.

مرحله	دستور (NX-OS)	انتظار
۱. Underlay	show ip ospf neighbors	همسایگی FULL با همه Spineها
۱. Underlay	show ip route 10.0.1.12	مسیر به Loopback VTEP مقابل؛ ترجیحاً چند مسیر ECMP
۱. Underlay	ping 10.0.1.12 source 10.0.1.11 packet-size 8972 df-bit	پاسخ موفق؛ یعنی MTU مسیر برای Jumbo کافی است
۲. Overlay	show bgp l2vpn evpn summary	نشست EVPN با هر RR در وضعیت Established
۲. Overlay	show bgp l2vpn evpn	وجود مسیرهای Route Type 2، 3 و 5
۳. تونل	show nve peers	وضعیت Up مقابل VTEP با LearnType برابر CP
۳. تونل	show nve vni	VNIها در وضعیت Up؛ حالت CP یعنی Control Plane و DP یعنی Flood & Learn
۴. میزبان	show l2route evpn mac-ip all	MAC و IP میزبان‌های محلی و دوردست
۴. میزبان	show ip arp suppression-cache detail	ورودی‌های ARP Suppression
۴. میزبان	show ip route vrf TENANT-A	مسیر /32 میزبان‌های دوردست از طریق BGP
vPC	show vpc	Peer adjacency formed ok و Consistency موفق

دستورهای روزمره دیگر: show fabric forwarding ip anycast-gateway vrf all، show l2route mac all.

جدول مشکلات رایج

علامت	علت محتمل	راه‌حل
Ping کوچک موفق، ترافیک بزرگ قطع	MTU ناکافی یا ناهمسان در Underlay	MTU 9216 روی کل مسیر؛ دو سر هر لینک یکسان
show nve peers خالی است	نشست BGP برقرار نیست یا Loopback VTEP در Underlay اعلام نشده	بررسی OSPF، BGP و مسیر به loopback1
نشست BGP برقرار است ولی مسیر Import نمی‌شود	Extended Community ارسال نمی‌شود یا RT مطابقت ندارد	send-community extended و بررسی RT دو طرف
RT خودکار با eBGP کار نمی‌کند	RT خودکار به شکل AS:VNI است و ASها متفاوت‌اند	RT دستی یا دستور rewrite-evpn-rt-asn
میزبان پس از جابه‌جایی به Gateway نمی‌رسد	MAC مجازی Anycast Gateway روی leafها یکسان نیست	یک anycast-gateway-mac واحد در کل فابریک
مسیریابی بین subnetها کار نمی‌کند	L3VNI، VLAN یا SVI آن روی یکی از leafها تعریف نشده	L3VNI یکسان روی همه VTEPهای آن VRF
NVE روی یکی از اعضای vPC خاموش شده	ناهمسانی پیکربندی vPC (نگاشت VNI یا آدرس Secondary)	یکسان‌سازی پیکربندی دو عضو vPC
ترافیک BUM به برخی VTEPها نمی‌رسد	روش Replication در VTEPها یکسان نیست	یک روش (Multicast یا IR) و نگاشت گروه یکسان در کل سایت

یادآوری: برخی قابلیت‌ها روی بعضی پلتفرم‌های Nexus به تخصیص منابع TCAM (TCAM Carving) و راه‌اندازی مجدد سوئیچ نیاز دارند؛ پیش از فعال‌سازی، راهنمای پیکربندی مدل خود را بخوانید.

مقایسه با VLAN، QinQ، FabricPath، OTV و Geneve

فناوری	لایه انتقال	شناسه سگمنت	Control Plane	وضعیت امروز
VLAN (802.1Q)	لایه ۲	۱۲ بیت (~۴۰۹۴)	STP	پایه شبکه دسترسی؛ برای فابریک بزرگ ناکافی
QinQ (802.1ad)	لایه ۲	دو تگ ۱۲ بیتی	STP	کاربرد اپراتوری؛ مشکلات STP پابرجاست
FabricPath / TRILL	لایه ۲ مسیریابی‌شده با IS-IS	VLAN	IS-IS	نسل قبل؛ امروز جایشان را به VXLAN داده‌اند
OTV	MAC-in-IP بین دیتاسنترها	VLAN	IS-IS	راهکار قدیمی DCI سیسکو؛ جایگزین مدرن EVPN Multi-Site
VPLS	MPLS	VLAN یا VPN	LDP یا BGP	DCI اپراتوری؛ نیازمند MPLS
VXLAN + EVPN	UDP/IP (MAC-in-UDP)	۲۴ بیت (~۱۶ میلیون)	MP-BGP EVPN	استاندارد غالب دیتاسنتر و پردیس
NVGRE (RFC 7637)	GRE/IP	۲۴ بیت	نامشخص در استاندارد	عمدتاً کنار گذاشته؛ توزیع بار ECMP ضعیف‌تر به‌دلیل نبود پورت UDP
Geneve (RFC 8926)	UDP/IP، پورت 6081	۲۴ بیت + گزینه‌های متغیر	متغیر	هدر توسعه‌پذیر با TLV؛ رایج در پلتفرم‌های مجازی‌سازی نرم‌افزاری

VXLAN جایگزین VLAN نیست بلکه آن را گسترش می‌دهد؛ سرورها همچنان روی VLAN وصل می‌شوند و leaf آن را به VNI نگاشت می‌کند. FabricPath و TRILL مشکل STP را حل کردند اما به سخت‌افزار و پروتکل‌های مخصوص لایه ۲ وابسته بودند؛ VXLAN روی هر شبکه IP کار می‌کند. طبق راهنمای طراحی EVPN سیسکو، استفاده از یک فناوری واحد (VXLAN EVPN) برای داخل و بین دیتاسنترها طراحی را ساده و پیچیدگی عملیاتی را کم می‌کند. Geneve انعطاف بیشتری در هدر دارد، اما در دنیای سوئیچ‌های سخت‌افزاری و فابریک‌های چندبرندی، VXLAN با EVPN پشتیبانی بسیار گسترده‌تری دارد.

کی سراغ VXLAN برویم + سه توصیه شروع درست

سراغ VXLAN بروید وقتی:

• دیتاسنتر یا اتاق سرور شما در حال رشد است و VLANها، STP و وابستگی به توپولوژی به گلوگاه تبدیل شده‌اند.
• ماشین‌های مجازی یا سرویس‌ها باید آزادانه بین رک‌ها، podها یا دیتاسنترها جابه‌جا شوند.
• به جداسازی واقعی بخش‌ها، مستأجرها یا تجهیزات حساس نیاز دارید.
• می‌خواهید دیتاسنتر دوم یا سایت DR را با یک overlay یکپارچه به سایت اصلی وصل کنید.
• در پردیس به سگمنت مبتنی بر هویت و سیاست گروه‌محور (SD-Access) فکر می‌کنید.

سه توصیه برای شروع درست:

1. طراحی را از Underlay شروع کنید: MTU 9216، IGP ساده، آدرس‌دهی Loopback جدا و منظم.
2. از روز اول EVPN را انتخاب کنید: Flood & Learn برای شبکه امروز مناسب نیست؛ روش BUM (Multicast یا Ingress Replication) را هم از ابتدا درست انتخاب کنید.
3. امنیت و عملیات را فراموش نکنید: Underlay را ایزوله کنید، ترافیک بین VRFها را از فایروال عبور دهید، و با NDFC یا قالب‌های استاندارد خطای انسانی را به حداقل برسانید.

قدرت واقعی VXLAN وقتی آشکار می‌شود که با یادگیری کنترل‌شده MP-BGP EVPN همراه شود: ARP Suppression، Anycast Gateway، Symmetric IRB و چندمستأجری واقعی. امروز زبان مشترک دیتاسنتر و پردیس مدرن است؛ طراحی و پیاده‌سازی درست آن زیرساختی می‌سازد که سال‌ها بدون بازطراحی بنیادین رشد می‌کند.

منابع رسمی برای ادامه مطالعه

• RFC 7348 – Virtual eXtensible Local Area Network (VXLAN)
• RFC 7432 – BGP MPLS-Based Ethernet VPN
• RFC 8365 – A Network Virtualization Overlay Solution Using EVPN
• Nexus 9000 NX-OS VXLAN Configuration Guide — Overview
• Configuring the Underlay
• A Modern, Open, and Scalable Fabric: VXLAN EVPN (PDF)
• VXLAN BGP EVPN Design and Implementation Guide
• Cisco Live BRKDCN-1621 — Introduction to VXLAN
• Cisco Live BRKDCN-1999 — VXLAN BGP EVPN
• Catalyst 9300 — BGP EVPN VXLAN Overview

مشاوره و پیاده‌سازی با آکانت

آکانت (Akanet) با بیش از بیست سال سابقه در شبکه‌های مبتنی بر سیسکو، کنار سازمان‌هایی ایستاده که از Access پردیس تا دیتاسنتر leaf/spine و فابریک‌های بزرگ سازمانی را طراحی و پیاده‌سازی می‌کنند. مشاوره معماری، انتخاب بین Nexus و Catalyst، طراحی underlay/overlay، کانفیگ VXLAN EVPN، مهاجرت از VLAN کلاسیک، سگمنت امنیتی، اتصال سایت‌ها و DR، و استقرار شبکه‌های بزرگ سازمانی بخشی از همان مسیر روزمره ماست — نه کار کاتالوگ ورق زدن. طراحی و پیاده‌سازی شبکه‌ای مثل آنچه خواندید فقط دانستن دستورات نیست؛ تجربه میدانی، طراحی درست از روز اول و پشتیبانی مطمئن پس از اجرا می‌خواهد.

09121308444

aka@aka.ir  |  aka.ir

وفقک الله