استانداردهای GRE-in-UDP RFC 8086 و GENEVE: قطبش هش ECMP و مسیریابی چندمسیره VPN

شبکه‌های ستون فقرات سازمانی VPN و سامانه‌های سراسری Anycast نیازمند مقیاس‌پذیری بالایی در پهنای باند هستند. هنگام تجمیع هزاران تونل اتصالی کاربران بر بستر مراکز داده و ارائه‌دهندگان ابری، ترافیک اصلی شبکه نمی‌تواند تنها به یک مسیر فیزیکی واحد وابسته باشد. شبکه‌های مدرن با کارایی بالا از فناوری مسیریابی چندمسیره با هزینه یکسان (Equal-Cost Multi-Path یا ECMP) و گروه‌های تجمیع پیوند (LAG) برای پخش بسته‌ها بر روی ده‌ها مسیر موازی بهره می‌برند.

با این وجود، پروتکل‌های تونل‌سازی سنتی نقطه به نقطه—به‌ویژه پروتکل کپسوله‌سازی عمومی مسیریابی (GRE, RFC 2784) و IP-in-IP (RFC 2003)—در بستر ساختارهای سوئیچینگ چندمسیره با افت شدید عملکرد مواجه می‌شوند. از آنجا که این پروتکل‌ها بار مفید داخلی را مستقیما درون سرایندهای خارجی IP بدون شماره پورت‌های لایه انتقال (لایه ۴) قرار می‌دهند، سوئیچ‌های میانی ترانزیت قادر به شناسایی و تفکیک جریان‌های ترافیکی مستقل کاربران نخواهند بود.

این محدودیت ساختاری موجب پدیده قطبش هش ECMP (یا Hash Polarization) می‌شود. در این وضعیت، انبوهی از نشست‌های مستقل داده درون تونل به یک پیوند فیزیکی مشترک هدایت می‌شوند و منجر به افت بسته، تراکم بالا و نوسان تاخیر می‌گردند، در حالی که سایر پیوندهای موازی با ظرفیت بالا بدون استفاده باقی می‌مانند. برای رفع اساسی این چالش، کارگروه مهندسی اینترنت (IETF) استاندارد RFC 8086 (کپسوله‌سازی GRE درون UDP) و پروتکل‌های نوینی همچون GENEVE (RFC 8926) را معرفی کرد.

گلوگاه شبکه پوششی: دلایل اختلال در مسیریابی چندمسیره توسط تونل‌های سنتی VPN

در یک شبکه IP معمولی بدون کپسوله‌سازی اورلی، سوئیچ‌های ترانزیت با محاسبه هش ECMP روی سرایندهای لایه انتقال، ترافیک را متوازن می‌سازند. جریان‌های داده TCP و UDP شامل شماره پورت‌های مبدا و مقصد گوناگونی هستند که انتروپی طبیعی را فراهم کرده و به تجهیزات شبکه امکان می‌دهند بسته‌ها را به طور متقارن میان مسیرهای خروجی پخش کنند.

زمانی که بسته‌ها وارد یک تونل نقطه به نقطه سنتی می‌شوند، این دسترسی و شفافیت از بین می‌رود:

1. کپسوله‌سازی سرایندها: درگاه ورودی بسته اصلی IP حامل ترافیک کاربر را درون یک سرایند GRE قرار می‌دهد.
2. تخصیص پروتکل خارجی: درگاه مقدار فیلد Protocol سرایند بیرونی IP را برابر با عدد 47 (مربوط به GRE) تعیین می‌کند.
3. از بین رفتن انتروپی: سرایند خارجی هیچ شماره پورت لایه انتقالی ندارد. تمام بسته‌های ارسالی میان درگاه A (198.51.100.1) و درگاه B (203.0.113.2) دارای آدرس‌های IP و شماره پروتکل کاملا یکسانی هستند.

از دید روترهای ترانزیت در شبکه ستون فقرات اینترنت، میلیون‌ها ارتباط مجزای کاربران مانند یک جریان داده تکی و غیرقابل تفکیک به نظر می‌رسند.

کالبدشکافی هشینگ ECMP: نحوه انتخاب پیوندهای فیزیکی توسط سوئیچ‌های میانی

روترهای هسته شبکه و سوئیچ‌های ساختار Spine-Leaf از تراشه‌های مدارهای مجتمع با کاربرد خاص (ASIC) برای هدایت بسته‌ها در مقیاس میلیون‌ها بسته در ثانیه استفاده می‌کنند. برای جلوگیری از بی‌نظمی در ترتیب تحویل بسته‌ها (که سبب ارسال مکرر درخواست بازپخش در TCP و سقوط نرخ انتقال می‌شود)، تراشه‌های سوئیچینگ از روش چرخشی ساده استفاده نمی‌کنند، بلکه یک تابع هش قطعی (مانند CRC32 یا Jenkins Hash) را روی فیلدهای سرایند اجرا می‌کنند.

شاخص پیوند خروجی از طریق عملیات باقیمانده تقسیم به دست می‌آید:

$$ ext{شاخص پیوند} = ext{Hash}( ext{مجموعه مشخصه‌های بسته}) \pmod N$$

که در آن $N$ نشان‌دهنده تعداد کل پیوندهای فیزیکی موازی موجود با هزینه یکسان است (معمولا ۸، ۱۶، ۳۲ یا ۶۴ پیوند).

معمای ۵-تاپل: نبود پورت‌های لایه انتقال در پروتکل GRE 47

تراشه‌های پردازش بسته معمولا پنج مولفه اساسی (5-tuple) را بررسی می‌کنند: IP مبدا، IP مقصد، پروتکل انتقال، پورت مبدا و پورت مقصد. هنگام پردازش یک بسته با پروتکل 47:

;; بسته استاندارد IP (حامل TCP/UDP)
[ سرایند IP خارجی ] [ سرایند TCP/UDP ] [ بار مفید ]
-> داده‌های ورودی تابع هش: IP مبدا، IP مقصد، پروتکل (6/17)، پورت‌ها (انتروپی بالا)

;; بسته تونل سنتی GRE (استاندارد RFC 2784)
[ سرایند IP خارجی ] [ سرایند GRE ] [ بسته IP داخلی ]
-> داده‌های ورودی تابع هش: IP مبدا، IP مقصد، پروتکل (47)، [فاقد پورت] (انتروپی صفر)

تراشه ASIC ناچار می‌شود به هشینگ ساده ۲ فیلدی یا ۳ فیلدی بسنده کند: یعنی تنها IP مبدا، IP مقصد و پروتکل 47. از آنجا که این سه فیلد در کل طول اتصال تونل ثابت هستند، خروجی تابع هش برای تمام بسته‌های ارسالی دقیقا یکسان خواهد بود.

قطبش هش: تراکم گسترده ترافیک روی شبکه‌های زیرساخت چندپیوندی

اگر چند لایه پیاپی از سوئیچ‌ها الگوریتم هش مشابهی را به کار گیرند، قطبش هش تشدید می‌شود. ساختار فیزیکی با تمرکز بار نامتقارن روبرو می‌شود:

[ جریان‌های کاربران 1..1000 ]
           |
     [ درگاه ورودی A ] (کپسوله‌سازی GRE, Proto=47)
           |
   [ سوئیچ‌های میانی ] (محاسبه هش ECMP)
     /     |       [پیوند ۱] [پیوند ۲] [پیوند ۳] ... [پیوند N]
  100%       0%       0%             0%
 (اشباع)   (بیکار)   (بیکار)        (بیکار)
           |
     [ درگاه خروجی B ]

اگرچه زیرساخت شبکه فیزیکی دارای ده‌ها پیوند پرظرفیت موازی است، تونل سنتی GRE تمامی داده‌ها را به یک پیوند فیزیکی محدود می‌کند. این مسئله سبب ایجاد صف‌های طولانی و ریزش بسته‌ها شده و مزیت مسیریابی چندمسیره را بی‌اثر می‌سازد.

معماری RFC 8086: کپسوله‌سازی GRE درون دیتاگرام‌های UDP

به منظور خنثی کردن این گره ترافیکی و حفظ هماهنگی کامل با تجهیزات استاندارد شبکه، کارگروه IETF استاندارد RFC 8086 را تدوین نمود. در این استاندارد، فریم کامل GRE درون یک سرایند استاندارد UDP قرار می‌گیرد:

+-------------------------------------------------------------------+
|         سرایند IP خارجی         |  (Protocol = 17, UDP)            |
+-------------------------------------------------------------------+
|        سرایند UDP خارجی         |  (پورت مبدا = انتروپی, مقصد = 4754) |
+-------------------------------------------------------------------+
|           سرایند GRE            |  (RFC 2784 / RFC 2890)           |
+-------------------------------------------------------------------+
|         بسته IP داخلی           |  (بار مفید کاربر IPv4 یا IPv6)   |
+-------------------------------------------------------------------+

اصول کلیدی معماری RFC 8086 عبارتند از:

1. پورت مقصد اختصاصی: سازمان IANA پورت شناخته‌شده UDP با شماره 4754 را برای شناسایی تونل‌های GRE-in-UDP تخصیص داده است.
2. پایداری امکانات پروتکل: تمامی ویژگی‌های کاربردی GRE شامل شماره‌های توالی، کلیدهای شناسایی (Key) و پشتیبانی چندپروتکلی بدون تغییر حفظ می‌شوند.
3. سازگاری فراگیر با سخت‌افزارها: همه سوئیچ‌های میانی به صورت پیش‌فرض از تفکیک پنج‌گانه دیتاگرام‌های UDP پشتیبانی می‌کنند و نیازی به ارتقای نرم‌افزاری روترهای ترانزیت نخواهد بود.

پورت مبدا انتروپی: توزیع پویای جریان‌ها بدون بازرسی عمیق بسته‌ها

نوآوری برجسته در پروتکل RFC 8086 استفاده از پورت مبدا UDP خارجی به عنوان کانال تزریق انتروپی است.

در روش‌های مرسوم، برای توزیع بار چنین بسته‌هایی، سوئیچ‌های بین‌راهی باید عملیات بازرسی عمیق بسته‌ها (DPI) را انجام دهند و با گذر از لایه‌های GRE، آدرس‌های IP و پورت‌های TCP/UDP داخلی را استخراج نمایند. با این حال، تحلیل بسته‌ها در عمق سخت‌افزاری بسیار زمان‌بر و هزینه‌بر بوده و در صورت رمزنگاری بار مفید، ناممکن خواهد بود.

پروتکل GRE-in-UDP وظیفه ایجاد تعادل بار را به درگاه ورودی تونل منتقل می‌کند:

1. محاسبه در مبدا: هنگام ورود بسته کاربر، درگاه ورودی مشخصات ۵ گانه داخلی آن را هش کرده و مقداری ۱۶ بیتی تولید می‌کند.
2. نگاشت پورت: درگاه این مقدار را به محدوده پورت‌های پویای IANA (از 49152 تا 65535) اختصاص می‌دهد.
3. کپسوله‌سازی بیرونی: این شماره پورت متغیر در فیلد پورت مبدا سرایند خارجی UDP ثبت می‌شود.

$$ ext{پورت مبدا UDP خارجی} = 49152 + ( ext{Hash}( ext{مشخصات داخلی}) \pmod{16384})$$

برای یک نشست ارتباطی مشخص، مشخصات داخلی تغییری نکرده و پورت مبدا خارجی همواره یکسان باقی می‌ماند که مانع از تغییر ترتیب بسته‌ها می‌گردد. در مقابل، نشست‌های متفاوت مقادیر متفاوتی تولید می‌کنند که به سوئیچ‌های مسیر اجازه می‌دهد ترافیک را به طور هماهنگ میان تمام پیوندهای ECMP تقسیم نمایند.

مقایسه استانداردهای کپسوله‌سازی: GRE-in-UDP، VXLAN و GENEVE RFC 8926

در زیرساخت‌های نوین شبکه‌ای، چندین راهکار کپسوله‌سازی مبتنی بر UDP وجود دارند. جدول زیر مشخصات فنی این پروتکل‌ها را مقایسه می‌کند:

اگرچه GENEVE (RFC 8926) به دلیل انعطاف‌پذیری گزینه‌های TLV گزینه‌ای ایده‌آل برای شبکه‌های نرم‌افزارمحور پیشرفته است، ساختار بهینه‌تر و سربار اندک GRE-in-UDP آن را به انتخابی عالی برای ارتباطات نقطه به نقطه پرسرعت و شبکه‌های ستون فقرات VPN تبدیل کرده است.

سربار سرایند و MTU مسیر: کاهش تورم کپسوله‌سازی و کنترل MSS Clamping

افزودن سرایندهای UDP و GRE اندازه فیزیکی بسته‌ها را افزایش می‌دهد. اگر رایانه‌های مبدا بسته‌های معمولی اترنت با اندازه ۱۵۰۰ بایت ارسال کنند، کپسوله‌سازی بسته را از حداکثر واحد انتقال (MTU) فیزیکی فراتر برده و سبب ریزش یا قطعه‌قطعه شدن بسته می‌گردد.

[ اندازه استاندارد اترنت MTU: 1500 بایت ]
- [ سرایند خارجی IPv4: 20 بایت ]
- [ سرایند خارجی UDP: 8 بایت ]
- [ سرایند پایه GRE: 4 بایت ]
= [ ظرفیت باقیمانده MTU داخلی: 1468 بایت ] (در صورت فعال بودن فیلدهای توالی به 1456 بایت می‌رسد)

برای پیشگیری از افت اتصالات به دلیل پدیده سیاه‌چاله PMTUD، راهکارهای چندگانه زیر اجرا می‌شوند:

1. کنترل اندازه قطعات TCP (روش MSS Clamping): درگاه‌های شبکه در حین برقراری نشست TCP مقدار بیشینه قطعه داده را تعدیل کرده و کلاینت‌ها را به ارسال بسته‌هایی با اندازه کمتر از ۱۴۲۰ بایت مقید می‌کنند.
2. کشف خودکار MTU مسیر: انطباق با استاندارد RFC 8201 و بازپخش صحیح پیام‌های ICMP (Type 3, Code 4).
3. پیکربندی فریم‌های بزرگ (Jumbo Frames): تنظیم MTU فیزیکی روی ۹۰۰۰ بایت در اتصالات زیرساختی اختصاصی به منظور جذب کامل بارهای اضافی سرایند.

مفاهیم چکسام: چکسام صفر و قوانین اعتبارسنجی UDP در IPv6

سرایند UDP دارای یک فیلد چکسام ۱۶ بیتی است. در پروتکل IPv4 محاسبه این چکسام اختیاری بوده و مقداردهی 0x0000 به معنی عدم محاسبه آن توسط فرستنده تلقی می‌شود.

ساختار سرایند و شتاب‌بخشی با چکسام صفر در سوئیچینگ با توان عملیاتی بالا

مطابق با بخش ۳.۲ از استاندارد RFC 8086، در تونل‌های مبتنی بر IPv4 تنظیم چکسام بیرونی روی صفر مجاز است. از آنجا که بسته‌های داده داخلی معمولا دارای سازوکارهای حفاظتی و کنترلی خود هستند (نظیر چکسام TCP، پروتکل WireGuard ChaCha20-Poly1305 یا IPsec ESP)، محاسبه مجدد چکسام بیرونی توسط درگاه‌های شبکه موجب اتلاف توان پردازشی CPU می‌شود.

صفر قرار دادن چکسام بیرونی به کارت‌های شبکه (NIC) امکان می‌دهد بسته‌ها را با بیشترین توان سخت‌افزاری پردازش و ارسال کنند.

مدیریت الزامات چکسام بیرونی IPv6 بر اساس استانداردهای RFC 6935 و RFC 6936

در استاندارد پایه IPv6 (RFC 8200)، محاسبه چکسام UDP الزامی است و هر گره دریافت‌کننده در صورت مشاهده چکسام صفر باید بسته را دور بریزد.

این الزام مانعی جدی بر سر راه تونل‌های پرسرعت در بستر IPv6 ایجاد می‌کرد. برای برطرف ساختن این مشکل، استانداردهای RFC 6935 و RFC 6936 الزامات را تسهیل نموده و استفاده از چکسام صفر را تحت شرایط مشخصی مجاز شمردند:

• پایانه‌های تونل باید اطمینان حاصل کنند که بار مفید داخلی سازوکار خطایابی مناسبی دارد.
• درگاه شبکه باید بسته‌ها را تنها به پورت‌های تعیین‌شده هدایت کند تا تداخلی با سایر برنامه‌های UDP ایجاد نشود.
• ترافیک باید در شبکه‌های زیرساخت مدیریت‌شده با درصد خطای بسیار ناچیز جریان یابد.

شبکه ستون فقرات Anycast رابرد RiceGuard: معماری مش چندمسیره بدون قطبش

سامانه VPNRice از لایه مش RiceGuard در لایه ۳ برای ارتباط میان نقاط حضور Anycast بر بستر تامین‌کنندگان معتبر Tier-1 بهره می‌برد. در ساختارهای توزیع‌شده متراکم، قطبش هشینگ می‌تواند پایداری ارتباط کاربران را مختل سازد.

معماری RiceGuard با به کارگیری پورت‌های انتروپی UDP این مشکل را رفع می‌کند:

• تزریق پویای انتروپی: گره‌های لبه Anycast یک هش ۱۶ بیتی از نشست‌های کاربر ایجاد کرده و آن را در پورت مبدا بسته‌های ارسالی بین مراکز داده قرار می‌دهند.
• توزیع بار متقارن: ترافیک تونل به صورت یکپارچه روی مسیرهای موازی ۳۲ و ۶۴ گانه ECMP هدایت شده و نیازی به پردازش عمیق توسط اپراتورها نخواهد بود.
• حفظ پایداری نشست‌ها: مقدار انتروپی برای هر اتصال مشخص ثابت مانده و از جابه‌جایی نابهنگام بسته‌ها جلوگیری می‌کند و تاخیر را زیر ۱ میلی‌ثانیه نگه می‌دارد.
• کنترل خودکار شکستگی بسته‌ها: سامانه RiceGuard با تنظیم خودکار مقادیر MSS مانع از قطع اتصالات می‌شود. کاربران می‌توانند برای ارزیابی مشخصات اتصال به بخش /what-is-my-ip مراجعه نمایند.

برای دسترسی به ارتباط پایدار روی دستگاه‌های گوناگون می‌توانید نرم‌افزارهای مورد نیاز را از بخش /download دریافت فرمایید. بررسی تخصصی پایداری اتصالات در هنگام نوسانات مسیریابی در مقاله /news/bgp-graceful-restart-rfc-4724-llgr-anycast-resilience و تحلیل استفاده مجدد از پورت‌های اتصال در /news/tcp-time-wait-state-rfc-1337-port-exhaustion-vpn ارائه گردیده است.

پیاده‌سازی کاربردی: پیکربندی GRE-in-UDP و FOU در لینوکس

هسته لینوکس به صورت پیش‌فرض از تونل‌های مبتنی بر UDP از طریق ساختار Foo-over-UDP (FOU) پشتیبانی می‌کند. مدیران شبکه می‌توانند تونل‌های GRE-in-UDP را با دستورهای iproute2 راه‌اندازی کنند.

فعال‌سازی ماژول‌های هسته و ایجاد پورت دریافتی:

ماژول‌های مورد نیاز را بارگذاری کرده و پورت شنود استاندارد RFC 8086 را روی درگاه A تنظیم کنید:

# بارگذاری ماژول‌های مربوط به FOU و GRE
modprobe fou
modprobe ip_gre

# باز کردن پورت دریافت ترافیک FOU برای استاندارد RFC 8086 (پورت 4754)
ip fou add port 4754 gue

ایجاد رابط کاربری تونل GRE-in-UDP:

رابط مجازی را همراه با تنظیم انتروپی خودکار پورت مبدا ایجاد نمایید:

# تنظیم رابط کاربری تونل روی درگاه A
ip link add name tun-gre-udp type gre     remote 203.0.113.2 local 198.51.100.1     ttl 64     encap fou encap-sport auto encap-dport 4754

# انتساب آدرس IP و فعال‌سازی رابط با تنظیم MTU مناسب
ip addr add 10.200.0.1/30 dev tun-gre-udp
ip link set dev tun-gre-udp up mtu 1440

عبارت encap-sport auto نقشی کلیدی دارد و به هسته لینوکس دستور می‌دهد تا مقدار هش هر جریان داخلی را به صورت خودکار محاسبه کرده و در پورت مبدا UDP خارجی قرار دهد.

بررسی و سنجش توزیع ترافیک از طریق دورسنجی:

مشخصات کارت شبکه ایجاد شده را بررسی کنید:

ip -d link show tun-gre-udp

خروجی نشان‌دهنده فعال بودن قابلیت کپسوله‌سازی است:

tun-gre-udp: gre/ip remote 203.0.113.2 local 198.51.100.1 ttl 64
    encap fou encap-sport auto encap-dport 4754

برای اطمینان از توزیع بسته‌ها می‌توان از ابزار tcpdump استفاده کرد:

tcpdump -ni eth0 udp port 4754

نتایج به دست آمده تنوع پورت‌های مبدا را به نمایش می‌گذارند:

21:20:15.102482 IP 198.51.100.1.53120 > 203.0.113.2.4754: UDP, length 1448
21:20:15.102590 IP 198.51.100.1.61445 > 203.0.113.2.4754: UDP, length 1448
21:20:15.102645 IP 198.51.100.1.49812 > 203.0.113.2.4754: UDP, length 1448

هر جریان ترافیکی از یک پورت مبدا جداگانه (53120، 61445، 49812) استفاده می‌کند که به سوئیچ‌های میانی اجازه می‌دهد بسته‌ها را به طور متعادل در تمام مسیرهای موازی ECMP هدایت کنند.