Again not exactly certain why it would work on the live versus the installed but it could be that the system doesn't have IP forwarding turned on as it sounds like this is trying to route through the system. So your host that is trying to reach the system would not be in the routing table of the host so it will be sent to the default gateway no matter what interface it comes in on, you said it could talk to the 10.19.174.242 address which would point to the fact that the router can route to from the 10.19.174.242 to the 10.19.176.22. So perhaps the issue is that Ubuntu does not want to return a ping received on one interface out another interface. It would receive the ping on the 192.168.164.2 interface but its only route back would be out its 10.19.174.242 interface. The other issue could be if there are any firewalls around and this would cause an asynchronous routing issue which would break any state tables, also depending on the routes on the 6509 could also be an issue but if the routes are all there it shouldn't matter although if there is anything fancy going on like route-maps that could cause issues. 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. 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. --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/8abeb125/attachment-0001.htm