- Home
- News aggregator
News aggregator
Time To Say Goodbye To Static IPs
The thinking behind the practice is that if all else fails, IT can still connect to critical services because the IP address is static and therefore known. That may be true, but with the advent of server virtualization and the inevitable migration to IPv6 addresses, it's time to end this well-intentioned but misguided habit. The fact is, static IPs break the mobility and flexibility that server virtualization provides. As for IPv6, do you really want to keep lists of all those 32- digit addresses in hex?
A Better Choice
Extend your use of DNS and DHCP to these systems. I know some IT pros will argue that this is dangerous and insecure. After all, if DNS and DHCP services fail, you won't know the IP addresses for important network devices or virtual servers. It would also force IT to treat DNS and DHCP like mission-critical services, which means spending more time and resources to keep them up and running. But DNS and DHCP are already used for essential devices and applications, such as VoIP phones, Active Directory services, and wired and wireless desktops. If your DNS or DHCP servers fail, you have to get them restored right away.
In other words, DNS and DHCP are already essential, and it's time to treat them as such. Moreover, by expanding use of DNS and DHCP to eliminate static IPs, you can take better advantage of server virtualization. One of the benefits of virtualization is it lets you move VMs around your data center and even between data centers. Data center automation simplifies VM moves and VM provisioning.
Those actions, as well as others, are difficult or impossible to do if you use static IP addresses. What happens if you bring up a VM on, or move a VM to (not a live migration, of course), a subnet where there is an address collision? You must, as part of the move, change the node's IP address. You can do that using automation software like Puppet, but it's not only a lot more integration work, it's one more function that can fail. Static IPs are also more difficult to use with virtual appliances because they are often physical-to-virtual clones of their hardware counterparts, and IP configuration can't easily be automated.
And managing static IP addresses only gets more complicated as you move up into applications because those assignments are buried in configuration files.
Frankly, the IP address assigned to a host shouldn't matter. What's more important and useful to IT is the host name: You can decouple a name, which is portable, from an IP address, which may not be. You want to connect your application to database.example. com, not 2001:0db8:85a3::8a2e:0370:7334.
I can hear the concerns from operations and security about how DNS and DHCP aren't reliable or secure. But it's your job to make them so. Do it now, and you can thank me later.
Hybrid Memory Cube Takes RAM to the Third Dimension
Formerly known as Hyper Memory Cubes, the new Hybrid Memory Cubes promise memory bandwidth up to 1 Tbps, more than 10 times what today's DDR-3 can deliver, while using about one-eighth the power per gigabyte. The cube is a hybrid package that stacks four or eight DRAM chips on top of a base-level memory controller chip.
Stacking the chips in a small package has several advantages. First, the stack keeps the interconnections between the memory chips and logic chip significantly shorter than they could be on a more conventional DIMM. At multigigahertz-frequencies, distances--even those measured in just a few inches--matter, since data signals are limited by the speed of light to traveling about one foot per nanosecond.
Using a stack rather than a single chip required the Hybrid Memory Cube designers to develop what they're calling silicon through-vias, which provide data paths vertically through the extra-thin silicon chips that make up each layer. Without silicon through-vias, signal paths would have to extend to the edges of each chip, where a massive number of interconnection wires would have to be connected. This would slow performance and make the whole thing too complex to manufacture cost effectively.
Most significantly, it allows designers to use completely different integrated circuit manufacturing processes for the memory controller logic chip and the DRAM chips themselves. Combining logic and memory on the same chip means the logic sections of the chip have to be produced using the memory chip process, which significantly limits their performance. A dedicated logic chip provides significantly more horsepower for ECC and other memory management.
We should see Hybrid Memory Cubes appear as preproduction samples some time in 2013, with the technology appearing as an extended processor cache in leading-edge servers, as vendors roll out their next generation of servers in 2014 to 2015. With power players like Micron, Intel, Samsung and most recently Microsoft in the consortium, odds are good that Hybrid Memory Cubes could be the solution to our memory bandwidth woes.
Disclaimer: Micron has provided SSDs for use in DeepStorage Labs.
Cisco Acquires Data Analytics Company Truviso: Can It Execute?
At first glance, data analytics isn't part of Cisco's core business of networking, and it isn't related to one of the company's foundational priorities. Memories of previous business failures, like the Flip video camera, come quickly to mind as areas where Cisco picked the trend but failed in the execution.
Most of Truviso's product offerings are focused on Web analytics. Truviso also claims that it can provide analysis for video and mobile, as well as for advertising (including targeted placement). Given that most of the current market for data analytics is applied to extracting more advertising revenue from existing Web businesses, this seems like a solid application of the technology.
What can Cisco do with these assets? Where does data analytics with a Web-centric application fit into the Cisco product portfolio?
Truviso's offerings seem different, in that the company performs real-time analysis (unlike most other analytics tools, which are batched and near time). In my view, the concept of continuous analytics would be very useful for network management and operations. The immediate application of the software assets to NetFlow applications could improve the quality of the reporting and data. The limitation of NetFlow analysis is partly determined by the performance of the collectors, but, critically, the user's perception of product performance and value is determined by the NetFlow analyzer. Today's NetFlow analysis products are competent but rarely expose useful data metrics beyond simple analysis of voice and critical data. The amount of data processing needed to enhance the usefulness of NetFlow is beyond the current software developers--Truviso may be an answer to that.
But perhaps the most vital part is software-defined networking (SDN) applications. While many SDN controllers are looking to implement as configuration utilities, the longer-term value of the OpenFlow-enabled network is the ability to dynamically respond to packet flow events and change the network configuration. This concept would require massive data analysis of the entire network (a big-data problem if ever there was one) and is not easily implemented. Therefore, a "big-data engine" will be a vital part of any long-term SDN strategy.
Because Truviso already has an OEM model, the business unit could release products into other Cisco business units for use. Less repackaging and less change means faster adoption of technologies (Cisco is slow to integrate new acquisitions these days).
So, perhaps Truviso has a part to play in the Cisco portfolio. Here's the vision I see: The network of the future will be driven by software controllers that are fueled by big data. Truviso doesn't look like a networking product, but the fundamental change in networking to data requires new engines.
Given Cisco's execution track record after correctly identifying trends, we'll just have to see how this one plays out.
BYOD vs. Network Bandwidth: How Blue Coat Tackles Selfish Apps
There's a lot of Internet applications out there with a lot of different network usage models. Some are chatty, some are optimized. Some are bursty, others are constant network bandwidth users. Even if you can figure out what applications are coming into your enterprise and understand their bandwidth needs, that's only part of the problem. Some of the apps are critical to the company, and others--like, say, YouTube--are less so. Many who've tried to manage the melee have given up in favor of just adding more bandwidth. And that was a viable solution until the recent rise of what Blue Coat calls the selfish application.
What's a selfish application? It's any app that from time to time downloads a lot of data and does it as fast as it can--regardless of the needs of other apps on the network. In other words, most apps are selfish. The difference these days is the quantity of data they're downloading and the likelihood that lots of other people are running the same apps and downloading similar quantities of data. Think of all the Flash updates, or iOS refreshes, or YouTube users on their personal devices. The data sets have gotten bigger, and the number of users is growing daily. So if you weren't managing your WAN bandwidth before, it might be time to start.
Blue Coat gave a quick demo of how YouTube can suck up available network bandwidth, and how its Mach5 and PacketShaper products can manage bandwidth limitations for particular apps. For the most part, the problem of bandwidth-hungry apps is newer than the Blue Coat features to limit them. The problem is compounded by employees, visitors and contractors bringing in their own devices and expecting access to the Internet and internal resources. It can be further exacerbated by heavy use of SaaS applications.
Blue Coat does have a new major release of its software, which has been shipping for just a month now. Version 9.1 now handles IPv6 and increased the throughput capability when run on Blue Coat's fastest hardware.
Interop Las Vegas 2012: A Big Thanks to the Speakers
I mainly want to say thanks.
Thanks to the audience members who attended the sessions. I know the speakers appreciate you coming and asking questions. There were a number of good sessions each day; making a choice of where to go was difficult.
Thanks to the track speakers, in no particular order: Dave Peters from ESRI, Kurt Marko from InformationWeek, John Burke from Nemertes, Sam Barnett from Infonetics, Frank Wiener from Cyan, Eric Shepcaro from Telx, Barry Dykes from ViaWest, John Abbott from the 451 Group, Duncan Cambell from HP, Brendon Howe from NetApp, Stephen Steir from VCE and Dheeraj Pandey from Nutanix. The Data Center track was informative, and I'm sure the Interop Las Vegas audience learned from your sessions.
On the Storage track, thanks to Stu Miniman from Wikibon, Howard Marks from Deep Storage.net, Stephen Foskett from Gestalt IT, Randy Kerns from the Evaluator Group and Sandeep Singh from HP. In particular, Marks and Foskett agreed—I still don't know why—to engage in a "Cloud storage is DOA" debate, with Foskett arguing it isn't and Marks arguing it is. (Marks doesn't really think cloud storage is DOA, he was just arguing the point.) It was fun, funny and informative. Marks won by a landslide, but that was due to releasing his inner thespian. You can catch the debate on YouTube.
I had the pleasure of sitting down with:
- Allan Leinwand from Zynga, who discussed what the social gaming company is doing with its cloud;
- John Engates from Rackspace, about cloud computing and OpenStack, among other things;
- Allwyn Sequeira from VMware, who talked about virtual networking and software-defined networking (SDN);
- Steve Hanna from Juniper and the Trusted Computing Group, Lisa Lorenzin from Juniper and Mark Townsend from Enterasys, who caught me up on IF-MAP; and
- Don Clark from NEC, who caught me up on what NEC is doing with OpenFlow.
If you missed the Las Vegas Interop keynotes, you can catch them at Interop TV. We're getting ready to work on Interop New York, coming Oct. 1 through 5. We should be going through the call for papers and putting together the sessions. I know Jim Metzler and I will do the SDN and Data Center LAN Design workshops again.
Enterprise IPv6 Deployment Stories at Summit a Refreshing Change
Shannon McFarland of Cisco presented "Enterprise Internet Edge Design for IPv6." He explained how many of Cisco's enterprise customers are enabling their Internet edge as the first step in deploying IPv6. Enabling the edge involves configuring IPv6 routing on the Internet edge router, obtaining IPv6 service from a provider and turning on IPv6 on the Border Gateway Protocol sessions to the service provider router. The advantage of this approach is it's a business continuity play: You can decouple your external services and the risk of IPv4 address exhaustion. In addition, this IPv6 deployment strategy allows you to take a slower approach to overall IPv6 deployment.
Who knew enterprise IPv6 could be so entertaining? Tom Coffeen of Infoblox told the audience about "IPv6 Adoption in the Enterprise," in which he included references to sci-fi favorites such as Star Trek, A Clockwork Orange and Alien. Joking aside, I found several aspects of Tom's speech to be very interesting. He pointed to Infoblox polling data for the question, "What is your organization's current plan for dealing with IPv6?" A whopping 26% of respondents had no plan for IPv6; another 5% planned to "ignore IPv6 and do nothing." That almost a third of respondents don't see any urgency for IPv6 isn't surprising, as these companies are often very conservative and risk-averse. I wonder if enterprises will be surprised at the costs of being late to the IPv6 game.
Coffeen also described a concept he called "the enterprise IPv6 death spiral." Companies that wait on an ideal business case don't dedicate resources to IPv6. For their engineering staffs, learning about IPv6 without hands-on practice has limited benefits. Without training and operational experience, these engineers are less likely to promote IPv6 deployment within their companies. IPv6 fails to gain traction in these organizations, and the spiral continues.
Several government employees and contractors spoke about IPv6 in the federal arena. One pointed out that many of the lessons learned in government deployments apply to enterprise IPv6 deployments. I enjoyed Dale Geesey's talk on "U.S. Government IPv6 Adoption Synopsis." Geesey, chief operating officer of Auspex Technologies, discussed how the U.S. Department of Veterans Affairs will disable IPv4 in 2015--a startling contrast from the federal government's aggressive IPv6 deployment and the more gradual approach taken by enterprises.
My speech at the summit, "Why Your Network Should Go IPv6 Only," applied to enterprises, among other organization types. I made the argument that the dual-stack approach to IPv6 deployment is no longer valid because IPv4 space is nearly exhausted. Deploying IPv6-only in some parts of your network reduces cost and complexity, and gives your staff experience with IPv6.
As enterprises continue to venture into the IPv6 world, I hope future conferences include talks from enterprises that have deployed IPv6. There's a lot of work to be done in this area, so spreading the word about your experiences gives back to the technical community in an important way.
Searching for an SDN Definition: What Is Software-Defined Networking?
Case in point: I had the opportunity to talk with Allwyn Sequeira, VMware's CTO of security and VP of security and network solutions, about what the company is doing in networking. It's neat stuff and I'll write more later, but toward the end he said VMware's virtual networking is a software-defined network--to which I said it wasn't. The dynamics of networking in virtualized scenarios are interesting and require unique products and features to support app and VM mobility, hybrid scenarios and the like. Someone (I don't remember who) said on Monday's SDN workshop that if the networking vendors don't solve virtual networking problems, VMware will. For better or worse, VMware is working the problem and apparently trying to co-opt the term SDN along the way (or maybe signaling future plans).
When I think about what makes an SDN unique from networking or virtual networking, it hinges on the word defined. Sure, Cisco's IOS or Juniper's JunOS are software systems that implement algorithms and routing protocols to define the paths through the network, but is that enough to satisfy the requirements of software-defined networking? If you think yes, they why do we have the term SDN (which I don't think was created by marketers)? If we have a new term, it ought to indicate something new, right? If you think not, then we have to define what makes SDN different from what networking does today.
The Open Networking Foundation (ONF)--the organization shepherding the OpenFlow specification through to standards--is at the forefront of SDN. Its SDN definition, published in "Software-Defined Networking: The New Norm for Networks," focuses on three key features:
- Separation of the control plane from the data plane
- A centralized controller and view of the network
- Programmability of the network by external applications
The report says, "Software defined networking (SDN) is an emerging network architecture where network control is decoupled from forwarding and is directly programmable. Network intelligence is (logically) centralized in software-based SDN controllers, which maintain a global view of the network."
The Open Networking Summit's graphic to the left illustrates the separation argument very well. On the left, individual devices form a map of the network in cooperation with their neighbors, and then populate their forwarding engines with paths through the network. It's how networks have worked, and they work well. On the right, an SDN separates the control plane--the purple rectangles on top--from the forwarding devices on the bottom.
The centralized view and the separation of the control plane and the data plane means that the SDN controller can create a physical topology--I'm not using the term L2 topology on purpose, since that implies more than the physical topology--of how nodes are connected and, based on some combination of algorithms, create paths through the network. Finally, the paths are programmed into the devices' forwarding engines. That allows the SDN controller to better manage traffic flows across the entire network and react to changes quicker and more intelligently. How well the controller defines those paths is, of course, critical to the operation of an SDN.
That brings us to programmability. SDN abstracts the network much like an OS abstracts the applications from that hardware. The ONF white paper above has this graphic depicting the abstractions:
Why would you want to program the network? Think about the ways that we perform tasks today, like enforcing quality of service. If we have two apps--a file transfer that needs capacity and an interactive app like VoIP that needs low, consistent latency--we use QoS marking to tell the network to treat the packets differently and, when congestion occurs, which ones to queue up and drop first. It works OK, but when the network is congested, performance suffers.
If you have multiple paths through the network, wouldn't it be useful to be able to, in real time, move that file traffic to a path that has capacity but perhaps has more hops? Doing so would open more capacity for the latency-dependent traffic and, in the end, both applications get better performance.
Consider a security context where you want to ensure that a set of users can only access a set of resources. You can do it with firewalls, access control lists and user identity, but that integration works only with a subset of pre-integrated products. With an SDN, you could enforce access control in your network. Naturally, you need a common protocol to do that, and OpenFlow is one example, but it is not the only way to implement an SDN.
It's important to remember these distinctions between an SDN and virtual networking because network overlays such as VXLAN or NVGRE have distinct advantages, such as hiding layers of addressing between the physical and virtual network, providing better mobility for entire groups of servers and services to different locations regardless of the underlying L2 network, and creating adjacency of virtual hosts in the virtual network, regardless of their physical location. Doing networking in software doesn't make it a software-defined network.
VMware's virtual network is a software virtual network. VMware's virtual networking doesn't have the other hallmarks of SDN, such as separation of the control plane from the data plane, which are still combined in the virtual and physical switches. It also doesn't have the programmability of forwarding paths, such as the ability to directly determine the path a flow will take in the network. It's companies like Big Switch, Contextream, Embrane, NEC and Nicira that are bringing those features to the market.
I'm using VMware as an example, but there are and will be other vendors, particularly in networking, that will try to co-opt SDN to mean everything from simple overlays to API/SDK-enabled configuration control, which does not define the network but simplifies hardware management.
Gigamon Visualizes Virtualization Traffic
Gigamon makes modular hardware technology that examines traffic in-line, based on administrator-defined parameters (from servers down to the applications), and spits that data out to a variety of traffic management tools--intrusion detection systems, application monitors, and so on--where more specific analysis takes place.
At Interop, Gigamon announced GigaVUE-VM, so administrators can look at the same traffic flows, but this time between virtual machines--again, setup and defined down to the application (including custom applications). GigaVUE-VM supports VMware's vMotion, so it continues to collect the traffic, even as virtual machines move.
By the way, the new technology supports only VMware at this point, but GigaVUE-VM will support more hypervisors in due time.
For a deeper look at GigaVUE-VM's architecture, and a demonstration of how it works, watch the video embedded below.