Problème carte réseau étrange

Support Debian
#1

Bonjour,

Ce post suit celui la forum.debian-fr.org/viewtopic.php?t=5455 mais j’en ai résolu une partie

Bon j’ai du nouveau sur ce probleme étrange, nous venons de changer notre routeur/passerelle avec un boitier netasq il est configurer en passall.

La deuxieme machine marche maintenant extremement bien (probleme de route en fait :blush: ). Mais j’ai compris le phénomene sur la premiere machine.

Quand je descend la eth1 et monte la eth0 , ca ping la eth0.

Quand je descend la premiere interface eth0 et monte la deuxieme interface eth1 , ca ping bien la eth1.

Mais quand je monte les 2 y seulement la eth1 qui répond.

On dirait que les cartes sont réliées en elles, ou ca ressemble a un probleme avec les drivers de broadcom ethernet gigabit ou un probleme dans le noyau ???

Est-ce que vous voyez un truc qui peut expliquer ca ? ou avez vous deja eu un probleme similaire?

Pour rappel ce serveur est un dell poweredge 1950 ( lautre cetait un 2850 mais j’ai pas de probleme sur celui la ), les cartes réseaux sont des broadcom ethernet gigabit 1Gb ( elles sont vu sous windows comme des intels je crois )

Je voudrais bien comprendre ce truc, parce que j’ai jamais vu ca.

Merci

#2

Quelles sont les routes dans les deux cas?

(donne le résultat de route -n)

#3

Quelquechose m’est arrivé de similaire sur un contrôleur de domaine 2003 avec deux cartes. Les autentifications ne se faisaient pas quand les deux cartes étaient up. J’ai pensé que ça pouvait provenir d’un pb d’arp.
Par contre, est ce que tes deux interfaces sont sur le même réseau physique ?
Parceque sinon, faute de trouver d’ou vient le pb, tu peux le contourner en agregeant les deux cartes (bonding que j’ai découvert cet AM), et en affectant deux IPs à l’interface ainsi constituée.

#4

[quote=“mattotop”]Quelquechose m’est arrivé de similaire sur un contrôleur de domaine 2003 avec deux cartes. Les autentifications ne se faisaient pas quand les deux cartes étaient up. J’ai pensé que ça pouvait provenir d’un pb d’arp.
Par contre, est ce que tes deux interfaces sont sur le même réseau physique ?
Parceque sinon, faute de trouver d’ou vient le pb, tu peux le contourner en agregeant les deux cartes (bonding que j’ai découvert cet AM), et en affectant deux IPs à l’interface ainsi constituée.[/quote]

Oui elles sont bien sur le meme réseau physique

#5

alors tu peux les agrèger comme une seule carte (ça fonctionne un peu comme le bridging en terme de config):
sluce.developpez.com/bonding/
glasnost.beeznest.org/articles/179
et ensuite affecter le nombre d’adresses que tu souhaites à l’interface unique obtenue.
L’avantage est que si une des cartes physiques crame, l’ensemble continue à gèrer toutes les adresses, simplement avec un peu moins de bande passante.

#6

[quote=“fran.b”]Quelles sont les routes dans les deux cas?

(donne le résultat de route -n)[/quote]

132.80.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
132.80.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 132.80.1.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 132.80.1.1 0.0.0.0 UG 0 0 0 eth1

#7

tu as du parefeu sur ta machine ?
parceque comme la route de sortie d’un paquet est par défaut celle par eth0 et que tu n’as pas d’equilibrage de charge je pense que TOUT sort par eth0 (il y a peut être un tourniquet par défaut quand plusieurs routes sont équivalentes pour un paquet, mais je ne pense pas), les paquets ‘reponse echo’ emis par eth1 doivent traverser le noyau pour aller répondre au pingueur. Si tu as un DROP ou un REJECT sur la chaine FORWARD (ou que tu bloques l’OUTPUT pour ce qui est en -i eth1), les paquets retour du ping ne passent plus.
Enfin il me semble, mais bon.

Sinon, dans l’autre fil, tu prenais un exemple en 132.80.10.0 alors que tes routes sont en 132.80.0.0, c’est normal ?
Tu as bien des ip distinctes sur chaque carte ?

As tu essayé de jouer avec les paramètres du noyau, genre:

echo 1>/proc/sys/net/ipv4/conf/all/proxy_arpla modif est ponctuelle et disparait au reboot, tu peux aussi essayer carte par carte, ou essayer de jouer sur d’autres fonctionnalités d’arp de /proc/sys/net/ipv4/

#8

[quote=“mattotop”]tu as du parefeu sur ta machine ?
parceque comme la route de sortie d’un paquet est par défaut celle par eth0 et que tu n’as pas d’equilibrage de charge je pense que TOUT sort par eth0 (il y a peut être un tourniquet par défaut quand plusieurs routes sont équivalentes pour un paquet, mais je ne pense pas), les paquets ‘reponse echo’ emis par eth1 doivent traverser le noyau pour aller répondre au pingueur. Si tu as un DROP ou un REJECT sur la chaine FORWARD (ou que tu bloques l’OUTPUT pour ce qui est en -i eth1), les paquets retour du ping ne passent plus.
Enfin il me semble, mais bon.

Sinon, dans l’autre fil, tu prenais un exemple en 132.80.10.0 alors que tes routes sont en 132.80.0.0, c’est normal ?
Tu as bien des ip distinctes sur chaque carte ?

As tu essayé de jouer avec les paramètres du noyau, genre:

nan pas de parefeu et jai pas touché a /proc/sys/…
J’ai bien des ips distintcs sur chaque carte et ma passerelle cest 132.80.1.1

#9

[quote=“copyme”][quote=“fran.b”]Quelles sont les routes dans les deux cas?

(donne le résultat de route -n)[/quote]

132.80.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
132.80.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 132.80.1.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 132.80.1.1 0.0.0.0 UG 0 0 0 eth1[/quote]

Ben voilà, pour la répojnse du retour, une seule carte est utilisée, celle de la première entrée de route. Ton ping envoit une requête à une adresse arp et c’est une autre qui répond (le retour n’est pas pris en compte). Si tu fais un tcpdump, tu devrais voir le pong revenir sur ta machine mais ne pas être pris en compte. Par contre, la machine devrait répondre à un ping en broadcast non?

ping -b 138.80.255.255

#10

quote="fran.b"
Par contre, la machine devrait répondre à un ping en broadcast non?
ping -b 138.80.255.255[/quote] :laughing: sur un réseau de 500 machines, il faut “greper” la réponse !
oui, ma question sur les ips était idiote je ne pensais plus au fait que c’etait réseau de classe B.
Ce que je pensais semble confirmé par ce que dit fran: à moins d’agrèger, ou de mettre un tourniquet sur les routes, ce qui transite sur eth1 se limite à ce qui lui est spécifiquement envoyé, et comme tout part par eth0, la majorité du traffic est spécifiquement fait par eth0.

#11

[quote=“copyme”]
J’ai bien des ips distintcs sur chaque carte et ma passerelle cest 132.80.1.1[/quote]
J’ai un doute là. Il faut que tes cartes soient sur des reseaux different, pas seulement des ip differentes non? Cette machine est un routeur ou un bridge ou pas de traffic est censé passé entre les deux cartes?
Et deux routes par défaut je sais pas non plus ce que ca donne…

#12

[quote=“BorisTheButcher”][quote=“copyme”]
J’ai bien des ips distintcs sur chaque carte et ma passerelle cest 132.80.1.1[/quote]
J’ai un doute là. Il faut que tes cartes soient sur des reseaux different, pas seulement des ip differentes non? Cette machine est un routeur ou un bridge ou pas de traffic est censé passé entre les deux cartes?
Et deux routes par défaut je sais pas non plus ce que ca donne…[/quote]
C’est à dire que le plus astucieux aurait été de faire une interface virtuelle genre eth0:1, ça n’aurait pas posée ces pbms je pense.