I am replying to your previous two posts together.
On Fri, May 24, 2002 at 09:04:03AM -0500, DvB wrote: > > > The "H" flag indicates that the route is to a specific host. Obviously, > > 255.255.255.255 is not a valid host address. > > > The field with the 255.255.255.255 is labeled as "Genmask," whatever > that is. Interestingly, the field with "-" is labeled as "Gateway." I > wonder if that has something to do with it. > > The full header is: > Destination,Gateway,Genmask,Flags,MSS Window,irtt Iface > > > > It'd be interesting to see what "netstat -nr" outputs; the -n option > > reveals IPs as numeric. > > > > Other than that, consider what might have changed in the days since the > > problem has been manifesting, specifically where there any DNS and > > other > > networking related changes? > > > netstat -nr outputs > > xxx.xx.xxx.xx - 255.255.255.255 !H - - -- > > where the the x's are the correct IP address for the host I'm trying to > reach (it is still the correct address, since other machines that can > connect to it report that as its address). This is what I get from route: $/sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 66.108.152.0 * 255.255.248.0 U 0 0 0 eth0 default 66-108-152-1.ny 0.0.0.0 UG 0 0 0 eth0 I don't know why you get hyphens instead of asterisks. As you can see the flags "U" indicate that the route is up. "G" indicates that the route uses a gateway. Genmask indicates which network it is on. Also you should normally have a "default" entry. All network destinations that don't have a route indicated in the previous entries are routed through this gateway. "Default" is the fallback entry. By the way, unless your computer is on the same network as the destination machine, it will need a gateway. On Thu, May 30, 2002 at 08:58:13AM -0500, DvB wrote: > Andy Saxena <[EMAIL PROTECTED]> writes: > > > On Wed, May 29, 2002 at 10:42:39AM -0500, DvB wrote: > > > On Fri, May 24, 2002 at 09:04:03AM -0500, DvB wrote: > > > > > > > The "H" flag indicates that the route is to a specific host. Obviously, > > > > 255.255.255.255 is not a valid host address. > > > > Interesting reply line. Stop the blatant plagiarism! :-} > > > Oops! I downloaded your message at home and then attempted to fake a > reply from work, where I'm having the problem, based on my original > message... sorry :-D > Not a problem. > > <snip> > > > I just read your OP. I missed the "network is unreachable" part of it. > > Can you ping any machine? "Network is unreachable" is usually an > > indication that your machine is unable to establish contact with the > > "outside." IIRC it is the same as your machine being unplugged from the > > network. > > > > That's the strange thing. I can reach our production server and the > devel and production servers of the other group I'm doing coding for, > but I can't reach our devel server or a handful of other hosts on the > (internal) network with the "network unreachable" error. I think our > devel server may have changed subnets recently, but none of the other > hosts did that I'm aware of and the admin claims there's nothing wrong > on his side. There're also other people who can reach the devel server > but I don't think I'm the only one who can't reach it. > It is possible that the topology of your network has changed. You can try doing a traceroute to the destination machine. Aternately, you can use tcptraceroute. Traceroute uses UDP packets which might run into trouble with your firewall, trptraceroute proves more useful in these cases. $ /usr/sbin/tcptraceroute firewall.wcom.com Selected device eth0, address 66.108.155.11, port 34133 for outgoing packets Tracing the path to firewall.wcom.com (199.249.16.16) on TCP port 80, 30 hops max 1 10.38.0.1 (10.38.0.1) 8.044 ms 7.651 ms 7.936 ms 2 24-29-101-73.nyc.rr.com (24.29.101.73) 7.497 ms 6.380 ms 6.121 ms 3 24.29.98.30 (24.29.98.30) 6.302 ms 6.997 ms 9.428 ms 4 24.29.97.17 (24.29.97.17) 8.216 ms 7.591 ms 9.962 ms 5 pop2-nye-P0-3.atdn.net (66.185.137.221) 8.982 ms 7.979 ms 10.164 ms 6 level3.atdn.net (66.185.137.218) 8.124 ms 16.508 ms 7.685 ms 7 so-0-0-0.gar2.NewYork1.level3.net (209.247.8.166) 9.723 ms 7.830 ms 9.368 ms 8 so-7-0-0.mp2.NewYork1.Level3.net (64.159.1.185) 8.393 ms 7.984 ms 11.604 ms 9 so-3-0-0.mp2.SanFrancisco1.Level3.net (209.247.8.90) 83.594 ms 83.243 ms 86.630 ms 10 pos9-0.core2.SanFrancisco1.Level3.net (209.247.10.238) 85.462 ms 87.967 ms 82.989 ms 11 100.ATM2-0.BR5.SAC1.ALTER.NET (166.90.50.134) 93.723 ms 88.545 ms 86.141 ms 12 0.so-2-1-0.XL2.SAC1.ALTER.NET (152.63.52.230) 87.268 ms 86.750 ms 92.226 ms 13 0.so-3-0-0.XR2.SAC1.ALTER.NET (152.63.54.2) 88.249 ms 88.075 ms 85.938 ms 14 184.ATM7-0.GW7.SAC1.ALTER.NET (152.63.53.157) 85.577 ms 88.360 ms 104.596 ms 15 2-0.SCMIR1.wcomnet.com (208.214.143.14) 86.283 ms 86.100 ms 90.091 ms 16 192.135.74.2 (192.135.74.2) 88.375 ms 86.120 ms 89.339 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Destination not reached $ /usr/sbin/tcptraceroute pmesmtp02.wcom.com Selected device eth0, address 66.108.155.11, port 34138 for outgoing packets Tracing the path to pmesmtp02.wcom.com (199.249.20.2) on TCP port 80, 30 hops max 1 10.38.0.1 (10.38.0.1) 8.204 ms 7.282 ms 10.192 ms 2 24-29-101-73.nyc.rr.com (24.29.101.73) 9.417 ms 9.594 ms 7.968 ms 3 24.29.98.30 (24.29.98.30) 8.978 ms 7.591 ms 6.975 ms 4 24.29.97.17 (24.29.97.17) 7.646 ms 8.292 ms 7.363 ms 5 pop2-nye-P0-2.atdn.net (66.185.137.209) 11.345 ms 10.235 ms 7.131 ms 6 level3.atdn.net (66.185.137.218) 10.435 ms 8.498 ms 8.175 ms 7 so-0-0-0.gar2.NewYork1.level3.net (209.247.8.166) 8.373 ms 7.775 ms 10.308 ms 8 so-7-0-0.mp2.NewYork1.Level3.net (64.159.1.185) 9.599 ms 7.968 ms 10.275 ms 9 so-3-0-0.mp2.SanFrancisco1.Level3.net (209.247.8.90) 85.771 ms 90.880 ms 83.249 ms 10 pos9-0.core2.SanFrancisco1.Level3.net (209.247.10.238) 84.243 ms 93.909 ms 84.113 ms 11 100.ATM2-0.BR5.SAC1.ALTER.NET (166.90.50.134) 87.775 ms 86.549 ms 88.494 ms 12 0.so-2-1-0.XL2.SAC1.ALTER.NET (152.63.52.230) 86.625 ms 88.921 ms 92.351 ms 13 0.so-3-0-0.XR2.SAC1.ALTER.NET (152.63.54.2) 86.567 ms 87.838 ms 88.201 ms 14 184.ATM7-0.GW7.SAC1.ALTER.NET (152.63.53.157) 86.868 ms 86.533 ms 86.148 ms 15 2-0.SCMIR1.wcomnet.com (208.214.143.14) 86.165 ms 85.152 ms 96.444 ms 16 192.135.74.2 (192.135.74.2) 86.501 ms 88.096 ms 87.267 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Destination not reached As you can see, it appears that both these machines are behind a firewall, which won't let the packets through. All other entries show the gateways involved in the routing of these packets. Here's a successful trace to www.nytimes.com $ /usr/sbin/tcptraceroute www.nytimes.com Selected device eth0, address 66.108.155.11, port 34145 for outgoing packets Tracing the path to www.nytimes.com (64.15.247.200) on TCP port 80, 30 hops max 1 10.38.0.1 (10.38.0.1) 8.130 ms 8.932 ms 8.737 ms 2 24-29-101-73.nyc.rr.com (24.29.101.73) 9.763 ms 7.458 ms 7.739 ms 3 24.29.98.30 (24.29.98.30) 10.621 ms 8.262 ms 10.018 ms 4 24.29.97.17 (24.29.97.17) 10.122 ms 37.229 ms 9.879 ms 5 pop2-nye-P0-3.atdn.net (66.185.137.221) 7.366 ms 7.667 ms 7.535 ms 6 dcr2-sonet3-2-0-0.NewYork.cw.net (206.24.207.217) 8.040 ms 9.434 ms 7.659 ms 7 cable-and-wireless-internal-isp.NewYork.cw.net (206.24.207.210) 8.283 ms 9.391 ms 8.708 ms 8 64.15.224.244 (64.15.224.244) 7.611 ms 9.882 ms 7.760 ms 9 64.15.224.178 (64.15.224.178) 9.981 ms 7.678 ms 44.646 ms 10 64.15.239.10 (64.15.239.10) 10.517 ms 7.619 ms 12.339 ms 11 64.15.247.200 (64.15.247.200) [open] 7.487 ms 9.335 ms 7.622 ms You might want to run a trace from your machine to the servers, and then possibly telnet/ssh into the servers from another machine and run a trace to your machine. Of course, I cannot access sesquipedalian from here. -Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
