On Tue, Nov 10, 2009 at 10:31:40PM +0800, Mark Tinka wrote: > <instructor hat> > > However, wearing my "instructor" hat when we give workshops > in various places around the world, we tend to teach folk > how to build large scale networks, based on our own > experiences doing the same. > > In some cases, we say build scaling into your operations > even when it may seem "unnecessary", because the general > assumption is that your network is going to grow. Sure, it > could take 5, 10, 15 years, depending on whom you ask, but > if there's a chance it does grow, you don't want to re-work > your entire design to add scaling into the mix; especially > since adding scalability in from the start doesn't add any > incremental cost in terms of $$ or complexity.
<arguing with the teacher hat> I have nothing against advocating that you design your network to scale from the very beginning, and (without trying to channel Vijay Gill here) IMHO if oyu don't design your netwrok to scale then in all likelihood it WON'T scale. But there is also a point where you start making more trouble for yourself than you save, and may actually inhibit your growth by adding unnecessary additional complexity. Smart network engineering is about knowing the network you are trying to build, and figuring out where that magic line is so you don't cross it. I think your argument applies perfectly to situations like "but I only have a few hundred /30s between my 10 3560s, why can't I just redistribute connected/static into my IGP and call it a day". Yes you COULD, but if you grow your network by even a very small amount you'll start to bump the CAM limits on your stackable switches, and thus you should probably engineer your network to scale past that limit from the very beginning. Taking the time to design a system with only loopbacks into IGP + iBGP loopback peering and redistribution of other routes into BGP may be more time consuming than just slapping a redist into your IGP, but it will save you more time in the end. On the other hand, what level of scale do you need before IGP areas actually start to pay off, and make it worth the added complexity and other issues you will impose (inter-area TE problems, etc)? You'd need to take your 10 routers to what? 100? 1000? 10000? At what point does your newly expanded network look absolutely nothing like your original network, to the point that nothing you decided about your 10 router network has any bearing on your new network? If you're really designing some massive dial network with the potential for 10000 pops, or the next IBM Global Services network, you may have a legitimate reason for needing the IGP areas. But if you're building a more concentrated network there just may never be a situation where there is any benefit no matter how big you grow (i.e. I don't think Level 3 has any need for them :P). There is no right answer for everyone, your network may look very different from mine, etc. We can both make arguments for simplistic theories like "you should always design to scale" vs "keep it simple stupid" until we're blue in the face, but at the end of the day this is an engineering question to which there is no one correct answer. </arguing with the teacher hat> Did I mention I got a lot of D's in class from arguing with the teacher? :) -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
