ECMP به یک VTEP: منشأ آنتروپی VXLAN

این ادعا که چندمسیری‌بودن هم‌هزینه برای یک مسیر میزبان بی‌فایده است آن‌قدر تکرار می‌شود که درست به نظر می‌رسد. /32 یک نشانی مقصد را انتخاب می‌کند و هیچ چیز در این انتخاب بسته را به یک پیوند فیزیکی محدود نمی‌کند. وقتی مقصد یک نقطه پایانی تونل VXLAN دوردست است، چندین گام بعدی می‌توانند جریان‌های لایه‌ای متفاوت را حمل کنند و اینکه چنین کنند به آنچه هش ارسال مجاز به دیدنش است بستگی دارد. بقیه حساب‌وکتاب روی سرآیند بیرونی است، نه ویژگی پیشوند.

مسیر دسترسی‌پذیری را تعیین می‌کند؛ هش توزیع را.

افسانه: /32 یعنی یک مسیر

OSPF می‌تواند دسترسی‌پذیری هم‌هزینه به یک loopback VTEP را گزارش کند، در حالی که جدول ارسال گروهی از گام‌های بعدی را برای همان پیشوند نصب می‌کند. پروتکل نامزدها را فراهم می‌کند؛ سکو تصمیم می‌گیرد کدام‌یک قابل استفاده است و بسته چگونه تخصیص می‌یابد. هیچ پروتکل مسیریابی هش تازه‌ای برای هر قاب کپسوله‌شده محاسبه نمی‌کند. همین جدایی دلیل آن است که دو مسیریاب با مسیرهای یکسان باز هم می‌توانند ترافیک را متفاوت توزیع کنند.

به ورودی ارسال نصب‌شده نگاه کنید نه فقط نمایش مسیر، چون محدودیت‌های سخت‌افزار یا سیاست می‌توانند نامزدهایی را که صفحه کنترل هنوز اعلام می‌کند حذف کنند.

آنتروپی باید از کجا بیاید

میان دو VTEP نشانی‌های بیرونی مبدأ و مقصد ثابت می‌مانند و پورت مقصد UDP در استقرار متعارف 4789 است. هشی که فقط آن مقادیر را می‌خواند ورودی ثابت می‌بیند و مسیر ثابت برمی‌گرداند. چیزی در سرآیند بیرونی باید تغییر کند و VTEP همان دستگاهی است که می‌تواند آن را تغییر دهد.

RFC 7348 پیشنهاد می‌کند پورت مبدأ UDP از فیلدهای داخل قاب کپسوله‌شده گرفته شود. آن‌گاه گفتگوهای درونی متفاوت چندتایی‌های بیرونی متفاوت پدید می‌آورند که به یک هش انتقال معمولی چیزی برای کار کردن می‌دهد.

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

هشی را که واقعاً می‌گیرید بررسی کنید

اندازه بگیرید نه اینکه فرض کنید. نمونه‌ای از ترافیک کپسوله‌شده بگیرید و پورت‌های مبدأ بیرونی را ببینید، سپس نتیجه را با ورودی‌های ارسال و شمارنده‌های هر پیوند مقایسه کنید.

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

یک پورت مبدأ که در گفتگوهای درونی مختلف بسیاری دیده شود یعنی VTEP آن فیلد را تغییر نمی‌دهد و هیچ میزان تنظیم underlay بار را پخش نمی‌کند. پورت‌های متفاوت بسیار با یک گام بعدی در حال استفاده به گروه ارسال اشاره می‌کند.

شمارنده‌ها را پیش و پس از نمونه ثبت کنید و ترافیک نامرتبطی را که uplinkها را شریک است در نظر بگیرید، وگرنه اعداد بدتر از آنچه هش سزاوار است به نظر می‌رسند.

توزیع یکنواخت چه معنایی ندارد

هش به‌ازای هر جریان طراحی شده تا یک گفتگو را روی یک مسیر نگه دارد، تا زمانی که ورودی‌هایش و مجموعه مسیرهای در دسترس تغییر نکنند. از این رو یک انتقال بزرگ TCP همه uplinkها را تجمیع نمی‌کند و افزودن پیوندها آن جریان را سریع‌تر نمی‌کند. این رفتار عادی است، نه نقص.

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

با جفت‌های نشانی، انتقال‌ها و نرخ‌های نماینده زیر یک طرح تأییدشده آزمایش کنید و انتخاب اعضای تجمیع پیوند را از انتخاب چندمسیری مسیریابی‌شده جدا نگه دارید، چون دو مرحله هش الگوی خودشان را می‌سازند. گروه گام بعدی پر و آنتروپی بیرونی قابل‌مشاهده نتیجه را توضیح می‌دهند؛ طول پیشوند نه.