[144640] in North American Network Operators' Group
Re: routing issue for verizon dsl customers in western massachusetts
daemon@ATHENA.MIT.EDU (Dave Hart)
Fri Sep 16 04:17:39 2011
In-Reply-To: <CAL9jLaZYQfFj_hSwCWPK5H2iyFSoRWQT375MmbXzt=r6W-muUw@mail.gmail.com>
From: Dave Hart <davehart@gmail.com>
Date: Fri, 16 Sep 2011 08:15:43 +0000
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: nanog@nanog.org
Reply-To: davehart_gmail_exchange_tee@davehart.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Thu, Sep 15, 2011 at 20:52 UTC, Christopher Morrow
<morrowc.lists@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 4:13 PM, Steve Bohrer <skbohrer@simons-rock.edu> =
wrote:
>> Traceroutes from Brian's house
>> show that for our blocked hosts, the users don't get beyond Verizon's NA=
T.
>
> 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:
>>
>> =C2=A01 =C2=A0 =C2=A0<1 ms =C2=A0 =C2=A0<1 ms =C2=A0 =C2=A0<1 ms =C2=A01=
92.168.10.1
>> =C2=A02 =C2=A0 =C2=A0 1 ms =C2=A0 =C2=A0 1 ms =C2=A0 =C2=A0 1 ms =C2=A01=
92.168.1.1
>> =C2=A03 =C2=A0 =C2=A053 ms =C2=A0 104 ms =C2=A0 116 ms =C2=A010.14.1.1
>> =C2=A04 =C2=A0 =C2=A0 * =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0 =C2=
=A0 =C2=A0* =C2=A0 =C2=A0 Request timed out.
>> =C2=A05 =C2=A0 =C2=A0 * =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0 =C2=
=A0 =C2=A0* =C2=A0 =C2=A0 Request timed out.
>> =C2=A06 =C2=A0 =C2=A0 * =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0 =C2=
=A0 =C2=A0* =C2=A0 =C2=A0 Request timed out.
>> =C2=A07 =C2=A0 =C2=A0 * =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0 =C2=
=A0 =C2=A0* =C2=A0 =C2=A0 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.1=
97]
9 37 ms 38 ms 38 ms so2-2-0-10G.scr2.NYC1.gblx.net [67.17.95.10=
2]
10 43 ms 44 ms 44 ms pos9-0-2488M.cr2.BOS1.gblx.net [67.17.94.15=
7]
11 244 ms 200 ms 204 ms pos1-0-0-155M.ar1.BOS1.gblx.net [67.17.70.1=
65]
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
