Trouble reaching whois.ripe.net and www.ietf.org
Stig Venaas
stig.venaas at uninett.no
Tue Oct 17 21:42:11 CEST 2006
Williams, Marc wrote:
> trace 2001:948:0:F042::1
>
> Type escape sequence to abort.
> Tracing the route to 2001:948:0:F042::1
>
> 1 2001:4830:E6:D::1 4 msec 4 msec 4 msec
> 2 2001:4830:FF:F150::1 8 msec 12 msec 12 msec
> 3 2001:4830:FE:1010::1 80 msec 80 msec 80 msec
> 4 2001:7F8:4::D1C:1 80 msec 80 msec 80 msec
> 5 2001:1900:5:2::6 116 msec 116 msec 116 msec
> 6 2001:798:CC:1001:1301::1 116 msec 208 msec 116 msec
> 7 2001:798:CC:1301:1401::2 116 msec 116 msec 116 msec
> 8 2001:798:CC:1401:1501::2 132 msec 128 msec 132 msec
> 9 2001:798:15:10AA::2 132 msec 132 msec 132 msec
> 10 2001:948:0:F032::2 132 msec
> 2001:948:0:F03E::2 132 msec 132 msec
> 11 2001:948:0:F03D::1 140 msec 140 msec 136 msec
> 12 2001:948:0:F042::1 136 msec 140 msec 140 msec
Right. Now it's fine for me as well. Earlier on I got response back from
#8 below but not #9 I believe.
Tracing the route to 2001:503:C779:B::D1AD:35B4
1 2001:948:0:F042::1 12 msec 4 msec 0 msec
2 2001:948:0:F041::2 0 msec
2001:948:0:F02F::2 4 msec 0 msec
3 2001:948:0:F033::2 8 msec 8 msec 8 msec
4 2001:798:15:10AA::D 24 msec 20 msec 20 msec
5 2001:798:CC:1401:2201::1 28 msec 28 msec 24 msec
6 2001:798:CC:1301:1401::1 32 msec 32 msec 36 msec
7 2001:798:CC:1001:1301::2 40 msec 40 msec 40 msec
8 2001:1900:5:2::5 60 msec 56 msec 56 msec
9 2001:7F8:4::31F9:1 68 msec 68 msec 64 msec
10 2001:4830:FE:1010::2 136 msec 136 msec 136 msec
11 2001:4830:FF:F150::2 144 msec 144 msec 140 msec
12 2001:4830:E6:D::2 144 msec 148 msec 148 msec
13 2610:A0:C779::FE 148 msec 148 msec 152 msec
14 2001:503:C779:B::D1AD:35B4 144 msec 148 msec 148 msec
I can also reach whois.ripe.net now:
Tracing the route to 2001:610:240:0:193::202
1 2001:948:0:F042::1 4 msec 8 msec 0 msec
2 2001:948:0:F02F::2 116 msec
2001:948:0:F041::2 204 msec 200 msec
3 2001:948:0:F033::2 8 msec 8 msec 12 msec
4 2001:948:0:F032::1 8 msec 8 msec 8 msec
5 2001:798:15:10AA::1 8 msec 12 msec 8 msec
6 2001:798:CC:1401:1501::1 24 msec 28 msec 24 msec
7 2001:798:CC:1301:1401::1 32 msec 144 msec 32 msec
8 2001:798:CC:1001:1301::2 48 msec 36 msec 40 msec
9 2001:1900:5:2::5 56 msec 56 msec 56 msec
10 2001:7F8:4:1::CB9:1 72 msec 72 msec 72 msec
11 2001:668:0:2::640 76 msec 72 msec 76 msec
12 2001:668:0:2::1:181 76 msec 72 msec 72 msec
13 2001:7F8:1::A500:3333:1 44 msec 48 msec 48 msec
14 2001:610:240:0:193::202 44 msec 48 msec 44 msec
In this case we previously got response from #9, but not #10.
Anyway, all seems fine again now. Now I should just look into how to
get a better path by asking people to adjust filters or by getting
additional peerings... I might be getting back to some of you regarding
that...
Thanks,
Stig
> STIH2811A#
>
> Marc Williams
> Network Engineer
> Neustar, Inc.
>
> 571-434-5626 (desk)
> 571-283-1587 (mobile)
>
>
>>-----Original Message-----
>>From:
>>ipv6-ops-bounces+wan.engineering=neustar.biz at lists.cluenet.de
>>[mailto:ipv6-ops-bounces+wan.engineering=neustar.biz at lists.clu
>
> enet.de] On Behalf Of James Jun
>
>>Sent: Tuesday, October 17, 2006 12:33 PM
>>To: 'Stig Venaas'; ipv6-ops at lists.cluenet.de
>>Subject: RE: Trouble reaching whois.ripe.net and www.ietf.org
>>
>>
>>>From occaid prespective, there is alternate path available to reach
>>
>>>2603 at
>>
>>Stockholm, but it seems L(3) is doing just fine from here, at
>>least to the next-hop shown in your BGP show commands.
>>
>>It may be possible it's not working for IETF's
>>crit-infrastructure /48. If they can run a traceroute for us
>>to 2001:948:0:F042::1 that might help better.
>>
>>
>>traceroute6 to 2001:948:0:F042::1 (2001:948:0:f042::1), 64
>>hops max, 12 byte packets
>> 1 0.fe1-3.cr1.atl1.us.occaid.net 1.024 ms 0.853 ms 0.689 ms
>> 2 ge-0-1-0.cr1.iad1.us.occaid.net 14.565 ms 14.537 ms 14.431 ms
>> 3 21.ge0-0.cr1.ewr1.us.occaid.net 20.220 ms 20.237 ms 20.935 ms
>> 4 v3323-mpd.cr1.lhr1.uk.occaid.net 90.316 ms 89.977 ms 89.899 ms
>> 5 2001:7f8:4::d1c:1 91.032 ms 90.645 ms 90.505 ms
>> 6 2001:1900:5:2::6 125.838 ms 126.067 ms 126.017 ms
>> 7 so-7-2-0.rt1.vie.at.geant2.net 126.020 ms 125.966 ms 125.944 ms
>> 8 so-6-3-0.rt1.fra.de.geant2.net 126.554 ms 126.044 ms 126.144 ms
>> 9 so-1-3-0.rt1.lux.lu.geant2.net 139.965 ms 139.980 ms
>>139.912 ms 10 nordunet-gw.rt1.cop.dk.geant2.net 140.304 ms
>>140.138 ms 140.378 ms
>>11 dk-gw.nordu.net 140.489 ms dk-gw.nordu.net 140.535 ms
>>dk-gw.nordu.net
>>140.778 ms
>>12 no-gw2.nordu.net 148.424 ms 148.354 ms 148.296 ms
>>13 no-gw.nordu.net 148.577 ms 149.466 ms 148.467 ms
>>
>>James
>>
>>
>>>-----Original Message-----
>>>For www.ietf.org, the prefix 2001:503:C779::/48 is used and
>>
>>the story
>>
>>>is similar. We get an in-optimal path, and it again seems
>>
>>to stop in
>>
>>>level3.
>>>
>>>*> 2001:503:C779::/48
>>> 2001:948:0:F042::1
>>> 0 2603
>>>20965
>>>3356 30071 7786 i
>>>
>>>Use of these longer prefixes for critical infrastructure
>>
>>seems like a
>>
>>>bad idea to me. Due to many people filtering these, the
>>
>>paths are at
>>
>>>best in-optimal, and in this case not working at all.
>>>
>>>I assume you guys see similar things?
>>>
>>>Stig
>>
>>
More information about the ipv6-ops
mailing list