Как вычислить виновника из-за которого отваливается интернет с какой-то периодичностью в маленькой сети?
Всем привет, есть небольшая сеть в здании. Следующая структура: оптика заходит в Eltex mes2428, от него уже в гигабитный роутер, от роутера витая пара идет на коммутатор TP-link из коммутатора уже подключаются кабинеты через монтажную планку, от монтажной планки провод идет в кабинет в ethernet розетку. Как итог пропадает интернет с какой-то периодичностью, провайдер заявляет что сигнал стабильный от них. Как вычислить из-за чего пропадает интернет, кто является виновником?
Простой 9 комментариев
Sand, есть подключение к интернету, потом в момент становится «без доступа», через время опять появляется доступ
MrFlatman, вы сделали вывод о «неработает интернет» на основании индикатора состояния подключения интернета на отдельно взятом компе с windows?
Sand, такая ситуация повсеместно на всех ПК, которые участвуют в сети, такая же ситуация и с ПК, который подключен непосредственно к основному роутеру
Sand, ну и также пропадает ping, если пинговать то мало того скачет как сумасшедший с 30 до 1300 и как пропадает пинг пишет «Превышен интервал ожидания для запроса»
MrFlatman, самое простое — идите смотрите светодиоды на сетевом оборудовании. Если какой-то светодиод моргает сильно чаще других — ну попробуйте выдернуть провод, а вдруг поможет. Можно подключиться к роутеру и посмотреть трафик на его интерфейсах. Или по SNMP
Сейчас стоит tenda ac1200, до этого был tp-link wr840, tp-link c54, и на всех такая же ситуация. На данный момент подключено 6 устройств и ситуация не поменялась. Если напрямую к роутеру подключиться, то проблема остается, если он у всех начинает пропадать то и на входящем роутере тоже пропадает
MrFlatman, что тенда что тплинк надежностью похвастаться не могут. но по кабелю обычно нормально работают.
тут скорее всего проблема в провайдере, надо бы напрямую в ПК проверить конечно.
Такого рода проблемы все и всегда решаются однотипно.
1. Необходимо сформулировать критерии наличия проблемы.
Как именно пропадает интернет, насколько часто, как надолго. Это нужно для диагностики. поиска причины и определения ушла ли проблема после принятия каких либо мер.
2. Делить проблему на части и проверять части по отдельности.
Самый эффективный способ делить — это пополам. Отсекаем часть сети и проверяем наличие проблемы в обеих частях (если есть возможность) или в одной из частей.
3. Когда найден минимальный проблемный участок, который уже нельзя или бессмысленно делить — заменяем его.
4. Помним, что чаще всего сложные проблемы — это композиция нескольких более простых. которые по отдельности могут не проявляться. В вашем случае может быть проблема, связанная с нагрузкой на роутер, например, которую создает один из услов из-за плохого контакта обжима и большого объёма биттых пакетов. Устранив одну из причин, вы, может быть, сделаете проявления проблемы реже, но не устраните её полностью. К примеру, если замените ротуер, битые пакеты будут всё равно будут нагружать вашу сеть и портить ее производительность, но это будет не так очевидно. Переобжав коннектор вы избавитесь от части нагрузки, но еслив ваш ротуер работал на переделе, то лишний вафай-клиент или тяжелый видос в сети сможет его снова нагрузить до критического снижения производительности.
Итак, пробежимся по перечисленным пунктам сначала.
1. Критерии. Поиск критериев — это часть решения. Обычно в этом случае нуно сорать необходимую статистику. Есть куча софта, который это умеет делать, но пинг есть всегда под рукой.
Для этой тулзы есть две полезных опции: ключ для бесконечного пинга и размер пакета.
В разных ОС эти ключи немного разные, поэтому ищите их отдельно, у меня нет винды под рукой, поэтому не стану на этом заострять.
Скаж лишь, что пинговать лучше большими пакетами, жалетально превышающими размер TTL, прописанный в роутере. Тогда такой пинг будет реже проскакивать в периоды хорошей связи, то есть выловит больше пролблем.
Пинговать нужно в отдельных окнах сразу несколько хостов:
— ya.ru — этот хост всегда отвечает на пинги и выявит проблемы с DNS
— 8.8.8.8 — это гугловый DNS-сервер, тоже всегда отвечает на пинги, покажет, что связь с инетом есть даже если DNS, прописанныйна компе не правильно работает.
— 192.168.0.1 — или какой там IP у вашего роутера. Нужно. чтбы отделить проблемы с инетом от проблем с внутренней связностью до роутера
— 192.168.0.x — ip одного из компов в сети. Я обычно пингую несколько компов, доступных через баксимальное число потенциально проблемных узлов — ethernet-розеток, свичей, вайфай-соединений. Этот пинг поможет понять где проблема, во внутрисетевой связности или в последней миле.
Учтите, что проблемы часто бывают комбинированные и каждое сочетание симптомов будет свидетельствовать о раных проблемах.
Да, тревожным принаком может служить не только пропадание пакетов, но и скачки в длительности их возврата, особенно если такие длительности достигают 500мс и выше. Но и скачки от 3мс до 250мс тоже будут свидетельствовать о каких-то проблемах.
Запускать пинг на всех компах лучше одновременно и на некоторое время. Например минут на 20. Потом по статистике будет видно сколько где пакетов пропало.
2. Если критерии наличия проблемы позволяют, то можно попробовать отрубать части сети и смотреть наличие проблемы. Это я в том смысле, что если проблема происходит в среднем раз в пару-тройку часов, то отрубать на многие часы части сети при диагностикем ожет быть неприемлемым.
Редкеи пробемы дольше отлавливать. Но напоминаю, что критерии можно детализировать, ведь если пакеты у вас пропадат относительно редко, то скачки времени их возврата могут случаться чаще и подсвечивать проблему. Также можно сделать рамер пакета близким к максимальному, это должно тоже в некоторых случаях участить проявление проблемы.
Иногда не мешает нагрузить сеть комированием по локалке большого файла. В линуксе можнно с помощью утилиты tc послать большой поток рандомных байт на любой сокет..
3. Плавающие проблемы случаются из-за плохого обжима, перебитого жверью кабеля, перегрызенного UTP в плинтусе, из-за умиращих конденсаторов в блоке питания роутера (БП может не выдавать необходимого при нагрузках тока, но вольтметром такая неисправность не будет различима без нагрузки). Вообще старые (да и не только) роутеры могут страдать поплывшими электролитическими конденсаторами не только в блоках питания.
Хорошо, когда можно подменить роутер.
4. ну с четвертым пунктом ничего не пососветуешь, только разделать и тестировать все по отедльности и в разных сочетания и да поможет нам ктулху.
А для тех, кто дочитал этот опус до конйа — интересная задачка. Что пингуют эти команды, как и почему?
Тех, кто знает, попрошу не спойлерить=)
Пусть для кого-то будет сюрпризом этот дивный мир=)
UPD. Простите за адское количество опечаток в тексте. Писал в спешке и с непривычной клавиатуры. Исправлю всё попозже. Не ожидал, что многим ответ придётся по душе. Вроде ж накапитанил как мог.
Свитч перестаёт нормально работать при подключении роутера
Настроено это всё по мануалам из интернета, знания у меня в сетях чуть выше чем «продвинутый пользователь», никаких научных степеней по MTCNA конечно нет. Всевозможные «защиты от взлома» постарался настроить (например эти: https://habr.com/ru/post/424433/), веб-морду из интернета закрыл, так же как и все остальные службы.
Проблема:
Долгое время работало прекрасно, но в какой-то момент стало просто тупо пропадать подключение, и даже не через WiFi а прямо по проводам. То всё работает, то не работает ничего, не пингуется ни соседний ПК, ни сам роутер на 192.168.1.1, не идёт трассировка никуда, а то и вовсе arp -a ничего не возвращает.
Что было сделано для анализа:
- Попробовал перезагрузить роутер и свитч несколько раз — не помогло. Точнее помогало, но ненадолго, минут на 10.
- Проанализировал логи роутера, а также всех WiFi-тарелок. Ничего опасного или даже интересного там не было.
- Проанализировал записи /system sheduler, /ip proxy, /ip socks, /ppp secret роутера — ничего не нашлось.
- Два ноутбука подключил короткими проводами непосредственно к свитчу, на одном поднял сервер iperf, на другом запустил простенький скрипт:
# Бесконечно проверять скорость с частотой раз в 0.5 секунды while true; do iperf -c 192.168.1.121 -p 5001 -i 0.5; done При подключении ноутбуков к свитчу скорость по iperf то была около 100 МБит, но временами, раз в несколько секунд, резко просаживалась до нуля или почти до нуля, после чего снова возрастая до 100МБит.
- Попробовал подключить эти два ноутбука к свободным выходным портам роутера — там никаких просадок скорости не было, всё отлично.
- Достал маленький свитч на 5 портов, воткнул его проводом в большой свитч, переткнул два ноутбука в маленький свитч — точно также, просадки скорости.
- Отключил провод соединяющий маленький свитч с большим, т.е. ноутбуки остались сидеть на маленьком свитче в одиночестве, и скорость, естественно, не проседала а шла стабильно около 100МБит. При повторном подключении мелкого свитча к большому — скорость снова начинала периодически проседать.
Итого я сделал вывод, достойный капитана очевидность, о том, что похоже проблема в свитче, я слышал о каких то flood-ах сети (хотя и не очень представляю принципов), и подумал, что может какой-то ПК не даёт жить остальным.
- Стал отключать потребителей от большого свитча, тем временем глядя на то как меняются показания iperf.
- Обнаружил, что iperf начинает стабильно показывать почти 100 МБит когда отключён САМ РОУТЕР.
- Ещё раз перепроверил все настройки роутера в которых я что-то понимал, долго и вдумчиво посмотрел на те, которых я не понимаю.
- Пробовал подключать роутер не напрямую в большой свитч, а «сквозь» маленький. Безрезультатно.
- Параллельно прогуглил весь интернет, но похоже я даже не могу сформулировать вопрос так чтобы найти его на английском (на русском и подавно)
Ну и собственно, сотрудники разошлись, и проблема стала сходить на нет, когда осталось совсем мало народу, проседание скорости были уже не до 0 а до 60-70 МБит, и проблему больше не получалось воспроизвести.
Что хотелось бы понять (но не получается):
- Бывают ли такие flood-атаки (пусть даже и не «специальные») которые могут привести к такому поведению свитча?
- Какими инструментами можно это проверить? Как их найти? Я конечно пробовал включить wireshark, но в сети такой объём пакетов, что понять в них что-то можно только статистическим анализом, сдампив несколько гигов этих пакетов, и написав скрипты для анализа, что я наверное буду делать в случае если вообще ничего больше не поможет.
- Как можно проверить что в свитче есть проблема? Как его можно «отладить» если он неуправляемый? На мысль что дело не в нём меня навело то, что при подключении его к новенькому 5-портовому свитчу, он его «заражал» своим странным поведением. Но может это он как-то неверно реагирует на передаваемые данные и сам устраивает какой-то flood?
- Может быть есть какие-то «кривые» пакеты которые могут приводить к таким результатам? Откуда они могут браться? Как их обнаружить, как отладить?
Понимаю что на эти вопросы я должен знать ответы изучив стек сетевой стек TCP/IP до основания, устройство низкоуровневых протоколов и т.д., но я не сетевик, поэтому прошу помощи у более опытных товарищей.