Span порт коммутатора что это

Обновлено: 09.01.2025

RSPAN (Remote Switched Port ANalyzer) - предоставляет возможность использовать в качестве источника и назначения трафика зеркала интерфейсы, находящиеся на разных коммутаторах, а также отправлять трафик зеркала в несколько интерфейсов на одном коммутаторе. Функционал использует такие понятия как reflector port и remote-span VLAN.

Remote-span VLAN, это та VLAN, в которую будет отправляться зеркалируемый трафик в порту назначения зеркала. Эта VLAN может быть назначена в режиме trunk одновременно с другими пользовательскими VLAN. Изучение MAC-адресов в remote-span VLAN отключено. Remote-span VLAN также может быть использован для передачи трафика из зеркала через несколько промежуточных коммутаторов - для этого потребуется пробросить remote-span VLAN по пути к порту мониторинга.

Reflector port используется в качестве порта назначения зеркала и имитирует прием трафика из зеркала. Если существует потребность использовать несколько портов назначения зеркала, этого можно достичь, назначив Remote-span VLAN на Reflector port и на все те порты, в которые требуется передать трафик - он будет продублирован во все эти порты.

2.2. Конфигурация RSPAN

Назначить VLAN в качестве remote VLAN;
Выбрать порт (CPU) в качестве источника зеркала;
Выбрать порт в качестве назначения зеркала;
Выбрать reflector порт;
Задать remote VLAN для мониторинговой сессии.

Команда

Описание

! В режиме конфигурации VLAN

Назначить VLAN в качестве remote-span VLAN. Команда no удаляет эту конфигурацию.

2. Выбрать порт (CPU) в качестве источника зеркала:

Команда

Описание

no monitor session <session> source

! В режиме глобальной конфигурации

Задать интерфейс или CPU в качестве источника трафика зеркала для сессии <session>. указывают направление трафика. Команда no удаляет источник трафика для сессии <session>.

3. Выбрать порт в качестве назначения зеркала:

Команда

Описание

monitor session <session> destination interface <interface-number>

no monitor session <session> destination interface <interface-number>

! В режиме глобальной конфигурации

Задать интерфейс назначения трафика зеркала для сессии <session>. Команда no удаляет интерфейс назначения для сессии <session>.

4. Выбрать reflector порт:

Команда

Описание

monitor session <session> reflector-port <interface-number>

no monitor session <session> reflector-port

! В режиме глобальной конфигурации

Выбрать интерфейс в качестве reflector порта. Команда no отменяет выбор.

5. Задать remote VLAN для мониторинговой сессии:

Команда

Описание

monitor session <session> remote vlan <vlan_id>

no monitor session <session> remote vlan

! В режиме глобальной конфигурации

Задать для мониторинговой сессии <session> remote VLAN <vlan_id>. Команда no отменяет выбор.

2.3. Пример конфигурации RSPAN

Пример 1

Рисунок 69.1 - RSPAN VLAN

Как показано на рисунке 69.1, сервер мониторинга “Sniffer 1” подключен к коммутатору “Switch B”, а ПК пользователя - к коммутатору “Switch A”. Для диагностики проблем подключения требуется зеркалировать трафик с порта ПК пользователя на сервер мониторинга.

Конфигурация коммутатора Switch A:

Конфигурация коммутатор Switch B:

Пример 2

Серверы мониторинга “Sniffer 1” и “Sniffer 2” а также ПК пользователя подключены к коммутатору “Switch A” к портам к портам 1/0/8, 1/0/9 и 1/0/1 соответственно. Порт 1/0/7 на коммутаторе не занят. Для мониторинга требуется зеркалировать трафик с порта ПК пользователя одновременно на оба сервера.

Мы уже кратко упоминали о технологии SPAN (Switched Port Analyzer) в предыдущих частях серии. Но есть очень много моментов, о которых нужно помнить, и поэтому давайте рассмотрим преимущества и недостатки SPAN подробнее. Также достойна упоминания постоянная битва между сторонниками SPAN и TAP: часть аналитиков будет настаивать на использовании «только ТАР!», другая часть – наоборот.

Порты SPAN
Я уже говорил это раньше и, наверное, буду повторять ещё несколько раз в следующих статьях: когда вы захватываете трафик, всё сводится к вопросу – «насколько достоверный дамп вам необходим?»
Цель этой статьи – предоставить как можно более полную информацию о практике использования SPAN в реальных задачах анализа трафика, о недостатках и преимуществах этой технологии. Обладая такой информацией, вы и сами будете в состоянии понять, сможет ли SPAN дать вам тот результат, который нужен, в части достоверности.

Повторим основы
Сейчас я немного повторюсь и опишу понятия, которые мы уже рассмотрели в первой части серии. Зачем? Просто потому, что вы, возможно, сразу начали чтение с этой части, без предыдущих. Как вы, скорее всего, уже знаете, SPAN – это функция коммутатора, которая необходима, чтобы получить копию трафика на нужном порту. Не забывайте, что для этого коммутатор должен быть управляемым. То есть, обычный «тупой» коммутатор с 5-16 портами, скорее всего, не имеет такой способности (бывают редкие исключения, когда зеркалирование порта «зашито» в конструкцию изначально).

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

Бывают коммутаторы, у которых мониторный порт продолжает работать параллельно и в обычном режиме (один из таких как раз стоит у нас в офисе – прим. перев.) Это означает, что, наряду с мониторингом, порт участвует в обычном обмене данными. Об этом факте нужно помнить. Особенно это присуще более дешевым коммутаторам, или тем, у которых мониторный порт «железно» зашит изначально. То есть, не забывайте протестировать порт перед «боевым» использованием.

Когда SPAN – хороший
SPAN-порт может быть очень полезным:

Он позволяет получить доступ к трафику, который иначе не так просто увидеть, при этом не нужно ничего покупать дополнительно.
Использование SPAN не требует временного прерывания линка.
SPAN-сессию можно достаточно просто включить/выключитьCLI-командой или через Веб-интерфейс.
SPAN позволяет получить агрегированный доступ к нескольким портам-источникам или даже к целому VLAN’у.

1. Доступ к трафику
Еще раз напомним, без SPAN-порта устройство захвата не увидит трафика, который вам нужен, потому что коммутатор отправляет пакеты напрямую между теми узлами, которые общаются между собой:

Но с помощью SPAN коммутатор создает копии всех пакетов, проходящих через «mirror»-порт, и отправляет их в мониторный порт, куда мы и присоединяем анализатор трафика:

Рис.3 -Веб-интерфейс SOHO-коммутатора НР

Кстати. Есть некоторые самые старые коммутаторы, которые, несмотря на то, что управляемые, не имеют функции SPAN. Последний такой я видел в одном из немецких госпиталей несколько лет назад, там до сих пор в работе коммутаторы 3COM Superstack. Если вдруг вы увидите где-нибудь подобный коммутатор, сделайте себе мысленную пометку поменять его вчера (без шуток. Это серьезно).

4. SPAN позволяет получить агрегированный доступ к нескольким источникам
Большинство коммутаторов позволяют указать больше, чем один источник трафика в конфигурации. Это означает, что вы можете мониторить больше одного устройства одновременно на мониторном порту. Профессиональные коммутаторы (я намекаю на те, в которых есть команды “enable” и “config”, а также контракт на обслуживание) также позволяют указать как источник один или несколько VLAN’ов. Постепенно такая возможность появляется и в более дешевом оборудовании (естественно, управляемом).

Зеркалирование VLAN’а означает, что выможете перенаправлять все пакеты, входящие/выходящие в коммутатор, принадлежащие определенному (указанному при настройке) VLAN’у. Несмотря на то, что это звучит очень круто, при такой настройке нужно быть невероятно осторожным. Почему – увидим немножко позже. Ну и также надо помнить, что, указав VLAN как источник, мы, естественно, не увидим ну прямо ВСЕ пакеты, входящие в данный VLAN, но только те, которые проходят через наш настроенный коммутатор. Всё же это не магический инструмент, уж простите.

Если вы захотите, вы можете настроить коммутатор так, чтобы он зеркалировал все порты или VLAN’ы в один мониторный порт – многие неопытные пользователи (а временами и админы) считают, что это хороший способ «мониторить все, что происходит в сети». Но нет. В самом деле, эта идея не так уж хороша, скоро увидим почему (ключевое понятие – «бутылочное горлышко»).

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

Недостаточная полоса пропускания мониторного порта.
Излишняя нагрузка на ЦП коммутатора.
Недостаточная достоверность.

1. Недостаточная полоса пропускания мониторного порта

Недостаток полосы пропускания (Bandwidth bottleneck) – частая проблема со SPAN. Даже если вы мониторите всего лишь один порт, который имеет ту же скорость, что и мониторный порт. То есть, создаете сессию 1 Гбит/с -> 1 Гбит/с. Причина в том же, о чем я уже упоминал в статье о сетевых картах: настоящая комбинированная скорость 1-гигабитного порта – 2 Гбит/с (1 Гбит/с на прием и столько же на отдачу). Мониторный же порт использует только свою полосу на отдачу (в сторону анализатора). В худшем случае это значит, что 2 Гбит/с нужно будет впихнуть в 1 Гбит/с – линк. Теперь представьте, что будет с таким интенсивным трафиком (в 2 раза больше максимальной пропускной способности)? Наверное, что-то типа этого:

Ответ: коммутатор начнет дропать пакеты. И это также значит, что анализатор увидит не весь трафик, и ведь он даже не будет знать, что пакеты где-то были отброшены (это случилось перед сетевой картой, она даже не будет подозревать, что пакетов изначально-то было больше). У коммутатора нет никакого способа сообщить: «мне пришлось тут выкинуть часть трафика!»
Итак, создание SPAN-сессии, если вы знаете, что у порта-источника высокая нагрузка – не такая уж хорошая идея. А может быть и ещё хуже – попытка зеркалировать источник в 10 Гбит/с на порт 1 Гбит/с. В итоге вы скорее всего получите дамп трафика, подобный такому:

Скорее всего, вы будете видеть много пакетов с предупреждением “ТСР ACKed unseen segment”. Оно создается автоматически экспертной системой Wireshark в случае, когда большие пакеты с полезной нагрузкой теряются по пути, а мелкие АСК-пакеты оказываются достаточно юркими, чтобы проскочить-таки к анализатору через «бутылочное горлышко».

Ситуация стремительно усугубляется, если вы добавляете больше портов-источников или целые VLAN’ы к SPAN-сессии. Представим на секунду, что у вас есть хост с виртуальными машинами, который соединен с коммутатором четырьмя гигабитными портами. Виртуальные машины могут использовать любой из этих портов в соответствии с правилами балансировки трафика. Поэтому, лучше, конечно, зеркалировать все 4 – ведь вы не знаете, куда направится трафик в определенную секунду. И получается, что мы создаем SPAN-сессию, у которой на входе 4 потенциально загруженных гигабитных порта «падают» на 1 гигабитный мониторный порт. В наихудшем случае 8 Гбит/с попытается уместиться в 1 Гбит/с. К чему это приведет? 7 из 8 пакетов отбросятся на коммутаторе. Конечно, это уж очень далеко от приемлемой достоверности дампа.

2. Излишняя нагрузка на ЦП коммутатора

Следующий момент при использовании SPAN – дополнительная нагрузка на ЦП коммутатора. Естественно, это будет зависеть от конкретной модели коммутатора. Как правило, коммутаторы пересылают пакеты между «боевыми» портами с использованием специализированных «железных» цепей даже без участия ЦП как такового. При использовании SPAN ситуация может в корне измениться. ЦП задействуется в процессе зеркалирования, и, как итог, добавление портов к сессии может вызвать следующие эффекты:

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

3. Недостаточная достоверность

Теперь к наибольшей проблеме. В некоторых ситуациях использование SPAN дает недостаточную достоверность дампа. Эти ситуации таковы:

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

Подведем итоги
SPAN – это очень полезная технология, и сейчас это наиболее распространенный способ получения трафика для анализа. Но не стоит забывать о некоторых моментах. Даже принимая во внимание то, что точность при захвате со SPAN-порта меньше, чем при использовании ТАР, часто предпочитается именно SPAN. Суммируя все преимущества: легко запустить, легко выключить обратно, не требуется прерывание линка. Можно просто сказать: «ведь это удобно!»

Краткие рекомендации

Не опасайтесь использовать SPAN, если достоверность результатов вас устраивает (смотрите список ниже, где это не так). Отсутствие необходимости разрывать линк, для установки ТАР – это уже очень немало.
Знаете поговорку «семь раз отмерь, один отрежь»? Она подойдет и тут. Определите порты источника и назначения дважды. Запишите их. Потом конфигурируйте. Бонус: дважды проверьте, что команда конфигурации совпадает с тем, что вы записали. 75% проблем со SPAN-сессиями оказываются вызваны тем, что кто-то неправильно указал порт-источник и порт назначения. А ведь это может «положить» всю вашу сеть. Испугались? Хорошо. «Семь раз отмерьте» и всё будет нормально.
Отслеживайте загрузку ЦП, когда добавляете порты источника. Старайтесь оставаться в пределах 50%, никогда не превышайте 75%. Конечно же, это зависит от текущей загрузки коммутатора. Но помните: если вы все же доведете коммутатор, он озадачит вас далеко не самыми легкими и предсказуемыми проблемами.
Захватите трафик в течение нескольких секунд, и проверьте, правда ли это именно то, что вам нужно (диапазоны IP, VLAN’ы и т.д.) – потому что запустить захват на неделю, а потом, придя за результатом, увидеть, что вы указали не тот порт источника – вот что по-настоящему печально.
Поглядывайте на тикеты, которые приходят, пока SPAN-сессия активна, и удостоверьтесь, что сама сессия не является причиной сбоев сети. Это бывает редко, но всё же случается.
Если подумываете об использовании SPAN в forensics-задачах, при анализе проникновения – не забывайте, что взломать можно и коммутатор со SPAN, скрыв от вас трафик.
Избегайте использования RSPAN и ЕRSPAN всеми силами – дополнительный транспорт исказит тайминги и порядок пакетов и в худшем случае приведет к неверным выводам вашего анализа.
Отключите SPAN, когда закончите работу, иначе порт останется недоступен для обычной передачи трафика.

Ну и, наконец, список ситуаций, для которых SPAN не подойдет (но, конечно же, никто вам не запретит попробовать его и тут):

Поиск устройства, которое является причиной потерь пакетов.
Определение максимально точных таймингов, особенно при задержках менее 50 мс.
Неоспоримое доказательство того, что пакет действительно был передан в сегмент сети.
Слишком большая загрузка источника, которую мониторный порт не потянет.
Расследования, forensics – ситуации, где вы не можете себе позволить потерять ни один пакет (потому что потом надо извлекать из них и анализировать полезную нагрузку).

Выбирайте стратегию захвата с осторожностью, ведь качество анализа напрямую зависит от качества полученного дампа.
В одной из следующих статей мы рассмотрим ответвители трафика – ТАР.

Для чего эта технология может использоваться?
Ну в первую очередь, например для того, чтоб просмотреть трафик на каком-то порту, для анализа того, что передается в сети (вдруг мы что-то забыли настроить и там рассылается то, что не нужно, ну и т.п.).
Так же может понадобиться например для записи VOIP. Берем VLAN Voice переправляем весь трафик на определенный интерфейс, ну а там ПО, записывает все разговоры.
Еще одной из причин использовать зеракалирование трафика, например для систем IPS/IDS.

Судя по примерам, достаточно приятная и полезная функция, не так ли?
Теперь более подробно поговорим об этой технологии.

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

Давайте рассмотрим графически топологию SPAN и RSPAN.

Думаю что комментарии к этим топологиям излишни. Я уже описал все выше.

Базовые знания о SPAN и RSPAN.

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

Создать список источников, то есть откуда мы будем брать трафик для анализа или других целей. Здесь можно указывать порты (как минимум 1), или VLAN (минимум 1, можно больше).
Указать куда доставлять данные с списков источников, описанных в первом пункте. То есть куда будет зеркалироваться трафик (например, порт f0/24).

Хочется отметить, что источниками трафика могут быть layer 2 порты: access port, trunk port, etherchannel; layer 3 (routed port) и так далее. Если Source указан как VLAN , то будет зеркалироваться трафик всех портов, которые включены в данный VLAN и в настоящее время активны. Можно включать или удалять из VLAN порты, и это сразу будет влиять на SPAN/RSPAN.

Перед тем как перейти к практике, давайте поговорим об ограничениях и некоторых условиях, связанных с SPAN/RSPAN.

Порт приемника зеркалированного трафика имеют ряд ограничений, такие как:

При настройке порта назначения (Destination SPAN ) его конфигурация будет перезаписана. При удалении SPAN с порта, конфигурация восстанавливается.
При настройке Destination SPAN порта, который находится в Etherchannel, он будет удален из него. Если порт был routed (L3), то будет переписаны настройки этого порта.
Destination port SPAN не поддерживает : port security, 802.1x аутентификацию, private VLAN.
Destination Port SPAN не поддерживает Layer 2 протоколы, такие как: CDP, Spanning Tree, VTP,DTP и другие.

Это то, что касалось ограничений, теперь давайте поговорим о условиях.

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

По умолчанию Layer 2 фреймы, такие как CDP, spanning tree, BPDU, VTP,DTP и PagP игнорируются и не передаются на Destination Port, но можно настроить устройство так, чтоб эти фреймы передавались. Для этого необходимо использовать команду encapsulation replicate.

В этой статье мы освоили теоретическую часть. В следующей статьей будем заниматься практикой SPAN/RSPAN.

На многих коммутаторах cisco реализованы технологии SPAN и RSPAN позволяющие зеркалировать траффик с порта на порт или с vlan на порт удаленного коммутатора и т.п.

Port mirroring (Зеркалиирование порта) — процесс копирования пакетов с порта на другой порт в пределах одного или нескольких коммутаторов.

Настройка SPAN на cisco

SPAN (Switch Port Analyzer) - Локальное зеркалирование используется для копирования траффика с порта или vlan на другой порт этого же коммутатора.

Зеркалирование траффика с порта на порт

Gi0/X - порт с которого будем зеркалировать траффик.

Gi0/Y - порт на который будем зеркалировать траффик.

Для зеркалирования только входящего трафиика добавляем в "rx".

Для зеркалирования только исходящего трафиика добавляем "tx".

Можно зеркалировать траффик с нескольких портов

Gi0/X1..Gi0/Xn - порты с которых будем зеркалировать траффик.

Gi0/Y - порт на который будем зеркалировать траффик.

Таким образом через SPAN VLAN можно передавать зеркалированный траффик между портами одного коммутатора.

Для зеркалирования траффика с vlan на порт указываем не интерфейс а влан.

vlan 100 - номер vlan с которого будем зеркалировать траффик.

Gi0/Y - порт на который будем зеркалировать траффик.

Таким образом через SPAN VLAN можно передавать зеркалированный траффик определенной VLAN на порт коммутатора.

Настройка RSPAN на cisco

RSPAN (Remote Switch Port Analyzer) - Удаленное зеркалирование используется для копирования траффика с порта или vlan на порт удаленного коммутатора.

Рассмотрим пример работы RSPAN. Допустим у нас есть 2 коммутатора (SW1 и SW2) соединеных между собой транковыми портами. Нам требуется передать зеркальный траффик VLAN 50 с коммутатора SW1 на порт Gi0/1 коммутатора SW2 используя RSPAN VLAN 100.

1. Создаем RSPAN VLAN 100 на коммутаторах (SW1 и SW2) в котором будем передавать траффик.

2. Создаем сессию мониторинга на коммутаторе SW1

vlan 50 - номер vlan который будем зеркалировать

Gi0/1 - номер порта в который будет сливаться весь зеркальный траффик.

Таким образом через RSPAN VLAN можно передавать зеркалированный траффик между двумя коммутаторами.

Команды диагностики SPAN и RSPAN

На последок приведу несколько команд для диагностики настроеных monitor session.

Читайте также: