Хабы / свичи вынимаем свитчи?

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

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

1. Подключите концентратор к коммутатору Cisco как обычно, с портом восходящего канала
2. Подключите рабочую станцию ​​к порту концентратора (в нашем случае под управлением ОС Windows XP, но это не имеет значения)
3. Соедините два других порта вместе на концентраторе (либо напрямую, с одним CAT5, либо косвенно через другой концентратор).

Все идет гладко до того как эта рабочая станция рассылает широковещательное объявление. Хотя концентратор и Cisco достаточно умен, чтобы предотвратить широковещательный шторм для других широковещательных пакетов, концентратор недостаточно умен, чтобы обнаруживать, что два его порта подключены друг к другу, и будет использовать почти 100% своей вычислительной мощности. для широковещательной передачи этого пакета в бесконечном цикле туда и обратно, а также через все другие порты (т. е. восходящий канал к вашей Cisco).

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

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

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

Тривиальные моменты, но я еще не видел их упомянутых:

Убедитесь, что порты вашего коммутатора не переведены в режим полного дуплекса, потому что в этом случае они не будут работать с концентраторами. Подумайте об этом - если их дуплекс или их скорости принудительно установлены, они, скорее всего, не будут правильно подключаться к коммутатору типа Netgear, который хочет автоматически согласовывать

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

Раньше в коммутаторах Cisco (а, может быть, и сейчас - сейчас я не в этом бизнесе) есть функция под названием «Быстрый старт». Для любого порта с включенным Faststart коммутатор не будет выполнять полный анализ связующего дерева и, включив эту функцию, администратор «пообещал» не подключать коммутатор или концентратор к этому порту. Причина этого заключалась в том, чтобы избежать тайм-аута DHCP-запроса клиентского ПК до того, как Cisco решит, что включение порта безопасно. Вы можете также посмотреть на это. (Если я совсем не вспомнил все это, заранее прошу прощения и надеюсь, что кто-то с более свежими знаниями меня поправит)

Если вы используете защиту портов на портах, вы столкнетесь с проблемами, когда на данном порте будет больше, чем ожидаемое количество MAC-адресов. Основные проблемы с подключением концентраторов к коммутируемой сети заключаются в том, что вы получаете большие домены коллизии (вместо «коммутатор + конечный блок» вы получаете «коммутатор + все нижестоящее на концентраторе»), вы можете вызвать петли переключения ( если концентратор когда-либо подключен к двум коммутаторам), и вы можете получить сеть, которая достаточно велика, чтобы широковещательный домен был «слишком широким» (абсолютное требование, чтобы локальная сеть была достаточно маленькой, чтобы пакеты из одного края в другой будут видны в преамбуле Ethernet; поскольку концентраторы имеют тенденцию хуже пропускать пакеты со скоростью (дешевле и все такое), это может в конечном итоге нарушаться).

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

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

Если у вас слишком широкий широковещательный домен, вы получите ложные повторные передачи из-за поздних конфликтов.

это классическая проблема переключения.
Если вы выполните cisco ccnp или просто изучите протокол связующего дерева, ответ станет очевидным.

связующее дерево предотвращает появление петель -> оно делает это, изначально определяя "корневой мост" ->
это определяется самым низким приоритетом коммутатора -> если есть связь, то сравниваются MAC-адреса коммутаторов -> часто старый коммутатор приравнивается к более низкому MAC-адресу -> весь трафик в сети проходит через старый коммутатор !!!! = сбой исправлен путем установки вашего самого быстрого / и наиболее централизованно подключенного коммутатора с жестко заданным приоритетом ниже значения по умолчанию.

по умолчанию cisco использует команду per-vlan-spanning-tree (pvst +): spanning-tree vlan 1-666 priority 24576

Я рекомендую использовать быстрое связующее дерево "режим связующего дерева quick-pvst", что в основном значительно ускоряет работу

из википедии (http://en.wikipedia.org/wiki/Spanning_tree_protocol)

Корневой мост связующего дерева - это мост с наименьшим (самым низким) идентификатором моста. Каждый мост имеет уникальный идентификатор (ID) и настраиваемый номер приоритета; идентификатор моста содержит оба числа. Для сравнения двух идентификаторов моста сначала сравнивается приоритет. Если два моста имеют одинаковый приоритет, сравниваются MAC-адреса. Например, если коммутаторы A (MAC = 0200.0000.1111) и B (MAC = 0200.0000.2222) имеют приоритет 10, то коммутатор A будет выбран в качестве корневого моста. Если сетевые администраторы хотят, чтобы коммутатор B стал корневым мостом, они должны установить для него приоритет меньше 10.

У меня это происходило в среде, отличной от Cisco. Концентратор был подключен к сетевому порту, к которому затем были подключены три компьютера. Один пользователь, без проблем. Когда все остальные вошли, чтобы играть, он начал убивать RDP-подключения к серверу терминалов. Вытащите ступицу, и проблема исчезнет.