Last weekend I was interviewing a potential new staff member for a job we have going, and we started discussing various vendors strengths and weaknesses. I put forward that I would question buying hardware from a vendor who just copies everyone else and doesn’t innovate on their own undertaking.

The response from one of the people present was that you can buy innovation (eg Cisco buying back Nuova, HP buying 3Com and thus H3C). I didn’t respond at first to this statement because I wasn’t really sure how I felt. After some thought I have decided how I feel.

You cannot buy innovation, you can only buy innovative product lines. Innovation is an ongoing process

Anybody with a hefty wallet can buy a company who is making some new products and bring them into your own portfolio, but this is only buying an innovative product line. To be truly innovative is a corporate culture kind of thing. If your company does not believe in innovation as a way of life then purchasing any new products is only going to move you in very small baby steps – steps that will possibly become dead-ends without appropriate investment in research and development.

Corporate Culture can be changed or learned. Various companies throughout corporate history have brought in new management who have been able to change the core practices. Sometimes this can be through grass-roots change, or from a visionary new C-Level exec, but without fail it has required key changes be made to how the company does business and what values are important to them.

I’ve said it before, and I will say it again if you are just doing what everyone else is doing then why should I buy from you?

If you are waiting for the standards instead of innovating new ways to do things today, then I guess I will come back to you next refresh cycle – cos you cannot meet my needs today.

Maybe this is a naive view, and as always Im happy for those wiser than me to “show me the light”

A couple of weeks back, when we recorded Episode 33 of Packet Pushers Podcast, one of the items we had on the list of topics to discuss was that of multi-vendor networks and the recent Gartner report on the topic.

Due to various reasons this topic was taken off the list, but I still had a few thoughts on the topic so I decided to write this blog post to discuss some of them.

The Gartner Report

In late 2010 I attended a HP Australia executive briefing and breakfast in Sydney. The keynote speaker at this event was Mark Fabbi, and I had the honour (luck?) of sitting at the same table as him during the event. Mr Fabbi was the author of a paper called “Debunking the Myth of the Single Vendor Network”. The presentation was aimed at C-level executives along with the various Magic Quadrants that we Network Engineers love to laminate and stick to the walls of our cubicles!

Whilst telling us (well me at least) something we already knew, he laid out in a fashion suitable for presentation to upper management for discussion and approval to add addition vendors to your network.

Suggestions have been made that vendors with deeper pockets have been pushing the agenda for these reports, but I think that at the end of the day there are compelling reasons not to have vendor lock-in.

The right tool for the right job

At eintellego we specialise in building multi-vendor networks. I like to call this the “Chasing Amy School of Network Design”. Anyone who has seen that movie should know what I am referring to, but basically why should I limit my choice of devices to one particular vendor. If there is a better tool to complete the task I am trying to do then I will not put blinders on because it does not come from my vendor of choice.

By way of an example, for quite a few years we had been selling and supporting the Cisco PIX and ASA platforms for our customers because we felt they offered the best overall hardware firewall solution for our customers. Other vendors had products that were competitive but none of them were compelling enough for us to move away from the ASA. Then in mid-2009 in a space of maybe 3 weeks I had two separate customers ask me on my opinion of the Juniper SRX platform. I had previously looked at Juniper equipment and was quite impressed with the Junos Operating System, but when it came to firewalls I was not impressed with the ScreenOS options. I could have easily just dismissed the new product because it wasn’t from Vendor X who I was used to buying from, but after several recommendations from colleagues as well as requests from customers I decided to take a look. And I am very glad I did!

What I found was a product that met several of the short comings I had with the ASA platform (dynamic routing with redundancy etc), was based on the Junos Operating System, and had quite an impressive throughput and capabilities for the price. Today at eintellego we will recommend and sell SRX solutions to our customers before an ASA solution because we feel that in 2011 it is truly a better option.

Multi-Vendor for the sake of Multi-Vendor

One point I should make clear is that I do not advocate multi-vendor when it is not required. For a long time the Security Industry Best Practice promoted the idea of separate firewalls from separate vendors. While there are sensible reasons behind this approach (vulnerability in one platform will be safe on another), often during the implementation one of the two devices was treated worse than the other. Maybe installing the second box was to achieve a “tick in the box” for some industry security certification, or maybe a choice by a previous admin who no longer is there to champion the cause for the device, but sometimes one of these boxes was modified and updated far less than the other.

Why should we make our lives complicated for ourselves? Why would I force myself to use, say, an ASR and an MX series router as my border routers purely to meet the requirement of multivendor. Valid reasons may exist for this solution, buy “multi-vendor” is not that reason.

I need to learn another System?

I often hear from engineers that they do not want to learn another operating system. I usually laugh at this point at tell them their future doesn’t look that bright. Even within a single vendor you have several new operating systems now, an depending on the direction your network takes you, you may find yourself working with IOS, NX-OS, IOS-XR and/or possibly IOS-XE.

When I train my staff in networking concepts, I try to re-enforce the theory behind the solution or protocol more than the commands required to complete the solution. If you understand why Spanning Tree or OSPF behave a certain way or respond to an event in the network, it does not matter what operating system you are on, all you need to do is work out where to find those options. Knowing the right commands is only 10% of the job!

As an example, we recently rolled out 500+ HP E-series switches for a customer. Prior to this project my experience with the (former) ProCurve range was limited mostly to simple Layer 2 designs with a little bit of AAA and SNMP thrown in. After about an hour of playing on the device, I was already comfortable with the CLI and ready to start “translating” the config I was after into the correct dialect.

ProCurve CLI is very similar to IOS you say? Well how about Junos then? I think we can all agree that Junos is significantly different to many of the other competitors, but it only took me a day or two in the lab before I was comfortable enough to deploy some of these in a semi-production network to start getting some real world experience.

If you’re working in the network field DO NOT be afraid of new tech. That doesn’t matter if it from the same vendor or a new vendor.

My Vendor is the only one who does X?

Personally I think this one falls under the same heading of “The right tool for the right job”, but sometimes people have engineered themselves into a corner and decide to continue implementing the same solutions because to change or re-design is “too hard”.

Maybe you deployed a proprietary protocol and now you are locked into that vendor. In a previous post I discussed how I was not opposed to proprietary solutions, particularly when they are the only option for a solution. Does this mean that you should stick with this solution when new alternatives exist? The same driving force behind the implementation of the proprietary solution should drive the review of new alternatives – The right tool for the right job!

I understand that certain environments have strict design/innovation schedules, and that once a network is built it is extremely hard to get changes made, but we should always be looking for the best way to do our jobs and to design our networks. Don’t be designing networks based on the text-book from 10 years ago!

Wrap up

Multi-Vendor is not scary or hard, as long as you do it for the right reasons.

Feel free to share your comments, flames or multi-vendor nightmares 🙂

Driving home the other night I was listening to the latest episode of the podcast “Coffee with Thomas”. This episode had our host, Thomas Jones, interviewing Steve Chambers of ViewYonder (and also a history of great vendors!). During the interview, Steve made the following comment:

It amazes me that people criticise Cisco for not be standardised on things that are brand new, as if the standards bodies are innovators. That is not their job. They follow up after things have been invented.

This statement took me back at first, and I was about to write it off as protecting your own team, but the further I drove (I have a very long commute – about 100km each way) the more I thought about this statement and the evidence – both historical and current.

As network engineers we often love to get into religious arguments about which technology is better, and almost invariably a comparison will be made between a vendor proprietary solution and an open standards solution. Whether that is EIGRP vs OSPF, HSRP vs VRRP, or FabricPath vs TRILL they all seem to come down to a core need:

I have a need right now, and the standards bodies will take years to agree. Do I innovate and press forward with what I can do now, or do I wait?

When HSRP was introduced the market had a need for redundancy of Layer 3 gateway devices. A vendor saw a problem, thought of a solution, and implemented the solution without waiting for the rest of the market to catch up. And I firmly believe that this is in the best interest of the market. Once HSRP was recognised as a viable solution other vendors and standards bodies worked on bringing to market an industry standard protocol. Admittedly Cisco could have done many things to improve HSRP (proper load balancing is just one idea, though they brought similar options into GLBP), but they brought a solution to market when it was needed.

Zoom forward to today. The market today is seeing a push towards large virtualised domains (dare I say “Cloud”?), and as a side effect of this we (currently) need to implement these solutions using large Layer 2 domains. As has been the history of Layer 2 this comes with the “nightmares of spanning tree”, that seems to wake up so many admins at 2am in the morning in a cold sweat.

A problem exists now, and a solution is needed now. As is usual with standards bodies there is much debate as to how to move forward as everyone has their own opinion. In fact, which standards body do we look to? IETF with TRILL or IEEE with SPB? Life is slow in the land of standards, and while the boffins are battling it out there is a market place looking to roll out a solution to meet a need in there own environment.

So who is tackling these problems today? Well, like in the past, some vendors are claiming “There is no standard to move forward with”, or “We will support it when there is a standard”. This is not innovation – this is doing the same as everyone else. Im honestly not sure how I feel about a tech company who will only do exactly what everyone else is doing. Maybe in the sub-$50 SMB switch and router market sure – but not somebody I have to justify budgets and ROI and staking part of my career on!

Cisco’s FabricPath and OTV solutions may not be standards compliant. They do appear to have taken several of the nice features of the proposed standards and added some other features that will improve the Nexus platform overall, but they are not backwards (forwards?) compatible with either of the proposed standards.

Is this a bad thing? They have gone to market with a solution to a problem we have now. From the accounts I have heard the technology appears to do what it promised (even if it was behind schedule). With the standards “almost ratified” should they have waited so that their competitors could go to market with a solution at the same time?

The main thing I would like to hear from Cisco is that they will also support the standards compliant version when ever it finally gets ratified.

Im sitting in a hotel room in Hong Kong right now, with a whole city to explore so I will leave it here for now.

As always, thoughts, flames and comments welcome.

I recently gave a presentation to the New Zealand Network Operators Group (NZNOG) 2011 conference on “Data Centre 3.0”. During my research over the last 8 months coupled with the fact checking I had been following up during the creation of the slides, I kept asking myself:

“Would we need all these protocols if we, as an industry, had made better technology implementation decisions?”

I understand the background and requirements for some of the different technology proposals, particularly Layer 2 Multi-path and the various Data Centre Bridging (DCB) QoS standards, but I cant help but feel that we are trying to bring features of the higher layer protocols down into Layer 2.

Back when I started studying networking (probably around mid 2001 when I first obtained my CCNA), the CCNA curriculum was quite clear on the OSI layer and how each layer had a very particular purpose, with clear functional definitions: