Comments 15
Сетевой TAP (Test Access Point) — это
тап это просто английское слово, пришедшее в телеком (интернет) из телекома (телефонии), а туда из обычного языка. Только совсем недавно некоторые (не все) вендоры придумали к нему бэкроним
просто из любопытства, на какой элементной базе все это строится?
скажем для NPB (network packet broker) нужны специализированне IC, что-нибудь типа network processor, у вас есть возможность их заказать, или изготовить?
Хотя наша компания и занимается, в том числе разработкой микросхем, наши брокеры сетевых пакетов построены на базе готовых интегральных схем. При этом мы используем интегральные микросхемы общего применения и весь функционал обработки пакетов и управления разрабатываем сами. При этом выбор типа ЭКБ позволяет обеспечить гарантию сохранения производительности независимо от задействованных функций.
Почему-то забыли про главный минус TAP - если он выходит из строя, то трафик не идет от источника к получателю. Со SPAN такого не будет, если конечно сетевое устройство в 100% утилизацию не уйдет из-за него.
Стоимость DS Copper-TAP сопоставима с зарубежными аналогами. Подробную информацию вы можете получить, написав нам на sales@dsol.ru
Из ключевых преимуществ нашего решения можно выделить: увеличенное время автономной работы, низкий уровень вносимых задержек и статус ТОРП (Единый реестр по ПП РФ № 878).
при всех мнимых преимуществах тапов и притянутых за уши недостатков спан
стоит отметить что озвученные в самом начале задачи успешно решают обе технологии
при этом тапы еще надо где то взять и как то подключить к сети,
а спаны, вот они - присутствуют в каждом свиче
Позвольте не согласиться с утверждением, что указанные в данной статье преимущества TAP мнимы, а недостатки SPAN притянуты за уши. Наша цель - дать объективную оценку технологиям зеркалирования трафика, основываясь на собственном опыте и опыте наших коллег по всему миру. Мы показали, что в одних случаях и при определенных условиях (требованиях) можно применять одну технологию, в других другую. При этом есть ситуации, при которых технология SPAN строго не приемлема, а при других технология TAP нецелесообразна (нерентабельна). Сейчас TAPы широко представлены на мировом рынке почти десятком вендоров, в том числе и нашей компанией, так что приобрести их не составляет особой проблемы. Что касается сложности подключения TAP, то тут есть свои нюансы, которые описаны в статье. Поверьте, если стоит задача полностью контролировать сеть и иметь полную видимость сети, альтернативы TAP на сегодняшний день не существует. И да, мы писали «SPAN порт — это полезная технология, если она используется правильно, в хорошо управляемой сети и проверенной методологии».
Спасибо за Ваш комментарий.
Большего бреда в жизни не читал))
Расскажите про
"канал Inter Switch Link (ISL), который разделит пропускную способность ISL с обычным сетевым трафиком, сетевой трафик получит высший приоритет"
подробнее, пожалуйста)) ISL - это сисковский аналог vlan, проприетарный, использовался на CatOS. С конца девяностых о нём ничего не слышал (оцените свежесть материала - 20-с-хреном-лет). Сетевой трафик получит высший приоритет от кого?)) для чего?))
При использовании SPAN создаются дублирующиеся пакеты данных, что снижает эффективность инструментов мониторинга
Ого! Но как? Почему эффективность снижается?
SPAN может легко переподписаться, отбрасывая пакеты, также наблюдаются потери пакетов в случае перегрузки портов или в случае наличия в них ошибок. В результате «некорректной работы» сетевой специалист упускает из вида часть пользовательского трафика, что не позволяет выявить серьезные ошибки в работе сети, а специалист по информационной безопасности может упустить вирусный трафик или атаку злоумышленника
Эээ. Ну, так-то и аплинк легко переподписывается. Не будем использовать аплинки?
Сетевой специалист ничего не упускает. Приведите пример. Специалист по ИБ тоже ничего не упускает - пример пожалуйста)
Данные 1 уровня, повреждённые и некорректные пакеты, неправильный CRC, межкадровый интервал и другие нестандартные данные не пересылаются на SPAN- порты. Следовательно, SPAN не подходит для мониторинга, захвата и анализа протокола реального времени (RTP), особенно в современных стратегиях оценки среднего значения качества голоса или видео (MOS) и качества восприятия в целом (QoE)
О каких данных первого уровня речь?))
некорректные, повреждённые пакеты, неправильный CRC (это что-то отличное от некорректных пакетов?), данные 1 уровня и межкадровый интервал - что-то из этого используется в RTP и поэтому RTP нельзя мониторить, я правильно понял?))
MOS это разве не про кодек?))
QoE - с нулевых ничего не слышал, это вроде как "юзер экспириенс"? "ой шото лагает", да? SPAN лагает, конечно)
Теги VLAN не передаются через SPAN-порт, поэтому это может привести к обнаружению ложных проблем и затруднению поиска проблем VLAN
Передаются)) Лол))
SPAN-порты предоставляют только обобщенные данные
Это как? Что не так с этими данными?))
SPAN-порты изменяют временные метки пакетов
не больше чем при обычной коммутации
Доказано, что SPAN-порты можно взломать (поэтому они могут представлять угрозу безопасности)
показывайте, ладно, ваше доказательство)
SPAN-порт имеет самый низкий приоритет на коммутаторе, когда дело доходит до выбора между основным трафиком и трафиком SPAN
Что за ересь?)) Где это написано?
Зная, что SPAN-порт произвольно отбрасывает трафик при определенных условиях нагрузки, какую стратегию должны принять пользователи, чтобы не пропустить кадры? Согласно «white paper» Cisco - «лучшая стратегия состоит в том, чтобы принимать решения, на основании загрузки портов в текущей конфигурации, и в случае сомнений применять SPAN-порт только при относительно низкой загрузке».
Какая связь между "отбрасывает трафик" и "использованием только при относительно низкой нагрузке в случае сомнения"?
Remote SPAN (RSPAN), в свою очередь, позволяет производить мониторинг трафика на физически удаленных портах, через сеть коммутаторов.
Лол)) Нет, не позволяет)) У меня вот - ремут спан на одном коммутаторе и я хочу мониторить порт у соседнего коммутатора - но не получается)) Как вы настраивали?
RSPAN не является жизнеспособной технологией доступа к зеркалу трафика, особенно если пакеты передаются по глобальной сети.
Чего?)))) RSPAN по глобальной сети? Это как?
RSPAN поглотит всю вашу пропускную способность, передавая кадры обратно на ваш локальный коммутатор, которые уже прошли через сеть.
обратно в коммутатор?)))) ахахахах
Пожалуйста, пишите ещё! Я от всех сетевиков вас благодарю и мы ждём рассказ про ещё какую-нибудь технологию или протокол. Я даже сохраню это.
подробнее, пожалуйста)) 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 лагает, конечно)
Вопрос по-прежнему актуален (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 вы можете найти на просторах интернета или на сайтах вендоров.
Чего?)))) RSPAN по глобальной сети? Это как?
обратно в коммутатор?)))) ахахахах
Да, на самом деле имелось ввиду ERSPAN. Спасибо, поправили.
Пожалуйста, пишите ещё! Я от всех сетевиков вас благодарю и мы ждём рассказ про ещё какую-нибудь технологию или протокол. Я даже сохраню это.
Спасибо за столь обширный комментарий! Надеюсь, мы ответили на все ваши вопросы, всегда приятно разбираться в тех или иных вопросах в диалоге.
Был бы интересно увидеть примеры TAP устройств
Наши TAP можно не только увидеть, но и протестировать, для этого заполните форму запроса или напишите нам на sales@dsol.ru
TAP или SPAN? Рекомендации по зеркалированию трафика для профессионалов