"Michael H. Warfield" wrote: > > > 15 main1-core5-oc12.sjc1.above.net (208.185.175.250) 238.888 ms > > > 229.529 ms 239.743 ms > > > 16 209.249.170.20.nvidia.com (209.249.170.20) 249.612 ms 228.921 ms > > > 239.750 ms > > > 17 10.0.0.2 (10.0.0.2) 239.545 ms 229.588 ms 229.720 ms > > > 18 * * * > > > 19 * * > > > Notice the last address: 10.0.0.2 - this isn't blocking, just hopelessly > > messed up routing tables (10.0.0.0 network is private, you may never see > > one of those adresses outside of you local network). Once you hit a > > 10.0.0.0 network outside of a local network, all bets are off... > > Actually, no. This is not true. Private addresses do show up > on traceroutes quite often. It indicates a link in the route which is > using private addresses for internal routing. You can't address it > directly but when it returns an error (TTL expired) it indicates the > address at which the failure occured. That failure just happen to be > at one of those private addresses. You should never see one of those > private addresses routed to or addressed to outside of your local > address and boarder gateways SHOULD filter out anything that has a > source address of a private address space, but, baring "policy routing", > stock routing does not take the source address into consideration in > the routing tables. Lack of filtering? Maybe... Debatable. > Hopelessly messed up routing tables? Not. I complained to my ISP about the sites I couldn't access and got a similar answer, that traceroute and even ping (depending on firewall setup) don't necessarily determine whether you can actually access the site. In the case of www.nvidia.com I was unable to access the site for a couple of days, but I'm now able to access it although I *still* get the 10.0.0.2 address and subsequent "* * *"'s in the traceroute! Ben
