I believe the expected behavior is for the 192.168.164.2 interface to route
packets out the 10.19.174.242 interface if it is not intended for the
192.168.164.0 network. And in fact that is the behavior exhibited by F10 and
Solaris 8 & 9.

So not sure if the bug is Ubuntu or not but I'm not sure what the standard
> behaviour is and if it is different from the live version versus installed.
>

It is not as much as the difference in behavior between live and installed
versions as it is the difference in behavior between the newer Ubuntu
versions and older Ubuntu versions as well as other Unix-y boxes. Here's a
summary of what I've tried and observed:

Ubuntu 7.10 (Live) ---- Works as expected (as per my
understanding/observation stated above).
Ubuntu 8.04 (Live) ---- Does not work as expected.
Ubuntu 8.10 (Live) ---- Does not work as expected.
Ubuntu 8.10 (Inst) ---- Does not work as expected.
Fedora 9 (Inst)      ---- Works as expected.
Fedora 10 (Live)    ---- Works as expected.
Solaris 9 & 10 (Inst) ---- Works as expected.

Try just adding in a route just to the 10.19.176.22 pointing to the
> 192.168.164.1 than try pinging it.  If it works, try pinging the
> 10.19.176.242 and chances are it wont work because you will have the same
> problem only in reverse.  Or maybe it will all magically work and you can
> just add that route to your startup configuration.
>

Yep - I tried this and you guessed correctly - I had the problem, only in
reverse.

Thanks,
Venkat.


>  --j
>
>
> On Wed, Feb 18, 2009 at 10:50 AM, Venkat Chandra <vc.lists at gmail.com>wrote:
>
>> The IP trying to reach the 192.168.164.2 interface is 10.19.176.22.
>> I removed the iptables package for good measure after I noticed this
>> problem. No luck.
>>
>> I just tried a live Ubuntu 7.10 off of a USB drive and the routing works
>> just fine. At this point, I am fairly certain this is a bug in Ubuntu 8.10
>> (and also 8.04 LTS). It would be great to have a workaround. Any suggestions
>> are appreciated.
>>
>> Thanks,
>> Venkat.
>>
>>
>> On Tue, Feb 17, 2009 at 7:42 PM, J Cruit <j at packetgod.com> wrote:
>>
>>> What is the IP of the system trying to reach the 192.168.164.2
>>> interface?  It sounds like the system may not have a route back to the
>>> client.  With the default route pointing to the 10.19.175.241 address
>>> anything not in a local subnet will get routed out that interface.
>>>
>>> I've never seen Ubuntu behave differently than Fedora when it comes to
>>> routing, not sure what else could be going on there if there are no
>>> firewalls involved.
>>>
>>> --j
>>>
>>> On Tue, Feb 17, 2009 at 5:04 PM, Venkat Chandra <vc.lists at gmail.com>wrote:
>>>
>>>> One of the applications that I am working with requires a fairly
>>>> unorthodox network configuration. This machine is running Ubuntu 8.10 with
>>>> all the latest patches. This has multiple wired network interfaces.
>>>> The /etc/network/interfaces file is as under:
>>>>
>>>> auto lo
>>>> iface lo inet loopback
>>>>
>>>> auto eth0
>>>> iface eth0 inet static
>>>>         address 10.19.175.242
>>>>         netmask 255.255.255.240
>>>>         network 10.19.175.240
>>>>         broadcast 10.19.175.255
>>>>         gateway 10.19.175.241
>>>>         dns-nameservers 10.19.173.245
>>>>
>>>> auto eth1
>>>> iface eth1 inet static
>>>>         address 192.168.164.2
>>>>         netmask 255.255.252.0
>>>>
>>>> The output of netstat -nr is as under:
>>>>
>>>> Kernel IP routing table
>>>> Destination     Gateway         Genmask         Flags   MSS Window  irtt
>>>> Iface
>>>> 10.19.175.240   0.0.0.0         255.255.255.240 U         0 0          0
>>>> eth0
>>>> 192.168.164.0   0.0.0.0         255.255.252.0   U         0 0          0
>>>> eth1
>>>> 169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0
>>>> eth1
>>>> 0.0.0.0         10.19.175.241   0.0.0.0         UG        0 0          0
>>>> eth0
>>>>
>>>>
>>>> The network cables from these two interfaces terminate on a Cisco 6509
>>>> switch. Another machine of interest is also connected to this switch. Pings
>>>> from this other machine to the 192.168.164.2 interface are not returned.
>>>>
>>>> If I were to do:
>>>>
>>>> $ sudo route delete default device eth0
>>>> $ sudo route add default gw 192.168.164.1 device eth1
>>>>
>>>> then the other machine is able to ping 192.168.164.2. Of course I lose
>>>> the ability to reach the 10.19.175.242 interface.
>>>>
>>>>
>>>> I tried the Fedora 10 Live distribution on the same machine. I used the
>>>> NetworkManager applet to first configure eth0, checked the connectivity to
>>>> that interface before configuring the eth1 interface. I lost connectivity to
>>>> the eth0 interface at this point. I then did the following:
>>>>
>>>> # route delete default device eth1
>>>> # route add default gw 10.19.175.241 device eth0
>>>>
>>>> and the routing table:
>>>>
>>>> [root at localhost ~]# route
>>>> Kernel IP routing table
>>>> Destination     Gateway         Genmask         Flags Metric Ref    Use
>>>> Iface
>>>> 10.19.175.240   *               255.255.255.240 U     1      0        0
>>>> eth0
>>>> 192.168.164.0   *               255.255.252.0   U     1      0        0
>>>> eth1
>>>> default         10.19.175.241   0.0.0.0         UG    0      0        0
>>>> eth0
>>>>
>>>> And I was able to reach both the eth0 and eth1 interfaces at this point
>>>> from appropriate machines on the network.
>>>>
>>>> I tried using a bootable USB Live Ubuntu 8.10, and I repeated the exact
>>>> steps I had performed with the F10 and I was only able to reach one of the
>>>> interfaces and not both at the same time. I can run tcpdump on the
>>>> interfaces separately and I can see ICMP Requests coming in on both the
>>>> interfaces but only one of the interfaces responds with an ICMP Reply.
>>>>
>>>> Any idea why Ubuntu would behave differently? I'd appreciate any
>>>> suggestions on what I could try so that both interfaces are reachable
>>>> simultaneously.
>>>>
>>>> Thanks,
>>>> Venkat.
>>>>
>>>> _______________________________________________
>>>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
>>>> tclug-list at mn-linux.org
>>>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20090218/26de0d83/attachment.htm