Hello,
 
Je suis bloqué sur un problème IP.
Un serveur Redhat possède 2 interfaces connectées à deux subnets différents.
 
Lorsque j'essaie de contacter un réseau distant, pas de souci depuis la première interface.
 
Depuis la seconde interface, tcpdump m'indique qu'une requête ARP est émise pour l'IP distante (?!).
Je ne m'attends pas à ça puisque le serveur devrait utiliser sa passerelle par défault pour contacter cette IP distante.
 
J'ai écarté le problème de connectivité en branchant un laptop ) la place de cette seconde interface, en prenant son IP, et le réseau distant est joignable.
 
Une idée?
Je peux poster ifconfig ou autres config files si besoin.
 
Merci d'avance
W85
 
 
=================
La config:
 
 
Les deux interfaces sont connectées à deux interfaces du même firewall.
Le firewall est connecté à d'autres réseaux et sert de passerelle par défaut pour le serveur.
 
ifconfig:
eth0      Link encap:Ethernet  HWaddr 34:40:B5:A4:87:20
          inet addr:192.168.212.150  Bcast:192.168.212.159  Mask:255.255.255.240
          inet6 addr: fe80::3640:b5ff:fea4:8720/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:74368 errors:0 dropped:0 overruns:0 frame:0
          TX packets:278070 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:14681017 (14.0 MiB)  TX bytes:337516843 (321.8 MiB)
          Memory:92c60000-92c80000
 
eth1      Link encap:Ethernet  HWaddr 34:40:B5:A4:87:21
          inet addr:192.168.212.165  Bcast:192.168.212.175  Mask:255.255.255.240
          inet6 addr: fe80::3640:b5ff:fea4:8721/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:126739 errors:0 dropped:0 overruns:0 frame:0
          TX packets:903 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:56367962 (53.7 MiB)  TX bytes:42290 (41.2 KiB)
          Memory:92c20000-92c40000
 
Firewall (gateway):
IP 192.168.212.145 (GW pour subnet connecté à eth0)
IP 192.168.212.161 (GW pour subnet connecté à eth1)
 
IP distante:
10.80.74.54
 
Route:
#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.212.160 0.0.0.0         255.255.255.240 U     0      0        0 eth1
192.168.212.144 0.0.0.0         255.255.255.240 U     0      0        0 eth0
0.0.0.0         192.168.212.145 0.0.0.0         UG    0      0        0 eth0
 
 
=====================================================
Ping depuis eth0 + tcpdump (fonctionne, logs présents sur le firewall):
 
#ping 10.80.74.54 -I eth0
PING 10.80.74.54 (10.80.74.54) from 192.168.212.149 eth0: 56(84) bytes of data.
64 bytes from 10.80.74.54: icmp_seq=1 ttl=125 time=0.899 ms
64 bytes from 10.80.74.54: icmp_seq=2 ttl=125 time=0.577 ms
64 bytes from 10.80.74.54: icmp_seq=3 ttl=125 time=0.557 ms
 
tcpdump
10:53:17.138378 IP 192.168.212.149 > 10.80.74.54: ICMP echo request, id 53568, seq 2, length 64
10:53:17.138937 IP 10.80.74.54 > 192.168.212.149: ICMP echo reply, id 53568, seq 2, length 64
10:53:18.138381 IP 192.168.212.149 > 10.80.74.54: ICMP echo request, id 53568, seq 3, length 64
 
=====================================================
Ping depuis eth1 + tcp dump (ne fonctionne pas à cause des requêtes ARP, pas de logs sur le firewall):
 
#ping 10.80.74.54 -I eth1
PING 10.80.74.54 (10.80.74.54) from 192.168.212.165 eth1: 56(84) bytes of data.
From 192.168.212.165 icmp_seq=2 Destination Host Unreachable
From 192.168.212.165 icmp_seq=3 Destination Host Unreachable
From 192.168.212.165 icmp_seq=4 Destination Host Unreachable
 
tcpdump
10:54:59.545510 ARP, Request who-has 10.80.74.54 tell 192.168.212.165, length 28
10:55:00.545538 ARP, Request who-has 10.80.74.54 tell 192.168.212.165, length 28
10:55:01.545535 ARP, Request who-has 10.80.74.54 tell 192.168.212.165, length 28

ce dont ont aurait besoin:
un schéma réseau
ifconfig -a
route -n
la trace du tcpdump
l'adresse ciblée
la manière dont tu spécifies l'interface par laquelle sortir (ie la commande/test que tu passes lorsque tu dis

Merci pour ton retour. J'ai updaté le premier post.

Retire le câble de eth0 avant ton test sur eth1 pour voir.

Il n'y a aucune route utilisable pour joindre ton adresse via eth1

Mais ça doit passer par eth0, non ?

Merci pour vos retours.
 
eth0 fonctionne bien.
 
Pour eth1, je ne pense pas avoir besoin de route car je peux forcer l'utilisation de l'interface avec ma commande "ping -I eth1 10.80.74.54".
Aussi, j'arrive à pinger la GW de cette interface 1.
 
Ceci dit je vais entrer une route par defaut avec une priorité moindre sur cette interface, ça ne coute rien de tester.
 
Merci pour vos idées
W85

Je viens de tester en entrant une route forcant le traffic par eth1 et le problème de requête ARP est toujours là.

J'ai compris qu'il voulait passer par eth1 dans son second test.

Met toi à la place du kernel, si tu lui dis de sortir par eth1, derrière, il ne sait pas quoi faire

J'ai créé la route pour l'ip distante en forçant l'interface eth1, ça ne marche malheuresement pas (je vais tester avec l'ip de la passerelle plutot que l'interface).

J'ai aussi compris ça, mais il me semblait que le kernel allait partir de eth1, puis ne trouvant rien allait passer sur eth0 pour atteindre la gateway par defaut (attention je suis pas glop en réseau)
 
Mais j'avais lu il y a longtemps que quand un même hôte doit répondre à une requête ARP et qu'il a plusieurs interfaces, toutes les interfaces répondent, et donc la machine cliente va recevoir deux réponses ARP  et utiliser celle de l'interface la plus rapide. Donc en gros faut filtrer.
 
je schématise hein   (pas glop inside)

Le problème est qu'il ne devrait pas y avoir de requête ARP pour un hôte distant
Le serveur devrait juste envoyer le paquet IP à sa passerelle par défault.

indique une GATEWAY pour chaque interface

et arp -a pour examiner le cache ARP