verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?

Gordon Cook cook at cookreport.com
Fri Oct 4 17:15:15 UTC 2013


Hi chris

really appreciate the help from ALL you guys

does what you just said mean that non reachability for version customer  may mean a config problem for a small bloc and not something intentional??
=============================================================
The COOK Report on Internet Protocol, (PSTN) 609 882-2572 
Back Issues: http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61  
 Cook's Collaborative Edge Blog 
 http://www.cookreport.com/wp/
  Subscription info: http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=============================================================










On Oct 4, 2013, at 12:54 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote:

> err.. nothing in the /24 is reachable from 701's perspective (so it
> seems)... so I'd suspect that there's a routing problem with the /24,
> in fact the surrounding /24's also seem to be having the same problem.
> 
> On Fri, Oct 4, 2013 at 12:42 PM, Miles Fidelman
> <mfidelman at meetinghouse.net> wrote:
>> Also inaccessible from FIOS Boston:
>> new-host-2:~ mfidelman$ traceroute floksociety.org
>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 52 byte packets
>> 1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms 0.724 ms
>> 2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms 6.855 ms
>> 7.304 ms
>> 3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C
>> 
>> But just fine from our datacenter via xo.net.  And the web server is up - at
>> least to a text browser (Lynx).
>> 
>> Also via Verizion cell network (Boston area).
>> 
>> Some kind of routing table glitch or peering issue, perhaps?
>> 
>> 
>> 
>> William Herrin wrote:
>>> 
>>> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook <cook at cookreport.com> wrote:
>>>>> 
>>>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
>>>>> packets
>>>>>  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>>>>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
>>>>> 17.508 ms  7.316 ms
>>>>>  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms
>>>>> !N *
>>>>>  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101
>>>>> ms !N
>>>>>  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms
>>>>> !N *
>>>>>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms
>>>>> !N *  8.846 ms !N
>>> 
>>> Inaccessible via FIOS Washington DC too:
>>> 
>>> traceroute -T -p 80 200.10.150.169
>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte
>>> packets
>>>  1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
>>> 1.595 ms  1.562 ms
>>>  2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N
>>> * *
>>> 
>>> Correctly accessible via Cox, Qwest, Sprint and others, but the
>>> network path is really slow and really long.
>>> 
>>> The border is consistently with telefonica-wholesale.net and then
>>> telconet.net. Beyond the border there are badly behaving routers,
>>> including ones configured with RFC 1918 addresses. The addressable
>>> routers are reachable via Verizon, just not the last hop.
>>> 
>>> traceroute -T -p 80 200.10.150.169
>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte
>>> packets
>>>  1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
>>>  2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
>>>  3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424
>>> ms
>>>  4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms
>>> 9.140 ms
>>>  5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
>>> ms  8.929 ms
>>>  6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
>>>  7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
>>>  8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
>>> 52.415 ms  52.421 ms
>>>  9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
>>> 60.397 ms  60.378 ms
>>> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
>>> ms  58.392 ms
>>> 11  * * *
>>> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms
>>> 47.435 ms
>>> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
>>> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
>>> (94.142.119.38)  60.181 ms
>>> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
>>> 125.888 ms
>>> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
>>>  67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
>>> (213.140.37.77)  63.435 ms
>>> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
>>> 141.873 ms
>>> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
>>> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
>>> (176.52.249.241)  64.668 ms
>>> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
>>> 17  * * *
>>> 18  * * *
>>> 19  * * *
>>> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
>>> 120.967 ms  115.040 ms
>>> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
>>> 125.164 ms  119.520 ms
>>> 22  * * *
>>> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845 ms
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> In theory, there is no difference between theory and practice.
>> In practice, there is.   .... Yogi Berra
>> 
>> 
> 





More information about the NANOG mailing list