Мониторинг сети

[BRZ513]

Добрый день. Может кто-то посоветовать прогарамму/ы для мониторинга сети и доступа к сайтам? Смысл в чем, провайдер утверждает что у меня нет проблем, я вижу определённые сложности и мне кажется, что проблемы всё же есть. Выражается это в том, что я не могу стримить на ютюб. Поток постоянно лагет и у зрителей идет подгрузка. Причём в обратку тоже хреново. Даже не в ХД видео иногда долго подгружается, обрывается, подгружается. 

Мне посоветовали программу PingPlotter она показывает не самые радужные картинки... Но проваедер говорит, что я е**ан и у меня всё хорошо и рекомендует получше настроить мои программы для стрима.... 

Если есть администраторы сетей или просто люди грамотные подскажите софт или ещё что-то, как проверить качество подключения. 

(оператор дом.ру)

[Rizer]

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

Запускаешь на длительный период, потом отсылаешь им результат.

Обычно, на потери пакетов больше 1.5-2%, они нормально реагируют.

 

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

 

Посмотрел графики.

Потерь то нет, и пинг до ютуба хороший, вообщем проблема не в канале.

Изменено 16 января 2016 пользователем rizer

[mr_Yoda]

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

И не стоит забывать, что серверы ютуба или другие по пути, бывают перегружены

[Kaiten]

Чем не устраивают штатные пинг и трассировка?

 

Win+R

tracert 192.168.1.1

или

ping 192.168.1.1

где 192.168.1.1 - IP адрес пингуемого сайта (хотя можно и просто адрес ввести, но у некоторых порталов может оказаться несколько IP)

айпишник узнаётся там же в консоли командой nslookup

 

Если вместо адреса ввести параметр "-?" (без кавычек), то будет выведена подсказка по параметрам.

например: ping 192.168.1.1 -t -l 100 выполняет команду ping до прерывания (-t) пользователем и задаёт размер пакета в 100 байт (тут есть некоторый простор для экспериментов - возможно какой-то размер пакета в Ваших условиях будет шустрее "проскакивать" и тогда нужно будет внести соответствующие корректировки в стриммер)

 

вместо штатной можно пользовать расширенную консоль, например console2

 

[16GvIAP_Zalex]

Уточни, не через WiFi ли у тебя подключение к своему роутеру (если он есть?) либо у тебя кабель провайдера напрямую в комп воткнут?  Чей это ip 10.94.255.* - это роутер или шлюз провайдера ? Судя по твоим скринам - у тебя проблемы на первом хопе.  Если это роутер за 500 рублей, то не исключено что провайдер прав и сложности у тебя с железкой. Если это твой комп, то посмотри не погрыз ли кабель ребенок/кот/собак  Если это роутер таки и по шнурку подключен - проверь соединение между ним и твоим компьютером, а именно не передавил ли ты где то шнур. Всякое бывает.

[BRZ513]

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

Стандартные команды хороши, но они не особо показательны. На картинках видно красную зону, это и есть 100% потеря пакетов. Потом PL нивелируется ибо пакеты проходят. 

Роутер Асус, подключение "по земле".

Да и проблема не в пинге а качестве канала... Ибо за первым хопом вроде как все путем....

[2BAG_Miron]

На каком участке потери?

[BRZ513]

от компа (или роутера) до их первого узла... тупо где-то в подъезде ( 

[2BAG_Miron]

Тогда пингуй первый хоп и статистику провайдеру отправляй. Тут никаких программ не нужно особо.

Изменено 18 января 2016 пользователем 2BAG_Miron

[Rizer]

Потери на шлюзе, это частая ситуация.

И так как дальше потерь нет, это означает что шлюз так настроен, не принимает пинги и\или принимает их с низким приоритетом.

 

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

[DogEater]

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

Стандартные команды хороши, но они не особо показательны. На картинках видно красную зону, это и есть 100% потеря пакетов. Потом PL нивелируется ибо пакеты проходят. 

Роутер Асус, подключение "по земле".

Да и проблема не в пинге а качестве канала... Ибо за первым хопом вроде как все путем....

Попробуй ping -l 1500 <ip addr>

Обычно размер пакета для пинга равен  32 байта, и мелкие пакеты проскакивают без проблем.

При большом размере пакета потерь больше (как в том случае когда ты сёрфишь или качаешь), соответственно проблема видна чётче.

[2BAG_Miron]

 

 

И так как дальше потерь нет, это означает что шлюз так настроен, не принимает пинги и\или принимает их с низким приоритетом.

 

Вполне возможно. Запусти первый пинг на первый хоп с ключом -t и второй на ya.ru тоже с ключом. Если потери синхронные, то есть проблема. Если ya.ru будет без потерь, то просто настройка на шлюзе такая. У меня например провайдер вообще шлюз закрыл на ICMP.

[BRZ513]

Придумал как объяснить как эта проблема выглядит для меня. Соединение очень похоже на работу через спутник Т.е. если качаешь что-то большое, то проблем нет (и со скоростью тоже), а если куча маленьких запросов, то адски тупит. Т.е. иногда не грузит страничку, но если пару раз обновишь, то всё налаживается. 

[16GvIAP_Zalex]

Для меня очевидно механическое повреждение кабеля. Ну или плохо обжат на какой то из сторон. Возможно был плохо обжат и от времени "окислилось".

 

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

 

Посмотрите, нет ли у вас в доме другого провайдера - обычно это самый действенный способ. И обязательно напишите письмо в ТП, не по телефону.

[BRZ513]

Самое смешное, что такое уже было. После нудных переговоров и 1 нед времени, мне написали, что нашли проблему ии поменяли оборудование. Потом всё работало как надо... 

[DogEater]

Самое смешное, что такое уже было. После нудных переговоров и 1 нед времени, мне написали, что нашли проблему ии поменяли оборудование. Потом всё работало как надо... 

Мда, доказать "обезьяне", что ты не "верблюд" очень сложно.

[16GvIAP_Zalex]

Самое смешное, что такое уже было. После нудных переговоров и 1 нед времени, мне написали, что нашли проблему ии поменяли оборудование. Потом всё работало как надо... 

 

Кстати говоря, эксперимента для - зажмите свою сетевую на десятку и посмотрите, будут ли потери (а похоже проблема именно в потерях). Не исключено что потери "уйдут", тогда весьма с большой долей вероятности что проблема таки со шнурком от вас к ним.

[Utyug]

Не играл ли ты с "тюнингом" TCP/IP? Не менял ли MTU/MRU/TCPWindowSize?

 

Там, где рекомендуют погонять пакеты с ключиком -l размер_пакета попробуй задать еще ключ запрета фрагментации (-f), это покажет, насколько хорошо передаются относительно большие пакеты. Бывает так, что мелкие пакеты проходят вполне нормально, а с большими - проблемы. Обычно это говорит о некачественном кабеле или проблемах с сетевыми портами (на твоем или провайдерском устройстве).

 

Примерно так:

ping -t Твой_Шлюз -f -l 1400

и параллельно, в соседнем окошке:

ping -t Что-нибудь_у_провадера -f -l 1400

Пакеты размером 1400 байт должны хорошо проходить через Ethernet-соединение (точнее, 1472). Если же у тебя соединение другое, например PPoE, то размер пакета придется задавать поменьше. (можно подобрать экспериментально).

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

 

Далее. Одолжи у друга ноут. Попробуй потестировать с него (другое оборудование, другое ПО, исключаем/подтверждаем проблемы на твоем компе). Если ноута нет, можно скачать какой-нибудь Live-CD с поддержкой сети (да хоть DrWeb) и провести тестирование с него - т.о. можно исключить проблемы в твоем ПО.

 

Как-то так я бы попробовал.

Да! На время тестирования отключай всякое ПО, которое может влиять на результаты.

[BRZ513]

Кстати говоря, эксперимента для - зажмите свою сетевую на десятку и посмотрите, будут ли потери (а похоже проблема именно в потерях). Не исключено что потери "уйдут", тогда весьма с большой долей вероятности что проблема таки со шнурком от вас к ним.

 

 

Не играл ли ты с "тюнингом" TCP/IP? Не менял ли MTU/MRU/TCPWindowSize?

 

Там, где рекомендуют погонять пакеты с ключиком -l размер_пакета попробуй задать еще ключ запрета фрагментации (-f), это покажет, насколько хорошо передаются относительно большие пакеты. Бывает так, что мелкие пакеты проходят вполне нормально, а с большими - проблемы. Обычно это говорит о некачественном кабеле или проблемах с сетевыми портами (на твоем или провайдерском устройстве).

 

 

 

Примерно так:

ping -t Твой_Шлюз -f -l 1400

и параллельно, в соседнем окошке:

ping -t Что-нибудь_у_провадера -f -l 1400

Пакеты размером 1400 байт должны хорошо проходить через Ethernet-соединение (точнее, 1472). Если же у тебя соединение другое, например PPoE, то размер пакета придется задавать поменьше. (можно подобрать экспериментально).

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

 

Далее. Одолжи у друга ноут. Попробуй потестировать с него (другое оборудование, другое ПО, исключаем/подтверждаем проблемы на твоем компе). Если ноута нет, можно скачать какой-нибудь Live-CD с поддержкой сети (да хоть DrWeb) и провести тестирование с него - т.о. можно исключить проблемы в твоем ПО.

 

Как-то так я бы попробовал.

 

Да! На время тестирования отключай всякое ПО, которое может влиять на результаты.

 

 

Спасибо попробую. Что-то про понизить до 10ки не догадался.  Бука нет, а вот с телефона попробую.. 

Изменено 19 января 2016 пользователем BRZ513

[=13IAP=Ky3He4uK-]

Придумал как объяснить как эта проблема выглядит для меня. Соединение очень похоже на работу через спутник Т.е. если качаешь что-то большое, то проблем нет (и со скоростью тоже), а если куча маленьких запросов, то адски тупит. Т.е. иногда не грузит страничку, но если пару раз обновишь, то всё налаживается. 

 

 

Модельку Асуса напиши.

[Utyug]

Если доберешься до Live-CD учти операционную систему, на которой он построен. В Linux'е синтаксис команды ping иной. Например, вместо "-l 1400" может быть "-s 1400".

[BRZ513]

Если доберешься до Live-CD учти операционную систему, на которой он построен. В Linux'е синтаксис команды ping иной. Например, вместо "-l 1400" может быть "-s 1400".

ok, спасибо.

[72AGs_Augur]

Если потери до первого хопа 10.94.255.* не вставленный во время лан кабель, а именно потери на шлюзе прова, то ping 10.94.255.* -t и скидываешь этот пинг в тп. Так как пинг то проходит, то нет, блокировкой icmp пакетов это быть не могет. Тут или не правильная настройка шлюза (было у нас такое, долго доказывали что мы не верблюды) или повреждение кабеля, что менее вероятно учитывая нормальную скорость при скачивании. Как вариант,  поиграть с размером MTU (forum.oszone.net/thread-129550.html) и выставить рекомендуемую, попробовать netsh winsock reset. Но ИМХО для начала лучше понасиловать техподдержку.

Изменено 19 января 2016 пользователем 72AGs_Augur

[BRZ513]

Роутер  Asus Rt-N12