NETWORKING

  • 02/23/2015
    8:00 AM
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

NFV: 4 Home Lab Options

Network functions virtualization is well suited to the home lab. Ethan Banks describes how he built his NFV lab and the pros and cons of different configurations.

Network functions virtualization, as the term implies, takes networking functions that were once hardware and virtualizes them to run in software on a hypervisor. What sorts of functions? Switching, routing, stateful firewalling, and load balancing come immediately to mind, but any L2-7 network functions that can be virtualized fall under the NFV category.

While the growing popularity of NFV is big news for data center architectures, it’s also big news for technology enthusiasts with home labs. Many virtual network devices can be downloaded freely or as fully-functioning evaluations, or purchased cheaply as lab editions, possibly with limited throughput. This means folks with home labs can create mini data centers and get a handle on relatively complex technologies to expand their knowledge.

I’ve spent time with a few different versions of an NFV home lab, finally settling on a configuration I’m happy with, although I ended up spending some money. Let’s walk through each phase of my home lab build. I’ll explain the pros and cons of each lab option as I go.

Option 1: Running a hypervisor inside of your laptop or workstation OS

The most convenient way to test virtual network appliances is by loading them onto the computer you already own and work with each day. A number of software packages can help with this.

  • VMware Workstation is expensive at a $249 list price, but it's a powerful virtual machine manager that can integrate with your existing VMware infrastructure.
  • VMware Player Pro has fewer features than Workstation, but is more affordable at $149.
  • VirtualBox joined Oracle’s portfolio during the Sun acquisition, and is a free and capable hypervisor. On the other hand, VirtualBox isn’t seeing much feature development these days, although the codebase is actively maintained.

Consumer-grade PC CPUs usually have plenty of cycles to spare. Therefore, to run NFV-related virtual machines, working memory (RAM) will likely be a greater issue than CPU. Also, pay attention to the virtual networking capability of the hypervisor tool you chose. If you’re looking at testing several virtual interfaces or VLANs, you might find that the virtual networking capability of PC-based hypervisor products is limiting.

Overall, this method is good as a low-cost way to test NFV virtual machines, but can be limited by available memory and networking capability for some testing scenarios.

Option 2: Dedicating a server to run a hypervisor

I ran into a lack of flexibility running VMs on my workstation;  I wanted to test several VMs at a time, test their interoperability, and create complex IP addressing schemes. I also found that some of my labs scenarios were taking multiple days to complete. Having a dedicated lab server to run those scenarios saved me from relying so heavily on my workstation to stand up the environment.

After doing some research, I opted to build a custom server and run VMware vSphere ESXi hypervisor. ESXi is free and well-featured for a lab environment, and well-documented. If something isn’t going quite right, you can probably Google an answer to the problem. In addition, NFV vendors anticipate that their products will be run on ESXi, so they frequently offer specific installation instructions for that environment.

My server build is a bit dated now, but after nearly a year, I can report zero hardware problems; the system just runs. I spent roughly $1,200 on the server, if my memory serves me correctly. My peers who have built home labs have had good luck buying used servers stuffed full of RAM on eBay. Big cloud providers dump older hardware from time to time when they buy the latest and greatest for their data centers, so it’s possible to find a deal if you’re paying attention.

Unless you’re planning to do heavy load testing, you can get away with less CPU power, but don’t skimp on the RAM. I consider 32 GB a decent place to start, but get more if you can. If you do choose a system with an older, slower CPU, also be sure to check out the virtualization capabilities. VMware provides an excellent compatibility guide.

In summary, this option is good for those willing to spend a bit of money on dedicated hardware. An ESXi host is a good choice for testing NFV, as most vendors expect their products to run in that environment. The downsides are that a dedicated server consumes electricity, takes up space, and makes noise. In addition, it’s not as portable as, say, a laptop -- if you travel a lot and need remote access to your lab, you need to supply some way to access your lab, such as a VPN connection.

Note that it's possible to run ESXi on VMware Workstation (yes, a hypervisor on a hypervisor). This option is not the configuration I chose, but it can be done. ESXi on VMware Workstation is an option for those who want to test with ESXi, but don’t want to dedicate bare-metal hardware to ESXi. VMware suggests that the ESXi-on-Workstation scenario is best for those who are trying to learn the VMware product itself, and not necessarily for running VMs, although you certainly can do it.

Option 3: Dedicating two servers to run hypervisors

For testing NFV, a single ESXi server presents a few limitations. Ideally, it’s nice to be able to lab between two different ESXi hosts that are interconnected with a physical switch. That allows proof-of-concept that’s a bit closer to real-world data center scenarios.

Introducing communication between ESXi hosts through a physical switch reveal potential issues that you might never otherwise see. Therefore, for testing NFV, including a physical switch as a part of the test scenario is important. Testing should happen not only from virtual machines living on the ESXi hosts, but also from physical machines living outside of the ESXi environment.

This set-up is useful to more realistically simulate traffic flows through a production environment. Of course, adding a second ESXi host to the mix doubles the challenge of electricity consumption, noise, space requirements, etc. There’s also that pesky price tag.

Option 4: Cloud hosting with a VPS or Amazon Web Services

This is a scenario I have not tried, but I wanted to raise the issue as I suspect it is on people’s minds. Poking around, I found  a somewhat expensive monthly cost for a suitably beefy virtual private server (VPS), but that running my own hypervisor on a VPS instance wasn’t available anyway.

Of course, there’s always Amazon Web Services, but that seems a bit pricey as well. For example, AWS offers a Cisco Cloud Services Router, but the cheapest instance of it costs $0.07 per hour. Some quick math comes up with over $50 a month to run the instance, and Amazon still expects that you’ve brought your own license.

If you extrapolate costs to run as many NFV virtual machines on AWS as might interest you, the costs quickly exceed that of simply buying a server. Of course, you could power the lab instances up and down as you need them and cut back on that spend dramatically, but there is convenience in an always-on, always-there lab.

To me, cloud hosting a home NFV lab seems impractical at best. If you’ve come up with a cost-effective way to build a cloud lab that gives you the flexibility and ease of use to stand up and tear down NFV-related virtual machines as you like, please share in the comments section below.

In my next blog post, I'll look at the storage and networking considerations for your NFV home lab, and provide a list of NFV appliances so you can start working with NFV.

Attend Ethan Banks' live session, IT Infrastructure in 2025: What Will The Future Look Like? It's one of the dozens of learning opportunities at Interop Las Vegas this spring. Don't miss out! Register now for Interop, April 27 to May 1, and receive $200 off.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.