Junos Fusion: the First Steps (updated)

I was really excited when Juniper announced Junos Fusion. I hoped for QFabric Done Right, but after watching the NFD10 video describing the architecture, I was disappointed: they reinvented Fabric Extenders.

The blog post was slightly updated on November 14th 2015 based on feedback received from Juniper engineers.

What they promised

Here are a few highlights I extracted from the video, and double-checked with the Junos Fusion datasheet:

  • Junos Fusion is a leaf-and-spine architecture. They call the leaf switches satellite devices and the spine switches aggregation devices.
  • The aggregation devices could be MX routers or QFX10K or EX9200 data center switches;
  • Architecture is limited to two aggregation devices with independent control- and management planes (identical to Nexus OS with VPC);
  • Satellite devices are completely dumb; the control plane is run in the spines;
  • Packet forwarding is done through the aggregation devices (same as Cisco’s fabric extenders) apart from some local switching (not available when you use EX9200 as the aggregation device);
  • The maximum number of leafs is 128.

From the high level, Junos Fusion looks exactly like Nexus OS with vPC-connected fabric extenders (a technology that is more than half a decade old) – a real disappointment coming from a company that developed QFabric and Virtual Chassis Fabric. On the other hand, ONF must be proud - Juniper implemented a picture-perfect ONF-promoted SDN architecture.

For more details on how fabric extenders and other fabric architectures work, watch the Data Center Fabrics webinar.

Separating features from futures

I wanted to know more, so I started reading the Junos Fusion documentation, and discovered that both the NFD10 video (recorded over 2 months ago) and the Junos Fusion datasheet suffer from a severe case of marketitis.

Marketitis: indiscriminate and/or excessive use of marketing grammar.

As of November 2015 Junos Fusion shipping with Junos 14.2 supports:

  • MX-series routers as aggregation devices (no support for QFX10K or EX9200 yet);
  • a single aggregation device, which is obviously a single point of failure;
  • packet switching through the aggregation device (no local packet switching);
  • maximum of 64 satellite devices.

I wanted to know how well the system scales, but couldn’t find any information on the other configuration maximums (the area where Cisco is doing a fantastic job with the Nexus OS), there was only a vague mention of “approximately 1000 aggregated Ethernet interfaces” in the release notes.

But Wait, There’s More!

As expected, someone quickly pointed out that I lack the understanding of the bigger vision and great things coming in the future. You know I believe in features not futures, but let’s go through the list nonetheless:

I’ll cover the then-shipping feature of Junos Fusion in an update session of Data Center Fabrics webinar in May 2016. You can buy the recording now and register for the live session free-of-charge when it’s scheduled.

Hardware/software disaggregation. This one is actually cool (but keep in mind that they still have to ship it) – it would allow you to buy QFX5100 hardware, use it as a fabric extender, and upgrade it to full-blown Junos device when needed.

I would love to hope that this also solves sparing/maintenance problems, but I have yet to see a networking vendor that understands the need for simple licensing scheme.

Unified architecture for service provider edge, data center, and campus. This sounds very similar to “single Junos image” message I’ve been hearing for the last few years. Anyone who had to deal with the various Junos images (for MX, EX, QFX, QFabric and now Junos Fusion series) knows that this idea looks great in PowerPoint but doesn’t work as well in practice. Let’s wait and see…

Easy software upgrades. Checked with a few colleagues (thank you, Ethan Banks, Jeremy Filliben and Chris Marget), and all of them remember having the same functionality on Cisco FEX a long time ago. Sounds like business-as-usual.

Supports single-homed as well as dual-homed topologies. The engineer that sent me this one either used marketing grammar or wanted to say “the hardware supports it, but we’re not shipping the software yet.”

Extends rich features and high logical scale down to the satellite devices. Sounds really great, but means nothing. Every well-designed fabric extender system implements all functionality on all ports (unless there’s an ASIC problem due to multiple encapsulations) and is limited by the capacity of the central device (and yes, I agree that QFX10K makes a better central device than Nexus 5000 ;).

LAG across multiple satellites. Really? This is a selling point in 2015?

Automatic LAG and VLAN discover for hosts. Automatic LAG discovery would be a first (or maybe I’m missing something), automatic VLAN discovery is done in one form or another by almost all vendors. Let’s see how exactly this feature works when Juniper publishes the configuration guides.

Junos Fusion is enabled on per-port basis on the aggregation device, which means you can run L2 or L3 switching on other ports. Yet again, sounds like a great selling point, but Cisco has been doing the same since they shipped FEX years ago.


  1. Here - http://packetpushers.net/podcast/podcasts/show-249-juniper-qfx-dc-fabrics-automation-sponsored/
    Juniper sad satellite devices SUPPORT local switching.

    and because you have to change the JunOS to Yocto Linux on the satellite devices it is not real PnP. )

    and what about troubleshooting on sattelite? - different OS and tools. FEX runs NXOS.

    BTW QFX5100 is about $40K ))) 40K for a dumb device....
    1. Of course they support local switching. They just haven't implemented it yet.
  2. A great man I met once mentioned something to me about the reinvention wheel turning and turning and turning...
  3. More like Fusion is FEX done right. OP left out that you can run different software versions between all nodes and doesn't require a huge maintenance window to upgrade the entire fabric. Fusion also supports automatic LACP creation for servers and auto-senses VLANs on server-facing trunks.
    1. what do mean "auto-senses VLANs on server-facing trunks"? proof link, please. and do we really need it?
  4. What a stupid old technology :)
  5. met some guys from Arista and they keep telling me how bad the QFX is...
    Hope can get some comparison between Arista and Juniper DC switch?
Add comment