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.
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.
Tout à fait, et j'aurais du me relire avant de poster. L'adresse MAC posant problème était: AB:CD:EF:GH:12:34
Mais la conclusion est là: un ping entre deux machines qui ont cette @MAC entourées d'autres machines avec des @MAC du même genre a des résultats stupéfiants: ping qui revient en plusieurs exemplaires, machine qui tombe lorsqu'une seconde envoie un ping, etc, etc..
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx? -- Kevin
Le 25-06-2008, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
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.
Tout à fait, et j'aurais du me relire avant de poster.
L'adresse MAC posant problème était: AB:CD:EF:GH:12:34
Mais la conclusion est là: un ping entre deux machines qui ont cette
@MAC entourées d'autres machines avec des @MAC du même genre a des
résultats stupéfiants:
ping qui revient en plusieurs exemplaires, machine qui tombe
lorsqu'une seconde envoie un ping, etc, etc..
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
--
Kevin
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.
Tout à fait, et j'aurais du me relire avant de poster. L'adresse MAC posant problème était: AB:CD:EF:GH:12:34
Mais la conclusion est là: un ping entre deux machines qui ont cette @MAC entourées d'autres machines avec des @MAC du même genre a des résultats stupéfiants: ping qui revient en plusieurs exemplaires, machine qui tombe lorsqu'une seconde envoie un ping, etc, etc..
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx? -- Kevin
Daniel Dupont
Le 26 juin 2008 à 7h52, Kevin Denis a écrit :
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
En fait c'est le second bit de l'adresse qui, s'il est à 1, fait que l'adresse MAC devient "privée" (Locally administered).
Pour les détails : http://standards.ieee.org/regauth/groupmac/tutorial.html
A+
-- Daniel Dupont
Le 26 juin 2008 à 7h52, Kevin Denis <kevin@nowhere.invalid> a écrit :
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
En fait c'est le second bit de l'adresse qui, s'il est à 1, fait que
l'adresse MAC devient "privée" (Locally administered).
Pour les détails :
http://standards.ieee.org/regauth/groupmac/tutorial.html
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
En fait c'est le second bit de l'adresse qui, s'il est à 1, fait que l'adresse MAC devient "privée" (Locally administered).
Pour les détails : http://standards.ieee.org/regauth/groupmac/tutorial.html
A+
-- Daniel Dupont
Pascal Hambourg
Kevin Denis a écrit :
L'adresse MAC posant problème était: AB:CD:EF:GH:12:34
Mais la conclusion est là: un ping entre deux machines qui ont cette @MAC entourées d'autres machines avec des @MAC du même genre a des résultats stupéfiants: ping qui revient en plusieurs exemplaires, machine qui tombe lorsqu'une seconde envoie un ping, etc, etc..
En fait ce qui m'étonne c'est que le système accepte d'attribuer une adresse multicast à une interface, ce qui est "illégal".
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
Comme l'a précisé Daniel, ce sont les adresses dont le second bit de poids faible du premier octet est à 1. En pratique, les adresses locales unicast ont le premier octet pair mais non multiple de 4 : 02, 06, 0a, 0e, 12... f6, fa, fe.
Kevin Denis a écrit :
L'adresse MAC posant problème était: AB:CD:EF:GH:12:34
Mais la conclusion est là: un ping entre deux machines qui ont cette
@MAC entourées d'autres machines avec des @MAC du même genre a des
résultats stupéfiants:
ping qui revient en plusieurs exemplaires, machine qui tombe
lorsqu'une seconde envoie un ping, etc, etc..
En fait ce qui m'étonne c'est que le système accepte d'attribuer une
adresse multicast à une interface, ce qui est "illégal".
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
Comme l'a précisé Daniel, ce sont les adresses dont le second bit de
poids faible du premier octet est à 1. En pratique, les adresses locales
unicast ont le premier octet pair mais non multiple de 4 : 02, 06, 0a,
0e, 12... f6, fa, fe.
L'adresse MAC posant problème était: AB:CD:EF:GH:12:34
Mais la conclusion est là: un ping entre deux machines qui ont cette @MAC entourées d'autres machines avec des @MAC du même genre a des résultats stupéfiants: ping qui revient en plusieurs exemplaires, machine qui tombe lorsqu'une seconde envoie un ping, etc, etc..
En fait ce qui m'étonne c'est que le système accepte d'attribuer une adresse multicast à une interface, ce qui est "illégal".
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
Comme l'a précisé Daniel, ce sont les adresses dont le second bit de poids faible du premier octet est à 1. En pratique, les adresses locales unicast ont le premier octet pair mais non multiple de 4 : 02, 06, 0a, 0e, 12... f6, fa, fe.
Kevin Denis
Le 26-06-2008, Pascal Hambourg a écrit :
L'adresse MAC posant problème était: AB:CD:EF:GH:12:34
Mais la conclusion est là: un ping entre deux machines qui ont cette @MAC entourées d'autres machines avec des @MAC du même genre a des résultats stupéfiants: ping qui revient en plusieurs exemplaires, machine qui tombe lorsqu'une seconde envoie un ping, etc, etc..
En fait ce qui m'étonne c'est que le système accepte d'attribuer une adresse multicast à une interface, ce qui est "illégal".
J'ai testé avec du linux-2.6 et des qemu pour mettre en cluster mySQL. Peut etre que linux est laxiste sur ce que lui remonte qemu comme hardware.
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
Comme l'a précisé Daniel,
j'en profite pour le remercier ici de son lien.
ce sont les adresses dont le second bit de poids faible du premier octet est à 1. En pratique, les adresses locales unicast ont le premier octet pair mais non multiple de 4 : 02, 06, 0a, 0e, 12... f6, fa, fe.
Ok, j'avais résolu mon problème de manière 'agricole' en utilisant le préfixe d'un constructeur (ce qui marche), mais c'est toujours intéressant de connaitre les raisons du pourquoi du comment. -- Kevin
Le 26-06-2008, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
L'adresse MAC posant problème était: AB:CD:EF:GH:12:34
Mais la conclusion est là: un ping entre deux machines qui ont cette
@MAC entourées d'autres machines avec des @MAC du même genre a des
résultats stupéfiants:
ping qui revient en plusieurs exemplaires, machine qui tombe
lorsqu'une seconde envoie un ping, etc, etc..
En fait ce qui m'étonne c'est que le système accepte d'attribuer une
adresse multicast à une interface, ce qui est "illégal".
J'ai testé avec du linux-2.6 et des qemu pour mettre en cluster mySQL.
Peut etre que linux est laxiste sur ce que lui remonte qemu comme
hardware.
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
Comme l'a précisé Daniel,
j'en profite pour le remercier ici de son lien.
ce sont les adresses dont le second bit de
poids faible du premier octet est à 1. En pratique, les adresses locales
unicast ont le premier octet pair mais non multiple de 4 : 02, 06, 0a,
0e, 12... f6, fa, fe.
Ok, j'avais résolu mon problème de manière 'agricole' en utilisant le
préfixe d'un constructeur (ce qui marche), mais c'est toujours
intéressant de connaitre les raisons du pourquoi du comment.
--
Kevin
L'adresse MAC posant problème était: AB:CD:EF:GH:12:34
Mais la conclusion est là: un ping entre deux machines qui ont cette @MAC entourées d'autres machines avec des @MAC du même genre a des résultats stupéfiants: ping qui revient en plusieurs exemplaires, machine qui tombe lorsqu'une seconde envoie un ping, etc, etc..
En fait ce qui m'étonne c'est que le système accepte d'attribuer une adresse multicast à une interface, ce qui est "illégal".
J'ai testé avec du linux-2.6 et des qemu pour mettre en cluster mySQL. Peut etre que linux est laxiste sur ce que lui remonte qemu comme hardware.
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.
Intéressant à savoir, c'est l'ensemble des 02:xx:xx?
Comme l'a précisé Daniel,
j'en profite pour le remercier ici de son lien.
ce sont les adresses dont le second bit de poids faible du premier octet est à 1. En pratique, les adresses locales unicast ont le premier octet pair mais non multiple de 4 : 02, 06, 0a, 0e, 12... f6, fa, fe.
Ok, j'avais résolu mon problème de manière 'agricole' en utilisant le préfixe d'un constructeur (ce qui marche), mais c'est toujours intéressant de connaitre les raisons du pourquoi du comment. -- Kevin
