Microsegmentación con Firewall Distribuido de NSX (DFW)

Revisemos primero los tipos de FW que disponemos:

-Fisicos: aunque aun son necesarios, los cortafuego perimetrales tienen limitaciones sobre el ancho de banda que pueden gestionar asi como la carga de analisis que obliga a una escalabilidad horizontal compleja y que aumenta la complejidad del entorno.

-Virtuales, mismo servicio que los fisicos pero en formato virtual, son un buen complemento para los FW fisicos aunque estan limitados a una mdia de 1 y 4 Gb de ancho de banda.

-Distribuidos: son el complemento perfecto para los fw fisicos en un entorno de vSphere. EL FW de NSX esta basado en el rendimiento del kernel del hypervisor (ESXi), permiten una gran escalabilidad horizontal muy agil y que no implica aumentar la complejidad del entorno y que permite un ancho de banda de hasta 20Gbps por host.

Gracias al nuevo paradigma que presentan los servicios distribuidos de NSX, como en este caso el de FW,  es posible plantear otros escenarios a donde las capas de los servicios fisicos tradicionales no estaban llegando, en este caso, el esquema de firewall perimetral se amplia a un esquema de una relacion 1:1 entre VM y FW como vemos en al siguiente imagen:

De la idea anterior nace el concepto de "microsegmentación": el trafico se inspecciona ahora en las tarjetas de las maquinas virtuales a nivel de capa 2, 3 y 4 gracias a NSX.

Ademas permite integración con soluciones de terceros que aumentan la capacidad de analisis de las aplicaciones como de capa 7.

Por ultimo es importante destacar que si la VM se mueve de host hypervisor (ESXi), las reglas de esta VM se van con ella, y no es necesario ningun tipo de reconfiguracion con lo que es 100% compatible con las tecnicas de asignacion dinamica de recursos (DRS) y de caracteristicas como HA de VMware para dotar de alta disponibilidad a las maquinas virtuales. 

La microsegmentacion nos permite aislar y segmentar las aplicaciones de diferentes formas como podemos ver en la siguiente imagen:

Rendimiento del Firewall Distribuido (DFW) de NSX

En los siguientes post, desmontaremos algunos de los mitos que existen sobre el rendimiento y la visibilidad de operaciones que existen relacionadas con NSX, en este caso nos centraremos el el rendimiento del cortafuegos implementado por NSX.

Una buena metrica para analizar el rendimiento del DFW de NSX; es medir las conexiones por segundo que puede alcazar un firewall con un numero determinado de reglas.

En el siguiente grafico vemos como incluso con 100 reglas de firewall por host se alcanzan sin problemas las 80.000 conexiones por segundo.

En la siguiente gráfica podemos observar como apenas hay perdida de rendimiento incluso cuando se transmiten 20Gbps a través de un solo host (con dos enlaces de 10 Gbps)

Es importante tener en cuenta que con el DFW (Firewall Distribuido de NSX) la carga que debe soportar y gestionar cada FW es el de las VMs que residen en ese host o del trafico que se envia y/o recibe en un solo host; a diferencia de los FW fisicos tradicionales que tienen que soportar el trafico de todo el entorno tanto fisico como virtual ya que son un punto único de filtrado de trafico. Esto ademas obliga a que el trafico circule por toda la ed hasta llegar la FW fisico, en cambio con el DFW de NSX, se llega al extremo de que si el trafico es entre VMs ubicadas en el mismo no host no tengan ni que salir del host para comunicarse entre ellas.

Ademas, la posibilidad de combinar las vRealize Automation (vRA) con NSX, nos permite implementar las aplicaciones y los servicios de forma muy ágil y flexible:

-implementaciones de aplicaciones multinivel en redes aisladas.

-implementaciones de VMs en redes planas.

-implementaciones de reglas para aplicaciones que se apliquen en el momento de su activación.

-implementar servicios combinados de FW y LB o VPNs

Componentes de VMware NSX

Los componentes de la solución de virtualización de red NSX de VMware se dividen en tres areas o planos: Plano de Gestión, Plano de Control y Plano de Datos. Ademas de estos tres planos basicos, tambien se incluyen los componentes para integracion con la plataforma de gestion cloud o CMP a través de vRealize Suite.

Ahora veamos cuales son los componentes y/o funciones de cada plano en la siguiente tabla:

Plano de Datos (Data Plane)

Los modulos de cortafuegos distribuido (DFW), enrutador lógico  NSX virtual (DR) y puertos VXLAN son implementados por NSX Manager en el VMkernel de cada host (hypervisor ESXi).

Los enrutadores lógicos y distribuidos son los que permiten trafico este-oeste.

Las puertas de enlace o gateways de NSX Edge se implementan como una maquina virtual se encargan de permitir el trafico norte-sur (dispone de servicios de cortafuegos, balanceo y servicios basados en VPN)

Plano de Control (Control Plane)

En este plano nos encontramos con los enrutadores lógicos de NSX (NLR), el NSX Controller y el gestos de usuarios global (UWA).

Plano de Gestión (Management Plane)

En este plano tenemos la interfaz de gestion de usuario unificada para controlar y gestionar vSphere y NSX desde el Web Client.

Modelo de Consumo (CMP)

En el CMP tenemos el portral de autoservicio y automatizacion de cloud y NSX (basado principalmente en vRealize Automation (vRA))

VMware NSX Part I: Deployment

First steps with VMware Network Virtualization aka NSX:

-OVA deployment

-NSX connection to vCenter Server

Nueva certificacion VMware Certified Professional – Network Virtualization (VCP-NV)

Ya esta disponible la nueva certificacion de redes VCP-NV y VCDX-NV

Si ya eres VCP , puedes presentarte al examen directamente aunque se recomienda realizar el curso de ICM de NSX (VMware NSX: Install, Configure Manage).

Y como detalle a destacar, si eres CCNA o CCNP tambien puedes presentarte al examen aunque como en el punto anterior tambien se recomienda realizar el curso ICM y/o los Labs.

Si no me falla la memoria es la primera vez que con una certificacion externa a VMware se permite realizar una certificacion interna :-)

Info del producto NSX   http://www.vmware.com/products/nsx

Info de las certificaciones: 

VMware Certified Professional – Network Virtualization (VCP-NV)
http://mylearn.vmware.com/mgrReg/plan.cfm?plan=51111&ui=www_cert

VCDX – Network Virtualization (VCDX-NV)
https://mylearn.vmware.com/mgrReg/plan.cfm?plan=51110&ui=www_cert

Understanding networks in vCloud Director - Part 2/2

Read first "Understanding networks in vCloud Director - Part 1/2"
http://virtualshocks.blogspot.com.es/2013/09/understanding-networks-in-vcloud.html

This part 2/2 is about the "vApp networks" on VMware vCloud Director. This vApp networks connect the virtual machines in a vApp, it´s like configure a router in front a vApp to separate the vm´s from the rest of the vApp or the Cloud enviroment.

What VMware says "vCloud Director coordinates with vCloud Networking and Security Manager to provide automated network security for a vCloud environment. vCloud Networking and Security Edge gateway devices are deployed during the provisioning of routed or private networks. Each vCloud Networking and Security Edge gateway runs a firewall service that allows or blocks inbound traffic to virtual machines that are connected to a public access organization virtual datacenter network.    The vCloud Director web console exposes the ability to create five-tuple firewall rules that are comprised of source address, destination address, source port, destination port, and protocol."

When creating a vApp netork the options are:

-Direct: vApps coonect directly to the organization virtual datacenter network.
-Routed: new network where the router provides NAT and FW functions.
-Isolated: no connections outside de vApp, only inside vApp VM machines can communicate.
-Fenced: Identical virtual machines can exist in different vApps, the virtual router provides isolation and proxy ARP.

Before see some examples, take care with the Network Pool options as defined above:

...Trough the wizard:

..Trough the vApp diagram tab in vCloud Director GUI. This view is one of the best way to review the networking configuration issues clicking on a VM the paths are highlighted:

...Trough the Networks tab you can sleect the network type ant the NAT or FW options:

Let´s check some examples:

CASE1: where 2 Organizations keep comunicated with a External Network: vShield Edge routing and statics routes are necessary

-CASE1: where 2 Organizations keep communicated without NAT but where vShield Edge is necessary.

.

LINK:  vCloud Networking

http://blogs.vmware.com/vsphere/files/2012/09/VMW-vCloud-Networking-Fixed-Sep13.pdf

Understanding networks in vCloud Director - Part 1/2

To easily use the program, you must have clear concepts of network types that we have in vCloud Director.

We have basically three types:

External Network: a portgroup on a switch (distributed, standard or Nexus). It is the vlan and ip segment (public or private) allocated physically

Organization Network: created automatically when create the Provider VDC, it´s only for organization use and could be one of three types:
1-direct connected to an external network
2-routed connected with a vShield Edge wich have two ip´s: one on the External Network side and one on the Organization Network to share the traffic between the vApp and the External Network
3-no connected to external network

vApp network: this network is created automatically when the vApp is created. The two functions are:
-No connected to Organization Network
-Routed connected to Organization Network


....On next post Part-1/2 will review more concepts like Fencing, Isolating or Routed networks.

How to test network performance with Netperf

As we can read at the offcial webpage: "Netperf is a benchmark that can be used to measure the performance of many different types of networking. It provides tests for both unidirecitonal throughput, and end-to-end latency"

It´s so usefull to test network performance between two virtual machines , for example from a database server to the aplicacion client.

First, download Netperf for Linux or Windows O.S and install or unzip it:

    Linux:  http://www.netperf.org/netperf/DownloadNetperf.html
    Windows: https://i18n-zh.googlecode.com/files/NetPerf-2.4.5-w32.zip

See a Windows example:

-Start server side. You can specified a port with -p

-Start client side. With -h you can see all the options.

In this case, we get a test with the result 524,55 Mbit/s (Mbps) between two virtual machines.

The simple test run for 10seconds, but this can be changed to. Netperf -h:

E:\datos\NetPerf-2.4.5-w32>netperf -h

Usage: netperf [global options] -- [test options]

Global options:

    -a send,recv      Set the local send,recv buffer alignment

    -A send,recv      Set the remote send,recv buffer alignment

    -B brandstr       Specify a string to be emitted with brief output

    -c [cpu_rate]     Report local CPU usage

    -C [cpu_rate]     Report remote CPU usage

    -d                Increase debugging output

    -D [secs,units] * Display interim results at least every secs seconds

                      using units as the initial guess for units per second

    -f G|M|K|g|m|k    Set the output units

    -F fill_file      Pre-fill buffers with data from fill_file

    -h                Display this text

    -H name|ip,fam *  Specify the target machine and/or local ip and family

    -i max,min        Specify the max and min number of iterations (15,1)

    -I lvl[,intvl]    Specify confidence level (95 or 99) (99)

                      and confidence interval in percentage (10)

    -l testlen        Specify test duration (>0 secs) (<0 bytes="" font="" trans="">

    -L name|ip,fam *  Specify the local ip|name and address family

    -o send,recv      Set the local send,recv buffer offsets

    -O send,recv      Set the remote send,recv buffer offset

    -n numcpu         Set the number of processors for CPU util

    -N                Establish no control connection, do 'send' side only

    -p port,lport*    Specify netserver port number and/or local port

    -P 0|1            Don't/Do display test headers

    -r                Allow confidence to be hit on result only

    -t testname       Specify test to perform

    -T lcpu,rcpu      Request netperf/netserver be bound to local/remote cpu

    -v verbosity      Specify the verbosity level

    -W send,recv      Set the number of send,recv buffers

    -v level          Set the verbosity level (default 1, min 0)

    -V                Display the netperf version and exit

For those options taking two parms, at least one must be specified;

specifying one value without a comma will set both parms to that

value, specifying a value with a leading comma will set just the second

parm, a value with a trailing comma will set just the first. To set

each parm to unique values, specify both and separate them with a

comma.

* For these options taking two parms, specifying one value with no comma

will only set the first parms and will leave the second at the default

value. To set the second value it must be preceded with a comma or be a

comma-separated pair. This is to retain previous netperf behaviour.

E:\datos\NetPerf-2.4.5-w32>

Take care with the units (about caudal, no about velocity):

106 bit = 1 000 000 bit/s = 1 Mbit/s

1 megabyte/s = 8 megabit/s

1 megabit/s = 1000 kilobit/s = 125 kilobyte/s

Unit	Bits	Bits / 1,000,000
Mega-bit	1,000,000	1.0
Mebi-bit	1,048,576	1.05
Mega-byte	8,000,000	8.0
Mebi-byte	8,388,608	8.39

Links:

Units http://en.wikipedia.org/wiki/Data_rate_units

Training NetPerf http://www.netperf.org/netperf/training/Netperf.html

VMware vCloud helpfully posters

vCloud Poster   

http://blogs.vmware.com/vsphere/files/2013/01/VMware-vCloud-Suite-Poster-v1.pdf

vCloud Networking Poster
http://blogs.vmware.com/vsphere/files/2012/09/VMW-vCloud-Networking-Fixed-Sep13.pdf

Cambiar "Network Adapter Type" en #vSphere con PowerCLI

Una vez creada una mv no se puede cambiar el tipo de adaptador a las tarjetas de red mediante el entorno grafico. Para hacer esta operacion primero debemos apagar la mv y luego cambiar por PowerCLI el tipo de adaptador. Eso si, es mas que probable que perdamos la configuracion de las tarjetas de red, con lo que sera necesario anotar las ip´s de estas antes de hacer cualquier cambio.

Estos serian los pasos para cambiar varias tarjetas E1000 a VMXNET3, primero nos conectamos al vCenter, listamos las tarjetas de red y despues lanzamos el cambio del tipo de adaptador, nos preguntara tarjeta por tarjeta si que queremos cambirlar...y voila!!!

-----------------------------------------------------------------------------------------------------

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> 

get-vm MVTEST01 | get-networkadapter

Name                 Type       NetworkName  MacAddress         WakeOnLan

                                                                  Enabled

----                 ----       -----------  ----------         ---------

Network adapter 1    e1000      RED_VLAN1 -... 00:50:56:93:75:11       True

Network adapter 2    e1000      RED_VLAN2... 00:50:56:93:75:22       True

Network adapter 3    e1000     RED_VLAN13... 00:50:56:93:75:33    True

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

get-vm MVTEST01 | get-networkadapter | set-networkadapter -type "vmxnet3"

Confirmar

¿Está seguro de que desea realizar esta acción?

Se está realizando la operación "Setting Type: Vmxnet3" en el destino "Network

adapter 1".

[S] Sí  [O] Sí a todo  [N] No  [T] No a todo  [U] Suspender  [?] Ayuda

(el valor predeterminado es "S"):s

Confirmar

¿Está seguro de que desea realizar esta acción?

Se está realizando la operación "Setting Type: Vmxnet3" en el destino "Network

adapter 2".

[S] Sí  [O] Sí a todo  [N] No  [T] No a todo  [U] Suspender  [?] Ayuda

(el valor predeterminado es "S"):s

Confirmar

¿Está seguro de que desea realizar esta acción?

Se está realizando la operación "Setting Type: Vmxnet3" en el destino "Network

adapter 3".

[S] Sí  [O] Sí a todo  [N] No  [T] No a todo  [U] Suspender  [?] Ayuda

(el valor predeterminado es "S"):s

Name                 Type       NetworkName  MacAddress         WakeOnLan

                                                                  Enabled

----                 ----       -----------  ----------         ---------

Network adapter 1    Vmxnet3    RED_VLAN1-... 00:50:56:93:75:11       True

Network adapter 2    Vmxnet3    RED_VLAN2... 00:50:56:93:75:22       True

Network adapter 3    Vmxnet3    RED_VLAN3... 00:50:56:93:75:33       True

PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI>

 -----------------------------------------------------------------------------------------------------