> I saw exactly this same thing.  I also couldn't reach
> gatekeeper.dec.com.  When I removed my static default route (so the
> only route was the one that pppd installed (with the defaultroute
> option) when it started), all the problems went away.  Dunno why.

> So, with the default route installed via the route command, things
> broke.  But with pppd's defaultroute, it worked fine.  I think somehow
> the system interprets the IP numbers for these hosts (class A nets) in
> such a way that the netmask gets messed up or something.  With the IP
> #'s 16.x.x.x and 18.x.x.x this problem appears.  All the other hosts I
> tried to reach had numbers like 129.x.x.x, 133.x.x.x 198.x.x.x.

That's interesting.  Maybe there is something worth pursuing here.

As it turns out, the default route (created from hostname.ppp0) is the
one which was bogus; I had put in a gateway of "10.0.0.1" intending to
fill it in later.  It seemed odd that a bogus route to 10.0.0.1 should
trap addresses in the 18.xxx range, but deleting it made things work,
so I stopped worrying about it.  What *is* up with class A nets, anyway?