On 12/19/10 1:45 PM, Jose Maria Terry Jimenez wrote: > > El 19/12/2010, a las 20:34, Les Mikesell escribió: > >> On 12/19/10 12:31 PM, Jose Maria Terry Jimenez wrote: >>>>> >>>>> First make sure that you can ping/access those 'other' services from the centos >>>>> box with 2 nics. It should source from the .236 interface and 'just work'. If >>>>> not, you have firewalls or something else blocking traffic. When you route >>>>> other traffic from the .1 network, the destination machines need some reason to >>>>> send the return packets to the 192.168.236.74 address. You can either add the >>>>> route to every machine or on the router that is currently their default router. >>>>> >>>>> -- >>>>> Les Mikesell >>>>> lesmikesell at gmail.com >>>> >>>> Thank you Les, >>>> >>>> Yes, i can ping/access those 'other' services from the CentOS box with 2 NICs. >>>> >>>> I understand that i need, for example in a networked printer in 236. network a 'return' route. I definitely have no access to configure network on every machine in the 236 network (only a few), nor the router... >>>> >>>> This can't be solved any other way? >>>> >>>> Best >>> >>> Hello Again, >>> >>> I forgot: >>> I made a mistake in my original post, the ping is to a diferent CentOS box in the 236. network (192.168.236.80) and it replies and i can access it from the Fedora machine in the 1. net. >>> >>> Why the other CentOS box (in the 236. net) works (reply, can be accessed) without adding any route? >>> >>> The Fedora box (1. network): >>> [jose at IDi ~]$ ping 192.168.236.80 >>> PING 192.168.236.80 (192.168.236.80) 56(84) bytes of data. >>> 64 bytes from 192.168.236.80: icmp_req=1 ttl=64 time=1.61 ms >>> 64 bytes from 192.168.236.80: icmp_req=2 ttl=64 time=0.684 ms >>> [jose at IDi ~]$ ifconfig eth0 | grep -i 'inet addr' >>> inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0 >> >> This doesn't make much sense without a route. Can you try a traceroute to the >> fedora box address from the 192.168.236.80 box to see how/why it gets there? > > Sure, here it is: > >> From fresh reboot of the Fedora14 box: > > [jose at IDi ~]$ su - > Contraseña: > [root at IDi ~]# route add -net 192.168.236.0 netmask 255.255.255.0 gw 192.168.1.100 dev eth0 > [root at IDi ~]# logout > > [jose at IDi ~]$ traceroute 192.168.236.80 > traceroute to 192.168.236.80 (192.168.236.80), 30 hops max, 60 byte packets > 1 puente (192.168.1.100) 0.286 ms 0.260 ms 0.239 ms > 2 192.168.236.80 (192.168.236.80) 0.963 ms !X 0.949 ms !X 0.930 ms !X We know why it works this direction. > [jose at IDi ~]$ ping 192.168.236.80 > PING 192.168.236.80 (192.168.236.80) 56(84) bytes of data. > 64 bytes from 192.168.236.80: icmp_req=1 ttl=64 time=0.668 ms > 64 bytes from 192.168.236.80: icmp_req=2 ttl=64 time=0.599 ms > 64 bytes from 192.168.236.80: icmp_req=3 ttl=64 time=0.566 ms > ^C > --- 192.168.236.80 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2000ms > rtt min/avg/max/mdev = 0.566/0.611/0.668/0.042 ms > > [jose at IDi ~]$ ssh 192.168.236.80 > jose at 192.168.236.80's password: > Last login: Sun Dec 19 20:44:44 2010 from 192.168.1.3 > [jose at control ~]$ I wanted the reverse path. Traceroute from the 192.168.236.80 box back to the fedora address. It doesn't make sense that it can return packets without a route going through the Centos box. -- Les Mikesell lesmikesell at gmail.com