<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Their provider has peering issues, or
      simply got turned off and their provider isn't null-routing their
      smaller block.<br>
      <br>
      On 01/15/2014 01:02 PM, ChasM wrote:<br>
    </div>
    <blockquote cite="mid:BLU177-W1960C65F4DEEFB7E85EB489BE0@phx.gbl"
      type="cite">
      <pre wrap="">traceroute to 82.94.226.104 (82.94.226.104), 30 hops max, 38 byte packets
 1  192.168.0.1 (192.168.0.1)  0.511 ms  0.220 ms  0.130 ms</pre>
    </blockquote>
    Probably your gateway/router.  192.168.0.1 is default.<br>
    <blockquote cite="mid:BLU177-W1960C65F4DEEFB7E85EB489BE0@phx.gbl"
      type="cite">
      <pre wrap="">
 2  *  *  *
 3  *  *  *
 4  *  *  *
 5  *  *  *</pre>
    </blockquote>
    Weird your provider is filtering icmp, or you are.  Maybe they do is
    they don't want someone topology mapping satellites per the
    government.  Five hops to get to their internet provider for bgp
    handoff from your uplink gateway.<br>
    <blockquote cite="mid:BLU177-W1960C65F4DEEFB7E85EB489BE0@phx.gbl"
      type="cite">
      <pre wrap="">
 6  xe-11-3-2.edge3.Denver1.Level3.net (4.31.10.21)  573.083 ms  600.139 ms  610.012 ms
 7  vlan51.ebr1.Denver1.Level3.net (4.69.147.94)  623.971 ms  636.495 ms  639.317 ms
 8  ae-3-3.ebr2.SanJose1.Level3.net (4.69.132.57)  641.511 ms  637.943 ms  640.662 ms
 9  ae-82-82.csw3.SanJose1.Level3.net (4.69.153.26)  640.213 ms  ae-92-92.csw4.SanJose1.Level3.net (4.69.153.30)  658.787 ms  636.883 ms
10  ae-1-60.edge1.SanJose3.Level3.net (4.69.152.16)  637.633 ms  ae-2-70.edge1.SanJose3.Level3.net (4.69.152.80)  638.802 ms  640.916 ms
11  KPN.edge1.SanJose3.Level3.net (4.53.208.18)  641.029 ms  638.968 ms  1401.923 ms</pre>
    </blockquote>
    Your provider peers with Level 3 from denver land gateway, to san
    jose, paying them for internet transit.  They respond outside the
    satellite network to the traceroute as a provider should.  They pass
    you off to the next bgp autonomous system in path.<br>
    <blockquote cite="mid:BLU177-W1960C65F4DEEFB7E85EB489BE0@phx.gbl"
      type="cite">
      <pre wrap="">
12  chg-s1-rou-1041.US.eurorings.net (134.222.232.65)  758.628 ms  759.915 ms  758.051 ms
13  asd2-rou-1022.NL.eurorings.net (134.222.233.20)  760.562 ms  759.132 ms  760.946 ms
14  asd2-rou-1044.NL.eurorings.net (134.222.230.226)  767.319 ms  751.061 ms  759.146 ms</pre>
    </blockquote>
    L3 hands off from san jose to chicago, and launches to netherlands
    within this eurorings.net next in the as-path.<br>
    <blockquote cite="mid:BLU177-W1960C65F4DEEFB7E85EB489BE0@phx.gbl"
      type="cite">
      <pre wrap="">
15  134.222.97.18 (134.222.97.18)  760.857 ms  728.594 ms  759.813 ms</pre>
    </blockquote>
    Probably a mutual peering switch at the euro data center. <br>
    <blockquote cite="mid:BLU177-W1960C65F4DEEFB7E85EB489BE0@phx.gbl"
      type="cite">
      <pre wrap="">
16  te5-4.swcolo1.1d12.xs4all.net (194.109.12.2)  763.195 ms  756.420 ms  763.124 ms
17  *  *  *
18  *  *  *
19  *  *  *
20  *  *  *
21  *  *  *
22  *  *  *
23  *  *  *
24  *  *  *
25  *  *  *
26  *  *  *
27  *  *  *
28  *  *  *
29  *  *  *
30  *  *  *</pre>
    </blockquote>
    this <a
      href="https://www.ultratools.com/tools/asnInfoResult?domainName=3265">xs4all.net</a>
    is still advertising the route, but there's a loop in routing
    (conflicting routes) internally where they hand off to a customer
    (old customer?):<br>
    <br>
     <a href="http://xostats.xo.com/cgi-bin/xostats/diagtool-pub/bgp">show
      ip bgp</a>  82.94.226.104  <br>
     BGP routing table entry for 82.92.0.0/14, version 123161444<br>
     * * *  Advertised to update-groups:<br>
          59        <br>
     * * *  Refresh Epoch 1<br>
     * * *  2828 6939 <a
      href="https://www.ultratools.com/tools/asnInfoResult?domainName=3265">3265</a>,
    (received & used)<br>
    <br>
    ... so they take your request within the /14 aggregate that route
    that falls in, but no one home at that more specific route/ip
    address, and the trace bounce until ttl's expire @ 30 as a
    precaution against bad network administration like that (this is
    what sinkhole routing to null0 is for).<br>
    <br>
    FWIW, I get the same from cox here to that IP, but that IP isn't
    what blender.net resolves to:<br>
    <br>
    mb@host:~$ ping blender.net<br>
    PING blender.net (208.113.154.63) 56(84) bytes of data.<br>
    64 bytes from apache2-cabo.caroline.dreamhost.com (208.113.154.63):
    icmp_req=1 ttl=53 time=77.1 ms<br>
    ^C<br>
    --- blender.net ping statistics ---<br>
    2 packets transmitted, 2 received, 0% packet loss, time 999ms<br>
    rtt min/avg/max/mdev = 77.102/77.364/77.627/0.382 ms<br>
    <br>
    mb@host:~$ nslookup 82.94.226.104<br>
    Server:        127.0.1.1<br>
    Address:    127.0.1.1#53<br>
    <br>
    ** server can't find 104.226.94.82.in-addr.arpa.: NXDOMAIN<br>
    <br>
    What is this ip?  Do you have cached indefinite dns or something for
    it as blender.net?  What does it resolve to for you?<br>
    <br>
    -mb<br>
  </body>
</html>