| ||
Понял, про роутер - я ж там приводил и логи при подключении напрямую к киевстару, тоже там потери есть. Про iperf погуглю, спс. А симптомы отвала как раз в том, что все отваливается одновременно, потом поднимается (начиная от щакачек и заканчивая ютубом).Сообщение от infinite
А вы не подскажете киевстаровский сервак ipref, чтобы на него проверять? Или можно любой в интернете найти и подойдет?
Во-первых - благодарю за отзывчивость и рекомендации 👍
И к сожалению, ваши слова подчеркивают единственную, на мой взгляд, печать и боль - и это: "если у клиента проблема - то это проблемы самого клиента" ((
УВЫ, но действительно, реалии таковы - что если сильно хочется оставаться, то нужно либо самому стать слегка сисадмином/пригласить друга, либо уходить к другому провайдеру... А то пробиться через их уровни защиты - это наверно как прохождение игры на сложном (сперва чат-бот, затем чел.-бот, затем повтори X-раз, и если повезет - дойдешь до босса)
На счет типа подключения конечного оборудования, - мне кажется им всегда есть что предъявить..., и если макнуться с Wi-Fi подключением - то так можно будет хотя бы остановиться на этапе LAN соединения. А то если сразу поменять все патч-корды, всё переобжать - то могут сказать "зачем рукожоп ты туда полез", "умные" ведь самые - они)))
(хотя с другой стороны, - зачем менять рабочий коннектор - не до конца понимаю... другое дело его протестировать, даже внутри LAN тем же iperf3 - было бы достаточным, а коннектор приходящий от провайдера - это "чужой", пусть сами меняют)
Да и ближе к проблеме - у человека, судя по описанию, проблема возникает раз в какое-то время. Сложно будет такое словить iperf'ом...
--
PS: да, все вспоминаю как я обращался... пройдя все круги тестирования с простукивания в поддержку - в полной мере моя проблема так и не была решена... а я уверен, что проблема где-то на стороне Kyivstar. У меня была проблема низкой скорости в направлении германии. После того, как Киевстар заявил, что у них всё лучше чем хорошо и проблема не уних - я прислал отчет на следующий узел, который оказался центральной магистралью, где мне, ЗАМЕТЬТЕ, довольно быстро, и детально сообщили, что на их и последующих узлах - скорость не режется и что, они на столько "озабочены" своим оборудованием, что с ним проблем просто не может быть )))
Не видел. Логи чего именно при подключении напрямую? Iperf - есть несколько публичных серверов, но все-таки это больше диагностический инструмент, чем скоростемерялка. Но это про скорость между узлами, не про потери/просадки. Сделайте как я предлагаю, глядишь и решится проблема. В худшем случае будете знать что дело ТОЧНО не в вашей домашней сети.
Наблюдатель эффекта.
Не за что, как говорится "мав час та натхнэння".Во-первых - благодарю за отзывчивость и рекомендации ��
И к сожалению, ваши слова подчеркивают единственную, на мой взгляд, печать и боль - и это: "если у клиента проблема - то это проблемы самого клиента" ((
УВЫ, но действительно, реалии таковы - что если сильно хочется оставаться, то нужно либо самому стать слегка сисадмином/пригласить друга, либо уходить к другому провайдеру... А то пробиться через их уровни защиты - это наверно как прохождение игры на сложном (сперва чат-бот, затем чел.-бот, затем повтори X-раз, и если повезет - дойдешь до босса
На счет типа подключения конечного оборудования, - мне кажется им всегда есть что предъявить..., и если макнуться с Wi-Fi подключением - то так можно будет хотя бы остановиться на этапе LAN соединения. А то если сразу поменять все патч-корды, всё переобжать - то могут сказать "зачем рукожоп ты туда полез", "умные" ведь самые - они)))
(хотя с другой стороны, - зачем менять рабочий коннектор - не до конца понимаю... другое дело его протестировать, даже внутри LAN тем же iperf3 - было бы достаточным, а коннектор приходящий от провайдера - это "чужой", пусть сами меняют
Да и ближе к проблеме - у человека, судя по описанию, проблема возникает раз в какое-то время. Сложно будет такое словить iperf'ом...
--
PS: да, все вспоминаю как я обращался... пройдя все круги тестирования с простукивания в поддержку - в полной мере моя проблема так и не была решена... а я уверен, что проблема где-то на стороне Kyivstar. У меня была проблема низкой скорости в направлении германии. После того, как Киевстар заявил, что у них всё лучше чем хорошо и проблема не уних - я прислал отчет на следующий узел, который оказался центральной магистралью, где мне, ЗАМЕТЬТЕ, довольно быстро, и детально сообщили, что на их и последующих узлах - скорость не режется и что, они на столько "озабочены" своим оборудованием, что с ним проблем просто не может быть )))
Не соглашусь, вернее не совсем соглашусь - потеря абонента это проблема оператора. Просто вы выбрали (очевидно были на то причины) такого оператора, для которого это не такая уж и проблема
Почти всегда есть что предъявить, кроме как в случае если абонент обладает знаниями и квалификацией, которые позволят провести полноценную диагностику самостоятельно. А это бывает довольно редко, если вы, к примеру, бухгалтер, то зачем вам разбираться в сетях?
Пачт-корд поменять от розетки к роутеру и от роутера к телику или компьютеру - зачем коннектор срезать? Кстати часто помогает и просто "переткнуть" кабель, оно ж заламывается, окисляется, отходит в конце концов если зацепить случайно.
"Раз в какое-то время" и прямо все-все тормозит - конечно больше похоже на проблемы в домашней сети (роутер, кабели, загрузки чего-то в домашней сети).
Ну, так устроены большие операторы - многоуровневая техподдержка. Вернее даже не так - сначала оператор контакт-центра, потом техсап первого уровня, потом второго, потом младший инженер, потом... Ну, вы поняли?
"Проблема на стороне Киевстар": повторюсь - Киевстар большой и богатый. Магистральная сеть и оборудование у них очень крутые, и "труба" с ооочень большим запасом. Я конечно в и NOC не бывал, но сильно сомневаюсь что там может быть проблема.
Но всякое бывает, особенно сейчас, очень много магистральных кабелей повреждено в окрестностях Киева.
Наблюдатель эффекта.
Мтр там 3 лога, 2 из них были напрямую. ipref пока показывает хорошую скорость даже через сеть, анализирую еще, если найду просадки, то буду напрямую проверять, опубликую потом логи, если увижу падение скорости.
Это не логи
По таблицам, которые вы показали, видно что максимальные задержки доходят до 7 секунд (это прямо сильно много) на хосте 134-249-99-253. Предполагаю что это ваш адрес шлюза на WAN-порту, т.е. тот адрес, который Киевстар вам выдал. Если да, а на порту коммутатора, в который вы подключены, нет ошибок - то 100% проблема у вас. Чаще всего так бывает в моменты когда вы "выедаете" всю полосу.
Еще вижу потери 7-8% при использовании роутера, и отсутствие таких потерь при подключении нотика напрямую.
PS Еще вижу что вы пакетами по 1500 байт MTR делаете, напоминаю что ICMP это диагностический протокол, а нормальный размер его пакета 64 байта. Может просто футболить как что-то подозрительное.
Последний раз редактировалось infinite; 12.04.2022 в 10:54.
Наблюдатель эффекта.
Странно, видимо я неправильно понял мануал
вот такой командой делал:Код:В столбце Snt — количество отправленных пакетов. -c COUNT, --report-cycles COUNT Use this option to set the number of pings sent to determine both the machines on the network and the reliability of those machines. Each cycle lasts one second.
Код:for i in {1..10}; do mtr -rwc 1500 kyivstar.ua >> ./kyivstar_log/$(date +%Y%m%d%H%m%S)mtr200_log.txt; done
Последний раз редактировалось Youri_od; 12.04.2022 в 14:38. Причина: решил показать код из терминаторва
Не думаю что вам именно MTR чем-то поможет в поисках где же собака порылась, но и не помешает. Есть WinMTR такой, там не командная строка, а вполне себе удобный интерфейс. Мониторьте ресурсы системы и трафик в момент лагов. Ну и все-таки советую сделать то, с чего я начал - исключите самое простое и очевидное - коммутацию и железки.
Наблюдатель эффекта.
Значит заметил странность, что на 5000 ipref не выдерживает и напрямую и через роутер приложу файлы
Код:iperf3 -c iperf.volia.net -t 5000 >> ./kyivstar_log/$(date +%Y%m%d%H%m%S)ipref3__directconnect_log.txt20220412100417ipref3_log.txt.zipКод:iperf3 -c iperf.volia.net -t 6000 >> ./kyivstar_log/$(date +%Y%m%d%H%m%S)ipref3_log.txt
20220412200438ipref3__directconnect_log.txt.zip
вот что выдало в обоих случачях в терминаторе при не окончании задачи:
Код:iperf3: error - unable to receive control message: Connection timed out
Последний раз редактировалось Youri_od; 12.04.2022 в 21:37. Причина: дополнил откликом в терминале
В общем обновил прошивку на роутере, стал смотреть логи, вот что выдает с периодичностью в в несколько часов:
Код:Tue Apr 19 22:58:20 2022 kern.info kernel: [254330.229564] mt7530 mdio-bus:1f wan: Link is Down Tue Apr 19 22:58:20 2022 daemon.notice netifd: Network device 'wan' link is down Tue Apr 19 22:58:20 2022 daemon.notice netifd: Interface 'wan' has link connectivity loss Tue Apr 19 22:58:34 2022 kern.info kernel: [254344.565613] mt7530 mdio-bus:1f wan: Link is Up - 100Mbps/Full - flow control off Tue Apr 19 22:58:34 2022 daemon.notice netifd: Network device 'wan' link is up Tue Apr 19 22:58:34 2022 daemon.notice netifd: Interface 'wan' has link connectivity
Выглядит, будто на 14 секунд пропадал аплинк. С кабелем и девайсом на другом его конце всё ок? Если девайс провайдерский - думаю, эти логи им также помогут
В том то и проблема, что девайс свой, роутер strong 1200 под openwrt 21.02 (проблему заметил на 19.07, решил обновиться), не могу понять роутеру гайки или проблема у киевстара. Похоже придется роутер еще покупать.
С начала подключите на прямую кабель. У меня падал аплинк, когда гайки пришли свитчу провайдера на крыше.
Судя по тому, чтоТо проблемы 90% у провайдерского оборудования. Полагаю, что вменяемый админ провайдера располагая столь детальными клиентскими логами сможет локализовать проблему. Если же у провайдера такого админа нет или к нему не прорваться через заскриптованный саппорт - может ну его, этого провайдера?
- логи роутер писал - питание на него приходило, ос и демоны работали
- даунтайм аплинка всего 14 сек (большинство роутеров не умеют так быстро ребутаться)
- аплинк успешно поднялся - проблем с портом абон.роутера скорее всего нет
Последний раз редактировалось phobos_nik; 20.04.2022 в 14:07. Причина: очепятка
если в роутере на интерфейсе wan не ставить опцию force link, то ребут длится чуть дольше:
мне бы еще понять куда бы тикет с логами оставить, а то там звонишь, говорят - есть интернет? а ну если есть, то все ок.Код:Wed Apr 20 12:45:43 2022 daemon.notice netifd: Network device 'wan' link is down Wed Apr 20 12:45:43 2022 daemon.notice netifd: Interface 'wan' has link connectivity loss Wed Apr 20 12:45:43 2022 kern.info kernel: [ 2575.547492] mt7530 mdio-bus:1f wan: Link is Down Wed Apr 20 12:45:43 2022 daemon.notice netifd: wan (3572): udhcpc: received SIGTERM Wed Apr 20 12:45:43 2022 daemon.notice netifd: wan (3572): udhcpc: unicasting a release of 100.68.27.106 to 193.41.60.7 Wed Apr 20 12:45:43 2022 daemon.notice netifd: wan (3572): udhcpc: sending release Wed Apr 20 12:45:43 2022 daemon.notice netifd: wan (3572): udhcpc: entering released state Wed Apr 20 12:45:43 2022 daemon.notice netifd: wan (3572): Command failed: Permission denied Wed Apr 20 12:45:43 2022 daemon.notice netifd: Interface 'wan' is now down Wed Apr 20 12:45:43 2022 daemon.info avahi-daemon[2009]: Withdrawing address record for 100.68.27.106 on wan. Wed Apr 20 12:45:43 2022 daemon.info avahi-daemon[2009]: Leaving mDNS multicast group on interface wan.IPv4 with address 100.68.27.106. Wed Apr 20 12:45:43 2022 daemon.info avahi-daemon[2009]: Interface wan.IPv4 no longer relevant for mDNS. Wed Apr 20 12:45:43 2022 daemon.info avahi-daemon[2009]: Interface wan.IPv6 no longer relevant for mDNS. Wed Apr 20 12:45:43 2022 daemon.info avahi-daemon[2009]: Leaving mDNS multicast group on interface wan.IPv6 with address fe80::8e6d:50ff:fe91:9245. Wed Apr 20 12:45:43 2022 daemon.info avahi-daemon[2009]: Withdrawing address record for fe80::8e6d:50ff:fe91:9245 on wan. Wed Apr 20 12:45:43 2022 daemon.notice netifd: Interface 'wan' is disabled Wed Apr 20 12:45:43 2022 kern.info kernel: [ 2575.682279] mt7530 mdio-bus:1f wan: configuring for phy/gmii link mode Wed Apr 20 12:45:43 2022 kern.info kernel: [ 2575.696739] 8021q: adding VLAN 0 to HW filter on device wan Wed Apr 20 12:45:43 2022 daemon.notice netifd: Interface 'wan' is enabled Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: reading /tmp/resolv.conf.d/resolv.conf.auto Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain test Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain onion Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain localhost Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain local Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain invalid Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain bind Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain lan Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: using nameserver 8.8.8.8#53 Wed Apr 20 12:45:43 2022 daemon.info dnsmasq[3239]: using nameserver 8.8.4.4#53 Wed Apr 20 12:45:57 2022 kern.info kernel: [ 2590.043410] mt7530 mdio-bus:1f wan: Link is Up - 100Mbps/Full - flow control off Wed Apr 20 12:45:57 2022 kern.info kernel: [ 2590.058255] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready Wed Apr 20 12:45:57 2022 daemon.notice netifd: Network device 'wan' link is up Wed Apr 20 12:45:57 2022 daemon.notice netifd: Interface 'wan' has link connectivity Wed Apr 20 12:45:57 2022 daemon.notice netifd: Interface 'wan' is setting up now Wed Apr 20 12:45:58 2022 daemon.notice netifd: wan (3925): udhcpc: started, v1.33.2 Wed Apr 20 12:45:58 2022 daemon.notice netifd: wan (3925): udhcpc: sending discover Wed Apr 20 12:45:59 2022 daemon.notice netifd: wan (3925): udhcpc: sending select for 100.68.27.106 Wed Apr 20 12:45:59 2022 daemon.notice netifd: wan (3925): udhcpc: lease of 100.68.27.106 obtained, lease time 19969 Wed Apr 20 12:45:59 2022 daemon.info avahi-daemon[2009]: Joining mDNS multicast group on interface wan.IPv4 with address 100.68.27.106. Wed Apr 20 12:45:59 2022 daemon.info avahi-daemon[2009]: New relevant interface wan.IPv4 for mDNS. Wed Apr 20 12:45:59 2022 daemon.info avahi-daemon[2009]: Registering new address record for 100.68.27.106 on wan.IPv4. Wed Apr 20 12:45:59 2022 daemon.notice netifd: Interface 'wan' is now up Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: reading /tmp/resolv.conf.d/resolv.conf.auto Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain test Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain onion Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain localhost Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain local Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain invalid Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain bind Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using only locally-known addresses for domain lan Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using nameserver 8.8.8.8#53 Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using nameserver 8.8.4.4#53 Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using nameserver 193.41.60.2#53 Wed Apr 20 12:45:59 2022 daemon.info dnsmasq[3239]: using nameserver 193.41.60.1#53 Wed Apr 20 12:45:59 2022 daemon.info avahi-daemon[2009]: Joining mDNS multicast group on interface wan.IPv6 with address fe80::8e6d:50ff:fe91:9245. Wed Apr 20 12:45:59 2022 daemon.info avahi-daemon[2009]: New relevant interface wan.IPv6 for mDNS. Wed Apr 20 12:45:59 2022 daemon.info avahi-daemon[2009]: Registering new address record for fe80::8e6d:50ff:fe91:9245 on wan.*. Wed Apr 20 12:45:59 2022 user.notice firewall: Reloading firewall due to ifup of wan (wan)
Тех. сап. КС это отдельная история, тикет с логами роутера они не принимают под любым соусом. Только подключение на прямую в комп. или ноутбук.
В момент залипания интернета, комп должен показать сетевой кабель не подключен, в этот момент звоните 460, если интернет появится раньше чем дозвонились человеку на 460 можете завершать дозвон до следующего залипа. Я так 1 неделю вызванивал 460, пока они не выловили проблему со свитчем.
Последний раз редактировалось Черный_Рыцарь; 20.04.2022 в 23:57.
Это не про админов КС.
в общем я вчера психанул, посидел напрямую, разрывов не было, пошел купил роутер ксяоми разрывов нету, поставил назад этот прошитый под openwrt strong 1200 - о пять разрывов нету.... ничего не понятно, но очень интересно. До этого я тоже перетыкивал wan кабель от киевстара в стронга, но все равно были разрывы эти.... у меня такое ощущение, что что-то поменялось и совпало, но уже оставлю запасной роутер, а то не всегда удобно сидеть впритык к входу кабеля.
Upd: Похоже сглазил я киевстар, на ксяоми новом роутере тоже обрыв, сидел по ssh и оборвалась сессия... Печально это, доказать сложно, а пользоваться неприятно... Может придется на тенет переходить, я там такого не замечал, помнится неделю в консоли ssh сидишь и не обрывается.
Последний раз редактировалось Youri_od; 22.04.2022 в 12:04. Причина: обновилась информация.
Это да. Киевстар таким страдает намного больше, чем Бриз или Тенет. Поэтому лучший из вариантов(если провайдера поменять нельзя по каким то причинам) - удаленна дев. машина, а на ней что то вроде tmux. Хотя это дороже, конечно.
Ваши права
Тема: 
Ответить с цитированием
Социальные закладки