У всех нас были жалобы на то, что «сеть» в какой-то момент «медленная»: может быть локализована для одной комнаты (коммутатора) или одного компьютера, может быть просто Интернет (DNS? Проблема с браузером?), Может быть только одно приложение (длинные SQL-запросы? AV-сканирование запущено?).
Когда вы исключили очевидные проблемы с системой и / или приложением, как вы проводите тестирование сети на медленность или неустойчивое поведение? Вы продвигаетесь вверх по уровням OSI? Если да, то как проверить каждый слой? Что вы делаете, чтобы убедиться, что физическая сеть работает в неизвестной среде? А как насчет слишком большого количества трансляций или широковещательного шторма? Уровень 3 и выше? traceroute? Какие-нибудь другие советы, методы, идеи? Необходимые функции и инструменты (зеркалирование портов, SNMP, мониторинг и т. Д.) Для сетей любого размера?
tcpdump и wirehark - ваши друзья.
Я обнаружил, что наблюдение за пакетами по проводу «медленной» сети по сравнению с «хорошей» сетью обычно указывает на проблему.
Есть много типов «медленных».
Вы можете отслеживать задержку на локальных и интернет-сайтах с помощью такого инструмента, как SmokePing. (SmokePing можно настроить для отслеживания задержки ICMP, а также задержки службы от служб TCP)
Коммутаторы должны отслеживать широковещательные пакеты по сравнению с одноадресными. Изобразите это соотношение.
Мне также нравится отслеживать трассировку (проверка доменных имен ISP переходов между «важными» сайтами).
Надеюсь, эти комментарии помогут.
Трудно дать конкретные ответы, поскольку 90% этой работы - это опыт, который учит, где искать и какую проблему, а остальные 90% знают, где искать в Google, чтобы получить подсказки, с чего начать.
Я обычно пробую использовать бумажные пакеты, например, заставить клиента продемонстрировать проблему (в основном, чтобы исключить проблемы с пальцами и любые проблемы, которые могут возникнуть у покупателя при описании его проблемы), а затем пытаюсь скопировать проблему на другом компьютере. Это часто дает вам представление о том, где искать.
Не забывайте корректирующую проблему перезагрузки, особенно для систем Windows, даже сегодня. Раньше это было так часто, что я спрашивал людей: «Вы перезагружались? Что ж, попробуйте это и дайте мне знать, если проблема не исчезнет» - это решило очень большой процент проблем, о которых меня спрашивали.
Также часто возникают проблемы с разрешением DNS и базовыми подключениями (списки управления доступом на маршрутизаторах, воздушные зазоры в сети, ping / traceroutes / mtrs на удаленные сайты и т. Д.).
Для сервисов, над которыми вы имеете прямой контроль, запуск nagios или что-то еще, чтобы гарантировать, что сервис действительно работает, часто может побудить вас исправить проблемы до того, как клиенты сообщат вам о них. Вероятно, вы также захотите запустить сбор статистики либо напрямую через munin или что-то еще, либо через SNMP для чего-то вроде Cacti.
Обычно я стараюсь запустить Cacti, по крайней мере, против всех моих основных коммутаторов и брандмауэров; где возможно, я использую Cacti против всего, что могу. В этих случаях я обычно ищу такие вещи, как количество ошибок порта или чрезмерный трафик. Графики брандмауэра с некоторых устройств могут показывать использование ЦП и количество одновременных сеансов; вы узнаете, при каких порогах у вашего брандмауэра возникают проблемы.
Ваш брандмауэр может иметь возможность регистрироваться на устройстве системного журнала; Если да, запишите все, что сможете, и просмотрите их на предмет подсказок. Это будет проще, если вы запустите что-то вроде syslog-ng, rsyslog или splunk, которое позволит вам несколько разделить журналы, а не работать с одним монолитным файлом.
Я также пытаюсь запустить nfsen, по крайней мере, внутри моего брандмауэра и, где возможно, восходящей линии связи с интернет-провайдером. Это позволяет вам вернуться во времени и посмотреть на сеансы, чтобы увидеть, кто что делал; иногда это может уловить интересное поведение.
Вот несколько полезных инструментов для устранения задержек и других проблем с сетью:
Если вы используете беспроводную сеть, одним из частых сбоев является помехи в канале. Связка SSID в одной области действительно может замедлить сетевой трафик. (Подумайте: демонстрация iPhone 4 на WWDC '10).
Устранить эту проблему довольно просто, если использовать программное обеспечение, которое может показать вам модели беспроводного трафика в этом районе. Есть хороший бесплатный веб-сайт по адресу: http://meraki.com/tools/stumbler. (раскрытие: я работаю в Meraki)
Чтобы уменьшить помехи, лучше всего работать на каналах 1, 6 или 11. Использование оборудования 802.11n с частотой 5 ГГц также может помочь.
Я всегда начинаю с мониторинга уровня 2, используя Кактусы. Это даст вам хороший объем данных, которые вы можете использовать для поиска закономерностей, и вы сможете сравнить свои графики Cacti, когда все работает хорошо, и когда пользователи видят медлительность.
Вероятно, это не поможет найти точную проблему, но даст вам хорошую отправную точку, чтобы помочь сузить проблему.
Я начинаю с самого внешнего маршрутизатора и постепенно опускаюсь вниз и измеряю производительность самым примитивным способом: использую сайт тестирования пропускной способности или известный внешний FTP-сайт, который даст вам скорость загрузки / выгрузки, и продолжаю снижаться, пока вы найдите уровень, на котором находится проблема.
Как только вы узнаете, в чем проблема, разверните свои модные инструменты и мониторы. Но не тратьте время на то, чтобы делать то же самое на каждом слое. Это займет вечность.
Вам также необходимо знать свои серверы и среду рабочего стола / клиента, а не просто предполагать, что пользователь прав, когда он говорит, что «сеть работает медленно». Вам необходимо методично устранять каждую проблему - как говорили другие, вы должны сначала иметь возможность просмотреть и идеально воспроизвести ошибку, а затем работать оттуда таким образом, чтобы это имело смысл для сценария.
Однако хорошее управление и мониторинг в сети и на серверах могут сэкономить вам много времени, потому что вы не пытаетесь придумывать инструменты на лету, хотя, возможно, также пытаясь смягчить или исправить симптомы, и иметь дело с жалобами пользователей / клиентов.
Ответы на tcpdump и wirehark не ошибочны, они могут быть жизненно важными частями вашего набора инструментов. Но если вы не уверены, что это на самом деле сеть, они не должны быть вашим первым делом.
Медленная сеть - обычное явление. Низкая скорость сети может быть вызвана рядом причин. Устранение неполадок в медленной сети - одна из самых распространенных и трудоемких задач в повседневном управлении сетью.
Согласно анализу, основными причинами медленной сети являются:
Loopback
Broadcast/Multicast storm
Virus attack
Server slow response
Too many clients
Application slow response
Error client mask
Как мы можем быстро выяснить причину медленной работы сети? Хорошая идея - захватывать и анализировать пакеты с помощью сетевого анализатора (Ax3soft Unicorn, wirehark и т. Д.).
Вы также читали статью «Найдите причины медленной сети», щелкнув URL-адрес (http://www.ids-sax2.com//Unicorn/Tutorials/Find-Reasons-for-Slow-Network-with-Ax3soft-Unicorn.htm) посетить его.