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.<br>
<br>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.<br>
<br>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.<br><br>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.<br>
<br> --j<br><br><div class="gmail_quote">On Wed, Feb 18, 2009 at 10:50 AM, Venkat Chandra <span dir="ltr"><<a href="mailto:vc.lists@gmail.com">vc.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The IP trying to reach the 192.168.164.2 interface is 10.19.176.22.<div><br></div><div>I removed the iptables package for good measure after I noticed this problem. No luck. </div><div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Venkat. <div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Tue, Feb 17, 2009 at 7:42 PM, J Cruit <span dir="ltr"><<a href="mailto:j@packetgod.com" target="_blank">j@packetgod.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>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.<br><br>--j<br><br><div class="gmail_quote"><div><div>
</div><div>On Tue, Feb 17, 2009 at 5:04 PM, Venkat Chandra <span dir="ltr"><<a href="mailto:vc.lists@gmail.com" target="_blank">vc.lists@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div>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. <div>
<br></div>
<div>The <span style="font-family: 'courier new',monospace;">/etc/network/interfaces</span> file is as under:</div><div><br></div><div><div><div><span style="font-family: 'courier new'; font-size: 12px;">auto lo</span></div>
<div><span style="font-family: 'courier new'; font-size: 12px;">iface lo inet loopback</span></div><div><span style="font-family: 'courier new'; font-size: 12px;"><br>
</span></div><div><span style="font-family: 'courier new'; font-size: 12px;">auto eth0</span></div><div><span style="font-family: 'courier new'; font-size: 12px;">iface eth0 inet static</span></div>
<div><span style="font-family: 'courier new'; font-size: 12px;"> address 10.19.175.242</span></div><div><span style="font-family: 'courier new'; font-size: 12px;"> netmask 255.255.255.240</span></div>
<div><span style="font-family: 'courier new'; font-size: 12px;"> network 10.19.175.240</span></div><div><span style="font-family: 'courier new'; font-size: 12px;"> broadcast 10.19.175.255</span></div>
<div><span style="font-family: 'courier new'; font-size: 12px;"> gateway 10.19.175.241</span></div><div><span style="font-family: 'courier new'; font-size: 12px;"> dns-nameservers 10.19.173.245</span></div>
<div><span style="font-family: 'courier new'; font-size: 12px;"><br></span></div><div><span style="font-family: 'courier new'; font-size: 12px;">auto eth1</span></div>
<div><span style="font-family: 'courier new'; font-size: 12px;">iface eth1 inet static</span></div><div><span style="font-family: 'courier new'; font-size: 12px;"> address 192.168.164.2</span></div>
<div><span style="font-family: 'courier new'; font-size: 12px;"> netmask 255.255.252.0</span></div><div><br></div></div><div>The output of <span style="font-family: 'courier new',monospace;">netstat -nr</span> is as under:</div>
<div><span style="font-family: 'courier new',monospace;"><br></span></div><div><div><span style="font-family: 'courier new',monospace;">Kernel IP routing table</span></div>
<div><span style="font-family: 'courier new',monospace;">Destination Gateway Genmask Flags MSS Window irtt Iface</span></div><div><span style="font-family: 'courier new',monospace;">10.19.175.240 0.0.0.0 255.255.255.240 U 0 0 0 eth0</span></div>
<div><span style="font-family: 'courier new',monospace;">192.168.164.0 0.0.0.0 255.255.252.0 U 0 0 0 eth1</span></div><div><span style="font-family: 'courier new',monospace;">169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1</span></div>
<div><span style="font-family: 'courier new',monospace;">0.0.0.0 10.19.175.241 0.0.0.0 UG 0 0 0 eth0</span></div><div><br></div><div><br></div><div>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. </div>
<div><br></div><div>If I were to do:</div><div><span style="font-family: 'courier new',monospace;"><br></span></div><div><span style="font-family: 'courier new',monospace;">$ sudo route delete default device eth0<br>
</span></div><div><span style="font-family: 'courier new',monospace;">$ sudo route add default gw 192.168.164.1 device eth1 </span><br></div><div><br></div><div>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. </div>
<div><br></div><div><br></div><div>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:</div>
<div><span style="font-family: 'courier new',monospace;"><br></span></div><div><span style="font-family: 'courier new',monospace;"># route delete default device eth1<br>
</span></div><div><span style="font-family: 'courier new',monospace;"># route add default gw 10.19.175.241 device eth0</span></div><div><br></div><div>and the routing table:</div><div><span style="font-family: 'courier new'; font-size: 12px;"><br>
</span></div><div><span style="font-family: 'courier new',monospace;">[root@localhost ~]# route </span></div><div><span style="font-family: 'courier new',monospace;">Kernel IP routing table </span></div>
<div><span style="font-family: 'courier new',monospace;">Destination Gateway Genmask Flags Metric Ref Use Iface</span></div><div><span style="font-family: 'courier new',monospace;">10.19.175.240 * 255.255.255.240 U 1 0 0 eth0 </span></div>
<div><span style="font-family: 'courier new',monospace;">192.168.164.0 * 255.255.252.0 U 1 0 0 eth1 </span></div><div><span style="font-family: 'courier new',monospace;">default 10.19.175.241 0.0.0.0 UG 0 0 0 eth0 </span></div>
<div><span style="font-family: 'courier new'; font-size: 12px;"><br></span></div><div><span style="font-size: 12px;"><span style="font-family: arial,helvetica,sans-serif;">And I was able to reach both the eth0 and eth1 interfaces at this point from appropriate machines on the network.</span></span></div>
<div> <br></div><div>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. </div>
<div><br></div><div>Any idea why Ubuntu would behave differently? I'd appreciate any suggestions on what I could try so that both interfaces are reachable simultaneously.</div><div><br></div><div>Thanks,</div><div>Venkat. <br>
</div></div></div>
<br></div></div>_______________________________________________<br>
TCLUG Mailing List - Minneapolis/St. Paul, Minnesota<br>
<a href="mailto:tclug-list@mn-linux.org" target="_blank">tclug-list@mn-linux.org</a><br>
<a href="http://mailman.mn-linux.org/mailman/listinfo/tclug-list" target="_blank">http://mailman.mn-linux.org/mailman/listinfo/tclug-list</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br>