저는 다음과 같이 네트워크를 설정했습니다. VirtualBox에서 호스트 전용 네트워크 설정. 첫 번째 어댑터는 NAT로 구성되고 두 번째 어댑터는 호스트 전용 네트워킹으로 구성됩니다.
호스트: Windows
게스트: CentOS VM1, CentOS VM2(VM1의 복제본)
두 가상 머신 모두에서 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 주소를 기반으로 라우팅합니다.
답변2
어떤 경우에는 중복된 MAC 주소의 영향이 미묘할 수 있습니다.
스위치는 "표시된 MAC" 주소를 기반으로 호스트에 트래픽을 분산합니다. 컴퓨터를 켜고 네트워크의 첫 번째 패킷을 보내면 스위치는 MAC 테이블에 "포트 Y의 MAC 주소 X"를 기록합니다. 대신, 나중에 MAC 주소 X로 주소가 지정된 유니캐스트 패킷을 발견하면 이를 포트 Y로 보내는 것을 알고 있습니다.
가상 머신은 단일 물리적 스위치 포트에만 있으므로 해당 가상 MAC에 패킷을 보낼 위치를 결정하는 것은 하이퍼바이저(VirtualBox)에 달려 있습니다. 중복된 경우에는 두 VM 모두에 전송하고 각 VM의 네트워크 스택이 이를 정렬하도록 할 수 있습니다. (네트워크 스택은 자체 IP 주소 중 하나가 아닌 MAC 주소로 전송된 트래픽을 보고 자동으로 패킷을 삭제할 수 있습니다.) 따라서 이로 인해 OS가 깨어나는 등 상당한 추가 작업이 발생할 것이라고 상상할 수 있습니다. 패킷당 처리가 가능하며, 고유한 MAC 주소가 있는 경우 [가상] 하드웨어나 드라이버는 다른 호스트용 패킷을 스택 위로 보내기 전에 삭제할 수 있습니다.
VM 예제와 달리 스위치 네트워크에서는 MAC 주소가 중복되면 스위치가 트래픽을 보낼 위치를 혼동하게 될 수 있습니다. 중복된 MAC이 있는 호스트에서 전송된 각 패킷은 일반적으로 스위치에서 호스트가 스위치의 한 포트에서 다른 포트로 "이동"했다고 추측하게 만듭니다. 두 호스트가 동일한 속도로 트래픽을 보내고 받는 경우 각 호스트가 반환 트래픽의 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).