J'ai configuré un réseau en tant que tel: configurez un réseau hôte uniquement sur VirtualBox. Le premier adaptateur est configuré avec NAT, le second avec un réseau uniquement hôte
HÔTE: Windows
GUEST: CentOS VM1, CentOS VM2 (clone de VM1)
Lors de l'exécution d'ifconfig -a sur les deux machines virtuelles, j'ai remarqué que les adresses MAC sont exactement les mêmes. Ma question est de savoir comment puis-je envoyer une requête ping de VM1 à VM2 étant donné que les adresses MAC sont les mêmes?
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
networking
ip
ethernet
mac-address
utilisateur
la source
la source
dadfaileddans votreip -6 addrsortie. Cela signifie que votre adresse n'a pas détecté d'adresse en double, donc IPv6 ne sera pas utilisable sur cette interface.Réponses:
C'est une de ces choses qui surprend les gens parce que cela va à l'encontre de ce qu'on leur a enseigné.
2 machines avec la même adresse matérielle mac sur le même domaine de diffusion peuvent très bien communiquer entre elles tant qu'elles ont des adresses IP différentes (et que l'équipement de commutation fonctionne bien).
Commençons par une configuration de test:
Notez donc comment les deux machines ont le même adresse MAC, mais des adresses IP différentes.
Essayons de cingler:
Ainsi, l'hôte distant a répondu. Eh bien, c'est bizarre. Regardons la table voisine:
C'est notre MAC!
Permet de faire un
tcpdumpsur l'autre hôte pour voir qu'il obtient réellement le trafic:Ainsi, comme vous pouvez le voir, même si le trafic a la même adresse mac matérielle source et de destination, tout fonctionne toujours parfaitement bien.
La raison en est que la recherche d'adresse MAC arrive très tard dans le processus de communication. La boîte a déjà utilisé l'adresse IP de destination et les tables de routage pour déterminer sur quelle interface elle va envoyer le trafic. L'adresse mac qu'il ajoute au paquet vient après cette décision.
Je dois également noter que cela dépend de l'infrastructure de couche 2. Comment ces machines sont connectées et ce qui se trouve entre elles. Si vous avez un commutateur plus intelligent, cela peut ne pas fonctionner. Il peut voir ce paquet passer et le rejeter.
Passons maintenant à la croyance traditionnelle selon laquelle cela ne fonctionne pas. Eh bien, c'est vrai, d'un certain point de vue :-)
Le problème se pose lorsqu'un autre hôte du réseau doit parler à l'une ou l'autre de ces machines. Lorsque le trafic disparaît, le commutateur va acheminer le trafic par l'adresse mac de destination, et il ne l'enverra qu'à un seul hôte.
Il existe plusieurs raisons possibles pour lesquelles cette configuration de test fonctionne:
la source
Les effets d'une adresse MAC en double peuvent être subtils dans certains cas.
Les commutateurs distribuent le trafic aux hôtes en fonction des adresses "MAC vues". Lorsque vous allumez votre ordinateur et qu'il envoie son premier paquet sur le réseau, votre commutateur enregistre dans sa table MAC que "l'adresse MAC X provient du port Y". Inversement, alors, à l'avenir, lorsqu'il verra un paquet de monodiffusion adressé à l'adresse MAC X, il sait qu'il doit l'envoyer au port Y.
Étant donné que votre machine virtuelle est uniquement sur un seul port de commutateur physique, c'est à votre hyperviseur (VirtualBox) de trier où envoyer les paquets dirigés vers ce MAC virtuel. Dans le cas d'un doublon, il l'envoie probablement aux deux machines virtuelles et laisse la pile réseau sur chaque machine virtuelle le trier. (la pile de mise en réseau verrait probablement que le trafic a été envoyé à son adresse MAC qui n'appartenait pas à l'une de ses propres adresses IP, et abandonnerait silencieusement le paquet.) Vous pouvez donc imaginer que cela entraînerait une quantité considérable de travail supplémentaire, par exemple le système d'exploitation pour se réveiller et traiter chaque paquet, alors que si vous aviez des adresses MAC uniques, le matériel ou le pilote [virtuel] pourrait supprimer le paquet destiné à l'autre hôte, avant de l'envoyer dans la pile.
Sur un réseau commuté (contrairement à votre exemple de machine virtuelle), une adresse MAC en double entraînerait une confusion sur un commutateur pour savoir où envoyer le trafic. Chaque paquet envoyé par un hôte avec un MAC en double entraînerait généralement le commutateur à supposer que l'hôte "déplacé" d'un port sur le commutateur à un autre. Si les deux hôtes envoyaient et recevaient du trafic au même taux, vous vous attendriez à ce que chaque hôte perde 50% de son trafic de retour.
ARP et IPv4 peuvent ne pas être trop préoccupés par les adresses MAC en double, donc la mise en réseau IPv4 peut fonctionner correctement. (bien qu'une pile robuste, ou un hôte avec des outils de sécurité / réseau supplémentaires, puisse considérer une adresse MAC en double comme un indicateur rouge.) De plus, si vous utilisez DHCP, un serveur DHCP (en l'absence d'un ID client suffisamment unique) pourrait attribuer un adresse IPv4 en double, ce qui pourrait être problématique.
D'un autre côté, IPv6 base automatiquement les adresses configurées sur l'adresse MAC . IPv6 inclut également le concept de détection d'adresse en double , ce qui signifie qu'une adresse MAC en double peut provoquer les effets suivants (selon RFC 4862 section 5.4.5):
la source