<br><font size=2 face="sans-serif">One key consideration you should think about is the ability to perform maintenance on redundant devices in the N+1 model without impacting the availability of the network.</font>
<br>
<br><font size=2 face="sans-serif">Brent</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Timothy Brown <tim@tux.org></b></font>
<br><font size=1 face="sans-serif">Sent by: owner-nanog@merit.edu</font>
<p><font size=1 face="sans-serif">01/16/2004 10:14 PM</font>
<br>
<td><font size=1 face="Arial">        </font>
<br><font size=1 face="sans-serif">        To:        nanog@merit.edu</font>
<br><font size=1 face="sans-serif">        cc:        </font>
<br><font size=1 face="sans-serif">        Subject:        One-element vs two-element design</font></table>
<br>
<br>
<br><font size=2 face="Courier New"><br>
I fear this may be a mother of a debate.<br>
<br>
In my (short?) career, i've been involved in several designs, some successful,<br>
some less so.  I've recently been asked to contribute a design for one of the<br>
networks I work on.  The design brings with it a number of challenges, but<br>
also, unlike a greenfield network, has a lot of history.<br>
<br>
One of the major decisions i'm being faced with is a choice between one-element<br>
or two-element design.  When I refer to elements, what I really mean to say<br>
is N or N+1.  For quite some time now, vendors have been improving hardware<br>
to the point where most components in a given device, with the exception of<br>
a line card, can be made redundant.  This includes things like routing and<br>
switching processors, power supplies, busses, and even, in the case of vendor<br>
J and several others, the possibility of inflight restarts of  particular<br>
portions of the software as part of either scheduled maintenance or to correct<br>
a problem.<br>
<br>
I have always been traditionally of the school of learning that states that<br>
it is best to have two devices of equal power and on the same footing, and,<br>
in multiple site configurations, four devices of equal power and equal footing.<br>
I feel like a safe argument to make is N+1, so that is the philosophy that<br>
I tend to adopt.  N+2 or N...whatever doesn't seem to add a lot of additional<br>
security into the network's model of availability.  This adds complexity, but<br>
I prefer to think of this in terms of,  "Well, I can manage software or design<br>
complexity in my configurations, but I can't manage the loss of a single<br>
device which holds my network together."  Now I must view this assertion in<br>
the context of better designed hardware and cheap spares-on-hand.<br>
<br>
Of course, like many other folks, I have tried to drink as deeply as I can<br>
from the well of knowledge.  I've perused at length Cisco Press' High<br>
Availability Network Fundamentals, and understand MTBF calculations and<br>
some of the design issues in building a highly available network.  But from<br>
a cost perspective, it seems that a single, larger box may be able to offer me<br>
as much redundancy as two equally configured boxes handling the same traffic<br>
load.  Of course, there's that little demon on my shoulder, that tells me<br>
that I could always lose a complete device due to a power issue or short,<br>
and then i'd be up a creek.<br>
<br>
We have a history of adopting the N+1 model on the specific network i'm <br>
talking about, and it has worked very well so far in the face of occassional<br>
software failures by a vendor we occassionally have ridiculed here on nanog-l.<br>
However, in considering a comprehensive redesign, another vendor offers<br>
significantly more software stability, so i'm re-evaluating the need for<br>
multiple devices.<br>
<br>
My mind's more or less already made up, but i'd like to hear the design<br>
philosophies of other members of the operational community when adopting a<br>
N+1 approach.  In particular, i'd love to hear a catastrophic operational<br>
failure which either proves or disproves either of the potential options.<br>
<br>
Tim<br>
<br>
ObDisclaimer:  Please contact me off-list if you're okay with your thoughts<br>
on this matter being published in a book targeted to the operations community.<br>
<br>
</font>
<br>
<br>