The Case for a Vendor-Neutral Network
Pages: 1, 2
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.
Getting the Best of Both Worlds
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.