Trouble reaching whois.ripe.net and www.ietf.org

[Williams, Marc]

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
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
> 
>