Well, that traceroute helpfully tells us that A cannot talk to C.
A traceroute from B to C might shed some light on how B reaches C.
And a "netstat -rrv" from all 3 hosts would show us the routing tables.
Another idea is a bad network card. Is the link light lit?
traceroute from B to C:
$ traceroute 10.6.0.33
traceroute to 10.6.0.33 (10.6.0.33), 30 hops max, 46 byte packets
1 10.6.0.33 (10.6.0.33) 0.588 ms 0.118 ms 0.092 ms
$
netstat for hostA
# netstat -rv
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.10.128.49 10.10.136.1 255.255.255.255 UGH 0 0 0 eth0
10.10.135.10 10.10.136.1 255.255.255.255 UGH 0 0 0 eth0
10.6.0.0 * 255.255.255.192 U 0 0 0 eth2
10.10.136.0 * 255.255.255.192 U 0 0 0 eth0
default 10.10.136.2 0.0.0.0 UG 0 0 0 eth0
#
netstat for hostB
$ netstat -rv
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.9.3.8 * 255.255.255.248 U 0 0 0 eth1
10.9.3.0 * 255.255.255.248 U 0 0 0 eth0
10.6.0.0 * 255.255.255.192 U 0 0 0 eth2
default 10.9.3.1 0.0.0.0 UG 0 0 0 eth0
$
netstat for hostC
$ netstat -rv
IRE Table: IPv4
Destination Mask Gateway Device Mxfrg Rtt Ref Flg Out In/Fwd
-------------------- --------------- -------------------- ------ ----- ----- --- --- ----- ------
default 0.0.0.0 10.10.128.1 1500* 0 1 UG 5334 0
10.6.0.0 255.255.255.192 RKARM1 eth0 1500* 0 1 U 3737 0
10.10.128.0 255.255.255.192 RKARM1-01 eth1 1500* 0 1 U 2169 0
localhost 255.255.255.255 localhost lo0 8232* 0 3 UH 1456 0
$
I notify that the link light is lit
I can't put the information you have posted together into a picture that makes any sense. In post 18 HostC had a single interface, eth0. If that is true why does the hostC routing table think that hostC has two interfaces? I'm not real sure what I can trust.
The strangest thing I see is the default route in hostC being first. I thought that the routing table is scanned sequentially with the first match being taken. If that is right, HostC default route will always win.
Other than that, I don't don't know where your problem is. This one has me stumped.
hi All,
finally I've resolved my issue, just by this command:
route add 10.6.0.50 eth2
Frankly I don't understand the importance of this line, although this resolved my problem. so, if someone can explan me its importance, it will help me a lot.
once again thanks to all for your help
bye
Firstly, this added route definition will not be available after the next boot. Is 10.6.0.50 the gateway?
If not and this was the address you were struggling to connect with, then perhaps the address was cached somewhere, perhaps an ARP pointing to the wrong MAC or because of a previous attempt to go via eth0. Maybe I'm talking out of my hat, but i can't think of another explanation.
When you get a chance to boot, please test if the problem recurs. If not, then it is likely to have been something cached, but if it does we will have to dig some more.
Robin
hi Robin,
thanks for your explanation, and as you told it, I'll let you know, if the issue persists or not, when I get the chance to reboot my server.
take care