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