Комментарии 7
Я сталкивался с проблемой даже не SPAN, а RSPAN на устройствах Sg350-10 в связке с ESXi версии то ли 6.5 то ли 6.7. Проблема заключалась в категорическом нежелании esx-ом понимать "зеркальный" VLAN. Но это совсем другая история....
Оптические делители в помощь))
TAP в силу естественных причин имеет определенные преимущества перед SPAN - просто потому что съем трафика осуществляется на L1-уровне и исключает прохождение возможных "узких" мест внутри коммутатора (ASIC\буфера).
В статье есть "нюансы", которые могут вводить в заблуждение.
Нюансы:
Фрейм помещается в буфер до момента прохождения коммутационной матрицы - т.е либо буфер "на порту" (выделенный на порт), либо он общий (shared buffer).
"
Как только коммутационная матрица принимает или собирается передать пакет через зеркалируемые порты, она дополнительно передаёт копии пакетов на порт мониторинга. И пока пакет не будет передан на порт мониторинга, он остаётся в буфере.""
Поговорим про реализацию функции 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 не будет.
Под коммутационной матрицей мы как раз понимаем весь коммутирующий ASIC (иначе необходимо разрисовывать структурную схему чипа и определять, где заканчиваются интерфейсные и вспомогательные блоки, и начинается сама матрица). Основной буфер обычно всё-таки общий, на портах он меньше (есть, конечно, исключения).
Что касается репликации, то одновременности достичь не удается – разное количество пакетов хочет выйти в разные порты, и на выход образуются очереди. Длины этих очередей разные, поэтому когда в порт обычного обмена пакет уже ушёл, то на порт зеркалирования он ещё стоит в очереди за пакетом, который ушёл в другой свободный порт обычного обмена. И да, BUM-трафик "ожидает" и занимает место в буфере входного порта (или shared буфере), пока не отправятся все реплики на все порты, но не поочередно на каждый порт, а по мере освобождения очередей каждого порта (если другого трафика нет, то получится одновременно). Очень редко кто выделяет 10G порт на SPAN в 1G коммутаторах – если он есть, то его скорее используют для аплинка или стекирования. А порезанный трафик – это всё-таки удел каких-то внешних каналов. Кто же режет трафик у себя в сети? Плюс проблема, что об этом необходимо не только подумать, но и помнить затем. А то шейпер можно перенастроить (расширить внешние каналы), а про архитектурно заложенные ограничения SPAN-порта забыть…
"И да, BUM-трафик "ожидает" и занимает место в буфере входного порта (или shared буфере), пока не отправятся все реплики на все порты, но не поочередно на каждый порт, а по мере освобождения очередей каждого порта (если другого трафика нет, то получится одновременно) "
Любопытно, а есть какие-то пруфы, которые можно почитать для ознакомления?
Да, конечно, можете почитать книгу “Где сохранить пакет”
Проблемы использования SPAN для мониторинга в современной сети