I guess I should also mention that my earlier assertion that this could be a bug in Ubuntu 8.10 is incorrect. - Venkat. On Wed, Feb 18, 2009 at 4:09 PM, Venkat Chandra <vc.lists at gmail.com> wrote: > 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/2f57e760/attachment.htm