When I started out in my Networking career, Cisco’s firewall product was called the Cisco Private Internet eXchange (PIX). A few years after that, they rebranded it as the Cisco Adaptive Security Appliance (ASA) and now Next Generation Firewall (NGFW) with FirePOWER Services. The point I’m trying to make is that in the field of Technology, things change really fast and something new always comes up. Network Function Virtualization (NFV) is one of those new topics that is gaining momentum and you may be left wondering: “what in the world is NFV?”
What is a Network Function Virtualization?
Traditionally, when you hear the word (perimeter) firewall, you think of a dedicated appliance/hardware that performs the firewall function and this appliance is installed (logically) at the edge of the network. Examples will be the Cisco ASA series and the Checkpoint firewall.
However, have you thought about what is inside that firewall appliance? Basically, you have the firewall software running on a custom, proprietary and usually expensive hardware from that vendor. So what are you really paying for? The function the device is performing or the hardware (plus brand name of the vendor)?
Side note: It can be argued that total cost of ownership (TCO) of a networking device should be favored over just the initial purchase value (capital expense). Vendors like Cisco claim that when TCO is used, then the deal they offer is not half as bad.
While it is true that it may be better to run custom-made hardware for certain functions (e.g. high packet switching that require purpose-built Application Specific Integrated Circuits (ASICs)), many organizations are experimenting with the fact that some network functions can be handled very well on standard servers that are less expensive and more readily available.
This is what Network Function Virtualization aims to do: separate the software (network function) from the hardware so that the network functions like Firewall, Deep Packet Inspection (DPI), Content Delivery Network (CDN), Virtual Private Network (VPN), can be run on industry standard servers, storage and switches using normal virtualization technologies.
Why NFV?
Let’s think for a moment about some of the benefits of virtualizing network functions. These benefits will be similar to the benefits provided by any virtualization technology. For example, if you have used VMware Workstation or VirtualBox, you know that such virtualization software (also known as Hypervisors) allow us to run several guest OSs/virtual machines on one host machine (depending on how much capacity the host device has).
In the same way, instead of having several boxes to serve as VPN gateways, using the NFV model, you can have one (or a couple) bare metal servers and storage and then create VPN gateway virtual appliances on this hardware. This will result in a couple of things:
Lower Capital Expenses (CapEx): Standard servers and storage are less expensive and more readily available than proprietary hardware. In fact, you may already have underutilized hardware that can be put to use. Moreover, by converging your infrastructure, you can reduce your upfront cost.
Lower Operating Expenses (OpEx): Think about the energy and cooling savings a single box will result in versus that of several boxes.
Roll out new services faster: NFV actually originated in the Telecommunications space and this was one of their main issues – the time it takes to implement new services, from ordering new hardware to testing and then implementing. With NFV, it’s simpler to just spin up a new virtual instance, test and roll out in weeks (days?) and not months.
Scalability: One of the advantages of virtualization is the ability to increase or decrease capacity as needed and NFV also provides this.
About NFV
As mentioned earlier, NFV started out in the Telecommunications industry. Even though there are no standards for NFV yet, the big players joined forces in 2012 to create an Industry Specification Group (ISG) for NFV under the European Telecommunications Standards Institute (ETSI). This was done in a bid to move the dream of NFV forward and define specifications.
Virtualized Network Function (VNF): This is the software implementation of a network function (e.g. DPI, Firewall, CDN, etc.). VNFs will run on the virtual machines provided by the NFVI (below).
Network Function Virtualization Infrastructure (NFVI): This includes the physical resources (servers, storage, networking), the virtualization software and the virtualized resources (e.g. virtual machines) that make it possible to run VNFs.
NFV Management and Orchestration (MANO): This block is responsible for the coordination and management of the NFVI and VNFs.
These parts can be further broken down into different functional blocks. For example, the NFV MANO group contains blocks like the Virtualized Infrastructure Manager (VIM), the VNF Managers and the NFV Orchestrator. However, this article will not go into such technical details. You can read more about those blocks in the GS NFV 002 document already referenced.
Another buzzword that has hit the networking industry in recent times is Software Defined Networking (SDN). The aim of SDN is to decouple the control plane from the data plane so that network control can be more easily programmed. As you can see, this is quite different from NFV. Therefore, it is important to note that NFV does not need SDN to work (and vice-versa) even though both technologies can complement each other. By virtualizing network functions (software), it becomes easier and less restrictive to apply SDN technologies.
A good example of how SDN and NFV can work together (along with the cloud) is the Central Office Re-architected as a Data Center (CORD) effort where traditional Telco Central Offices with legacy closed and proprietary hardware are replaced with software running on standard commodity servers (NFV) and these software are better managed and orchestrated as scalable services (SDN).
NFV in the real world
So far, we have looked at NFV as an abstract concept. However, NFV is already making gains in the world today and in this section, we will look at some examples under the three major blocks of the NFV architectural framework we discussed above.
We can test out NFV by running the Cisco ASAv in GNS3. The process to do this is now more tightly integrated in GNS3 than before by using their GNS3 VM. To set this up, you need to have GNS3 installed, download and setup GNS3 VM, and then add the Cisco ASAv as an appliance to GNS3.
Note: You can run ASAv in VMware like you will run a normal virtual machine without using GNS3.
We will be using a simple lab setup containing one Cisco ASAv appliance and one PC as shown below:
After the ASAv boots up, we can use the show version command to view the details of this appliance:
Notice that I am running ASA software version 9.8 but the hardware type is ASAv.
To test that it works, I will configure an IP address on the ASA’s Gi0/1 interface and ping the IP address of the PC (192.168.1.100):
You should keep in mind that the Cisco ASAv does not (yet) support features like Clustering, Active/Active Failover and Multiple context mode.
Challenges of NFV
As with any technology, especially a relatively new one like NFV, there are a couple of challenges to be overcome. The first that should come to mind is Performance. Like we discussed in this article, one reason to go with a Cisco ASA box over pfSense is the fact that it comes in a dedicated hardware that has gone through rigorous performance tests. Would off-the-shelf hardware used in NFV be able to match the performance of application specific hardware? The jury is still out on that and only time will tell. However, companies like Facebook seem to be willing to take the risk and have been building their own hardware for a while now.
A closely related challenge with running virtualized network functions on commodity servers will be that of Support. If a problem occurs on the network and it is not clear if it is a software or hardware fault, who takes responsibility for the solution? The hardware providers (NFVI) or the software providers (VNFs)?
Another challenge is that of Interoperability. Due to the “open” nature of NFV, an organization may need to run VNFs created by one vendor on top of virtual machines/hardware created by a different vendor. Standardized and open interfaces (e.g. APIs) that facilitate seamless integration will need to be developed.
Currently, organizations are running network functions in the traditional manner – hardware and software tightly coupled together. Since the move to NFV will not happen all at once (and a complete move may not even happen at all), another thing to consider is Coexistence. The new virtualized network functions (which ideally will be designed around open standards) must be able to work with and be compatible with the legacy systems (usually closed source) already in place.
Other challenges include Management, Security, Stability and Automation.
Summary
Original Equipment Manufacturers (OEMs) like Cisco and Juniper had a hold on the Telecommunications market for a long time with their proprietary devices. Since Network Function Virtualization (NFV) allows network functions to be run on standard hardware using virtualization technology, the market seems to be using NFV to take that OEM hold off.
NFV offers several benefits like the potential for reduced capital and operating expenses, scalability and the ability to roll out new services quicker. However, there are also challenges to be overcome including performance issues, interoperability and compatibility issues, management, security and so on.
Several products already exist that can be classified as being in the NFV space including the Cisco Cloud Services Router (CSR), Juniper vSRX Virtual Firewall, VMware vCloud NFV and so on.
NFV is gaining a lot of momentum especially among big service providers and it seems those who will be affected most are the OEMs like Cisco. However, those OEMs are also revamping their products and services and are trying to retain their top spot even in this new NFV market. Good for them.
Adeolu Owokade
Adeolu Owokade is a technology lover who has always been intrigued by Security. He has multiple years of experience in the design, implementation and support of network and security technologies. He's a CCIE (Security) with a new found love for writing and teaching. He is currently working on a startup that teaches kids practical technology skills such as coding and robotics.
RouterFreak Reviews, Tips and Tools for Network Engineers
Network Functions Virtualization (NFV)
Introduction
When I started out in my Networking career, Cisco’s firewall product was called the Cisco Private Internet eXchange (PIX). A few years after that, they rebranded it as the Cisco Adaptive Security Appliance (ASA) and now Next Generation Firewall (NGFW) with FirePOWER Services. The point I’m trying to make is that in the field of Technology, things change really fast and something new always comes up. Network Function Virtualization (NFV) is one of those new topics that is gaining momentum and you may be left wondering: “what in the world is NFV?”
What is a Network Function Virtualization?
Traditionally, when you hear the word (perimeter) firewall, you think of a dedicated appliance/hardware that performs the firewall function and this appliance is installed (logically) at the edge of the network. Examples will be the Cisco ASA series and the Checkpoint firewall.
However, have you thought about what is inside that firewall appliance? Basically, you have the firewall software running on a custom, proprietary and usually expensive hardware from that vendor. So what are you really paying for? The function the device is performing or the hardware (plus brand name of the vendor)?
Side note: It can be argued that total cost of ownership (TCO) of a networking device should be favored over just the initial purchase value (capital expense). Vendors like Cisco claim that when TCO is used, then the deal they offer is not half as bad.
While it is true that it may be better to run custom-made hardware for certain functions (e.g. high packet switching that require purpose-built Application Specific Integrated Circuits (ASICs)), many organizations are experimenting with the fact that some network functions can be handled very well on standard servers that are less expensive and more readily available.
This is what Network Function Virtualization aims to do: separate the software (network function) from the hardware so that the network functions like Firewall, Deep Packet Inspection (DPI), Content Delivery Network (CDN), Virtual Private Network (VPN), can be run on industry standard servers, storage and switches using normal virtualization technologies.
Why NFV?
Let’s think for a moment about some of the benefits of virtualizing network functions. These benefits will be similar to the benefits provided by any virtualization technology. For example, if you have used VMware Workstation or VirtualBox, you know that such virtualization software (also known as Hypervisors) allow us to run several guest OSs/virtual machines on one host machine (depending on how much capacity the host device has).
In the same way, instead of having several boxes to serve as VPN gateways, using the NFV model, you can have one (or a couple) bare metal servers and storage and then create VPN gateway virtual appliances on this hardware. This will result in a couple of things:
About NFV
As mentioned earlier, NFV started out in the Telecommunications industry. Even though there are no standards for NFV yet, the big players joined forces in 2012 to create an Industry Specification Group (ISG) for NFV under the European Telecommunications Standards Institute (ETSI). This was done in a bid to move the dream of NFV forward and define specifications.
In 2013, this group released a high-level architectural framework for NFV which is broken down into three major parts:
These parts can be further broken down into different functional blocks. For example, the NFV MANO group contains blocks like the Virtualized Infrastructure Manager (VIM), the VNF Managers and the NFV Orchestrator. However, this article will not go into such technical details. You can read more about those blocks in the GS NFV 002 document already referenced.
Figure: High-level NFV Framework (source: ETSI GS NFV 002)
Relationship with Software Defined Networking
Another buzzword that has hit the networking industry in recent times is Software Defined Networking (SDN). The aim of SDN is to decouple the control plane from the data plane so that network control can be more easily programmed. As you can see, this is quite different from NFV. Therefore, it is important to note that NFV does not need SDN to work (and vice-versa) even though both technologies can complement each other. By virtualizing network functions (software), it becomes easier and less restrictive to apply SDN technologies.
A good example of how SDN and NFV can work together (along with the cloud) is the Central Office Re-architected as a Data Center (CORD) effort where traditional Telco Central Offices with legacy closed and proprietary hardware are replaced with software running on standard commodity servers (NFV) and these software are better managed and orchestrated as scalable services (SDN).
NFV in the real world
So far, we have looked at NFV as an abstract concept. However, NFV is already making gains in the world today and in this section, we will look at some examples under the three major blocks of the NFV architectural framework we discussed above.
Virtual Network Function (VNF)
Tip: Some of these VNFs are available on Amazon AWS e.g. Cisco and Juniper
Network Function Virtualization Infrastructure (NFVI)
NFV Management and Orchestration (MANO)
Lab Scenario: Running Cisco ASAv in GNS3
We can test out NFV by running the Cisco ASAv in GNS3. The process to do this is now more tightly integrated in GNS3 than before by using their GNS3 VM. To set this up, you need to have GNS3 installed, download and setup GNS3 VM, and then add the Cisco ASAv as an appliance to GNS3.
Note: You can run ASAv in VMware like you will run a normal virtual machine without using GNS3.
We will be using a simple lab setup containing one Cisco ASAv appliance and one PC as shown below:
After the ASAv boots up, we can use the show version command to view the details of this appliance:
Notice that I am running ASA software version 9.8 but the hardware type is ASAv.
To test that it works, I will configure an IP address on the ASA’s Gi0/1 interface and ping the IP address of the PC (192.168.1.100):
You should keep in mind that the Cisco ASAv does not (yet) support features like Clustering, Active/Active Failover and Multiple context mode.
Challenges of NFV
As with any technology, especially a relatively new one like NFV, there are a couple of challenges to be overcome. The first that should come to mind is Performance. Like we discussed in this article, one reason to go with a Cisco ASA box over pfSense is the fact that it comes in a dedicated hardware that has gone through rigorous performance tests. Would off-the-shelf hardware used in NFV be able to match the performance of application specific hardware? The jury is still out on that and only time will tell. However, companies like Facebook seem to be willing to take the risk and have been building their own hardware for a while now.
A closely related challenge with running virtualized network functions on commodity servers will be that of Support. If a problem occurs on the network and it is not clear if it is a software or hardware fault, who takes responsibility for the solution? The hardware providers (NFVI) or the software providers (VNFs)?
Another challenge is that of Interoperability. Due to the “open” nature of NFV, an organization may need to run VNFs created by one vendor on top of virtual machines/hardware created by a different vendor. Standardized and open interfaces (e.g. APIs) that facilitate seamless integration will need to be developed.
Currently, organizations are running network functions in the traditional manner – hardware and software tightly coupled together. Since the move to NFV will not happen all at once (and a complete move may not even happen at all), another thing to consider is Coexistence. The new virtualized network functions (which ideally will be designed around open standards) must be able to work with and be compatible with the legacy systems (usually closed source) already in place.
Other challenges include Management, Security, Stability and Automation.
Summary
Original Equipment Manufacturers (OEMs) like Cisco and Juniper had a hold on the Telecommunications market for a long time with their proprietary devices. Since Network Function Virtualization (NFV) allows network functions to be run on standard hardware using virtualization technology, the market seems to be using NFV to take that OEM hold off.
NFV offers several benefits like the potential for reduced capital and operating expenses, scalability and the ability to roll out new services quicker. However, there are also challenges to be overcome including performance issues, interoperability and compatibility issues, management, security and so on.
Several products already exist that can be classified as being in the NFV space including the Cisco Cloud Services Router (CSR), Juniper vSRX Virtual Firewall, VMware vCloud NFV and so on.
NFV is gaining a lot of momentum especially among big service providers and it seems those who will be affected most are the OEMs like Cisco. However, those OEMs are also revamping their products and services and are trying to retain their top spot even in this new NFV market. Good for them.
Adeolu Owokade
What do you think about this article?
About us
RouterFreak is a blog dedicated to professional network engineers. We
focus on network fundamentals, product/service reviews, and career advancements.
Disclaimer
As an Amazon Associate, I earn from qualifying purchases.
RouterFreak is supported by its audience. We may receive a small commission from the affiliate links in this post, at no extra cost to our readers.
Topics
Recommended
Popular articles