I remember when I first started working with IT and heard the term “virtual” for the first time. When I tried to understand what it was and how it worked, it was like magic. I couldn’t see it, yet something was working in the background like magic to do good or bad deeds without my knowledge!
This was in the era where you physically had to put “jumpers” on hardware to tell a CPU or Motherboard where interface-cards were actually located. Just imagine the leap from this to the "virtual world."
It sounded crazy, too good to be true—even like madness. Just pause for a moment and consider this thought from a skeptical mind such as myself (and I was extremely skeptical):
What if someone told you in the early 1990’s that there was a way to run multiple instances of anything . . . sharing the same hardware . . . using the same resources as other instances . . . yet separate them at a logical level in what they called a “virtual world”.
These were crazy thoughts from brilliant minds that eventually figured out a way to do exactly this.
But I was still skeptical. Time and time again I had been proven that even running multiple applications on a single server or system was usually a root-cause for long sleepless nights. Later in early 1999 these brilliant minds released the first commercial product called a “virtualizer” for the x86 platform. We know them today as “VMware”. And the rest is as we say . . . history!
The (personal) definition of virtualization:
"It’s the use of software to make it behave like hardware." It's really that simple.
Virtualization Changed Everything
As an engineer you should be very skeptical about change, since most things that work suddenly don’t work after a change. And, as many times before, my skeptical thinking proved me right—but only in the very beginning! Virtualization turned out to be extremely unstable, and it just wasn’t good enough to be useful. However, this was quickly fixed, and before I could figure out the “magic” behind Virtualization, companies where investigating this new technology everywhere.
Because it *literally changed everything* for the IT-industry.
For the first time, it was possible to utilize all the available hardware resources to support your business needs! You could simply just buy enough hardware resources needed for your applications and install all your applications on top of a single server. Needless to say, this changed everything.
But it didn't stop there. Today, virtualization is what makes it possible to move servers around "in the cloud." It enables extreme redundancy, quick disaster recoveries, smart power-saving techniques, extreme flexibility in network designs, enforcing security policies that were not possible before, and so much more that just isn't possible in the physical world!
Why Virtualization Changed Everything
Even though virtualization was meant to be used to simulate x86 hardware using software in order to better utilize hardware resources for server applications, this technology was soon adopted over the upcoming years to the rest of the IT-industry.
So, without virtualization, you would not be able to build a modern data center that can include common technologies, such as:
- Multiple Spanning-Tree topologies
- Virtual network devices
Virtual network devices. Doesn’t that sound cool to you?
It should! Because this is probably the number one reason why virtualization changed everything to network engineers!
But, all of the above technologies are in some way a virtualization technology. They all use specially crafted software that acts like real hardware.
In today's networks, it’s even common to run “Virtual-in-Virtual,” which basically means that you run a virtual instance inside another virtual instance. Cisco uses this with, for example, Cisco VIRL PE. The possibilities today are probably endless, and I keep finding new use cases almost every month!
Why All This Matters to Network Engineers
Without virtualization technology, we would not be able to design and operate networks to meet the very complex demands that an IT infrastructure requires today!
You may think of yourself as a network engineer, but maybe you should stop for a while and think about if your day-to-day work isn’t a “virtualization engineer” instead.
As a network engineer (especially as a designer), you need to consider some basic network devices that you may need to use in order to meet a requirement:
- Network Management
- …hopefully Automation & Orchestration systems.
All of the above network devices can be virtualized and installed as a “virtual appliance or server.” The configuration and operational aspects might be your day-to-day standard tasks, but to actually implement the above devices as a "virtual" version requires a totally different approach.
First of all you need to be extremely careful with your investigation about how many resources you need. This is very easy in the “physical,” world but much more difficult in the “virtual” world.
For example, what happens to a physical switch if you disable STP and end up with a L2-loop? Do you assume that STP works the same in a virtual switch as in a physical switch? WRONG! Although they achieve the same result, they are not implemented in the same way for very good reasons.
What about firewalls? You can fairly easily just get the hardware specifications from any vendor and figure out if they meet your needs or not. But consider this—what if you decide to implement 3DES instead of DES for your IPSEC-tunnels? On a physical firewall, chances are that your throughput would drop a bit, and depending on other features you currently run, nothing might happen. To overcome this problem you have to choose between enabled features or simply replace it with better hardware. What about a virtual firewall? It would most likely just be a matter of assigning more hardware resources to your virtual firewall in order to better handle the extra load.
What about load-balancers? They usually want to use a VIP (Virtual IP-address) and in most cases manipulate source or destination headers. In a physical appliance there are strict ways for how to cable them and how to connect them to your other network infrastructure. Do you assume that you connect them the same way to your virtual-switch? WRONG! A virtual network doesn’t follow the same forwarding rules as a physical switch or a physical firewall, and therefor you need to implement it differently in the virtual world.
What about simple things such as “load-balancing” protocols (LAcP or PAgP)? In any sane network you would want to use a “load-balancing protocol” to/from your server. You are used to connecting 2xNICs to your physical switch and then running LAcP to bundle them together. Typically you want to use the same procedure for the server that runs the virtualization software in order to spread the load going to/from all the servers inside the hypervisor. The problem? You may have tons of virtual network devices inside your little server. And run 100s of servers and virtual-storage-systems inside your little server. It’s not easy to make all this work together, and the important thing to remember is that things just don’t work the same way in the virtual world as in the physical world.
For example all major virtualization software vendors have their own specialized load-balancing techniques inside their virtualization software. These can cause a lot of troubles in your physical network infrastructure unless you learn how they work and operate inside the virtual world.
A simple example would be, do you want to present the virtual-NIC to your physical switch as the source-MAC-Address?
Or do you want to present the physical NIC of the server where the cable is connected to your physical switch as the source-MAC-Address?
Depending on your choice, you might “break” or “fix” your network. MAC-FLAP is one of the worst things a network can experience, and it can really destroy a well-designed network.
Connecting the virtual world to the network is getting more and more complex, and that’s why you—as a network engineer—need to care about virtualization!
So Virtualization Changed Everything—What Now?
Without a doubt, no other technology had a greater impact on the IT industry since the dawn of The Internet than Virtualization. We are virtualizing everything we can, and we try to squeeze more and more technology into smaller and smaller boxes.
Cisco is no different—they are among the best in the IT industry to adapt to changes and find creative ways to give us options of how to continue to operate the complex world that a network is today!
It’s my personal belief that virtualization will move closer and closer to the edge of the users in a network, and we are already discussing and looking into things that would have been impossible without virtualization.
We have been using tunneling techniques for over a decade (yep, virtualization!) to segment our networks. These techniques are now being pushed almost down to the end user and, in rare cases, even all the way down to clients that are now running a virtualized-desktop (VDI Infrastructure) that talks directly to the network.
I’ll repeat myself: Virtualization *literally changed everything*.
So to end this blog post, I will list some use cases you should be aware of that require knowledge about virtualization. Because sooner or later you will find yourself having to deal with these.
Isolation of API-calls on Cisco Switches/Routers and other hardware. This is achieved by virtualization that separates the external API-calls from the internal API-calls so that in case something bad happens, it will only consume the resources assigned for this task. Not to forget the fact that this also provides security!
Software-Defined Networking - although not a virtualization technology by itself, the purpose with many of Cisco’s SDN technologies rely on using virtualization to build the network you define. It's common knowledge that a branch site might need switches, routers, firewalls, Load-Balancers, Syslog-servers, etc. to enforce company policies. SDN helps us implement the complex policies, but virtualization is what makes this possible in the end!
Containers can now be run directly on top of Cisco Switches/Routers and other hardware. This means that instead of using SPAN/ERSPAN/RSPAN, you can now install a Wireshark client running directly on the end user access switch to do your inline packet captures for you. As if this wasn't enough, you can even set up your own application running in-line with your network if you have other requirements than a simple packet capture.
Multi-Tenant Networks - where multiple corporations with different business needs uses the same shared infrastructure. This is impossible to achieve without extreme use of virtualization to segment every different tenant to meet their business requirements. Unless you work with a data center, this is pretty rare to see at offices. But even offices are getting more and more complex, and if we can be bold to mention Cisco SDA . . . This is happening even at the smallest offices!
Service Providers - Without extreme use of virtualization, most service provider networks would not be able to run the way they do today. For any service provider, it's a business requirement to be able to use their infrastructure to provide the same services everywhere to multiple customers, even if they are physically located at the same office.
Flexible Q&A Environments - It's so easy to test applications before putting them in production today. Without virtualization, you would need a physical copy of your production servers and networks to do all your testing. Today even networks can be tested in a fully virtualized environment before being implemented. This made it possible to make sure that you have a completely isolated lab where everything can go wrong without affecting the production network.
This was just a small touch of the virtual world that we live in. A deep dive requires additional posts for the future. For now I hope that I have raised your interest about virtualization so that YOU can be ready for the future that uses virtualization technologies more and more for every week that passes!
If you are interested in learning more about Cisco's SDN solutions that use a lot of virtualization, be sure to read more about:
- ACI (Data center)
- SD-WAN (Service provider)
- SD-Access (Network Edge)
They are soon going to be a main requirement for a network engineer, since networks are getting so complex that it's not going to be possible to manage them without software!