Поддержу тех, кто говорит, что виноваты студенты. За все инсты не скажу, но у нас базу по телекому давали хорошую. Кто хотел — то вникал, остальные прогуливали или просто просиживали.
Мне всегда нравилась разработка под FPGA разных сетевых проектов, но в последнее время стал сильно думать прежде чем связываться еще.
Развитие современных процов и разных модулей для Линукс для работы с сетью сильно повысили возможности и производительность систем на базе х86. И я сейчас не касаюсь DPDK или решений от 6wind.
Как-то решения на базе FPGA становятся все более и более узкоспециализированные. Найти толковых разработчиков ПЛИС все сложнее и сложнее, девкиты дорогие и достать не всегда просто, отладка сложнее, переносимость кода не супер.
Вроде как Network брокер это всегда была железка для записи трафика сети в хранилище, для последующего анализа.
Описанное вами решение это решение по сбору трафика по каким-то определенным правилам. У Gigamon что-то не припомню брокеров линейке.
Дамп ситуации не прояснил.
Жаль, что этого свича нет больше. Так бы с ним парочку экспериментов провести. Интересно разобраться, подумаю где бы его раздобыть.
Что-то из вашего описания картина проблемы никак не склеивается.
Как-то непонятно каким образом пакеты с MAC DST test switch попадают на CPU zyxel.
1. Ясно, что после того как вы отключили test switch, промежуточный считч удалил из своей таблицы коммутации MAC адрес test switch.
2. Так как на хосте ARP запись еще сохранилась, то хост продолжает посылать пакеты обычные и будет это делать до тех пока запись ARM не заэкспайрится.
3. L2 switch не знает за каким портом теперь MAC DST test switch и пересылает его как unknown unicast (в вашей схеме на порт zyxel).
4. Zyxel получив пакет с MAC DST test switch также обрабатывает его как unknown unicast, но пересылать то его не куда. Пакет не предназначен самому коммутатору MAC DST != MAC CPU, т.е. на CPU пакет не отправится, других портов в UP нет, т.е. пакет должен дропнуться. Или баг в ПО как раз и связан с тем, что unknown unicast на порт CPU попадают и CPU их обрабатывает?
Немного вопросов:
1. Судя по дампу пользуете UDP пинг линуксовый. С обычным ICMP пингом такая ситуация проявляется?
2. Можете показать дамп пакетов пинга и трасераута?
3. Можете показать FDB до и после очистки? А заодно еще и ARP кэш на хосте и zyxel?
У меня наступил полный когнитивный диссонанс. Уже прошла неделя или нет с тех пор как отсюда выпилили все Hardware Хабы, объявив что они не имеют никакого отношения к разработке?
Я может что пропусти, можно ссылку на это объявление.
> С технической стороны, ниша у Go довольно скромная: сеть
Что значит сеть?
> иностранные компании, предоставляющие электронные услуги, будут облагаться НДС.
а в этой
> иностранные и отечественные компании не будут облагаться НДС
Можете чуть подробнее почему GPU не помогает?
Развитие современных процов и разных модулей для Линукс для работы с сетью сильно повысили возможности и производительность систем на базе х86. И я сейчас не касаюсь DPDK или решений от 6wind.
Как-то решения на базе FPGA становятся все более и более узкоспециализированные. Найти толковых разработчиков ПЛИС все сложнее и сложнее, девкиты дорогие и достать не всегда просто, отладка сложнее, переносимость кода не супер.
Описанное вами решение это решение по сбору трафика по каким-то определенным правилам. У Gigamon что-то не припомню брокеров линейке.
Еще интересно, смотрели в сторону pf_ring?
Жаль, что этого свича нет больше. Так бы с ним парочку экспериментов провести. Интересно разобраться, подумаю где бы его раздобыть.
Как-то непонятно каким образом пакеты с MAC DST test switch попадают на CPU zyxel.
1. Ясно, что после того как вы отключили test switch, промежуточный считч удалил из своей таблицы коммутации MAC адрес test switch.
2. Так как на хосте ARP запись еще сохранилась, то хост продолжает посылать пакеты обычные и будет это делать до тех пока запись ARM не заэкспайрится.
3. L2 switch не знает за каким портом теперь MAC DST test switch и пересылает его как unknown unicast (в вашей схеме на порт zyxel).
4. Zyxel получив пакет с MAC DST test switch также обрабатывает его как unknown unicast, но пересылать то его не куда. Пакет не предназначен самому коммутатору MAC DST != MAC CPU, т.е. на CPU пакет не отправится, других портов в UP нет, т.е. пакет должен дропнуться. Или баг в ПО как раз и связан с тем, что unknown unicast на порт CPU попадают и CPU их обрабатывает?
Немного вопросов:
1. Судя по дампу пользуете UDP пинг линуксовый. С обычным ICMP пингом такая ситуация проявляется?
2. Можете показать дамп пакетов пинга и трасераута?
3. Можете показать FDB до и после очистки? А заодно еще и ARP кэш на хосте и zyxel?
packetpushers.net/podcast/podcasts/show-250-document-network
forums.juniper.net/t5/Data-Center-Technologists/Juniper-QFX10002-Technical-Overview/ba-p/270358
раздел
Hybrid Memory Cube and Bloom Filters
Содержимое оригинальной статьи настолько порезали, что понять смысл из этого поста невозможно.
Я может что пропусти, можно ссылку на это объявление.