Openflow, Merchant Silicon, and the end of the reign of King John.

Early this morning, I finally had an opportunity to listen to the latest episode of Packet Pushers Podcast.

In the podcast, the guys discuss Openflow and the impact it could have on the networking industry. One of the points mentioned in the podcast was that Cisco is apparently using merchant silicon in the latest 10GB Nexus switch, the 3000. I was shocked when I heard this, and had to do a little research to verify. Sure enough, it seems that Cisco’s latest Nexus switch is built on Broadcom chipsets. Wow.

Let me say that again…Wow. To recap, here is my favorite Cisco blog post regarding Cisco and merchant silicon by Douglas Gourlay, an ex-Cisco Senior Manager of Product Marketing.

To quote the post:

Do major automobile manufacturers outsource engine design and development to other firms? Of course not, they design and build their engines. Do manufacturers of more consumer goods like lawn mowers outsource their engines? Absolutely, they go to specialized engine manufacturers because the core value of what they offer is either a certain price point, or the value is not tied to the engine. So the question then – is do you want to ride to work or school in a car, or on a lawnmower?

Ok, so if Cisco is using merchant silicon in their Nexus line, it seems to me that the course adjustment that Big John emailed his employees about last week wasn’t the beginning. Maybe John was trying to answer rumors that had already started within Cisco’s ranks. Change was in the air, questions were being asked, and it all had to be addressed.

What would cause such a shift in Cisco? Is it possible that Cisco already realizes that being faster is no longer relevant in an age of Openflow, TRILL, IPV6, etc. etc.? There is no doubt that Cisco has felt the pressure from HP, Juniper, and other vendors. In fact, my current role is in a company that made that jump from Cisco to HP and Juniper when Cisco tried to sell Nexus 7K’s when 4507’s  or 6509’s would have been the better solution. Cisco didn’t just lose a customer here, Cisco made enemies. (I get scowls when I mention Cisco.)

Is it possible that Cisco realizes that the days of huge profit margins on every device it sells are coming to a close? Is it possible that maybe, just maybe, Cisco realizes that it’s not the only game in town?

For years, people bought Cisco for the additional features that Cisco offered. PAGP, ISL, EIGRP, LWAPP were all answers to problems that no one else had addressed. They were good answers at the time, and all led the industry standards by a couple of years. Now, the alternatives 802.1Q, LACP, OSPF, and CAPWAP have replaced those proprietary Cisco protocols. Looking at the environment now, I don’t see any areas where Cisco has a unique answer. Either the networking community has a solution (Openflow, TRILL), or each vendor has their own unique solution to the same problem (Qfabric, Unified Fabric).

Let’s look ahead 3 years. If an engineer has the option of buying products from Cisco which cost a lot more, and must be managed individually, or buying products from a range of vendors that all must compete in a cost effective manner, and all of which support unified management through Openflow, and all of which have the same features, which would he choose?

Two closing thoughts:

Apple is trying to teach the tech world a lesson: specs alone doesn’t make a better product. For Cisco to compete, they have to focus on features that answer real world problems, not imaginary scenarios. IPv6 and TRILL vs. Who really uses an ASA for deep packet inspection on a regular basis?

Cisco is a very big ship, and it will take a long time to turn. Watching from the shore, we have only begun to realize that it is turning, and have no idea where the new heading points.

6 thoughts on “Openflow, Merchant Silicon, and the end of the reign of King John.

  1. You should also notice that Doug Gourlay works for Arista Networks who makes serious ethernet gear out of merchant silicon exclusively and seem to be making serious sales into financial institutions.

    And remember that Uncle John made a big thing about proprietary silicon at Cisco Live in London.

    Some two faced strategy going on.

  2. Jonathan:

    Great post.

    Yes, its true that the N3K uses merchant silicon, but I would not read too much into that. At the end of the day, we still believe in having “no technology religion”–something my friend Greg refers to as “two faced” above :). We believe in our own ASICs because we feel its is usually be best path to deliver what our customers are asking for but are willing to look at other options, where it makes sense. I recently posted an interview with Soni Jiandani (VP at the BU that created the N3K) on the topic:

    So, I believe we continue the process of leading industry standards are you note. FabricPath > TRILL, VN-Link > 802.1Qbh and LISP are recent examples of this. Looking ahead, we also look to embrace OpenFlow–see my post today on the topic: –because we see the value of it to our customers.

    Finally, to answer your question about which option a network engineer will chose. I have been doing the networking thing since the days of VAXes, and some things have stayed constant over the decades. I think the answer is that the engineer will choose the solution that works best and meets his/her need. Perhaps OpenFlow, perhaps not–one of the things we are looking to do is giving the option to not have to choose.


    Omar (@omarsultan)

    • Hey Omar,

      Thanks for adding to the conversation.

      A question for you. How is Cisco contributing to TRILL or 802.1Qat? FabricPath may be a better solution, but it will require the use of Cisco only hardware, correct? As many engineers know, a Cisco only network rarely happens.

      • So, off the top of my had, I cannot comment on 802.1Qat–not something on my radar.

        As far a TRILL vs FabricPath, we are also quite active on the TRILL working group. From an implementation perspective, we will support both FP and TRILL and customers can choose which option they want–features or standards compliance–much like folks can choose between HSRP and VRRP.

        The TRILL interoperability question makes me smile a bit, because there is currently a shortage of folks to interoperate with. Brocade is the only other company with TRILL, but they are using FSPF instead of IS-IS. But, regardless, we’ll have TRILL support once the standard is fully baked.



  3. Thanks Omar for the info.

    I agree with you regarding the lack of support for TRILL from other vendors, and also agree that you can’t really call what Brocade is doing “TRILL”. However, when I buy a switch, I know that it will be used for 4-5 years. Therefore I worry less about vendor support for TRILL right now, and more about who will be supporting it, and in what way, 1 year from now.

    Again, thanks for the input.

  4. Pingback: Texas Hold’em and the IETF – Did Brocade bet against TRILL? « subnetwork

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s