Усунення несправностей у "повільній" мережі

У всіх нас була скарга на те, що "мережа" в якийсь момент "повільна": може бути локалізована в одній кімнаті (комутаторі) або на одному комп’ютері, може бути просто Інтернет (DNS? Проблема браузера?), Може бути лише одна програма (тривалі запити SQL? Запуск AV-сканування?).

Коли ви виключаєте очевидні проблеми із системою та / або додатками, як ви беретесь на тестування мережі на повільність або нестабільну поведінку? Чи працюєте ви вгору по шарах OSI? Якщо так, то як рухатись до перевірки кожного шару? Що ви робите, щоб переконатися, що фізична мережа працює в невідомому середовищі? А як щодо занадто багато трансляцій чи трансляції шторму? 3 рівень і вище? простежити? Ще якісь поради, методи, ідеї? Потрібно мати функції та інструменти (дзеркальне відображення порту, SNMP, моніторинг тощо) для всіх розмірів мереж?

tcpdump і wireshark - ваші друзі.

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

Існує багато типів "повільних".

Ви можете відстежувати затримку на локальних та інтернет-сайтах, використовуючи такий інструмент, як SmokePing. (SmokePing можна налаштувати для відстеження затримок ICMP, а також затримки обслуговування від служб TCP)

Ваші комутатори повинні відслідковувати широкомовні пакети проти одноадресних пакетів. Графік цього співвідношення

Мені також подобається відстежувати трасування (перевіряти доменні імена хоп-провайдерів між "важливими" сайтами).

Я сподіваюся, що ці коментарі допоможуть.

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

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

Не забувайте про виправлену проблему перезавантаження, особливо для систем Windows, навіть сьогодні. Раніше це було настільки багато, що я б запитав людей "Ви перезавантажили? Ну, спробуйте це, і повідомте мені, якщо проблема не зникне" - це вирішило дуже великий відсоток питань, про які я задавався.

Проблеми з вирішенням DNS та основне підключення часто є також низько висячими фруктами (ACL на маршрутизаторах, повітряні проміжки в мережі, пінг / traceroutes / mtrs на віддалені сайти тощо).

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

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

Ваш брандмауер може мати можливість увійти до пристрою syslog; якщо так, запишіть все, що можете, і перегляньте ці підказки. Це стане простіше, якщо ви запускаєте щось на зразок syslog-ng або rsyslog або splunk, що дозволяє ділити ваші журнали дещо, а не мати справу з одним монолітним файлом.

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

Ось пара корисних інструментів для усунення затримок та інших мережевих проблем:

• режим OSI л - починати з самого низу і працювати ваш шлях вгору
• ping - перевірити RTT (тобто затримку)
• HTTP-пінг - корисний, якщо ваш брандмауер блокує звичайні ICMP
• ping -r 9 - корисний для виявлення асиметричних ситуацій маршрутизації
• traceroute - як мої пакети потрапляють туди і як маршрутизатори реагують на цьому шляху? Майте на увазі, що маршрутизатори часто обробляють ці пакети з низьким пріоритетом, тому реальна продуктивність може бути кращою.
• Wireshark - потрібен певний досвід, але ви не можете отримати набагато нижчий рівень
• SpeedGuide.net TCP / IP Analyzer - перевірити настройки TCP вашого ПК
• SG TCP Optimizer - (лише для Windows) пропонують способи оптимізації налаштувань NIC
• IP Chicken - яка ваша IP-адреса джерела (не NAT'д)?
• http://downforeveryoneorjustme.com/ - можливо, це ти ...
• Тест на швидкість пропускної здатності - перевірити швидкість завантаження / завантаження
• Мережеві інструменти - запускайте інструменти / тести за межами вашої мережі
• перевірити ваші мережеві порти на наявність помилок / CRC / тощо. -
• перевірити вашу мережу на надмірне використання (монітори пропускної здатності) та трансляції штормів
• перевірка на одноразове затоплення - використовуйте проводку та монітор для одноадресного руху, який не призначений для вашої робочої станції.
• переконайтеся, що кореневий міст моєго розміщеного дерева розміщений правильно

Якщо ви працюєте з бездротовою мережею, однією з частих повільних збоїв є перешкоди каналу. Купа SSID в одній області може дійсно уповільнити мережевий трафік. (Подумайте: демонстрація iPhone 4 на WWDC '10).

Вирішити цю проблему досить легко, якщо за допомогою програмного забезпечення, яке може показати вам схему бездротового трафіку в цьому районі. Є хороший безкоштовний та веб-сайт за адресою: http://meraki.com/tools/stumbler . (розголошення: я працюю на Меракі)

Щоб зменшити перешкоди, краще бути на каналах 1, 6 або 11. Використання передач 802.11n з частотою 5 ГГц також може допомогти.

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

Напевно, не збирається знайти точну проблему, але це дасть вам гарне вихідне місце, щоб допомогти звузити проблему.

Я починаю з самого зовнішнього маршрутизатора і працюю вниз, і вимірюю продуктивність найпримітивнішим способом: використовую тестовий пропускну здатність веб-сайту або відомий зовнішній FTP-сайт, який надасть вам швидкість завантаження / завантаження, і продовжуйте знижуватися, поки ви не знайти рівень, де проблема знаходиться.

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

Вам також потрібно знати ваші сервери та робоче середовище / клієнтське середовище, а не просто припускати, що користувач правильний, коли кажуть, що "мережа повільна". Потрібно методично вирішити кожне питання - як уже говорили інші, ви повинні спершу мати можливість переглядати та ідеально відтворювати помилку, а потім працювати звідти так, що має сенс для сценарію.

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

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

Повільна мережа - поширене явище. Повільна швидкість мережі може бути викликана низкою речей. усунення повільних мереж - одна з найпоширеніших та найскладніших робіт у щоденному управлінні мережею.

За даними аналізу, основними причинами повільної роботи мережі є:

Loopback
Broadcast/Multicast storm
Virus attack
Server slow response
Too many clients
Application slow response
Error client mask

Як ми можемо швидко з’ясувати причину того, що відбувається повільна мережа? Хороша ідея збирати та аналізувати пакети за допомогою мережевого аналізатора (Ax3soft Unicorn, wireshark тощо).

Ви також прочитали статтю "Знайти причини повільної мережі", натиснувши на URL ( http://www.ids-sax2.com//Unicorn/Tutorials/Find-Reasons-for-Slow-Network-with-Ax3soft-Unicorn .htm ) відвідати його.