This post will be the first in a series that examine what I think are some of the powerful security capabilities of the VMware NSX platform and the implications to the data center network architecture. In this post we’ll look at the concepts of Zero Trust (as opposed to Trust Zones), and virtualization-centric grouping (as opposed to network-centric grouping).
Note: Zero Trust as a guiding principle to enterprise wide security is inspired by Forrester’s “Zero Trust Network Architecture”.
We want to be able to secure all traffic in the data center without compromise to performance (user experience) or introducing unmanageable complexity. Most notably the proliferation of East-West traffic; we want to secure traffic between any two VMs, or between any VM and physical host, with the best possible security controls and visibility – per flow, per packet, stateful inspection with policy actions, and detailed logging – in a way that’s both economical to obtain and practical to deploy.
Until now, it hasn’t been possible (much less economically feasible or even practical) to directly connect every virtual machine to its own port on a firewall. Because of this, the Continue reading
This post will be the first in a series that examine what I think are some of the powerful security capabilities of the VMware NSX platform and the implications to the data center network architecture. In this post we’ll look at the concepts of Zero Trust (as opposed to Trust Zones), and virtualization-centric grouping (as opposed to network-centric grouping).
Note: Zero Trust as a guiding principle to enterprise wide security is inspired by Forrester’s “Zero Trust Network Architecture”.
We want to be able to secure all traffic in the data center without compromise to performance (user experience) or introducing unmanageable complexity. Most notably the proliferation of East-West traffic; we want to secure traffic between any two VMs, or between any VM and physical host, with the best possible security controls and visibility – per flow, per packet, stateful inspection with policy actions, and detailed logging – in a way that’s both economical to obtain and practical to deploy.
Until now, it hasn’t been possible (much less economically feasible or even practical) to directly connect every virtual machine to its own port on a firewall. Because of this, the Continue reading
This post will be the first in a series that examine what I think are some of the powerful security capabilities of the VMware NSX platform and the implications to the data center network architecture. In this post we’ll look at the concepts of Zero Trust (as opposed to Trust Zones), and virtualization-centric grouping (as opposed to network-centric grouping).
Note: Zero Trust as a guiding principle to enterprise wide security is inspired by Forrester’s “Zero Trust Network Architecture”.
We want to be able to secure all traffic in the data center without compromise to performance (user experience) or introducing unmanageable complexity. Most notably the proliferation of East-West traffic; we want to secure traffic between any two VMs, or between any VM and physical host, with the best possible security controls and visibility – per flow, per packet, stateful inspection with policy actions, and detailed logging – in a way that’s both economical to obtain and practical to deploy.
Until now, it hasn’t been possible (much less economically feasible or even practical) to directly connect every virtual machine to its own port on a firewall. Because of this, the Continue reading
In this post I share the slides, audio recording, and short outline of a presentation I gave at the Melbourne VMUG conference (Feb 2014) called “Three reasons why Networking is a pain in the IaaS, and how to fix it”.
As network technologists we know that when the compute architecture changes, the network architecture changes with it. Consider the precedent. The transition from mainframe to rack servers brought about Ethernet and top-of-rack switches. Blade servers introduced the blade switch and a cable-less network. And of course the virtual server necessitating the software virtual switch and a hardware-less network. At each iteration, we observe the architecture change occurring at the edge, directly adjacent to compute.
We can look at this superficially and say, “yes, the network architecture changed”. However if you think about it, the catalyzing change in each shift was the operational model, with intent to increase agility and reduce costs. The architecture change was consequential. Without compute, there is no reason for a network. Networking, both as a profession and technology, exists as a necessary service layer for computing. Without a network, computing is practically useless. As such, the capabilities of the network will either enable or impede Continue reading
In this post I share the slides, audio recording, and short outline of a presentation I gave at the Melbourne VMUG conference (Feb 2014) called “Three reasons why Networking is a pain in the IaaS, and how to fix it”.
As network technologists we know that when the compute architecture changes, the network architecture changes with it. Consider the precedent. The transition from mainframe to rack servers brought about Ethernet and top-of-rack switches. Blade servers introduced the blade switch and a cable-less network. And of course the virtual server necessitating the software virtual switch and a hardware-less network. At each iteration, we observe the architecture change occurring at the edge, directly adjacent to compute.
We can look at this superficially and say, “yes, the network architecture changed”. However if you think about it, the catalyzing change in each shift was the operational model, with intent to increase agility and reduce costs. The architecture change was consequential. Without compute, there is no reason for a network. Networking, both as a profession and technology, exists as a necessary service layer for computing. Without a network, computing is practically useless. As such, the capabilities of the network will either enable or impede Continue reading
In this post I share the slides, audio recording, and short outline of a presentation I gave at the Melbourne VMUG conference (Feb 2014) called “Three reasons why Networking is a pain in the IaaS, and how to fix it”.
As network technologists we know that when the compute architecture changes, the network architecture changes with it. Consider the precedent. The transition from mainframe to rack servers brought about Ethernet and top-of-rack switches. Blade servers introduced the blade switch and a cable-less network. And of course the virtual server necessitating the software virtual switch and a hardware-less network. At each iteration, we observe the architecture change occurring at the edge, directly adjacent to compute.
We can look at this superficially and say, “yes, the network architecture changed”. However if you think about it, the catalyzing change in each shift was the operational model, with intent to increase agility and reduce costs. The architecture change was consequential. Without compute, there is no reason for a network. Networking, both as a profession and technology, exists as a necessary service layer for computing. Without a network, computing is practically useless. As such, the capabilities of the network will either enable or impede Continue reading
The status quo approach to Networking is the biggest barrier to realizing the full potential of Virtualization and the private, public, or hybrid cloud. We must re-think how Networking Services are delivered, in a way that comports with automation, decoupling, pooling, and abstractions. I would argue, the solution is a more software-centric approach – Network Virtualization. But more importantly, we must re-think how we view Networking as a career skill set and the value we bring to an organization.
This was the message of two keynote talks I recently gave at the Sydney & Melbourne VMUG user conferences. The title of the talk was Three reasons why Networking is a pain in the IaaS, and how to fix it. I will share the slides and a brief summary of that talk in a subsequent post. But before I do that, please indulge me in a heart-to-heart chat from one long time Networking professional (me) to another (you):
I emphasize the word services because if you really think about it, that is what Networking really is – Networking is a Service. It always has been, and will always continue to be a service – a service that will always be needed. Continue reading
The status quo approach to Networking is the biggest barrier to realizing the full potential of Virtualization and the private, public, or hybrid cloud. We must re-think how Networking Services are delivered, in a way that comports with automation, decoupling, pooling, and abstractions. I would argue, the solution is a more software-centric approach – Network Virtualization. But more importantly, we must re-think how we view Networking as a career skill set and the value we bring to an organization.
This was the message of two keynote talks I recently gave at the Sydney & Melbourne VMUG user conferences. The title of the talk was Three reasons why Networking is a pain in the IaaS, and how to fix it. I will share the slides and a brief summary of that talk in a subsequent post. But before I do that, please indulge me in a heart-to-heart chat from one long time Networking professional (me) to another (you):
I emphasize the word services because if you really think about it, that is what Networking really is – Networking is a Service. It always has been, and will always continue to be a service – a service that will always be needed. Continue reading
The status quo approach to Networking is the biggest barrier to realizing the full potential of Virtualization and the private, public, or hybrid cloud. We must re-think how Networking Services are delivered, in a way that comports with automation, decoupling, pooling, and abstractions. I would argue, the solution is a more software-centric approach – Network Virtualization. But more importantly, we must re-think how we view Networking as a career skill set and the value we bring to an organization.
This was the message of two keynote talks I recently gave at the Sydney & Melbourne VMUG user conferences. The title of the talk was Three reasons why Networking is a pain in the IaaS, and how to fix it. I will share the slides and a brief summary of that talk in a subsequent post. But before I do that, please indulge me in a heart-to-heart chat from one long time Networking professional (me) to another (you):
I emphasize the word services because if you really think about it, that is what Networking really is – Networking is a Service. It always has been, and will always continue to be a service – a service that will always be needed. Continue reading
Back in September 2013 I wrote a piece on why you would deploy VMware NSX with your Cisco UCS and Nexus gear. The gist being that NSX adds business agility, a rich set of virtual network services, and orders of magnitude better performance and scale to these existing platforms. The response to this piece was phenomenal with many people asking for more details on the how.
The choice is clear. To obtain a more agile IT infrastructure you can either:
To help you execute on choice #2, we decided to write a design guide that provides more technical details on how you would deploy VMware NSX for vSphere with Cisco UCS and Nexus 7000. In this guide we provide some basic hardware and software requirements and a design starting point. Then we walk you through how to prepare your infrastructure for NSX, how to design your host networking and bandwidth, how traffic flows, and Continue reading
Back in September 2013 I wrote a piece on why you would deploy VMware NSX with your Cisco UCS and Nexus gear. The gist being that NSX adds business agility, a rich set of virtual network services, and orders of magnitude better performance and scale to these existing platforms. The response to this piece was phenomenal with many people asking for more details on the how.
The choice is clear. To obtain a more agile IT infrastructure you can either:
To help you execute on choice #2, we decided to write a design guide that provides more technical details on how you would deploy VMware NSX for vSphere with Cisco UCS and Nexus 7000. In this guide we provide some basic hardware and software requirements and a design starting point. Then we walk you through how to prepare your infrastructure for NSX, how to design your host networking and bandwidth, how traffic flows, and Continue reading
Back in September 2013 I wrote a piece on why you would deploy VMware NSX with your Cisco UCS and Nexus gear. The gist being that NSX adds business agility, a rich set of virtual network services, and orders of magnitude better performance and scale to these existing platforms. The response to this piece was phenomenal with many people asking for more details on the how.
The choice is clear. To obtain a more agile IT infrastructure you can either:
To help you execute on choice #2, we decided to write a design guide that provides more technical details on how you would deploy VMware NSX for vSphere with Cisco UCS and Nexus 7000. In this guide we provide some basic hardware and software requirements and a design starting point. Then we walk you through how to prepare your infrastructure for NSX, how to design your host networking and bandwidth, how traffic flows, and Continue reading
This post is intended to be a primer on the distributed routing in VMware NSX for vSphere, using a basic scenario of L3 forwarding between both virtual and physical subnets. I’m not going to bore you with all of the laborious details, just the stuff that matters for the purpose of this discussion.
In VMware NSX for vSphere there are two different types of NSX routers you can deploy in your virtual network.
Both the ESR and DLR can run dynamic routing protocols, or not. They can just have static/default routes if you like. The ESR is a router in a VM (it also does other L4-L7 services like FW, LB, NAT, VPN, if you want). Both the control and data plane of the ESR router are in the VM. This VM establishes routing protocol sessions with other routers and all of the traffic flows through this VM. It’s like a router, but in a VM. This should be straight forward, not requiring much explanation.
The ESR is unique because it’s more than a just router. It’s also a feature rich firewall, load balancer, Continue reading
This post is intended to be a primer on the distributed routing in VMware NSX for vSphere, using a basic scenario of L3 forwarding between both virtual and physical subnets. I’m not going to bore you with all of the laborious details, just the stuff that matters for the purpose of this discussion.
In VMware NSX for vSphere there are two different types of NSX routers you can deploy in your virtual network.
Both the ESR and DLR can run dynamic routing protocols, or not. They can just have static/default routes if you like. The ESR is a router in a VM (it also does other L4-L7 services like FW, LB, NAT, VPN, if you want). Both the control and data plane of the ESR router are in the VM. This VM establishes routing protocol sessions with other routers and all of the traffic flows through this VM. It’s like a router, but in a VM. This should be straight forward, not requiring much explanation.
The ESR is unique because it’s more than a just router. It’s also a feature rich firewall, load balancer, Continue reading
This post is intended to be a primer on the distributed routing in VMware NSX for vSphere, using a basic scenario of L3 forwarding between both virtual and physical subnets. I’m not going to bore you with all of the laborious details, just the stuff that matters for the purpose of this discussion.
In VMware NSX for vSphere there are two different types of NSX routers you can deploy in your virtual network.
Both the ESR and DLR can run dynamic routing protocols, or not. They can just have static/default routes if you like. The ESR is a router in a VM (it also does other L4-L7 services like FW, LB, NAT, VPN, if you want). Both the control and data plane of the ESR router are in the VM. This VM establishes routing protocol sessions with other routers and all of the traffic flows through this VM. It’s like a router, but in a VM. This should be straight forward, not requiring much explanation.
The ESR is unique because it’s more than a just router. It’s also a feature rich firewall, load balancer, Continue reading