Computer networks are like any complex engineering project. A small network can be slapped together quite successfully with minimal experience. But a larger network requires careful thought and planning. As with many types of engineering projects, this planning and design phase is best served by an organized and disciplined design philosophy. The trouble with design is that it is difficult to differentiate between personal or near-religious biases and sound ecumenical strategies that can result in better usability, stability, security, and manageability.
Everyone has religious biases when it comes to network design. This is because most networks are so complex that a feeling of black magic falls over anybody trying to understand them. They tend to be too large and too intricate to hold in your mind all at once. So when some particular incantation appears to work miracles, it is adopted as an article of faith. And when a vendor's equipment (or support engineer) saves the day in some important way, it can turn into a blanket belief in that vendor as savior.
So, in the interests of making plain my assumptions and biases, let me explain right from the start that I am a network agnostic. I have used equipment from most of the major vendors, and I believe that every individual piece of gear has its pluses and minuses. I prefer to use the gear that is right for the job, rather than expressing a blind devotion to one or another. So this book is vendor neutral.
I will discuss some proprietary protocols and standards because these are often the best for a particular situation. But in general I will try to lead the reader towards open industry standards: I believe that it is unwise to lock your technology budget to one particular vendor.
In the mainframe-computing era, many firms spent large amounts of money on one company's equipment. Then they found that this required them to continue spending their hardware budget with that company unless they wanted to abandon their initial investment. All incremental upgrades merely reinforced their dependency on this one vendor. This was fine unless another manufacturer came along with gear that would be better (cheaper, faster, more scalable, etc.) for important business requirements of the company. It is wise to avoid the "fork-lift" upgrade where the entire infrastructure has to be replaced simultaneously to improve performance.
In practice, most LANs are multivendor hybrids. This may be by design or by chance. In many cases a best-of-breed philosophy has been adopted so that a particular type of Ethernet switch is used in the wiring closets, another type at the backbone, with routers from another vendor, while ATM switches and long-haul equipment are provided by still other vendors. In other cases, the multivendor nature of the network is more of an historical accident than intention. And there are also cases where all or nearly all of the network hardware comes from the same manufacturer. If this is the case, then the choice should be made consciously, based on solid technical and business reasons. Having stated my biases here, I leave the reader to make these decisions freely.
Because computer networks are large and complex engineering projects, they should be designed carefully and deliberately. There are many important questions to ask about how a network should function and what purposes it needs to serve. And there are even more questions to ask about how best to meet these objectives. This book will serve as a guide to this process.