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

Как работает SPAN?

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

Для понимания работы функции SPAN схематично изобразим коммутатор (рисунок 1). На схеме мы оставляем только порты, коммутационную матрицу и буфер коммутационной матрицы. Как же работает коммутатор? На порт приходит пакет и поступает на коммутационную матрицу. Матрица сохраняет пакет в буфер, определяет порт назначения и передаёт в него пакет, освобождая буфер. Буфер коммутационной матрицы представляет собой память, в которую помещается пакет, ожидающий своей обработки.


Рисунок 1
Рисунок 1

Разберемся, как работает функция SPAN (рисунок 4). Для начала надо назначить зеркалируемые порты (все пакеты, поступающие с него или на него, в зависимости от конфигурации, будут копироваться) и порт мониторинга. Как только коммутационная матрица принимает или собирается передать пакет через зеркалируемые порты, она дополнительно передаёт копии пакетов на порт мониторинга. И пока пакет не будет передан на порт мониторинга, он остаётся в буфере.

Стоит отметить, когда пакет приходит на порт коммутатора/маршрутизатора, он проходит проверку целостности, а затем может быть модифицирован (добавление/замена заголовков) или отброшен. В итоге на порт мониторинга придёт не исходный пакет, а модифицированный. Или вовсе не придёт.

Поведение SPAN при нагрузке

Как же будет себя вести коммутатор при различных нагрузках и вариантах использования порта мониторинга? Ведь зеркалируемых портов может быть как один, так и десять, а количество SPAN-портов обычно не превышает 4. Кроме того, меняется загруженность зеркалируемых портов.

Самой важной характеристикой порта мониторинга является пропускная способность: если коммутационная матрица будет подавать на порт мониторинга больше пакетов, чем он сможет передать, то они будут отбрасываться. На графике (рисунок 2) показано зеркалирование трафика с одного порта: пропускной способности порта мониторинга хватает с запасом, чтобы передать все пакеты. Но что будет, если зеркалировать трафик с нескольких портов? Трафика будет в разы больше пропускной способности порта мониторинга (рисунок 3). Пропускной способности порта мониторинга не будет хватать, и часть пакетов будет отбрасываться.

Рисунок 2
Рисунок 2
Рисунок 3
Рисунок 3

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


Рисунок 4
Рисунок 4

Влияние функции SPAN на сеть

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


Рисунок 5
Рисунок 5

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

Потери пакетов при низкой нагрузке на коммутатор

Даже в слабонагруженных сетях трафик передается неравномерно. Сетевые карты накапливают данные для передачи и затем передают их на скорости порта. Так называемые всплески трафика (Burst) вызывают эффект локальных по времени перегрузок портов (рисунок 6). Именно на их сглаживание при совпадении порта назначения закладываются ресурсы буфера в коммутаторе. Но даже в устройстве с 10G портами это единицы мегабайт, а соответственно, единицы миллисекунд превышения пропускной способности по одному порту. Назначая один из портов портом мониторинга, мы гарантируем переполнение буфера и потери, как минимум, зеркалируемых пакетов.

Рисунок 6
Рисунок 6

Заключение

Функция SPAN была придумана уже давно для:

  • Выборочного мониторинга портов при поиске неисправностей и ошибок передачи в сети

  • Обеспечения информационной безопасности на слабонагруженных портах, выходящих за границы периметра

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

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

Комментарии (7)


  1. KGBmen
    23.09.2021 00:58

    Я сталкивался с проблемой даже не SPAN, а RSPAN на устройствах Sg350-10 в связке с ESXi версии то ли 6.5 то ли 6.7. Проблема заключалась в категорическом нежелании esx-ом понимать "зеркальный" VLAN. Но это совсем другая история....


  1. Stranger181
    23.09.2021 10:39

    Оптические делители в помощь))


    1. DSol Автор
      27.09.2021 14:04

      И медные тоже!)


  1. bukoka
    24.09.2021 13:37

    TAP в силу естественных причин имеет определенные преимущества перед SPAN - просто потому что съем трафика осуществляется на L1-уровне и исключает прохождение возможных "узких" мест внутри коммутатора (ASIC\буфера).

    В статье есть "нюансы", которые могут вводить в заблуждение.

    Нюансы:

    1. Фрейм помещается в буфер до момента прохождения коммутационной матрицы - т.е либо буфер "на порту" (выделенный на порт), либо он общий (shared buffer).

    2. "Как только коммутационная матрица принимает или собирается передать пакет через зеркалируемые порты, она дополнительно передаёт копии пакетов на порт мониторинга. И пока пакет не будет передан на порт мониторинга, он остаётся в буфере."

      "Поговорим про реализацию функции SPAN. Как мы уже упоминали, пока пакет не будет передан и на целевой порт, и на порт зеркалирования, он занимает место в буфере пакетов. Зеркалирование нескольких портов (или обоих направлений передачи одного порта) приводит к скапливанию пакетов в очереди на порт мониторинга и заполнению буфера. Некоторые производители ставят самый низкий приоритет для портов мониторинга, иными словами, оборудование под нагрузкой будет выбирать между передачей трафика на обычные порты или порты мониторинга."

    По поводу механизмов репликации - всю жизнь думал, что фрейм передается одновременно на все порты за счет механизмов работы ASIC (поскольку если фрейм попал в ASIC - то легче его "реплицировать" силами ASIC сразу на все порты, нуждающиеся в его передаче). С Вашей подачи можно подумать что и BUM-трафик "ожидает" и занимает место в буфере входного порта (или shared буфере) пока не отправятся все реплики на все порты поочередно? Тогда сети работали бы довольно плохо с любым real-time трафиком by design.

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

    По поводу работы SPAN - тут надо четко понимать какой объем собираемся снимать с его помощью. Очевидно, что порт не пропустит трафика больше, чем его ёмкость. Т.е зеркалится in или out порта такой же ёмкости - то берите 1 к 1. Если зеркалятся несколько портов - то берите большую ёмкость - например на 5 портов 1G (в фулл дуплексе дают 10G) закладывайте один 10G. Тут будут возможны потери фреймов - но только тех, которые были в бёрстах на зеркалируемых портах (вывалились за возможности буферизации порта\общего буфера) - впрочем они терялись бы и так - безотносительно SPAN.

    Опять же, если трафик к Вам приходит уже "порезанный" до какой-то полосы полисером или шейпером, и вы понимаете, какая возможная максимальная ёмкость канала передачи - то можно зеркалить и трафик 5-ти 1G портов на 1G. В таком случае бёрсты в пределах ёмкости будут сглаживаться входными буферами и потерь при SPAN не будет.


    1. DSol Автор
      28.09.2021 17:48
      +1

      Под коммутационной матрицей мы как раз понимаем весь коммутирующий ASIC (иначе необходимо разрисовывать структурную схему чипа и определять, где заканчиваются интерфейсные и вспомогательные блоки, и начинается сама матрица). Основной буфер обычно всё-таки общий, на портах он меньше (есть, конечно, исключения).
      Что касается репликации, то одновременности достичь не удается – разное количество пакетов хочет выйти в разные порты, и на выход образуются очереди. Длины этих очередей разные, поэтому когда в порт обычного обмена пакет уже ушёл, то на порт зеркалирования он ещё стоит в очереди за пакетом, который ушёл в другой свободный порт обычного обмена. И да, BUM-трафик "ожидает" и занимает место в буфере входного порта (или shared буфере), пока не отправятся все реплики на все порты, но не поочередно на каждый порт, а по мере освобождения очередей каждого порта (если другого трафика нет, то получится одновременно). Очень редко кто выделяет 10G порт на SPAN в 1G коммутаторах – если он есть, то его скорее используют для аплинка или стекирования. А порезанный трафик – это всё-таки удел каких-то внешних каналов. Кто же режет трафик у себя в сети? Плюс проблема, что об этом необходимо не только подумать, но и помнить затем. А то шейпер можно перенастроить (расширить внешние каналы), а про архитектурно заложенные ограничения SPAN-порта забыть…


      1. bukoka
        02.10.2021 21:23

        "И да, BUM-трафик "ожидает" и занимает место в буфере входного порта (или shared буфере), пока не отправятся все реплики на все порты, но не поочередно на каждый порт, а по мере освобождения очередей каждого порта (если другого трафика нет, то получится одновременно) "

        Любопытно, а есть какие-то пруфы, которые можно почитать для ознакомления?


        1. DSol Автор
          05.10.2021 14:30

          Да, конечно, можете почитать книгу “Где сохранить пакет”