An effective network engineer must have some expertise in implementing architectural concepts. In most organizations, 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.
Usually, the detailed design includes such information as which IP address in a subnet you should use for an interface, which one of the 48 ports on a switch you should plug the router into, and the specific commands that make up device configurations. This information may not seem terribly important, but the thing that keeps it interesting is that there are many ways a router or switch can be configured to accomplish a given task -- and some ways are much better than others.
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
Since network designers are usually the most skilled individuals on the team, they should always consider the rest of the team when given a set of options. Creating a needlessly complex detailed design (no matter how impressive) is a bad idea if you have to support it, and it's a horrible idea if your junior colleagues have to support it. That's not to say you have to design for the lowest common denominator, but you'd better have a training plan before you do anything crazy.
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.
