[3507] in North American Network Operators' Group
Re: problem at mae-west tonight?
daemon@ATHENA.MIT.EDU (epg@merit.edu)
Thu Jul 18 15:59:31 1996
From: epg@merit.edu
To: matthew@scruz.net (Matthew Kaufman)
Date: Thu, 18 Jul 1996 15:54:31 -0400 (EDT)
Cc: nanog@merit.edu
In-Reply-To: <199607170849.BAA11320@scruz.net> from "Matthew Kaufman" at Jul 17, 96 01:49:10 am
Matthew,
>Matthew Kaufman writes:
>
> Here's an edited copy of mail I just sent elsewhere, which I believe
> deserves some thought by other network operators :
>
> Just to update you on this situation:
> The problem was caused by a bad NetEdge device on the link from
> Netcom to MAE-West. It caused a partial failure of layer 2 connectivity
> from July 13 08:30 PDT until July 15 16:00 PDT. That's over 2 days.
> The current design and implementation of the route server suffers from
> two fatal flaws which, until they are fixed, will mean that I avoid using
> route servers at all costs:
>
> 1. The route server does not have access to the true state of layer 2
> interconnectivity, and thus cannot adjust its announcements to avoid
> "black holes" in the layer 2 fabric, be they caused by missing ATM
> PVCs or bad bridging devices. Clearly we need a protocol whereby the
> route server can gain information from the routers about who they can
> and cannot see. (Others here have suggested an approach similar to
> the new OSPF multipoint model)
>
> 2. The route server does not have a mechanism whereby a client router can
> force the route server to NOT advertise information to another client,
> except by editing the policy information and waiting for it to reload.
> That time-frame is excessive from a network operations standpoint,
> because every minute that the route server announces a route into a
> black hole, customers are without service... service which can be
> restored simply by tearing down the session with the route server, which
> of course forces it to stop announcing routes to _every_ client...
> solving the one problem, and causing others at the same time.
>
> -matthew kaufman
> matthew@scruz.net
>
> ps. Given that I'd like to refuse to use the route servers, should I _not_
> peer with them, but make my RADB policy look right, so that other people
> can tell what my policy is? or should I peer with them, to help their
> statistics gathering, but set my policy to "don't advertise anything to
> anyone" ?
>
>
We would encourage you to continue to export routes to the route servers
and to register your policy in the RADB. We will explore potential
solutions to the issues you raise.
--Elise
