Archive

Posts Tagged ‘net-dvs’

VCAP – Sección 6 – Troubleshooting de red

February 5, 2011 2 comments

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

 

 

 

Categories: VCAP Tags: , , , , , ,

VCAP – Sección 2 – Administrar configuraciones de switches distribuidos

November 15, 2010 Leave a comment

Que tal gente, continuando con los temas para el examen VDCA410 nos toca hablar de las configuraciones que tenemos en los switches distribuidos.

Relación entre switches distribuidos (vDS) y switches standard lógicos

Un switch distribuido entre las muchas cualidades que nos ofrece esta la de administrar y configurar todos los parámetros de red desde una manera centralizada aplicando todos los cambios a los servidores ESX/ESXi que pertenezcan a dicho switch distribuido.

 

 

Aquí en esta imagen podemos ver como es la arquitectura de vNetwork que hace posible el uso de switches distribuidos. Tenemos un “control plane” desde donde nosotros realizamos todas las configuraciones que necesitemos en dicho switch, el punto importante a entender aquí casi todas las modificaciones a los vDS se realizan desde vCenter. Después podemos ver “ProxySwitch”, estos switches son switches standard (vSS) a este elemento también se le llama I/O plane, aquí es donde ocurre todo el trafico de nuestras vms.

Uso de la línea de comando para realizar modificaciones en nuestros switches distribuidos

esxcfg-vswitch -Q <vmnic> -V <dvPort ID de la vmnic> <dvSwitch> #quitar un uplink
esxcfg-vswitch -P <vmnic> -V < dvPort ID si usar> <dvSwitch> #agregar un uplink
esxcfg-vswif -a -i <dirección ip> -n <mascara de subred> -V <dvSwitch> -P <DVPort Id> vswif0 #crea un vswif (service console y lo agrega a un switch distribuido).

Tipos de port binding

  • Static binding: este es el default, aquí cada vNIC le corresponde un puerto de nuestro vDS en cuanto la vm se enciende se le asigna dicho puerto este puerto será de dicha vm hasta que esta sea removida del port group. Este es el valor recomendado por VMware. Aquí se preservan todos los datos y estadísticas de los puertos.
  • Dynamic binding: aquí en el momento de encender una vm se le asigna un puerto, y cuando nosotros apagamos dicha vm se libera el puerto para ser utilizado por otra vm. Este tipo de binding es recomendado para ambientes donde tengamos una mayor cantidad de vms que el número de puertos disponibles en nuestro vDS. Aquí se preservan todos los datos y estadísticas de los puertos, es por eso que al tener configurado dynamic binding las vms deberán ser iniciadas desde el vCenter.
  • Ephemeral: en este caso el puerto es creado y asignado en el momento que encendemos una vm y al apagar dicha vm este puerto es destruido. En este caso todas las estadísticas del puerto no son conservadas y podemos iniciar vms desde nuestros hosts ESX/ESXi o desde el vCenter.

Configurar live port moving


 

Esta función lo que nos permite es el poder migrar puertos standalone (puertos que no pertenecen a ningún portgroup) a un portgroup aun cuando este en uso, con esto se heredan todas las características de dicho port group sobre el puerto standalone. esta función es eliminada del GUI en la versión 4.1:

 

Estos puertos “standalone” solo pueden ser creados desde el SDK de VMware por lo cual yo creo que esta configuración fue removida del GUI.

Identificar que tipo de switch distribuido requerimos

Aquí básicamente es decidir si nos vamos por switches distribuidos VMware o compramos licencias adicionales para Cisco Nexus 1000v, honestamente si se tiene el dinero $$ es un gran plus contar con el switch cisco, debido a que nos ofrece bastantes ventajas entre las cuales podemos encontrar las siguientes:

  • Cisco IOS: con esto podemos lograr una integración mucho más cercana entre el equipo de networking y los administradores de VMware, cada uno enfocándose a lo que les corresponde teniendo a los admins de la red trabajando con una interfaz que conocen muy bien.
  • perfiles en los puertos: podemos configurar una gran cantidad políticas de seguridad,netflow,etc y estas políticas estarán viajando junto con la vm aunque se realice operaciones de VMotion.
  • Opciones avanzadas de Cisco: Netflow,QoS,port security, etc etc, ustedes nombren.

 

Troubleshooting desde la línea de comando para nuestros vDS

Aquí podemos hacer uso de varios comandos como puede ser esxcfg-vswitch,esxcfg-vswif,esxcfg-route,etc. Aquí me interesa mas platicarles de un comando llamado net-dvs, con el cual podemos obtener información mucho más detallada de nuestros switches distribuidos:

Para poder ejecutar este comando necesitamos logearnos directamente al servidor sea por ssh o directo en la consola, y seguimos estos pasos:

Paso 1-. navegamos a la ruta /usr/lib/vmware/bin/ , aquí encontraremos un programa llamado net-dvs, el cual podríamos ejecutar y nos daría el display en la pantalla si nosotros quisiéramos ser capaces de leer toda la información podríamos ejecutar el siguiente comando:

/usr/lib/vmware/bin/net-dvs |more

Paso 2-. para mi gusto es mucho mas cómodo leer el output de este comando desde un notepad o un documento de word, aquí podríamos redirigir el output a un .txt

/usr/lib/vmware/bin/net-dvs > /tmp/confvds.txt

Vamos a analizar un poco lo que nos muestra este comando:

Follow

Get every new post delivered to your Inbox.

Join 38 other followers