- Home
- News aggregator
News aggregator
Why I Like Juniper's QFabric (And A Mea Culpa)
Juniper's QFabric, in a nutshell, distributes the traditional chassis switch into discrete components. The top-of-rack (ToR) switches, called QFNodes, are line cards. The QFinterconnect, which the QFNodes are connected to via OM-4 or OM-5 fiber, is the back plane, and the QFdirector(s) are the supervisors (in Cisco parlance), or managers. Each QF node is connected to between two and four QFInterconnects via 40-Gbit links, and there are two QFDirectors that are connected to QFNodes and interconnect via an out-of-band 1-Gbit link.
Greg Ferro, who does network design and consultation for large organizations and also contributes to Network Computing, has written a nice explanation of QFabric and explains some benefits.
Here's why I like it. It's operationally simple. The distributed chassis metaphor is apt and means that multi-switch management is greatly simplified. You can manage up to 128 switches as if they were a single switch, which for all intents and purposes, they are. Think about that for a moment. You don't have to maintain credentials across 128 switches or authentication configuration if you are using RADIUS or some other authentication server.
You don't have to integrate 128 devices into your network management system (NMS), hypervisor management system or other IT systems. Even with scripting or an NMS, making sweeping changes to 128 individual switches in a network is dicey. Granted, you can aggregate multidevice management to simulate a single pane of glass, but that means introducing more servers and management protocols that can get in the way or breakdown. As the number of things you need to manage grows, the simpler your management framework needs to be.
Traffic-wise, you don't have to worry about multiple paths, spanning tree, building N-tiers, or deciding where to set-up routing since QFabric also routes (although Juniper is quick to point out that you likely wouldn't replace your edge or core router with a QFabric, just like you wouldn't replace them with a 1U ToR L2/L3 switch). Any two points in the QFabric is a mere 5 microseconds away. Unless your company requires ultra low latency, anything below 1 millisecond (typically, the granularity that latency is measured and reported in enterprise switches) is probably fine. But, hey, less is better in any case. If you need more capacity at the edge, you can add additional switches fairly cost effectively, as Ferro points out.
Bear in mind that, currently, each QFNode 3500 can be oversubscribed at 3 to 1, based on 48 10-Gbit ports facing the access devices and 4 by 40 gigabit uplink ports facing the QFInterconnects. 480 Gbits inbound going into a 160-Gbit uplink makes 3-to-1. However, engineers at Juniper said the limitation today is the interface speed of the uplink ports. There is no limitation to the QFInterconnect, so speeds can increase in the future provided Juniper ships QFInterconnect cards and QFNodes that support higher capacities.What gets interesting with QFabric is the migration path to and from QFabric, and how QFabric can fit into the data center. In a fit of whiteboard craziness, we mapped out some scenarios. A couple of things come clear:
- To the rest of the network, QFabric is just a L2/L3 switch. It's one bridge in a spanning tree, and outside QFabric, it's just Ethernet. That means you can plug a QFfabric into the rest of your network and it will be loop-free.
- All the rest of your L2/L3 network will behave just fine, and you can run any other network equipment, like a Cisco Nexus side-by-side.
- Any requirements such as reaching hosts defined by routes on an external router or passing traffic through a load balancer mean traffic many have to pass out and back in to QFabric.
If you have already invested in Juniper's QF 3500s, the EX line is not supported and you want to migrate to QFabric, you need a QFInterconnect and a QFDirector, although Juniper recommends pairs for redundancy. You can cable to your existing QF 3500s and they become part of the Qfabric. Take them out of the QFabric, and they become l2/L3 switches. Pretty nice investment protection.
I like it. QFabric is a fairly simple design—simple is good. No need to worry about mutlipath Ethernet protocols like TRILL, SPB, LAG or MLAG. It only scales to 6,144 10-Gbit ports with over subscription, 2,048 if you want non-blocking (that's 16 10-Gbit ports per QFNode). If you dual-home your servers, that only 3,072 servers. I say only tongue in cheek. That's a lot of servers for most organizations, and I will go out on a limb and assume that if you're looking at that kind of scale, it's either a special-purpose computing center or a hosting or cloud provider.
The other elephant in the room is cost. That's a topic I will take up later, as well as digging a little deeper into the design scaling issues. Of course, there are a number of other things to consider, like distance limitations of the OM-4 cable, cable layout and designing the L2/L3 network within QFabric. But if you are looking at upgrading from a 1-Gbit to a 10-Gbit network and you want to take advantage of the new features that network fabrics such as Brocade's VCS, Cisco's Fabricpath and Juniper's QFabric offer, it's worth a long hard look. And I bet the proprietary features will be less important the deeper you look.
Disclosure. I traveled to Sunnyvale on my company's dime. Juniper fed me a hamburger, chips and a soda, and gave me a pen.
Prepare The Mobile Ship For Ludicrous Speed!
To read the various analyses of what the International Telecommunications Union (ITU) has recently approved in its IMT-Advanced announcement is to be schooled on what 3G and 4G really are, and are not, as well as to get a look at where mobile wireless is heading. And where it's heading is impressive.
Where a present-day good 3G connection will yield a respectable few megabits-per-second connectivity (if you’re not moving), IMT-Advanced will make 3G feel like a dial-up modem. Current LTE networks that claim 4G-ness measure and market their speeds in the double-digit megabits per second, but there is a lot of variability across carriers and conditions required to get to top speeds.
Regardless of the current marketing campaigns and the decent speeds that the carriers are giving us on their "4G" networks, the ITU says that we have yet to see true 4G networks by its technical definition. To really be 4G, a network must deliver speeds of 100 Mbps when in motion at vehicle speeds and 1 Gbps (yes, gig speeds from mobile networks) when not moving. Marketing being what it is, nothing we have in the United States from LTE or WiMax comes close to these lofty requirements, despite of all of the 4G hype taking root. So far, 4G isn't really 4G. But when we get there, it will be ludicrous.
So what did the ITU do for the mobile network space during its meeting in Switzerland that commands so much interest? The communications governing body approved two technologies--LTE-Advanced and WiMax 2--as the path forward to mind-blowing mobile networks under the heading of IMT-Advanced. Now that the declaration has been made, development and manufacturing can proceed. Though it will likely take a couple-few years for IMT-Advanced network and handset build-out, it stands to reason that IMT-Advanced will stay on people's minds as they contemplate their future mobile strategies.
All guesses about how IMT-Advanced will truly impact the mobile network space are on the table. As more individuals and businesses alike make mobile data a priority, carriers today are using strategies like data plan terms and WiFi offload to prevent network saturation, which also gets interesting through the lens of IMT-Advanced. Though network speed is easy to get excited about, you can’t get blazingly fast without modulation and antenna techniques that make for better cells and higher capacity for everyone, even legacy non-IMT–Advanced users. Higher speeds and better cells mean better general traffic-handling capability, which has to have some impact on how service plans will be structured.
There is little doubt that IMT-Advanced will certainly come to be recognized as a disruptive technology and will likely challenge notions of traditional networking in many areas yet to see broadband. Testing with early IMT-Advanced components is already well under way in Europe and China, and Internet videos showing beta efforts and results for IMT-Advanced are simply captivating if you follow mobile network development.
Gigabit mobile broadband? Even Dark Helmet would approve.
At the time this was written, I was not being paid by any vendors or organizations mentioned.
IBM And NEC Leverage OpenFlow For High-Performance Networking
There are a number of myths surrounding OpenFlow, including that there is a delay on the first packet of a flow to perform a lookup and that the controller is a single point of failure. Both are easily addressed through sound management practices. In fact, the upsides of using OpenFlow--such as simplified traffic management, policy-based networking that creates paths through the network based on higher-level decisions than the destination address, and software-defined networking where there is tight integration between applications and network configuration--can far outweigh any downsides. The IBM and NEC announcement describes how enterprises are overcoming these obstacles in OpenFlow on their production networks
One customer of the combined IBM and NEC products is Selerity which provides financial information from primary sources to their subscribers. Their service-level commitments are on the order of microseconds, required so that all subscribers receive the same information at the same time. In addition, Selerity has to manage subscription entitlements to its customers to ensure they are getting what they paid for. Selerity's entitlement application needs to make those decisions and dispatch the data in near real time. The challenge Selerity faces in meeting all of those competing goals is in maintaining low latency and traffic separation.
Selerity satisfied those requirements using a convoluted set of VLANs and high-end firewalls to forward traffic to the proper locations, or by using an application-level process to make the forwarding decisions. In either case, the solution was complex, inflexible and expensive. Adding a new subscription to a customer meant making a number of changes to networking equipment, which took time and was error-prone.
Using OpenFlow on NEC's Programmable Flow Controller, Selerity was able to move the forwarding decision off the servers and firewall/switch layer into an OpenFlow-controlled network. Using flow rules defined once on the Programmable Flow Controller, the UDP packets coming from Selerity's servers are rewritten, added to a multicast group and forwarded to the destination ports corresponding with individual customers in a few micro-seconds. Selerity ensures that the correct data goes only to intended customers and that all of the customers receive the data at the same time. Selerity was also able to easily add more redundancy to its delivery network since an OpenFlow network isn't hobbled by Ethernet constraints like having a loop-free network.
Selerity's application and SLA requirements are unique to the financial industry, but many enterprises have similar demands that could be addressed using an OpenFlow-managed network.
IBM and NEC also described unnamed customers using OpenFlow to solve common issues such as forwarding network traffic to multiple analysis devices and forwarding traffic to load balancers. Companies like Anue Systems, Gigamon and NetOptics offer in-line network taps that can combine many network connections into a single output or split a single input into many outputs, either replicating all frames across all output ports or slicing the output stream based on data in the frame like addresses and port numbers. These taps work well but are expensive and require that they sit in-line with the monitored link. The security customer connected taps and switch span ports to an IBM G8264 OpenFlow switch, ran the traffic though a deep packet inspection engine and then forwarded the flows to one or more analysis tools. The monitoring is much more flexible than a fixed tap.
More vendors are hopping on the OpenFlow bandwagon, including networking giants Cisco and HP. Juniper Networks added OpenFlow to its Junos SDK in 2011, while OpenFlow controller vendor Big Switch introduced an open source OpenFlow controller early this year. We will continue to see interesting use cases of OpenFlow in production environments.
Learn more about OpenFlow vs. Traditional Networks by subscribing to Network Computing Pro Reports (free, registration required).