Network engineering overview: Detailed design considerations

the engineer rarely initiates a network effort. Far more often, the engineer inherits the general idea from an architect or someone in pre-sales who did just enough high-level work to come up with a price tag. After that, it's up to the network engineer to come up with a detailed design that turns a pile of hardware into a functional network.

More tips in the 'Network engineering overview' series Technology Techniques for making changes Policy and process

Consistency

The No. 1 way to minimize the number of times you get paged in the middle of the night because "the network's down" is to do things consistently. Standardization is always the subject of much discussion. But desiring standardization is easy. The hard part is achieving it, because technology changes rapidly.

The trick is figuring out when you should implement something the old way so it will be consistent, and when you should implement something the new way because it's enough of an improvement to justify the deviation. Configuration management can help: Create a process that allows you to update everything so that it is all implemented the new way and all consistent.

Minimum and maximum configs

A major decision in the detailed design revolves around how much you trust the network devices to make good decisions. On most routers and switches, a minimum number of commands are required to achieve connectivity. Some devices will work out of the box with no configuration because they automatically configure themselves in various ways. You can also specify hundreds of commands on the same router or switch to achieve essentially the same connectivity while ensuring that your network works exactly the way you want, in a very deterministic fashion. That is, you leave nothing to chance or to be auto-negotiated; you define and customize everything.

We have probably all encountered architects who subscribe to both extremes and all points in between. The extremes have their advantages and disadvantages. Obviously, the more deterministic something is, the better -- assuming you know what you're doing. Defining everything can be helpful or harmful when troubleshooting, depending on what went wrong, but it is far more time-consuming to configure.

In my opinion, the happy medium depends on how large the environment is. The larger the network, the less I leave to chance, particularly as far as routing protocols are concerned. But in any case, you want to understand your options and choose them intentionally with some rationale, instead of configuring seemingly random commands across random devices in the network.

Design for support

Keep it simple... KISS Principle, defined

Design for lifecycle management

Yet another thing to keep in mind when faced with choices between different technologies or configurations is the maturity and roadmap. Implementing something new carries long-term risks, not just the immediate risk of incompatibility. For instance, if a technology isn't widely adopted, it might not be supported in the next version of hardware or software, forcing an early design change.

You also have to consider how difficult it will be to move away from a technology. As an example, most Cisco LAN routers and switches support MPLS, so if you had a large campus network with several thousand users in various organizations and you decided to run MPLS in the core of your LAN with different VRFs for organizations and security zones, you could offer some really fantastic new services to your users in a way that would be far superior to normal VLAN trunking. And yet, four or five years from now, how would you get out of that situation? While everyone else is migrating from simple routed LAN networks to the latest and greatest technology, you'll be facing a much more difficult situation, particularly if your users have become accustomed to features that aren't offered by the next big thing.

About the author:
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.