Большинство управляемых коммутаторов позволяют конфигурировать несколько портов для мониторинга, а функция зеркалирования — копировать трафик с выбранного порта/портов на порт для мониторинга (см. Рисунок 1). Эта методика называется замещением (aliasing), зеркалированием (mirroring) или спаннингом (spanning) портов. Последний термин происходит от словосочетания Switched Port Analyzer (SPAN), т.е. анализатор коммутируемых портов.

Рисунок 1. Настройка зеркального порта для мониторинга.

КОНФИГУРИРОВАНИЕ ЗЕРКАЛЬНОГО ПОРТА

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

У разных производителей и моделей коммутаторов свой набор функций мониторинга, однако основные, как правило, одинаковы: трафик с выбранного порта копируется и направляется на порт мониторинга для анализа (см. Рисунок 2). Веркальный порт часто работает только в режиме вывода, хотя некоторые производители допускают настройку на двусторонний режим (ввод/вывод). При подключении к такому порту устройству для мониторинга будет доступен весь текущий трафик между пользователем, испытывающим проблемы с соединением, и сервером. Источником зеркалируемого трафика может быть любой другой порт на коммутаторе, включая предназначенный для каскадирования, несколько портов и даже одна или несколько виртуальных сетей VLAN.

Плюсы. Зеркалирование порта – один из самых распространенных и эффективных методов диагностирования в коммутируемых сетях. Он позволяет устройству мониторинга «видеть» весь проходящий через коммутатор трафик, которым обмениваются несколько станций. Чаще всего данный метод используется в сочетании с анализатором протоколов.

Минусы. Реализация этой технологии зависит от производителя коммутатора, однако у них есть ряд общих черт. Практически всегда при пересылке пакетов на порт мониторинга осуществляется фильтрация данных. На порту мониторинга ошибки не будут видны, поскольку коммутатор их фильтрует. Как результат, при диагностике зеркалирование порта иногда оказывается бесполезным: коммутатор фактически скрывает информацию о целом классе сетевых проблем.

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

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

ИЗБЫТОЧНАЯ ПОДПИСКА

Максимальная пропускная способность порта мониторинга при выводе данных должна обязательно приниматься во внимание. Порт вывода имеет два пути – TX (передача) и RX (прием). Как уже отмечалось, маршрут TX (от тестера к сети) на порту для мониторинга может принудительно блокироваться коммутатором в соответствии с настройками зеркалирования. Заблокирован он или нет (то есть работает ли порт в одностороннем или двустороннем режиме) – все равно, емкость пути RX (к устройству мониторинга) ограничена. Если вы зеркалируете полнодуплексный порт с такой же скоростью, что и у зеркального порта вывода, то коммутатор будет отбрасывать часть трафика, даже не извещая об этом. В таком случае неважно, каковы настройки дуплексного режима у устройства для мониторинга – полудуплекс или полный дуплекс – все равно ограничение на пропускную способность маршрута к устройству остается тем же.

На Рисунке 3 показано, как трафик, передаваемый в сети между сервером и коммутатором в полнодуплексном режиме со скоростью 100 Мбит/с, зеркалируется на порт мониторинга. При полном дуплексе оба направления – и прием RX, и передача TX – способны поддерживать трафик со скоростью 100 Мбит/с, то есть суммарная пропускная способность составляет 200 Мбит/с. Если вы будете зеркалировать трафик на другой порт 100 Мбит/с, то сможете использовать только путь TX от коммутатора к устройству мониторинга. В этом примере объем зеркалируемого трафика ограничен 100 Мбит/с. У коммутатора есть небольшой буфер (его приходится использовать из-за неравномерного характера трафика), но та часть трафика, проходящего через серверный порт коммутатора, которая превышает 50% совокупной емкости отслеживаемого полнодуплексного порта, скорее всего, будет потеряна.

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

Остроту проблемы можно снять, если подключить устройство мониторинга к более скоростному порту, способному осуществить вывод всего зеркалируемого трафика. Если бы зеркальный порт на Рисунке 3 имел пропускную способность не 100 Мбит/с, а 1 Гбит/с, то он был бы в состоянии принять совокупный трафик 200 Мбит/с.

ПРОДВИЖЕНИЕ ПАКЕТОВ

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

Большинство современных коммутаторов по умолчанию настроены на применение технологии продвижения пакетов с промежуточной буферизацией (Store and Forward), а порой только для этого и предназначены. Тем не менее, многие из ранее установленных коммутаторов могут допускать (или быть настроенными по умолчанию) методы продвижения с малой задержкой. Определить, какой метод продвижения пакетов используется, не так-то просто: для этого придется изучать документацию, а иногда не обойтись и без тестирования.

Наиболее часто употребляются три метода продвижения пакетов (названия иногда варьируются):

  • продвижение пакетов с промежуточной буферизацией (Store and Forward) — традиционная технология для моста на втором уровне модели OSI;
  • сквозная пересылка (Cut-Through) — пересылка начинается сразу после прочтения MAC-адреса;
  • модифицированная сквозная пересылка (Modified Cut-Through) — пересылка после получения 64 байт, что соответствует концепции синхронизации по временным слотам для полудуплексного режима Ethernet на 10/100 Мбит/с; она представляет собой отсечку для интервала времени, когда возможно обнаружение допустимой коллизии.

Оба метода продвижения с малой задержкой стали терять популярность уже после нескольких лет использования — возможно, по причине того, что сравнительно небольшое увеличение производительности достигалось ценой усложения диагностики, характерного для методов с малым временем задержки. Вдобавок существовала и комбинированная методика — метод детектирования ошибок (Error Sensing), или адаптивная технология (Adaptive). В этом случае, пока уровень ошибок не превышал установленный или задаваемый пороговый уровень, использовался один из методов с малой задержкой, а затем происходило переключение на продвижение пакетов с промежуточной буферизацией. Однако определить, исчезла ли ошибка и насколько она серьезна, было непросто, если не сказать невозможно. Ситуация становится еще запутаннее, если речь идет о нерегулярной ошибке, которая то появляется, то исчезает.

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

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

Зеркальный порт вывода на втором уровне модели OSI будет использовать те же методы продвижения пакетов, что и все остальные порты в коммутаторе. Ошибки MAC-уровня практически никогда не направляются на зеркальный порт.

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

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

ПОДКЛЮЧЕНИЕ К ТЕГИРОВАННОМУ ИЛИ ТРАНКОВОМУ ПОРТУ

Тестер можно подключить к транковому порту VLAN или к порту, который относится к одной или нескольким виртуальным локальным сетям (см. Рисунок 5). Этот подход похож на метод использования зеркального порта, все плюсы и минусы остаются теми же. Кроме того, необходимо удостовериться, что тестер в состоянии интерпретировать тег или теги виртуальных сетей VLAN и/или распределить их по широковещательным доменам – иначе вы не получите ясную картину сети. Если тестер подключен к транковому порту, возможно, ему потребуется участвовать в трафике управления транком — например, по протоколу Cisco VTP.

Рисунок 5. Подключение к тегированному или транковому порту VLAN.

Трафик, наблюдаемый на тегированном или транковом порту, может быть разным. Вот некоторые возможные варианты:

  • коммутатор направляет на порт только тегированный трафик виртуальной сети VLAN. Станции, не относящиеся к этой сети, не смогут использовать подключенные сетевые ресурсы;
  • коммутатор поддерживает на порту как тегированный, так и нетегированный трафик, обеспечивая работу и транков виртуальной сети VLAN, и локальных нетегированных станций. Часто изначальная виртуальная сеть VLAN на транковом порту не тегируется;
  • коммутатор выводит на порт тегированный трафик от нескольких виртуальных сетей VLAN. При такой конфигурации к порту подключаются обычно не конечные рабочие станции, а сервер, поскольку он может поддерживать несколько виртуальных сетей VLAN для одного соединения.

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

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

ПОДКЛЮЧЕНИЕ КОНЦЕНТРАТОРА К СЕГМЕНТУ

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

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

Рисунок 6. Установка концентратора между рабочей станцией и портом коммутатора.

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

Плюсы. Для изучения трафика и поиска ошибок полезно использовать протокол SNMP, однако наиболее эффективный способ — непосредственное подключение диагностического прибора. Если между портом коммутатора и другим интерфейсом разместить концентратор с разделяемой средой передачи, то устройство для мониторинга можно подключить к тому же самому коллизионному домену. Этот метод позволяет анализатору «видеть» весь имеющийся трафик, доступ к которому существенно облегчает диагностику целого ряда проблем, включая невозможность регистрации в сети, низкую производительность и потерю соединения. Это одна из наиболее благоприятных ситуаций для диагностики сбоев, затрагивающих отдельную станцию, поскольку устройству для мониторинга доступна вся информация.

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

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

Подключение к линии концентратора может привести к трем проблемам:

  • если изначально сегмент работал в полнодуплексном режием, то включение концентратора вызывает дополнительную проблему, поскольку он поддерживает только полудуплексный режим;
  • если подключенный «концентратор» на самом деле оказался мостом (частично или полностью), то вы ничего не добились;
  • если к сегменту уже были подключены один или более концентраторов, т.е. архитектура Ethernet перестала быть легальной, то вы спровоцируете дополнительные коллизии.

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

Отдельные программные анализаторы протоколов задействуют расширенные возможности некоторых сетевых карт, благодаря чему им все-таки оказывается доступна часть трафика с ошибками. Но чтобы выявить все ошибки в коллизионном домене, необходим аппаратный анализатор протоколов или другое устройство со специально разработанными печатными платами, работающими на физическом уровне (Ethernet PHY – часть схемных плат, отвечающая за преобразование двоичных данных в корректные сигналы в расчете на конкретную среду передачи).

АРХИТЕКТУРНЫЕ ОГРАНИЧЕНИЯ ДЛЯ КОНЦЕНТРАТОРОВ

Использование концентраторов ограничивается следующими условиями:

  • в сетях Ethernet на 10 Мбит/с между двумя персональными компьютерами можно последовательно установить до четырех концентраторов;
  • в сетях Ethernet на 100 Мбит/с между двумя персональными компьютерами можно последовательно установить один или два концентратора;
    - в коллизионном домене допускается только один концентратор Класса I (маркированный или немаркированный как таковой);
    - в коллизионном домене разрешено устанавливать один или два концентратора Класса II (обычно они маркируются);
  • в сетях Ethernet на 1000 Мбит/с в коллизионном домене можно использовать только один концентратор, однако приобрести такое оборудование вряд ли удастся. В настоящее время концентраторы с разделяемой средой передачи для Gigabit Ethernet не производятся;
  • в сетях Ethernet на 10 000 Мбит/с (10 Gigabit Ethernet) полудуплексный режим передачи не предусматривается, поэтому концентраторов для 10-гигабитного Ethernet не существует в принципе.

АРХИТЕКТУРНЫЕ ОГРАНИЧЕНИЯ КОММУТАТОРОВ

Жестких ограничений по количеству мостов (коммутаторов, работающих на втором уровне модели OSI) нет, причем ни для каскадов коммутаторов, ни для их параллельного подключения. Однако архитектура влияет на характеристики сети, и два наиболее важных момента касаются широковещательных рассылок:

  • если два моста работают параллельно, причем оба пути открыты, то первый же широковещательный пакет, дошедший до любого из них, автоматически вызовет широковещательный шторм. Мосты обязаны направлять все широковещательные пакеты на все порты, кроме порта, с которого они поступили. Второй мост сделает то же, что и первый, и исходный широковещательный пакет вернется на первый порт по параллельному пути. У некоторых коммутаторов есть настройка trust me – доверительный режим, который подразумевает, что вы сами должны следить за тем, чтобы параллельные пути не создавались. В ответ коммутатор предоставляет любому новому соединению практически мгновенный доступ к сети (такова, например, настройка portfast у Cisco);
  • если для исключения параллельных маршрутов применяется протокол связующего дерева или какой-либо другой механизм, то чем больше количество мостов в отдельном широковещательном домене, тем масштабнее будет соответствующий широковещательный трафик. Широковещательные рассылки – полезная и необходимая составляющая работы сети, отказаться от них нельзя. Если в широко-вещательный домен включить слишком много станций, то чрезмерно выросший объем фонового широковещательного трафика приведет к ухудшению работы сети. Каждая станция в широковещательном домене должна обработать каждый широковещательный пакет, и на это время выполнение других задач прерывается. Специальный таймер Max Age для связующего дерева ограничивает максимальные размеры сети, в которой данное дерево применяется.

Игорь Панов — региональный менеджер по продукции и поддержке партнеров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.

Рисунок 2. Логическая схема организации зеркального порта.

Рисунок 3. Зеркальный порт имеет ограниченную пропускную способность для вывода данных.

Рисунок 4: Возможное перенаправление ошибки при продвижении кадров с промежуточной буферизацией (Store and Forward, рисунок слева) и сквозной пересылке с малой задержкой (рисунок справа).