обратный канал L2

Существует ли вероятность того, что порт на коммутаторе заблокирован каким-нибудь луп-детектом? На коммутаторе настроена статическая запись в fdb?

Стесняюсь спросить, но все же спрошу, чем вызвана необходимость подобной схемы?

Просто, хочется организовать ethernet через sata.

Имеем бридж и два односторонних интерфейса

нет, не имеем. ты создал два интерфейса в бридже и назвал их «односторонними», с таким же успехом, мог назвать оперденскими, ничего бы не изменилось. Имеем бридж и два оперденских интерфейса, звучит.

чтобы входящий трафик шёл через один интерфейс, в исходящий через другой, причём на втором уровне?

в таком случае eth0 должен передать информацию eth1 для составления фрейма, иначе как eth1 узнает на какой mac слать? brctl\eth0 такого не умеет, по этому бридж или интерфейс не важен, нужен дополнительный софт, который будет это делать.

А openvswitch умеет так делать?

это про bonding и xmit-Policy. бридж в принципе не про это.

Фрейм составляется исходя не из «информации переданной от eth0 к eth1», а исходя из arp-таблицы. Фрейм пришел на любой из интерфейсов, запись мак-айпи попали в таблицу, проблем нет.

Проблема же, как по мне заключается в отправке через нужный интерфейс, и для этого есть fdb. В fdb можно добавить статическую запись о том, что фреймы на мак 00:16:3e:06:cb:d5 нужно слать на eth0 (или какой там является интерфейсом-отправителем). Однако, fdb будет автоматически обновляться по мере прихода фреймов с eth1. Возможно, существует fdb'шный аналог опции arp_ignore, о которой я не знаю, и который поможет предотвратить обновление fdb. fdb редактируется при помощи bridge fdb Автору советую поискать способ остановить обновление fdb с определенного интерфейса.

Фрейм составляется

Пардон, адрес получателя в заголовке фрейма

arp — это уже L3

возможно, если с OpenFlow и каким-нибудь фреймворком, вроде распиаренного ryu

arp — это уже L3

и что с того? разве отношение протокола к одному из абстрактных уровней каким либо образом оспаривает написанное мною?

А openvswitch умеет так делать?

тут дело не в реализации драйвера бриджа, а в задаче, идущей вразрез с принципом работы бриджинга

Криво, но, все же удалось реализовать схему.

Имеем: Хост и lxd-контейнер, обе системы имеют по бриджу (lxd-br0 и br0 соответственно), системы соединены между собой двумя «забриджованными» veth парами:

Хост__________контейнер

vethUTAX00____eth0 # будет использоваться для передачи трафика от контейнера хосту

vethTH9AD6____eth1 # будет использоваться для передачи от хоста контейнеру

На хосте бридж уже сконфигурирован.

На контейнере:

ip link add br0 type bridge
ip link set eth0 master br0 up
ip link set eth1 master br0 down
ip addr add 192.168.2.11/24 dev br0
ip link set br0 up
arp -s 192.168.2.1 fe:0e:fc:41:39:49
bridge fdb add fe:0e:fc:41:39:49 dev eth0 master static
ip link set eth1 up
brctl setageing br0 0 

На хосте:

arp -s 192.168.2.11 00:16:3e:06:cb:d5
bridge fdb add 00:16:3e:06:cb:d5 dev vethTH9AD6 master static
brctl setageing lxd-br0 0 

vwvol@metalmachine:~$ ping 192.168.2.11 -c 1
PING 192.168.2.11 (192.168.2.11) 56(84) bytes of data.
64 bytes from 192.168.2.11: icmp_seq=1 ttl=64 time=0.096 ms

--- 192.168.2.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.096/0.096/0.096/0.000 ms

tcpdump на хосте:

vwvol@metalmachine:~$ sudo tcpdump -i vethUTAX00 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vethUTAX00, link-type EN10MB (Ethernet), capture size 262144 bytes
12:37:42.056336 IP 192.168.2.1 > 192.168.2.11: ICMP echo request, id 2268, seq 1, length 64
12:37:42.056379 IP 192.168.2.11 > 192.168.2.1: ICMP echo reply, id 2268, seq 1, length 64
12:37:42.056387 IP 192.168.2.11 > 192.168.2.1: ICMP echo reply, id 2268, seq 1, length 64

tcpdump в контейнере:

root@stonedl2:~# tcpdump -i eth0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:39:18.918589 IP 192.168.2.11 > 192.168.2.1: ICMP echo reply, id 2290, seq 1, length 64
12:39:18.918558 IP 192.168.2.1 > 192.168.2.11: ICMP echo request, id 2290, seq 1, length 64
12:39:18.918600 IP 192.168.2.11 > 192.168.2.1: ICMP echo reply, id 2290, seq 1, length 64

Видим, что пакеты дублируются, причины этому я объяснить не могу, но исходя из дампа, можно быть уверенным в том, то контейнер отвечает на пинг, пришедший с eth1 ответом через eth0. Хост в свою очередь принимает ответы, пришедшие с другого интерфейса.

Значит на выходном интерфейсе надо перекрыть входящий трафик, а на входном - исходящий.

ebtables -A FORWARD --logical-in br0 -i eth0 -j DROP
ebtables -A FORWARD --logical-out br0 -o eth0 -j DROP

Возможно, не пробовал.

Так же стоит силами того же ebtables запритить весь трафик проходящий между 2мя бриджед-инрфейсами для защиты от петель.

разве отношение протокола к одному из абстрактных уровней каким либо образом оспаривает написанное мною?

дело в том, что до L3 нет IP адресов и вообще IP протокола, теоретически.
т.е. унылые фреймы, мультикаст, да mac адреса. особо не разгуляться, без каких-нибудь инкапсуляций.

А какая может быть инкопсуляция?

v[x]lan какой нибудь.

Vlan тоже l2

Vlan тоже l2

и чего мне делать с этим знанием? по-моему, в этом ИТТ треде, ОПу т.е. тебе надо что-то с l2 делать.

Спасибо, что объяснили основы основ, но что вы хотите сказать? Да, L2 есть L2. ARP помогает нам заполнить заголок для эзернет-фрейма для инкапсуляции IP-пакета.

инкапсуляции

вот и разгулялись