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@xxxxxxxxx
>>>>
>>>> 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@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@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@IDi ~]$ su -
> Contraseña:
> [root@IDi ~]# route add -net 192.168.236.0 netmask 255.255.255.0 gw 192.168.1.100 dev eth0
> [root@IDi ~]# logout
>
> [jose@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@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@IDi ~]$ ssh 192.168.236.80
> jose@xxxxxxxxxxxxxx's password:
> Last login: Sun Dec 19 20:44:44 2010 from 192.168.1.3
> [jose@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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
