VCAP – Sección 6 – Troubleshooting de red

Que tal gente, vamos a continuar con los temas de preparación para el examen de certificación VCAP-DCA, en este caso nos toca hablar de como realizar troubleshooting a nivel de red en vSphere.

Identificar configuraciones de vSwitches en un .vmx

Para empezar recordemos que los archivos .vmx son aquellos en donde reside la configuración de nuestra VM, por lo cual todas las opciones de hardware y modificaciones que realicemos se verán reflejadas en este archivo, vamos a ver un ejemplo:

ethernet0.present = “TRUE”
ethernet0.virtualDev = “vmxnet3″
ethernet0.dvs.switchId = “36 85 17 50 c7 4e 07 a1-65 b0 9c ca 55 88 a9 0b”
ethernet0.dvs.portId = “105″
ethernet0.dvs.portgroupId = “dvportgroup-42″
ethernet0.dvs.connectionId = “692809732″
ethernet0.addressType = “vpx”
ethernet0.generatedAddress = “00:50:56:97:00:00″
ethernet1.present = “TRUE”
ethernet1.virtualDev = “vmxnet3″
ethernet1.dvs.switchId = “”
ethernet1.dvs.portId = “”
ethernet1.dvs.portgroupId = “”
ethernet1.dvs.connectionId = “0″
ethernet1.addressType = “vpx”
ethernet1.generatedAddress = “00:50:56:97:00:01″
ethernet1.networkName = “Produccion alterna”

• virtualDev = “vmxnet3″  – Aquí se nos hace referencia al tipo de vNic que se tiene.
• dvs.switchId = “36 85 17 50 c7 4e 07 a1-65 b0 9c ca 55 88 a9 0b” – el identificador del switch distribuido al que esta conectado, este id lo podemos verificar de una manera simple utilizando el comando net-dvs:

También tenemos la opción de verificar este ID en la carpeta .dvsData (net-dvs |grep com.vmware.common.port.volatile.persist):

 

• dvs.portgroupId = “dvportgroup-42″ – este es el identificador del portgroup en la base de datos del vCenter, podemos confirmarlo de igual manera con el comando net-dvs

(select * from vpx_dvportgroup)

• addressType = “vpx” – esta línea nos indica que el mac address del ethernet 0 (en este caso) esta a cargo de un vCenter, es decir, este se encargara del manejo de las mismas para que no haya problema con mac addresses repetidas.
• generatedAddress = “00:50:56:97:00:00″ -  mac address generada para el adaptador.
• networkName = “Produccion alterna” - vm portgroup (vSS) al cual esta conectado dicho adaptador.

Identificar entradas de vSwitches en el archivo de configuración del host ESX/ESXi

Aquí con archivo de configuración vamos a entender el archivo esx.conf , que encontramos en /etc/vmware. Vamos a ver un pequeño fragmento del mismo donde podemos ver las entradas de nuestro vSwitch:

/net/vswitch/child[0000]/name = “vSwitch0″
/net/vswitch/child[0000]/numPorts = “128″
/net/vswitch/child[0000]/portgroup/child[0000]/name = “Management Network”
/net/vswitch/child[0000]/portgroup/child[0000]/shapingPolicy/enabled = “false”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/hasUplinkOrder = “false”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/beacon = “ignore”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/fullDuplex = “ignore”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/minSpeed = “10″
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/pctError = “ignore”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/maxActive = “1″
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/notifySwitch = “true”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/reversePolicy = “true”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/rollingRestoration = “false”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/team = “lb_srcid”

Aquí podemos ver que tenemos el nombre de un vSwitch, el vSwitch0,  y podemos ver todas sus configuraciones como load balancing (lb_srcid , port ID) , beacon probing, etc. Todas las configuraciones de switches standard las encontraremos en este archivo empezando con “/net/vswitch/”.

Identificar comandos y herramientas que podemos utilizar para el troubleshooting de red en vSphere

• esxcfg-vswitch
• esxcfg-vswif
• esxcfg-vmknic
• esxcfg-vmknic
• net-dvs

Les sugiero darle un vistazo a esta página http://vmware-land.com/esxcfg-help.html , para poder conocer el uso de estos comandos (con excepción de net-dvs)

identificar logs a utilizar en el troubleshooting de red

Aquí no existen los en especifico que nos brinden información de red, pero por experiencia propia les podría decir que cualquier problema que se tenga en cuanto a desconexiones en las vmnics lo pueden encontrar en /var/log/messages.

utilzar net-dvs para troubleshooting de vDS

El problema con este comando es que no existe documentación oficial por parte de VMware para el uso del mismo, además de ser “unsupported”. Aquí como vimos anteriormente podemos obtener información del mismo. La manera más facil seria ejecutando el comando y mandando el resultado del mismo a un archivo de texto que podamos observar con mas calma:

net-dvs >infodvs.txt

Aquí podemos ver todas las opciones que tenemos para el uso del mismo:

~ # net-dvs –help
net-dvs: unrecognized option `–help’
Warning: This is an unsupported command. Use at your own risk.
net-dvs -a [ -P maxPorts] switch_name
net-dvs -d switch_name
net-dvs [ -A | -D ] -p port switch_name
net-dvs [ -s name=value | -u name ] -p port switch_name
net-dvs -l [ switch_name ]
net-dvs -i (init database)
net-dvs [-S | -R | -G ]
net-dvs -T
net-dvs -v “vlanID[;t|p[0-7][;min-max,min-max...]]
net-dvs -V “primaryVID,secondaryVID,i|c|p;primaryVID,secondaryVID,i|c|p…”
net-dvs -m “sid;dname;snaplen;[oiveld];encapvlan;wildcardsIn,wildcardsOut;dstPort1,dstPort2,…;srcInPort1,srcInport2,…;srcOutPort1,srcOutPort2,…;:sid2;dname2…”
net-dvs dvswitch -k “respool1_id;respool2_id;…”
net-dvs dvswitch -p dvport -K “respool1_id:shares:limit;respool2_id:shares:limit;…”
net-dvs dvswitch -p dvport -z “respool_id”
net-dvs dvswitch -j [activate|deactivate]
net-dvs -L uplink_name1[,uplink_name2,...] -t team_policy_type -p port switch_name
net-dvs dvswitch -H “red|yellow|green:some message” switch_name
net-dvs -o “depth,param|classname;depth,param|classname;… -p port|globalPropList switch_name
net-dvs –mtu mtu_value [-p dvport] switch_name
net-dvs –x 0|1 -p dvport switch_name
net-dvs –vlan vlanID -p dvport switch_name
net-dvs –reset -p dvport switch_name
net-dvs –cap cap_value -p dvport switch_name
net-dvs –states -p dvport switch_name
net-dvs –miscInfo  ;# Dumps cpu/meminfo
net-dvs –vmknicIp <vmknic> ;# Displays IPv4 address on <vmknic>

Utilizar comandos de vicfg-* (vSphere CLI) para realizar troubleshooting de configuraciones de red

Aquí vamos a encontrar muchos equivalentes de los comandos esxcfg-* les sugiero echar un vistazo a este link http://www.vmware.com/support/developer/vcli/vcli41/doc/reference/index.html para que puedan encontrar que comandos pueden utilizar y como utilizarlos.

Configurar un analizador de paquetes en un ambiente vSphere

Aquí básicamente estarán instalando el analizador de paquetes que ustedes utilicen, generalmente nos vamos por wireshark. Un punto importante que debemos de tener en cuenta al configurar la VM donde estará siendo ejecutando este sniffer es que la vNic o interfaz de red de dicha vm que estará capturando paquetes debe de ser conectada a un portgroup que permita “promiscuous mode”

Y para poder capturar paquetes de todas las VLANs configuradas en dicho vSwitch podemos configurar para dicho portgroup la vlan 4095, esto solo aplica para VST.

Troubleshooting de Private VLANs

Aquí mas que nada sería cuestión de entender el concepto de PVLAN, les dejo un link a un articulo propio explicándoselos VCAP – Sección 2 – Configurar y administrar VLANs y PVLANs

Existen algunos puntos importantes en cuanto a la configuración de red física:

• lógicamente los puertos conectados a nuestro servidor ESX/ESXi deben de ser trunk
• Nuestros Switches deben de ser PVLAN aware.
• En el caso del uso de PVLANs VTP (VLAN trunking protocol) deberá estar en modo transparente, debido a que las PVLANs son definidas localmente.

Troubleshooting de red en Service Console e interfaces de vmkernel

Les recomiendo echarle un vistazo a este KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007986. Estaremos utilizando el comando esxcfg-vswif para el manejo de las configuraciones de Service Console.

En el caso de tener ESXi el termino de Service Console nos es irrelevante, por lo cual estaremos realizando troubleshooting de una interfaz de vmkernel y estaremos utilizando el comando esxcfg-vmknic.

También necesitaremos del comando esxcfg-vswitch para poder agregar uplinks,vlans,etc.

 

Troubleshooting de DNS y ruteo

Para modificar nuestros DNS lo podemos realizar desde el vSphere client en “Configuration>DNS and Routing” , al igual que nuestro Default gateway.

Esto también puede ser modificado directamente en los archivos

/etc/sysconfig/network - para poder modificar el default gateway del service console

/etc/resolv.conf - para poder modificar nuestros DNS

Para modificar el gateway del vmkernel, lo tenemos que realizar directamente con el comando esxcfg-route

 

Utilizar ESXTOP / RESXTOP para troubleshooting de red

Aquí les recomendaría leer mis artículos VCAP- sección 3 – utilizar herramientas avanzadas para el monitoreo de performance y VCAP – Sección 3 – realizar medición y calculo de recursos en un ambiente vSphere para que se den una mejor idea de como funciona esxtop.

Aquí solo sería cuestión de poner atención a paquetes caídos:

%DRPTX – “dropped transmit packets” porcentaje de paquetes transmitidos que se han caido, esto representa problemas con la red fisica, alto consumo de la misma, problemas de hardware , etc. si el valor es distinto a “0″ , es algo que tenemos que verificar.

%DRPRX – “dropped received packets” porcentaje de paquetes recibidos que se han caido, aquí puede ser por cuestiones de recursos en el lado de la VM (no hay suficiente capacidad de procesamiento , aumentar recursos) o porque se esta teniendo un buffer overflow a nivel de rx rings.

 

Utilizar CDP y network hints para identificar problemas de conectividad

Podemos obtener información de CDP (Cisco Discovery Protocol) directamente desde nuestro vSphere client en la sección de “Configuration>Networking”, seleccionamos una vmnic conectada a un vSwitch donde tendremos el siguiente simbolo:

Y haciendo click sobre el mismo podremos ver información de CDP (si es que está disponible):

 

También tenemos la opción de obtener esta información desde la línea de comando, utilzando vim-cmd:

vim-cmd hostsvc/net/query_networkhint

 

 

 

VCAP – Sección 2 – implementar y mantener una red virtual escalable

Que tal gente, continuando con los temas de preparación para el examen VDCA410 nos toca hablar sobre las políticas de failover y nic teaming que tenemos en vSphere.

Identificar políticas de NIC teaming en vSphere

El termino NIC teaming se refiere al agrupamiento de tarjetas físicas o pNICs de nuestros hosts ESX/ESXi para poder tener tolerancia a fallos y mediante una serie de políticas poder lograr una correcta distribución del trafico entre las mismas. Dentro de nuestro vSphere client conectado ya sea al vCenter o directamente a un host podemos navegar a Configuration>Networking y editamos las propiedades de un vSwitch:

Vamos a conocer todas las políticas que tenemos en esta sección de NIC teaming:

Como primer parámetro o política tenemos la sección de load balancing, aquí tenemos todas las técnicas disponibles en vSphere para la distribución de tráfico entre los distintos portgroups y sus tarjetas de red:

• Route based on the originating virtual port ID: este método es el default, cada puerto está configurado para utilizar una tarjeta física de red  (pNIC) en específico. Este método es el menos demandante en cuanto a ciclos de cpu ya que no se tiene que hacer un cálculo para dirigir el tráfico. El problema con este método está en que se puede terminar con todo el tráfico intenso en una misma pNIC y no correctamente distribuido.

• Route based on source IP hash: este método es el más complejo y más demandante en cuanto a ciclos de cpu de nuestro host ESX/ESXi pero aun así el más efectivo en distribuir las cargas entre distintas pNICs. En este método se utiliza el ultimo byte (LSB) tanto de la mac address de la vm como del host (almacenamiento,cliente,etc) con el cual se entabla una comunicación, para hacer un cálculo y poder determinar que pNIC será la que le corresponderá a dicha vm vamos a ver como funciona este cálculo:  Tenemos la VM2 la cual tiene una mac address de 00-0C-29-22-B4-20, y tenemos un file server que tiene la mac address de 00-0C-29-22-B4-02, esta vm esta conectada a un vSwitch con 2 pNICs para saber que pNIC será utilizada para la comunicación de la misma se realiza el siguiente calculo, tomamos los 2 ultimos bytes de cada una de las mac address 20 y 02, que en decimal son 32 y 2, los sumamos y lo dividimos entre el numero de pNICs 34/2=17, aquí tenemos una división exacta por lo cual el restante sería 0 (cero) y le correspondería la pNIC 1:

• Route based on source MAC hash: con este método se utiliza el ultimo byte perteneciente a la mac address de la vm a ser encendida y se divide entre el numero de pNICS y el restante de dicha división (en el caso de ser exacta el numero 0) será la pNIC a utilizar, EJ. tenemos un vSwitch con 2 pnics  y una nueva vm será encendida, en el caso de dicha vm se tiene una mac address de 00-0C-29-22-B4-20, en este caso dividimos el ultimo byte (LSB – less significant byte) que en decimal seria 32 entre el numero de pnics 32/2=16, aquí podemos ver que es una división exacta por lo cual no tenemos remanentes entonces le tocaría la pNIC numero uno. El problema aquí es que al igual que basado en el puerto o port ID, no se distribuyen el trafico de las vms entre las pNICs según el consumo por lo cual podríamos terminar con todo el tráfico intenso en una misma pNIC.

• Use explicit failover: este método en si no “balancea” cargas, en este método se estarán utilizando las pNICs configuradas como “Active Adapters” haciendo solo un simple cálculo de que pNIC es la que ha estado arriba el mayor tiempo, una vez determinada esta pNIC será a través de la cual se estará enviando el trafico. en el caso que las pNICs configuradas como “Activas” no estén arriba se utilizaran las configuradas como “Standby”.

Configurar politicas de Load Balancing desde la linea de comando

Para modificar los de load balancing en nuestros vSwitches necesitamos utilizar vim-cmd:

Modificar la política de load balancing a port ID para el vSwitch 0:

vim-cmd hostsvc/net/vswitch_setpolicy –nicteaming-policy=’loadbalance_srcid’ vSwitch0

Modificar la política de load balancing a IP hash para el vSwitch 0:

vim-cmd /hostsvc/net/vswitch_setpolicy –nicteaming-policy=’loadbalance_ip’ vSwitch0

Modificar la política de load balancing a MAC hash para el vSwitch 0:

vim-cmd /hostsvc/net/vswitch_setpolicy –nicteaming-policy=’loadbalance_srcmac’ vSwitch0

Verificar las políticas de load balancing en todos nuestros vSwitches:

vim-cmd /hostsvc/net/vswitch_info |grep -E ‘(policy|name)’

Network Failover Detection

• Link status only: con este método para la detección de una posible falla en nuestra red lo único que tenemos es el estado físico de conexión, es decir si existe un link físico entre el switch y nuestro host ESX/ESXi, en este caso no podemos detectar fallas avanzadas como podría ser un puerto bloqueado por STP (Spanning tree protocol).

 

• Beacon probing: con este método nuestros hosts ESX/ESXi mandan una serie de paquetes broadcast (beacon packets) a través de todas las pNICs que conforman un nic teaming, en el momento que llegan al switch este realiza el forward o reenvio de todos estos paquetes a cada uno puertos que este tenga. En el caso que alguno de las pNICs o uplinks no reciban 3 paquetes consecutivos este link se marca como caido. Este método esta pensado para ser utilizado en el caso que nuestros switches no soporten Link state tracking (también conocido como trunk failover).

Notify Switches

Esta opción básicamente lo que nos va a permitir es el notificar a los switches cambios en cuanto a nuestra red en VMware, se notifican las siguientes acciones:

• Operaciones de VMotion: al cambiar de host nuestra vm se tiene que notificar al switch este cambio para que se hagan las modificaciones en su lookup table.
• Cambios de MAC address: al realizar cambios de mac es necesario nuevamente notificar esta modificación para poder entablar comunicación.
• Failover en nuestro nic teaming: se notifica al switch el cambio de uplink.
• Inicio de una vm: estrictamente esto ocurre cada vez que una vm se conecta a un vswitch.

Para realizar las notificaciones se hace uso de RARP (Reverse Address Resolution Protocol) lo cual actualiza las asociaciones en el lookup table de nuestros switches físicos. Si nosotros necesitamos configurar Network load Balancing de Microsoft (NLB) en modo unicast es necesario deshabilitar esta función.

 

Failback

Aquí simplemente definimos en el caso de realizarse un failover hacia una tarjeta activa debido a la caída de otra si es que se regresara a utilizar la tarjeta fallida en el momento que esta se marca como activa. En el caso de puertos vmkernel utilizados para almacenamiento ip (ISCSI & NFS) se recomienda tener esta opción en “no” para prevenir un “ping-pong” entre los puertos en el caso que experimentemos problemas con puertos en especifico y se tenga lo que se conoce como “port flapping”.

Failover Order

Aquí básicamente nosotros decidimos que tarjetas de red estarán activamente participando en la comunicación, cuales estarán en standby en el caso de fallo de alguna activa y cuales no quisiéramos que se utilicen:

 

 

 

VCAP – Sección 2 – Configurar y administrar VLANs y PVLANs

Que tal gente, continuando con los temas para el examen VDCA410 es momento de hablar sobre VLANs y PVLANs. Vamos a saber que utilidad tienen y como debemos configurarlas.

¿Qué es VLAN y PVLAN?

Una VLAN es la división de un broadcast domain en varios broadcast domains, podemos entender mas fácil este concepto como la división de una LAN en distintas LANs que viajan sobre el mismo medio físico y con esto podemos tener varias subnets y una división de los tráficos de manera efectiva. En esta imagen lo podemos de mejor manera:

Una PVLAN es también conocida como vlan secundaria, básicamente es dividir las VLANs en otras vlans, con esto lo que logramos es aislar la comunicación entre hosts de distintas pvlans por lo tanto ganamos seguridad.

¿Qué tipo de tagging de VLAN tenemos?

En VMware tenemos 3 tipos de realizar el tagging o etiquetado para las VLANs:

• Virtual machine guest tagging (VGT): el etiquetado de los paquetes con el número de VLAN es realizado por el sistema operativo, con esto logramos quitar la limitación que tenemos en cuanto a número de VLANs. Tenemos que tener en cuenta el hecho de un mayor consumo de CPU debido a el etiquetado de paquetes dentro del sistema operativo del cliente.

• External switch tagging (EST): el etiquetado de los paquetes se realiza una vez que llega al puerto del switch físico.

• Virtual switch tagging (VST): este es el modo de etiquetado más utilizado en infraestructuras VMware, nuestros switches virtuales se encargan de hacer el etiquetado de los paquetes. Nosotros definimos portgroups para nuestras máquinas virtuales y definimos un tag de vlan para cada uno de ellos,  solo es cuestión de conectar nuestras vms a los portgroups indicados según las vlans que requieran.

Ahora que sabemos todos los métodos para poder etiquetar nuestros paquetes es necesario especificar que tipos de PVLANs tenemos, existen 3 tipos en VMware:

• Promiscua (Promiscuous): como su nombre lo indica,cualquier vm conectada a una pvlan promiscua será capaz de comunicarse con todas las pvlans existentes ya sean isolated o community. Las pvlans promiscuas llevan el mismo tag que la vlan principal.
• Comunidad (Community): toda vm conectada a una pvlan de comunidad puede comunicarse con vms existentes dentro de su misma pvlan y con vms conectadas a pvlans promiscuas de la misma vlan principal.
• Aislada (Isolated): con este tipo de pvlan lo que tenemos es el aislamiento total de la vm conectada a esta pvlan, solo las vms conectadas a una pvlan promiscua podrán tener contacto ella.

Existen algunos puntos que debemos tener en cuenta en el caso de implementar pvlans:

• Todos los switches externos (físicos) tienen que ser compatibles con pvlans.
• El puerto en trunk deberá ser hecho para las vlans primarias no las secundarias (pvlans).

Tenemos 2 modos principales para nuestros puertos en un switch distribuido:

• VLAN: También conocido como access mode, estos puertos pertenecerán a una sola vlan principal.
• VLAN trunking: en este modo se permite tener varias vlans comunicándose a través del mismo puerto. Es necesario configurar este modo de puerto en los switches fisicos donde se estarán conectando nuestros servidores ESX/ESXi. Dentro de este modo tenemos un modo secundario:

Private VLAN: en este modo nosotros permitimos el uso de pvlans o vlans secundarias.

¿Cómo configuro VLANs en mis switches standard (vSS) y mis switches distribuidos (vDS)?

• Switches standard: en el caso de los vSS solo somos capaces de configurar vlans principales no pvlans, navegamos a Configuration>Networking y seleccionamos hacemos click en “properties” sobre un switch standard y seleccionamos un port group, estas vlans son configuradas en cada port group.

• Switches distribuidos (vDS): Navegamos a home>inventory>networking, una ves dentro seleccionamos nuestro por group hacemos click derecho sobre el seleccionando “edit settings”, esto nos abrirá una ventana donde seleccionaremos “VLAN” aquí configuramos que modo se estará utilizando, ya sea vlan , vlan trunking o private vlan.

Si nosotros quisiéramos configurar trunking seleccionamos “VLAN trunking” e ingresamos todas las vlans que se estarán utilizando:

En el caso de querer configurar pvlans seleccionamos nuestro vDS y damos click derecho sobre el, aquí configuraremos las pvlans que necesitemos:

Una vez configuradas las pvlans necesarias solo es cuestión de dictar en cada uno de los port groups el modo “Private VLAN” y seleccionar la pvlan que se necesita:

¿Cómo configuro vlans desde la línea de comando?

En el caso de utilizar la linea de comando solo podemos modificar o configurar el vlan id en nuestros switches standard, ya que dichas operaciones para los switches distribuidos solo pueden ser realizadas desde el vCenter.

para modificar o asignar un id 10 de VLAN para el port group llamado “Produccion” haríamos lo siguiente:

esxcfg-vswitch  -v 10 -p “Produccion” vSwitch1

-v VLAN ID

-p nombre de portgroup

Aquí también podríamos utilizar vicfg-vswitch en el caso de vSphere CLI.