نشست BGP برقرار، مسیر مشتری خراب: MPLS روی DMVPN

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

این شکاف در طراحی MPLS روی DMVPN آسان‌تر دیده می‌شود، جایی که مسیر از طریق هاب و مسیر مستقیم از طریق شعبه می‌توانند به دلایلی بی‌ارتباط با همسایگی رفتار متفاوت داشته باشند.

نشست در واقع چه چیزی را اثبات می‌کند

BGP روی TCP کار می‌کند، پس هر همتا پیش از هر چیز دیگری به مسیری به نشانی طرف مقابل نیاز دارد. اگر برای آن طرف یک loopback انتخاب کنید، یک الزام دسترس‌پذیری ساخته‌اید، نه تضمین ارسال. سپس نشست می‌تواند از طریق رابطی برقرار بماند که ترافیک مشتری هرگز از آن استفاده نمی‌کند.

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

چهار سازوکار، نه یکی

مستندات Cisco درباره MPLS روی DMVPN قطعات را روشن از هم جدا می‌کند. MP-BGP برچسب‌های لایه پوششی مشتری را میان دستگاه‌های لبه ارائه‌دهنده توزیع می‌کند. MPLS از آن برچسب‌ها برای انتخاب بافت ارسال یک بسته استفاده می‌کند. NHRP یک نشانی لایه پوششی را به طرف انتقالی که تونل پویا نیاز دارد نگاشت می‌کند. IPsec مسیر همتا را در جایی که اعمال شود محافظت می‌کند.

هر یک از این چهار می‌تواند درست باشد در حالی که دیگری نادرست است، و ترکیب آن‌هاست که ترافیک را حمل می‌کند. تبادل مسیر می‌تواند کامل شود در حالی که اتصال برچسب برای یک VRF غایب است، یا نگاشت NHRP به نشانی انتقالی کهنه اشاره می‌کند، یا تونل وجود دارد اما هیچ سیاستی بسته داخلی را مجاز نمی‌کند. هیچ‌یک از این شرایط نشست را نمی‌اندازد.

مسیر هاب را با میان‌بر مقایسه کنید، هر بار یک متغیر

میزبان مبدأ، میزبان مقصد و VRF را ثابت کنید و سپس همان جریان را دو بار دنبال کنید. در مسیر هاب، گام بعدی، برچسب سرویسی که بافت مشتری دور را شناسایی می‌کند و نگاشت لایه پوششی به انتقال را یادداشت کنید. در مسیر مستقیم مورد نظر نیز همان سه چیز را یادداشت کنید. تفاوت این دو فهرست همان عیب است، یا نبود آن.

جریان را در طول مقایسه ثابت نگه دارید. تغییر میزبان مبدأ، VRF یا مقصد میان مشاهده‌ها دو روایت بی‌ارتباط می‌سازد، و این رایج‌ترین راه خراب شدن این تمرین است.

آزمون‌های loopback را در اتاق خودشان نگه دارید

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

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

ادعاهای مربوط به نسخه و عیب به شواهد خود نیاز دارند

گزارش‌های میدانی گاهی تغییر ماسک میزبان یا نشانی مبدأ BGP را توصیه می‌کنند، و چنین گزارش‌هایی تنها در کنار عیبی که درباره آن نوشته شده‌اند و نسخه‌هایی که تحت تأثیر قرار گرفته‌اند ارزش خواندن دارند. راه‌حل موقت یک نسخه، بیانیه‌ای نیست که معماری هیچ پیشوند /32 را پشتیبانی نمی‌کند.

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