Whew! I have it working as required now. There's a kernel tunable parameter net.ipv4.conf.all.rp_filter which by default on Ubuntu 8.10 is set to 1. This is so as to "drop a packet if the source and destination IP addresses in the IP header do not make sense when considered in light of the physical interface on which it arrived". I changed it in the sysctl.conf file to 0 and all is good now. Thanks "j" and John for helping me with this! - Venkat. On Wed, Feb 18, 2009 at 1:37 PM, Venkat Chandra <vc.lists at gmail.com> wrote: > 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/8e12698f/attachment-0001.htm