Bushi Опубликовано 16 марта, 2020 · Жалоба Нужно зеркалировать около десяти портов 1G SFP (трафик только rx) в два порта 10G SFP. Под рукой был mes3124, но на нём невозможно использовать более одного destination порта, да и при зеркалировании на нём есть потери (даже если суммарная полоса по всем входящим портам <10G). Какой коммутатор можете посоветовать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 17 марта, 2020 · Жалоба @Bushi SNR-S2990X-24FQ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 17 марта, 2020 · Жалоба Это очень избыточно и дорого. Мне нужно всего 2 порта SFP+, остальные гигабитные. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 17 марта, 2020 · Жалоба @Bushi Прошу прощения, не так прочитал, думал все 10G. Тогда будет достаточно SNR-S2990G-24FX. Модель также на broadcom, как и вся серия S2990, потерь при зеркалировании нет, зеркалировать в два destination порта можно с помощью reflector-порта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 17 марта, 2020 · Жалоба 20 часов назад, Bushi сказал: Нужно зеркалировать около десяти портов 1G SFP (трафик только rx) в два порта 10G SFP. Под рукой был mes3124, но на нём невозможно использовать более одного destination порта, да и при зеркалировании на нём есть потери (даже если суммарная полоса по всем входящим портам <10G). Какой коммутатор можете посоветовать? На самом деле хреновая ситуация, что-бы собрать несколько гигабит в 10-ку без потерь нужен большой буфер. Задача может оказаться не такой простой как кажется на первый взгляд, и железо может в итоге оказаться не совсем дешевым. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Tkachenko Опубликовано 17 марта, 2020 · Жалоба @sdy_moscow для копирования трафика из нескольких гигабитных портов в десятку не нужен большой буфер, 10GE порт выгребает трафик из буфера быстрее, чем он наполняется. Большой буфер может потребоваться в обратной ситуации. MES3124 давал потери, так как пострен на чипе Marvell BobCat, который архитектурно имеет проблемы с копированием трафика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 17 марта, 2020 · Жалоба @Victor Tkachenko Видимо у Вас коммутаторы по новым законам физики работают путешествуя во времени. Это все равно что девять баб за месяц родят ребенка. Что-бы перенаправить пакет из медленного порта в быстрый его надо СПЕРВА ПОЛНОСТЬЮ получить, т.е. сохранить в буфер. Пока вы его не получите вы его не отправите. Вы не можете отправить сразу 10 пакетов в 1 канале, у них же есть конец и начало пакета. Нельзя отправить пол одного пакета, пол второго и пол третьего одновременно. Если при этом еще и будут очереди, то пакеты могут начать теряться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Tkachenko Опубликовано 18 марта, 2020 · Жалоба @sdy_moscow верно, сначала кадр должен быть полностью записан в буфер, условно это 1500 байт данных. Для приема такого пакета через порт 1GE и его последующей записи в буфер потребуется немногим больше 12мкс, в то же время 10GE порт выберет все данные примерно за 1.2мкс. В итоге 10GE порт за те же 12мкс может поочередно забрать 10 уже записанных в буфер пакетов. Если предположить, что пакеты "непрерывно" и одновременно поступают с десяти 1GE портов, для их хранения потребуется условных 15000 байт и еще 15000 байт свободного места для непрерывной записи следующих пакетов, размер же буфера в таком коммутаторе, как правило, составляет не менее 1.5МБ. То есть даже в более тяжелом случае (10x1GE -> 1x10GE) 10GE порт успевает забрать из буфера достаточное количество пакетов, при этом от буфера потребуется до 2% емкости, а за время выгрузки пакетов как раз запишутся новые. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 18 марта, 2020 · Жалоба @Victor Tkachenko Это в теории. А дальше все зависит от реальной реализации. Пакеты же не случайно начинают теряться. Прибавим в эти конструкции не очень внятное распределение буферной памяти между портами, jumbo frame, работу других портов, работу на прием трафика + процедуры зеркалирования. И всё становиться совсем не так радужно. 4 часа назад, Victor Tkachenko сказал: за время выгрузки пакетов как раз запишутся новые. Интересно, т.е. буфер освобождается до полной отправки пакета? Сомневаюсь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Tkachenko Опубликовано 18 марта, 2020 · Жалоба 5 часов назад, sdy_moscow сказал: Интересно, т.е. буфер освобождается до полной отправки пакета? Сомневаюсь. Абсолютно неверный вывод из написанного мной предложения, там ни слова об освобождении буфера. Дополню: "Пока 10GE порт выбирает уже записанные в буфер пакеты, порты 1GE успеют полностью или частично записать в буфер новые" 5 часов назад, sdy_moscow сказал: Это в теории. А дальше все зависит от реальной реализации. Пакеты же не случайно начинают теряться. Прибавим в эти конструкции не очень внятное распределение буферной памяти между портами, jumbo frame, работу других портов, работу на прием трафика + процедуры зеркалирования. И всё становиться совсем не так радужно. В теории и регулярно подтверждается на практике. Теория эта кстати строится на дизайнах конкретных архитектур сетевых ASIC. Пакеты, действительно, чаще всего теряются не просто по случайности, а систематически и по вполне конкретным причинам. Как я уже выше отметил, проблема ТС наверняка связана с особенностями реализации SPAN в ASIC Marvell BobCat, на котором построен упомянутый коммутатор. Чипы Broadcom в большинстве своем таких проблем не имеют, в том числе чипы, на которых построены коммутаторы SNR-S2990G. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 18 марта, 2020 · Жалоба @Victor Tkachenko Ок. Примем к сведению. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...