مسیر گم‌شده در VRF: محلی، VPNv4 یا جدول ارسال؟
پیشوندی که در VRF نیست، در VPNv4 نیست و در CEF نصب نشده است سه ایراد متفاوت است. پیش از ویرایش هدف‌های مسیر، جدول‌ها را به ترتیب بخوانید.
مشتری می‌گوید پیشوندی پس از تغییر هدف مسیر گم شده است، و نخستین تصویری که می‌فرستد معمولاً جدول اشتباه است. سه جدول متفاوت به سه پرسش متفاوت پاسخ می‌دهند: آیا پیشوند درون VRF وجود دارد، آیا به عنوان مسیر VPNv4 اعلام و وارد شده است، و آیا واقعاً یک ورودی ارسال نصب شده است. خواندن آن‌ها بیرون از ترتیب، نتیجه‌گیری‌های مطمئن و نادرست می‌دهد. این راهنما یک پیشوند محلی و یک پیشوند دور را به ترتیب از هر سه جدول می‌گذراند و با طرح بازگردانی برای تغییر RT که آن را آغاز کرد پایان می‌یابد.
پیشوند و جدولی که به آن تعلق دارد را نام ببرید
پیش از تایپ هر چیزی دو پیشوند را یادداشت کنید. یکی محلی در سایت مشتری است که از یک رابط متصل یا اعلام CE آموخته می‌شود. دیگری دور است و انتظار می‌رود از ستون فقرات ارائه‌دهنده برسد. آن‌ها از مسیرهای متفاوت به همان VRF می‌رسند، و ایراد در یکی چیزی درباره دیگری نمی‌گوید.
| Table | Question it answers | Command |
|---|---|---|
show ip vrf CUST-A | Which RTs are attached for import and export | Read the RT lists before anything else |
show ip route vrf CUST-A | Is the prefix present in this VRF at all | Local and imported routes both appear |
show ip bgp vpnv4 all | Was the NLRI advertised and retained | Keyed by route distinguisher |
show ip cef vrf CUST-A | Was a forwarding entry installed | Proves a usable path, not just a BGP entry |
تفاوت دو شناسه را روشن نگه دارید، چون بیشتر سردرگمی در این تیکت‌ها از همان‌جا می‌آید. متمایزکننده مسیر بخشی از NLRI در VPNv4 است و وجود دارد تا پیشوندهای یکسان مشتری در سراسر ستون فقرات یکتا شوند. هدف مسیر یک اجتماع توسعه‌یافته است که به عنوان ویژگی حمل می‌شود، و سیاست ورود و خروج با همان تطبیق می‌دهد. این نام دومی برای متمایزکننده نیست و در بسته‌های مشتری حمل نمی‌شود.
گام 1: اثبات کنید پیشوند در VRF است
با نمای محلی آغاز کنید، سپس با هدف‌های مسیری که ورود را کنترل می‌کنند. اگر پیشوند محلی اینجا نیست، هیچ چیز در بالادست نمی‌تواند مقصر باشد:
show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-Aپیشوندی که به صورت متصل یا ایستا دیده می‌شود محلی آموخته شده است، و حضورش چیزی درباره صادر شدنش نمی‌گوید. این رایج‌ترین بدخوانی در این روند کار است: جدول VRF سالم فقط شاهد یادگیری محلی است. سمت صدور پرسشی جداگانه است که نمای همسایه و هدف صدور متصل به آن پاسخ می‌دهند.
تا اینجا هستید فهرست‌های RT روی VRF را بررسی کنید. اگر هدف ورود موردنظر در فهرست نیست، هر چه در پایین دست است بی‌اهمیت می‌شود. اگر هست اما با آنچه PE دور صادر می‌کند تفاوت دارد، ایراد را بدون باز کردن حتی یک ضبط بسته پیدا کرده‌اید.
گام 2: جدول VPNv4 و هدف‌هایش را بخوانید
جدول VPNv4 نشان می‌دهد صفحه کنترل واقعاً چه چیزی مبادله کرده است. پیشوند دور را زیر متمایزکننده درست بجویید، سپس اجتماع‌های متصل به آن را ببینید:
show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routesورودی با هدف مسیر درست اما بدون نصب محلی به سیاست ورود یا به انتخاب مسیر اشاره می‌کند، نه به دسترس‌پذیری. ورودی که اصلاً در جدول VPNv4 دیده نمی‌شود به بالادست اشاره دارد: ممکن است PE مبدأ آن را صادر نکرده باشد، یا نشست خانواده نشانی را حمل نکند.
حالت سومی هم هست که در زمان تغییرها مردم را گیج می‌کند. برخی سکوها با استفاده از اطلاعات عضویت هدف مسیر محدود می‌کنند کدام مسیرهای VPN را درخواست یا نگه دارند، بنابراین نبودن یک NLRI دور در یک نمای فیلترشده دلیل بر نبودن اعلام در هیچ جا نیست. پیش از نتیجه‌گیری که مسیری به‌طور جهانی پس گرفته شده، جدول فیلترنشده و مسیرهای اعلام‌شده همسایه را بررسی کنید.
گام 3: تأیید کنید چیزی نصب و برچسب‌گذاری شده است
ورودی BGP یک تصمیم است، نه یک مسیر. جدول‌های ارسال می‌گویند بسته‌ها جایی برای رفتن دارند یا نه:
show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-Aورودی CEF با مجاورت حل‌شده و برچسب خروجی یعنی ترافیک صفحه داده باید کار کند، و هر نشانه باقی‌مانده به برنامه یا به فیلترکردن درون VRF مربوط است. ورودی CEF که پرش بعدی حل‌نشده نشان می‌دهد یعنی مسیر برچسب ناقص است هرچند BGP سالم به نظر می‌رسد، و دقیقاً همین حالتی است که تصویر جدول BGP بازبینی یک تغییر را گمراه کرده است.
برچسبی که PE محلی تحمیل می‌کند را با برچسبی که PE دور انتظار دریافتش را دارد مقایسه کنید. ناهمخوانی میان دو نما ایرادی در تخصیص برچسب یا در نشست است، و با ویرایش هدف‌های مسیر درست نمی‌شود، هر چند بار که این کار را بکنید.
تغییر RT را با گستره اعلام‌شده بازگردانید
اگر ایراد با ویرایش هدف مسیر آغاز شده است، آن را به عنوان یک گام آگاهانه لغو کنید و بگویید چه گستره‌ای را تغییر می‌دهید. برداشتن هدف ورود، واجدبودن را درون همان VRF پس می‌گیرد. اعلام VPNv4 را از ستون فقرات پاک نمی‌کند، و در برخی سکوها مسیر در جدول نگه داشته می‌ماند. این‌ها نتایج متفاوتی هستند و اثر قابل مشاهده برای کاربر بستگی دارد به اینکه کدام یک را می‌خواهید.
configure terminal
vrf definition CUST-A
address-family ipv4
no route-target import 65000:410
end
clear ip bgp vpnv4 vrf CUST-A soft inبازآرایی نرم‌افزاری ورودی وقتی نشست از پیش پیشوندها را ذخیره می‌کند کافی است؛ بازنشانی سخت یک نشست رو به ارائه‌دهنده در ساعات کاری تصمیمی است که فرد دیگری باید بگیرد. در Junos بررسی‌های معادل جدول هر VRF و جدول VPN را مستقیم می‌خوانند، و بازگردانی یک بازگشت هنگام commit است نه لغو فرمان به فرمان، پس پیش از شروع تفاوت پیکربندی را ثبت کنید.
با همان سه فرمانی که آغاز کردید و به همان ترتیب پایان دهید، و خروجی‌شان را با مهر زمانی ثبت کنید. تیکتی که می‌گوید RT غلط بود و اکنون درست است قابل استفاده دوباره نیست؛ تیکتی که نشان می‌دهد پیشوند در VRF، در VPNv4 و نصب‌شده در CEF است شواهدی است که نفر بعدی می‌تواند با آن مقایسه کند. اگر فقط دو مورد نخست تغییر کرده باشد، تغییر را تمام نکرده‌اید.