Добрый день, хотел узнать ваше мнение по поводу следующей топологии из linux бриджей:

                     br1(IPv6 lladdr1)
                    /  |      |
                   /   |      |
            eth1.33 eth2.33 eth3.33
              /      /     /
   br0(IPv6 lladdr1)/     / 
      |   | /   |  /  |  /
      |   |/    | /   | /
    eth0 eth1 eth2 eth3  

Т.е. созданы VLAN интерфейсы поверх физических и добавлены в новый бридж br1, при этом старый бридж осталcя без изменений. brctl show выглядит так:

brctl show
br1                3e3c.0050f1abdf1e       yes          eth1.33
                                                        eth2.33
                                                        eth3.33
br2          3e3c.0050f1a1df1e       yes                eth0
                                                        eth1
                                                        eth2
                                                        eth3

Моя проблема в том что при такой топологии начинается мультикаст шторм из IPv6 пакетов с бриджа br1 (пакеты могут быть Neigbor Solicitation, Neigbor Discovery, MLDv2 репорты, все идут с бриджа br1 и забивают всю сеть). Это выглядит как switching loop, но я не могу найти где получается петля, пробовал отключать физически порты, но шторм остается. Мой вопрос - является ли топология которую я описывал выше вообще рабочей? Не создает ли она петли сама по себе?

Может кто подскажет можно ли настроить dhcpd отправлять разные T1/T2 значения в DHCPv6 Reply на DHCPv6 Renew для префиксов IA_NA и IA_PD. Например я хочу чтобы для IA_NA было T1=100 T2=150, а для IA_PD T1=50 T2=75. Как я не пытался экспериментировать с конфигурацией (пробовал опции dhcp-renewal-time,dhcp-rebinding-time пихать в разные места)- у меня ничего не получилось, dhcpd всегда использует одно и тоже значение для обоих префиксов IA_NA и IA_P (либо 100, 150, либо 50, 75). Так вообще можно сконфигурировать DHCPv6 или предполагается что lease time для обоих префиксов должно быть одинакого? В RFC ничего такого не нашел…

Добрый день! Есть встраиваемый сетевой девайс на linux kernel 4.14.40. Есть небольшое число микросервисов (userspace-бинарей, всего их 4-6 программ). Нужно организовать между ними IPC. Есть ли смысл интегрировать DBUS если количество микросервисов небольшое? Или легче сделать что-то самодельное через UNIX-сокеты или может пайпы, shared memory. Что посоветуете? Заранее спасибо!

Добрый день! Есть ядро Linux 4.14.40 на встраиваемом устройстве (AM335x SoC). Задача сделать быстрый форвардер пакетов на уровне L2 в userspace, т.е. чтобы можно было править Ethernet header и т. д. Попробовал в лоб через сырые сокеты (socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW)) и recvfrom в блокирующем режиме - производительность не очень, даже 4kpps не получается. Подскажите, пожалуйста, какие подходы в моем случае подойдут для увеличения производительности форвардера (нужно именно в userspace, .rx_handler не предлагать)? Потому что я так понимаю 4kpps это не предел для userspace наверное…

Предположим у меня есть три модуля ядра - дженерный модуль бриджа линукс, rtnetlink модуль, и мой модуль - mymodule.ko. Насколько я понимаю, когда, например из userspace выполняется команда «ip link show type bridge», она отправляет rtnetlink сообщение в модуль rtnetlink и тот, в свою очередь что-то делает с таблицами и возвращает ответ в userspace. Что если я хочу перехватывать эти сообщения в моем модуле mymodule.ko, делать что-то свое, и возвращать ответ в userspace (для «ip link show type bridge») так что-бы она думала, что работает с обычным бриджом. Вот сдесь нашел статью про что-то подобное (одно из решений использовать BPF) - https://people.netfilter.org/pablo/netdev0.1/papers/Rtnetlink-dump-filtering-in-the-kernel.pdf. Но не уверен, что это применимо в моем случае. Да, вопрос не простой, но как можно добиться такого поведения, как я описал, если не менять код самого rtnetlink’а? Заранее спасибо!)

Я знаю что можно вклучить следующий параметр bridge-nf-call-iptables в procfs, корорый разрешит коду линуксового бриджа (а точнее модуля ядра br_netfilter) передавать IP пакеты в код фаервола (я имею ввиду в ту часть где рутинг и хуки, чейны и таблицы). Но вопрос такой, все ли правила применяются в случае бриджа, я имею ввиду все ли чейны, таблицы и хуки могут применяться или в случае бриджа какие-то правила не будут работать? Было бы здорово увидеть ссылку какую-нибуть… Я по этому поводу не смог ничего нагуглить… Спасибо!

Мне нужно создать библиотеку для работы с сетевыми устройствами (создание мостов, vlan интерфейсов из userspace) для встраимого устройства (коммутатора). Что лучше netlink (libnl) или ioctl? Я слышал что ioctl постепенно устаревает, но он кажется проще. Еще вроде как netlink производительнее. Как вы думаете? И есть ли готовые API поверх netlink? И не зависит ли netlink от версии ядра? Например если я буду писать/собирать либу под одной версией ядра используя netkink, соберется ли она без проблем под другую аерсию ядра? Может быть есть еще другие варианты кроме netlink и ioctl? Спасибо!

Добрый день! Собираю образ для встраиваемой системы с помощью buildroot версия ядра 4.14.40. Нужно менять содержимое всех входящих/исходящих TCP пакетов проходящих через интерфейс следующим образом: На передающей стороне:

1. непосредственно перед отправкой в сеть нужно добалять хвост (8 байт) который должен распологаться в конце пакета перед FCS
2. Делать дубликат пакета (отправлять сразу же пакет повторно)

На приемной стороне непосредственно перед TCP логикой:

1. убирать хвост перед FCS

Можно ли так модернизировать код ядра? И в каких файлах это делать?