2つの異なるVMで同一のMACアドレスですが、インターネット接続があります

そのようにネットワークをセットアップしました。VirtualBoxでホストオンリーネットワークをセットアップします。最初のアダプターはNATで構成され、2番目のアダプターはホストオンリーネットワークで構成されます

ホスト：Windows
ゲスト：CentOS VM1、CentOS VM2（VM1のクローン）

両方のVMでifconfig -aを実行すると、MACアドレスがまったく同じであることがわかりました。MACアドレスが同じであることを考慮して、VM1からVM2にpingを実行するにはどうすればよいですか？

VM1:
eth0      Link encap:Ethernet  HWaddr 08:00:27:AF:A3:28  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feaf:a328/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10671 (10.4 KiB)  TX bytes:5682 (5.5 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:C4:A8:B6  
          inet addr:192.168.56.102  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fec4:a8b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:859 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:114853 (112.1 KiB)  TX bytes:4823 (4.7 KiB)

 ip -6 addr
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:feaf:a328/64 scope link 
           valid_lft forever preferred_lft forever
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:fec4:a8b6/64 scope link 
           valid_lft forever preferred_lft forever

VM2:

eth0      Link encap:Ethernet  HWaddr 08:00:27:AF:A3:28  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feaf:a328/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:114 errors:0 dropped:0 overruns:0 frame:0
          TX packets:151 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:41594 (40.6 KiB)  TX bytes:13479 (13.1 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:C4:A8:B6  
          inet addr:192.168.56.101  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fec4:a8b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1900 errors:0 dropped:0 overruns:0 frame:0
          TX packets:78 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:259710 (253.6 KiB)  TX bytes:9736 (9.5 KiB)



ip -6 addr
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:feaf:a328/64 scope link 
           valid_lft forever preferred_lft forever
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:fec4:a8b6/64 scope link tentative dadfailed 
           valid_lft forever preferred_lft forever

これは、教えられたことに反するため、人々を驚かせるものの1つです。
同じブロードキャストドメインで同じハードウェアMACアドレスを持つ2台のマシンは、異なるIPアドレスを持っている限り（そして、スイッチングギアが適切に機能している限り）互いに正常に通信できます。

テストのセットアップから始めましょう：

VM1 $ ip addr show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:3c:f9:ad brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.2/24 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe3c:f9ad/64 scope link 
       valid_lft forever preferred_lft forever

VM2 $ ip addr show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:3c:f9:ad brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.3/24 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe3c:f9ad/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever

したがって、両方のマシンのMACアドレスは同じですが、IPが異なることに注意してください。

pingを試してみましょう：

VM1 $ ping -c 3 169.254.0.3
PING 169.254.0.3 (169.254.0.3) 56(84) bytes of data.
64 bytes from 169.254.0.3: icmp_seq=1 ttl=64 time=0.505 ms
64 bytes from 169.254.0.3: icmp_seq=2 ttl=64 time=0.646 ms
64 bytes from 169.254.0.3: icmp_seq=3 ttl=64 time=0.636 ms

--- 169.254.0.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.505/0.595/0.646/0.070 ms

したがって、リモートホストが応答しました。まあ、それは奇妙です。ネイバーテーブルを見てみましょう。

VM1 $ ip neigh
169.254.0.3 dev enp0s8 lladdr 08:00:27:3c:f9:ad REACHABLE
10.0.2.2 dev enp0s3 lladdr 52:54:00:12:35:02 STALE

これがMACです。

tcpdump他のホストでa を実行して、実際にトラフィックを取得していることを確認します。

VM2 $ tcpdump -nn -e -i enp0s8 'host 169.254.0.2'
16:46:21.407188 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.2 > 169.254.0.3: ICMP echo request, id 2681, seq 1, length 64
16:46:21.407243 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.3 > 169.254.0.2: ICMP echo reply, id 2681, seq 1, length 64
16:46:22.406469 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.2 > 169.254.0.3: ICMP echo request, id 2681, seq 2, length 64
16:46:22.406520 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.3 > 169.254.0.2: ICMP echo reply, id 2681, seq 2, length 64
16:46:23.407467 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.2 > 169.254.0.3: ICMP echo request, id 2681, seq 3, length 64
16:46:23.407517 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.3 > 169.254.0.2: ICMP echo reply, id 2681, seq 3, length 64

ご覧のとおり、トラフィックの送信元と宛先のハードウェアMACアドレスが同じであっても、すべてが完全に正常に機能します。

これは、MACアドレスのルックアップが通信プロセスの非常に遅いときに行われるためです。ボックスはすでに宛先IPアドレスとルーティングテーブルを使用して、トラフィックを送信するインターフェイスを決定しています。パケットに追加するMACアドレスは、その決定の後に来ます。

これはレイヤー2インフラストラクチャに依存していることにも注意してください。これらのマシンがどのように接続され、それらの間に何が存在するか。よりインテリジェントなスイッチがある場合、これは機能しない可能性があります。このパケットが通過するのを確認して拒否します。

さて、これはうまくいかないという伝統的な信念に移ります。まあそれは本当のことですが、特定の観点から:-)
ネットワーク上の別のホストがこれらのマシンのいずれかと通信する必要があるときに問題が発生します。トラフィックが送信されると、スイッチは宛先MACアドレスでトラフィックをルーティングし、単一のホストに送信するだけです。

このテスト設定が機能する理由はいくつか考えられます。

1. トラフィックは、すべてのポート、またはMACが一致するすべてのポートにブロードキャストされます。
2. スイッチは、宛先ポートを決定するときに、オプションとして送信元ポートを破棄します。
3. スイッチは実際にはレイヤー3スイッチであり、MACアドレスではなくIPアドレスに基づいてルーティングされます。

MACアドレスの重複による影響は、場合によっては微妙です。

スイッチは、「seen MAC」アドレスに基づいてトラフィックをホストに配信します。コンピュータの電源を入れ、最初のパケットをネットワークに送信すると、スイッチは「MACアドレスXがポートYから来た」というMACテーブルにログインします。逆に、将来的には、MACアドレスX宛てのユニキャストパケットを見つけたときに、ポートYに送信することを認識します。

VMは単一の物理スイッチポート上にあるため、ハイパーバイザー（VirtualBox）がその仮想MACに向けられたパケットの送信先を整理します。重複している場合、おそらく両方のVMに送信し、各VMのネットワークスタックにそれを分類させます。（ネットワークスタックは、トラフィックが自身のIPアドレスの1つに属さないMACアドレスに送信されたと認識し、パケットを静かにドロップします。）これにより、次のようなかなりの追加の作業が発生すると想像できます。 OSが起動して各パケットを処理するのに対し、一意のMACアドレスがある場合、[仮想]ハードウェアまたはドライバーは、スタックに送信する前に、他のホスト向けのパケットをドロップする可能性があります。

スイッチドネットワークでは（VMの例とは異なり）、MACアドレスが重複すると、トラフィックの送信先についてスイッチが混乱します。重複したMACを持つホストが送信する各パケットにより、通常、スイッチはホストがスイッチの1つのポートから別のポートに「移動」したと推測します。両方のホストが同じ速度でトラフィックを送受信している場合、各ホストはリターントラフィックの50％を失うと予想されます。

ARPとIPv4はMACアドレスの重複をあまり気にしないため、IPv4ネットワーキングが適切に機能する可能性があります。（堅牢なスタック、または追加のセキュリティ/ネットワークツールを備えたホストは、重複したMACアドレスを危険フラグと見なす場合があります。）また、DHCPを使用している場合、DHCPサーバー（十分に一意のクライアントIDがない場合）はIPv4アドレスが重複しているため、問題が発生する可能性があります。

一方、IPv6はMACアドレスに自動的に構成されたアドレスをベースにします。IPv6には重複アドレス検出の概念も含まれています。つまり、重複するMACアドレスは次の影響を引き起こす可能性があります（RFC 4862セクション5.4.5に従って）。

-  not send any IP packets from the interface,

-  silently drop any IP packets received on the interface, and

-  not forward any IP packets to the interface (when acting as a
   router or processing a packet with a Routing header).