J'ai un serveur sur lequel j'ai 2 interfaces ethernet d'installées.
Toutes les 2 configurées en dhcp (voici le fichier
/etc/network/interfaces):
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet dhcp
Pour ne pas vous embrouiller je vais mettre "good" pour eth1 et "bad"
pour eth0
Le probleme:
eth1(bad) et eth0(good)sont connectés:
j'arrive à pinguer l'ip de eth1(bad), jusque la tout va bien.
j'arrive à pinguer l'ip de eth0(good), jusque la tout va bien.
Seule eth0(good)est connecté:
j'arrive à pinguer l'ip de eth0(good), jusque la tout va bien (normal
tjrs connectée).
J'ARRIVE A PINGUER l'ip de eth1(bad), là c'est plus normal (en tout cas
pour moi puisque déconnectée).
Seule eth1(bad) est connecté:
Je ne ping aucune adresse ip ( la aussi pas normal, j'aurai du avoir au
moins l'ip de eth1(bad)).
Voila pour les pings!
Un arp -a(sur un autre psote) me donne pour les 2 adresses ip la meme
adresse mac (celle de eth0(good)) !! Bizzare !!
lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
il indique bien des adresses mac différentes !!
Pourtant voici le resultat des pings depuis un poste windows:
LES PINGS:
C:\>ping 10.96.36.85
Réponse de 10.96.36.85 : octets=32 temps<1ms TTL=64
Réponse de 10.96.36.85 : octets=32 temps<1ms TTL=64
C:\>ping 10.96.36.88
Réponse de 10.96.36.88 : octets=32 temps<1ms TTL=64
Réponse de 10.96.36.88 : octets=32 temps<1ms TTL=64
LE ARP:
C:\>arp -a
Interface : 10.96.36.155 --- 0x2
Adresse Internet Adresse physique Type
10.96.36.85 00-02-55-58-33-4d dynamique
10.96.36.88 00-02-55-58-33-4d dynamique
Vous voyer meme adresse mac pour 2 ip différentes
Pourtant le serveur dhcp m'indique bien des adresses mac différentes pour
chaque carte.
j'ai fais une copie d'écran mais je ne peut pas vous l'envoyer, mais il
indique bien les adresses mac respectif de chaque interface.
J'ai biensur changé la carte 3com meme chose.
J'ai déconnecté la carte intégrée du serveur(amd), en rajoutant la 3com
plus une autre carte, meme phénomene !!
Je ne suis pas sur place là donc je vous laisse quelques infos qui
peuvent vous etres utiles:
VERSION:
# cat /proc/version
Linux version 2.6.8-3-686 (pbuilder@dl360-g3) (gcc version 3.3.5 (Debian
1:3.3.5-13)) #1 Tue Dec 5 21:26:38 UTC 2006
LSPCI:
0000:00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 05)
0000:00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 05)
0000:00:01.0 VGA compatible controller: S3 Inc. Savage 4 (rev 04)
0000:00:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970
[PCnet32 LANCE] (rev 44)
0000:00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f)
0000:00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller
0000:00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller
(rev 04)
0000:01:03.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
0000:01:03.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
0000:01:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro
100] (rev 01)
0000:01:07.0 RAID bus controller: IBM ServeRAID Controller
Une partie de DMESG (si vous voulez tout dite le moi, mais j'ai coupé le
début):
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET: Registered protocol family 8
NET: Registered protocol family 20
ACPI: (supports S0 S4 S5)
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 4768 blocks [1 disk] into ram disk... done.
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 148k freed
vesafb: probe of vesafb0 failed with error -6
NET: Registered protocol family 1
SCSI subsystem initialized
ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 28 (level, low) -> IRQ 201
ACPI: PCI interrupt 0000:01:03.1[B] -> GSI 29 (level, low) -> IRQ 209
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Pour info, la carte AMD utilise le driver pcnet32, la 3com c'est le 3c59x
et l'autre(connais pas la marque):e100
En plein désespoir j'ai changé les cables, connecté sur des commutateurs
différent, booté rebooté re re booté, mis des adresses ip fixes.
Voila si vous voulez d'autre infos n'hésitez pas, car là je suis encore
dans l'incompréhension totale.
Merci de votre aide ou de vos éclaircissement.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Thu, May 24, 2007 at 09:59:17PM +0000, West wrote:
j'ai refait des tests:
- avec cache arp vide ou pas, l'adresse mac de eth0 est quand meme retournée, malgré un ping sur l'ip de eth1. (j'au aussi supprimé manuellement) - avec tcpdump je confirme bien que c'est eth0 qui répond a un ping su
r
eth1.
on ne ping pas une interface, mais une adresse IP. Comme l'a mentionne Pascal precedemment, une adresse IP n'appartient pas a une interface ; de ce fait une interface peut repondre a plusieurs adresse IP.
oui t'as raison de le préciser, j'assayer de résumer, mais c'est que j'aurai du écrire les choses comme il le faut.
- tcpdump sur eth1, il ne recoit rien, pourtant je ping bien sur son ip quand je dis qu'il ne recoit rien je m'explique, la requete arp demandant
l'adresse mac de son ip lui arrive bien, mais il ne réponds pas comme s
i
cela ne lui concernait pas.
Mais tu viens de dire que le client qui avait fait le ping recevait bien une reponse echo-reply ! Je suppose que tu veux dire que eth1 reponds alors que tu t'attendais a ce que ce soit eth0. (idem paragraphe precedent).
non c'est eth0 qui répond a l'adresse ip de eth1, je pingais sur l'adrr ip de eth1 et eth0 répondait. et le tcpdum sur eth1 montrait qu'il revcevait bien la requette arp(comme toutes les interfaces du réseau), mais ne la prenait en compte alors que l'adresse ip demandé par le client (via arp) était la sienne
- Si je déconnecte eth0 je ne ping rien du tout, meme si je ping l'ip d
e
eth1 qui est connecté je n'arrive à joindre ni l'un ni l'autre . Si quelqu'un me donne un réponse a se comportement, je lui dis un gros
merci d'avance !!
Avec le cache ARP vide du cote client ?
- En gros le serveur se comporte comme si l'interface eth1 n'existait pas
et que eth0 était la seul interface configurée avec 2 adresses ip. Ca
c'est le comportement global.
Il faudrait attribuer une interface pour un reseau prive specifique et tester de cette maniere ; Il faurait les decoupler et bien les separer pour voir si le probleme est reel et si c'est plus un probleme de comprehension. Cela ne devrait pas etre trop difficile a teste :p!
si je l'ai testé, voir réponse juste en dessous :) je l'ai ai mis sur des réseau privé différent et là ca marche
- j'ai changé l'ip de eth1 pour la placer sur un réseau différent d
e
eth0, j'arrive à le pingué.
Cela ne me parait pas anormal.
PS: je vous met la table de routage que j'avais oublié qui a peut etre la
reponse car je vois 2 localnet:
Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use
Iface localnet * 255.255.255.0 U 0 0 0
eth0 localnet * 255.255.255.0 U 0 0 0
eth1 10.96.38.0 10.96.36.254 255.255.255.0 UG 0 0 0
eth0
Si tu mets la gateway sur l'interface eth1 et non plus sur eth0, cela devrait inverser la tendance que tu as constate. Du moins je le pense.
Petite question : le mask dans la table de routage sur la ligne definissant le gateway ne devrait-il pas etre 0.0.0.0 ?
il n ya pas de gateway
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le 25.05 2007, Franck Joncourt ecrit ces mots :
On Thu, May 24, 2007 at 09:59:17PM +0000, West wrote:
j'ai refait des tests:
- avec cache arp vide ou pas, l'adresse mac de eth0 est quand meme
retournée, malgré un ping sur l'ip de eth1. (j'au aussi supprimé
manuellement)
- avec tcpdump je confirme bien que c'est eth0 qui répond a un ping
su
r
eth1.
on ne ping pas une interface, mais une adresse IP. Comme l'a mentionne
Pascal precedemment, une adresse IP n'appartient pas a une interface ;
de ce fait une interface peut repondre a plusieurs adresse IP.
oui t'as raison de le préciser, j'assayer de résumer, mais c'est que
j'aurai du écrire les choses comme il le faut.
- tcpdump sur eth1, il ne recoit rien, pourtant je ping bien sur son
ip quand je dis qu'il ne recoit rien je m'explique, la requete arp
demandant
l'adresse mac de son ip lui arrive bien, mais il ne réponds pas comme
s
i
cela ne lui concernait pas.
Mais tu viens de dire que le client qui avait fait le ping recevait
bien une reponse echo-reply ! Je suppose que tu veux dire que eth1
reponds alors que tu t'attendais a ce que ce soit eth0. (idem
paragraphe precedent).
non c'est eth0 qui répond a l'adresse ip de eth1, je pingais sur l'adrr
ip de eth1 et eth0 répondait.
et le tcpdum sur eth1 montrait qu'il revcevait bien la requette arp(comme
toutes les interfaces du réseau), mais ne la prenait en compte alors que
l'adresse ip demandé par le client (via arp) était la sienne
- Si je déconnecte eth0 je ne ping rien du tout, meme si je ping l'ip
d
e
eth1 qui est connecté je n'arrive à joindre ni l'un ni l'autre .
Si quelqu'un me donne un réponse a se comportement, je lui dis un
gros
merci d'avance !!
Avec le cache ARP vide du cote client ?
- En gros le serveur se comporte comme si l'interface eth1 n'existait
pas
et que eth0 était la seul interface configurée avec 2 adresses ip. Ca
c'est le comportement global.
Il faudrait attribuer une interface pour un reseau prive specifique et
tester de cette maniere ; Il faurait les decoupler et bien les separer
pour voir si le probleme est reel et si c'est plus un probleme de
comprehension. Cela ne devrait pas etre trop difficile a teste :p!
si je l'ai testé, voir réponse juste en dessous :)
je l'ai ai mis sur des réseau privé différent et là ca marche
- j'ai changé l'ip de eth1 pour la placer sur un réseau différent d
e
eth0, j'arrive à le pingué.
Cela ne me parait pas anormal.
PS:
je vous met la table de routage que j'avais oublié qui a peut etre la
reponse car je vois 2 localnet:
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref
Use
Iface
localnet * 255.255.255.0 U 0 0
0
eth0
localnet * 255.255.255.0 U 0 0
0
eth1
10.96.38.0 10.96.36.254 255.255.255.0 UG 0 0
0
eth0
Si tu mets la gateway sur l'interface eth1 et non plus sur eth0, cela
devrait inverser la tendance que tu as constate. Du moins je le pense.
Petite question : le mask dans la table de routage sur la ligne
definissant le gateway ne devrait-il pas etre 0.0.0.0 ?
il n ya pas de gateway
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Thu, May 24, 2007 at 09:59:17PM +0000, West wrote:
j'ai refait des tests:
- avec cache arp vide ou pas, l'adresse mac de eth0 est quand meme retournée, malgré un ping sur l'ip de eth1. (j'au aussi supprimé manuellement) - avec tcpdump je confirme bien que c'est eth0 qui répond a un ping su
r
eth1.
on ne ping pas une interface, mais une adresse IP. Comme l'a mentionne Pascal precedemment, une adresse IP n'appartient pas a une interface ; de ce fait une interface peut repondre a plusieurs adresse IP.
oui t'as raison de le préciser, j'assayer de résumer, mais c'est que j'aurai du écrire les choses comme il le faut.
- tcpdump sur eth1, il ne recoit rien, pourtant je ping bien sur son ip quand je dis qu'il ne recoit rien je m'explique, la requete arp demandant
l'adresse mac de son ip lui arrive bien, mais il ne réponds pas comme s
i
cela ne lui concernait pas.
Mais tu viens de dire que le client qui avait fait le ping recevait bien une reponse echo-reply ! Je suppose que tu veux dire que eth1 reponds alors que tu t'attendais a ce que ce soit eth0. (idem paragraphe precedent).
non c'est eth0 qui répond a l'adresse ip de eth1, je pingais sur l'adrr ip de eth1 et eth0 répondait. et le tcpdum sur eth1 montrait qu'il revcevait bien la requette arp(comme toutes les interfaces du réseau), mais ne la prenait en compte alors que l'adresse ip demandé par le client (via arp) était la sienne
- Si je déconnecte eth0 je ne ping rien du tout, meme si je ping l'ip d
e
eth1 qui est connecté je n'arrive à joindre ni l'un ni l'autre . Si quelqu'un me donne un réponse a se comportement, je lui dis un gros
merci d'avance !!
Avec le cache ARP vide du cote client ?
- En gros le serveur se comporte comme si l'interface eth1 n'existait pas
et que eth0 était la seul interface configurée avec 2 adresses ip. Ca
c'est le comportement global.
Il faudrait attribuer une interface pour un reseau prive specifique et tester de cette maniere ; Il faurait les decoupler et bien les separer pour voir si le probleme est reel et si c'est plus un probleme de comprehension. Cela ne devrait pas etre trop difficile a teste :p!
si je l'ai testé, voir réponse juste en dessous :) je l'ai ai mis sur des réseau privé différent et là ca marche
- j'ai changé l'ip de eth1 pour la placer sur un réseau différent d
e
eth0, j'arrive à le pingué.
Cela ne me parait pas anormal.
PS: je vous met la table de routage que j'avais oublié qui a peut etre la
reponse car je vois 2 localnet:
Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use
Iface localnet * 255.255.255.0 U 0 0 0
eth0 localnet * 255.255.255.0 U 0 0 0
eth1 10.96.38.0 10.96.36.254 255.255.255.0 UG 0 0 0
eth0
Si tu mets la gateway sur l'interface eth1 et non plus sur eth0, cela devrait inverser la tendance que tu as constate. Du moins je le pense.
Petite question : le mask dans la table de routage sur la ligne definissant le gateway ne devrait-il pas etre 0.0.0.0 ?
il n ya pas de gateway
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
West
Le 25.05 2007, =?utf-8?Q?François?= TOURDE ecrit ces mots :
je testerai le down Pour le réseau différant c'est déjà testé et ca marche Mais bon c'est juste pour comprendre, je cherche pas spécialement a faire tourner le serveur avec de interface sur le meme réseau.
ok, ca j'ai compris, mais si je veux avoir une 2eme interface pour je ne sais quoi (supervision, failover) je risque d'avoir un souci si eth0 est hs, non ? comment faire dans ce cas ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le 25.05 2007, =?utf-8?Q?François?= TOURDE ecrit ces mots :
je testerai le down
Pour le réseau différant c'est déjà testé et ca marche
Mais bon c'est juste pour comprendre, je cherche pas spécialement a faire
tourner le serveur avec de interface sur le meme réseau.
ok, ca j'ai compris, mais si je veux avoir une 2eme interface pour je ne
sais quoi (supervision, failover) je risque d'avoir un souci si eth0 est
hs, non ?
comment faire dans ce cas ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
je testerai le down Pour le réseau différant c'est déjà testé et ca marche Mais bon c'est juste pour comprendre, je cherche pas spécialement a faire tourner le serveur avec de interface sur le meme réseau.
ok, ca j'ai compris, mais si je veux avoir une 2eme interface pour je ne sais quoi (supervision, failover) je risque d'avoir un souci si eth0 est hs, non ? comment faire dans ce cas ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
mouss
west wrote:
Bonsoir,
J'ai un serveur sur lequel j'ai 2 interfaces ethernet d'installées. Toutes les 2 configurées en dhcp (voici le fichier /etc/network/interfaces):
# The loopback network interface auto lo iface lo inet loopback
# The primary network interface auto eth0 iface eth0 inet dhcp
auto eth1 iface eth1 inet dhcp
Pour ne pas vous embrouiller je vais mettre "good" pour eth1 et "bad" pour eth0
Le probleme:
eth1(bad) et eth0(good)sont connectés: j'arrive à pinguer l'ip de eth1(bad), jusque la tout va bien. j'arrive à pinguer l'ip de eth0(good), jusque la tout va bien.
Seule eth0(good)est connecté: j'arrive à pinguer l'ip de eth0(good), jusque la tout va bien (normal tjrs connectée). J'ARRIVE A PINGUER l'ip de eth1(bad), là c'est plus normal (en tout cas pour moi puisque déconnectée).
Seule eth1(bad) est connecté: Je ne ping aucune adresse ip ( la aussi pas normal, j'aurai du avoir au moins l'ip de eth1(bad)).
Voila pour les pings!
Un arp -a(sur un autre psote) me donne pour les 2 adresses ip la meme adresse mac (celle de eth0(good)) !! Bizzare !!
Une règle de tranquilité: soit tu mets les IPs dans des réseaux differents, soit tu changes le netmask de l'une des cartes. si tu veux implementer une fonctionallité spécifique avec la config ci-dessus, il faudra plus "que ça"... (la, il faudrait regarder du cote de policy routing ou d'autres trucs plus ou moins tordus).
- par defaut, les système bsd, linux, ... implementent le "weak model": on accepte les paquets destinés à l'une des IPs de la machine, quelle que soit l'interface par laquelles ces paquest arrivent (à l'exeception des paquest avec 127.0.0.* comme adresse source ou destination: la, le traitement depend de l'implementation. il est sain de les droper car ces adresses n'ont rien à faire sur le reseau).
- lorsque ton systeme envoie des paquets, et que ces paquets n'ont pas d'IP source (l'application n'en a pas mis). le système trouve la route en fonctionde la _destination_, une fois la route trouvée, il determine l'interface de sortie. dans ton cas, c'est forcément eth0. et puis il balance le paquet.
- idem pour arp. le systeme dit "c'est à moi cette IP", et les autres voient l'adresse MAC de eth0...
avec ta config, tu peux avoir des trucs bizarres: si tu forces l'adresse MAC sur une autre machine, et si tu branches les deux cartes, tu vas faire un circuit fermé (les paquest rentrent par eth1 et sortent par eth0). c'est joli, mais est-ce utile...
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
west wrote:
Bonsoir,
J'ai un serveur sur lequel j'ai 2 interfaces ethernet d'installées.
Toutes les 2 configurées en dhcp (voici le fichier
/etc/network/interfaces):
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet dhcp
Pour ne pas vous embrouiller je vais mettre "good" pour eth1 et "bad"
pour eth0
Le probleme:
eth1(bad) et eth0(good)sont connectés:
j'arrive à pinguer l'ip de eth1(bad), jusque la tout va bien.
j'arrive à pinguer l'ip de eth0(good), jusque la tout va bien.
Seule eth0(good)est connecté:
j'arrive à pinguer l'ip de eth0(good), jusque la tout va bien (normal
tjrs connectée).
J'ARRIVE A PINGUER l'ip de eth1(bad), là c'est plus normal (en tout cas
pour moi puisque déconnectée).
Seule eth1(bad) est connecté:
Je ne ping aucune adresse ip ( la aussi pas normal, j'aurai du avoir au
moins l'ip de eth1(bad)).
Voila pour les pings!
Un arp -a(sur un autre psote) me donne pour les 2 adresses ip la meme
adresse mac (celle de eth0(good)) !! Bizzare !!
Une règle de tranquilité: soit tu mets les IPs dans des réseaux
differents, soit tu changes le netmask de l'une des cartes. si tu veux
implementer une fonctionallité spécifique avec la config ci-dessus, il
faudra plus "que ça"... (la, il faudrait regarder du cote de policy
routing ou d'autres trucs plus ou moins tordus).
- par defaut, les système bsd, linux, ... implementent le "weak model":
on accepte les paquets destinés à l'une des IPs de la machine, quelle
que soit l'interface par laquelles ces paquest arrivent (à l'exeception
des paquest avec 127.0.0.* comme adresse source ou destination: la, le
traitement depend de l'implementation. il est sain de les droper car ces
adresses n'ont rien à faire sur le reseau).
- lorsque ton systeme envoie des paquets, et que ces paquets n'ont pas
d'IP source (l'application n'en a pas mis). le système trouve la route
en fonctionde la _destination_, une fois la route trouvée, il determine
l'interface de sortie. dans ton cas, c'est forcément eth0. et puis il
balance le paquet.
- idem pour arp. le systeme dit "c'est à moi cette IP", et les autres
voient l'adresse MAC de eth0...
avec ta config, tu peux avoir des trucs bizarres: si tu forces l'adresse
MAC sur une autre machine, et si tu branches les deux cartes, tu vas
faire un circuit fermé (les paquest rentrent par eth1 et sortent par
eth0). c'est joli, mais est-ce utile...
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
J'ai un serveur sur lequel j'ai 2 interfaces ethernet d'installées. Toutes les 2 configurées en dhcp (voici le fichier /etc/network/interfaces):
# The loopback network interface auto lo iface lo inet loopback
# The primary network interface auto eth0 iface eth0 inet dhcp
auto eth1 iface eth1 inet dhcp
Pour ne pas vous embrouiller je vais mettre "good" pour eth1 et "bad" pour eth0
Le probleme:
eth1(bad) et eth0(good)sont connectés: j'arrive à pinguer l'ip de eth1(bad), jusque la tout va bien. j'arrive à pinguer l'ip de eth0(good), jusque la tout va bien.
Seule eth0(good)est connecté: j'arrive à pinguer l'ip de eth0(good), jusque la tout va bien (normal tjrs connectée). J'ARRIVE A PINGUER l'ip de eth1(bad), là c'est plus normal (en tout cas pour moi puisque déconnectée).
Seule eth1(bad) est connecté: Je ne ping aucune adresse ip ( la aussi pas normal, j'aurai du avoir au moins l'ip de eth1(bad)).
Voila pour les pings!
Un arp -a(sur un autre psote) me donne pour les 2 adresses ip la meme adresse mac (celle de eth0(good)) !! Bizzare !!
Une règle de tranquilité: soit tu mets les IPs dans des réseaux differents, soit tu changes le netmask de l'une des cartes. si tu veux implementer une fonctionallité spécifique avec la config ci-dessus, il faudra plus "que ça"... (la, il faudrait regarder du cote de policy routing ou d'autres trucs plus ou moins tordus).
- par defaut, les système bsd, linux, ... implementent le "weak model": on accepte les paquets destinés à l'une des IPs de la machine, quelle que soit l'interface par laquelles ces paquest arrivent (à l'exeception des paquest avec 127.0.0.* comme adresse source ou destination: la, le traitement depend de l'implementation. il est sain de les droper car ces adresses n'ont rien à faire sur le reseau).
- lorsque ton systeme envoie des paquets, et que ces paquets n'ont pas d'IP source (l'application n'en a pas mis). le système trouve la route en fonctionde la _destination_, une fois la route trouvée, il determine l'interface de sortie. dans ton cas, c'est forcément eth0. et puis il balance le paquet.
- idem pour arp. le systeme dit "c'est à moi cette IP", et les autres voient l'adresse MAC de eth0...
avec ta config, tu peux avoir des trucs bizarres: si tu forces l'adresse MAC sur une autre machine, et si tu branches les deux cartes, tu vas faire un circuit fermé (les paquest rentrent par eth1 et sortent par eth0). c'est joli, mais est-ce utile...
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Si tu crains que ta carte reseau ne passe l'arme a gauche, mais que tu veux eviter du meme coup que ton reseau ne tombe, il faut regarder du channel bonding.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Si tu crains que ta carte reseau ne passe l'arme a gauche, mais que tu
veux eviter du meme coup que ton reseau ne tombe, il faut regarder du
channel bonding.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Si tu crains que ta carte reseau ne passe l'arme a gauche, mais que tu veux eviter du meme coup que ton reseau ne tombe, il faut regarder du channel bonding.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Thu, May 24, 2007 at 11:41:02PM +0000, West wrote:
>> Iface >> localnet * 255.255.255.0 U 0 0 >> 0 > >> eth0 >> localnet * 255.255.255.0 U 0 0 >> 0 > >> eth1 >> 10.96.38.0 10.96.36.254 255.255.255.0 UG 0 0 >> 0 > >> eth0 > > Si tu mets la gateway sur l'interface eth1 et non plus sur eth0, cela > devrait inverser la tendance que tu as constate. Du moins je le pense. > > Petite question : le mask dans la table de routage sur la ligne > definissant le gateway ne devrait-il pas etre 0.0.0.0 ? > il n ya pas de gateway
'G' comme gateway. Ton serveur DHCP doit bien fournir une gateway a ce poste, non ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Thu, May 24, 2007 at 11:41:02PM +0000, West wrote:
>> Iface
>> localnet * 255.255.255.0 U 0 0
>> 0
>
>> eth0
>> localnet * 255.255.255.0 U 0 0
>> 0
>
>> eth1
>> 10.96.38.0 10.96.36.254 255.255.255.0 UG 0 0
>> 0
>
>> eth0
>
> Si tu mets la gateway sur l'interface eth1 et non plus sur eth0, cela
> devrait inverser la tendance que tu as constate. Du moins je le pense.
>
> Petite question : le mask dans la table de routage sur la ligne
> definissant le gateway ne devrait-il pas etre 0.0.0.0 ?
>
il n ya pas de gateway
'G' comme gateway. Ton serveur DHCP doit bien fournir une gateway a ce
poste, non ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Thu, May 24, 2007 at 11:41:02PM +0000, West wrote:
>> Iface >> localnet * 255.255.255.0 U 0 0 >> 0 > >> eth0 >> localnet * 255.255.255.0 U 0 0 >> 0 > >> eth1 >> 10.96.38.0 10.96.36.254 255.255.255.0 UG 0 0 >> 0 > >> eth0 > > Si tu mets la gateway sur l'interface eth1 et non plus sur eth0, cela > devrait inverser la tendance que tu as constate. Du moins je le pense. > > Petite question : le mask dans la table de routage sur la ligne > definissant le gateway ne devrait-il pas etre 0.0.0.0 ? > il n ya pas de gateway
'G' comme gateway. Ton serveur DHCP doit bien fournir une gateway a ce poste, non ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
