The Case for a Vendor-Neutral Networkby Kevin Dooley, author of Designing Large-Scale LANs
As a consultant, I frequently see networks that are built exclusively using equipment from one vendor. There are some obvious advantages to this approach, but I believe that the advantages of a vendor-neutral network design philosophy are greater still. In many ways the situation is similar to what happened in the mainframe world before networks and client-server applications became common. Many companies bought their computing equipment exclusively from one manufacturer and wound up paying far more money for it as a result. They also found that the proprietary technology prevented them from buying less expensive and more powerful equipment from other vendors unless they abandoned their entire initial investment.
This article looks at the benefits and trade-offs that result from applying a best-of-breed philosophy to selecting network equipment. There is still room for an exclusive relationship with one vendor, but I believe that it is important to fully understand the consequences of running a single-vendor network. Looking at the bigger picture, a single-vendor network becomes more difficult to justify, and the vendor-neutral network design philosophy emerges as the better choice in most cases.
There are four main benefits to designing a network to be independent of any single equipment vendor. The relative importance of these benefits will change depending on your priorities and which vendors you choose, so the order is arbitrary. The benefits are:
The first two points are tied together. Many types of equipment are available from several different vendors. For example, most network hardware vendors have routers and switches with a variety of different physical port configurations. If these devices are going to be used in a highly specialized way that requires either software or hardware features that are only available from one manufacturer, then the choice of vendor is easy. But most of the time these devices are used in much simpler ways. The selection process can be widened to include comparable devices from several different vendors.
By opening up the selection process in this way, you gain the two most important benefits of a competitive market. You force the vendors to compete with one another by either having the best prices or the best technology, or some combination. One device is going to have the best throughput, another the best filtering, and still another will have the lowest price. You can then choose the one that best meets your needs. Most organizations do this sort of analysis at some point. But I frequently talk to clients who mistakenly make this decision once and for all. Not only do they decide that a particular vendor's equipment is the most appropriate, but they decide that this vendor's entire equipment line is the best across the board.
The key to benefiting from the market competition in networking equipment is to select the best of breed for each of the different categories of device. Access devices have vastly different requirements from core switches, so there is no reason to suppose that the vendor with the best of one has the best of the other.
Bear in mind that by "best" I mean the one that most closely meets your specific requirements for that device. A device that has sophisticated features that you don't need is not better than another device that has only those features that you do need. In another network, however, the more sophisticated device may be the only option.
The third benefit is greater flexibility. New and improved technology is continuously introduced to the market. Sometimes this new technology will ideally match your requirements. When this happens, you will want to be able to install the new equipment that implements this technology. The different network hardware vendors actively compete to be the first to devise and implement technological improvements. So tying your network to a single vendor frequently means that your chosen hardware vendor will not be the first to implement some important new feature. Perhaps they will catch up; but if you need the feature now, you are better off if you can buy at least this one device from the competing vendor.
A vendor-neutral design philosophy allows you to change vendors to embrace new technology for two reasons. First, and most obvious, if you are tied to a single vendor, you are not able to try new technology from other vendors at all. But, that is just a matter of mind-set. The real issue is the second reason: a vendor-neutral design philosophy forces you to use open, non-proprietary protocols. Without such a design philosophy, it is often impossible to introduce equipment from a new vendor.
What are your experiences with single-vendor versus vendor-neutral networks?
In the current economic climate, every network professional should be acutely aware of the possibility of the financial problems of their favorite hardware vendors. Although I'm not predicting anybody's imminent demise, it is important to remember that sometimes companies get into trouble and have to discontinue product lines to cut costs and remain competitive. Sometimes they must refocus on their core products, possibly spinning off or selling off whole divisions. This can leave a network engineer with a serious problem that can only be addressed by implementing equipment from other vendors.
If the network design employs a fundamental philosophy of using the best equipment for a particular function regardless of vendor, then the change is greatly simplified. There will be no proprietary protocols to complicate the removal of unsupported equipment. And, more importantly, it will be straightforward to swap out one piece of equipment at a time. Just because equipment is no long supported doesn't mean that you have to immediately remove it. But it does mean that you should have a migration plan. A migration plan that involves simply swapping one box at a time is clearly much easier than one that requires a major redesign.
Naturally, there is a cost to be paid for going with a vendor-neutral network. There are three main benefits to choosing one vendor and sticking with it. It is important to be aware of these benefits so that you properly balance them against the benefits of a vendor-neutral design philosophy. The benefits are:
Over the years many vendors have introduced proprietary protocols and proprietary extensions to standard protocols. This means that you cannot swap individual pieces of equipment taking part in these protocols with equipment from competing vendors without also changing protocols. And, unfortunately, changing protocols often requires topology changes as well.
For example, if two Ethernet switches communicate using a proprietary trunk protocol, then it is not possible to change the access level switch. If a competing vendor were to introduce an extremely inexpensive high-speed switch that will allow Gigabit Ethernet to every desktop, then you might want to take advantage of this. However, the proprietary trunk protocol makes the change cumbersome at best. If the open standard 802.1q VLAN trunk protocol were used instead, then it would be much easier to make this swap.
So why do proprietary protocols exist? The case of trunk protocols makes a good example. The 802.1q standard was relatively late in developing, so vendors were forced to develop their own proprietary standards as a stopgap measure until an open standard was available. The proprietary standards continue to exist because they include features such as link multiplexing that are not available in the open standard.
It is important to fully understand the consequences of running a single-vendor network.
In other cases, such as Cisco's Enhanced Interior Gateway Protocol (EIGRP), proprietary protocols are useful because they are reliable and easy to implement. EIGRP is also useful because it supports the dynamic routing of not just IP, but also IPX and Appletalk. This has the effect of greatly simplifying a network design, since the routing infrastructure for all of these protocols can easily be built in parallel. If unrelated protocols are used for each of these protocols, on the other hand, it can be difficult to make a network topology that works for all of them equally well. In some cases it is necessary to resort to tunnels to carry foreign protocol traffic between islands of native support. Using EIGRP largely solves this problem, but it means that all of your routers must be Cisco.
Some vendors like to give special pricing to their biggest customers. This usually comes with an assurance of exclusivity. The customer promises not to buy anything from a competitor unless the vendor doesn't have a product in the category. So, for example, a company might sign a "partnership" contract with a particular vendor compelling them to buy all of their routers and switches from the company. But if that vendor doesn't make firewalls, then it would be acceptable to use equipment from a competitor. This sort of agreement also often specifies a minimum dollar amount that the customer will order per year or per quarter. In exchange for this, the customer receives a significant discount, often as much as 40 percent.
There are a few important things to bear in mind with this sort of agreement. First, it is often possible to get a similar discount by simply shopping around for competitive equipment. Second, if you do shop around, you can often come back to the first vendor and arrange for a discount in exchange for not going to a competitor. You will get the best discounts by buying in volume anyway. If you are going to buy several million dollars worth of equipment, just about any vendor will be excited enough by the sale to offer incentives. This is particularly true if they know that you are perfectly willing to go to a competitor if the price is not good enough. I have seen vendors jump through hoops to get a large customer to switch to them, even to the extent of taking a loss just to make the sale and secure the customer. This is a free market; make it work for you.
Finally, it is critical to remember that these sorts of discounts really only apply to very large customers. If you aren't buying millions of dollars worth of equipment, then the discounts you get from such an arrangement will benefit the vendor much more than the customer. In most cases you will be far better off with a best of breed approach.
The more types of devices you need to manage; the more you will need to train your staff. And you will also potentially need to manage more types of software. Most hardware vendors make so-called "instance manager" software to help manage their equipment. If you use Ethernet switches from three different vendors, then you will potentially require three different instance mangers, possibly running on three different platforms. This is a nuisance and introduces an extra hidden expense due to the extra hardware and software costs.
So there are positive and negative aspects to vendor neutrality. But there are several important measures that you can take to accentuate the positive.
In addition, configuration of devices from different vendors is rarely done in the same way. Cisco routers use their well-known command-line interface, which is completely different from the management interface used to configure Nortel routers. Sometimes the documentation from different vendors uses different terminology for similar concepts as well. So there is definitely a training issue involved if an organization is going to permit the use of many different types of equipment.
Interestingly, the use of open protocols helps to limit this. Although routers from different vendors are configured differently, the most difficult and important thing for the engineer to understand is how the protocol works, not how to configure it. The functioning of an open protocol such as Open Shortest Path First (OSPF) is the same on Nortel as it is on Juniper routers. So an engineer who understands the protocol well will have little difficulty in learning how to implement it on a new platform.
So there are positive and negative aspects to vendor neutrality. But there are several important measures that you can take to accentuate the positive while limiting the negative. The two most important are developing internal standards for common types of devices and using open standards throughout your network.
It is often possible to get around some of these trade-offs. One of the best ways to do this is to establish standards for certain types of devices. For example, a particular make and model of router might be used for WAN access at all remote sites. Similarly, it should be possible to standardize on access switches, on core switches, and so forth. Standardization on this level is actually much more effective than standardization for a single vendor for all types of equipment.
A good network design considers the network as a set of similar modules. You have access modules for connecting users into the network, LAN and WAN distribution modules, and network core modules. It is useful to standardize these modules, so that all access switches look similar, all LAN trunks use the same protocols, and all WAN distribution uses a common set of WAN protocols. Once these functions are defined, you can start looking for the most appropriate vendor for each piece of equipment.
For access switches the requirements are low cost, high port density, and some sort of trunk up-link. For core switches you don't care so much about port density, but you do care about throughput. So it is not hard to imagine that one vendor's equipment will be better in one case but not the other. You can develop a standard that says that whenever you need a device of a particular type, you will always use the same vendor, make, and model. These standards need to be revisited periodically as new technology comes to market.
The ways to achieve vendor neutrality are relatively simple. They involve carefully selecting and deploying only open standards for networking technology and protocols.
This approach has many advantages. First, it still allows you to buy in bulk. If you need a thousand access routers, you can still negotiate a good price discount without having to also promise to buy core switches from the same vendor. Second, it makes it much easier for network engineers to implement new network elements. If a new remote branch site is required, then there is a simple template for the required equipment. Third, if all devices of a particular functional type are the same make and model, then network management becomes much easier. This very effectively reduces the training and software problems mentioned earlier.
In fact, this approach not only allows you to establish special costing relationships with your vendors, it allows an extra level of bargaining power if the vendor knows that you can change your standards if the pricing is not competitive.
There are a few exceptions where a proprietary protocol might give better performance. In these cases it is worth considering, but you should always be prepared to consider this technology as a pure throwaway if something better comes along. In most cases it is possible to use an open standard.
A common example is found in trunk protocols. The open standard for VLAN tagging is 802.1q. But, as I mentioned earlier, many switch vendors have their own standards as well. The result is a serious lack of interoperability that effectively forces the network engineer to use one vendor's equipment exclusively. Unless there is a significant advantage to using the proprietary protocol that outweighs the many benefits of open standards and vendor neutrality, it is best to stay away from them.
Another good example is the Cisco proprietary routing protocol EIGRP mentioned earlier. This protocol is reliable, stable, and easy to configure, so there are many benefits to using it. But a network design that is based on it is compelled to contain only Cisco routers. In this case it is particularly difficult to change the decision down the road, too. Migration from EIGRP to an open standard such as OSPF frequently involves significant network topology changes. This is because OSPF scales best when constructed using a simple hierarchy of OSPF Areas. But, while EIGRP can benefit from a hierarchical design, there need not be such clearly defined structures. Most EIGRP networks cannot be easily converted to OSPF. So the decision to use EIGRP is inherently a decision to commit all routers in the network to one vendor. This may not be a bad thing, but the consequences must be understood clearly from the outset.
I'd like to mention one important counter example where the open standard is not critical. Cisco's proprietary standard HSRP (Hot Standby Routing Protocol) is functionally similar but incompatible with the open standard VRRP (Virtual Router Redundancy Protocol). Other router vendors such as Nortel and Juniper use VRRP to do the same things that Cisco routers do with HSRP. HSRP and VRRP are both used to make one router a redundant backup for another. The backup router monitors the primary router and takes over its IP and MAC addresses in case of a failure. The critical point, though, is that you usually want to make these two routers nearly identical copies of one another. Even if they are configured differently, they occupy similar network functions, so your internal standards should mean that they are from the same vendor. So it would be extremely unusual to have a situation where routers from different vendors need to share the same redundancy protocol.
I've tried to show the benefits of a vendor-neutral design philosophy. This issue is only worth discussing because so many enterprise networks make exclusive use of a single vendor for all of their networking equipment. The owners of these networks do so for a few good reasons. However, I believe I have demonstrated that the benefits of a vendor-neutral network outweigh those of a single-vendor solution.
The principle benefits to an exclusive single-vendor agreement are cost savings. However, in most cases it is more likely that the bargaining advantage of being able and willing to switch vendors quickly and easily will bring greater cost benefits. Doing this also protects the network against business decisions by the vendor such as eliminating product lines or, in the worst case, bankruptcy. With the current economic conditions in the telecommunications sector, this is an issue that should be in the back of every network designer's mind.
The ways to achieve vendor neutrality are relatively simple. They involve carefully selecting and deploying only open standards for networking technology and protocols. This allows the organization to develop internal standards for each of the different generic types of equipment that will be required. An organization that uses the best equipment for its requirements will have the best overall network.
Kevin Dooley is an independent networking consultant who has been designing and implementing networks for more than ten years.
O'Reilly & Associates recently released (December 2001) Designing Large-Scale LANs.
Sample Chapter 3, Design Types, is available free online.
For more information, or to order the book, click here.
Return to the O'Reilly Network.
Copyright © 2009 O'Reilly Media, Inc.