Ruslan Grumble - Fotolia
Looking for something else?
Virtual routers are technically simple -- they are software instances of routing features hosted on servers. Interest in virtual routers is high, but questions remain about how far they can go in the network and whether developments like network functions virtualization (NFV) increase the pace of virtual router adoption.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Operators were excited about virtual routing and issuing real purchase orders to acquire it before there was a European Telecommunications Standards Institute (ETSI) specification group working on NFV, and before there were any NFV tests or trials.
The Capex savings from buying virtual routers instead of physical routers are simple benefits to realize. A single physical router replaced by a virtual router saves about 25% to 40%, operators say. You don't have to deploy a server farm to realize the benefit, because there's no presumed economy of scale. And you don't have to rework operations because operational efficiency isn't part of the business case.
This simplicity is why virtual routing got off to a running start while NFV and software-defined networking (SDN) standards writers were still sharpening their pencils. So, why haven't all physical routers been replaced with virtual ones?
Part of the reason is the remaining depreciation on existing equipment -- which, on average, has a little less than three years of expected useful life remaining out of the usual five years for operators' routers. But the bigger reason is that while some routers are easily virtualized, other types are not.
A typical corporate WAN is currently built from VPN services and edge routers. The edge routers handle traffic for a single location, which is well within the capabilities of even many non-customized servers. For use with managed services, VPNs and Carrier Ethernet VLANs, a service provider can save money by putting an inexpensive server on each site and loading it with virtual routing software.
The problem comes with the VPN routers for the interior of the network. Where a single user's traffic is involved, virtual routing substitution is easy. But when operators are trying to build a VPN on-ramp for an entire metro area, they need a giant router whose aggregate capacity is far beyond what a server can currently support. As a result, it's no surprise that router vendors report stronger hardware sales for the network core because you can't easily virtualize routing there.
More evolving uses for virtual routing
Even though virtual routers benefit from the simple Capex-driven business case, operators will run out of edge routers to virtualize at some point. But several drivers are already visible that will keep virtual routing growing.
In the Carrier Ethernet edge example above, we might typically build VPNs using MPLS and routers. But if you built a VLAN based on Ethernet and added virtual router edges, the result would still look like a VPN to the user. You could even join metro VLAN/VPNs with virtual router links. A network like this would be independent of carrier IP networks, so it would potentially be more secure and offer better availability and quality of service.
The mobile space offers another example. Mobile infrastructure moves traffic using what's known as the Evolved Packet Core (EPC). EPC has many dedicated and specialized devices that vendors are working hard to virtualize. So, why not virtualize the routers involved in mobile infrastructure as well? While mobile traffic is significant, it has "edges" at the radio network edge that could be virtualized using server technology. Given that we're already talking about virtual radio access networks, a virtual router connection with the RAN is very logical.
The final example is virtual router use in SDN and the cloud. Most cloud computing relies on some form of network virtualization. Public cloud providers like Amazon Web Services (AWS), Google and Microsoft Azure use virtualization to separate tenants, and vSwitches are used routinely to provide tenant-specific networking. As the use of the cloud grows, these tenant networks will start to resemble private networks, and we'll need to unify them into a single network, across all the cloud applications the customer happens to be running. That's another virtual router mission.
Where NFV and virtual routing benefit each other
The interesting point here is that none of these drivers involves NFV, which is often considered the primary driver for virtual routing. NFV is only now working its way to real deployment, but two of its early applications are in mobile infrastructure and virtual CPE. As NFV is deployed, it could also accelerate virtual routing deployment in two mutually beneficial areas.
The first area is scaling and resiliency. While you can deploy a virtual router on a server, you can't fully realize the benefits of a virtual router in terms of scaling under load or replacing a failed instance unless you deploy it within an automated operations framework. NFV also requires such a framework, so NFV can build the tools to fully realize virtual routing's performance/availability benefits.
The second area is agility. The topology of a network built from fixed devices is fixed by the location of the devices. If we imagine virtual routers hosted in cloud server complexes throughout an operator's service area, we can imagine an IP network or subnetwork that has nodes wherever traffic conditions suggest they should be. By adapting topology to traffic flows, you can optimize network resource usage and manage the tradeoff between availability and performance.
All of this is happening as chip vendors like Intel, network adapter vendors like Mellanox and software projects like the Linux Foundation's IO Visor Project for virtualizing and accelerating server I/O are improving server performance in virtual router applications. That allows virtual routing to exploit new niches.
And new niches are being developed. The long-term driver for virtual routing may be agile optics. If users and applications on networks are separated at the optical or physical layer, then network traffic is aggregated below Layer 3. Per-user and per-service routing functions would then be well in range for virtualization, and we could see Layer 2 and Layer 3 move almost entirely to a virtual form.
Virtual routing is part of the broader trend toward virtualization, symbiotic with NFV and other forces driving virtualization, but it is not dependent on them. We'll see more of it every year, and it may dominate the space sooner than many people think.
The evolution of virtual routers
Check out our Cisco, Brocade virtual router review
And more reviews: Alcatel-Lucent, HP and Juniper virtual routers