6bone partitioned?

[Philip Blundell]

Hi guys.

Here's a message I just sent to the UK-6bone mailing list.  Not wanting to
point fingers of blame, but could NRL and JOIN have a look at their
routing tables and see if all is well? 

On a more positive subject, now that things are by and large fairly
reliable and we are starting to see a fair amount of IPv6-capable mail
software at large in the world, would there be any interest in setting up
an exploder for this list so that people can actually the mail over their
6bone connections? 

p.

---------- Forwarded message ----------
Date: Tue, 22 Apr 1997 21:06:33 +0100 (BST)
From: Philip Blundell <Philip.Blundell@pobox.com>
To: Peter Curran <pcurran@ticl.co.uk>
Cc: UK 6bone <uk6bone@scorpio.ecs.soton.ac.uk>
Subject: Re: Connectivity

On Tue, 22 Apr 1997, Peter Curran wrote:

> I went and checked the NIST page (my normal measure of 'whats working')
> and all was well.  Looking at the traceroute info there I think that
> there is some partitioning going on for sites that are not directly or
> indirectly connected to NRL (or maybe its the other way round) - our
> primary path is via a direct tunnel to NRL. 

It certainly looks now as if there is a partitioning effect.  I suspect
that some routes are getting lost where the backbone nodes peer with each
other. 

This is what I get if I try to traceroute to BT-LABS (who get their
connectivity from NRL).

kings-cross:~$ traceroute 5f06:d800:c171:3a00::1
traceroute to 5f06:d800:c171:3a00::1 (5f06:d800:c171:3a00::1), 30 hops
max, 60 byte packets
 1  6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111)
14.777 ms !N  16.376 ms !N *
kings-cross:~$ 

They apparently are up, because NIST can see them (and I imagine TICL can
too). 

I checked Bob Fink's 6bone map.  With the exception of NIST (who I _can_
see) all the other nodes off NRL are unreachable from here.  I get a
similar picture in Germany; all nodes fed from JOIN are unreachable aside
from BME-FSZ.

A traceroute to BME gives me this:

kings-cross:~$ traceroute 5f09:f300:9842:4c00:4c:0:c067:7b99
traceroute to 5f09:f300:9842:4c00:4c:0:c067:7b99
(5f09:f300:9842:4c00:4c:0:c067:7b99), 30 hops max, 60 byte packets
 1  6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111)
21.024 ms *  12.603 ms
 2  5f07:2b00:82e1:e700:5:3333:3333:3333
(5f07:2b00:82e1:e700:5:3333:3333:3333)  79.197 ms *  98.866 ms
 3  tracy.ipv6.fsz.bme.hu (5f09:f300:9842:4c00:4c:0:c067:7b99)  1007.476
ms *  630.767 ms
kings-cross:~$

and a traceroute to NIST gives me this:

kings-cross:~$ traceroute 5f00:3100:8106:3300:0:c0:3302:5a
traceroute to 5f00:3100:8106:3300:0:c0:3302:5a
(5f00:3100:8106:3300:0:c0:3302:5a), 30 hops max, 60 byte packets
 1  6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111)
15.904 ms *  12.136 ms
 2  6bone-core.ipv6.imag.fr (5f06:b500:8158:1a00:0:800:2bb9:f33d)  74.400
ms  66.592 ms  100.538 ms
 3  luna-v6.ipv6.imag.fr (5f06:b500:8158:1a00:0:800:2075:24ea)  70.568 ms
329.833 ms  64.592 ms
 4  ipng9.ipng.nist.gov (5f00:3100:8106:3300:0:c0:3302:5a)  245.904 ms *
482.212 ms
kings-cross:~$ 

- in both cases it seems that either the 6bone map is wrong about the
connectivity, or there are backup routes in place.

I'll forward this to the main 6bone mailing list and see what people there
have to say.

p.