نگاشت پورت دسترسی بدون برچسب به VNI درست EVPN
قاب میزبان بدون برچسب توسط پورت دسترسی طبقهبندی میشود و سپس VTEP آن را بهعنوان VNI حمل میکند. ورودی، خروجی و مدل سرویس را جداگانه بررسی کنید.
یک میزبان اترنت معمولی قابهای بدون برچسب میفرستد و پارچه EVPN باز هم باید آنها را در سرویس مستأجر درست حمل کند. پورت دسترسی قاب را در یک بخش محلی طبقهبندی میکند، VTEP آن بخش را به یک VNI نگاشت میکند و اتصال دور قاب را همانگونه که میزبانش انتظار دارد ارائه میدهد. VLAN و VNI بخشهای متفاوتی از این مسیر را مشخص میکنند و لازم نیست شماره مشترک داشته باشند. runbook زیر را به ترتیب اجرا کنید، چون خطا در هر مرحله همان نشانه را تولید میکند: میزبانی که میفرستد و چیزی دریافت نمیکند.
دنبال کردن یک قاب در سراسر پارچه
برای یک سرویس ساده مبتنی بر VLAN، یک مسیر نمونه چنین است:
Host A: untagged frame
to access port: local VLAN 110
to VTEP A: L2VNI 50110
to VTEP B: corresponding local service
to access port: untagged frame to Host Bشمارههای VLAN و VNI نمونهاند، نه قاعده. VLAN محلی یک طبقهبندی ورودی است که روی یک سوئیچ وجود دارد؛ L2VNI شناسه سرویس لایه رویی است که هر دو VTEP آن را میفهمند. مشخصات لایه رویی RFC 8365 شناسه سرویس را از نحوه اتصال میزبان جدا نگه میدارد و سه شکل را نام میبرد: مبتنی بر VLAN، دستهبندیشده و آگاه از VLAN.
پیکربندی طبقهبندی ورودی
میزبان نشانی دارد و به هیچ چیز نمیرسد، در حالی که خود پورت دیده میشود. تعیین کنید پورت واقعاً در کدام حالت اتصال است — پورت دسترسی که قابهای بدون برچسب را حمل میکند یا trunk با VLAN بومی — و دقیقاً همان را صریح تنظیم کنید. قاب بدون برچسب باز هم پورت را درون یک بخش محلی نامدار ترک میکند و آن بخش یک تصمیم است نه اثر جانبی پلتفرم. پیکربندی جاری پورت را باز کنید و طبقهبندیای را بخوانید که واقعاً دارد، بهجای اعتماد به مقدار پیشفرض سازنده که هرگز تنظیم نکردهاید.
روی یک سوئیچ معمولی ترتیب کار تغییر حالت و تخصیص VLAN دسترسی است و پس از آن بررسی اینکه پورت واقعاً بالاست و در آن حالت قرار دارد. اگر پورت trunk باشد، VLAN بومی قابهای بدون برچسب را مدیریت میکند و آن پیکربندی دیگری با حالتهای خرابی متفاوت است. پیش از ادامه هم حالت و هم VLAN را ثبت کنید.
show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan briefپیکربندی VTEP و نگاشت VNI
VTEP کپسولهسازی VXLAN و VNI را اضافه میکند. میزبان آن سرآیند را تولید نمیکند و لازم نیست بداند سرویس وجود دارد.
VLAN محلی را با شکل فرمانی که پلتفرم پشتیبانی میکند به L2VNI نگاشت کنید و آن نگاشت را در دو انتهای سرویس یکسان نگه دارید. L2VNI مستأجر و L3VNI که برای مسیریابی میان زیرشبکهها به کار میرود دو شیء متفاوتاند و آمیختن شمارههایشان مسیریابی را میشکند بدون آنکه به مسیر L2 دست بزند؛ و به یاد داشته باشید که یک مسیر underlay کارآمد به VTEP دور به لایه دیگری از چیدمان تعلق دارد.
اگر نگاشت نادرست باشد، قاب باز هم وارد پارچه میشود و صرفاً در سرویس اشتباه فرود میآید. به همین دلیل بررسی، بررسی سرویس است نه بررسی پیوند.
پیکربندی ارائه در خروجی
در انتهای دور، سرویس دریافتشده باید دوباره به آن چیزی تبدیل شود که میزبان انتظار دارد: اترنت خالی روی پورت دسترسی، برچسب مشخص روی trunkی که شما کنترل میکنید و پردازش برچسب درونی که با مدل سرویس انتخابی مطابقت دارد. پیش از متهم کردن لایه رویی، فهرست VLANهای مجاز روی trunk را بررسی کنید، چون برچسبی که trunk خروجی اجازه نمیدهد پس از آنکه لایه رویی کار خود را انجام داد حذف میشود. تأیید کنید که میزبان دور همان ارائهای را انتظار دارد که دریافت میکند، نه آنچه نمودار شما فرض کرده بود.
اینکه برچسب درونی باقی میماند یا نه ویژگی مدل سرویسی است که انتخاب کردید، پس هیچ مقالهای نمیتواند بهطور کلی حذف یا حفظ را وعده دهد. طراحیای که یک رفتار را فرض میکند و پلتفرمی که رفتار دیگر را پیاده میکند، آزمون پیوند را میگذرانند و در برنامه شکست میخورند.
یادگیری MAC محلی، مسیر سرویس EVPN و نگاشت اتصال دور را با هم بخوانید و کشف همسایگانی را که برنامه لازم دارد، بهجای فقط یک ping به راه بیندازید. نشانی MACی که در دامنه پل دیگری یاد گرفته شده میتواند آنجا کاملاً معتبر باشد و باز هم به سرویس اشتباه اشاره کند.
تأیید با یک جفت میزبان
یک جفت میزبان را بالا بیاورید و پیش از افزودن جفت دوم، کل مسیر را اثبات کنید. سپس وضعیت را روی هر دو VTEP بخوانید و تأیید کنید که همان شناسه سرویس در دو انتها دیده میشود.
show mac address-table vlan 110
show bgp l2vpn evpn
show nve peersبرای هر انتها چهار مقدار بنویسید: ارائه پورت، بخش محلی، L2VNI و ارائه معکوس در خروجی. آن ثبت به مهندس بعدی اجازه میدهد ببیند چرا میزبان یک اتصال ساده بدون برچسب دارد در حالی که پارچه سرویس مستأجر را حمل میکند. اگر تغییری شکست خورد، پورت را به VLAN قبلی بازگردانید و همان جفت را دوباره آزمایش کنید تا بازگشت یک وضعیت شناختهشده باشد نه یک حدس.