О Spanning Tree Protocol администраторам стоит знать несколько больше, чем кажется на первый взгляд

Есть немало разбитых на сегменты сетей, которые обслуживаются коммутаторами уровня 2 и одновременно поддерживают устройства уровня 3 и, возможно, уровня 4. В некоторых сетях организованы виртуальные локальные сети. Тому, чья сеть подходит под это описание, стоит подумать о том, чтобы лучше разобраться в протоколе Spanning Tree (дословно «спутанное дерево». — Прим.ред.).

Нет ничего необычного в применении коммутаторов уровня 2, предоставляющих для соединения с локальными пользователями каналы на 10 или 100 Мбит/с, а также каналы Fast Ethernet или Gigabit Ethernet для связи с коммутаторами уровня 3 или 4. При таком сценарии сегменты уровня 2, по существу, представляют собой сети с мостовыми соединениями. Если подобные сети имеют избыточные связи с другими локальными сетями, то гарантировать корректную работу этих связей так, чтобы одна из них играла роль дублера другой, можно только с помощью протокола Spanning Tree. Виртуальные локальные сети усугубляют проблему, поскольку каждая из них по сути представляет собой сеть с мостовыми соединениями. Поэтому для каждой виртуальной локальной сети необходимо сконфигурировать отдельный экземпляр Spanning Tree. По мере перехода на коммутаторы уровня 3 проблема, для решения которой применяется Spanning Tree, исчезает, поскольку здесь уже используются маршрутизируемые сети. Конечная цель состоит в том, чтобы избавиться от Spanning Tree, полностью перейдя на маршрутизирующие сети на основе коммутаторов уровня 3 или 4.

В лаборатории нашей компании мы проанализировали девять коммутаторов пяти производителей, с тем чтобы сопоставить избранные ими реализации алгоритма Spanning Tree и сформулировать общие рекомендации по их конфигурированию. Выяснилось, что сколько производителей, столько и вариантов реализации. А значит, заказчикам необходимо изрядно потрудиться, чтобы удостовериться в том, что Spanning Tree корректным образом реализован в различных коммутаторах уровня 2.

Прежде чем перейти к детальному описанию, необходимо сделать несколько общих замечаний. Протокол Spanning Tree Protocol входит в состав стандарта IEEE 802.1D, специфицирующего MAC-уровень для мостовых соединений. Любое устройство, осуществляющее коммутацию на уровне 2, использует Spanning Tree.

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

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

Spanning Tree по умолчанию используется коммутаторами большинства производителей, но, скорее всего, пользователю следует переустановить некоторые из параметров настройки, что может оказаться довольно трудной задачей из-за достаточно сложной природы Spanning Tree. Достаточно сказать, что описание стандарта 802.1D занимает 378 страниц. Однако включение коммутаторов в сеть без должной их переконфигурации может привести к замедлению процесса регистрации пользователей, появлению некорректных соединений и несанкционированным перемещениям пользователей между виртуальными локальными сетями.

Исходя из данных, полученных при тестировании коммутаторов компаний Cisco, Nbase-Xyplex, Foundry, Olicom и Anritsu, стало ясно, что каждый из большинства ведущих производителей реализует Spanning Tree по-своему. К примеру, некоторые позволяют активизировать и отключать Spanning Tree отдельно для каждого порта, так что на порту 5 этот протокол может поддерживаться, а на порту 6 нет. Однако, похоже, что все производители придерживаются одних и тех же значений по умолчанию для фильтров Spanning Tree.

Проблемы клиентов

Общий недостаток всех проанализированных реализаций Spanning Tree состоит в том, что этот протокол медленный и зачастую он не может поддерживать скорость работы современных сетей. К примеру, для того чтобы гарантировать передачу данных корректному адресату, Spanning Tree использует пакеты BPDU (устройства данных протокола моста), содержащие информацию о портах, адресах, приоритетах и затратах. Но некоторые клиентские программы Novell и Microsoft связываются с портом коммутатора настолько быстро, что Spanning Tree не успевает послать пакеты BPDU. В этом случае есть вероятность, что пакеты будут отосланы на порты, где их быть не должно, порождая тем самым проблемы, которые Spanning Tree призван преодолевать.

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

Анализируя работу алгоритма Spanning Tree в своей лаборатории, мы убедились, что клиентское программное обеспечение Novell не в состоянии установить соединения с коммутаторами некоторых производителей. Нам удалось организовать эти соединения, только отключив Spanning Tree на некоторых портах коммутатора, подключенных к соответствующим клиентам Novell. Обнаружилось также, что NT Server время от времени самопроизвольно перезагружается.

На Web-узлах компаний Novell и Microsoft опубликованы рекомендации по разрешению подобных проблем, возникающих при использовании коммутаторов определенных типов. Обычно здесь советуют отключить тот или иной порт, что мы и сделали, или установить параметр регистра, который контролирует время, необходимое клиенту для того, чтобы найти следующий сервер. Отключение Spanning Tree на отдельных портах не должно вызывать каких-либо проблем до тех пор, пока вы отключаете только клиентские порты, но не основные каналы связи.

На настольных компьютерах, оснащенных ОС Windows NT с TCP/IP-клиентами корпорации Microsoft, ни разу не возникло проблем с соединением во время всех 150 попыток регистрации и установки связи в режиме DHCP при активизированном Spanning Tree. Правда, на Web-странице, посвященной поддержке NT, упоминаются некоторые потенциальные некорректности со Spanning Tree в режиме DHCP, и в этих случаях также рекомендуется отключить Spanning Tree на порту клиента.

Как справиться с проблемами?

Мы работали с инженерами из компании Netcom Systems, которая производит модули анализа производительности SmartBits, отслеживающие процедуру регистрации и отключения клиента на серверах Windows NT и NetWare. Этот процесс, как предполагается, должен контролироваться Spanning Tree.

Мы сконфигурировали анализатор SmartBits таким образом, чтобы он посылал 1000 пакетов в секунду в режиме широковещательной рассылки с одного модуля порта SmartBits на Коммутатор 1. SmartCounters на устройстве Netcom был сконфигурирован так, чтобы отслеживать время между моментом начала передачи пакетов с порта и появлением их на порту-получателе. Мы использовали для этого три различных порта на коммутаторе и определили среднее время доставки. При отключенном Spanning Tree оно было почти на четыре секунды больше, чем в том случае, когда протокол был активизирован. Это ожидаемый результат для сети небольшого размера; в крупной сети задержка может оказаться гораздо больше.

Но и задержка длительностью в четыре секунды может вызвать проблемы у пользователей, которые пытаются получить доступ к ресурсам серверов. К примеру, если при попытке клиента зарегистрироваться на сервере DHCP возникает подобная задержка, клиент может не получить IP-адрес и, следовательно, не сможет зарегистрироваться ни на одном из серверов сети.

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

Так, мы включили свои рабочие станции, подсоединенные к Коммутатору 1 и стали регистрироваться на серверах, содсоединенных к Коммутатору 2. При использовании некоторых из коммутаторов зарегистрироваться не удалось. Novell рекомендует изменить время регистрации на клиенте. Как отмечалось выше, для крупных сетей, содержащих тысячи узлов, такая ситуация неприемлема. Отключить Spanning Tree на отдельных портах куда проще.

Долговременное и, по всей видимости, наилучшее с точки зрения сетевого администратора решение — перейти на коммутаторы уровня 3 или 4 и обходиться без виртуальных локальных сетей. Нет никаких причин возвращаться к использованию мостов в сетях, которые полностью готовы к «внедрению» маршрутизации, поддерживающей работу со скоростью соединения, применяя коммутаторы уровня 3 или 4.

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

Стефан Льюис — технический директор центра SIGNAL Technology Solution Center. В подготовке статьи принимали участие сотрудники центра Джеймс Бек, Стив Уилсон и Эрик Лейх. Компания SIGNAL (www.signalcorp.com), созданная в 1987 году, специализируется на предоставлении услуг в области ИТ. С Льюисом можно связаться по электронной почте по адресу Tech_solutions@signalcorp.com.

Здравствуй, уровень 3 и прощай, Spanning Tree
Стефан Льюис

Зачем вы купили коммутатор уровня 2, который требует использования Spanning Tree для поддержки мостов между локальными сетями, когда могли бы предпочесть коммутатор уровня 3 или 4, способный осуществлять маршрутизацию на уровне портов и которому не нужен Spanning Tree? Из экономии. Коммутаторы уровня 2 намного дешевле коммутирующих маршрутизаторов уровня 3 и 4.

Впрочем, чтобы воспользоваться всеми преимуществами сегментации сетей, вам, скорее всего, придется заменить все коммутаторы уровня 2 в своей сети на коммутаторы уровня 3 или 4. Сделать это сразу, скорее всего, очень сложно, но вполне возможно заменять их постепенно.

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

Некоторые производители сетевого оборудования считают, что использовать алгоритм Spanning Tree в сетях с мостами уровня 2 в конечном счете то же самое, что применять маршрутизирующие коммутаторы уровня 3. Не верьте. Скорее всего, те, кто делает подобные заявления, просто не продает коммутаторы уровня 3.
Зачем нужен алгоритм Spanning Tree

В сетях, где установлено несколько прозрачных мостов, использование алгоритма Spanning Tree позволяет предотвратить возникновение бесконечных циклов, как показано ниже.

Мост 2 также передает пакет, который он сначала получил из Сегмента 1, в Сегмент 2. Станция F получает тот же самый пакет во второй раз — это уже потенциальная проблема. Мост 1 обнвруживает пакет, пришедший через Сегмент 2. Он обновляет свои таблицы, чтобы отобразить, что Станция A перенесена в Сегмент 2, и, поскольку по-прежнему не знает, где находится Станция F, передает пакет через Сегмент 1, замыкая тем самым цикл трафика.