Як діагностувати втрату пакету?

Я усвідомлюю, що це дуже суб'єктивно і залежить від ряду змінних, але мені цікаво, через які кроки проходить більшість людей, коли їм потрібно діагностувати втрати пакетів у певній системі?

Я мережевий інженер, тому опишу це з моєї точки зору.

Для мене діагностування втрати пакету зазвичай починається з "це не дуже добре працює". Звідти я зазвичай намагаюся знайти комплект якомога ближче до обох кінців зв'язку (як правило, робоча станція в офісі та сервер десь) і пінг якомога ближче до іншого кінця (в ідеалі "віддаленої кінцевої точки", але іноді є брандмауери, через які я не можу надсилати пінг, тому доведеться влаштуватися на LAN-інтерфейс на маршрутизаторі) і побачити, чи можу я побачити будь-яку втрату.

Якщо я бачу втрати, це зазвичай випадок "недостатньої пропускної здатності" або "зв'язку з проблемами" десь посередині, тому знайдіть маршрут через мережу і почніть з середини, що зазвичай дає тобі один чи інший кінець.

Якщо я не бачу втрати, наступними двома кроками є "надіслати більше пінгів" або "надіслати більші пінгви". Якщо це не сортує, не вказує на те, у чому полягає проблема, саме час почати переглядати політику QoS та статистику інтерфейсу через увесь шлях між кінцевими точками.

Якщо це нічого не знайде, саме час почати сумніватися у ваших припущеннях, чи дійсно ви страждаєте від втрати пакетів. Єдиний вірний спосіб пошуку - це одночасне захоплення з обох кінців, або за допомогою WireShark (або його еквівалента) на хостах, або за допомогою підключення снайферних машин (можливо, за допомогою WireShark або подібних) за допомогою мережних підключень. Потім настає задоволення від порівняння двох пакетів захоплення ...

Іноді те, що приписується "втрата пакету" - це просто те, що на стороні сервера помітно повільніше (наприклад, переміщення бази даних "з тієї самої локальної мережі" на "20 мс" та використання запитів, для яких потрібно дуже багато вперед-назад між передньою частиною та базою даних).

З точки зору системи Linux, я спершу шукаю втрати пакетів у мережевому інтерфейсі ethtool -S ethX.

Більшу частину часу, збільшуючи кільцевий буфер, ethtool -G ethX rx VALUEвирішує це.

Іноді переривання не врівноважуються, оскільки в системі відсутня служба irqbalance, тому загляньте в chkconfig(EL) або update-rc(Debuntu), щоб побачити, чи працює ця служба. Ви можете сказати, чи переривання не врівноважуються, оскільки /proc/interruptsбуде показано лише Core 0, що обслуговує всі канали IRQ.

Якщо цього не зробити, можливо, вам доведеться збільшити, net.core.netdev_max_backlogякщо система пропускає більше кількох гігабітних трафіку, а може бути net.core.netdev_budget.

Якщо це не працює, ви можете налаштувати значення переривання, з’єднуючись ethtool -C.

Якщо в мережевому інтерфейсі немає крапель пакетів, загляньте netstat -sі перевірте, чи є краплі в буферах сокетів, про них буде повідомлено статистику типу " pruned from receive queue" і " dropped from out-of-order queue".

Ви можете спробувати збільшити буфери сокета за замовчуванням для відповідного протоколу (наприклад: net.ipv4.tcp_rmemдля TCP).

Якщо програма встановлює власний розмір буфера сокета, то програмі можуть знадобитися зміни конфігурації. Якщо у вашій програмі розміщено буфер жорсткого коду, розмістіть буфер, подайте скаргу до постачальника програми.

Особисто мені не подобається завантаження протоколу на NIC (контрольна сума, завантаження сегментації, велике завантаження), оскільки це, мабуть, викликає більше проблем, ніж варто. Пограти з цими налаштуваннями, використовуючи, ethtool -Kможливо, варто спробувати.

Подивіться на параметри модулів для вашого NIC ( modinfo <drivername>), оскільки вам може знадобитися змінити деякі функції. Якщо навести один із прикладів, я зіткнувся із застосуванням Intel Flow Flow Director у системі, яка обробляє один великий потік TCP, ймовірно, шкодить ефективності цього потоку, тому вимкніть FDir.

Крім того, ви налагоджуєте цю конкретну систему вручну для її конкретного навантаження, що, мабуть, виходить за рамки вашого питання.

Почну з використання інструменту захоплення пакетів, таких як: wireshark (в Windows) і tcpdump (на терміналі Linux).

Я також перевірю конфігурацію брандмауера (хост-брандмауер, а також мережевий брандмауер).

Ізолюйте, потім усуньте.

Знайдіть найменший підмножина шляхів із проблемою. Зробіть це, випробувавши різні комбінації та / або перегорнувши звіти користувачів. Не забудьте врахувати час вирівнювання. Можливо, це лише пакетна втрата всього трафіку до певної мережі, а може страждають лише бездротові клієнти. Враховуйте різні типи трафіку (обмеження ставки на пінгвах). Знайдіть найнадійніший і легко повторюваний спосіб його тестування.

Тоді усуньте потенційні причини. Скорочення трафіку посиланнях (тимчасово), видалення джерел перешкод із спектру, відключення певних клієнтів. Зрештою ви знайдете джерело проблеми.

Іноді ви можете приймати ярлики, дивлячись на звалища пакетів або здогадуючись (це завжди bittorrent). Крім того, скажіть, що ваш сервер за замовчуванням професора є дивним.

Pings може не відображати втрати пакетів, якщо ви не надсилаєте великі пінгси! У мене в мережі була втрата пакету, яка була непомітною, поки я не збільшив розмір пакету ping.

Для вікон:

ping -n 30 -l <largevalue> <target>

Для largevalueЯ використовував 40960 (40k пакетів)

Для targetя використовував перші кілька IP - адрес зtracert google.com

(що було моїми маршрутизаторами та кабельним модемом). Один з пристроїв далі по ланцюжку мав жахливі втрати пакетів (> 60%) для великих пакетів, але 0% для малих. Я виправив його, перезавантаживши його, але це може бути кабель або щось внутрішнє, що потребує заміни.