Network Virtualization as I understand it

For some reason, I had a difficult time with the basic concept of Network Virtualization. VMware equates network virtualization to Server Virtualization. With server virtualization you can deploy an application to any physical server in your environment easily because the Server OS that the application resides on is abstracted from the network. This gives you an incredible amount of flexibility operationally. You can easily manage OS images, clone virtual machines, create entire test environments with almost a push of a button. With a Hp Memory Module 809082-091 16GB you’ll be able to save all of your adjustments and make sure that your NV is working at its best capacity. It streamlines server deployments because you can now deploy servers based on templates with almost no regard to the underlying hardware. If you are managing network hardware, you may wish to get some information from Viavi Solutions regarding components such as PCIe.

I’ve done server virtualization long enough that I just get it. It seems natural to this point. What doesn’t seem as natural is Network Virtualization. I re-read the VMware post announcing the NSX product and it all kind of just clicked for me. I had a problem disassociating the physical access layer with the abstracted network component. After all it makes sense that the device that the port is connected to is the device that controls the behavior of the device of the network. This is useful to know when exploring network device monitoring which can be important if you’re interested in having a more comprehensive understanding of your network workflow of your next better. You could also use network monitoring application to keep an eye on your network, but I digress.

Source VMware
Source VMware

The Physical Infrastructure really is just that that the physical infrastructure. It’s the assurance that every device is physically connected to the network. It can be via Token Ring, Frame Relay, Ethernet or ATM. In theory it can even be a overlay network. It really doesn’t matter from a logical perspective. You have to ensure that the physical infrastructure is reliable and meets the latency requirements of your applications but that’s it (maybe a bit oversimplified). Now that there is physical connectivity a solution like NSX can take over. You create virtual ports and associate them to physical ports or other virtual ports on virtual switches. These virtual ports can then be assigned to a virtualized Firewall, Switch, Router or IDS ports based on the need.

Cisco has a similar device level approach with their ISR architecture. A port on an ISR router can be an IDS, Firewall or Router port as examples. Network virtualization just takes the abstraction one level higher and broadens the capability of each individual port. You now eliminate physical limitations of the device and virtualization the capability of the port.

The virtualized network devices can then have all the characteristics we associate with server virtualization. They can be cloned, copied, vMotioned, DRS’d and snapshot. Many of the operational advantages associated with server virtualization is now available to us on the network. The only requirement again is that there is physical connectivity and VMware is able to do the easy part which is create a network Hypervisor capable of creating the robust abstraction layer needed to manage all of these dynamic ports. I can see a pretty significant challenge in creating a high speed/low latency fabric. I can also see where troubleshooting physical vs. logical performance will be a challenge. However, these were some of the same challenges server virtualization faced during the early years as well.

I haven’t been excited by networking since I got a sample loaner Gigabit switch back in 2001 from Cisco. This is actually a pretty big deal and I look forward to seeing a shipping product from VMware and customer feedback. Your thoughts… is this an operation model that translates to your network?

Related Posts

Network Virtualization vs. SDN

Published by Keith Townsend

Now I'm @CTOAdvisor

10 thoughts on “Network Virtualization as I understand it

  1. If you had asked me 3 years ago if I would expect virtual appliances to be a reality soon, I would probably have answered: I don’t know, but maybe some day.

    In the past few years, there were hints that it would be realistic. Now, if you ask me, I’d say it is obvious:

    I have a feeling the people working on just the servers don’t usually have much of an idea of how much goes into networking.

    But I think there is a chance of simplifying it, before we start to make things more complicated again. As I mentioned in an other post there are things like AWS CloudFormation (and the OpenStack equivalent Heat and tools from specialized companies) which are templates for cloud depoyment and auto-scaling of applications.

    It looks like OpenStack is planning to use their own tooling to deploy OpenStack. Even automatically deploying it on baremetal. In that case OpenStack own services will be deployed in HA-setup from the start and automatically scale when it is needed.

    I hope application developers and the developers of PaaS solutions will include such a template by default. People have already made them for a number of PaaS solutions.

    Application specific network configuration is part of these templates. People who want to deploy the applications can then change these templates to fit their access-controllists, vpns or connect it to their federated authentication system and so on.

    1. Two really good links. One of the nagging questions about vShield has been throughput for functions such as total number of transactions per second versus raw throughput. VM’s behind the vShield appliance that have a higher level of transactions can suffer vs. VM’s behind a hardware based FW. My questions around Network Virtualization is basically scale. I get that Network Virtualization is a feasible idea with plenty of merit but if you create a virtual switch across a physical infrastructure you will be limited by both the interconnect between the physical connection and the overhead associated with the hypervisor. I can see use in smaller environments without low latency needs but scaling it to Cloud Provider levels can be a challenge.

      The first link really goes into some good detail on scaling solutions for really big implementations. I agree it’s feasible and the challenge will be solving problems versus just providing a solution to a perceived academic solution. The argument from the academics is that networks are too complex to manage (I don’t disagree) and that abstraction is the solution to the problem. Traditional networking interests seem to think better protocols or implementation of protocols is the solution. I think this is one area that the market will decide.

    2. Maybe I should eleborate, I don’t know if the enterprise will really embrase the cloud, private or otherwise or if the cloud will just accomodate for running ‘pets’.

      I think the cloud model could make it easier for the developers and also for the enterprise, but they will need to understand the advantages and have a willingness to learn and adopt.

      1. I agree. I do think they will adopt some of the best practices for running large scale data centers from the lessons learned from Cloud Providers. Server Virtualization is obviously a no brainer. The questions are around new operation models for networks. Be it device focused such as Cisco ONE or virtual/SDN based.

      2. Virtualization overhead/latency is going to be solved. I’m not worried about that at all.

        Especially if the application architectures are more build for scale out instead of scale up.

        If there are exceptions, they will run on bare metal or bare networking hardware. Just like now with certain databases.

        And you can even get baremetal in the cloud.

        I guess it is the usual answer, people in consulting will always give you: it depends on the application/requirements

  2. Virtualization as a whole can be confusing to the organizations that could benefit from it the most. This is why there is still hesitation in moving to the cloud.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: