It’s Time to Stop Using the Term Network Function Virtualization (NFV)

I think it’s time to stop using the term “network function virtualization”. Why? Because it doesn’t exist, at least not in the way the term suggests. The term is a category error, and when people try to make sense of the term, confusion and frustration ensue.

Think of it like this: what’s the difference between a “virtual network function” and a “non-virtual network function”? For example, how is “virtual IP forwarding” different than “non-virtual IP forwarding?” Answer: it’s not.

So what then exactly is network function virtualization?

The Right Idea, The Wrong Term

The European Telecommunications Standards Institute, which arguably coined the term NFV, said the following in a 2012 whitepaper (emphasis mine):

Network Functions Virtualisation aims to address these problems by leveraging standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers

Look at the bold text. How does one consolidate many network equipment types onto commodity servers? Let’s add some specifics to make it more concrete. How does one consolidate a firewall, router, switch, and load-balancer onto a server? By implementing those network functions in software and putting that software on the server.

But here’s the problem with calling that “network function virtualization”: virtualization has nothing to do with implementing network functions in software. In the early days of the Internet, routers (gateways as they were called back then) ran on commodity x86 machines with no virtualization (with the exception, maybe, of virtual memory).

Network functions don’t need virtualizing, and in fact, can’t be virtualized. But the term NFV suggests otherwise.

And that’s where the confusion started….

NFV is like dividing by zero: undefined

Conceptually, NFV is just implementing network functions in software. That’s easy enough to understand. And yet it’s hard to find an actual definition of it anywhere. Instead, you’ll see a lot of hand-wavy things like this:

NFV is a virtual networking concept…
NFV is a network architecture concept that uses the technologies of IT virtualization…

Hence the letters “N” and “V”. And then you have those who gave up on a definition and just went straight for the marketing lingo:

NFV is the next step…
…is the future…
…is the progression/evolution…

Others get closer by hinting at what NFV does, but stop short of actually saying what it is:

NFV consolidates multiple network functions onto industry standard equipment

This seems to be pretty close, but where’s the virtualization part come in? Let’s try this blurb from Angela Karl at TechGenix:

[NFV lets] service providers and operators… abstract network services, including things such as load balancing, into a software that can run on basic server.

Bingo. NFV is not virtualizaton at all. It’s an abstraction of network functions!

NFV is Abstraction, not Virtualization

Before you accuse me of splitting hairs, let me explain the distinction between virtualization and abstraction. Put simply, virtualization is an imitation, while abstraction is a disguise.

Virtualization is an imitation

When you virtualize something, you’re creating an imitation of the thing you’re virtualizing.

For example, when you create a virtual disk in your favorite hypervisor, you’re hiding the characteristics of the underlying storage (disk geometry, partition info, formatting, interface, etc.). But in the same motion, you give the virtual disk the same types of characteristics: disk geometry, partition info, formatting, interface, and so on. To put it in programming lingo, the properties are the same, but the values are different.

Virtualization preserves the underlying properties and doesn’t add any property that’s not already there. Have you ever pinged a virtual disk? Probably not, because virtual disks, like real disks, don’t have network stacks.

Virtualization also preserves the behavior of the thing being virtualized. That’s why you can “shut down” and “power off” virtual machines and “format” and “repartition” virtual disks.

Now try fitting NFV into this definition of virtualization. How do you “virtually route” or “virtually block” a packet? It’s a category error.

Abstraction is a disguise

When you create an abstraction, you’re creating a disguise. Unlike virtualization, with abstraction you’re changing some of the properties of the thing you’re abstracting. You’re taking something and dressing it up to look and act completely different.

Swap space is a good example of an abstraction. It’s data on storage that looks and acts like random access memory (but way slower). Before the days of SSDs, swap was stored on spinning disks which were read and written sequentially. This is completely different than memory which can be read and written randomly. Swap space is a file (Windows) or partition (Linux) disguised as RAM.

The Case for Abstracting Network Functions

Let’s bring this around to networking. What’s it mean to abstract network functions like IP routing and traffic filtering? More importantly, why would you want to? Why not just use virtual routers, switches, and firewalls?

Simply put, virtualized network devices don’t scale. The reasons for this are too numerous to list here, but suffice it to say that TCP/IP and Ethernet networks have a lot of built-in waste and aren’t the most efficient. This is why cloud providers do network function abstraction to an extreme. It’s utterly necessary. Let’s take Amazon AWS as an example.

In AWS, an instance has a virtual network interface. But what’s that virtual network interface connected to? A virtual switch? Nope. Virtual router? Try again. A virtual firewall. Negative. Virtual routers, switches, and firewalls don’t exist on the AWS platform. So the question remains: what’s that virtual NIC connected to?

The answer: nothing. The word “connected” here is a virtual concept borrowed from the real world. You “connect” NICs to switches. In your favorite hypervisor, you “connect” a vNIC to a vSwitch.

But there are no virtual switches or routers in this cloud. They’ve been abstracted into network functions. AWS presents this as if you’re connecting a virtual interface to a “subnet” rather than a router. That’s because AWS has abstracted IP routing away from you, leaving you with nothing to “connect” to. After all, we’re dealing with data. Not devices. Not even virtual devices. So what happens? The virtual NIC passes its traffic to some software that performs network functions. This software does a number of things:

  • Switching – It looks at the Ethernet frame and checks the destination MAC address. If the frame contains an ARP request seeking the default gateway, it replies.
  • Traffic Filtering – If it’s a unicast for the default gateway, it looks at the IP header and checks the destination against the security group rules, NACLs, and routing rules.
  • Routing – If it needs to forward the packet, it forwards it (although forwarding may simply consist of passing it off to another function.)

This is a massive oversimplification, of course, but you get the idea. There’s no reason to “virtualize” anything here because all you’re doing is manipulating bits!

Overvirtualizing the Network

It’s possible to over-virtualize. To give an analogy, suppose you wanted to write a calculator application (let’s call it a virtual calculator). You’d draw a little box with numbers and operators, and let the user click the buttons to perform a calculation. Now imagine that you also decided to write a “virtual hand” application that virtually pressed buttons on the virtual calculator. That would be ridiculous, but that’s essentially what happens when you connect two virtual network devices together.

There an especially great temptation to do this in the cloud. Folks may spin up virtual firewalls, cluster them together, connect them to virtual load-balancers, IDSes, and whatnot. That’s not bad or technically wrong, but in many cases it’s just unnecessary. All of those network functions can be performed in software, without the additional complexity of virtual NICs connecting to this and that.

The Difference Between a Virtual Network Device and a Network Function

When it comes to the cloud, it’s not always clear what you’re looking at. Here are some questions I ask to figure out whether a thing in the cloud is a virtual device or just a abstracted network function:

Is there an obvious real world analog?

There’s a continuum here. An instance has a clear real world analog: a virtual machine. An Internet gateway sounds awfully like the router your ISP puts at your site, but “connecting” to it is a bit hand-wavy. You don’t get a next-hop IP or interface. Instead, your next hop is igw- followed by some gibberish. That smacks of an abstraction to me.

Can you view the MAC address table or create bogus ARP entries?

If  you can, it’s a virtual device (maybe just a Linux VM). If not, it’s likely some voodoo done in software.

Can you blackhole routes?

In AWS you can create blackhole routes, although people usually do it by accident. You can create a route with an internet gateway as a next hop, then delete the gateway. But can you create a route pointing to null0? If not, you have an abstraction, not a virtual device.

Does the TTL get decremented at each hop?

A TTL in an overlay can get decremented based on the hops in the underlay. But what I’m talking about here is not decrementing the TTL when you normally would. AWS doesn’t decrement the TTL at each hop. If you were to get into a routing loop, you’d have a nasty problem. Hence, AWS doesn’t allow transitive routing through its VPCs. So if your TTLs don’t go down at each hop, as with AWS, you’re probably dealing with an abstraction.

 

Visual Studio Code as a PowerShell Integrated Scripting Environment

I know what you’re thinking. “Why use Visual Studio Code instead of the PowerShell ISE?” Well, if you’re using Mac OS or Linux, you don’t have the option to use the PowerShell ISE natively. And that’s a problem if you want to take advantage of the cross-platform capabilities of PowerShell Core. In this article, I’ll show you how to use Visual Studio Code (free!) to perform the key functions of the PowerShell ISE, namely:

  • Simultaneously view code and execute it in the PoSh terminal
  • Execute code on a selection or line-by-line basis (F8)
  • Syntax highlighting (for people who are easily bored like me)

Installing Visual Studio Code

The best way to install most things is with a package manager. This would be something like apt-get or yum for Linux distros, homebrew for Mac OS, and Chocolatey for Windows. Or you could go old school and download it here.

Installing the PowerShell Extension

Go to the Extensions button (looks like a busted up square) or View > Extensions.

If the PowerShell extension doesn’t show up under the bombastic “RECOMMENDED” heading, just search for it in the “Search Extensions” field. Then install it.

Integrating the PowerShell Terminal

Open up a PowerShell script of your choice. Then in the menu, go to View > Integrated Terminal. You should see the following.

If you don’t see the PS prompt Make sure you select “TERMINAL” and “PowerShell Integrated” from the drop-down menu.

Running Only Selected Code

In the PowerShell ISE, you can select a block of text and hit F8, and the ISE runs only that code. Or you can position your cursor at the end of a line and hit F8, and the ISE runs only the code on that line. Next we’ll enable the exact same behavior in Visual Studio Code.

Go To File > Preferences > Keyboard Shortcut

In the text entry field at the top, type “runsel”. You should see two items:

  • “Run Selection” with a keybinding to F8
  • “Run Selected Text In Active Terminal” with no keybinding

This is not what we want because it will not run the selected text in the PowerShell terminal. It will run the selection in the “OUTPUT” section, but not in the terminal. Obviously, that’s not the normal behavior of the PowerShell ISE. Let’s fix it.

Right-click the “Run Selection” item and select “Remove keybinding”

Right-click the “Run Selected Text in Active Terminal” item and select “Add Keybinding”

Depress the F8 key (or whatever you want to use) then hit Enter.

Testing It Out

Go back to your code and select a block of code. Hit F8 and watch the magic!

That’s what I’m talking about!

But… as of this writing, there’s an issue with this that’s being tracked on the vscode-powershell GitHub repo, and it’s this: multi-line input in the integrated console doesn’t work. That means you can’t select a function block, hit F8, and have it work. It will throw ugly errors in your face.

Why People Still Haven’t Adopted IPv6 (And Why You Should Learn It Anyway)

It’s 2017, and if you haven’t learned IPv6 yet, well, you’re not the only one. In December 2016, IPv6 turned 18 years old. Children who were in the womb when RFC 2460 was being drafted are now old enough to vote, get married, and purchase firearms in some states.

In honor of IPv6’s 18th birthday, allow me to share my theories on why people have been so slow to adopt IPv6. And why you still should consider learning it.

The “Lame name” theory

IPv6 terminology makes it sound like a new version of IPv4 and it’s not. It’s a totally different protocol with a similar name. If you’re familiar with the confusion between Java and JavaScript, you know what I’m talking about. People who set out to learn IPv6 are disappointed when they find out it’s almost nothing like IPv4.

The “Let’s split DHCP in half and spread its most popular functions across two protocols” theory

DHCP for IPv4 can provide clients with IP addresses, DNS servers, default gateways, TFTP servers, and pretty much anything else. DHCPv6 doesn’t have an option for providing a default gateway. If you want to push a default gateway to IPv6 clients, you have to use SLAAC.

The “all things to all people, places, animals, plants” theory

IPv4 has only a few address types that anyone actually uses. Colloquially, they’re public, private (RFC 1918 addresses like 192.168.1.1), and multicast (which includes broadcast). IPv6 has approximately one zillion different address types, including unique-local, link-local, unspecified, and global unicast. Although there are technical justifications for some of these, the plethora of address types makes no sense to anyone who doesn’t deeply understand why “layer 2” is even in the IT lexicon.

The “IPv4 apocalypse” theory

We’ve all heard the constant chicken-little talk about how we have to move to IPv6 yesterday or the internet will die. Driving this is the myth that all IPv4 addresses are gone. They’re not, and the U.S. government is sitting on tens of thousands it’s never going to use. What really happened was that in 2011, the Internet Assigned Numbers Authority (IANA) assigned the last of its available IP address space to regional internet registries (RIRs) which are responsible for doling out addresses. But the IPv4 addresses didn’t just go away. They still exist, and many of them are unused and can be reassigned.

The “NAT is a tool of the devil” theory

If you ever want to have fun, go on any IT forum and ask, “Why do we need IPv6 when we have NAT?” Actually, don’t. That would be trolling. But if you were to ask that question, you’d probably get a few responses hating on IPv4 NAT as a tool of the devil, which IPv6 will save us from… except it does NAT, too.

The “Why do I need both again?” theory

Implementing IPv6 almost always requires a multihomed (dual-stack) implementation, which people figured out about 30 years ago was a bad idea with IPv4 because it confuses everybody. IT admins translate this as, “More work for me.”

The “Because we can” theory

There are enough IPv6 addresses for every cell in your body to have its own internet. Seriously? This, like NAT, is another non-reason to adopt it. Yes, it’s cool that I can give my Uncle Milton’s ant farm its own Internet. But as far as business justification goes, nope.

Why you might want to learn IPv6 (hint: money)

Although IPv6 has been poorly marketed, it’s still worth learning. In fact, I believe in IPv6 so strongly that I’ve created several Pluralsight courses on configuring and troubleshooting it.

Here are three big reasons to consider adding IPv6 to your set of skills:

  • It’s is like a sports team. The big boys are rooting for it. I’m talking about Cisco, Juniper, ISPs, Google, et alia. They want to see it win, and they’ll pay to make it happen. If you know IPv6, you can be on the receiving end of some of those payments.
  • The confusion and complexity around IPv6 has made experts that much more valuable to companies who have already invested in IPv6 infrastructure.
  • If you know IPv4, IPv6 isn’t that hard to learn once you realize that it’s a distinct protocol and not a new version of IPv4.

For further IPv6 learning, check out my Pluralsight courses:

Troubleshooting IPv6 at the desktop:

Practical Networking

Configuring and troubleshooting IPv6 on Cisco routers:

Basic Networking for CCNP Routing and Switching 300-101 ROUTE
Troubleshooting Cisco Networks: IPv6 Routing Protocols for CCNP R&S 300-135 TSHOOT

Building Windows Server with Puppet and Chocolatey

Forget using scripts and group policies to configure a new Windows Server machine. Using Chocolatey and Puppet, you can do it faster & easier than ever (and it’s more fun too). This is especially true if you’re using a Server Core installation and don’t have a GUI to help you along. Oh, and if you don’t know Puppet, you really should watch my course Puppet Fundamentals for System Administrators on Pluralsight 🙂

Assign IP address using PowerShell:

$ New-NetIPAddress –InterfaceAlias "Ethernet" –IPAddress "192.168.51.29" –PrefixLength 24 -DefaultGateway 192.168.51.8

$ Set-DnsClientServerAddress -InterfaceAlias “Ethernet” -ServerAddresses 192.168.50.20, 192.168.50.21

Install Chocolatey:

$ set-executionpolicy unrestricted
$ iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

Restart PowerShell

Install VMware tools

$ choco install vmware-tools

The server will automatically restart.

Rename server

$ rename-computer -newname newservername

Reboot

restart-computer

Join to domain
add-computer -domain benpiper.com

Reboot again
restart-computer

Install Puppet
choco install puppet

Configure Puppet
Configure c:\programdata\puppetlabs\puppet\etc\puppet.conf

Generate puppet certificate
puppet_interactive

Sign puppet certificate on puppet master
puppet cert sign newservername

Apply appropriate profiles to server. Remember to restart the Puppet master if you change your Hiera configuration.

Run Puppet agent
puppet_interactive

Verify
puppet resource dism
puppet resource package

Citrix Web Interface 5.4: Error occurred while making the requested connection

I recently ran into a bizarre issue with users not being able to launch applications from a very old Citrix Presentation Server 4.0 farm when trying to launch from Citrix Web Interface 5.4. They were getting the eminently unhelpful, “An error occurred while making the requested connection.”

In the web interface application logs, I noticed this:

An error of type IMA with an error ID of 0x80000003 was reported from the Citrix XML Service at address (servername)

And this:

The farm MyFarm has been configured to use launch references, but a launch reference was not received from the Citrix XML Service. Check that the farm supports launch references or disable launch reference requests.

To resolve this, I modified C:\inetpub\wwwroot\Citrix\XenApp\conf\WebInterface.conf on the Web Interface servers and changed the RequireLaunchReference directive as follows:
RequireLaunchReference=Off
(It was set to On)

And it worked. Supposedly, that directive must be set to Off when using Web Interface 5.4 with PS 4.0. But, I’ve been running for years with it set to On and it worked fine until recently. Another Citrix mystery.

Want more Citrix tips and tricks? Watch my course Citrix NetScaler 10: Design and Deployment!