[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
routing issue for verizon dsl customers in western massachusetts
- Subject: routing issue for verizon dsl customers in western massachusetts
- From: bgold at simons-rock.edu (bgold at simons-rock.edu)
- Date: Fri, 16 Sep 2011 07:51:44 -0400 (EDT)
- In-reply-to: <CAMbSiYDb0jrhUJCsVKr8oJfDwaWdqZs1nqs-LKTh=UdWrx7DMA@mail.gmail.com>
- References: <[email protected]> <CAL9jLaZbnASaiRuBic+ayKMEGOTXMUeKWD2FmT+TMnYDFniziQ@mail.gmail.com> <[email protected]> <CAL9jLaZYQfFj_hSwCWPK5H2iyFSoRWQT375MmbXzt=r6W-muUw@mail.gmail.com> <CAMbSiYDb0jrhUJCsVKr8oJfDwaWdqZs1nqs-LKTh=UdWrx7DMA@mail.gmail.com>
> 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...
In my setup, 192.168.10.1 is my DD-WRT router and 192.168.1.1 is the DSL
modem. When I ran a traceroute directly from the DSL modem's web
interface, I got the following results:
1 57 ms 98 ms 129 ms 10.14.1.1
3 * * * Request timed out.
5 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
>
> Cheers,
> Dave Hart
>
>