Alamat MAC identik pada dua VM yang berbeda, namun saya memiliki konektivitas internet


8

Saya telah mengatur jaringan seperti itu: Mengatur jaringan hanya host di VirtualBox. Adaptor pertama dikonfigurasi dengan NAT, yang kedua dengan jaringan host-only

PEMBAWA ACARA:
TAMU Windows : CentOS VM1, CentOS VM2 (klon dari VM1)

Ketika menjalankan ifconfig -a pada kedua VM, saya perhatikan bahwa alamat MAC persis sama. Pertanyaan saya adalah bagaimana saya bisa melakukan ping dari VM1 ke VM2 mengingat alamat MACnya sama?

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

Apakah Anda yakin benar-benar melakukan ping VM1 dari VM2, dan tidak benar-benar melakukan ping VM1? Anda dapat memiliki dua mesin dengan alamat MAC yang sama, tetapi hanya jika mereka berada pada tautan Ethernet yang berbeda, yang tidak berlaku untuk dua VM yang menggunakan perangkat lunak virtualisasi yang sama pada host yang sama.
Gilles 'SANGAT berhenti menjadi jahat'

Mengapa ini ditutup sebagai duplikat? Pertanyaannya tidak sama.
Patrick

Apakah Anda menyalin satu VM ke yang lain? Dalam hal ini Anda perlu mengubahnya melalui "VirtualBox Manager" -> Pengaturan -> Adaptor 1 -> Tingkat Lanjut -> Alamat MAC
Anthon

@Gilles. Anda salah. Dua VM yang menggunakan perangkat lunak virtualisasi yang sama pada host yang sama dapat memiliki tautan Ethernet yang berbeda. Lihatlah VMware Workstation Virtual Network Editor sebagai contoh.
fpmurphy

1
@khadija, perhatikan bahwa Anda melihat dadfaileddi ip -6 addroutput Anda . Itu berarti bahwa alamat Anda gagal deteksi duplikat alamat, sehingga IPv6 tidak akan dapat digunakan pada antarmuka itu.
mpontillo

Jawaban:


15

Ini adalah salah satu hal yang mengejutkan orang karena bertentangan dengan apa yang telah diajarkan kepada mereka.
2 mesin dengan alamat mac perangkat keras yang sama pada domain broadcast yang sama dapat berbicara satu sama lain dengan baik selama mereka memiliki alamat IP yang berbeda (dan gear switching berfungsi dengan baik).

Mari kita mulai dengan pengaturan tes:

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

Jadi perhatikan bagaimana kedua mesin memiliki addr MAC yang sama, tetapi IP berbeda.

Mari kita coba 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

Jadi, host jarak jauh merespons. Nah, itu aneh. Mari kita lihat tabel tetangga:

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

Itu MAC kami!

Mari kita lakukan tcpdumppada host lain untuk melihat bahwa itu sebenarnya mendapatkan traffic:

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

Jadi, seperti yang Anda lihat, meskipun lalu lintas memiliki sumber dan alamat perangkat keras yang sama dengan alamat mac, semuanya masih berfungsi dengan baik.

Alasan untuk ini adalah bahwa pencarian alamat MAC datang sangat terlambat dalam proses komunikasi. Kotak telah menggunakan alamat IP tujuan, dan tabel routing untuk menentukan antarmuka mana yang akan mengirimkan lalu lintas keluar. Alamat mac yang ditambahkan ke paket datang setelah keputusan itu.

Saya juga harus mencatat bahwa ini tergantung pada infrastruktur layer 2. Bagaimana mesin ini terhubung, dan apa yang duduk di antara mereka. Jika Anda memiliki saklar yang lebih cerdas, ini mungkin tidak berfungsi. Mungkin melihat paket ini datang dan menolaknya.

Sekarang, melanjutkan ke kepercayaan tradisional, bahwa ini tidak berhasil. Yah itu benar, dari sudut pandang tertentu :-)
Masalahnya muncul ketika host lain di jaringan perlu berbicara dengan salah satu mesin ini. Ketika lalu lintas keluar, saklar akan merutekan lalu lintas dengan alamat mac tujuan, dan itu hanya akan mengirimkannya ke satu host.

Ada beberapa kemungkinan alasan mengapa pengaturan tes ini berfungsi:

  1. Lalu lintas disiarkan ke semua port, atau ke semua port yang cocok dengan MAC.
  2. Switch membuang port sumber sebagai opsi saat menentukan port tujuan.
  3. Switch sebenarnya adalah switch layer 3 dan routing berdasarkan alamat IP, dan bukan alamat mac.

Penjelasan menarik! Terima kasih telah memberikan klarifikasi.
pengguna

5

Efek dari alamat MAC duplikat dapat halus dalam beberapa kasus.

Switch mendistribusikan lalu lintas ke host berdasarkan alamat "MAC yang terlihat". Ketika Anda menyalakan komputer Anda dan mengirimkan paket pertamanya di jaringan, switch Anda akan masuk dalam tabel MAC-nya yang "alamat MAC X berasal dari port Y". Sebaliknya, di masa depan ketika melihat paket unicast dialamatkan ke alamat MAC X, ia tahu untuk mengirimnya ke port Y.

Karena VM Anda hanya pada satu port switch fisik, terserah hypervisor Anda (VirtualBox) untuk memilah tempat mengirim paket yang diarahkan ke MAC virtual tersebut. Dalam kasus duplikat, mungkin hanya mengirimkannya ke kedua VM dan memungkinkan tumpukan jaringan pada setiap VM mengatasinya. (tumpukan jaringan kemungkinan akan melihat bahwa lalu lintas dikirim ke alamat MAC-nya yang bukan milik salah satu alamat IP-nya sendiri, dan diam-diam menjatuhkan paket.) Jadi, Anda dapat membayangkan bahwa ini akan menyebabkan cukup banyak pekerjaan tambahan, karena OS untuk membangunkan dan memproses setiap paket, sedangkan jika Anda memiliki alamat MAC yang unik, perangkat keras atau driver [virtual] dapat menjatuhkan paket yang ditujukan untuk host lain, sebelum mengirimnya ke stack.

Pada jaringan yang diaktifkan (tidak seperti contoh VM Anda), alamat MAC duplikat akan menyebabkan sakelar bingung tentang ke mana harus mengirim lalu lintas. Setiap paket yang dikirim oleh host dengan duplikat MAC biasanya akan menyebabkan switch untuk menduga bahwa host "pindah" dari satu port pada switch ke yang lain. Jika kedua host mengirim dan menerima lalu lintas pada tingkat yang sama, Anda akan mengharapkan setiap host kehilangan 50% dari lalu lintas pengembaliannya.

ARP dan IPv4 mungkin tidak terlalu khawatir tentang duplikat alamat MAC, sehingga jaringan IPv4 dapat berfungsi dengan baik. (meskipun tumpukan yang kuat, atau host dengan alat keamanan / jaringan tambahan, dapat mempertimbangkan duplikasi alamat MAC sebagai bendera merah.) Juga, jika Anda menggunakan DHCP, server DHCP (tidak ada ID klien yang cukup unik) dapat menetapkan alamat IPv4 duplikat, yang bisa bermasalah.

Di sisi lain, IPv6 mendasarkan alamat yang dikonfigurasi secara otomatis pada alamat MAC . IPv6 juga mencakup konsep deteksi alamat duplikat , yang berarti bahwa alamat MAC duplikat dapat menyebabkan efek berikut (menurut RFC 4862 bagian 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).

Sakelar Layer 3 ada, rute mana yang berdasarkan IP, bukan MAC.
Patrick

2
@ Patrick Switch layer 3 yang saya kerjakan masih menggunakan alamat MAC pada layer 2. Ketika mereka mengatakan "Layer 3 switch" mereka biasanya berarti bahwa perangkat keras switching juga tahu bagaimana merutekan traffic di layer 3. (bertindak sebagai router IP ) Lalu lintas yang dirutekan pada lapisan 3 diperlakukan berbeda dari lalu lintas yang beralih pada lapisan 2. (jadi paket yang dirutekan yang masuk mungkin tidak akan terpengaruh oleh hilangnya paket, tetapi lapisan 2 yang mengaktifkan paket pada jaringan yang sama akan melakukannya.) Tetapi saklar spesifik mana yang Anda bicarakan ?
mpontillo
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.