Таблица. Результаты тестов на взаимодействие

Целью тестирования была проверка способности коммутаторов взаимодействовать друг с другом, и семь компаний, согласившихся представить на наш суд свои продукты, не только получили высокие баллы за реализацию в этих устройствах технологий коммутации второго и третьего уровней, но и искренне прониклись духом происходившего. Непримиримые конкуренты на рынке активного сетевого оборудования, они сумели на время отказаться от маркетинговых заготовок и попытались максимально содействовать друг другу в прохождении тестов, организованных компанией The Tolly Group и еженедельником Network World.

Взять хотя бы Джеффа Табота из Lucent Technologies. Даже в промежутках между испытаниями продуктов этой корпорации он не успокаивался ни на минуту: переставлял «чужие» коммутаторы, протягивал и подключал кабели и вообще предпринимал все возможное, чтобы заставить работать очередную пару устройств. Такую картину увидишь не часто, но самое удивительное, что приведенный пример — далеко не единственный. Представители Hewlett-Packard активно взаимодействовали с коллегами из Foundry Networks, специалисты Nortel Networks сотрудничали с инженерами из Cabletron и даже фирма Cisco решила отключить свои новые средства поддержки алгоритма Spanning Tree ради достижения совместимости с коммутаторами IBM, Lucent и иных компаний.

Понятно, что в тесте на взаимодействие производительность одного устройства напрямую зависит от быстродействия другого, так что тесная кооперация представителей разных фирм является чуть ли не обязательным требованием. Тем не менее подобный дух товарищества и взаимовыручки не возникает во время более традиционных испытаний, поскольку компании напрямую общаются только с организаторами. В нашем же случае настоятельная потребность в совместной работе породила неповторимую атмосферу, благодаря которой даже удалось освободить один из пяти дней, первоначально отведенных для четырех обязательных (№ 1—4) и шести необязательных (№ 5—10) тестов.

Для испытаний были предоставлены пять коммутаторов второго уровня (SmartSwitch 6000 компании Cabletron, Catalyst 2948G производства Cisco Systems, ProCurve Switch 4000M фирмы Hewlett-Packard, 8275-416 Ethernet Switch корпорации IBM и Cajun P120 Workgroup Switch производства Lucent Technologies) и семь — третьего (SmartSwitch Router 8600 компании Cabletron, Catalyst 8510 производства Cisco Systems, BigIron 4000 фирмы Foundry Networks, ProCurve Routing Switch 9304M компании Hewlett-Packard, 8371 Multilayer Ethernet Switch корпорации IBM, Cajun P550 Gigabit Switch производства Lucent Technologies и Accelar 1200 корпорации Nortel Networks). Показанные ими результаты в целом выглядят обнадеживающе: их изготовители заявляют о приверженности стандартам, и на поверку выяснилось, что так оно и есть. По крайней мере, если и имеются отклонения от существующих спецификаций, то они настолько незначительны, что практически не ограничивают способность этих устройств к взаимодействию. В результате пользователи могут комбинировать оборудование разных фирм, исходя из собственных потребностей.

Все исследованные нами модели оказались в состоянии согласовывать скорость и другие параметры дуплексной передачи данных для достижения максимальной полосы пропускания сформированных соединений, а коммутаторы третьего уровня к тому же свободно «общались» друг с другом, даже когда принадлежали к сетям с различными протоколами. Большая часть коммутаторов третьего уровня продемонстрировала также умение дублировать «напарника» в случае его отказа: в конечном счете, самое худшее, что может обнаружиться при серьезных нарушениях в функционировании реальной сети, это неспособность коммутаторов к совместной работе в таких условиях.

Тест 1. Согласование параметров

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

Степень сложности: низкая.

Участники: все 12 устройств.

Результаты: тест успешно прошли все устройства.

Удостоверившись в том, что конфигурации коммутаторов на обоих концах соединения настроены правильно и позволяют начать процедуру согласования, мы записали значения параметров, которые каждое из устройств сообщило своему «напарнику», и сравнили эти значения с максимальными величинами, поддерживаемыми обоими коммутаторами. Как выяснилось, пропускная способность остается в требуемом диапазоне при подаче на коммутаторы потоков 1518-байтных пакетов от устройства SmartBits фирмы Netcom Systems.

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

Тест 2. Управление потоком

Описание: любые два устройства должны были обменяться служебной информацией, относящейся к управлению потоком.

Степень сложности: средняя.

Участники: все устройства за исключением коммутатора 8371 Multilayer Ethernet Switch компании IBM.

Результаты: различны для разных устройств.

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

Если говорить конкретнее, мы попытались проверить способность указанных устройств отправлять и принимать кадры PAUSE, относящиеся к управлению потоком, хотя стандарт IEEE 802.3x для сетей Fast Ethernet и Gigabit Ethernet требует лишь того, чтобы коммутатор адекватно реагировал на поступившие сообщения о приостановке передачи, а не генерировал их самостоятельно (см. врезку). Нам важно было определить, какие действия предпринимает конкретный коммутатор, получив такое сообщение: попросту игнорирует его, пытается «задушить» входящий трафик или корректирует потоки данных на отдельных портах. Хотя все эти стратегии могут рассматриваться как соответствующие стандарту, они приводят к совершенно разным результатам.

Установив связь между двумя устройствами и сформировав высокоскоростное восходящее соединение, мы намеренно создавали перегрузку на выходном порте одного из коммутаторов и ждали, когда он отправит сообщение о приостановке передачи своему «партнеру». Затем мы выясняли, получил ли второй коммутатор указанное сообщение от перегруженного устройства. Наконец, при помощи сетевых анализаторов (Sniffer Pro HighSpeed фирмы Network Associates для гигабитных соединений и DominoFE компании Wavetek для соединений Fast Ethernet) проверяли, действительно ли коммутатор, принявший сообщение о приостановке передачи, уменьшал интенсивность потока отправляемых данных до тех пор, пока перегрузка не исчезала. Тест выполнялся в обоих направлениях для каждой пары устройств.

Испытание прошли, не вызвав нареканий, лишь четыре модели — Cajun P120 Workgroup Switch и Cajun P550 Gigabit Switch компании Lucent, 8275-416 Ethernet Switch корпорации IBM и ProCurve Switch 4000M фирмы Hewlett-Packard. Оба коммутатора SmartSwitch фирмы Cabletron, два представителя семейства Catalyst компании Cisco и Accelar 1200 корпорации Nortel реагировали на кадры PAUSE, но сами не генерировали их, что допускается стандартом. Устройства BigIron 4000 фирмы Foundry и ProCurve Routing Switch 9304M компании Hewlett-Packard (в действительности, последнее из них является «четырехтысячником» от Foundry, только продаваемым HP под собственной торговой маркой) не только не инициализировали сообщений о приостановке передачи, но и не реагировали на них. Несмотря на отсутствие поддержки стандарта 802.3x в многоуровневом коммутаторе 8371, компания IBM намерена реализовать средства управления потоком в следующей версии, которая появится на рынке в конце года.

Тест 3. IP-маршрутизация

Описание: пара устройств должна была продемонстрировать безошибочную маршрутизацию трафика TCP/IP.

Степень сложности: низкая.

Участники: только коммутаторы третьего уровня.

Результаты: тест успешно прошли все устройства.

Представители компаний-поставщиков настроили каждый из коммутаторов третьего уровня на статическую маршрутизацию или выполнение функций шлюза (принятых по умолчанию), после чего мы объединили устройства в пары. Требовалось, чтобы коммутаторы «общались» друг с другом через две разные IP-сети (одна играла роль опорной, а другая — частной) с использованием протокола TCP/IP.

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

Тест 4. Поддержка RIP

Описание: два коммутатора должны были обмениваться содержимым таблиц маршрутизации IP-пакетов в соответствии с протоколом Routing Information Protocol (RIP) версии 1.0 (обязательно) и 2.0 (факультативно).

Степень сложности: низкая.

Участники: коммутаторы третьего уровня.

Результаты: тест успешно прошли все устройства.

При проверке совместимости на уровне протокола RIP версий 1.0 и 2.0 нам пришлось отказаться от статической маршрутизации. Коммутаторы могли формировать динамические таблицы маршрутизации, основываясь на служебной информации, которой они обменивались по протоколу RIP. Наши требования сводились к корректному обновлению таблиц маршрутизации с учетом сведений, поступавших из удаленных сетевых сегментов, и к наличию связи по TCP/IP между двумя конечными станциями, на которых было запущено приложение Chariot фирмы Ganymede Software.

Тест 5. IPX-маршрутизация

Описание: пара устройств должна была продемонстрировать безошибочную маршрутизацию трафика IPX.

Степень сложности: низкая.

Участники: коммутаторы третьего уровня (кроме BigIron 4000 и ProCurve Routing Switch 9304M).

Результаты: тест успешно прошли все устройства.

Как и в тесте на IP-маршрутизацию, требовалось, чтобы два коммутатора, настроенных на статическую маршрутизацию или на выполнение функций шлюза, могли взаимодействовать через две различные сети. Только на этот раз и в опорной, и в частной сети использовался протокол IPX. Нам пришлось исключить из испытаний указанные выше устройства, поскольку они не поддерживают статическую маршрутизацию IPX-трафика.

Тест 6. Поддержка IPX RIP

Описание: два коммутатора должны были обмениваться содержимым таблиц маршрутизации в соответствии с протоколом IPX RIP.

Степень сложности: низкая.

Участники: коммутаторы третьего уровня.

Результаты: тест успешно прошли все устройства.

От связанных попарно коммутаторов третьего уровня требовалось, чтобы они обменивались данными через базовую и частную сети IPX. По аналогии с четвертым тестом, этим устройствам предстояло самостоятельно сформировать динамические таблицы маршрутизации, используя сведения, полученные средствами протокола RIP. Мы проверяли корректность обновления таблиц маршрутизации с учетом информации, поступавшей из удаленных сетевых сегментов, и наличие связи по протоколу IPX между двумя конечными станциями, на которых работало все то же приложение Chariot фирмы Ganymede Software.

Тест 7. Агрегация соединений

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

Степень сложности: средняя.

Участники: все устройства за исключением 8275-416 Ethernet Switch производства IBM.

Результаты: тест успешно прошли все коммутаторы.

Каждый из производителей, предоставивших свои продукты для испытаний, создал собственный алгоритм, позволяющий объединить несколько двухточечных соединений в один логический канал с большей пропускной способностью. Fast EtherChannel фирмы Cisco, OpenTrunk корпорации Lucent и SmartTRUNK компании Cabletron — вот лишь несколько примеров подобных разработок. Из-за различия реализаций нам пришлось отказаться от тестирования продуктов на соответствие какой-либо одной спецификации — например, пока не утвержденному стандарту IEEE 802.3ad Link Aggregation Protocol. Тем не менее мы хотели получить доказательства того, что патентованные решения в области агрегации соединений не конфликтуют друг с другом в гетерогенной сети.

Мы объединяли коммутаторы в пары при помощи агрегированного канала, состоявшего из двух дуплексных соединений Fast Ethernet. Устройства SmartBits позволяли сгенерировать два потока пакетов (размером 1518 байт), которые поступали на два неагрегированных входных порта на каждом из коммутаторов. Затем пара устройств должна была пересылать друг другу трафик по агрегированному каналу со скоростью, превышающей пропускную способность одиночного соединения, т.е. в каждом направлении данные передавались со скоростью, большей 100 Мбит/с.

Коммутатор 8275-416 Ethernet Switch корпорации IBM не испытывался, поскольку он не поддерживает агрегации соединений.

Тест 8. Восстановление работоспособности

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

Степень сложности: высокая.

Участники: Catalyst 2948G компании Cisco Systems и Accelar 1200 корпорации Nortel Networks.

Результаты: эти устройства успешно прошли тест.

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

Поскольку типичное время восстановления по алгоритму Spanning Tree не превышает 30 с, нас интересовала возможность более оперативного изменения маршрута передачи данных и обеспечения меньших времен восстановления — в пределах 3 с. Однако в этой области производители, кажется, еще не чувствуют себя столь же уверенно, как в сфере агрегации соединений, и наш вызов приняли только Cisco и Nortel. Мы взяли по два устройства Catalyst 2948G и Accelar 1200, построив частично связанную сеть: каждый коммутатор фирмы Cisco был связан с обоими устройствами Nortel, и наоборот, так что в итоге образовалось четыре «перекрестных» соединения. Затем мы разорвали соединения, связывавшие коммутаторы одного производителя и, выдав команду ping, оценили время, за которое был восстановлен процесс передачи трафика: оно оказалось меньше 3 с.

Тест 9. Поддержка VRRP

Описание: в каждой паре устройства при отказе основного маршрутизатора резервный должен был переключить на себя обработку трафика, используя протокол Virtual Router Redundancy Protocol (VRRP). Степень сложности: средняя. Участники: все коммутаторы третьего уровня (кроме Catalyst 8510 производства Cisco Systems). Результаты: тест успешно прошли все устройства.

Исследование маршрутизации в автономном режиме продолжает основную идею предыдущего теста. Протокол VRRP позволяет назначить резервный маршрутизатор, который автоматически «вступает в игру» сразу же после отказа основного. Это устройство должно в полном объеме взять на себя функции неисправного узла, в частности обработку IP-трафика, который станции-клиенты отправляют на отказавший маршрутизатор. Автоматический перехват полномочий освобождает администратора от необходимости вручную перенастраивать клиентские станции на взаимодействие с резервным оборудованием.

Как и в тесте на восстановление передачи, мы формировали частично связанную сетевую топологию, задействуя по два коммутатора одной фирмы, а затем намеренно разрывали соединение с одним из них. Успешное прохождение теста означало, что оставшиеся устройства восстановили работоспособность сети, взяв на себя обработку трафика тех клиентских станций, которые ранее обслуживались отказавшим маршрутизатором. Оборудование Cisco не участвовало в испытании, поскольку вместо стандартного VRRP оно использует протокол Hot Standby Routing Protocol собственной разработки компании.

Тест 10. Восходящее соединение Gigabit Ethernet

Описание: два коммутатора должны были взаимодействовать через единственное высокоскоростное дуплексное соединение Gigabit Ethernet (1000Base-SX).

Степень сложности: низкая.

Участники: все устройства за исключением коммутаторов фирмы IBM.

Результаты: тест успешно прошли все устройства.

Этот тест представлял собой еще одну нетрадиционную домашнюю заготовку, которая, впрочем, не смутила участников испытаний. Мы объявили его необязательным только потому, что не все предоставленные в наше распоряжение устройства были оборудованы гигабитным портом: его не оказалось у обоих коммутаторов фирмы IBM. Однако остальные десять моделей успешно взаимодействовали друг с другом по единственному соединению Gigabit Ethernet, обмениваясь данными в дуплексном режиме.

Обратная связь с помощью управления потоком

Механизм управления потоком был создан в целях контроля за потоком данных, передаваемых между двумя сетевыми устройствами по дуплексному соединению Ethernet. Этот механизм позволяет узлу, оказавшемуся в состоянии перегрузки (на «макроскопическом уровне» — из-за ошибки в распределении системных ресурсов или на «микроскопическом» — в связи с избыточными объемами трафика, поступающего на отдельные порты), отправить устройству на противоположном конце соединения так называемое сообщение о приостановке передачи (pause message). В результате передающее устройство временно уменьшает объем передаваемых данных. В противном случае возникает переполнение буферов, данные начинают теряться, а это требует их повторной передачи, что приводит к еще большей перегрузке сети.

Затевая исследование способности коммутаторов к взаимодействию, мы полагали, что тест на управление потоком не вызовет особых затруднений. В самом деле, соответствующие функции описаны в стандарте 802.3x института IEEE, относящемся к сетям Fast Ethernet и Gigabit Ethernet. Однако указанный стандарт требует лишь, чтобы поддерживающее его сетевое устройство реагировало на сообщение о приостановке передачи, но не предписывает выдавать подобные сообщения. Сознательно создав перегрузку на одном из портов, мы хотели проверить, какие из тестировавшихся коммутаторов способны отсылать и принимать такие сообщения, а также должным образом реагировать на них.

По правде говоря, мы услышали от производителей множество заявлений по этому поводу, особенно в связи с тем, что далеко не во всех устройствах реализован полный набор операций с сообщениями о приостановке передачи. Так, коммутаторы, поддерживающие симметричное управление потоком, в состоянии отправлять и принимать соответствующие пакеты, а ориентированные на асимметричное управление — только отправлять или только принимать их. Тем не менее мы не отказались от наших намерений, пообещав производителям, что они смогут обнародовать свои взгляды на управление потоком (см. электронную версию статьи на сервере www.networld.ru). Тогда большинство фирм поспешило заявить, что поддержка упомянутого стандарта реализована в их устройствах именно как реакция на поступающие сообщения о приостановке передачи. Однако наши тесты показали, что и такая реакция бывает разной.

Прежде всего, производители устанавливают различные пороговые значения интенсивности трафика, при превышении которых генерируются сообщения о приостановке передачи. Например, коммутаторы производства Cabletron и Foundry Networks начинают выдавать такие сообщения лишь при очень высокой нагрузке на устройства и острой нехватке вычислительных ресурсов, мы же создавали перегрузку только на одном порте и не пытались «насытить» данными весь коммутатор. В ходе тестирования указанных продуктов нам так и не удалось добиться генерации сообщений о приостановке передачи. Комментируя этот факт, представители Cabletron и Foundry поспешили заверить нас, что в действительности причиной тому — недостаточная нагрузка.

Как утверждают сотрудники Hewlett-Packard, лучший способ избежать перегрузок в сети — использовать средства управления качеством сервиса (QoS), причем специалисты из Cabetron и Nortel добавляют, что средства QoS не могут работать корректно, если коммутатор отправляет сообщения о приостановке передачи. Граничные коммутаторы фирмы Cisco не генерируют подобных сообщений по другой причине: чтобы периферийное устройство не снижало пропускной способности сетевых магистралей. Кроме того, представители Cisco и Nortel обратили наше внимание на то, что сообщения о приостановке в принципе могут вызвать блокировку на передающем конце соединения.

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

Грег Килмартин, Скотт Хамильтон

Поделитесь материалом с коллегами и друзьями