Comportement bizzare de eth0 et eth1

Le
west
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 !!

Pourtant un ifconfig me donne:
~# ifconfig
eth0 Lien encap:Ethernet HWaddr 00:02:55:58:33:4D
inet adr:10.96.36.88 Bcast:10.96.36.255 Masque:255.255.255.0
adr inet6: fe80::202:55ff:fe58:334d/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:254 errors:0 dropped:0 overruns:0 frame:0
TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:22819 (22.2 KiB) TX bytes:9418 (9.1 KiB)
Interruption:193 Adresse de base:0x2000

eth1 Lien encap:Ethernet HWaddr 00:AA:00:CA:8F:80
inet adr:10.96.36.85 Bcast:10.96.36.255 Masque:255.255.255.0
adr inet6: fe80::2aa:ff:feca:8f80/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:166 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:12588 (12.2 KiB) TX bytes:1062 (1.0 KiB)

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 : octets2 temps<1ms TTLd
Réponse de 10.96.36.85 : octets2 temps<1ms TTLd

C:>ping 10.96.36.88
Réponse de 10.96.36.88 : octets2 temps<1ms TTLd
Réponse de 10.96.36.88 : octets2 temps<1ms TTLd

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

Using anticipatory io scheduler
(scsi0:A:0): 10.000MB/s transfers (10.000MHz, offset 15)
Vendor: ARCHIVE Model: Python 04106-XXX Rev: 758B
Type: Sequential-Access ANSI SCSI revision: 02
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

ACPI: PCI interrupt 0000:01:07.0[A] -> GSI 24 (level, low) -> IRQ 225
ips 0000:01:07.0: Warning ! ! ! ServeRAID Version Mismatch
ips 0000:01:07.0: Bios = 4.70.17, Firmware = 4.70.17, Device Driver =
7.00.15
ips 0000:01:07.0: These levels should match to avoid possible
compatibility problems.
scsi2 : IBM PCI ServeRAID 7.00.15 Build 625 <ServeRAID 4L>
Vendor: IBM Model: SERVERAID Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 02
Vendor: IBM Model: SERVERAID Rev: 1.00
Type: Processor ANSI SCSI revision: 02
Vendor: IBM Model: CaVv3 S2 Rev: 0
Type: Processor ANSI SCSI revision: 02
ACPI: Processor [CPU0] (supports C1)
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
ACPI: PCI interrupt 0000:00:0f.2[A] -> GSI 11 (level, low) -> IRQ 11
ohci_hcd 0000:00:0f.2: ServerWorks OSB4/CSB5 OHCI USB Controller
ohci_hcd 0000:00:0f.2: irq 11, pci mem e082b000
ohci_hcd 0000:00:0f.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
usbcore: registered new driver usbkbd
drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
drivers/usb/serial/usb-serial.c: USB Serial support registered for
Generic
usbcore: registered new driver usbserial_generic
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
vga16fb: initializing
vga16fb: mapped to 0xc00a0000
fb0: VGA16 VGA frame buffer device
Console: switching to colour frame buffer device 80x30
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
Initializing USB Mass Storage driver
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
inserting floppy driver for 2.6.8-3-686
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
SvrWks OSB4: IDE controller at PCI slot 0000:00:0f.1
SvrWks OSB4: chipset revision 0
SvrWks OSB4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x0840-0x0847, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x0848-0x084f, BIOS settings: hdc:pio, hdd:pio
hda: LTN486S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: ATAPI 48X CD-ROM drive, 120kB Cache, (U)DMA
Uniform CD-ROM driver Revision: 3.20
pcnet32.c:v1.30i 06.28.2004 tsbogend@alpha.franken.de
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 27 (level, low) -> IRQ 193
pcnet32: PCnet/FAST III 79C975 at 0x2000, 00 02 55 58 33 4d assigned IRQ
193.
eth0: registered as PCnet/FAST III 79C975
pcnet32: 1 cards_found.
SCSI device sda: 71094272 512-byte hdwr sectors (36400 MB)
SCSI device sda: drive cache: write through
/dev/scsi/host2/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 >
Attached scsi disk sda at scsi2, channel 0, id 0, lun 0
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Adding 979956k swap on /dev/sda2. Priority:-1 extents:1
EXT3 FS on sda3, internal journal
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
Capability LSM initialized
mice: PS/2 mouse device common for all mice
ts: Compaq touchscreen protocol output
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
e100: Intel(R) PRO/100 Network Driver, 3.0.18
e100: Copyright(c) 1999-2004 Intel Corporation
ACPI: PCI interrupt 0000:01:05.0[A] -> GSI 20 (level, low) -> IRQ 217
e100: eth1: e100_probe: addr 0xefffd000, irq 217, MAC addr
00:AA:00:CA:8F:80
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: unable to determine aperture size.
agpgart: agp_backend_initialize() failed.
agpgart-serverworks: probe of 0000:00:00.0 failed with error -22
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: unable to determine aperture size.
agpgart: agp_backend_initialize() failed.
agpgart-serverworks: probe of 0000:00:00.1 failed with error -22
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]
input: PC Speaker
Real Time Clock Driver v1.12
st: Version 20040403, fixed bufsize 32768, s/g segs 256
Attached scsi tape st0 at scsi0, channel 0, id 0, lun 0
st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA
1048575
eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
NET: Registered protocol family 17
e100: eth1: e100_watchdog: link up, 100Mbps, full-duplex
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0300140(lo)
IPv6 over IPv4 tunneling driver
eth1: no IPv6 routers present
eth0: no IPv6 routers present


Et pour finir LSMOD:

# lsmod
Module Size Used by
ipv6 265124 12
af_packet 22600 4
st 40316 0
rtc 12760 0
pcspkr 3592 0
parport_pc 36900 0
parport 41800 1 parport_pc
aic79xx 308572 0
sworks_agp 9344 0
agpgart 34664 1 sworks_agp
e100 32608 0
tsdev 7392 0
mousedev 10476 0
evdev 9600 0
capability 4520 0
commoncap 7232 1 capability
psmouse 20360 0
ext3 127432 6
jbd 62616 1 ext3
mbcache 9348 1 ext3
sd_mod 21728 8
3c59x 39400 0
pcnet32 29000 0
mii 5120 2 e100,pcnet32
ide_cd 42656 0
cdrom 40732 1 ide_cd
ide_disk 19296 0
ide_generic 1408 0
pdc202xx_new 11036 0
aec62xx 10588 0
alim15x3 12492 0
amd74xx 14620 0
atiixp 8920 0
cmd64x 12764 0
cs5520 6504 0
cs5530 6920 0
cy82c693 5124 0
generic 4416 0
hpt34x 5952 0
ns87415 5032 0
opti621 5028 0
pdc202xx_old 16892 0
piix 13440 0
rz1000 2976 0
sc1200 9000 0
serverworks 13268 1
siimage 13472 0
sis5513 17000 0
slc90e66 8616 0
triflex 5444 0
trm290 4804 0
via82cxxx 14332 0
floppy 61200 0
usb_storage 69056 0
ide_core 139940 28
ide_cd,ide_disk,ide_generic,pdc202xx_new,aec62xx,alim15x3,amd74xx,atiixp,
cmd64x,cs5520,cs5530,cy82c693,generic,hpt34x,ns87415,opti621,pdc202xx_old
,piix,rz1000,sc1200,serverworks,siimage,sis5513,slc90e66,triflex,trm290,v
ia82cxxx,usb_storage
fbcon 32100 70
vga16fb 13160 1
vgastate 10048 1 vga16fb
usbserial 29896 0
usbhid 32224 0
usbkbd 7424 0
ohci_hcd 21764 0
usbcore 119044 7
usb_storage,usbserial,usbhid,usbkbd,ohci_hcd
thermal 12656 0
processor 17264 1 thermal
fan 3980 0
ips 50556 7
aic7xxx 206392 0
scsi_mod 125228 6 st,aic79xx,sd_mod,usb_storage,ips,aic7xxx
unix 28788 16
font 8320 1 fbcon
vesafb 6656 0
cfbcopyarea 3872 2 vga16fb,vesafb
cfbimgblt 3040 2 vga16fb,vesafb
cfbfillrect 3776 2 vga16fb,vesafb


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
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #9553601
Salut,

west a écrit :

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



C'est raté : deux lignes plus bas tu écris exactement le contraire !

Le probleme:

eth1(bad) et eth0(good)sont connectés:



Au même réseau si j'en crois la sortie d'ifconfig. Ce qui est une
mauvaise idée à moins de savoir exactement ce qu'on fait, et d'où le
comportement que tu observes.

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).



Peu importe que l'interface soit connectée, du moment qu'elle est
activée et configurée. Une adresse IP configurée sur une interface
active appartient à la machine tout entière et pas seulement à cette
interface. Par conséquent, la machine peut recevoir et répondre sur
cette adresse par l'autre interface, qui plus est sur le même réseau. Et
c'est pareil pour la résolution ARP : par défaut n'importe quelle
interface peut répondre pour n'importe quelle adresse locale, à moins de
régler quelques paramètres du noyau dans
/proc/sys/net/ipv4/conf/<interface>,all comme arp_announce, arp_filter
et/ou arp_ignore. Cf. networking/ip-sysctl.txt(.gz) dans la
documentation du noyau. Du coup l'interface qui reste connectée répond
pour les deux adresses.

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)).



Tu n'as probablement pas attendu assez longtemps, le temps que le cache
ARP de la machine source expire. Par conséquent elle continue à envoyer
les paquets à l'adresse MAC d'eth0 qui est maintenant déconnectée.

Un arp -a(sur un autre psote) me donne pour les 2 adresses ip la meme
adresse mac (celle de eth0(good))



Voilà, comme je disais.

!! Bizzare !!



Je ne trouve pas.


--
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
BARBIER Jean-Matthieu
Le #9553591
--nextPart8945981.dIqaNV6lUX
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le Thursday 24 May 2007 00:23:50 west, vous avez écrit :


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 commuta teurs
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 enco re
dans l'incompréhension totale.
Merci de votre aide ou de vos éclaircissement.





j'ai bien lu jusqu'au bout, et je n'ai pas de solution...

pb hard ou pb soft ?..?

une idée pour circonscrire les pbs :

- en mettant des ip fixes à partir d'un live cd genre knoppix, et en pi nguant
avec un simple cable croisé et une machine saine en face, on restreint un peu
plus le problème, en éliminant les pbs de dhcp, de routeur, de config
spécifique de ta machine..

si ça marche pas comme ça, c'est un truc louche mais je sais pas quoi.. .
(bios ? CM ? j'ai pas trop compris tes changements de cartes...)

a suivre...


@+
JMB

--nextPart8945981.dIqaNV6lUX
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGVMxa+cj6VhfIEVgRAtOwAJ99grQfmqv3thfBvwwSiFpGheknmwCfVZAb
DkUu18fghKrLelutUSfeBZ8 =ldi8
-----END PGP SIGNATURE-----

--nextPart8945981.dIqaNV6lUX--


--
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
Pascal Hambourg
Le #9553581
Pascal Hambourg a écrit :

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)).



Tu n'as probablement pas attendu assez longtemps, le temps que le cache
ARP de la machine source expire. Par conséquent elle continue à envoyer
les paquets à l'adresse MAC d'eth0 qui est maintenant déconnectée.



Une autre explication possible :
Comme la machine a deux interfaces avec deux adresses dans le même
sous-réseau, elle a deux routes directe vers ce sous-réseau, une via
chacune des deux interface. Cependant une seule de ces deux route, et
donc une seule interface, est effectivement utilisée pour émettre vers
une adresse de ce sous-réseau. Par conséquent pas de réponse possible si
cette interface est déconnectée.


--
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
fra-duf-no-spam
Le #9553511
Le 13657ième jour après Epoch,
écrivait:

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



Mauvaise idée, tu t'embrouilles toi même sur le coup :)

[... Tout plein de trucs compliqués, auxquels il manque l'analyse de
sang ...]

Voila si vous voulez d'autre infos n'hésitez pas, car là je sui s encore
dans l'incompréhension totale.
Merci de votre aide ou de vos éclaircissement.



Pourtant tout est normal. Tout d'abord tu ne dis pas d'où tu ping dans
les premiers tests, mais c'est pas trop grave.

Les deux cartes sont sur le même sous-réseau. C'est risqué v oire
inutile.

Si ta machine est configurée pour faire de l'IP Forwarding, alors
n'importe laquelle des interface va répondre pour l'autre si elle
reçoit un paquet qui lui est destiné (à l'autre, hein?).

Les IP de la machine appartiennent à la machine, donc:

A <------> eth0 machine eth1 <------> B

Si A pingue l'ip de eth0 ou l'ip de eth1, c'est eth0 qui va répondre
en général.

Idem pour B

Par contre, tout cela peut ne pas marcher selon les routes par défaut,
le fait que eth0 et eth1 soient ou non reliées sur un même switch,
etc..
West
Le #9553161
Le 24.05 2007, Pascal Hambourg ecrit ces mots :

Salut,

west a écrit :

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



C'est raté : deux lignes plus bas tu écris exactement le contraire !



Oupppss !!

Le probleme:

eth1(bad) et eth0(good)sont connectés:



Au même réseau si j'en crois la sortie d'ifconfig. Ce qui est une
mauvaise idée à moins de savoir exactement ce qu'on fait, et d'où le
comportement que tu observes.



oui le meme réseau, pour le moment, mais apres la 2eme interface sera
connecté sur un autre réseau local.
je vérifiais juste que la 2eme carte fonctionnait avant de placer le
serveur sur les 2 LANs

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).



Peu importe que l'interface soit connectée, du moment qu'elle est
activée et configurée. Une adresse IP configurée sur une interface
active appartient à la machine tout entière et pas seulement à cette
interface. Par conséquent, la machine peut recevoir et répondre sur
cette adresse par l'autre interface, qui plus est sur le même réseau.


Et
c'est pareil pour la résolution ARP : par défaut n'importe quelle
interface peut répondre pour n'importe quelle adresse locale, à moins


de
régler quelques paramètres du noyau dans
/proc/sys/net/ipv4/conf/<interface>,all comme arp_announce, arp_filter
et/ou arp_ignore. Cf. networking/ip-sysctl.txt(.gz) dans la
documentation du noyau. Du coup l'interface qui reste connectée répond
pour les deux adresses.



Oui je comprends ton explication, mais j'ai toujours penser qu'une carte
normalement configurée, n'acceptait que les adresses qui lui sont propres
+ les diffusions ( Il me semble que c'est le protocole Arp qui définit ce
comportement) et le localhost répondait a toutes les adresses ip du
poste.
D'oû mon étonnement de ce comportement, ont m'aurait menti ?

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)).



Tu n'as probablement pas attendu assez longtemps, le temps que le cache
ARP de la machine source expire. Par conséquent elle continue à envoyer
les paquets à l'adresse MAC d'eth0 qui est maintenant déconnectée.



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 sur
eth1.

- 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 si
cela ne lui concernait pas.

- Si je déconnecte eth0 je ne ping rien du tout, meme si je ping l'ip de
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 !!

- 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.

- pour info: j'ai pas de ip forwarding d'activé (c'est l'une des
premieres choses que j'avais vérifié).


- j'ai changé l'ip de eth1 pour la placer sur un réseau différent de
eth0, j'arrive à le pingué.
Donc on a bien ce comportement lorsque les 2 cartes sont sur le meme
réseau. La finalité n'est pas de laissé sur le meme réseau ( je vous
rassure encore une fois), mais maintenant que j'ai vu ça, j'aimerais bien
comprendre, surtout le fait que eth1 ne réponde pas du tout au ping, meme
si il est le seul connecté !
Est ce le noyau qui désactive la 2eme interface lorqu'il voit qu'elle
sont sur le meme réseau ?
Si c'est le cas, pourquoi ?
vous me direz peut etre que c'est parceque ca sert a rien, mais si j'ai
envie de rajouter une 2eme interface au serveur sur une autre ip juste
pour des taches d'administration ou de supervision, je ne vois pas
pourqu'elle raison je ne pourrais pas le faire, je n'enfrain aucune rfc
je pense et coté sécurité je ne vois pas ce que cela engendrera comme
probleme.

Un arp -a(sur un autre psote) me donne pour les 2 adresses ip la meme
adresse mac (celle de eth0(good))



Voilà, comme je disais.



voir tests plus haut

!! Bizzare !!



Je ne trouve pas.



et avec ces tests ?

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

Mais pourquoi eth0 répond et pas eth1, daccord ils sont sur le meme
réseau, mais lorsque je déconnecte eth0, eth1 ne répond pas.


--
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 #9553151
Le 24.05 2007, Pascal Hambourg ecrit ces mots :

Pascal Hambourg a écrit :

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)).



Tu n'as probablement pas attendu assez longtemps, le temps que le




cache
ARP de la machine source expire. Par conséquent elle continue à




envoyer
les paquets à l'adresse MAC d'eth0 qui est maintenant déconnectée.



Une autre explication possible :
Comme la machine a deux interfaces avec deux adresses dans le même
sous-réseau, elle a deux routes directe vers ce sous-réseau, une via
chacune des deux interface. Cependant une seule de ces deux route, et
donc une seule interface, est effectivement utilisée pour émettre vers
une adresse de ce sous-réseau. Par conséquent pas de réponse possible


si
cette interface est déconnectée.





je postait justement la table de routage, t'as peut etre un explication
sur le fait qu'une seule route soit utilisé ?
pourquoi il figerait le localnet que sur eth0 ?
peut etre parceque la table est lu séquentiellement et dès qu'il arrive
sur une route qui correspond au réseau de l'ip demandé il s'arrete là,
mais vu que l'interface sur laquelle il s'est arrété est déconnecté il ne
répond pas.
Est ce plausible comme raisonnement ?


--
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 #9553141
Le 24.05 2007, BARBIER Jean-Matthieu ecrit ces mots :

Le Thursday 24 May 2007 00:23:50 west, vous avez écrit :


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 commuta


teurs
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 enco


re
dans l'incompréhension totale.
Merci de votre aide ou de vos éclaircissement.





j'ai bien lu jusqu'au bout, et je n'ai pas de solution...

pb hard ou pb soft ?..?

une idée pour circonscrire les pbs :

- en mettant des ip fixes à partir d'un live cd genre knoppix, et en
pinguant avec un simple cable croisé et une machine saine en face, on
restreint un peu plus le problème, en éliminant les pbs de dhcp, de
routeur, de config spécifique de ta machine..



j'ai changé les cartes, changé les commutateurs et le hard semble ok
sur des réseaux différents pas de probleme.

si ça marche pas comme ça, c'est un truc louche mais je sais pas
quoi... (bios ? CM ? j'ai pas trop compris tes changements de
cartes...)



Je pense que se comportement dois venir de la table arp (voir message
précédent)
a suivre...



oui a confirmer

@+
JMB

--nextPart8945981.dIqaNV6lUX
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGVMxa+cj6VhfIEVgRAtOwAJ99grQfmqv3thfBvwwSiFpGheknmwCfVZAb
DkUu18fghKrLelutUSfeBZ8 >=ldi8
-----END PGP SIGNATURE-----

--nextPart8945981.dIqaNV6lUX--




--
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 #9553131
Le 24.05 2007, =?utf-8?Q?François?= TOURDE ecrit ces mots :

Le 13657ième jour après Epoch,
écrivait:

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



Mauvaise idée, tu t'embrouilles toi même sur le coup :)



désolé a trop vouloir etre clair j'ai créé l'effet inverse, mais
heureusement que vous etes plus éveilé que moi.

[... Tout plein de trucs compliqués, auxquels il manque l'analyse de
sang ...]


???

Voila si vous voulez d'autre infos n'hésitez pas, car là je sui


s encore
dans l'incompréhension totale.
Merci de votre aide ou de vos éclaircissement.



Pourtant tout est normal. Tout d'abord tu ne dis pas d'où tu ping dans
les premiers tests, mais c'est pas trop grave.

Les deux cartes sont sur le même sous-réseau. C'est risqué voire
inutile.



Ben comme je l'ai déjà dit, c'était juste pour vérifier que la carte
fonctionnait, en piguant j'ai eu une réponse, mais je constate que le
cable n'était pas branché, ca m'a alerté et comme j'ai pas envie de
mourrir trop bete j'ai essayé de comprendre le pourquoi du comment, d'oû
m'a présence parmis vous.

Si ta machine est configurée pour faire de l'IP Forwarding, alors
n'importe laquelle des interface va répondre pour l'autre si elle
reçoit un paquet qui lui est destiné (à l'autre, hein?).

Les IP de la machine appartiennent à la machine, donc:

A <------> eth0 machine eth1 <------> B

Si A pingue l'ip de eth0 ou l'ip de eth1, c'est eth0 qui va répondre
en général.

Idem pour B



Sauf que là si je deconnecte eth0, j'arrive a pingué aucune carte et
c'est aussi surtout ce que je voulais comprendre pourquoi il n y a que
eth0 qui répond, mais je commence a avoir une explication via la table de
routage, enfin ca reste à confirmer.

Par contre, tout cela peut ne pas marcher selon les routes par défaut,
le fait que eth0 et eth1 soient ou non reliées sur un même switch,
etc..




--
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
Franck Joncourt
Le #9553101
--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.

- 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).

- 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!

- 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 ?


--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

--OgqxwSJOaUobr8KG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGVhr4xJBTTnXAif4RAtCpAJ0RlFJ/iOaCWzfHnZBxx2cNzqJKXQCfTuxg
A1AVT97Qkz1QZtxx4aWUfI0 =CSNr
-----END PGP SIGNATURE-----

--OgqxwSJOaUobr8KG--


--
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
fra-duf-no-spam
Le #9553091
Le 13658ième jour après Epoch,
écrivait:

Le 24.05 2007, =?utf-8?Q?François?= TOURDE ecrit ces mots :
[... Tout plein de trucs compliqués, auxquels il manque l'ana lyse de
sang ...]



???



Non, rien... c'était une tentative d'humour, mais ça a pas march é...


Les IP de la machine appartiennent à la machine, donc:

A <------> eth0 machine eth1 <------> B

Si A pingue l'ip de eth0 ou l'ip de eth1, c'est eth0 qui va rà©pondre
en général.

Idem pour B



Sauf que là si je deconnecte eth0, j'arrive a pingué aucune car te et
c'est aussi surtout ce que je voulais comprendre pourquoi il n y a que
eth0 qui répond, mais je commence a avoir une explication via la tab le de
routage, enfin ca reste à confirmer.



Disons que si tu débranches eth0, mais que ton interface reste UP et
RUNNING, alors tu vas avoir un comportement compliqué dans ton cas:

1) Les deux cartes étant dans le même sous-réseau, que le pa quet
arrive par eth0 ou eth1 n'a pas d'importance dans ce cas

2) Ton système va choisir la route la mieux adaptée pour rép ondre au
ping, et on peut supposer que ça va passer par eth0, qui est l'IP
la plus faible (numériquement inférieure).

Au lieu de débrancher eth0 ou eth1, essaye plutôt un 'ifconfig et hN
down', ou mieux, mets-les sur des sous-réseaux différents.

Mais souviens toi que pinguer une adresse ce n'est pas pinguer une
carte mais une machine. C'est pour ça que si tu regardes le résul tat
de ARP depuis l'extérieur, un ping vers l'adresse de eth0 peut te
donner l'adresse MAC de eth1.
Publicité
Poster une réponse
Anonyme