Я видел странную проблему, которую я не могу воспроизвести по требованию, и у меня есть подозрение на первопричину.

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

Топология: у меня есть 2 неуправляемых гигабитных коммутатора Cisco, подключенных через гигабитный гигабит. Оба коммутатора имеют соответствующий порт рядом с гигабитным гигабитным портом незанятым, так что восходящий канал функционирует, как задумано. Оба коммутатора являются Cisco и принадлежат к одному семейству (SG100 и SG102), поэтому проблема несовместимости отсутствует.

Я сделал захват проволочного акула, напрямую подключенный к машине-виновнику, а также подключенный через коммутатор, и ОБА выдает тот же поток связующего дерева, в результате чего кадр MAC PAUSE замедляет работу, что убивает сеть.

Probable culprit but unable to replicate issue "YET" is that this seems to usually occur AFTER the following occurs:
1. User undocks their laptop from their docking station and connects to WiFi
2. User is done with need for laptop away from desk and re-docks
3. User's laptop re-connects via Ethernet on the docking station
4. Sometimes crashes entire network.

Так как я не смог воспроизвести проблему по требованию, как я мог построить какой-то фильтр для Wireshark, чтобы он захватывал только пакеты, которые были бы похожи на эхо (НЕ ICMP ECHO), больше похожее на дублированный трафик, вызывающий начальный шторм, прежде чем он уйдет орехи с остовом дерева?

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

Поскольку это не управляемые коммутаторы, они даже не поддерживают STP, поэтому я удивлен, почему он всегда заканчивается трафиком связующего дерева. Кроме того, MAC-адрес источника не существует в естественной конфигурации, и я знаю только рабочую станцию, на которую влияют, после факта, и он также всегда замораживается или иногда получает BSOD. Это было долгое время с тех пор, как я видел BSOD, когда это происходит, но система зависает каждый раз, когда нет минидампа, и да, он настроен.

Other things I've already eliminated:
Cabling or cabling loop(s)
event logs - just show time loss between frozen time and reboot
no dumps when frozen
updated to Dell's latest certified drivers and BIOS
rebooted everything (again intermittent but usually after a undock, connecft to WiFi, re-dock and auto connect to ethernet pattern)

1 ответ1

0

Во-первых, просто для ясности, это не протокол связующего дерева (IEEE 802.1D), это управление потоком Ethernet (IEEE 802.3x, теперь часть IEEE 802.3-2012). Фреймы ПАУЗ управления потоком данных Ethernet адресованы одному из тех же адресов, которые использует STP, поэтому анализаторы пакетов часто сообщают адрес как адрес STP, даже если он используется для управления потоком.

Эра 802.3x управления потоками Ethernet была своего рода провалом. Слишком поздно было обнаружено, что это может вызвать проблемы в сети, особенно блокировку заголовка. Представьте себе быстрый сервер, обслуживающий данные обычному клиенту и медленный клиент. Медленный клиент перегружен, отправляет кадр PAUSE на коммутатор, и теперь коммутатор не может доставить все кадры, которые он получает от сервера, поэтому коммутатор отправляет кадр PAUSE на сервер. Это блокирует возможность сервера отправлять кадры другому (обычному) клиенту, даже если на сервере, коммутаторе и клиенте имеется резервная емкость. Этот один медленный клиент (и не слишком яркий коммутатор, и не слишком яркий протокол управления потоком данных 802.3x Ethernet) облажался для всех.

Из-за этого некоторые поставщики коммутаторов намеренно не поддерживают управление потоком в стиле 802.3x или, если они вообще его поддерживают, они позволяют коммутатору только учитывать входящие кадры PAUSE, но никогда не отправляют их. Если ваши коммутаторы вообще управляемы и имеют параметры конфигурации для управления потоком, убедитесь, что они настроены так, чтобы никогда не отправлять кадры PAUSE.

Фактически, учитывая то, что вы наблюдаете флуд PAUSE, вашей сети, вероятно, будет лучше, если вы отключите управление потоком все вместе. Настройте свои коммутаторы и клиенты, чтобы отключить управление потоком.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .