routing issue for verizon dsl customers in western massachusetts

Fri Sep 16 08:15:43 UTC 2011

On Thu, Sep 15, 2011 at 20:52 UTC, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Thu, Sep 15, 2011 at 4:13 PM, Steve Bohrer <skbohrer at simons-rock.edu> wrote:
>> Traceroutes from Brian's house
>> show that for our blocked hosts, the users don't get beyond Verizon's NAT.
>
> I wasn't aware verizon implemented CGN already... way to be a 'first
> mover' in this field verizon!

I am betting they have not.

>> FAILS:
>> Tracing route to wilbur.simons-rock.edu [208.81.88.15]
>> over a maximum of 30 hops:
>>
>>  1    <1 ms    <1 ms    <1 ms  192.168.10.1
>>  2     1 ms     1 ms     1 ms  192.168.1.1
>>  3    53 ms   104 ms   116 ms  10.14.1.1
>>  4     *        *        *     Request timed out.
>>  5     *        *        *     Request timed out.
>>  6     *        *        *     Request timed out.
>>  7     *        *        *     Request timed out.

Here's a trace to the same destination from a Verizon residential DSL
on Maryland's Eastern Shore:

Tracing route to wilbur.simons-rock.edu [208.81.88.15]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.201.1
  2    25 ms    25 ms    24 ms  10.31.8.1
  3    38 ms    99 ms    78 ms
at-4-3-0-1712.sal-core-rtr1.verizon-gni.net [130.81.136.122]
  4    26 ms    26 ms    26 ms
so-0-0-0-0.sal-core-rtr2.verizon-gni.net [130.81.18.247]
  5    94 ms    31 ms    31 ms  130.81.20.238
  6    32 ms    32 ms    32 ms  0.ae2.BR2.IAD8.ALTER.NET [152.63.34.73]
  7    32 ms    33 ms    31 ms  te2-3.ar6.DCA3.gblx.net [64.215.195.113]
  8    33 ms    33 ms    32 ms  xe6-2-0-10G.scr2.WDC2.gblx.net [67.16.136.197]
  9    37 ms    38 ms    38 ms  so2-2-0-10G.scr2.NYC1.gblx.net [67.17.95.102]
 10    43 ms    44 ms    44 ms  pos9-0-2488M.cr2.BOS1.gblx.net [67.17.94.157]
 11   244 ms   200 ms   204 ms  pos1-0-0-155M.ar1.BOS1.gblx.net [67.17.70.165]
 12    50 ms    51 ms    50 ms  64.213.79.250
 13    49 ms    50 ms    48 ms  wilbur.simons-rock.edu [208.81.88.15]

192.168.201.1 is the router behind the bridged ADSL CPE which
terminates the customer PPPoE.  10.31.8.1 is RFC 1918, but is not a
NAT.  I know from various "test my crappy broadband" sites that the
only drain bramage on the provider side of the link is routine
consumer-class port blocking (SMB networking, SQL, and of course port
80 so the mothe#@#$rs can charge extra for "business" with static IP
and unblocked http).  At least https works.

Looking at Brian's trace above, I can't help wondering if the client
is 444'd, but not due to CGN/LSN.  Could both 192.168.10.1 and
192.168.1.1 be on-premises, with 192.168.1.1 terminating PPPoE?  The
latencies seem to confirm.  It is possible it's only a single level of
NAT on .1.1, with more-respectable routing by .10.1...

Cheers,
Dave Hart