[Impulse2013]

Добрый день уважаемые форумчане.

 

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

 

Итак, многим из Вас если Вы работаете в Провайдере, Операторе или просто в крупной компании переодически поступают "жалобы" на скорость от пользователей. Топология сети часто вносит коррективы какие инструменты диагностики может использовать сетевой инженер. Не всегда одни решения применимые к одной технологии могут быть использованы для диагностики с использованием другой технологии, но всегда есть определенный "боевой" набор инструментов помогающий в рутинной работе инженера по борьбе с "медленными страничками" и "мэил вообще не открывается"

 

Например я в своей работе использую следующие инструменты

 

- Cacti для общего мониторинга транспорта и в некоторых случаях мониторинга клиентских интерфейсов

- MRTG который тянет с netflow статистику по IP адресам абонентов.

- iftop - для проверки текущего состояния обмена трафиком (в моём случае маршрутизация идёт через сервер на линуксе, поэтому данный инструмент применим)

- iptraf - также для оценки объёма трафика абонента на текущий момент времени

- tcpdump - для оценки типа трафика абонента etc

- Встроенные средства свитчей и дсламов для оценки параметров интерфейса.

- ping&tracert

 

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

[saaremaa]

Инструменты:

- Zabbix куда занесены все базовые станции, коммутаторы ядра, магистрали и доступа , сервера и пр. Мониторинг загрузки всего что только можно получить от устройства по snmp, xml-rpc, icmp, внешние контроллеры (температура, наличие напряжения, влажность, протечка) Места на жестком диске это занимает немеряно, но очень хорошо видно что как происходило.

- tcpdump используем только для проверки долетают ли пакеты DNS, Netflow и биллинга.

- ping&tracert

- Mikrotik/Torch - если надо посмотреть что валится от абонента

- Mikrotik/Mac-telnet для хождения на mikrotik.

- Wireshark для выездов на доступ.

- ssh - для хождения на коммутаторы, роутеры и пр

[Saab95]

Я обычно вот что использую:

[secandr]

Выходит монтёр на линию и меряет iperf`ом. В 99% случаев касяк на участке от ПК абонента до коммутатора, включая порт. Меняет порт, кабелиь или показывает клиенту, что у него всё ништяк и пора менять ПК\роутер.

 

На аплинки всех коммутаторов стоят watchdog на 80% загрузку.

На аплинках в интернет скрипты анализируют полосу и если она "резко" упала дают алярм.

 

Ну и всё что можно мониторит zabbix, он же рисует графики для посмертного разбора.

[AKim]

Приходим к абоненту с ноутбуком.

 

Сначало проверяем скорость сюда http://speedtest.megafonkavkaz.ru/ с его оборудования. Если скорость в переделах нормы, разворачиваемся и уходим. Как правила на компе у абонента куча всяких гвардов и всякого "ускоряющего" ПО.

 

Графики на абон портах не рисуем, оно нам не надо. Сеть не большая, чуть больше 1000 человек.

 

Если скорость правда низкая, то проверяем на нешем ноутбуке

 

тест локальной сети

тест btest (микротик)

пинги

трасировка

 

 

в итоге:

ребут свича

смена порта

перетяжка кабеля

[megahertz0]

А как кто борется с любителями спидтеста?

У нас одна из подсетей определяется спидтестом где-то на дальнем востоке. Соответственно часть абонов меряет скорость как и положено на локальном спидтесте, о часть - хз на каком дальневосточном со всеми вытекающими последствиями. С поддержкой спидтеста связывался, скидывал им данные из RIPE DB и т.д. На что они ответили, что сами получают данные geoip у какой-то сторонней конторы и ничего поделать не могут. Абоны же как обычно про iperf и прочие достоверные средства измерения слышать не хотят ))).

[Impulse2013]

Спасибо за ответы!)

 

От себя поделюсь процедурами:

Обычно да всё так же - выезжаем к клиентам с ноутбуком, показываем скорость с нескольких ресурсов: локальных(вунтресетевых), внешних (где-то в мире) ну разбавляем разными спидтестами.

 

Где то тут на форуме товарищ выкладывал методику тестирования транспортных линков для принятия в эксплуатацию. Это применимо в случае когда своего транспорта нет, а клиентский узел идёт по транспорту стороннего провайдера.

Создается тестовая нагрузка путем флудинга пингом

Команда для линукса

ping -s 65000 -l 1 -f <ipaddr>

Так же на циске можно сделать подобную тестовую нагрузку.

Ну и совместить данный тест последущей проверкой на месте iperf'ом, ну или jperf'ом.

[alibek]

ping -s 65000 -l 1 -f <ipaddr>

Я правильно понял, что предлагается пинговать нефрагментированными пакетами 64КБ?

Они где-то через порт доступа пролезают?

Как по мне, так правильнее размер пакета использовать 1420 или 1460.

[dIMbI4]

Ну у меня алгоритм такой.

Техсапорт просит подключить комп без роутера кабелем напрямую

Спидтест

Если мало- запускаем тимвьювер- инсталяшка на главной страничке пересобраная есть

Спидтест оператором сапорта

Если все-таки точно мало, запускаем пинг -l 65500 на наш веб сервер. Делаем трассировку.

Если дропы- оформляем заявку на ремонт. Можно еще зайти посмотреть ошибки на порту, но долго и для сапорта бессмысленно а ситуация очевидна

Приходит ремонтник, цепляется своим нетбуком. Спидтест. Пинг.

Переобжимка со стороны клиента.

Идет к свичу, втыкается в порт клиента. Спидтест. Пинг.

Переобимка у свича.

Если не гут, меняется порт

Если не гут, перетягивается кабель или ищется коцка/скрутка. .

Если не гут, передается заявка админам. Они мониторят свич, разруливают. Если надо сварщики с рефом глядят волокно.

Профит.

Перегрузы все естественно отрабатываются админами и на нашей сети по факту с таким не сталкивались.

Обычно все останавливается на подключении компа напрямую.

Общение с юрлицами обычно сразу переводится админам, быстрее и меньше простой. Админ смотрит мак на порту, состояние порта. Ну дальше сам разбирается, если надо передает заявку ремонтникам.

[sheft]

На что они ответили, что сами получают данные geoip у какой-то сторонней конторы и ничего поделать не могут

немцы, адрес даже не помню, но была форма для заполнения, делал себе уточнение, спустя пару недель на спидтесте начали отображаться актуальные координаты

вспомнил.. тут - http://www.maxmind.com/en/correction

Изменено 28 декабря, 2013 пользователем sheft

[darkagent]

Я правильно понял, что предлагается пинговать нефрагментированными пакетами 64КБ?

неправильно. это так называемый fastping, когда утилита шлет следующий запрос недожидаясь ответа на предыдущий. на деле там пакеты так же фрагментируются и укладываются в стандартное мту, но при этом сама нагрузка по полосе значительно увеличивается. до появления iperf в массах, fastping вполне годился для выжимания полосы на скорости порта.

 

Я обычно вот что использую:

вся суть микротик в одной картинке :D

[alibek]

неправильно

Действительно, не обратил внимания, что речь про Linux.

[pppoetest]

С поддержкой спидтеста связывался, скидывал им данные из RIPE DB и т.д. На что они ответили, что сами получают данные geoip у какой-то сторонней конторы и ничего поделать не могут.

Сам столкнулся, обратитесь сюда: http://www.maxmind.com/en/correction. Эффект не моментальный, у мну ушло 3 недели. Некоторые крупные сервисы типа яндекса и прочих, вообще похожу забили на это дело, щяс воюю с ними.

 

А, уже ответили, не увидел сразу :)