& cplSiteName &

SDN Middleman: A Second Look at Juniper's MetaFabric

Dan O'Shea
11/13/2013
50%
50%

It's been a heady few weeks of vendor announcements outlining visions for next-generation datacenter infrastructure, with Cisco Systems' long-awaited Insieme announcement garnering much of the attention.

Now, with Cisco's strategy finally part of the public record, it's a good time to take a closer look at another approach that slipped by with less fanfare in the days leading up to the big Cisco announcement (See Cisco's ACI Gets Physical With SDN and Cisco Asks the Killer SDN Question.)

Juniper Networks Inc. (NYSE: JNPR) announced its new SDN-ready MetaFabric for the datacenter and distributed datacenter networks at the end of October. It was Juniper's second big SDN announcement in recent months after the launch of its Contrail SDN controller, which included the announcement that, despite having its own controller, Juniper also would provide an open-source version of Contrail and would be willing to contribute its code to standardization efforts, such as OpenDaylight . (See Juniper Unveils Datacenter MetaFabric and Juniper Opens SDN, Clouds OpenDaylight.)

For industry observers looking for key differences between Cisco's Application-Centric Infrastructure strategy and Juniper's MetaFabric strategy, that perceived openness is it in a nutshell: Cisco Systems Inc. (Nasdaq: CSCO) is offering the ability to use parts of ACI with standardized elements and gear from other vendors, but saying an all-Cisco ACI is optimum, while Juniper says it's aiming for a completely open architecture and, what's more, says it can prove it.

"The Contrail controller will work with Cisco hardware, but Cisco's controller doesn't work with anyone else's," claims Mike Marcellin, senior vice president of strategy and marketing at Juniper's Platform Systems Division. Marcellin also points out that Juniper is using standard Ethernet VPN VLAN extensions in its MX Series 3D router, while routers from its rival use Cisco's own Open Transport Virtualization protocol.

SDN translation
The MX routers also have a Universal SDN Gateway capability that allows them to act as translators between different makes of SDN controllers. That capability could be crucial for customers that implement SDN in different datacenters at different times using different vendors, but then decide later that they want to connect their SDN islands.

Marcellin emphasizes that Juniper is trying to let customers build out SDN architectures without worrying about being locked into one vendor for everything. Of course, as the market leader for datacenter switching and routing infrastructure, Cisco can attempt to force the market to do things its way, while Juniper, and any other company for that matter, must be more accommodating.

MetaFabric does have a few similarities to Cisco's approach. Like Cisco, Juniper does not offer a completely virtualized solution in the mode of some SDN vendors, since it does utilize hardware -- Juniper's new QFX 5100 top-of-rack 10 Gbit/s/40 Gbit/s Ethernet switch family. Though again, Marcellin stresses the switches can be used in any datacenter fabric.

Also like Cisco, Juniper is leveraging an existing family of routers, in the form of its MX Series, though Marcellin claims enhancements such as the Universal SDN Gateway address interconnection of multiple clouds in a way few others are discussing. Both Juniper and Cisco also understand the need to support leading hypervisors, namely VMware's EXSI.

Ultimately, Juniper, like its rival, is attempting to revitalize moribund network application provisioning.

Marcellin told Light Reading this week:

You can spin up a virtualized machine in minutes. You can spin up virtualized storage in minutes. The time it takes to deploy an application on the network is less than ideal. Typically if you want to a new application on the network, you need to first open up a trouble ticket because maybe your application guys don't talk to your network guys. You may have to get new equipment, so you're talking weeks, or in the service provider space maybe a year. Ten years ago we just accepted the fact it took forever to do any of this stuff, but now everything else has evolved significantly, and the network hasn't. What happens then is that your network is not extensible. It can't grow as you get new users or as new applications come in. It's difficult to continue to use the network in the same way.

In Cisco's case, some critics have contended that revitalizing application provisioning with a hardware-centric model is an attempt to distract customers from the broader trend of datacenter virtualization.

Not all virtualized
Juniper is likely no more eager to virtualize the datacenter than Cisco. Marcellin describes the complex nature of datacenters as environments where customers have an on-premises datacenter, but also may have some assets in a managed cloud provider or hosted services provider, and other applications sitting in clouds or as part of an infrastructure-as-a-service they get from a cloud provider.

"Within all that you've got both virtualized resources and physical resources you need to use, and you need to have a simple, smart and open way of getting at all of that," he says. This is not so far off from some of the things Cisco said in its Insieme announcement, but Juniper, like any contender, is intent on offering a different world-view than the incumbent.

"With Cisco's announcement, battle lines were drawn between Cisco's datacenter model and VMware's," Marcellin says. "An all-hardware-centric model is not right because it leaves a lot of potential agility benefits on the table. But, neither is an all-virtualized, abstracted model right. Where we're sitting is a sane middle ground. There are some attributes that can be done in hardware that are absolutely required, but we want to have all the right approaches, whether someone uses Contrail or [VMware's] NSX."

— Dan O'Shea, Managing Editor, Light Reading

(6)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
dwx
50%
50%
dwx,
User Rank: Light Sabre
11/14/2013 | 2:00:37 PM
Re: VXLAN, not OTV
Right, Cisco feels their hardware overlay based on VXLAN is better than using an implementation within a vSwitch.   This even after they spent the time and resources to add VXLAN gateway support to the Nexus 1000V vSwitch...

The new version called the AVS "Application Virtual Switch" punts all of this to the upstream Nexus 9000 switch if it has to leave the vSwitch.  
rogerfortier
50%
50%
rogerfortier,
User Rank: Light Beer
11/14/2013 | 1:42:23 PM
Re: VXLAN, not OTV
I work at VMware and am pretty sure (almost positive) that it's VXLAN.  This was somethng that was being pointed out pretty regularly whenever Cisco talked about the problems or challenges with overlays. It was noted that at the heart of ACI was actually an overlay using VXLAN. -- Roger Fortier
DOShea
50%
50%
DOShea,
User Rank: Blogger
11/13/2013 | 7:37:35 PM
Re: VXLAN, not OTV
My impression from an interview with Cisco was that they are nearly the same thing, though I get that doesn't mean they are exactly the same. I thought ACI was using OTV in any case, so let me check again with Cisco and make sure there needs to be correction here. Thanks for the close read, and helping us make sure we get the details right.

Re: QFabric, another good point worth mentioning. My view is that Juniper has a lot to protect with the sudden arrival of SDN, just like Cisco.
dwx
50%
50%
dwx,
User Rank: Light Sabre
11/13/2013 | 6:48:08 PM
Re: VXLAN, not OTV
According to the IETF drafts covering the two different encapsulations, they are identical except OTV uses an "Overlay" field for control plane packets.  Same 8 byte shim. 

The current Nexus 7K OTV doesn't use that encapsulation, it uses GRE with a 4-byte OTV shim, so there is a bit of difference between the two.  
schlettie
50%
50%
schlettie,
User Rank: Lightning
11/13/2013 | 6:22:30 PM
Re: VXLAN, not OTV
The VXLAN and OTV encapsulations are very similar.
dwx
50%
50%
dwx,
User Rank: Light Sabre
11/13/2013 | 6:05:28 PM
VXLAN, not OTV
According to the fabric architecture doc on Cisco's website and other sources I've seen the fabric uses VXLAN, not OTV.   The chipsets in the 9300/9700 switches is the Trident-2 with hardware support for VXLAN.  

To quote the document: 

"The Cisco ACI fabric (Figure 1) is a highly scalable, multipath, high-performance leaf-and-spine architecture (bipartite graph) which provides a Virtual Extensible LAN (VXLAN) overlay for the tenant space" 

Cisco and Juniper both have existing proprietary fabrics in QFabric and Fabricpath, so Juniper doesn't really have much of a leg to stand on with that one.  
Featured Video
Flash Poll
Upcoming Live Events
April 8, 2019, Las Vegas, Nevada
May 6, 2019, Denver, Colorado
May 6-8, 2019, Denver, Colorado
September 17-19, 2019, Dallas, Texas
October 1, 2019, New Orleans, Louisiana
October 2-22, 2019, Los Angeles, CA
October 10, 2019, New York, New York
November 5, 2019, London, England
November 7, 2019, London, UK
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
All Upcoming Live Events
Partner Perspectives - content from our sponsors
Huawei Shows 5G in Action at MWC
By Ken Wieland, for Huawei
Huawei Heats Up Microwave for 5G Backhaul
By Ken Wieland, for Huawei
Huawei Services Bring the Best 5G Into Reality
By Steven Wu, President of Consulting & Service Solution Sales Dept., Carrier BG, Huawei
All Partner Perspectives