QFabric – What excites me!

I was intrigued and excited about the Junipers announcement last week of QFabric. I was vaguely aware of TRILL and Cisco implementation (Fabric Path), but came to the table (so to speak) with no pre-conceptions of what I might expect.

 

SCI-FI – Is this just me?

Is the Q in QFabric taken from sci-fi TV ? I canít help but wonder if the Q in QFabric is taken from Star Trek the Next Generation where Q appeared in the first show of the first season as the omnipotent life in control of everything and can transport anyone, anything anywhere in an instant (Interconnect). There is also a Borg like undertone of all these independent units(Nodes) acting as a single entity, under the control of the Borg Queen (Director). The qfx3500 being the drones (decision engines) which can adapt to Fibre Channel or Ethernet with the correct attachment.

Okay maybe it’s just me.

 

Standout Points for Me

There are two things that really jump out of the announcement.

  • QFabric implements virtual Layer 2 and Layer 3 networks to support multiple tenants each running multi-tier applications
  • Single logical device: Despite its distributed implementation, QFabric acts as a single logical packet switching device.

 

QFabric implements virtual Layer 2 and Layer 3

During the announcement packet forwarding was described in such terms that you make a decision once about the destination for packet, not at each junction on network. If you could build out a datacentre using this QFabric and still have the ability to subdivide the network at layer 3 whilst taking full advantage of the low latency high bandwidth transport across your datacentre, then this is truly exciting.

I have to say I would be very surprised if this is in fact a case because the companies who do divide the network into service zones generally protect these with at least some access control list or perhaps even firewalls. †I just canít see how Juniper could maintain the low latency forwarding while performing these functions across the entire Fabric. I could imaging within a Node (Edge Device) doing inter VLAN routing, but not routing (packet switching ) to a† VLAN on another Node.

 

Single Logical Device

I just hope when Juniper say single logical device, they actually mean the network as a single entity and not just a bunch of independent network devices being viewed through a GUI to make them look like a single entity.

There edge nodes described QFX3500 during announcements seem to be fairly independent devices therefore what changes when they are tied into the QFabric, letís hope they become fully integrated into the fabric.

 

Summary

There were two key points on the Q fabric announcements that got me excited, Layer 3 and Single and Management instance, I just hope the ìsales talkî in the announcement does deliver on a technical level and that my excitement based on this does not turn into disappointment.

 

  • http://www.workingfrommyshed.co.uk Stuart Howlette

    If the QFX3500 starts trying to procreate with the female captain of the ship (company) then yes, it is probably based upon Q.

    Oh god, why do I even think of these things.

  • Brett Mason

    I share your excitement but I maintain a heavy dose of skepticism, and hope that QFabric turns out to be something good and not just hype.

    The technical details (as far as I can find) seem a bit lacking at this stage but from my initial exposure of QFabric a little while ago, it appeared that the backplane of each QFX switch can be shared, or distributed, similair to current stack technology, utilising the QSFP+ ports on the switch. My first thought was that as a packet enters a physical port it will be delivered (using the QFabric magic sauce) across the logical backplane to the physical switch that the physical egress port resides on.

    But that is just speculation on my part based on very light detail. Looking forward to understanding how this technology will work in greater detail.

  • rscheff

    Again, it amazed me contionously, that noone of the current generation of network engineers is familiar with SecureFast. That fulfilled the role TRILL, FabricPath, and QFabric etc are supposed to play completely, but about one decade earlier (with 100M/1G switches at the time).

    You can even check out the specs in this RFC: tools.ietf.org/html/rfc2643 (Version 1.8 had evolved over a couple iterations, and was stable and scalable enough to deploy 500 switch (!) “flat” networks. (Unfortunately, cabletron kicked itself out of business by bad business decisions, and everyone followed cisco L3 everywhere strategy at the time).

    Naturally, current hw is much more capable, and the features supported today are more advanced. Nevertheless, the basic tier-less network design principles and technology was being deployed once before…

    I keep trying to figure out, how the vendors address these simple questions:

    does it address Incast?
    does it address congestion (ie feedback from the network to control the bandwidth of the flows)?
    does it address bufferbloat (answers like “my switch supports 2GB of buffer memory” are fundamentally flawed)?

    Often I get blank stares though… sigh.

    • http://etherealmind.com Greg Ferro

      That’s because Cabletron was a bunch of losers. They spent too much time selling or marketing or just making stuff up instead of quality engineering or competent work. There were so few features in the products that you could list them in a single meeting, and then emphasise them over & over.

      Their MMAC power supplies were are disaster. SS2200 failed every six months. The software was full of bugs, and regularly crashed. The manuals were complete turds.

      The CEO was complete dropkick who deserved everything he got.

      No one misses Cabletron, and the stinking mess they left behind. Good bloody riddance. In the end they had to break the company into four pieces to sell because it was worthless as a single entity. Even then they struggled to get it sold. Says a lot.

      greg

  • FullMesh

    Greg, I’m curious as to why you would want this to be a single device versus independent devices that appear as a single entity? If QFabric is indeed a single brain device it would be one massive single point of failure. I’d be more comfortable with it being a distributed system that is managed as a single device.

    • John McManus

      Hello,

      IMO devices that have their independence in one way or another have the ability to go Rouge or Split Brain and that can really screw your network up.

      To keep my analogy in the world of sci-fi see the episode of StarTrek The Next Generation “I, Borg” where 1 rouge device if altered in such a way could be cataclysmic to the collective.

      BTW: It is John here not Greg :)

      • Andy Kwong

        Sorry, I don’t follow. Split-brain happens when the physically independent elements of a logically fused system has interconnections severed and with one or more of the resulting factions able to reach quorum and continue functioning. One major issue with split brain is when the split brain heals and the multiple factions regroup. If configuration has changed, then which configuration will be the active configuration after they re-merge?

        Surely, the way to prevent this from happening is not to make a centralised system with a single logical entity, but to make it a distributed system with multiple logical entities so that failure and recovery scenarios are deterministic.

  • FullMesh

    Sorry John. Split brain happens to people too…. :)