ناسازگاری دوپلکس روی پورت دروازه VPN: هر دو سر را بخوانید

یک کپی فایل از تونل برای یک ثانیه متوقف می‌شود، ادامه می‌یابد و گزارش‌های VPN چیزی نشان نمی‌دهند. برنامه شبکه را سرزنش می‌کند، شبکه برنامه را سرزنش می‌کند و پورت سوئیچ یازده ماه است که روشن است. این بررسی از همان توقف آغاز می‌شود و به سمت بیرون تا پیوند فیزیکی پیش می‌رود: پورت واقعاً چه می‌کند، سر دور چه می‌کند و شمارنده‌ها در مدتی که تماشا می‌کردید چه کردند. این کار پیش از آنکه کسی به تنظیم دوپلکس دست بزند ارزش انجام دادن دارد.

از توقف شروع کنید، نه از پورت

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

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

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

حالت عملیاتی را در هر دو سر بخوانید

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

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

سرعت، دوپلکس و اینکه مذاکره خودکار روشن است یا نه را ثبت کنید، سپس همان سه واقعیت را از سوئیچ مجاور یا پورت ارائه‌دهنده بگیرید. یک سر به‌تنهایی چیزی نمی‌گوید، زیرا ناسازگاری یک رابطه است نه یک تنظیم. هر دو سطر را کنار هم در تیکت بگذارید، با زمانی که آن‌ها را خواندید. نیمی از ارزش این تمرین داشتن دو قرائت در یک جاست.

اگر نمی‌توانید سر دور را بخوانید، نمی‌توانید این را عیب‌یابی کنید. از مالک حالت عملیاتی و شمارنده‌ها را بخواهید، یا پیش از شروع به تغییر سمت خود دسترسی ترتیب دهید.

حالت 10/100 با نیم‌دوپلکس چه شکلی است

روی پیوندهای مسی 10/100، یک سر مذاکره‌کننده خودکار می‌تواند سرعت همتای اجباری‌شده را تشخیص دهد بدون آنکه تنظیم دوپلکس آن را بیاموزد. تشخیص موازی سرعت را از سیگنال تعیین می‌کند و دوپلکس به جای مذاکره فرض می‌شود، بنابراین یک طرف ممکن است نیم‌دوپلکس بماند در حالی که طرف دیگر با دوپلکس کامل کار می‌کند.

راهنمای مذاکره خودکار سیسکو همان حالت خاص را توضیح می‌دهد. این استدلالی برای خاموش کردن مذاکره در همه‌جا نیست و درباره مس gigabit که دوپلکس در آن ثابت است و مذاکره خودکار برای بالا آمدن پیوند لازم است چیز مفیدی نمی‌گوید.

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

هر دو سر را با هم تغییر دهید، با راهی برای بازگشت

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

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

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

روی بسیاری از پیوندهای مدرن پاسخ درست این است که مذاکره خودکار را در هر دو سر روشن بگذارید نه اینکه چیزی را اجباری کنید. اعمال اجباری درمانی برای ناسازگاری مشخص در فناوری مشخص است، نه یک بهبود عمومی. مس gigabit به‌ویژه برای بالا آمدن پیوند به مذاکره خودکار نیاز دارد، پس توصیه 10/100 به آن منتقل نمی‌شود.

تأیید کنید که شمارنده‌ها به سمت بهتر حرکت کرده‌اند

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

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

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

اعداد قبل و بعد را با برچسب زمان در تیکت بنویسید. همان سابقه است که «VPN بهتر حس می‌شود» را به چیزی تبدیل می‌کند که مهندس بعدی می‌تواند بر آن بسازد.