After VLANs: managing the new virtualised networks

Feature

After VLANs: managing the new virtualised networks

Managing an ever-changing network landscape calls for as much  automation as possible. Can Juniper, HP and Cisco help?

IT suppliers often talk of  'evolution, not revolution' as being the way forward. However, the introduction of cloud computing, mass outsourcing and widespread virtualisation means that a revolution is surely what we now have on our hands.

142703_cs0390.jpg

Do we also need a revolution in terms of the technology at hand, to successfully deploy and manage this new wave of virtualised networks?

Network management tools, even later-generation examples such as application monitoring, are based on building up knowledge around a known (fixed) network and application set.

However, the new generation of hybrid networks, which may be part private, part public (cloud, managed services, and so on) are truly dynamic. There is no longer a one-to-one relationship between the physical connections of two network nodes or elements.

This means that any fixed knowledge base is always going to be out of date immediately and therefore, arguably, largely useless unless working with traditionally deployed networks.

There is also the human element to consider. With the introduction of the virtual environment, multiple groups across an organisation are responsible for different parts of the network, such as servers, local and remote datacentre administration and the physical network. This makes the traditional game of pointing the finger of blame in the event of a networking issue all the more complex; new rules apply. And to what extent can the human element be taken completely out of the equation with automation?

In other words, we need a means to manage an ever-changing networking landscape with as much automation as possible, which is no easy task. So what is the solution? Here we look at three global suppliers – Juniper, HP and Cisco – to see if they have the answer.

Juniper Networks

David Noguer Bau, head of service provider marketing at Juniper Networks, says the main reason for change is simply that the increased complexity of the current network model across both the enterprise and service provider landscapes has resulted in processes – and physical connections – slowing down, while the agility required to launch new services in a timely fashion has been compromised.

"In the datacentre, for example, the compute side has built up massively in the past 10 years, while networking has basically stayed the same," says Noguer Bau. "Yes, we have created bigger, more capable fabrics, but the time it takes to provision a VLAN [virtual LAN] between two servers can be minutes and major deployments can take hours or days, yet it takes seconds for a VM [virtual machine] to be deployed within a server."

Noguer Bau believes software-defined networks (SDNs) provide part of the answer – the virtualisation aspect, for example – but still require interaction with the physical networking hardware and other elements. Juniper’s approach is to take an open-standards model that encompasses all aspects of network management and control, whereby all they need is IP connectivity to deploy and manage the virtualised network.

At the heart of the system is a product called Contrail. This deploys a virtual router inside each virtual server, while a Contrail controller sits in the datacentre and manages the virtual routers, creating secure connec­tions between any servers in the datacentre. At this point, the majority of tasks are automated. The system is also completely open from an integration perspective, so is not designed as a purely Juniper play.

HP

HP was quick of out the traps to announce its SDN blueprint and support for OpenFlow and it has since developed a system called OpenNFV.

This is designed to be a comprehensive network functions virtualisation (NFV) program with the aim of accelerating innovation in the service provider/telco market, allowing HP to launch new services more quickly, more easily and more cheaply through the virtualisation of telecommunications core networks and network functions. In other words, a very similar set of aims to those of its competitor Juniper, the key being an obvious return on investment (ROI). As part of this process, HP has launched an open-standards-based NFV reference architecture – HP OpenNFV Labs – and a partner ecosystem of what it describes as best-in-class NFV applications and services.

At the heart of the HP OpenNFV program is the HP open-standards-based OpenNFV Reference Architecture (NFV RA), which provides a complete architectural ecosystem covering physical servers, storage and networking, virtualisation, controllers for SDN, resource management and orchestration, analytics, telco applications, and a complete operations support system (OSS).

The HP NFV RA incorporates SDN capabilities, including the HP SDN Controller, SDN Ecosystem and virtual services router (VSR) designed for multi-tenant, virtual private clouds and virtual customer premise equipment (CPE) deployments. This forms a ready-to-be-deployed architecture designed to enable a service provider or telco to move from a traditional network to an NFV/SDN-based architecture in one transition.

Cisco Systems

With its Open Network Environment (ONE), Cisco also has a system to help move networks into being more open, programmable and application-aware, including SDN.

One of the most important elements is being able to provide very high availability for applications while keeping operating expenses low

Ian Foddering, Cisco UK and Ireland

Again, the model is to simplify operations and reduce total cost of ownership (TCO) by extending the capabilities of an existing infrastructure, enabling it to deliver advanced applications and services for physical, virtual and cloud environments with a fully integrated framework. At the heart of Cisco ONE is what it calls a dynamic feedback loop that gathers network intelligence and programs individual network layers to optimise user conditions and which can be tailored for any number of individual applications.

Ian Foddering, chief technology officer at Cisco UK and Ireland, says one of the most important elements is being able to provide very high availability for applications while keeping operating expenses low, regardless of the geographical location. To enable all the benefits of geographically dispersed datacentres, the network must extend Layer 2 connectivity across the diverse locations.

Cisco’s Overlay Transport Virtualisation (OTV) provides a solution here, being a “MAC address in IP” technique for supporting Layer 2 virtual private networks (VPNs) to extend LANs over any transport. The transport can be Layer 2-based, Layer 3-based, IP-switched, label-switched or anything else as long as it can carry IP packets.

By using the principles of MAC routing, OTV provides an overlay that enables Layer 2 connectivity between separate Layer 2 domains while keeping these domains independent and preserving the fault-isolation, resilience and load-balancing benefits of an IP-based interconnection.

No single answer

Clearly, there is no single solution here for deploying and managing a distributed, virtualised network. SDN was excessively hyped as the new saviour of networking, but forms only part of the overall solution set – something outlined here by the approaches of Cisco, HP and Juniper. At the same time, there is an argument that no single networking supplier has the ability to fully manage its global environment. Products such as Incident.MOOG from Moogsoft support a multi-supplier environment.

What we are seeing here is undoubtedly work in progress, but it is ultimately a networking revolution, not a trivial update of existing infrastructures and, as such, is a long-term change, not an over-the-weekend makeover.


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in May 2014

 

COMMENTS powered by Disqus  //  Commenting policy