Their provider has peering issues, or
simply got turned off and their provider isn't null-routing their
smaller block.
On 01/15/2014 01:02 PM, ChasM wrote:
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
Probably your gateway/router. 192.168.0.1 is default.
2 * * *
3 * * *
4 * * *
5 * * *
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.
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
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.
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
L3 hands off from san jose to chicago, and launches to netherlands
within this eurorings.net next in the as-path.
15 134.222.97.18 (134.222.97.18) 760.857 ms 728.594 ms 759.813 ms
Probably a mutual peering switch at the euro data center.
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 * * *
this xs4all.net
is still advertising the route, but there's a loop in routing
(conflicting routes) internally where they hand off to a customer
(old customer?):
show
ip bgp 82.94.226.104
BGP routing table entry for 82.92.0.0/14, version 123161444
* * * Advertised to update-groups:
59
* * * Refresh Epoch 1
* * * 2828 6939 3265,
(received & used)
... 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).
FWIW, I get the same from cox here to that IP, but that IP isn't
what blender.net resolves to:
mb@host:~$ ping blender.net
PING blender.net (208.113.154.63) 56(84) bytes of data.
64 bytes from apache2-cabo.caroline.dreamhost.com (208.113.154.63):
icmp_req=1 ttl=53 time=77.1 ms
^C
--- blender.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 77.102/77.364/77.627/0.382 ms
mb@host:~$ nslookup 82.94.226.104
Server: 127.0.1.1
Address: 127.0.1.1#53
** server can't find 104.226.94.82.in-addr.arpa.: NXDOMAIN
What is this ip? Do you have cached indefinite dns or something for
it as blender.net? What does it resolve to for you?
-mb