Не работает сетевой коммутатор

5 типичных поломок сетевых коммутаторов: причины неисправностей и способы их устранения

Топ-5 причин выхода коммутатора из строя: перегрузка и другие поводы

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

Нарушение базовых правил эксплуатации

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

резкие выдергивания сетевых кабелей;

случайные удары по корпусу;

падения с большой высоты.

Среди причин повреждения внутренних компонентов также стоит упомянуть возгорание микросхем в результате контакта с водой или какой-либо другой жидкостью.

Чтобы защитить свитч от человеческого фактора, достаточно соблюдать правила безопасной эксплуатации, детально описанные в пользовательском руководстве.

Некачественное программное обеспечение

С проблемой недостаточно надежного ПО сталкиваются владельцы бюджетных коммутаторов от неизвестных производителей, а также пользователи контрфактного сетевого оборудования (подделок продукции известных брендов).

Важно: По ссылке https://www.moyo.ua/comp-and-periphery/network_equip/kommutatory-nastraiv/cisco/ можно приобрести оригинальный коммутатор Cisco на базе сертифицированного программного обеспечения.

Вернуть работоспособность свитчу в случае сбоя в работе ПО может повторная прошивка.

Нестабильность электрической сети

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

Для защиты девайсов от токов КЗ и резких перепадов напряжения следует использовать источники бесперебойного питания и внешний стабилизаторы.

Повреждения портов для подключения оборудования

Если сам коммутатор по визуальным признакам работает без перебоев, а подключить какое-либо устройство к нему не удается, проблема кроется в сетевых портах. Скорее всего, в результате продолжительной эксплуатации «входы» просто износились и стали непригодными для использования.

Решить эту проблему можно в любом сервисном центре. Специалисты быстро произведут замену поврежденных портов и вернут устройству функциональные возможности.

Выход из строя одного из внутренних элементов коммутатора

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

Устранить все эти поломки поможет поход в сервис или же самостоятельная замена неисправных запчастей.

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

Источник

Свитч перестаёт нормально работать при подключении роутера

Вопрос не столько по администрированию Linux-систем, сколько по сетям, и их отладке и настройке с помощью Linux-систем 🙂

Исходные данные:

В организации есть:

• Неуправляемый свитч на 48 портов (марку и модель записать забыл, добавлю позже, сейчас пишу уже из дома), к которому подключены по проводам некоторое количество рабочих станций на Linux, MacOS и Windows.
• Роутер MikroTik hEX RB750Gr3 (на RouterOS), через который заходит интернет
• Несколько Wifi-тарелок MikroTik подключённые также к свитчу

Настроено это всё по мануалам из интернета, знания у меня в сетях чуть выше чем «продвинутый пользователь», никаких научных степеней по 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, на другом запустил простенький скрипт:

При подключении ноутбуков к свитчу скорость по iperf то была около 100 МБит, но временами, раз в несколько секунд, резко просаживалась до нуля или почти до нуля, после чего снова возрастая до 100МБит.

• Попробовал подключить эти два ноутбука к свободным выходным портам роутера — там никаких просадок скорости не было, всё отлично.
• Достал маленький свитч на 5 портов, воткнул его проводом в большой свитч, переткнул два ноутбука в маленький свитч — точно также, просадки скорости.
• Отключил провод соединяющий маленький свитч с большим, т.е. ноутбуки остались сидеть на маленьком свитче в одиночестве, и скорость, естественно, не проседала а шла стабильно около 100МБит. При повторном подключении мелкого свитча к большому — скорость снова начинала периодически проседать.

Итого я сделал вывод, достойный капитана очевидность, о том, что похоже проблема в свитче, я слышал о каких то flood-ах сети (хотя и не очень представляю принципов), и подумал, что может какой-то ПК не даёт жить остальным.

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

Обнаружил, что iperf начинает стабильно показывать почти 100 МБит когда отключён САМ РОУТЕР.

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

Пробовал подключать роутер не напрямую в большой свитч, а «сквозь» маленький. Безрезультатно.

Параллельно прогуглил весь интернет, но похоже я даже не могу сформулировать вопрос так чтобы найти его на английском (на русском и подавно)

Ну и собственно, сотрудники разошлись, и проблема стала сходить на нет, когда осталось совсем мало народу, проседание скорости были уже не до 0 а до 60-70 МБит, и проблему больше не получалось воспроизвести.

Что хотелось бы понять (но не получается):

Бывают ли такие flood-атаки (пусть даже и не «специальные») которые могут привести к такому поведению свитча?

Какими инструментами можно это проверить? Как их найти? Я конечно пробовал включить wireshark, но в сети такой объём пакетов, что понять в них что-то можно только статистическим анализом, сдампив несколько гигов этих пакетов, и написав скрипты для анализа, что я наверное буду делать в случае если вообще ничего больше не поможет.

Как можно проверить что в свитче есть проблема? Как его можно «отладить» если он неуправляемый? На мысль что дело не в нём меня навело то, что при подключении его к новенькому 5-портовому свитчу, он его «заражал» своим странным поведением. Но может это он как-то неверно реагирует на передаваемые данные и сам устраивает какой-то flood?

Может быть есть какие-то «кривые» пакеты которые могут приводить к таким результатам? Откуда они могут браться? Как их обнаружить, как отладить?

Понимаю что на эти вопросы я должен знать ответы изучив стек сетевой стек TCP/IP до основания, устройство низкоуровневых протоколов и т.д., но я не сетевик, поэтому прошу помощи у более опытных товарищей.

Источник

Что делать, если на компьютере отсутствует подключение при соединении с неуправляемым коммутатором по кабелю?

Примечание: Данные советы предполагают, что индикатор Ethernet на вашем коммутаторе горит при подключении компьютера к коммутатору по кабелю, и ваш компьютер работает исправно, если он подключен к роутеру напрямую.

Если индикатор Ethernet не горит, когда компьютер подключён кабелем к коммутатору, то воспользуйтесь следующим FAQ: «Что делать, если Ethernet индикаторы не горят на неуправляемом коммутаторе?»

Проблем может быть несколько: настройки на вашем роутере, или коммутатор работает некорректно.

Для выявления проблемы необходимо последовательно следовать инструкциям ниже:

Шаг 1. Сначала выполните следующий тест.

1. Подключите два ваших компьютера кабелями к коммутатору (при этом отключите любые другие кабели от коммутатора и компьютеров); настройте на ваших компьютерах статические IP-адреса. Например, компьютер 1: 192.168.0.2, а компьютер 2: 192.168.0.3 (если не знаете, как это сделать, воспользуйтесь нашим FAQ: «Как настроить параметры TCP/IP у компьютера?»)

1. Отключите или удалите антивирус и брандмауэр на обоих ваших компьютерах, т.к данное программное обеспечение может мешать проведению следующего теста. После него вы сможете вернуть ваши настройки обратно. После запустите Ping с вашего первого компьютера на второй (если не знаете, как это сделать, пожалуйста, воспользуйтесь поиском в интернете)

О том, как использовать команду Ping, можно прочитать здесь.

Результаты команды PING:

1. Если вы видите сообщение «Узел назначения недостижим» или «Превышен интервал ожидания для запроса», и потери составляют 100%, то свяжитесь с нашей службой технической поддержки: support.ru@tp-link.com

1. Если в результатах вы видите сообщения типа «Ответ от…», то перейдите к шагу №2.

Шаг 2. Подключите ваш первый компьютер к коммутатору по кабелю и настройте на нём статический IP-адрес в той же локальной сети, в которой расположен ваш роутер и второй компьютер. Затем отключите или удалите антивирус и брандмауэр с вашего компьютера и попробуйте запустить PING с вашего первого компьютера на другой.

Результаты команды PING:

Источник

Типичные сбои сетевых коммутаторов

Проблемы, с которыми приходится сталкиваться в коммутируемой сетевой среде, мало чем отличаются от сбоев в разделяемой среде передачи.

Поэтому и вопросы, на которые требуется ответить, одинаковые: что случилось? кто это сделал? каков будет ущерб? Принципиальная разница заключается
в том, что в коммутируемой среде ответы должны относиться к конкретному порту, а значит, следует учитывать следующие факторы:

С чего следует начинать, когда вы получаете сообщение о том, что в коммутируемой сети возникла проблема? Как правило, главная трудность заключается в невозможности «заглянуть» внутрь коммутатора. Источник неполадок следует искать в первую очередь на втором уровне сетевой модели OSI при организации коммутатором моста, при этом использование виртуальных сетей VLAN и других функций третьего и более высоких уровней, а также правил продвижения трафика, может дополнительно осложнить ситуацию. Если в сети реализованы «продвинутые» функции коммутации, например, маршрутизация на четвертом уровне и выше вкупе с балансировкой нагрузки, то за диагностику должен браться специалист, отлично разбирающийся во всех тонкостях настройки коммутаторов.

Устанавливая в сети коммутатор, вы фактически создаете отдельный коллизионный домен на каждом порту – именно таков принцип работы коммутаторов. Если к порту подключить концентратор, ресурсы которого используются совместно, то коллизионный домен может увеличиться до максимально допустимого для данного варианта Ethernet размера. Коммутирующее оборудование постоянно дешевеет, поэтому в большинстве современных сетей к каждому порту подключается всего одна рабочая станция, и в этом случае коллизионный домен состоит из единственного кабельного сегмента.

Коммутатор, в целом в свою очередь, является частью отдельного широковещательного домена, причем иногда в домен входят несколько коммутаторов, объединенных в каскад или подключенных параллельно. При использовании функций третьего уровня модели OSI в сети создается большое количество широковещательных доменов — по числу виртуальных сетей VLAN. В предельном случае, если, конечно, коммутатор допускает это, каждый порт может быть сконфигурирован как отдельный широковещательный домен. Такая конфигурация, с полным на то основанием, называется прямой маршрутизацией до рабочего места пользователя.

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

К сожалению, весьма распространена конфигурация, когда в одну подсеть или широковещательный домен помещаются все серверы, а пользователи распределены по некоторому количеству других подсетей или широковещательных доменов. В таком случае практически все запросы должны маршрутизироваться. Если ради удобства обслуживания необходимо разместить все серверы в одном помещении (серверной), то их рекомендуется распределить по нескольким виртуальным сетям VLAN. Пользователей, которые обращаются к конкретному серверу, следует отнести к той же виртуальной сети. В такой конфигурации матрица коммутатора может использовать для обычного трафика мост на втором уровне модели OSI, поэтому маршрутизироваться будут только нетипичные или редкие запросы. Если сервер обслуживает более одного сообщества пользователей, то установите в него дополнительные сетевые карты, чтобы связь осуществлялась на втором уровне модели OSI.

ТОЧНОЕ РАСПОЗНАВАНИЕ ПРОБЛЕМЫ

Чуть ли не единственный по-настоящему эффективный метод диагностики коммутируемых сетей — запрос информации о поведении сети у самого коммутатора. Такие данные обычно запрашиваются с помощью протокола SNMP, либо через консольный порт коммутатора. Разумеется, прямое подключение к консольному порту менее удобно, поскольку администратору придется подходить к каждому коммутатору в сети. Во избежание подобных неудобств можно, конечно, установить терминальные серверы и подключить их к консольным портам, но все-таки предпочтительнее использовать протокол SNMP, поскольку он позволяет отправлять запросы из любой точки сети и для этого не нужно устанавливать дополнительное оборудование.

При наличии системы управления сетью коммутатор можно настроить таким образом, чтобы он сам отправлял незапрашиваемый ответ — уведомление SNMP trap – каждый раз, когда уровень использования, количество ошибок или какой-то другой параметр превышают установленное пороговое значение. Причину можно выяснить позже — с помощью системы управления сетью или инструментов мониторинга. Множество проблем успешно разрешается путем запроса к коммутатору, но есть такие, для которых этот способ непригоден. Запрос может применяться как в качестве профилактики, так и для осуществления мониторинга в случае сбоя.

Другая стратегия – дождаться, пока от пользователей начнут поступать жалобы. Во многих сетях применяется именно такой подход, который не стоит недооценивать из-за внешней простоты – на самом деле, он очень эффективен. Пользователи чутко реагируют на состояние сети, несмотря на то, что представление о ее работе больше основывается на подсознательном восприятии, чем на логических заключениях. Заметив малейшее ухудшение
в работе сети, пользователь обычно тут же обращается с жалобой в отдел ИТ или к системному администратору. Так что работу по поиску и устранению неисправности можно начать с его рабочего места. Такой подход называется реактивным, поскольку предполагает реагирование на уже произошедший сбой.

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

МЕТОДЫ ДИАГНОСТИРОВАНИЯ КОММУТАТОРОВ

Получить информацию о работе коммутатора можно как минимум десятью основными способами. Каждый предполагает свой порядок действий и имеет свои положительные и отрицательные стороны. Как обычно, единого рецепта на все случаи жизни не существует. Выбирать подходящее решение из разных вариантов следует, прежде всего, исходя из доступности ресурсов, опыта специалиста, проводящего работы, и оценки последствий для функционирования сети (приостановка, перерывы в работе) при использовании того или иного метода.

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

Для простоты представим себе минимальный сегмент сети: сервер, подключенный к коммутатору. В одних случаях мы будем предполагать, что пользователи, испытывающие проблемы, подключены к тому же самому коммутатору, в других — что они будут пытаться получить доступ к серверу через магистральный порт, ведущий либо к другому коммутатору, либо к маршрутизатору. Диагностика начинается в ответ на жалобу о медленной работе сети при обращении к серверу. К сожалению, такое описание проблемы ничего не говорит специалисту ИТ. Если речь идет не об обычном сбое, а взломе системы защиты, причем предполагаются последствия юридического характера, то необходимо принять дополнительные меры, чтобы обеспечить достоверность и юридическую силу собираемых данных.

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

МЕТОД 1: КОНСОЛЬНЫЙ ДОСТУП К КОММУТАТОРУ

Получить доступ к настройкам коммутатора можно разными способами, включая следующие:

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

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

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

Если сбой действительно вызван настройками, то метод консольного доступа, безусловно, позволит устранить его.

Минусы. Старшие системные администраторы и другие ведущие сотрудники отделов ИТ, обладающие паролями для доступа к настройкам коммутаторов, при проведении диагностики уделяют столь повышенное внимание конфигурации, что никакие другие варианты даже не приходят им в голову, пока этот метод себя полностью не исчерпает. Между тем, отказ от прочих подходов может существенно задержать устранение сбоя и дополнительно осложнить ситуацию. С помощью только консольного доступа удается выявить и устранить только часть сетевых проблем.

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

Данные о конфигурации полезны для того, чтобы в общих чертах выяснить, работает ли коммутатор так, как должен. Однако для проверки конфигурации и производительности сети нужно применять иные методы диагностики коммутаторов — возможно, даже не один,
а несколько.

Если речь идет о критически важных сегментах сети, то консольный доступ из удаленных точек может быть либо запрещен, либо разрешен только с конкретной группы жестко фиксированных адресов. Обычно пароли для доступа к коммутаторам не известны рядовому персоналу отделов ИТ и служб технической поддержки, поэтому они не имеют возможности использовать консольный доступ. Инженеры более высокого уровня, располагающие паролями, как правило, не участвуют в ежедневной работе по устранению сбоев в сетях. А теперь представьте, каким образом специалист, в прямые обязанности которого входит постоянное поддержание производительности сети, сможет эффективно работать, если консольный доступ ему запрещен?

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

Игорь Панов — региональный менеджер по продукции и поддержке партнеров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.

Поделитесь материалом с коллегами и друзьями

Источник