У меня только что случился странный опыт в моей домашней сети. Наш Ethernet вышел из строя; пинговать соседний хост было невозможно. Я проверил переключатель; все огни горели и мерцали, хотя мерцали синхронно, что немного беспокоило. Затем я заметил, что мой Linux-бокс разбился (не реагирует на мышь и клавиатуру). Я нажал кнопку сброса, и в этот момент сеть очистилась.
Это могло бы представлять только академический интерес, за исключением того, что мой работодатель работает в бизнесе, где непрерывность обслуживания имеет большое значение. Важные данные передаются по двум независимым локальным сетям Ethernet. Наши модели надежности предполагают, что единственное, что может вывести из строя всю локальную сеть, - это отказавший коммутатор. Так что мысль о том, что это может сделать один неисправный хост ... вызывает беспокойство.
Это сообщение на форуме Cisco говорит, что это невозможно, так что не волнуйтесь.
Этот отчет о сбое на таможне США звучит похоже: неисправная карта Ethernet выкупила их сеть. Это была одиночная сеть, и это звучит как аппаратный сбой, поэтому обе наши двойные сети не будут отключены. Но мне интересно: может ли ошибка драйвера устройства втиснуть карту в состояние, когда она глушит сеть? Если это так, то, если бы он управлял двумя связанными каналами, он мог бы заклинить оба одинаковым образом.
Кто-нибудь знает больше о возможных режимах отказа Ethernet?
редактировать
Я пытаюсь понять: что может сделать один узел в программном обеспечении (например, в драйвере устройства), что может вывести из строя всю сеть. Предположим, что это не вредоносное ПО, поэтому неясные ошибки конкретных переключателей, вероятно, не являются проблемой. Отправка кадров на один конкретный хост этого не сделает. Будет ли иметь такой эффект отправка большого количества широковещательных кадров (адресат FF: FF: FF: FF: FF: FF)? А как насчет джаббера? Это все еще?
Вот лишь несколько причин, которые могут вызвать поведение, свидетелем которого вы стали:
Петля переключателя.
Вредоносное ПО.
Плохая / неисправная сетевая карта.
Неисправный / некорректный драйвер сетевой карты.
Широковещательный шторм (обычно связанный с петлей коммутатора).
Чтобы обратиться к вашему редактированию: Эту проблему могут вызвать широковещательный шторм или переполнение коммутатора (это две разные вещи). Обратите внимание, что здесь работают два широковещательных адреса: FF-FF-FF-FF-FF-FF (255.255.255.255), который является широковещательным адресом уровня 2, И широковещательный адрес подсети уровня 3 (например, 192.168.1.255). - широковещательный адрес подсети уровня 3 для подсети 192.168.1.0/24). Широковещательный шторм на уровне 2 или 3 может вызвать эту проблему.
Коммутаторы запускают код в их прошивке. Иногда этот код содержит ошибки, и неожиданный ввод может привести к сбою переключателя. Так что да, некорректно работающий хост может вывести коммутатор из строя. Это маловероятно, но может случиться.
Несколько лет назад (может быть, в 2003 году?) У меня были неуправляемые коммутаторы Netgear, которые падали 2-4 раза в неделю, как если бы они подвергались широковещательной буре - как ваше описание выше. Единственным решением была перезагрузка стека. Служба поддержки Netgear сообщила, что у них есть известная проблема с запуском IP и IPX на них, и, поскольку они были неуправляемыми, устранять неполадки нечего. Они были EoL без дальнейших обновлений прошивки, поэтому они заменили их более новыми управляемыми коммутаторами по гарантии.
Что касается «перечислите, пожалуйста, все возможные режимы отказа Ethernet» - нет, это глупая просьба. Однако для вашего собственного образования прочитайте о циклах связующего дерева, это распространенный режим сбоя, вызванный пользователем.
Поскольку у Linux-бокса есть два интерфейса LAN: можете ли вы исключить, что он временно не соединял эти два интерфейса, создавая мостовую петлю?
Простое использование двух коммутаторов не обеспечивает высокой доступности. На переключателях должны быть индикаторы, сигнализирующие о широковещательном шторме, и соответствующее программное обеспечение для мониторинга. Для этого настройте управляющую VLAN с более высоким приоритетом, чтобы ее не прерывал широковещательный шторм. В качестве альтернативы можно запускать функции управления по физически отдельным сетевым каналам или вне полосы пропускания.
PS к вашему редактированию: на переключился сети, единственное, что может вывести из строя все порты, - это широковещательные штормы или серьезная перегрузка. Негабаритные кадры (jabber), фрагменты или подобные аномалии просто отбрасываются переключателем. Широковещательный шторм от входного порта может затопить сеть полосой пропускания этого порта - порт 100M не причиняет большого вреда сети 1G, но порт 1G может легко заглушить все выходные порты 100M. Точно так же отправка большего количества данных через восходящий канал, который он может обрабатывать, снизит большую часть другого трафика в этом направлении.
Широковещательные штормы обычно вызываются петлями моста. Spanning tree - хорошее средство от этого, также позволяющее добавлять избыточные ссылки в вашу сеть. С другими штормами можно справиться путем ограничения широковещательной передачи на граничных портах.
Заторность - более крутой зверь. Аппаратный подход состоит в том, чтобы убедиться, что все порты загрузки / загрузки работают быстрее, чем любой пограничный порт. На гигабитном коммутаторе с восходящим каналом 10GE вам потребуется как минимум 10 граничных портов для насыщения восходящего канала. Другой подход - ограничить пропускную способность граничного порта, чтобы они не могли перегрузить восходящий канал.