Под коммутационной матрицей мы как раз понимаем весь коммутирующий ASIC (иначе необходимо разрисовывать структурную схему чипа и определять, где заканчиваются интерфейсные и вспомогательные блоки, и начинается сама матрица). Основной буфер обычно всё-таки общий, на портах он меньше (есть, конечно, исключения). Что касается репликации, то одновременности достичь не удается – разное количество пакетов хочет выйти в разные порты, и на выход образуются очереди. Длины этих очередей разные, поэтому когда в порт обычного обмена пакет уже ушёл, то на порт зеркалирования он ещё стоит в очереди за пакетом, который ушёл в другой свободный порт обычного обмена. И да, BUM-трафик "ожидает" и занимает место в буфере входного порта (или shared буфере), пока не отправятся все реплики на все порты, но не поочередно на каждый порт, а по мере освобождения очередей каждого порта (если другого трафика нет, то получится одновременно). Очень редко кто выделяет 10G порт на SPAN в 1G коммутаторах – если он есть, то его скорее используют для аплинка или стекирования. А порезанный трафик – это всё-таки удел каких-то внешних каналов. Кто же режет трафик у себя в сети? Плюс проблема, что об этом необходимо не только подумать, но и помнить затем. А то шейпер можно перенастроить (расширить внешние каналы), а про архитектурно заложенные ограничения SPAN-порта забыть…
Хотя наша компания и занимается, в том числе разработкой микросхем, наши брокеры сетевых пакетов построены на базе готовых интегральных схем. При этом мы используем интегральные микросхемы общего применения и весь функционал обработки пакетов и управления разрабатываем сами. При этом выбор типа ЭКБ позволяет обеспечить гарантию сохранения производительности независимо от задействованных функций.
подробнее, пожалуйста)) ISL - это сисковский аналог vlan, проприетарный, использовался на CatOS. С конца девяностых о нём ничего не слышал (оцените свежесть материала - 20-с-хреном-лет). Сетевой трафик получит высший приоритет от кого?)) для чего?))
Действительно, данный протокол межкоммутационного канала является проприетарным протоколом в коммутаторах и маршрутизаторах компании Cisco. В настоящее время не поддерживается, но тем не менее может встретиться на старом оборудовании стандартов Fast Ethernet и Gigabit Ethernet. Приоритизацией трафика занимается коммутатор, в зависимости от настроек, и, думаю, компетентный администратор сети навряд ли даст SPAN-трафику приоритет выше, чем «боевому». В условиях повышенных нагрузок трафик RSPAN/SPAN, проходящий через/в коммутатор(е), будет отброшен. SPAN-пакеты всегда стоят первыми в очереди на свалку по логике коммутатора.
Ого! Но как? Почему эффективность снижается?
Если на устройство мониторинга/анализа приходит 10 пакетов из них 5 дублей (цифры для масштаба можно увеличить в десятки или сотни тысяч раз), то ему необходимо каждый из них обработать, потратив на это вычислительные ресурсы. При этом полезной информации в этих 10 пакетах столько же, сколько и в 5. А если система работает с высокой загрузкой, то дубли могут привести к перегрузке и потери части пакетов, с соответствующим ущербом для качества анализа.
Эээ. Ну, так-то и аплинк легко переподписывается. Не будем использовать аплинки?
Аплинки обычно делают с производительностью на порядок выше остальных портов и используют их несколько. То есть, если мы даже будем использовать 4*10G аплинка на 48*1G – масштаб переподписки довольно мал. И потенциальные потери в большинстве случаев будут компенсированы переповтором TCP. Использовать же порты 10G в аналогичном коммутаторе как SPAN мало кто будет, и даже в таком случае потерянные пакеты уже точно не попадут в систему мониторинга/ИБ – ради SPANа их переповторять некому.
Сетевой специалист ничего не упускает. Приведите пример. Специалист по ИБ тоже ничего не упускает - пример пожалуйста)
Даже в малонагруженной сети есть burst’ы по интерфейсам, которые приведут к потерям трафика на SPAN и получением анализирующим оборудованием неполных данных. При внезапно возросшей нагрузке на SPAN будет теряться большая часть трафика. Искать проблему инструментом, вносящим погрешность, тем сложнее, чем больше эта погрешность.
О каких данных первого уровня речь?))
Например, уровень оптического сигнала. TAP его, конечно, уменьшит, но предсказуемо. Для SPAN эта информация недоступна. Или упомянутые межкадровые интервалы.
некорректные, повреждённые пакеты, неправильный CRC (это что-то отличное от некорректных пакетов?), данные 1 уровня и межкадровый интервал - что-то из этого используется в RTP и поэтому RTP нельзя мониторить, я правильно понял?))
«Некорректными» могут восприниматься пакеты с проприетарными заголовками/метками другого оборудования, почему неправильный CRC (насколько и где побился пакет) – это не только для RTP, это и просто для анализа инцедентов и работоспособности сети.
MOS это разве не про кодек?))
Нет. Это про Mean Opinion Score (MOS) усредненная оценка разборчивости речи. MOS дает численное представление о качестве передаваемой медиаинформации и включает в себя и кодеки и передачу по каналам связи.
QoE - с нулевых ничего не слышал, это вроде как "юзер экспириенс"? "ой шото лагает", да? SPAN лагает, конечно)
Да, точнее «Теги VLAN не всегда передаются через SPAN-порт и это зависит от настроек». Спасибо, поправили.
Это как? Что не так с этими данными?))
Так как SPAN-портов мало, то обычно зеркалируется несколько портов в один SPAN. И, соответственно, невозможно понять, с какого порта эти данные пришли, они уже свалены в общий поток.
не больше чем при обычной коммутации
Так, точно! Поэтому используя SPAN, мы получаем некорректные временные метки на системе DPI, а в случае RSPAN ситуация еще более усугубляется, чего не происходит при использовании TAP. Как и на что это влияет, написано в статье. Опять же из-за объединения потоков понять, какие были задержки между пакетами в изначальных потоках после SPAN, уже невозможно.
показывайте, ладно, ваше доказательство)
Наиболее часто описывают 2 варианта:
изменение настроек коммутатора после взлома (SPAN-поток выключается, средство анализа перестает видеть трафик и если не успело зафиксировать атаку, то уже и не сможет)
подключение через SPAN-порт сторонним оборудованием (вместо средства анализа) и использование ошибок настройки или реализации у конкретного вендора.
Что за ересь?)) Где это написано?
Как минимум, в white paper Cisco. Даже в случае возможного выбора высшего приоритета SPAN-трафика над «боевым» на оборудовании того или иного вендора, компетентный инженер навряд ли понизит приоритет последнего (не рассматриваем исключительные и частные случаи). Более того, на оборудовании, где это возможно, инженеры с малой квалификацией допускают грубейшую ошибку при настройке SPAN (в плане приоритета) и «кладут» действующую сеть.
Какая связь между "отбрасывает трафик" и "использованием только при относительно низкой нагрузке в случае сомнения"?
При низкой нагрузке SPAN-порт может справляться или, по крайней мере, терять незначительный процент трафика. При высокой загрузке портов потери, скорее всего, станут неприемлемы.
Лол)) Нет, не позволяет)) У меня вот - ремут спан на одном коммутаторе и я хочу мониторить порт у соседнего коммутатора - но не получается)) Как вы настраивали?
Вам следует разобраться с возможностями и настройками оборудования, которое вы используете, и, если технология RSPAN поддерживается, у вас всё получится! Инструкции настройки SPAN/RSPAN/ERSPAN вы можете найти на просторах интернета или на сайтах вендоров.
Чего?)))) RSPAN по глобальной сети? Это как?
обратно в коммутатор?)))) ахахахах
Да, на самом деле имелось ввиду ERSPAN. Спасибо, поправили.
Пожалуйста, пишите ещё! Я от всех сетевиков вас благодарю и мы ждём рассказ про ещё какую-нибудь технологию или протокол. Я даже сохраню это.
Спасибо за столь обширный комментарий! Надеюсь, мы ответили на все ваши вопросы, всегда приятно разбираться в тех или иных вопросах в диалоге.
Позвольте не согласиться с утверждением, что указанные в данной статье преимущества TAP мнимы, а недостатки SPAN притянуты за уши. Наша цель - дать объективную оценку технологиям зеркалирования трафика, основываясь на собственном опыте и опыте наших коллег по всему миру. Мы показали, что в одних случаях и при определенных условиях (требованиях) можно применять одну технологию, в других другую. При этом есть ситуации, при которых технология SPAN строго не приемлема, а при других технология TAP нецелесообразна (нерентабельна). Сейчас TAPы широко представлены на мировом рынке почти десятком вендоров, в том числе и нашей компанией, так что приобрести их не составляет особой проблемы. Что касается сложности подключения TAP, то тут есть свои нюансы, которые описаны в статье. Поверьте, если стоит задача полностью контролировать сеть и иметь полную видимость сети, альтернативы TAP на сегодняшний день не существует. И да, мы писали «SPAN порт — это полезная технология, если она используется правильно, в хорошо управляемой сети и проверенной методологии». Спасибо за Ваш комментарий.
Стоимость DS Copper-TAP сопоставима с зарубежными аналогами. Подробную информацию вы можете получить, написав нам на sales@dsol.ru Из ключевых преимуществ нашего решения можно выделить: увеличенное время автономной работы, низкий уровень вносимых задержек и статус ТОРП (Единый реестр по ПП РФ № 878).
Не нужно путать торговых брокеров и брокеры сетевых пакетов.
Брокеры сетевых пакетов — это телекоммуникационное оборудование, обеспечивающее распределение потоков трафика на системы мониторинга и информационной безопасности. И как и положено оборудованию — работают независимо от экономических кризисов. Более того, наши брокеры сетевых пакетов полностью разработаны нами же в России, поэтому надёжность их работы от политической ситуации тоже не зависит.
Как раз пассивная схема в этом плане совершенно безопасна — трафик обычно ответвляется пассивным оптическим ответвителем с очень высокой степенью надежности, и брокер получает копию трафика через часть оптической мощности. Активную схему опишем чуть позже, и там, как правило, брокер устанавливается с оптическим переключателем (bypass), который замыкает линк мимо брокера в случае выхода его из строя.
Что касается части сети под мониторинг и ИБ, то при повышенных требованиях к бесперебойности работы этого сегмента, ставится 2 брокера и делается полный крест на средства анализа.
Мы делаем контроллеры, входящие в итоге в состав SSD. Мы их полностью разработали: архитектуру, схемотехнику (RTL), топологию кристалла, чертежи для корпусировки и так далее. ВПО (да, это прошивка) соответственно тоже полностью наше, включая алгоритмы.
В картах памяти microSD контроллер и firmware нашей разработки, сам накопитель тоже нашей разработки, но изготавливаем на стороннем производстве (российском).
В USB и SSD также всё нашей разработки, причём их мы можем и производить у себя (а можем помочь поставить на производство другим).
В этом плане мы также открыты к сотрудничеству: мы понимаем, что кто-то не захочет делиться идеей функционала, у кого-то могут быть готовые наработки и так далее — на монополизм на этом рынке мы не претендуем, хотя формат сотрудничества в данном случае и потребует более сложных договоренностей.
У МЦСТ всё-таки более требовательные к экосистеме продукты — замена SSD зарубежного вендора на отечественный не требует ничего кроме физического осуществления операции, думаю мало пользователей знают чей диск у них стоит.
Что касается SSD нашего производства, то мы планируем сконцентрироваться на крупных корпоративных клиентах и задачах, требующих наличия исходных кодов ВПО (например, реализация дополнительных функций). Соответственно, остается достаточно обширное поле для партнерства с другими производителями.
1. Да, все верно. А еще процесс разложения зависит от температуры. Твердотельные накопители лучше хранить в «сухом прохладном месте»)
2. Зависит от контроллера/накопителя и его программного обеспечения. В бытовых накопителях — вряд ли.
Мы планируем начать поставки контроллеров с интерфейсом SATA 6Gb/s (с встроенным программным обеспечением нашей разработки) в первом квартале 2021 года.
Спасибо за комментарий.
С приходом твердотельников проблема «изнашивания» памяти файловой системой если не утратила актуальность совсем, то уж точно не стоит остро так, как это было на дискетах. На магнитных дисках логические адреса (LBA) были тождественны физическим адресам. То есть, делая частые записи в FAT мы буквально «протирали до дыр» магнитный слой диска. В твердотельниках логическим адресам ставится соответствие физическим через LUN-table, запись в которой меняется каждый раз при записи в логический адрес. Таким образом, даже если вы будете перезаписывать многократно один и тот же LBA, данные будут писаться в разные физические адреса NAND-памяти, и вы не «протрете дырку» по какому-то конкретному адресу. Кроме того, как верно заметил Afterk, в твердотльных накопителях применяется алгоритм WearLeveling, который следит за тем, чтобы весь объем памяти изнашивался равномерно и прямолинейно.
Да, Packet Flow Switches гораздо точнее отражает важность сохранения целостности сессий и появляющиеся возможности пакетных брокеров работать уже на уровне приложений. Может быть поэтому и столько названий: новый функционал добавляется быстрее, чем люди привыкают к текущей терминологии?
Производительность модификации — до 1200 Гбит/с. Схема стекирования зависит от конкретного применения. А по архитектуре системы и схемам, я думаю, будет отдельная статья.
Картинка условная всё-таки: куда в принципе можно подключить. Конечно же к такому количеству точек обычно не подключают. С другой стороны, как раз есть функция дедупликации — в штатном режиме можно использовать её. А при необходимости вместо дедупликации включить тэгирование с TimeStamp на входе брокера и смотреть, как и с какими задержками ходят пакеты. По NetFlow/IPFix выдают уже аккумулированную статистику. А если нужны именно заголовки, то обрезать payload для TLS-пакетов, опять же, можно брокером (как и сформировать NetFlow/IPFix, если статистики достаточно). Причём для нешифрованных протоколов пакеты будут выдаваться целиком. Ну и с пакетными брокерами есть возможность оперативно переключаться между режимами NetFlow/«заголовки».
По цвету — хочется, чтобы наши устройства радовали пользователей в том числе своим видом. И спасибо за замечание по картинке.
Под коммутационной матрицей мы как раз понимаем весь коммутирующий ASIC (иначе необходимо разрисовывать структурную схему чипа и определять, где заканчиваются интерфейсные и вспомогательные блоки, и начинается сама матрица). Основной буфер обычно всё-таки общий, на портах он меньше (есть, конечно, исключения).
Что касается репликации, то одновременности достичь не удается – разное количество пакетов хочет выйти в разные порты, и на выход образуются очереди. Длины этих очередей разные, поэтому когда в порт обычного обмена пакет уже ушёл, то на порт зеркалирования он ещё стоит в очереди за пакетом, который ушёл в другой свободный порт обычного обмена. И да, BUM-трафик "ожидает" и занимает место в буфере входного порта (или shared буфере), пока не отправятся все реплики на все порты, но не поочередно на каждый порт, а по мере освобождения очередей каждого порта (если другого трафика нет, то получится одновременно). Очень редко кто выделяет 10G порт на SPAN в 1G коммутаторах – если он есть, то его скорее используют для аплинка или стекирования. А порезанный трафик – это всё-таки удел каких-то внешних каналов. Кто же режет трафик у себя в сети? Плюс проблема, что об этом необходимо не только подумать, но и помнить затем. А то шейпер можно перенастроить (расширить внешние каналы), а про архитектурно заложенные ограничения SPAN-порта забыть…
И медные тоже!)
Хотя наша компания и занимается, в том числе разработкой микросхем, наши брокеры сетевых пакетов построены на базе готовых интегральных схем. При этом мы используем интегральные микросхемы общего применения и весь функционал обработки пакетов и управления разрабатываем сами. При этом выбор типа ЭКБ позволяет обеспечить гарантию сохранения производительности независимо от задействованных функций.
Действительно, данный протокол межкоммутационного канала является проприетарным протоколом в коммутаторах и маршрутизаторах компании Cisco. В настоящее время не поддерживается, но тем не менее может встретиться на старом оборудовании стандартов Fast Ethernet и Gigabit Ethernet. Приоритизацией трафика занимается коммутатор, в зависимости от настроек, и, думаю, компетентный администратор сети навряд ли даст SPAN-трафику приоритет выше, чем «боевому». В условиях повышенных нагрузок трафик RSPAN/SPAN, проходящий через/в коммутатор(е), будет отброшен. SPAN-пакеты всегда стоят первыми в очереди на свалку по логике коммутатора.
Если на устройство мониторинга/анализа приходит 10 пакетов из них 5 дублей (цифры для масштаба можно увеличить в десятки или сотни тысяч раз), то ему необходимо каждый из них обработать, потратив на это вычислительные ресурсы. При этом полезной информации в этих 10 пакетах столько же, сколько и в 5. А если система работает с высокой загрузкой, то дубли могут привести к перегрузке и потери части пакетов, с соответствующим ущербом для качества анализа.
Аплинки обычно делают с производительностью на порядок выше остальных портов и используют их несколько. То есть, если мы даже будем использовать 4*10G аплинка на 48*1G – масштаб переподписки довольно мал. И потенциальные потери в большинстве случаев будут компенсированы переповтором TCP. Использовать же порты 10G в аналогичном коммутаторе как SPAN мало кто будет, и даже в таком случае потерянные пакеты уже точно не попадут в систему мониторинга/ИБ – ради SPANа их переповторять некому.
Даже в малонагруженной сети есть burst’ы по интерфейсам, которые приведут к потерям трафика на SPAN и получением анализирующим оборудованием неполных данных. При внезапно возросшей нагрузке на SPAN будет теряться большая часть трафика. Искать проблему инструментом, вносящим погрешность, тем сложнее, чем больше эта погрешность.
Например, уровень оптического сигнала. TAP его, конечно, уменьшит, но предсказуемо. Для SPAN эта информация недоступна. Или упомянутые межкадровые интервалы.
«Некорректными» могут восприниматься пакеты с проприетарными заголовками/метками другого оборудования, почему неправильный CRC (насколько и где побился пакет) – это не только для RTP, это и просто для анализа инцедентов и работоспособности сети.
Нет. Это про Mean Opinion Score (MOS) усредненная оценка разборчивости речи. MOS дает численное представление о качестве передаваемой медиаинформации и включает в себя и кодеки и передачу по каналам связи.
Вопрос по-прежнему актуален (https://habr.com/ru/company/vasexperts/blog/477180/). И да, со SPANом разбираться с этим можно долго.
Да, точнее «Теги VLAN не всегда передаются через SPAN-порт и это зависит от настроек». Спасибо, поправили.
Так как SPAN-портов мало, то обычно зеркалируется несколько портов в один SPAN. И, соответственно, невозможно понять, с какого порта эти данные пришли, они уже свалены в общий поток.
Так, точно! Поэтому используя SPAN, мы получаем некорректные временные метки на системе DPI, а в случае RSPAN ситуация еще более усугубляется, чего не происходит при использовании TAP. Как и на что это влияет, написано в статье. Опять же из-за объединения потоков понять, какие были задержки между пакетами в изначальных потоках после SPAN, уже невозможно.
Наиболее часто описывают 2 варианта:
изменение настроек коммутатора после взлома (SPAN-поток выключается, средство анализа перестает видеть трафик и если не успело зафиксировать атаку, то уже и не сможет)
подключение через SPAN-порт сторонним оборудованием (вместо средства анализа) и использование ошибок настройки или реализации у конкретного вендора.
Как минимум, в white paper Cisco. Даже в случае возможного выбора высшего приоритета SPAN-трафика над «боевым» на оборудовании того или иного вендора, компетентный инженер навряд ли понизит приоритет последнего (не рассматриваем исключительные и частные случаи). Более того, на оборудовании, где это возможно, инженеры с малой квалификацией допускают грубейшую ошибку при настройке SPAN (в плане приоритета) и «кладут» действующую сеть.
При низкой нагрузке SPAN-порт может справляться или, по крайней мере, терять незначительный процент трафика. При высокой загрузке портов потери, скорее всего, станут неприемлемы.
Вам следует разобраться с возможностями и настройками оборудования, которое вы используете, и, если технология RSPAN поддерживается, у вас всё получится! Инструкции настройки SPAN/RSPAN/ERSPAN вы можете найти на просторах интернета или на сайтах вендоров.
Да, на самом деле имелось ввиду ERSPAN. Спасибо, поправили.
Спасибо за столь обширный комментарий! Надеюсь, мы ответили на все ваши вопросы, всегда приятно разбираться в тех или иных вопросах в диалоге.
Позвольте не согласиться с утверждением, что указанные в данной статье преимущества TAP мнимы, а недостатки SPAN притянуты за уши. Наша цель - дать объективную оценку технологиям зеркалирования трафика, основываясь на собственном опыте и опыте наших коллег по всему миру. Мы показали, что в одних случаях и при определенных условиях (требованиях) можно применять одну технологию, в других другую. При этом есть ситуации, при которых технология SPAN строго не приемлема, а при других технология TAP нецелесообразна (нерентабельна). Сейчас TAPы широко представлены на мировом рынке почти десятком вендоров, в том числе и нашей компанией, так что приобрести их не составляет особой проблемы. Что касается сложности подключения TAP, то тут есть свои нюансы, которые описаны в статье. Поверьте, если стоит задача полностью контролировать сеть и иметь полную видимость сети, альтернативы TAP на сегодняшний день не существует. И да, мы писали «SPAN порт — это полезная технология, если она используется правильно, в хорошо управляемой сети и проверенной методологии».
Спасибо за Ваш комментарий.
Стоимость DS Copper-TAP сопоставима с зарубежными аналогами. Подробную информацию вы можете получить, написав нам на sales@dsol.ru
Из ключевых преимуществ нашего решения можно выделить: увеличенное время автономной работы, низкий уровень вносимых задержек и статус ТОРП (Единый реестр по ПП РФ № 878).
Брокеры сетевых пакетов — это телекоммуникационное оборудование, обеспечивающее распределение потоков трафика на системы мониторинга и информационной безопасности. И как и положено оборудованию — работают независимо от экономических кризисов. Более того, наши брокеры сетевых пакетов полностью разработаны нами же в России, поэтому надёжность их работы от политической ситуации тоже не зависит.
Что касается части сети под мониторинг и ИБ, то при повышенных требованиях к бесперебойности работы этого сегмента, ставится 2 брокера и делается полный крест на средства анализа.
С GS Nanotech знакомы. Остальное, боюсь, уже заходит на территорию коммерческой тайны.
В картах памяти microSD контроллер и firmware нашей разработки, сам накопитель тоже нашей разработки, но изготавливаем на стороннем производстве (российском).
В USB и SSD также всё нашей разработки, причём их мы можем и производить у себя (а можем помочь поставить на производство другим).
У МЦСТ всё-таки более требовательные к экосистеме продукты — замена SSD зарубежного вендора на отечественный не требует ничего кроме физического осуществления операции, думаю мало пользователей знают чей диск у них стоит.
2. Зависит от контроллера/накопителя и его программного обеспечения. В бытовых накопителях — вряд ли.
С приходом твердотельников проблема «изнашивания» памяти файловой системой если не утратила актуальность совсем, то уж точно не стоит остро так, как это было на дискетах. На магнитных дисках логические адреса (LBA) были тождественны физическим адресам. То есть, делая частые записи в FAT мы буквально «протирали до дыр» магнитный слой диска. В твердотельниках логическим адресам ставится соответствие физическим через LUN-table, запись в которой меняется каждый раз при записи в логический адрес. Таким образом, даже если вы будете перезаписывать многократно один и тот же LBA, данные будут писаться в разные физические адреса NAND-памяти, и вы не «протрете дырку» по какому-то конкретному адресу. Кроме того, как верно заметил Afterk, в твердотльных накопителях применяется алгоритм WearLeveling, который следит за тем, чтобы весь объем памяти изнашивался равномерно и прямолинейно.
Производительность модификации — до 1200 Гбит/с. Схема стекирования зависит от конкретного применения. А по архитектуре системы и схемам, я думаю, будет отдельная статья.
По цвету — хочется, чтобы наши устройства радовали пользователей в том числе своим видом. И спасибо за замечание по картинке.