Причина падения ЛВС?
Всем привет. Надеюсь, здесь мне смогут помочь, хотя бы задать направление. Ситуация следующая. Есть здание1 и здание2. В здании1 расположено сетевое оборудование, в него заходит интернет. Из здания1 в здание2 прокинута оптика. В здании2 оптику принимает конвертер ну и раздает интернет далее на неуправляемый свитч от Д-линк. На рабочих местах здания2 локалка и интернет работают ровно до тех пор, пока не выключается какой либо из компьютеров. В этом случае локалка падает на несколько минут, после чего поднимается. Если выключенный компьтюер включить, то локалка поднимается практически сразу. Под "падает локалка" подразумеваю пропажу пинга до основного роутера или любого устройства из здания1, индикация на свитчах и роутере при этом не пропадает. Менялись свитчи, медь, патч-корды в здании2, прозванивал сеть. Что это может быть? В каком случае оборудование может себя так вести?
Дополнительно:
Рассмотрите вариант установки управляемого коммутатора в здание№2, можно недорого и б/у
оборудование провайдера - медь - конвертор - оптика - конвертор - медь - один неуправляемый коммутатор - 15 компьютеров.
Я верно понимаю? больше нигде и ничего не подключается?
Полагаю не совсем. )))
Оборудование провайдера
В wan клиентское оборудование.
А уже оттуда опта в соседнее.
Должен стоят управляемый, или роутер с wan. И из его локалки уже идти в здание 2. На каком оборудовании dhcp сервер раздает адреса во второе здание?
Но я думаю что так:
свитч провайдера - медь - (в wan) роутер клиента главный (из lan) - медь - конвертер - опта в здание 2 - конвертер - медь - тупняк - 15 компов
Тут вопрос что прописано на роутере и что за тупняк, машины статикой идут или авто итд итп.
Провайдер - медь - ван порт здание 1 - сфп порт здания 1 - сфп конвертер здание 2 - свич- компы.
А вообще если это происходит в конкретными ПК то надо выявить куда они подключены , и если в один свич (а я так понял в здании 2 их несколько) то возможно свич тупит и попробовать его заменить, либо если вина конкретных пк то копать в этом направлении
я бы тоже посмотрел ))) это нужно задать вопрос автору.
Прошу пардону, был невнимателен. И да, роутер запросто может быть и провайдерский. У меня на одной площадке, например, именно так - роутер провайдера, даёт 4 физических порта и DHCP на 64 адреса (хотя и не запрещает дальше поставить ещё и свой роутер - но нафига?).
Ответы:
не используйте неуправляемые коммутаторы. Используйте управляемые, читайте их логи, смотрите за их состоянием. Это если в двух словах.
Больше похоже на то что STP шатается, что не вяжется с тупыми свичами и медюками.
Убирай конвертер, вместо него sfp в порт свича в здании2. Конвертеры бывают достаточно специфические...
Для начала получите ответы на вопросы:
Используется статика или DHCP?
Если DHCP то какое устройство раздает настройки?
Какие настройки получают ПК?
Какие сетевые настройки на "проблемных" компах?
Разберитесь как вообще работает сеть на вашем предприятии: кто получает интернет, как и кому раздает.
Далее не нужно бездумно менять оборудование, а нужно разобраться как связано отключение рандомного ПК с отвалом сети. Дело явно в сетевых настройках, придется обойти все ПК и разобраться что где, нарисовать карту что где стоит, как подключено и какое настройки имеет.
Раз все зависит от одного компа, в чем его уникальность? Может он включён а одну розетку с трансивером или на него ссылаются конфиги других пк?
- Нет, ничего подобного. Неточно выразился - в здании2 порядка 15 компьютеров, так вот при выключении части из них, происходит падения. Не одного конкретного, но нескольких. Никаких конфигов, ничего эдакого.
- Exmortis, в таком случае проблема кажется не сетевой, а физической, не могу представить ситуации, когда при выключении оборудования возникают проблемы у остальных. Управляемый коммутатор конечно добавит понимания, что происходит на нём самом, но не даст информации о том же конвертере, если у него перестаёт работать оптика, т.к состояние ethernet- порта не будет меняться. Попробуйте установить зависимость выключаемых пк и возникновения проблемы.
- Вы используете режим wol и тп средства удалённого доступа к машинам?
Отключите их в биосах, похоже, ваш свитч (роутер или коммутатор, что вы имеете ввиду?) не может обработать icmp пакеты от выключенного компа, сетевуха которого продолжает работать (если вы не знали). Для проверки выдерните физически rj-45 коннектор из компа. Если зависания свича не будет - дело в ICMP пакетах спящей сетевухи. - Exmortis, что значит "нет никаких конфигов"? они есть всегда. Религия запрещает сообщать операционную систему. не сказали айпишник, статика или DHCP или ещё с каким вывертом... Может у вас 15 dhcp-серверов и каждый сам себя шлюзом назначает.
После выключения компа, остальные через какое-то время продолжат работу, или починить можно только включением обратно всех компов?
По описанию - звучит очень странно.
Взять пару зависимых компов.
Посмотреть и сравнивать arp таблицу, ping, traceroute при включённом и выключенном соседе.
- Через какое-то время продолжат работу
- Exmortis,
Тесты провели? Вывод команд есть?Через какое время восстанавливается работа сети?
- SunTechnik, восстанавливается приблизительно через 5 минут. Какие тесты мне следует провести?
- По вашему описанию непонятно, в здании 2 Есть ли какой-нибудь router или нет.
Тесты:1. Все работает.
фиксируем вывод команд:
ping IP_основной_роутер
arp -a | find " IP_основной_роутер"
( Кавычки - обязательны)
ipconfig /all2. Тот же набор команд после выключения компа, начало проблемы.
3. Тот же набор команд после того, как работа сети сама восстановилась.Вообще - 5 минут страдартное время очистки ARP таблицы. Непонятно только где и почему ее надо чистить....
- SunTechnik, в здании2 роутера нет, лишь свитчи. Займусь тестом, спасибо.
- SunTechnik, вот такая ситуация. Не получается прикрепить картинку сюда, выдает ошибку, потому залил на хостинг.
https://ibb.co/ZBtvC8B
В arp-таблице несколько устройств, а в сети на данный момент 71 устройство - Exmortis,
1. Тест состоит из 3-х этапов. Вы вполнили 1/3 первого...
Надо понять что меняется.
2. Нас интересует запись для defaultrouter. Поэтому и стоит фильтр (find) на этот адрес.3. В arp таблице будут только адреса, с кем данный компьютер общался последние 5 минут. Так работает этот протокол.
5. Зачем картинки, если можно втсавить это все в виде текста прям в пост, оформив тегом code.....
PS, Ну почему нельзя сделать по шагам, то что просят..
- SunTechnik, сделаю, обязательно сделаю, просто сейчас нет возможности уронить сеть, решил начать с малого, с первого этапа. Спасибо!
- Exmortis,
При возможности, укажите модели коммутаторов которые используются в здании 2.Всё таки очень странное поведение сети...
Мастер браузер?
Отключите физически все машины. Либо по питанию, либо просто лан выдернуть. И добавлять по одной в строй. Вкл/выкл.
Например включили одну. Инет есть. Включили вторую. Инет есть на обеих. Выключаем машину номер 2 и смотрим. И тд. Наблюдаем и думаем дальше ))
Пингуй сеть и внутри второго здания если сеть осталась то виноват конвертер или порт на д-линке в сторону конвертора.
Дешёвые неуправляемые старые коммутаторы непредсказуемы. Не нужно доверять им.
Обязательно нужен, хотя бы самый дешёвый по акции D-Link, у которого будет веб интерфейс и поддержка большинства известных протоколов.
Новое оборудование будет работать нормально минимум пару лет.
неуправляшки, сразу после конвертера... бр. Если воткнуть перед неуправляшкой, какой нибудь роутер ,без ната. и попробовать, будет ли повторятся ситуация.
если нет- временно ставьте роутер, и ищите либо управляемый коммутатор, либо роутеры с двух сторон с sfp+1 портами. Сфп конвертер в связке с тупым свичом- лотерея. Ошибку сетевого оборудования так не отследить, без шлюза с логированием ВШ суточным и выявлением закономерностей.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Причины падения локальной вычислительной сети (ЛВС) могут быть разнообразными, и обычно требуют тщательного анализа для выявления и устранения проблемы. Вот несколько наиболее распространенных причин, которые могут привести к сбою в ЛВС:
1. Проблемы с оборудованием: Одной из основных причин сбоя ЛВС может быть неисправность сетевого оборудования, такого как маршрутизаторы, коммутаторы, кабели и т.д. В этом случае необходимо провести диагностику оборудования и, возможно, заменить неисправные компоненты.
2. Проблемы с настройками сети: Неправильные настройки сетевого оборудования или программного обеспечения могут привести к сбою ЛВС. Проверьте конфигурацию сетевых устройств, а также наличие конфликтов IP-адресов или других ошибок в настройках.
3. Атаки на сеть: Кибератаки, такие как DDoS, могут привести к отказу в обслуживании ЛВС. Для защиты сети от таких атак необходимо использовать специальное программное обеспечение или услуги безопасности.
4. Проблемы с программным обеспечением: Некорректная работа сетевых приложений или операционных систем на компьютерах в сети также может привести к падению ЛВС. Обновите программное обеспечение до последней версии и устраните возможные ошибки.
5. Нагрузка на сеть: Интенсивное использование сети большим количеством пользователей или передача большого объема данных может привести к перегрузке сети и, как следствие, к ее падению. Разгрузите сеть или увеличьте ее пропускную способность.
Для более точного определения причины падения ЛВС рекомендуется провести детальный анализ сети с использованием специализированных инструментов и методов диагностики. В случае затруднений, обратитесь к специалистам по сетевым технологиям для помощи в устранении проблемы.