Будет ли какая-либо проблема, если я создам мост в Linux с MAC-адресом его ведомого устройства?

Question

В Windows, если мы создадим внешний виртуальный коммутатор в диспетчере Hyper-V, у него будет MAC-адрес сетевой карты, к которой он подключен.

Поэтому я хочу делать подобные вещи в Linux, с помощью systemd-networkd. Моя конфигурация следующая:

[tom@localhost ~]$ ls /etc/systemd/network/
br0.netdev  br0.network  enp3s0.network

[tom@localhost ~]$ cat /etc/systemd/network/br0.netdev 
[NetDev]
Name=br0
Kind=bridge
MACAddress=ac:22:0b:29:e6:0c

[tom@localhost ~]$ cat /etc/systemd/network/br0.network 
[Match]
Name=br0    
[Network]
DHCP=ipv4
IPv6AcceptRouterAdvertisements=no

[tom@localhost ~]$ cat /etc/systemd/network/enp3s0.network 
[Match]
Name=enp3s0    
[Network]
Bridge=br0
IPv6AcceptRouterAdvertisements=no

где ac:22:0b:29:e6:0c - это MAC-адрес только NIC в системе (который служит в качестве подчиненного устройства br0).

Вот результат:

[tom@localhost ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether ac:22:0b:29:e6:0c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ae22:bff:fe29:e60c/64 scope link 
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:22:0b:29:e6:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.111/24 brd 192.168.1.255 scope global dynamic br0
       valid_lft 85622sec preferred_lft 85622sec
    inet6 fe80::ae22:bff:fe29:e60c/64 scope link 
       valid_lft forever preferred_lft forever

Как видите, теперь enp3s0 и br0 имеют одинаковые link/ether и inet6 (локальный адрес ссылки).

Пока что, похоже, хорошо сработало. Виртуальные машины, созданные с помощью qemu/kvm, имеют работающую мостовую сеть (с -net bridge -net nic , которая использует qemu-bridge-helper). И хозяин, и гости могут нормально подключиться к Интернету.

Однако у меня есть некоторые сомнения относительно того, может ли такая конфигурация вызвать конфликт при определенных обстоятельствах. Итак, мой вопрос, это правильно? Или это плохая / уродливая практика? Если таковые имеются, какие будут возможные проблемы?

РЕДАКТИРОВАТЬ: будет ли какая-либо разница, если я отключу локальный адрес enp3s0 и / или заставить br0 принять объявление маршрутизатора ipv6?

[tom@localhost ~]$ ls /etc/systemd/network/
br0.netdev  br0.network  enp3s0.network

[tom@localhost ~]$ cat /etc/systemd/network/br0.netdev 
[NetDev]
Name=br0
Kind=bridge
MACAddress=ac:22:0b:29:e6:0c

[tom@localhost ~]$ cat /etc/systemd/network/br0.network 
[Match]
Name=br0
[Network]
DHCP=ipv4

[tom@localhost ~]$ cat /etc/systemd/network/enp3s0.network 
[Match]
Name=enp3s0
[Network]
LinkLocalAddressing=no
IPv6AcceptRouterAdvertisements=no
Bridge=br0

[tom@localhost ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether ac:22:0b:29:e6:0c brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:22:0b:29:e6:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.111/24 brd 192.168.1.255 scope global dynamic br0
       valid_lft 86357sec preferred_lft 86357sec
    inet6 2404:c805:e00:5300:ae22:bff:fe29:e60c/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 1756sec preferred_lft 1756sec
    inet6 fe80::ae22:bff:fe29:e60c/64 scope link 
       valid_lft forever preferred_lft forever

Answer 1

Он будет генерировать огромное количество трафика ARP и вероятные ошибки маршрутизации из-за этой конфигурации. TCP/IP настолько устойчив, что обычно требуется значительное ухудшение, чтобы пользователь мог его заметить (имеется в виду человек или процессы общения).

ARP - это протокол в стеке Ethernet, который находится чуть ниже IP. Он обозначает протокол разрешения адресов, и его роль заключается в том, чтобы связывать IP-адреса с MAC-адресами. Нет сомнений в том, что он ухудшен, но по замыслу он будет маршрутизировать пакеты даже с неоднозначностью; используя значение, которое он получил в последний раз. IP-адреса назначаются временно и могут быть назначены различным и удаленным устройствам практически мгновенно - MAC-адреса предназначены для блокировки на hw, а ARP использует это для определения того, какой шлюз получит пакет следующим.

Таким образом, ответ заключается в том, что это уже ухудшает вашу сеть. Есть несколько способов доказать это себе. Существует нечто, называемое arpping-ping, использующее слой arp. Это будет отбрасывать пакеты. Отправьте arpings в два разных iface с высокой скоростью из внешнего источника и посмотрите на метрики.

Запустите Wireshark и посмотрите на трафик ARP, делая это и просто в целом.

Затем исправьте MAC. sudo ip link set dev interface address XX:XX:XX:XX:XX:XX Новый адрес, надеюсь, будет уникальным; если не уникальный, не местный. В Linux вы можете посмотреть ARP-кеш в файловой системе proc. Минимальная проверка состоит в том, что этот mac не кэшируется вашей системой.

Вы также можете использовать такие вещи, как iperf3 для проверки пропускной способности. Настройте несколько клиентов и / или несколько серверов в этой лаборатории для маршрутизации через этот мост и Nic и посмотрите на разницу. Если вы сделаете это, пожалуйста, опубликуйте результаты, просто любопытно.

Перезапустите те же тесты и посмотрите на дельту. Если вы делаете все это, и данные указывают на то, что нет никакой разницы, я люблю просматривать это сам.

В худшем случае, я думаю, будут два одинаковых Mac на одном и том же сегменте WAN, так как путаница будет иметь достаточное количество недетерминированных задержек, чтобы позволить возникновение некоторых почти тупиковых условий. Это предположение очевидно.

Кроме того, вы нарушаете фундаментальное правило 802.3 - MAC-адреса уникальны. Не должно быть, или было бы хорошо, если бы они были, но по определению они есть. Как ты можешь жить с собой?

Это допускается во встраиваемых системах все время; но не тогда, когда существует маршрутизируемый путь, который существует или может существовать.