Устранение неполадок в «медленной» сети

У всех нас была жалоба на то, что «сеть» в какой-то момент «медленная»: может быть локализована на одну комнату (коммутатор) или один компьютер, может быть просто Интернет (DNS? Проблема с браузером?), Может быть только одно приложение (длительные SQL-запросы? AV scan running?).

Если вы исключили очевидные проблемы с системой и / или приложением, как вы проводите тестирование сети на медлительность или нестабильное поведение? Работаете ли вы на уровне OSI? Если да, то как проверить каждый слой? Что вы делаете, чтобы убедиться, что физическая сеть исправна в неизвестной среде? А как насчет слишком большого количества передач или широковещательного шторма? Уровень 3 и выше? трассировка? Любые другие советы, методы, идеи? Должны ли иметь функции и инструменты (зеркалирование портов, SNMP, мониторинг и т. Д.) Для сетей любого размера?

tcpdump и wireshark - ваши друзья.

Я обнаружил, что просмотр пакетов по проводам «медленной» сети против «хорошей» сети - это обычно то, что выявляет проблему.

Существует много типов «медленных».

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

Ваши коммутаторы должны отслеживать широковещательные пакеты против одноадресных пакетов. График это соотношение.

Мне также нравится отслеживать трассировки (проверка доменных имен интернет-провайдеров между моими «важными» сайтами).

Я надеюсь, что эти комментарии помогут.

Трудно дать конкретные ответы, так как 90% этой работы - это опыт, который учит вас, где искать, какого рода проблемы, а остальные 90% знают, где искать в Google, чтобы получить подсказки, с чего начать.

Я обычно пробую бумажный пакет, например, чтобы клиент продемонстрировал проблему (в основном, чтобы исключить проблемы с пальцами и любые проблемы, которые могут возникнуть у клиента при описании своей проблемы), а затем пытаюсь продублировать проблему на другом компьютере. Это часто дает вам понимание того, где искать.

Не забывайте исправление проблемы перезагрузки, особенно для систем Windows, даже сегодня. Раньше было так много, что я спрашивал людей: «Вы перезагрузились? Хорошо, попробуйте и дайте мне знать, если проблема не исчезнет» - это решило очень большой процент вопросов, которые мне задавали.

Часто возникают проблемы с разрешением DNS и базовыми подключениями (списки ACL на маршрутизаторах, воздушные промежутки в сети, ping / traceroutes / mtrs для удаленных сайтов и т. Д.).

Для сервисов, которыми вы непосредственно управляете, запуск nagios или чего-то такого, что гарантирует, что сервис действительно работает, часто может побудить вас исправить проблемы, прежде чем клиенты сообщат вам о них. Вы, вероятно, также хотите запускать сбор статистики, либо напрямую через munin или что-то еще, либо через SNMP для чего-то вроде Cacti.

Я обычно стараюсь, чтобы Cacti работал по крайней мере со всеми моими основными коммутаторами и межсетевыми экранами; где возможно, я запускаю Кактусы против всего, что могу. В этих случаях я обычно ищу такие вещи, как количество ошибок порта или чрезмерный трафик. Графики брандмауэра с некоторых устройств могут показать вам использование процессора и одновременных сеансов; вы узнаете, при каких порогах у вашего брандмауэра возникают проблемы.

Ваш брандмауэр может войти в систему на системном журнале; если это так, запишите все, что можете, и посмотрите на них подсказки. Это будет проще, если вы запустите что-то вроде syslog-ng или rsyslog или splunk, что позволит вам несколько разделить журналы, а не работать с одним монолитным файлом.

Я также пытаюсь запустить nfsen, по крайней мере, внутри моего брандмауэра и, по возможности, для связи с интернет-провайдером. Это позволяет вам вернуться в прошлое, чтобы посмотреть на сессии, чтобы увидеть, кто чем занимается; это иногда может поймать интересные поведения.

Вот несколько полезных инструментов для устранения задержек и других сетевых проблем:

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

Если вы используете беспроводную сеть, одним из частых замедлений являются помехи в каналах. Группа SSID в одной области может реально замедлить сетевой трафик. (Подумайте: демонстрация iPhone 4 на WWDC '10).

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

Чтобы уменьшить помехи, лучше всего быть на каналах 1, 6 или 11. Использование передачи 802.11n с частотой 5 ГГц также может помочь.

Я всегда начинаю с мониторинга материала 2 уровня с помощью Cacti . Это даст вам большое количество данных, которые вы можете использовать для поиска шаблонов, и вы сможете сравнить свои графики Cacti, когда все работает хорошо, и когда пользователи видят медлительность.

Вероятно, он не найдет точную проблему, но даст вам хорошее стартовое место, чтобы помочь сузить проблему.

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

Как только вы узнаете, в чем проблема, разверните свои модные инструменты и мониторы. Но не тратьте время на то, чтобы делать это на каждом слое. Это займет вечность.

Вам также необходимо знать свои серверы и среду рабочего стола / клиента, а не просто предполагать, что пользователь прав, когда говорит «сеть медленная». Вы должны методично устранять каждую проблему - как уже говорили другие, вы должны сначала иметь возможность просмотреть и идеально воспроизвести ошибку, а затем работать таким образом, который имеет смысл для сценария.

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

Ответы для tcpdump и wireshark не ошибочны, они могут быть жизненно важными частями вашего инструментария. Но если вы не уверены, что это на самом деле сеть, они не должны быть первыми, чего вы достигнете.

Медленная сеть - обычное явление. Низкая скорость сети может быть вызвана несколькими причинами. Устранение неполадок в медленной сети является одной из наиболее распространенных и хлопотных задач в повседневном управлении сетью.

Согласно анализу, основными причинами медленной сети являются:

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

Как мы можем быстро выяснить причину медленной сети? Рекомендуется захватывать и анализировать пакеты с помощью сетевого анализатора (Ax3soft Unicorn, wireshark и т. Д.).

Вы также прочитали статью «Найти причины для медленной сети», перейдя по ссылке ( http://www.ids-sax2.com//Unicorn/Tutorials/Find-Reasons-for-Slow-Network-with-Ax3soft-Unicorn .htm ) чтобы посетить это.