[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: lost route (network unreachable)



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 <andyML@nyc.rr.com> 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 debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: