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/8328227d/attachment-0001.htm