je ne sais pas si je poste au bon endroit mais je charche des
sp=E9cialiste r=E9seau.
Alors voila ma probl=E9matique.
je d=E9veloppe une application qui doit caus=E9 avec 300 petit serveur
(PS).
cela cause avec un protocol maison en rawethernet. Donc via les
adresse MAC.
J aimerais tester la monter en charge de mon appli appelons la FOO.
Ce que je voulais faire c est installer un bridge sur un linux
disposant dun interface eth0
A ce bridge je lui rajoute 300 interface TAP (de TAP0 a TAP299).
Je recupere les adresse MAC des TAP et je les donne a mon appli FOO.
Ensuite je d=E9marre les 300 serveur PS chacun connect=E9 a une interface
TAP.
Mais ca marche pas.
voici la procedure :
# conf de l hote au 300 serveur
ifconfig eth0 0.0.0.0 promisc up
brctl addbr monbridge
brctl setfd monbridge 0
brctl sethello monbridge 0
brctl stp monbridge off
ifconfig monbridge 192.168.0.42 netmask 255.255.255.0 up
# connexion a eth0
brctl addif monbridge eth0
#creation des interface virtuel
tunctl -t tap0
=2E..
=2E..
tunctl -t tap299
#conf des interfaces
ifconfig tap0 0.0.0.0 promisc up
# on connect au bridge
brctl addif monbridge tap0
de m=EAme avec les autre tap (en fait j essaye d abord avec 2)
ensuite je lance mon serveur avec en parametre le nom de l interface.
FOO est sur une machine physique diff=E9rente
remarque monbridge a pris l adresse mac de eth0 ce qui me parrait
normal
l'ensemble des interface sont en "promisc" sauf monbridge
*** resultat ***
les 2 serveurs PS recoivent bien les requetes
ils repondent, quand je scan le reseau sur les interface TAP avec
wireshark je recup=E8re les requete qu ils envoient a FOO pas ce qui
rentre par contre ! bizarre d=E9j=E0.
Quand je fait inspecter l interface "monbridge" a wireshark je choppe
les trames qui rentre a destination des mes serveur PS mais rien qui
sort.
Si quelqu un avait une id=E9e a me proposer . car je suis pas fortich en
r=E9seau et cela me d=E9panerais bien.
J'oubliais : merci pour le retour. J'aime bien faire tester mes idées par les autres. ;-)
lidiriel
On 8 avr, 16:49, Pascal Hambourg wrote:
Ok il semble que cela marche:
alors le process que j ai appliqué :
J'oubliais : merci pour le retour. J'aime bien faire tester mes idées par les autres. ;-)
Bon je relance ce fil
Aujourd hui j ai fait des essai en grand 5 process qui cause via le switch. Avec des wireshark partout pour regarder si tout ce passe bien et la malheurs : 1) cas sans infrastructure virtuel FOO FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge tout est OK
2) cas avec le bridge qui fait le lien avec eth0 et le vde_switch conencter au bridge et a une tapX FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge, puis PS1 a l air de recevoir une second trame et une troisieme et renvoie donc 2 acknoledge. Sous wireshark on relève : la trame FOO=>PS1 les 3 acknoledge PS1=>FOO
quand on fait logger PS1 au niveau du traitement de la raw socket il log plusieurs message alors qu il n y en a qu un d emis de FOO
Ma question es : es ce que les TUN/TAP ne ferais pas de la redondance ou le bridge ?? A moin que j ai pas compris les subtilités d'un bridge, vde_switch ou tap ?
Si Pascal tu as une idée ou quelqu'un d autre qui a suivi le fil....
On 8 avr, 16:49, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org> wrote:
Ok il semble que cela marche:
alors le process que j ai appliqué :
J'oubliais : merci pour le retour. J'aime bien faire tester mes idées
par les autres. ;-)
Bon je relance ce fil
Aujourd hui j ai fait des essai en grand 5 process qui cause via le
switch.
Avec des wireshark partout pour regarder si tout ce passe bien et la
malheurs :
1) cas sans infrastructure virtuel FOO
FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge
tout est OK
2) cas avec le bridge qui fait le lien avec eth0 et le vde_switch
conencter au bridge et a une tapX
FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge,
puis PS1 a l air de recevoir une second trame et une troisieme et
renvoie donc 2 acknoledge.
Sous wireshark on relève :
la trame FOO=>PS1
les 3 acknoledge PS1=>FOO
quand on fait logger PS1 au niveau du traitement de la raw socket il
log plusieurs message alors qu il n y en a qu un d emis de FOO
Ma question es : es ce que les TUN/TAP ne ferais pas de la redondance
ou le bridge ?? A moin que j ai pas compris les subtilités d'un
bridge, vde_switch ou tap ?
Si Pascal tu as une idée ou quelqu'un d autre qui a suivi le fil....
J'oubliais : merci pour le retour. J'aime bien faire tester mes idées par les autres. ;-)
Bon je relance ce fil
Aujourd hui j ai fait des essai en grand 5 process qui cause via le switch. Avec des wireshark partout pour regarder si tout ce passe bien et la malheurs : 1) cas sans infrastructure virtuel FOO FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge tout est OK
2) cas avec le bridge qui fait le lien avec eth0 et le vde_switch conencter au bridge et a une tapX FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge, puis PS1 a l air de recevoir une second trame et une troisieme et renvoie donc 2 acknoledge. Sous wireshark on relève : la trame FOO=>PS1 les 3 acknoledge PS1=>FOO
quand on fait logger PS1 au niveau du traitement de la raw socket il log plusieurs message alors qu il n y en a qu un d emis de FOO
Ma question es : es ce que les TUN/TAP ne ferais pas de la redondance ou le bridge ?? A moin que j ai pas compris les subtilités d'un bridge, vde_switch ou tap ?
Si Pascal tu as une idée ou quelqu'un d autre qui a suivi le fil....
Olivier Miakinen
Avertissement : je n'y connais rien aux TAP, TUN, VDE et ainsi de suite, mais la description de ton dernier problème me fait penser à un problème que j'ai eu moi-même entre un modem routeur Thomson et un serveur FreeBSD.
Aujourd hui j ai fait des essai en grand 5 process qui cause via le switch. Avec des wireshark partout pour regarder si tout ce passe bien et la malheurs : 1) cas sans infrastructure virtuel FOO FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge tout est OK
2) cas avec le bridge qui fait le lien avec eth0 et le vde_switch conencter au bridge et a une tapX FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge, puis PS1 a l air de recevoir une second trame et une troisieme et renvoie donc 2 acknoledge.
J'ai constaté à peu près la même chose avec un FreeBSD à la place de PS1 et mon modem routeur à la place de ton bridge. Apparemment, le problème était que l'utilisation de l'option SACK (Selective Acknowledgment, RFC 2018) générait des trames TCP avec des options pas tout-à-fait correctes qui étaient rejetées par mon routeur. Le routeur passait donc son temps à envoyer des SYN et à rejeter tous les SYN ACK reçus en réponse.
Le contournement trouvé par le type génial qui a détecté le problème chez mon FSI a été de rajouter ceci dans /etc/sysctl.conf sur le serveur : net.inet.tcp.sack.enable=0
Au cas où cela pourrait t'être utile...
Avertissement : je n'y connais rien aux TAP, TUN, VDE et ainsi de suite,
mais la description de ton dernier problème me fait penser à un problème
que j'ai eu moi-même entre un modem routeur Thomson et un serveur FreeBSD.
Aujourd hui j ai fait des essai en grand 5 process qui cause via le
switch.
Avec des wireshark partout pour regarder si tout ce passe bien et la
malheurs :
1) cas sans infrastructure virtuel FOO
FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge
tout est OK
2) cas avec le bridge qui fait le lien avec eth0 et le vde_switch
conencter au bridge et a une tapX
FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge,
puis PS1 a l air de recevoir une second trame et une troisieme et
renvoie donc 2 acknoledge.
J'ai constaté à peu près la même chose avec un FreeBSD à la place de PS1
et mon modem routeur à la place de ton bridge. Apparemment, le problème
était que l'utilisation de l'option SACK (Selective Acknowledgment, RFC
2018) générait des trames TCP avec des options pas tout-à-fait correctes
qui étaient rejetées par mon routeur. Le routeur passait donc son temps
à envoyer des SYN et à rejeter tous les SYN ACK reçus en réponse.
Le contournement trouvé par le type génial qui a détecté le problème
chez mon FSI a été de rajouter ceci dans /etc/sysctl.conf sur le
serveur :
net.inet.tcp.sack.enable=0
Avertissement : je n'y connais rien aux TAP, TUN, VDE et ainsi de suite, mais la description de ton dernier problème me fait penser à un problème que j'ai eu moi-même entre un modem routeur Thomson et un serveur FreeBSD.
Aujourd hui j ai fait des essai en grand 5 process qui cause via le switch. Avec des wireshark partout pour regarder si tout ce passe bien et la malheurs : 1) cas sans infrastructure virtuel FOO FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge tout est OK
2) cas avec le bridge qui fait le lien avec eth0 et le vde_switch conencter au bridge et a une tapX FOO envoie une trame a PS1, PS1 la recoit et repond par un acknoledge, puis PS1 a l air de recevoir une second trame et une troisieme et renvoie donc 2 acknoledge.
J'ai constaté à peu près la même chose avec un FreeBSD à la place de PS1 et mon modem routeur à la place de ton bridge. Apparemment, le problème était que l'utilisation de l'option SACK (Selective Acknowledgment, RFC 2018) générait des trames TCP avec des options pas tout-à-fait correctes qui étaient rejetées par mon routeur. Le routeur passait donc son temps à envoyer des SYN et à rejeter tous les SYN ACK reçus en réponse.
Le contournement trouvé par le type génial qui a détecté le problème chez mon FSI a été de rajouter ceci dans /etc/sysctl.conf sur le serveur : net.inet.tcp.sack.enable=0
Au cas où cela pourrait t'être utile...
lidiriel
Merci pour l info mais je travaille sur la couche MAC donc une option du protocol TCP ne peux pas influencer le comportement de mon système vue que je travaille en dessous de la couche concernée. bon j'ai quand même changer l option au point ou j en suis.
Après un examen attentif il ya une duplication de la trame initial (la requet de FOO) et une duplication des réponses. mes process PS sont donc hors de cause. Il y a un truc que j ai pas capter sur le fonctionnement des tap bridge a mon avis.
net.inet.tcp.sack.enable=0
Au cas où cela pourrait t'être utile...
Merci pour l info mais je travaille sur la couche MAC donc une option
du protocol TCP ne peux pas influencer le comportement de mon système
vue que je travaille en dessous de la couche concernée.
bon j'ai quand même changer l option au point ou j en suis.
Après un examen attentif il ya une duplication de la trame initial (la
requet de FOO) et une duplication des réponses. mes process PS sont
donc hors de cause.
Il y a un truc que j ai pas capter sur le fonctionnement des tap
bridge a mon avis.
Merci pour l info mais je travaille sur la couche MAC donc une option du protocol TCP ne peux pas influencer le comportement de mon système vue que je travaille en dessous de la couche concernée. bon j'ai quand même changer l option au point ou j en suis.
Après un examen attentif il ya une duplication de la trame initial (la requet de FOO) et une duplication des réponses. mes process PS sont donc hors de cause. Il y a un truc que j ai pas capter sur le fonctionnement des tap bridge a mon avis.
net.inet.tcp.sack.enable=0
Au cas où cela pourrait t'être utile...
Olivier Miakinen
Merci pour l'info mais je travaille sur la couche MAC donc une option du protocole TCP ne peut pas influencer le comportement de mon système vu que je travaille en dessous de la couche concernée.
D'accord. Je me doutais bien que, n'ayant rien compris au problème, ma solution avait toutes les chances d'être à côté de la plaque. J'aurais quand même dû voir que tu écrivais « ... protocol maison en rawethernet. Donc via les adresse MAC ».
bon j'ai quand même changé l'option au point où j'en suis.
;-)
Merci pour l'info mais je travaille sur la couche MAC donc une option
du protocole TCP ne peut pas influencer le comportement de mon système
vu que je travaille en dessous de la couche concernée.
D'accord. Je me doutais bien que, n'ayant rien compris au problème, ma
solution avait toutes les chances d'être à côté de la plaque. J'aurais
quand même dû voir que tu écrivais « ... protocol maison en rawethernet.
Donc via les adresse MAC ».
bon j'ai quand même changé l'option au point où j'en suis.
Merci pour l'info mais je travaille sur la couche MAC donc une option du protocole TCP ne peut pas influencer le comportement de mon système vu que je travaille en dessous de la couche concernée.
D'accord. Je me doutais bien que, n'ayant rien compris au problème, ma solution avait toutes les chances d'être à côté de la plaque. J'aurais quand même dû voir que tu écrivais « ... protocol maison en rawethernet. Donc via les adresse MAC ».
bon j'ai quand même changé l'option au point où j'en suis.
;-)
lidiriel
Experience intéresante : Mon process PS est connecté sur tap0 Il recoit 3 trame au lieu de une je fait un ifdown tap0; ifconfig tap0 down je coupe le process vde_plug2tap et la : je ne reçois plus que 2 trames. Le process PS ne râle même pas... il continue a recevoir des truc j hallucine un peu
... :-(
Experience intéresante :
Mon process PS est connecté sur tap0
Il recoit 3 trame au lieu de une
je fait un ifdown tap0; ifconfig tap0 down
je coupe le process vde_plug2tap et la : je ne reçois plus que 2
trames.
Le process PS ne râle même pas... il continue a recevoir des truc j
hallucine un peu
Experience intéresante : Mon process PS est connecté sur tap0 Il recoit 3 trame au lieu de une je fait un ifdown tap0; ifconfig tap0 down je coupe le process vde_plug2tap et la : je ne reçois plus que 2 trames. Le process PS ne râle même pas... il continue a recevoir des truc j hallucine un peu
... :-(
Pascal Hambourg
Experience intéresante : Mon process PS est connecté sur tap0
tap0, ce n'est pas le port qui sert à relier le switch virtuel au pont (et qu'il ne faut donc pas utiliser comme interface) ?
Il recoit 3 trame au lieu de une
Trois exemplaires identiques de la trame émise par FOO ? Il n'y aurait pas une boucle quelque part ? Quelle est la structure complète du réseau virtuel ?
Experience intéresante :
Mon process PS est connecté sur tap0
tap0, ce n'est pas le port qui sert à relier le switch virtuel au pont
(et qu'il ne faut donc pas utiliser comme interface) ?
Il recoit 3 trame au lieu de une
Trois exemplaires identiques de la trame émise par FOO ?
Il n'y aurait pas une boucle quelque part ?
Quelle est la structure complète du réseau virtuel ?
Experience intéresante : Mon process PS est connecté sur tap0
tap0, ce n'est pas le port qui sert à relier le switch virtuel au pont (et qu'il ne faut donc pas utiliser comme interface) ?
Il recoit 3 trame au lieu de une
Trois exemplaires identiques de la trame émise par FOO ? Il n'y aurait pas une boucle quelque part ? Quelle est la structure complète du réseau virtuel ?
mlct
On 11 avr, 16:45, Pascal Hambourg wrote:
Experience intéresante : Mon process PS est connecté sur tap0
tap0, ce n'est pas le port qui sert à relier le switch virtuel au pont (et qu'il ne faut donc pas utiliser comme interface) ?
Il recoit 3 trame au lieu de une
Trois exemplaires identiques de la trame émise par FOO ? Il n'y aurait pas une boucle quelque part ? Quelle est la structure complète du réseau virtuel ?
Salut,
Je prends la suite du problème de Lidiriel et relance la discussion sur notre problématique. Je connais encore moins de chose en réseau que lui, mais bon je vais essayais de me faire comprendre.
La struture du réseau est la suivante: - port physique ETH0 relié au bridge virtuel. - le bridge virtuel est relié au switch virtuelle vde_switch par un TAP (TAP999) - ensuite le switch est relié à notre application via TAP0 (avec process Vdephys2tap).
Notre application reçoit 3 trames provenant du switch (alors que sur Eth0, on a qu'une seule trame). Si on observe avec Wireshark, il affiche pourtant qu'une seule trame sur TAP0. Au niveau du code de notre application, la réception des trames se fait avec une socket (on utilise la méthode recvfrom), et on ne voit aucune redondance qui pourrait expliquer cette réception des 3 trames.
De plus, si on connecte directement notre application sur Eth0, elle reçoit une seule trame et donc ne renvoie qu'une seule trame, ce qui veut à priori dire que notre application a l'air de fonctionner correctement.
Si ces quelques infos peuvent permettre de nous aider ....
On 11 avr, 16:45, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:
Experience intéresante :
Mon process PS est connecté sur tap0
tap0, ce n'est pas le port qui sert à relier le switch virtuel au pont
(et qu'il ne faut donc pas utiliser comme interface) ?
Il recoit 3 trame au lieu de une
Trois exemplaires identiques de la trame émise par FOO ?
Il n'y aurait pas une boucle quelque part ?
Quelle est la structure complète du réseau virtuel ?
Salut,
Je prends la suite du problème de Lidiriel et relance la discussion
sur notre problématique.
Je connais encore moins de chose en réseau que lui, mais bon je vais
essayais de me faire comprendre.
La struture du réseau est la suivante:
- port physique ETH0 relié au bridge virtuel.
- le bridge virtuel est relié au switch virtuelle vde_switch par un
TAP (TAP999)
- ensuite le switch est relié à notre application via TAP0 (avec
process Vdephys2tap).
Notre application reçoit 3 trames provenant du switch (alors que sur
Eth0, on a qu'une seule trame). Si on observe avec Wireshark, il
affiche pourtant qu'une seule trame sur TAP0.
Au niveau du code de notre application, la réception des trames se
fait avec une socket (on utilise la méthode recvfrom), et on ne voit
aucune redondance qui pourrait expliquer cette réception des 3 trames.
De plus, si on connecte directement notre application sur Eth0, elle
reçoit une seule trame et donc ne renvoie qu'une seule trame, ce qui
veut à priori dire que notre application a l'air de fonctionner
correctement.
Si ces quelques infos peuvent permettre de nous aider ....
Experience intéresante : Mon process PS est connecté sur tap0
tap0, ce n'est pas le port qui sert à relier le switch virtuel au pont (et qu'il ne faut donc pas utiliser comme interface) ?
Il recoit 3 trame au lieu de une
Trois exemplaires identiques de la trame émise par FOO ? Il n'y aurait pas une boucle quelque part ? Quelle est la structure complète du réseau virtuel ?
Salut,
Je prends la suite du problème de Lidiriel et relance la discussion sur notre problématique. Je connais encore moins de chose en réseau que lui, mais bon je vais essayais de me faire comprendre.
La struture du réseau est la suivante: - port physique ETH0 relié au bridge virtuel. - le bridge virtuel est relié au switch virtuelle vde_switch par un TAP (TAP999) - ensuite le switch est relié à notre application via TAP0 (avec process Vdephys2tap).
Notre application reçoit 3 trames provenant du switch (alors que sur Eth0, on a qu'une seule trame). Si on observe avec Wireshark, il affiche pourtant qu'une seule trame sur TAP0. Au niveau du code de notre application, la réception des trames se fait avec une socket (on utilise la méthode recvfrom), et on ne voit aucune redondance qui pourrait expliquer cette réception des 3 trames.
De plus, si on connecte directement notre application sur Eth0, elle reçoit une seule trame et donc ne renvoie qu'une seule trame, ce qui veut à priori dire que notre application a l'air de fonctionner correctement.
Si ces quelques infos peuvent permettre de nous aider ....
Kevin Denis
Le 21-04-2008, mlct a écrit :
Ca ne fait que deux mois que la question a été posée, mais bon..
La struture du réseau est la suivante: - port physique ETH0 relié au bridge virtuel. - le bridge virtuel est relié au switch virtuelle vde_switch par un TAP (TAP999) - ensuite le switch est relié à notre application via TAP0 (avec process Vdephys2tap).
Notre application reçoit 3 trames provenant du switch (alors que sur Eth0, on a qu'une seule trame). Si on observe avec Wireshark, il affiche pourtant qu'une seule trame sur TAP0.
J'ai eu le même genre de constations lorsque j'utilisais des tap0 et des machines qemu. Un envoi, 'x' réceptions. 'x' étant le nombre de machines qemu.
La solution résidait dans l'adresse MAC que je choisissais pour mes machines qemu. Si l'adresse MAC était: 00:AB:CD:EF:GH:xx tout fonctionnait, par contre, si je mettais: 12:34:56:78:90:AB, cela n'allait plus.
Le premier octet de l'adresse MAC définit une adresse unicast ou multicast. Pour faire bref, si tu ne veux pas de problèmes, fait toujours démarrer tes @mac par 00, et tu t'éviteras un certain nombre de problèmes. -- Kevin
Le 21-04-2008, mlct <mlct@laposte.net> a écrit :
Ca ne fait que deux mois que la question a été posée, mais bon..
La struture du réseau est la suivante:
- port physique ETH0 relié au bridge virtuel.
- le bridge virtuel est relié au switch virtuelle vde_switch par un
TAP (TAP999)
- ensuite le switch est relié à notre application via TAP0 (avec
process Vdephys2tap).
Notre application reçoit 3 trames provenant du switch (alors que sur
Eth0, on a qu'une seule trame). Si on observe avec Wireshark, il
affiche pourtant qu'une seule trame sur TAP0.
J'ai eu le même genre de constations lorsque j'utilisais des tap0
et des machines qemu.
Un envoi, 'x' réceptions. 'x' étant le nombre de machines qemu.
La solution résidait dans l'adresse MAC que je choisissais pour
mes machines qemu. Si l'adresse MAC était:
00:AB:CD:EF:GH:xx tout fonctionnait, par contre, si je mettais:
12:34:56:78:90:AB, cela n'allait plus.
Le premier octet de l'adresse MAC définit une adresse unicast ou
multicast. Pour faire bref, si tu ne veux pas de problèmes, fait
toujours démarrer tes @mac par 00, et tu t'éviteras un certain nombre
de problèmes.
--
Kevin
Ca ne fait que deux mois que la question a été posée, mais bon..
La struture du réseau est la suivante: - port physique ETH0 relié au bridge virtuel. - le bridge virtuel est relié au switch virtuelle vde_switch par un TAP (TAP999) - ensuite le switch est relié à notre application via TAP0 (avec process Vdephys2tap).
Notre application reçoit 3 trames provenant du switch (alors que sur Eth0, on a qu'une seule trame). Si on observe avec Wireshark, il affiche pourtant qu'une seule trame sur TAP0.
J'ai eu le même genre de constations lorsque j'utilisais des tap0 et des machines qemu. Un envoi, 'x' réceptions. 'x' étant le nombre de machines qemu.
La solution résidait dans l'adresse MAC que je choisissais pour mes machines qemu. Si l'adresse MAC était: 00:AB:CD:EF:GH:xx tout fonctionnait, par contre, si je mettais: 12:34:56:78:90:AB, cela n'allait plus.
Le premier octet de l'adresse MAC définit une adresse unicast ou multicast. Pour faire bref, si tu ne veux pas de problèmes, fait toujours démarrer tes @mac par 00, et tu t'éviteras un certain nombre de problèmes. -- Kevin
Pascal Hambourg
Kevin Denis a écrit :
Ca ne fait que deux mois que la question a été posée, mais bon..
Mieux vaut tard que jamais.
J'ai eu le même genre de constations lorsque j'utilisais des tap0 et des machines qemu. Un envoi, 'x' réceptions. 'x' étant le nombre de machines qemu.
La solution résidait dans l'adresse MAC que je choisissais pour mes machines qemu. Si l'adresse MAC était: 00:AB:CD:EF:GH:xx tout fonctionnait, par contre, si je mettais: 12:34:56:78:90:AB, cela n'allait plus.
Le premier octet de l'adresse MAC définit une adresse unicast ou multicast.
Plus exactement c'est le bit de poids faible du premier octet qui définit une adresse multicast s'il est à 1 et une adresse unicast s'il est à 0. Or si je ne m'abuse dans 12:34:56:78:90:AB ce bit est à 0, donc c'est une adresse unicast qui ne devrait pas poser problème.
Pour faire bref, si tu ne veux pas de problèmes, fait toujours démarrer tes @mac par 00, et tu t'éviteras un certain nombre de problèmes.
Le risque, infime certes, est de tomber sur la même adresse MAC que celle d'un équipement du réseau. Pour éviter cela on peut utiliser des adresses MAC commençant par 02, ce qui indique une adresse définie localement par l'administrateur et non globale attribuée par le fabricant.
Kevin Denis a écrit :
Ca ne fait que deux mois que la question a été posée, mais bon..
Mieux vaut tard que jamais.
J'ai eu le même genre de constations lorsque j'utilisais des tap0
et des machines qemu.
Un envoi, 'x' réceptions. 'x' étant le nombre de machines qemu.
La solution résidait dans l'adresse MAC que je choisissais pour
mes machines qemu. Si l'adresse MAC était:
00:AB:CD:EF:GH:xx tout fonctionnait, par contre, si je mettais:
12:34:56:78:90:AB, cela n'allait plus.
Le premier octet de l'adresse MAC définit une adresse unicast ou
multicast.
Plus exactement c'est le bit de poids faible du premier octet qui
définit une adresse multicast s'il est à 1 et une adresse unicast s'il
est à 0. Or si je ne m'abuse dans 12:34:56:78:90:AB ce bit est à 0, donc
c'est une adresse unicast qui ne devrait pas poser problème.
Pour faire bref, si tu ne veux pas de problèmes, fait
toujours démarrer tes @mac par 00, et tu t'éviteras un certain nombre
de problèmes.
Le risque, infime certes, est de tomber sur la même adresse MAC que
celle d'un équipement du réseau. Pour éviter cela on peut utiliser des
adresses MAC commençant par 02, ce qui indique une adresse définie
localement par l'administrateur et non globale attribuée par le fabricant.
Ca ne fait que deux mois que la question a été posée, mais bon..
Mieux vaut tard que jamais.
J'ai eu le même genre de constations lorsque j'utilisais des tap0 et des machines qemu. Un envoi, 'x' réceptions. 'x' étant le nombre de machines qemu.
La solution résidait dans l'adresse MAC que je choisissais pour mes machines qemu. Si l'adresse MAC était: 00:AB:CD:EF:GH:xx tout fonctionnait, par contre, si je mettais: 12:34:56:78:90:AB, cela n'allait plus.
Le premier octet de l'adresse MAC définit une adresse unicast ou multicast.
Plus exactement c'est le bit de poids faible du premier octet qui définit une adresse multicast s'il est à 1 et une adresse unicast s'il est à 0. Or si je ne m'abuse dans 12:34:56:78:90:AB ce bit est à 0, donc c'est une adresse unicast qui ne devrait pas poser problème.
Pour faire bref, si tu ne veux pas de problèmes, fait toujours démarrer tes @mac par 00, et tu t'éviteras un certain nombre de problèmes.
Le risque, infime certes, est de tomber sur la même adresse MAC que celle d'un équipement du réseau. Pour éviter cela on peut utiliser des adresses MAC commençant par 02, ce qui indique une adresse définie localement par l'administrateur et non globale attribuée par le fabricant.
