Brad Hedlund

Author Archives: Brad Hedlund

An introduction to Zero Trust virtualization-centric security

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”.

What are we trying to accomplish?

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.

Trust Zones of Insecurity

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

An introduction to Zero Trust virtualization-centric security

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”.

What are we trying to accomplish?

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.

Trust Zones of Insecurity

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

An introduction to Zero Trust virtualization-centric security

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”.

What are we trying to accomplish?

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.

Trust Zones of Insecurity

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

Three reasons why Networking is a pain in the IaaS, and how to fix it

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

Three reasons why Networking is a pain in the IaaS, and how to fix it

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

Three reasons why Networking is a pain in the IaaS, and how to fix it

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

Networking is a Service, and you are the Service Provider

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

Networking is a Service, and you are the Service Provider

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 […]

Networking is a Service, and you are the Service Provider

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

Networking is a Service, and you are the Service Provider

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

New design guide: VMware NSX with Cisco UCS and Nexus 7000

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:

  • Rip out every Cisco UCS fabric interconnect and Nexus switch hardware you’ve purchased and installed, then proceed to repurchase and re-install it all over again (ASIC Tax).
  • Add virtualization software that works on your existing Cisco UCS fabric interconnects and Nexus switches, or any other infrastructure.

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

New design guide: VMware NSX with Cisco UCS and Nexus 7000

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:

  • Rip out every Cisco UCS fabric interconnect and Nexus switch hardware you’ve purchased and installed, then proceed to repurchase and re-install it all over again (ASIC Tax).
  • Add virtualization software that works on your existing Cisco UCS fabric interconnects and Nexus switches, or any other infrastructure.

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

New design guide: VMware NSX with Cisco UCS and Nexus 7000

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:

  • Rip out every Cisco UCS fabric interconnect and Nexus switch hardware you’ve purchased and installed, then proceed to repurchase and re-install it all over again (ASIC Tax).
  • Add virtualization software that works on your existing Cisco UCS fabric interconnects and Nexus switches, or any other infrastructure.

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

New design guide: VMware NSX with Cisco UCS and Nexus 7000

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 […]

Distributed virtual and physical routing in VMware NSX for vSphere

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.

  • The NSX Edge Services Router (ESR)
  • The NSX Distributed Logical Router (DLR)

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

Distributed virtual and physical routing in VMware NSX for vSphere

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.

  • The NSX Edge Services Router (ESR)
  • The NSX Distributed Logical Router (DLR)

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

Distributed virtual and physical routing in VMware NSX for vSphere

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 […]

Distributed virtual and physical routing in VMware NSX for vSphere

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.

  • The NSX Edge Services Router (ESR)
  • The NSX Distributed Logical Router (DLR)

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

VMware NSX, Convergence, and Reforming Operational Visibility for the SDDC

Note: This article was originally written for and published at the VMware Network Virtualization Blog. The following is a verbatim re-post of the original content. Through convergence, VMware NSX will substantially reform operational visibility for the era of the software-defined data center Executive Summary Since the launch at VMworld 2013, much of the discussion about […]
1 2 3