Proprietary? So what.

There was a time not too long ago when you could look out on the networking hardware landscape and it would be covered in teal colored devices from Cisco. There were other companies out there, but the bulk of what I saw out there was Cisco.

These days it is a different story. Whether it is due to merchant silicon, the rise of nerds worldwide, or a bunch of ex-Cisco employees getting some venture capital funding, I don’t know. The reality of the networking market today is that there are plenty of competitors out there with products superior to some of Cisco’s, or about the same but at a much lower price. Another thing influencing people’s decisions is that Cisco has a fair amount of technology that can be considered proprietary. It doesn’t always stick around(ie TDP, ISL), but a lot of it can still be found running on Cisco dominated networks(ie LWAPP, PAgP, EIGRP, HSRP). Competitors love to mention this and beat Cisco up in marketing slides or ad campaigns. They’ll demonize them for using proprietary technology and often gloss over the fact that Cisco is the REASON some of those standards they love exist today.

I’m not looking to go into exhaustive detail around the proprietary technology that companies like Cisco(Yes, other tech companies make proprietary things too.) create. Rather, I simply want to make the case that just because something is proprietary, it doesn’t make it bad. As an architect, engineer, designer, etc, you just need to be aware of how that proprietary technology/protocol works in the overall scheme of things.

In the interest of fairness, let me give you two differing points of view:

Read this: http://www.network-janitor.net/2011/02/proprietary-cometh-before-the-standard/

and then read this: http://etherealmind.com/when-proprietary-kill-standards/

Now, i’ll give you the most common issue/argument I come across: EIGRP vs OSPF

The arguments/reasons around using one or the other of these protocols consist of some of the following:

1. You only have Cisco switches and routers in your network, therefore EIGRP is okay to use.
2. Cisco sucks.
3. Other vendors suck.
4. EIGRP is easy.
5. OSPF provides a better view of the network from each router’s standpoint.
6. EIGRP converges quicker.
7. Only morons run EIGRP.
8. Multi-area OSPF is too hard.
9. EIGRP can summarize at each interface.
10. OSPF has a variety of different stub and stub-like areas.
11. EIGRP has a stub feature.
12. Most firewalls don’t speak EIGRP, and an additional argument to this is “Only morons would run dynamic routing protocols on firewalls. They aren’t routers. They’re firewalls.”.
13. I have multiple hardware vendors on my network, so I use OSPF.
14. EIGRP can do unequal cost load balancing. OSPF cannot.
15. EIGRP has the “Stuck in active” problem.
16. EIGRP is a “hybrid” protocol and took the best of distance vector and link state. (This is WRONG. See here: http://blog.ioshints.info/2010/08/eigrp-myths-debunked.html)

Perhaps you know of others. I don’t actually take a side in this particular argument. I happen to like both protocols. Maybe people think I am a Cisco fanboy if I state that I like EIGRP. I can assure you that isn’t the case. Whether I would use EIGRP or OSPF really comes down to “it depends”. Let us consider a few example networks below. Assume all equipment is Cisco and that BGP is being used on the WAN and Internet side.

Here’s a fictional enterprise data center that connects to the Internet. There are servers and storage on the access layer, and remote sites over redundant WAN carriers. This is probably a fairly common setup.

Would I use EIGRP here? Absolutely not. There are way too many moving parts here and potential to talk to devices other than Cisco. For the anti-3 layer switching(Core, Distribution,Access) people out there, I could have drawn a collapsed core and my answer would still be no to using EIGRP here. Needs within the data center are such that plenty of vendors other than Cisco will be in play. Guess what those vendors won’t be able to speak? 🙂

Here we have a remote office connected to the enterprise data center:

Would I use EIGRP here? Possibly. If I knew my routers and switches were going to stay Cisco for a few years, I just might. It’s only 4 devices as I don’t usually run layer 3 down to the access layer due to cost savings, and the fact that in small environments like this, I don’t see the benefit from a technology perspective. With minimal planning, I can migrate to OSPF in minutes with only 4 devices and experience far less than a minute of down time, if any.

When I started my current job, I came into a network that had EIGRP running in the corporate data center. All over the data center. With nothing but Cisco switches and routers, it wasn’t a big shock, or even that big of a deal as far as I was concerned. Prior to my company deciding to outsource IT operations to another company, I was talking to several vendors about getting some aggregation switches and a router to replace some Cisco 3750 switch stacks. I needed more fiber interface capabilities(1Gbps and 10Gbps) as well as copper 1Gig interfaces. The 3750’s weren’t getting it done and I also didn’t want to replace them with another stacking solution. I am not a fan of stackable switches in the data center. I’ll use them all day long in wiring closets feeding phones and workstations, but don’t really like them in the data center. That’s for another discussion though.

Based on my requirements, I needed something matching the Cisco 4900M switch and the ASR 1001 router. Oh, and I needed 3Gbps of throughput(with services) on the router for Metro Ethernet connectivity. Going into this project, I knew that if I chose anyone other than Cisco, I would be looking at implementing OSPF. At least in part, but I was planning on migrating ALL devices off of EIGRP given the chance to do so. While some people might be thinking that was going to be a monumental task, I wasn’t that worried about it. The great thing about EIGRP is that I can summarize at any interface. As long as my IP subnets are zoned properly, this isn’t a problem. It will actually help me migrate everything over in an orderly fashion.

Let’s end the EIGRP vs OSPF discussion here, because this post isn’t supposed to be about EIGRP. It is just one example of proprietary technology. I guess the main concept I am trying to convey here is that I wasn’t too concerned with running EIGRP in my network because I understood enough about it to know how to get rid of it in the least painful way. Don’t get me wrong. I am NOT an expert in any way, shape, or form. However, I have enough of an EIGRP and OSPF background to feel comfortable with both protocols for a project like this. I also have additional networking resources that I can leverage for clarification. There’s co-workers, consultants, Cisco resources in the form of people, documents, and books. I could even use Twitter, as one author of an EIGRP book(@ioshints) happens to hang around there on a regular basis there. Not to mention all the other network rock stars(Sorry Tom. I felt like using that term.) that I follow as well.

When it comes to proprietary, I like to consider the following:

1. Do you know enough to consider the pros and cons of using that particular proprietary technology/protocol?
2. Is there any sort of exhaustive documentation from the vendor regarding that particular proprietary technology/protocol or do they just want you to “trust” them as to how the magic works?
3. Can you see past the silly arguments from competing vendors? For example, is using HSRP between a pair of switches REALLY going to be that much different than using VRRP? As for migration, how fast can you switch between the two?
4. Is that proprietary technology/protocol REALLY going to give you a capability that doesn’t exist in a standard?
5. Does that proprietary technology/protocol ever have to talk to a different vendor’s hardware? Consider something like wireless access points talking to a wireless controller. Would you EVER design a wireless network in which you needed lightweight/hybrid access points from multiple vendors to be joined to a common controller?

Closing Thoughts

Don’t be so quick to dismiss proprietary technology. Standards take some time to ratify, and that’s for a good reason. It’s not JUST a bunch of vendors protecting their own interests while crafting the standard. When there is no standard for something, companies can fill their customer’s needs with proprietary technology or protocols until a standard emerges. Even after it does, there may be some enhancements that weren’t ratified as part of the standard. Or, maybe the company just wanted to keep a competitive edge over the competition. Maybe they really do want to lock you in to their hardware or software. Lest you think that was a jab at Cisco, it wasn’t. There’s not a company out there that doesn’t want you using as much of their gear as possible. Well, not one that I have come across anyway.

Proprietary can be good or bad. It really does depend on the situation, and each one is different. Every company out there that I know of who has some cool technology is using proprietary means to a certain extent, no matter what the marketing slides say. Perhaps there is an exception to that rule. I prefer to remain neutral in these battles. I want to use what gets the job done. If I have done my homework, then I won’t implement something unless I have a reasonable grasp of the technology and understand the implications of using said technology. If you don’t do your homework and get bit, there’s an army of consultants and vendors standing by to fix that problem. For a fee of course. 🙂