
- Home
- News aggregator
- Categories
- Security News
Security News
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).
HP and Cisco Take Different Paths To SDN
There, Cisco chief technology officer Padmasree Warrior reportedly outlined Cisco's SDN strategy, but did not mention OpenFlow as the protocol on which it would be based. "It appears Cisco will go proprietary on its SDN strategy," according to a report. The report also quoted another Cisco executive saying that "at this point we don't think [OpenFlow] is production ready."
Asked to respond, Bethany Mayer, interim senior vice president and general manager of the HP Networking business, said Cisco and HP have very strong differences on support for standards-based versus proprietary technology.
"It is at the heart of a philosophy at HP that we remain open with open standards so that we can be interoperable with the other networking vendors in the industry. If they have decided to go the proprietary route, frankly that's bad for the customers," said Mayer.
OpenFlow is a protocol developed at Stanford University and HP Labs was present at the creation in 2007, working alongside Stanford researchers, said Charles Clark, an HP distinguished technologist and director of research in HP Networking. The idea behind it is that the intelligence in the network -- to route packets, prioritize traffic, minimize latency, enforce quality of service (QoS) policies and provide security -- is moved from network switches and routers to a software-based controller. Hence, the term software-defined networks.
The Open Network Foundation (ONF) is a community of academic researchers, networking vendors and companies that manage their enterprise networks, that is developing the OpenFlow protocol, evangelizing it, and helping to bring it to market.
At the HP event in Cupertino, Calif., Dan Pitt, executive director of the ONF, said Cisco is also a member of the group, as are other networking vendors, and that "everybody is contributing in good faith.""This is a movement that is happening and vendors will react to it in different ways over time, but I don't think the movement itself is stoppable," Pitt said, adding that Cisco or any other company can bring to market both a proprietary product and one built to industry standards.
But he and the HP people think OpenFlow is proven technology and that HP is the first networking vendor to offer OpenFlow over such a wide array of its networking products.
HP is offering a free download of OpenFlow to enable SDN on 16 switching product lines that are deployed by service providers, in data centers, on campus networks and in branch offices, said Dan Montesanto, worldwide product manager for data center network solutions integration at HP. Those 16 product lines represent an installed based of 250,000 devices with a combined total of about 10 million ports that can be SDN-enabled.
IBM and NEC jointly announced on Jan. 24 the introduction of an IBM switch coupled with an NEC network controller based on OpenFlow, but Montesanto noted that is only one switch that is SDN-enabled. Both IBM and NEC are also members of the ONF.
The CEO of a new vendor in the OpenFlow space, Big Switch Networks, says more OpenFlow products still in beta testing are expected to come out in 2012.
At an OpenFlow conference last fall Cisco was asked if the intelligence is moved from the switches to the network control layer, wouldn't that make switches more commodity products, selling for less money and making less profit for switch vendors? David Meyer, a Cisco fellow, said the company is aware of the situation and is preparing to deal with it. "Folks get this and how to react to it is what's being formulated right now."
He said it's very obvious to everyone that something's going on here, and the question is how to react to it in a way that everybody can live with. "When you have a big company like Cisco, you've got to socialize those kinds of things." Meyer added that he was pushing people inside Cisco "to start thinking about it."
Responding to the same question on Thursday, HP's Saar Gillai, vice president of the Advanced Technology Group within the networking division, replied that OpenFlow/SDN is not a "commodity play."
"This is a simplification play," he said. "If you look at where HP is deployed today, we're solving customer problems. If you look historically when things like this have happened, typically the same vendor who is providing the value in one place is now providing value some place else."
Cisco did not reply to a request for comment for this story but it will be updated when and if it does.
Learn more about Research: IT Pro Ranking: Data Center Networking by subscribing to Network Computing Pro Reports (free, registration required).
Meraki Ups The Cloud-Based Networking Ante
As mentioned before in this blog, I am a single-site Meraki customer. Though my main wired and wireless networks are built on Cisco gear, last year I opted to run with Meraki in one of my overseas locations for a campus deployment that features site-to-site VPN back to our main campus, routing and 35 access points in a framework that is all-Meraki except for the handful of Cisco edge switches that handle Layer 2 duties. The Meraki deployment has been rock-solid and reliable, but soon will be even better.
Meraki has just announced new hardware and features that bode well for existing and prospective customers, and for the industry in general as a sign of things to come. In my own little corner of the Meraki cloud-managed world, I manage wired and wireless networks via a common dashboard on the Web. Though this has been effective, I have found areas where Meraki could do better by its customers. One of these minor pain points is in managing my site-to-site VPN, as the current UI is pretty sparse on relevant information for this important function. Thankfully, the latest incarnation of the Meraki cloud-based management system rectifies this with two-click site-to-site VPN configuration and welcome details on each tunnel's latency and status.
Even bigger to me, no-extra-cost WAN acceleration has come to the Meraki MX series. Legacy customers like me who use the MX 50 or 70 will see modest gains in WAN acceleration after our free and automatic code upgrade, but customers who get in on the latest MX hardware series also get the benefit of increased processing, memory and a 1-Tbyte hard disk cache for what Meraki estimates to be "up to 197 times improved" WAN transfer times. As enterprises like mine continue to globalize, squeezing the most from site-connecting over-the-Internet WAN links is of paramount importance. That you get WAN optimization as part of the MX purchase without additional licensing is huge.
Also part of the latest release, Meraki is introducing its new cloud-managed Layer 2/3 switches with Power over Ethernet. In my own current deployment, I can manage my Meraki MX appliances (routing, security, DHCP, traffic classification and control, guest access, etc.) and wireless APs, but not my Cisco switches through my cloud-based dashboard. When I rolled out my environment, Meraki did not offer an edge switch. The new MS series switch comes in branch and campus network flavors, and other than not having redundant and field-replaceable fans and power supplies (hint to Meraki), it seems to have good feature parity with the big expensive competitors and some nice trouble-shooting value-adds not typically found in other switching products. The beauty here is that wired and wireless users alike are identified, classified, controlled and supported through the same administrative dashboard, regardless of whether they use a patch cable or wireless adapter to connect.
Given that wireless networking is fast coming to equaling or even surpass Ethernet in terms of criticality for user access across different business networks, it's not surprising that vendors are moving into even deeper "whole solution managed under single pain of glass" waters. Meraki may not be the biggest fish in the networking pond, but I can speak first-hand about its effectiveness at providing a turn-key, cloud-managed solution that makes managing a network easy. (And, in my case, it's a network on another continent that tightly integrates with my main network.) I'm tickled that a good thing is getting even better with Meraki's latest announcements, and am hopeful that others in the networking space are working on similar strategies.
Gone should be the days of thinking of wired and wireless networking as unique spaces, and needing racks full of appliances to gain VPN and enterprise-class security capabilities. Meraki has proven that for the right environments, a tremendous amount can be done with minimal box requirements, and that installation and management don't need a team of IT pros to accomplish. Here's hoping we see more of the same from the competition.
Disclaimer: I am a single-site Meraki customer.