[Bushi]

Нужно зеркалировать около десяти портов 1G SFP (трафик только rx) в два порта 10G SFP. Под рукой был mes3124, но на нём невозможно использовать более одного destination порта, да и при зеркалировании на нём есть потери (даже если суммарная полоса по всем входящим портам <10G). Какой коммутатор можете посоветовать?

[Aleksey Sonkin]

@Bushi SNR-S2990X-24FQ

[Bushi]

Это очень избыточно и дорого. Мне нужно всего 2 порта SFP+, остальные гигабитные.

[Aleksey Sonkin]

@Bushi Прошу прощения, не так прочитал, думал все 10G. Тогда будет достаточно SNR-S2990G-24FX. Модель также на broadcom, как и вся серия S2990, потерь при зеркалировании нет, зеркалировать в два destination порта можно с помощью reflector-порта.

[sdy_moscow]

20 часов назад, Bushi сказал:

Нужно зеркалировать около десяти портов 1G SFP (трафик только rx) в два порта 10G SFP. Под рукой был mes3124, но на нём невозможно использовать более одного destination порта, да и при зеркалировании на нём есть потери (даже если суммарная полоса по всем входящим портам <10G). Какой коммутатор можете посоветовать?

На самом деле хреновая ситуация, что-бы собрать несколько гигабит в 10-ку без потерь нужен большой буфер. Задача может оказаться не такой простой как кажется на первый взгляд, и железо может в итоге оказаться не совсем дешевым.

[Victor Tkachenko]

@sdy_moscow для копирования трафика из нескольких гигабитных портов в десятку не нужен большой буфер, 10GE порт выгребает трафик из буфера быстрее, чем он наполняется. Большой буфер может потребоваться в обратной ситуации.

MES3124 давал потери, так как пострен на чипе Marvell BobCat, который архитектурно имеет проблемы с копированием трафика.

[sdy_moscow]

@Victor Tkachenko

Видимо у Вас коммутаторы по новым законам физики работают путешествуя во времени. Это все равно что девять баб за месяц родят ребенка.

 

Что-бы перенаправить пакет из медленного порта в быстрый его надо СПЕРВА ПОЛНОСТЬЮ получить, т.е. сохранить в буфер. Пока вы его не получите вы его не отправите.

 

Вы не можете отправить сразу 10 пакетов в 1 канале, у них же есть конец и начало пакета. Нельзя отправить пол одного пакета, пол второго и пол третьего одновременно. Если при этом еще и будут очереди, то пакеты могут начать теряться.

 

[Victor Tkachenko]

@sdy_moscow верно, сначала кадр должен быть полностью записан в буфер, условно это 1500 байт данных. Для приема такого пакета через порт 1GE и его последующей записи в буфер потребуется немногим больше 12мкс, в то же время 10GE порт выберет все данные примерно за 1.2мкс.

В итоге 10GE порт за те же 12мкс может поочередно забрать 10 уже записанных в буфер пакетов. Если предположить, что пакеты "непрерывно" и одновременно поступают с десяти 1GE портов, для их хранения потребуется условных 15000 байт и еще 15000 байт свободного места для непрерывной записи следующих пакетов, размер же буфера в таком коммутаторе, как правило, составляет не менее 1.5МБ.

То есть даже в более тяжелом случае (10x1GE -> 1x10GE) 10GE порт успевает забрать из буфера достаточное количество пакетов, при этом от буфера потребуется до 2% емкости, а за время выгрузки пакетов как раз запишутся новые.

[sdy_moscow]

@Victor Tkachenko

 Это в теории. А дальше все зависит от реальной реализации. Пакеты же не случайно начинают теряться.

Прибавим в эти конструкции не очень внятное распределение буферной памяти между портами, jumbo frame, работу других портов, работу на прием трафика + процедуры зеркалирования. И всё становиться совсем не так радужно.

 

 

4 часа назад, Victor Tkachenko сказал:

за время выгрузки пакетов как раз запишутся новые.

Интересно, т.е. буфер освобождается до полной отправки пакета? Сомневаюсь.

[Victor Tkachenko]

5 часов назад, sdy_moscow сказал:

Интересно, т.е. буфер освобождается до полной отправки пакета? Сомневаюсь.

Абсолютно неверный вывод из написанного мной предложения, там ни слова об освобождении буфера. Дополню: "Пока 10GE порт выбирает уже записанные в буфер пакеты, порты 1GE успеют полностью или частично записать в буфер новые"

 

5 часов назад, sdy_moscow сказал:

Это в теории. А дальше все зависит от реальной реализации. Пакеты же не случайно начинают теряться.

Прибавим в эти конструкции не очень внятное распределение буферной памяти между портами, jumbo frame, работу других портов, работу на прием трафика + процедуры зеркалирования. И всё становиться совсем не так радужно.

В теории и регулярно подтверждается на практике. Теория эта кстати строится на дизайнах конкретных архитектур сетевых ASIC.

Пакеты, действительно, чаще всего теряются не просто по случайности, а систематически и по вполне конкретным причинам. Как я уже выше отметил, проблема ТС наверняка связана с особенностями реализации SPAN в ASIC Marvell BobCat, на котором построен упомянутый коммутатор. Чипы Broadcom в большинстве своем таких проблем не имеют, в том числе чипы, на которых построены коммутаторы SNR-S2990G.

[sdy_moscow]

@Victor Tkachenko Ок. Примем к сведению.