LINUX.ORG.RU
ФорумAdmin

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

 , , ,


0

1

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

brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 up
ifconfig br0 198.18.25.77/24

Если приговать шлюз, то получаем distention network unreachable. Как зделать так, чтобы входящий трафик шёл через один интерфейс, в исходящий через другой, причём на втором уровне?

★★★★★

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

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

vwvol
()
Ответ на: комментарий от vwvol

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

ne-vlezay ★★★★★
() автор топика

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

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

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

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

system-root ★★★★★
()

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

anonymous
()
Ответ на: комментарий от system-root

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

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

vwvol
()
Ответ на: комментарий от vwvol

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

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

vwvol
()
Ответ на: комментарий от ne-vlezay

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

system-root ★★★★★
()
Ответ на: комментарий от system-root

arp — это уже L3

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

vwvol
()
Ответ на: комментарий от ne-vlezay

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

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

vwvol
()

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

Имеем: Хост и 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 
Где fe:0e:fc:41:39:49 - мак бридж-интерфейса на хосте, а 192.168.2.1 - его ip-адрес

На хосте:

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 
Где 00:16:3e:06:cb:d5 - мак бридж-интерфейса на контейнере, а 192.168.2.11 - его ip-адрес

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. Хост в свою очередь принимает ответы, пришедшие с другого интерфейса.

vwvol
()
Ответ на: комментарий от vwvol

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

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

ne-vlezay ★★★★★
() автор топика
Ответ на: комментарий от ne-vlezay

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

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

vwvol
()
Ответ на: комментарий от vwvol

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

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

system-root ★★★★★
()
Ответ на: комментарий от ne-vlezay

Vlan тоже l2

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

system-root ★★★★★
()
Ответ на: комментарий от system-root

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

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

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

vwvol
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.