Я уверен, что многие из нас привыкли (или испытали) рутинную (или, по крайней мере, случайную) необходимость перезагрузки (или выключения и выключения) кабельного модема, модема dsl, маршрутизатора или концентратора / коммутатора.
Однако я решил опубликовать здесь сообщение в ответ на недавно возникшую широко распространенную проблему. У нас есть несколько сетевых шкафов в нескольких зданиях.
У большинства из них есть качественные управляемые коммутаторы - гигабитные, оптоволоконные между зданиями, а иногда и между шкафами.
На выходных у нас произошел какой-то сбой питания. Однако глюк поразил только одно здание, а не все локации.
После этого было много проблем с сетью. Проблемы с принтерами, потеря связи и многое другое. По всем зданиям.
Кажется, что все «качественное» управляемое сетевое оборудование в порядке. Однако в некоторых областях у нас есть неуправляемые коммутаторы потребительского класса. Например, большой офис, у которого всего 1 точка сети, но требуется несколько подключений. Теперь мы постепенно обходим все эти переключатели (из-за того, что пользователи звонят с проблемами) и выключаем их и выключаем. Это устраняет проблему для пользователя. Выключатель обычно выглядит нормально. У некоторых из них горят все огни (когда их не должно быть).
Так почему же все эти переключатели начали давать сбои? Какие-то фальшивые данные маршрутизации выталкиваются из переключателя с ошибкой питания?
Я собираюсь применить здесь бритву Оккама. Хотя я полагаю, что это возможно что некоторые определенные искаженные пакеты могут привести к тому, что ваши недорогие коммутаторы попадут в режим отказа, который вы описываете, я считаю это очень маловероятной причиной. Коммутаторы, которые вы описываете как имеющие проблемы (небольшие неуправляемые коммутаторы), скорее всего, не будут иметь реализации связующего дерева, не говоря уже о поддержке коммутации уровня 3 и протоколов динамической маршрутизации. Такой тип коммутатора должен быть «слепым» к фактическому содержанию кадров, которые он переключает, помимо использования MAC-адресов источника и назначения для принятия решений о переключении.
Это заставляет меня поверить, что у вас проблема с питанием шире, чем вы думаете.
Исходя из предположения о проблемах с питанием, я бы сказал, что у вас проблемы с недорогими коммутаторами, потому что они, скорее всего, низкокачественные. Я знаю, это звучит банально, но это был мой опыт работы с сетевым оборудованием на протяжении всей моей карьеры (за очень немногими исключениями). Как правило, вы получаете то, за что платите (и, хотя на что-то может быть выставлена неправильная цена, рынок это довольно быстро решает).
Коммутатор с более высокой стоимостью, как правило, будет иметь лучший источник питания, который с большей вероятностью будет работать в пределах допусков при воздействии «глючного» сетевого питания. Я подозреваю, что блоки питания в ваших более дешевых коммутаторах, вероятно, начали отказывать в плохом питании, когда сетевое питание вышло из строя. В этот момент некоторая часть «мозгов» коммутатора оказалась в сценарии «этого никогда не должно происходить», потому что одна или несколько шин питания смещены слишком далеко за пределы допуска.
Коммутатор Ethernet обычно не является отдельной ASIC, на которой работает все шоу, а скорее представляет собой группу систем ASIC, которые выполняют различные задания, связанные друг с другом. Не зная об архитектуре рассматриваемого коммутатора, сложно сказать что-либо определенное. Много лет назад у меня был опыт работы с моделью коммутатора, в которой для работы группы из 4 портов использовалась одна ASIC. Определенные типы сбоев могут привести к тому, что группы из 4 портов на коммутаторе будут «отключаться», в то время как остальная часть коммутатора продолжает работать нормально. По моему опыту, частичный отказ переключателя не является ненормальным.
В случае отказа, например, части выключателя, которые поддерживали включение света, продолжали работать нормально. Аппаратное обеспечение физического интерфейса (PHY), вероятно, продолжало работать нормально (поскольку вы, вероятно, видели «свет» на дальних концах соединений). Однако кое-что еще не работало должным образом, и в итоге вы увидели отсутствие связи. В тех случаях, когда мне «повезло» поймать переключатель «в процессе» подобного сбоя, я подключал свой ноутбук к «проблемному» порту и наблюдал (с помощью Wireshark) полностью «темную» сеть без любые широковещательные пакеты или другой «шум», обычно связанный с типичной «рабочей сетью». Пакеты, передаваемые в эти порты, никогда не появлялись где-либо еще в сети - они просто попадали в «черную дыру». Готов поспорить, вы бы увидели нечто подобное в своей ситуации.
Коммутаторы серии Cisco 1900 были печально известны этим несколько лет назад.
Эти переключатели использовали 2 внутренних источника питания: 5 В для ЦП / объединительной платы, 12 В для памяти CAM. При кратковременном скачке напряжения 5 Вольт оставались достаточно стабильными для продолжения работы коммутатора, но 12 Вольт упали достаточно, чтобы таблицы памяти CAM были повреждены. К сожалению, ЦП коммутатора не мог обнаружить повреждение памяти, которое вызвало разного рода хаос с коммутацией L2 и ARP.
Поэтому в каждый коммутационный шкаф мы ставим небольшой ИБП. Это было намного дешевле, чем переустанавливать каждый переключатель вручную. (И иметь дело с рассерженными пользователями.)
Cisco исправила это в более поздних моделях. Я слышал о тех же проблемах со старыми коммутаторами HP.
Я уверен, что есть много оборудования, особенно в сегменте потребительских товаров / soho, которое имеет аналогичные проблемы. Источник питания хорошего качества по-прежнему является одним из наиболее дорогих компонентов устройства, поэтому обычно это первый элемент, который снижается, когда PHB решают, что наценка на продукт слишком низкая.
Возможно некоторая ошибка CRC / Jabber / STP / широковещательной передачи, которую управляемые коммутаторы могли «обработать». Потребительский уровень не смог справиться с данными, поэтому они рухнули.
Возможно, это не имеет к этому никакого отношения, и нахальный пользователь нашел способ вывести из строя вашу сеть!
Большинство сетевых проблем, которые вы увидите с неуправляемыми коммутаторами, связаны с таблицей arp. На этом уровне сети больше нет ничего плохого. И это должно быть относительно легко протестировать с использованием arpping из различных мест в вашей сети. Если это связано с arp, вы найдете некоторые области вашей сети, где arp ping не разрешается.
Теперь, если вы используете STP в управляемых частях вашей сети, то есть вероятность, что устанавливается ссылка, которая должна быть активна. Но вы сможете понять это по управляемым коммутаторам. Ваши неуправляемые коммутаторы не будут поддерживать STP, поэтому они не будут участвовать.