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を実行して、実際にトラフィックを取得していることを確認します。
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アドレスでトラフィックをルーティングし、単一のホストにのみ送信します。
このテスト設定が機能する理由はいくつか考えられます。
- トラフィックは、すべてのポート、またはMACが一致するすべてのポートにブロードキャストされます。
- スイッチは、宛先ポートを決定するときに、オプションとして送信元ポートを破棄します。
- スイッチは実際にはレイヤー3スイッチであり、MACアドレスではなくIPアドレスに基づいてルーティングされます。
MACアドレスの重複による影響は、場合によっては微妙です。
スイッチは、「seen MAC」アドレスに基づいてホストにトラフィックを分散します。コンピュータの電源を入れ、最初のパケットをネットワークに送信すると、スイッチは「MACアドレスXがポートYから来た」というMACテーブルにログインします。逆に、将来的には、MACアドレスX宛てのユニキャストパケットを検出すると、ポートYに送信することを認識します。
VMは単一の物理スイッチポートにのみ存在するため、ハイパーバイザー（VirtualBox）がその仮想MACに向けられたパケットの送信先を整理する必要があります。重複する場合、それはおそらくそれを両方のVMに送信し、それぞれのネットワークスタックにVMをソートさせるだけです（ネットワークスタックは、トラフィックが1つに属していないMACアドレスに送信されたことがわかります。独自のIPアドレスの場合、パケットを静かにドロップします。）これにより、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).