[20869] in SIPB IPv6
Re: limekiller broken?
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Mon Dec 28 19:34:02 2009
From: Ken Raeburn <raeburn@MIT.EDU>
To: Quentin Smith <quentin@mit.edu>
In-Reply-To: <alpine.DEB.1.10.0912281850400.25857@dr-wily.mit.edu>
Date: Mon, 28 Dec 2009 19:33:57 -0500
Cc: Greg Troxel <gdt@work.lexort.com>,
=?ISO-8859-1?Q?Daniel_Jared_Dom=EDnguez?= <danjared@mit.edu>,
sipbv6@mit.edu
On Dec 28, 2009, at 18:52, Quentin Smith wrote:
> We had a machine labeled "lemonkiller" that we were intending to
> transition services to. I don't think we got much past the
> installation of the OS, and the machine is now old and decrepit.
> It's currently powered off.
Old and decrepit already? Wow.
> I think the reason we didn't want to make it a VM is that it needs
> to have a connection to the W20 network to provide route
> advertisements there.
Well, it has one now, but I don't see any reason the w20 IPv6 router
has to be the same box. As long as SIPB has *some* machine (real or
virtual; shared or dedicated; in the office or in the machine room) on
the w20 net that can serve that function, it doesn't have to be
integral with the central IPv6 router for campus. Even if that
machine should be the current lemonkiller or limekiller and dedicated
to the purpose, it would mean only one subnet is depending on "old and
decrepit" hardware.
And all that's assuming that the XVM maintainers aren't willing to add
a second interface on the other network, even a USB 2.0 adapter.
They've got enough to deal with that I wouldn't expect them to like
the idea, but I don't know if it's actually been considered and
rejected.
Oh, and a related issue we haven't really looked at: Can we can IPv6
onto the campus wifi network(s)? I'm not familiar enough with the
wifi net configuration to know what we'd need. But maybe whatever
machine handles w20 wired IPv6 routing could also handle routing onto
the local wifi network too.
> I've been having problems on and off reaching well-known IPv6 sites
> from MIT; most notably, packages.debian.org. The problem always
> fixes itself by the time I can get anyone to debug from the other end.
If we see a collection of problems to various external sites, and have
some nice, pretty graphs and charts exported for the world to see, we
can point OCCAID at the graphs and complain. If it's just one site,
the problem may indeed be at the other end. So, probably we should
monitor reachability of some specific external sites too, I guess, not
just the remote tunnel endpoints?
I wonder too if we should make the logs of BGP activity accessible,
and run a "looking glass" setup where you can look and see if we've
lost routes when such problems come up. (I was playing with some LG
software years ago. I don't remember if I left it running. I think
it was probably on my old workstation in W92, though, which has since
been reallocated and I assume reinstalled.)
Ken
