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(a)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" ?
