QoS هر تونل، کل پهنای باند خروجی هاب شما را محدود نمی‌کند

این باور شبیه حساب‌وکتاب است: پنج spoken که هرکدام به 5 Mbit/s محدود شده‌اند، پس هاب حداکثر 25 Mbit/s حمل می‌کند. نیمهٔ اول درست است و نتیجه نه. سیاست هر تونل یک‌بار برای هر تونل اعمال می‌شود، نه یک‌بار برای هر هاب، و uplink مشترکی که هر پنج تونل از آن عبور می‌کنند هرگز در آن محاسبه ظاهر نمی‌شود. ازدحام روی uplink دقیقاً همان‌طور که بود باقی می‌ماند.

این باور از کجا می‌آید

سردرگمی قابل درک است، چون اطلاعات گروه NHRP اجازه می‌دهد یک تعریف سیاست برای مجموعه‌ای کامل از spoken اعمال شود. این مثل یک بودجهٔ مشترک در فایل پیکربندی خوانده می‌شود. آنچه واقعاً معنا می‌دهد این است که هر spoke نمونهٔ خودش از آن تعریف را می‌گیرد.

پس 5 Mbit/s برای هر spoke سقفی برای هر تونل است، و به تعداد تونل‌ها سقف وجود دارد.

یک نمونهٔ سیاست چه چیزی را کنترل می‌کند

راهنمای Cisco دربارهٔ QoS هر تونل در DMVPN روی IOS XE سیاست خروج هاب را توصیف می‌کند که از طریق اطلاعات گروه NHRP انتخاب و جداگانه روی هر spoke اعمال می‌شود. از این جمله دو محدودیت برمی‌آید و هر دو نادیده گرفته می‌شوند. نرخ به یک spoke تعلق دارد نه به سطلی مشترک، و این ویژگی ترافیک از هاب به spoke را کنترل می‌کند، نه برعکس.

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

محدودیت تجمیعی را در گلوگاه مشترک بگذارید

تجمیع باید جایی شکل بگیرد که واقعاً رقابت می‌کند: یعنی رابط فیزیکی که همهٔ تونل‌ها آن را به اشتراک می‌گذارند. Cisco یک shaper با کلاس class-default روی رابط فیزیکی را به‌عنوان سیاست فیزیکی هم‌زمان پشتیبانی‌شده برای این ویژگی مستند می‌کند، که بیانی محدودتر از هر سلسله‌مراتبی است که می‌توانید بنویسید. فرض کنید سیاست فیزیکی دومِ دلخواهی که ساخته‌اید پشتیبانی نمی‌شود تا کسی خلافش را ثابت کند.

سپس تصمیم بگیرید وقتی همهٔ spoken هم‌زمان مشغول‌اند چه می‌شود. کدام ترافیک پذیرفته می‌شود، کدام کلاس اولویت می‌گیرد و کدام صف مالک رقابت است. سقف هر spoke به هیچ یک از این پرسش‌ها پاسخ نمی‌دهد، چون هر spoke تنها در نظر گرفته می‌شود.

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

شمارنده‌ها به یک روش مشخص دروغ می‌گویند

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

کپی کردن یک نمونهٔ قدیمی traffic-shape در کنار یک policy map بی‌ربط ثابت نمی‌کند که دو نرخ همان بسته‌ها را کنترل می‌کنند.

تجمیع را آزمایش کنید، نه فقط سقف را

با یک spoke مشغول شروع کنید و تأیید کنید که به سقفش می‌رسد. سپس طبق یک برنامهٔ تأییدشده از همهٔ آن‌ها هم‌زمان ترافیک ارائه دهید و رابط فیزیکی را کنار اعداد هر تونل ببینید. اگر هر spoke روی سقف خودش بماند در حالی که uplink اشباع است و تأخیر بالا می‌رود، سیاست هر spoke دقیقاً همان‌طور که طراحی شده کار می‌کند و بودجه هنوز اشتباه است.

اصلاح در آن نقطه تصمیمی دربارهٔ ظرفیت یا پذیرش است. تنظیم مجدد اعداد هر spoke فقط تغییر می‌دهد که کدام شعبه اول شکایت کند.