Czy będzie jakiś problem, jeśli utworzę most w systemie Linux z adresem MAC jego urządzenia podrzędnego?

Jeśli w systemie Windows utworzymy zewnętrzny przełącznik wirtualny w Menedżerze funkcji Hyper-V, będzie on miał adres MAC karty sieciowej, z którą jest połączony.

Więc chcę robić podobne rzeczy w Linuksie z systememd-networkd. Moja konfiguracja jest następująca:

[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

gdzie ac:22:0b:29:e6:0cjest adresem MAC tylko karty sieciowej w systemie (która służy jako urządzenie podrzędne br0).

Oto wynik:

[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

Jak widać, teraz enp3s0i br0ma ten sam link/etheri inet6(adres lokalny link).

Jak dotąd wydaje się, że działało dobrze. Maszyny wirtualne utworzone za pomocą qemu / kvm mają działającą mostkowaną sieć (z -net bridge -net nic, z której korzysta qemu-bridge-helper). Zarówno gospodarz, jak i goście mogą dobrze połączyć się z Internetem.

Mam jednak wątpliwości, czy taka konfiguracja może powodować konflikty w określonych okolicznościach. Więc moje pytanie brzmi: czy to jest słuszne? Czy to zła / brzydka praktyka? Jeśli tak, jakie będą możliwe problemy?

EDYCJA : Czy byłaby jakaś różnica, jeśli wyłączę adres lokalny łącza enp3s0i / lub br0zaakceptuję reklamę routera 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

Będzie generować ogromną ilość ruchu ARP i prawdopodobne błędy routingu z powodu tej konfiguracji. TCP / IP jest tak solidny, że zwykle wymaga znacznej degradacji, aby zostać zauważonym przez użytkownika (czyli osobę lub procesy komunikacyjne).

ARP to protokół stosu Ethernet, który leży tuż poniżej IP. Oznacza protokół rozpoznawania adresów, a jego rolą jest kojarzenie adresów IP z adresami MAC. Nie ma wątpliwości, że jest on zdegradowany, ale z założenia będzie kierował pakiety nawet z niejednoznacznością; używając wartości, którą ostatnio otrzymał. Adresy IP są przejściowo przydzielane sw i mogą być niemal natychmiast przypisywane do różnych i odległych urządzeń - MAC mają być blokowane na hw, a ARP używa tego, aby określić, która brama pobierze pakiet jako następny.

Więc odpowiedź jest taka, że ​​już degraduje ona twoją sieć. Istnieje kilka sposobów, aby to sobie udowodnić. Istnieje coś takiego jak arppinging przy użyciu warstwy arp. Zrzuci pakiety. Wysyłaj arpings do dwóch różnych iface z dużą prędkością z zewnętrznego źródła i spójrz na metryki.

Odpal wireshark i spójrz na ruch ARP, robiąc to i ogólnie.

Następnie napraw MAC. sudo ip link set dev interface address XX:XX:XX:XX:XX:XX Mamy nadzieję, że nowy adres będzie unikalny; jeśli nie jest unikalny, nie lokalny. W systemie Linux możesz sprawdzić pamięć podręczną ARP w systemie plików proc. Minimalna kontrola polega na tym, że komputer Mac nie jest buforowany przez system.

Możesz również użyć rzeczy takich jak iperf3, aby przetestować przepustowość. Skonfiguruj wielu klientów i / lub wiele serwerów na tym routingu laboratoryjnym przez ten mostek i Nic i spójrz na różnicę. Jeśli to zrobisz, opublikuj wyniki, po prostu ciekawy.

Uruchom ponownie te same testy i spójrz na deltę. Jeśli to wszystko zrobisz, a dane wskazują, że nie ma różnicy, chętnie przejrzę je samodzielnie.

Moim zdaniem najgorszym przypadkiem byłyby dwa identyczne komputery Mac w tym samym segmencie sieci WAN, ponieważ zamieszanie miałoby wystarczająco dużo niedeterministycznego opóźnienia, aby umożliwić wystąpienie niektórych warunków bliskiego impasu. To oczywiście spekulacja.

Poza tym łamiesz podstawową zasadę 802.3 - adresy MAC są unikalne. Nie powinny, bo byłoby miło, gdyby tak było, ale z definicji są. Jak możesz żyć ze sobą?

Przyznaję, że w systemach wbudowanych cały czas się psuje; ale nie wtedy, gdy istnieje ścieżka, którą można routować, która istnieje lub mogłaby istnieć.