Network engineering overview: Detailed design considerations
Implementing architectural concepts and dealing with detailed network designs must be second nature to the network engineer. In the conclusion of our tip series on things network engineers need to know to be effective, Tom Lancaster provides some considerations to keep in mind when you are in the process of turning a pile of hardware into a functional network.
An effective network engineer must have some expertise in implementing architectural concepts. In most organizations,...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
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.
 |
||||
|
|
|||
|
||||
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
|
||||
|
|
|||
|
||||
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.
