Au-del=E0 de ce que l'on trouve partout, sur les indications ou
significations des 2 bits U/L et I/G dans l'adresse Ethernet,
connaissez-vous une proc=E9dure qui v=E9rifie le contenu de ces bits.
Par exemple, le bit U/L serait-il simplement administratif ? Ou bien
contr=F4le-t-on quelque part la valeur qu'il devrait avoir ?
Au-delà de ce que l'on trouve partout, sur les indications ou significations des 2 bits U/L et I/G dans l'adresse Ethernet, connaissez-vous une procédure qui vérifie le contenu de ces bits.
Par exemple, le bit U/L serait-il simplement administratif ? Ou bien contrôle-t-on quelque part la valeur qu'il devrait avoir ?
Pour U/L, je ne comprends pas la question. Il y a eu des cas de U avec des Mac dupliqués... sur le même lan, c'est mal (et ça se passait mal, d'ailleurs) Le L est une facilité, mais la nécessité d'unicité reste sur le même lan (enfin segment).
Les DHCP peuvent être réglés pour distribuer certaines IP (fixe) à une Mac donnée... en général, on saisit les 6 octets. Je ne pense pas que le test ignore U/L (ni même I/G, mais jouer avec I/G... m'enfin!)
Dans les adresses U, il y a 22 bits pour le constructeur, mais à part une vérification "de visu" du composant, je ne vois pas l'intérêt de faire une vérification.
A la limite, la promotion de l'adresse Mac en adresse IPv6 EUI-64 pourrait étendre la visibilité.
Mais il n'y a pas de "bonne" valeur pour U/L intrinséquement. (ce n'est pas un checksum)
Le 25/09/2010 16:38, Michelot nous fit lire :
Bonjour,
Au-delà de ce que l'on trouve partout, sur les indications ou
significations des 2 bits U/L et I/G dans l'adresse Ethernet,
connaissez-vous une procédure qui vérifie le contenu de ces bits.
Par exemple, le bit U/L serait-il simplement administratif ? Ou bien
contrôle-t-on quelque part la valeur qu'il devrait avoir ?
Pour U/L, je ne comprends pas la question.
Il y a eu des cas de U avec des Mac dupliqués... sur le même lan, c'est
mal (et ça se passait mal, d'ailleurs)
Le L est une facilité, mais la nécessité d'unicité reste sur le même lan
(enfin segment).
Les DHCP peuvent être réglés pour distribuer certaines IP (fixe) à une
Mac donnée... en général, on saisit les 6 octets. Je ne pense pas que le
test ignore U/L (ni même I/G, mais jouer avec I/G... m'enfin!)
Dans les adresses U, il y a 22 bits pour le constructeur, mais à part
une vérification "de visu" du composant, je ne vois pas l'intérêt de
faire une vérification.
A la limite, la promotion de l'adresse Mac en adresse IPv6 EUI-64
pourrait étendre la visibilité.
Mais il n'y a pas de "bonne" valeur pour U/L intrinséquement. (ce n'est
pas un checksum)
Au-delà de ce que l'on trouve partout, sur les indications ou significations des 2 bits U/L et I/G dans l'adresse Ethernet, connaissez-vous une procédure qui vérifie le contenu de ces bits.
Par exemple, le bit U/L serait-il simplement administratif ? Ou bien contrôle-t-on quelque part la valeur qu'il devrait avoir ?
Pour U/L, je ne comprends pas la question. Il y a eu des cas de U avec des Mac dupliqués... sur le même lan, c'est mal (et ça se passait mal, d'ailleurs) Le L est une facilité, mais la nécessité d'unicité reste sur le même lan (enfin segment).
Les DHCP peuvent être réglés pour distribuer certaines IP (fixe) à une Mac donnée... en général, on saisit les 6 octets. Je ne pense pas que le test ignore U/L (ni même I/G, mais jouer avec I/G... m'enfin!)
Dans les adresses U, il y a 22 bits pour le constructeur, mais à part une vérification "de visu" du composant, je ne vois pas l'intérêt de faire une vérification.
A la limite, la promotion de l'adresse Mac en adresse IPv6 EUI-64 pourrait étendre la visibilité.
Mais il n'y a pas de "bonne" valeur pour U/L intrinséquement. (ce n'est pas un checksum)
Michelot
Merci pour ces remarques,
Les DHCP peuvent être réglés pour distribuer certaines IP (fixe) à une Mac donnée... en général, on saisit les 6 octets. Je ne pense pas q ue le test ignore U/L (ni même I/G, mais jouer avec I/G... m'enfin!)
Sauf erreur, la position des bits U/L et I/G dans l'adresse IP allouée de cette manière n'est pas signifiante pour l'IP.
Merci pour le numéro de RFC en IPv4, si vous pensez le trouver assez facilement.
Dans les adresses U, il y a 22 bits pour le constructeur, mais à part une vérification "de visu" du composant, je ne vois pas l'intérêt d e faire une vérification.
Merci pour ce témoignage.
A la limite, la promotion de l'adresse Mac en adresse IPv6 EUI-64 pourrait étendre la visibilité.
J'ai vu cela mais je n'ai pas bien compris au 1er coup d'oeil. Est-ce un équivalent IPv6 de votre commentaire sur DHCP (qui avait l'air de concerner IPv4) ?
Cordialement, Michelot
Merci pour ces remarques,
Les DHCP peuvent être réglés pour distribuer certaines IP (fixe) à une
Mac donnée... en général, on saisit les 6 octets. Je ne pense pas q ue le
test ignore U/L (ni même I/G, mais jouer avec I/G... m'enfin!)
Sauf erreur, la position des bits U/L et I/G dans l'adresse IP allouée
de cette manière n'est pas signifiante pour l'IP.
Merci pour le numéro de RFC en IPv4, si vous pensez le trouver assez
facilement.
Dans les adresses U, il y a 22 bits pour le constructeur, mais à part
une vérification "de visu" du composant, je ne vois pas l'intérêt d e
faire une vérification.
Merci pour ce témoignage.
A la limite, la promotion de l'adresse Mac en adresse IPv6 EUI-64
pourrait étendre la visibilité.
J'ai vu cela mais je n'ai pas bien compris au 1er coup d'oeil. Est-ce
un équivalent IPv6 de votre commentaire sur DHCP (qui avait l'air de
concerner IPv4) ?
Les DHCP peuvent être réglés pour distribuer certaines IP (fixe) à une Mac donnée... en général, on saisit les 6 octets. Je ne pense pas q ue le test ignore U/L (ni même I/G, mais jouer avec I/G... m'enfin!)
Sauf erreur, la position des bits U/L et I/G dans l'adresse IP allouée de cette manière n'est pas signifiante pour l'IP.
Merci pour le numéro de RFC en IPv4, si vous pensez le trouver assez facilement.
Dans les adresses U, il y a 22 bits pour le constructeur, mais à part une vérification "de visu" du composant, je ne vois pas l'intérêt d e faire une vérification.
Merci pour ce témoignage.
A la limite, la promotion de l'adresse Mac en adresse IPv6 EUI-64 pourrait étendre la visibilité.
J'ai vu cela mais je n'ai pas bien compris au 1er coup d'oeil. Est-ce un équivalent IPv6 de votre commentaire sur DHCP (qui avait l'air de concerner IPv4) ?
Cordialement, Michelot
Le Forgeron
Le 25/09/2010 18:35, Michelot nous fit lire :
Merci pour ces remarques,
Les DHCP peuvent être réglés pour distribuer certaines IP (fixe) à une Mac donnée... en général, on saisit les 6 octets. Je ne pense pas que le test ignore U/L (ni même I/G, mais jouer avec I/G... m'enfin!)
Sauf erreur, la position des bits U/L et I/G dans l'adresse IP allouée de cette manière n'est pas signifiante pour l'IP.
L'adresse MAC sert uniquement de clef dans la table. L'adresse IP est une valeur de la ligne sélectionnée. Il n'y a aucun bit transféré entre l'adresse MAC et l'adresse IP (v4) dans une table DHCP.
Une telle table est d'ailleurs plus souvent implémenté en liste (ou en arbre, mais le nombre d'entrée est souvent faible par rapport à la plage de 47 bits disponibles).
Merci pour le numéro de RFC en IPv4, si vous pensez le trouver assez facilement.
Je ne comprends absolument pas cette question. L'adresse MAC a une visibilité limité au lien/segment. On ne peut pas calculer une IP avec (sauf à faire une convention toute personnelle mais nullement universelle). (une telle convention peut être de mettre l'IPv4 dans les 4 derniers octets d'une Mac locale... mais comme avec toute les Mac locales, ça ne contraint en rien ceux qui se présente sur votre réseau et qui peuvent avoir fait une autre convention...)
Pour prendre une comparaison (c'est toujours dangereux), l'adresse Mac est le numéro et la rue de l'adresse d'une lettre postale. Rien n'indique qu'au "31 avenue de la république" doive résider Jacques Chirac (IPv4).
En fait, Il peut même exister plusieurs "31 avenue de la république", du moment que c'est dans des villes différentes. Et il n'y pas d'obligation que dans chaque ville, cela correspondent à l'adresse de JC. (D'ailleurs, Mme Michu est a cette adresse)
L'intérêt des Mac locale est mieux ressentie dans le cas des machines à haute disponibilité: la machine "en service" et celle "de relève" utilise la même Mac (si! en local), afin de s'épargner le temps du flush/redecouverte arp du routeur amont. (et la signalisation qui va avec). Au moment où celle en service défaille, la relève prend ça place sur le réseau, et personne n'y voit rien (enfin, ça pose d'autres soucis au niveau des protocoles ayant la notion de connexion).
A la limite, la promotion de l'adresse Mac en adresse IPv6 EUI-64 pourrait étendre la visibilité.
J'ai vu cela mais je n'ai pas bien compris au 1er coup d'oeil. Est-ce un équivalent IPv6 de votre commentaire sur DHCP (qui avait l'air de concerner IPv4) ?
Le DHCP sert ce qu'on lui demande de servir. Le DHCP se contente en effet souvent de servir des IPv4 (ainsi que les adresses de DNS et de routeur par défaut, également en v4... quoique, les serveurs DNS en IPv4 peuvent aussi répondre pour les résolutions v6 si on leur demande gentillement (et qu'ils ont les champs pour))
IPv6 EUI-64 consiste a générée (de manière autonome) une adresse v6 valide (sur les 128 bits, 64 viennent du "réseau", reste a en générer 64 uniques (en théorie mondialement tant que l'adresse MAC reste unique, et de toute manière on va router sur les 64 premiers jusqu'au réseau). L'avantage est la "numérotation" automatique: plus la peine d'essayer de suivre qui a 192.168.222.44 ... On met la même configuration (y compris en faisant des installation en groupe de type ghosts sur une chaine de 400 machines) à tout le monde (en diffusant les 64 bits du réseau) et chaque machine finit toute seule de mettre la bonne adresse qui va bien. Ce n'est pas possible en IPv4 (mais ça le devient avec un DHCP... ça coûte un service en plus)
Le 25/09/2010 18:35, Michelot nous fit lire :
Merci pour ces remarques,
Les DHCP peuvent être réglés pour distribuer certaines IP (fixe) à une
Mac donnée... en général, on saisit les 6 octets. Je ne pense pas que le
test ignore U/L (ni même I/G, mais jouer avec I/G... m'enfin!)
Sauf erreur, la position des bits U/L et I/G dans l'adresse IP allouée
de cette manière n'est pas signifiante pour l'IP.
L'adresse MAC sert uniquement de clef dans la table. L'adresse IP est
une valeur de la ligne sélectionnée. Il n'y a aucun bit transféré entre
l'adresse MAC et l'adresse IP (v4) dans une table DHCP.
Une telle table est d'ailleurs plus souvent implémenté en liste (ou en
arbre, mais le nombre d'entrée est souvent faible par rapport à la plage
de 47 bits disponibles).
Merci pour le numéro de RFC en IPv4, si vous pensez le trouver assez
facilement.
Je ne comprends absolument pas cette question.
L'adresse MAC a une visibilité limité au lien/segment.
On ne peut pas calculer une IP avec (sauf à faire une convention toute
personnelle mais nullement universelle).
(une telle convention peut être de mettre l'IPv4 dans les 4 derniers
octets d'une Mac locale... mais comme avec toute les Mac locales, ça ne
contraint en rien ceux qui se présente sur votre réseau et qui peuvent
avoir fait une autre convention...)
Pour prendre une comparaison (c'est toujours dangereux), l'adresse Mac
est le numéro et la rue de l'adresse d'une lettre postale.
Rien n'indique qu'au "31 avenue de la république" doive résider Jacques
Chirac (IPv4).
En fait, Il peut même exister plusieurs "31 avenue de la république", du
moment que c'est dans des villes différentes. Et il n'y pas d'obligation
que dans chaque ville, cela correspondent à l'adresse de JC.
(D'ailleurs, Mme Michu est a cette adresse)
L'intérêt des Mac locale est mieux ressentie dans le cas des machines à
haute disponibilité: la machine "en service" et celle "de relève"
utilise la même Mac (si! en local), afin de s'épargner le temps du
flush/redecouverte arp du routeur amont. (et la signalisation qui va
avec). Au moment où celle en service défaille, la relève prend ça place
sur le réseau, et personne n'y voit rien (enfin, ça pose d'autres soucis
au niveau des protocoles ayant la notion de connexion).
A la limite, la promotion de l'adresse Mac en adresse IPv6 EUI-64
pourrait étendre la visibilité.
J'ai vu cela mais je n'ai pas bien compris au 1er coup d'oeil. Est-ce
un équivalent IPv6 de votre commentaire sur DHCP (qui avait l'air de
concerner IPv4) ?
Le DHCP sert ce qu'on lui demande de servir. Le DHCP se contente en
effet souvent de servir des IPv4 (ainsi que les adresses de DNS et de
routeur par défaut, également en v4... quoique, les serveurs DNS en IPv4
peuvent aussi répondre pour les résolutions v6 si on leur demande
gentillement (et qu'ils ont les champs pour))
IPv6 EUI-64 consiste a générée (de manière autonome) une adresse v6
valide (sur les 128 bits, 64 viennent du "réseau", reste a en générer 64
uniques (en théorie mondialement tant que l'adresse MAC reste unique, et
de toute manière on va router sur les 64 premiers jusqu'au réseau).
L'avantage est la "numérotation" automatique: plus la peine d'essayer de
suivre qui a 192.168.222.44 ... On met la même configuration (y compris
en faisant des installation en groupe de type ghosts sur une chaine de
400 machines) à tout le monde (en diffusant les 64 bits du réseau) et
chaque machine finit toute seule de mettre la bonne adresse qui va bien.
Ce n'est pas possible en IPv4 (mais ça le devient avec un DHCP... ça
coûte un service en plus)
Les DHCP peuvent être réglés pour distribuer certaines IP (fixe) à une Mac donnée... en général, on saisit les 6 octets. Je ne pense pas que le test ignore U/L (ni même I/G, mais jouer avec I/G... m'enfin!)
Sauf erreur, la position des bits U/L et I/G dans l'adresse IP allouée de cette manière n'est pas signifiante pour l'IP.
L'adresse MAC sert uniquement de clef dans la table. L'adresse IP est une valeur de la ligne sélectionnée. Il n'y a aucun bit transféré entre l'adresse MAC et l'adresse IP (v4) dans une table DHCP.
Une telle table est d'ailleurs plus souvent implémenté en liste (ou en arbre, mais le nombre d'entrée est souvent faible par rapport à la plage de 47 bits disponibles).
Merci pour le numéro de RFC en IPv4, si vous pensez le trouver assez facilement.
Je ne comprends absolument pas cette question. L'adresse MAC a une visibilité limité au lien/segment. On ne peut pas calculer une IP avec (sauf à faire une convention toute personnelle mais nullement universelle). (une telle convention peut être de mettre l'IPv4 dans les 4 derniers octets d'une Mac locale... mais comme avec toute les Mac locales, ça ne contraint en rien ceux qui se présente sur votre réseau et qui peuvent avoir fait une autre convention...)
Pour prendre une comparaison (c'est toujours dangereux), l'adresse Mac est le numéro et la rue de l'adresse d'une lettre postale. Rien n'indique qu'au "31 avenue de la république" doive résider Jacques Chirac (IPv4).
En fait, Il peut même exister plusieurs "31 avenue de la république", du moment que c'est dans des villes différentes. Et il n'y pas d'obligation que dans chaque ville, cela correspondent à l'adresse de JC. (D'ailleurs, Mme Michu est a cette adresse)
L'intérêt des Mac locale est mieux ressentie dans le cas des machines à haute disponibilité: la machine "en service" et celle "de relève" utilise la même Mac (si! en local), afin de s'épargner le temps du flush/redecouverte arp du routeur amont. (et la signalisation qui va avec). Au moment où celle en service défaille, la relève prend ça place sur le réseau, et personne n'y voit rien (enfin, ça pose d'autres soucis au niveau des protocoles ayant la notion de connexion).
A la limite, la promotion de l'adresse Mac en adresse IPv6 EUI-64 pourrait étendre la visibilité.
J'ai vu cela mais je n'ai pas bien compris au 1er coup d'oeil. Est-ce un équivalent IPv6 de votre commentaire sur DHCP (qui avait l'air de concerner IPv4) ?
Le DHCP sert ce qu'on lui demande de servir. Le DHCP se contente en effet souvent de servir des IPv4 (ainsi que les adresses de DNS et de routeur par défaut, également en v4... quoique, les serveurs DNS en IPv4 peuvent aussi répondre pour les résolutions v6 si on leur demande gentillement (et qu'ils ont les champs pour))
IPv6 EUI-64 consiste a générée (de manière autonome) une adresse v6 valide (sur les 128 bits, 64 viennent du "réseau", reste a en générer 64 uniques (en théorie mondialement tant que l'adresse MAC reste unique, et de toute manière on va router sur les 64 premiers jusqu'au réseau). L'avantage est la "numérotation" automatique: plus la peine d'essayer de suivre qui a 192.168.222.44 ... On met la même configuration (y compris en faisant des installation en groupe de type ghosts sur une chaine de 400 machines) à tout le monde (en diffusant les 64 bits du réseau) et chaque machine finit toute seule de mettre la bonne adresse qui va bien. Ce n'est pas possible en IPv4 (mais ça le devient avec un DHCP... ça coûte un service en plus)
Michelot
Bonsoir,
L'adresse MAC sert uniquement de clef dans la table. L'adresse IP est une valeur de la ligne sélectionnée. Il n'y a aucun bit transféré entre l'adresse MAC et l'adresse IP (v4) dans une table DHCP.
Ah, pardon ! Je faisais un contre-sens. J'imaginais une sémantique voisine d'écriture, à la manière de la relation entre les adresses multicast IPv4 et MAC.
(D'ailleurs, Mme Michu est a cette adresse)
Je savais qu'elle faisait des efforts de citoyenneté, mais je ne connaissais pas ce trait commun avec Jacques.
L'intérêt des Mac locale est mieux ressentie dans le cas des machines à haute disponibilité: la machine "en service" et celle "de relève" utilise la même Mac (si! en local), afin de s'épargner le temps du flush/redecouverte arp du routeur amont. (et la signalisation qui va avec). Au moment où celle en service défaille, la relève prend ça place sur le réseau, et personne n'y voit rien (enfin, ça pose d'autres sou cis au niveau des protocoles ayant la notion de connexion).
Il ne doit pas être aisé de trouver des machines avec des adresses MAC non OUI, à moins qu'elles ne soient dans ce cas configurables (et non gravées).
Ce n'est pas possible en IPv4 (mais ça le devient avec un DHCP... ça coûte un service en plus)
Merci pour la description.
Cordialement, Michelot
Bonsoir,
L'adresse MAC sert uniquement de clef dans la table. L'adresse IP est
une valeur de la ligne sélectionnée. Il n'y a aucun bit transféré entre
l'adresse MAC et l'adresse IP (v4) dans une table DHCP.
Ah, pardon ! Je faisais un contre-sens. J'imaginais une sémantique
voisine d'écriture, à la manière de la relation entre les adresses
multicast IPv4 et MAC.
(D'ailleurs, Mme Michu est a cette adresse)
Je savais qu'elle faisait des efforts de citoyenneté, mais je ne
connaissais pas ce trait commun avec Jacques.
L'intérêt des Mac locale est mieux ressentie dans le cas des machines à
haute disponibilité: la machine "en service" et celle "de relève"
utilise la même Mac (si! en local), afin de s'épargner le temps du
flush/redecouverte arp du routeur amont. (et la signalisation qui va
avec). Au moment où celle en service défaille, la relève prend ça place
sur le réseau, et personne n'y voit rien (enfin, ça pose d'autres sou cis
au niveau des protocoles ayant la notion de connexion).
Il ne doit pas être aisé de trouver des machines avec des adresses MAC
non OUI, à moins qu'elles ne soient dans ce cas configurables (et non
gravées).
Ce n'est pas possible en IPv4 (mais ça le devient avec un DHCP... ça
coûte un service en plus)
L'adresse MAC sert uniquement de clef dans la table. L'adresse IP est une valeur de la ligne sélectionnée. Il n'y a aucun bit transféré entre l'adresse MAC et l'adresse IP (v4) dans une table DHCP.
Ah, pardon ! Je faisais un contre-sens. J'imaginais une sémantique voisine d'écriture, à la manière de la relation entre les adresses multicast IPv4 et MAC.
(D'ailleurs, Mme Michu est a cette adresse)
Je savais qu'elle faisait des efforts de citoyenneté, mais je ne connaissais pas ce trait commun avec Jacques.
L'intérêt des Mac locale est mieux ressentie dans le cas des machines à haute disponibilité: la machine "en service" et celle "de relève" utilise la même Mac (si! en local), afin de s'épargner le temps du flush/redecouverte arp du routeur amont. (et la signalisation qui va avec). Au moment où celle en service défaille, la relève prend ça place sur le réseau, et personne n'y voit rien (enfin, ça pose d'autres sou cis au niveau des protocoles ayant la notion de connexion).
Il ne doit pas être aisé de trouver des machines avec des adresses MAC non OUI, à moins qu'elles ne soient dans ce cas configurables (et non gravées).
Ce n'est pas possible en IPv4 (mais ça le devient avec un DHCP... ça coûte un service en plus)
Merci pour la description.
Cordialement, Michelot
Pascal Hambourg
Salut,
Michelot a écrit :
Il ne doit pas être aisé de trouver des machines avec des adresses MAC non OUI, à moins qu'elles ne soient dans ce cas configurables (et non gravées).
Quid des machines virtuelles ? Elles utilisent des adresses non OUI ou des OUI réservés ?
Salut,
Michelot a écrit :
Il ne doit pas être aisé de trouver des machines avec des adresses MAC
non OUI, à moins qu'elles ne soient dans ce cas configurables (et non
gravées).
Quid des machines virtuelles ? Elles utilisent des adresses non OUI ou
des OUI réservés ?
Il ne doit pas être aisé de trouver des machines avec des adresses MAC non OUI, à moins qu'elles ne soient dans ce cas configurables (et non gravées).
Quid des machines virtuelles ? Elles utilisent des adresses non OUI ou des OUI réservés ?
kurtz le pirate
In article <i7nn2f$1enl$, Pascal Hambourg wrote:
Salut,
Michelot a écrit : > > Il ne doit pas être aisé de trouver des machines avec des adresses MAC > non OUI, à moins qu'elles ne soient dans ce cas configurables (et non > gravées).
Quid des machines virtuelles ? Elles utilisent des adresses non OUI ou des OUI réservés ?
je dirais, pour VMWare Esx, un peu des deux.
les addresses mac doivent être de la forme : 00:50:56:xx:yy:zz avec xx entre 00 et 3f. pour yy et zz, entre 00 et ff.
00:50:56 est le OUI de VMWare inc.
-- klp
In article <i7nn2f$1enl$1@saria.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Salut,
Michelot a écrit :
>
> Il ne doit pas être aisé de trouver des machines avec des adresses MAC
> non OUI, à moins qu'elles ne soient dans ce cas configurables (et non
> gravées).
Quid des machines virtuelles ? Elles utilisent des adresses non OUI ou
des OUI réservés ?
je dirais, pour VMWare Esx, un peu des deux.
les addresses mac doivent être de la forme : 00:50:56:xx:yy:zz
avec xx entre 00 et 3f. pour yy et zz, entre 00 et ff.
Michelot a écrit : > > Il ne doit pas être aisé de trouver des machines avec des adresses MAC > non OUI, à moins qu'elles ne soient dans ce cas configurables (et non > gravées).
Quid des machines virtuelles ? Elles utilisent des adresses non OUI ou des OUI réservés ?
je dirais, pour VMWare Esx, un peu des deux.
les addresses mac doivent être de la forme : 00:50:56:xx:yy:zz avec xx entre 00 et 3f. pour yy et zz, entre 00 et ff.
00:50:56 est le OUI de VMWare inc.
-- klp
Michelot
Bonsoir,
Il semble que ce soit toujours des adresses MAC avec OUI, pas des adresses locales.
"VMware has two OUIs: one for automatically generated MAC addresses and one for manually set addresses. One OUI (00:0C:29) is used only for generated addresses and the other OUI (00:50:56) is used for both generated and manually set addresses".
Apparemment, les adresses locales sont plutôt rares.
Cordialement, Michelot
Bonsoir,
Il semble que ce soit toujours des adresses MAC avec OUI, pas des
adresses locales.
"VMware has two OUIs: one for automatically generated MAC addresses
and one for manually set addresses. One OUI (00:0C:29) is used only
for generated addresses and the other OUI (00:50:56) is used for both
generated and manually set addresses".
Apparemment, les adresses locales sont plutôt rares.
"VMware has two OUIs: one for automatically generated MAC addresses and one for manually set addresses. One OUI (00:0C:29) is used only for generated addresses and the other OUI (00:50:56) is used for both generated and manually set addresses".
Apparemment, les adresses locales sont plutôt rares.
