GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Configuración de VLAN Tagging en Hyper-V: Switch Trunking, 802.1Q, Tarjetas de Red, y otros misterios


Este artículo pretende aclarar las típicas dudas que pueden producirse al intentar configurar VLAN Tagging (802.1Q) en Hyper-V, es decir, conseguir configurar el campo VLAN ID en nuestras Máquinas Virtuales para gestionar fácilmente la asignación a VLANes de las Máquinas Virtuales. Para ello se profundiza un poco en los principales requisitios necesarios para hacer funcionar VLAN Tagging (tarjetas de red, drivers y switches), y se muestra como ejemplo la configuración de red en un Switch SMC 8024L2 para comunicar dos Host Hyper-V dotados de tarjetas de red Intel Gigabit CT Desktop Adapter, utilizando Switch Trunking, y sin Trunks también.

Configurar Redes Virtuales en Hyper-V (Virtual Networks), VLAN Tagging (802.1Q) y Switch Trunk, es una de last areas más importantes de una implementación de Hyper-V (con y sin Virtual Machine Manager 2008), y en algunos casos, también puede convertirse en una de las tareas más confusas.

Requisitos para utilizar VLAN Tagging con Hyper-V

Lo primero que tenemos que tener claro, es si cumplimos o no los requisitos para poder utilizar VLAN Tagging en nuestra instalación de Hyper-V. Los requisitos que debemos cumplir, son principalmente los siguientes:

  • Disponer de una tarjeta de red (con sus correspondientes drivers, ojo al dato) que soporte VLAN Tagging. Este es el principal marrón. Por un lado, muchas tarjetas de red de escritorio o de segundas marcas que SI soportan VLAN Tagging, nos pueden dar más de un dolor de cabeza al intentar configurarlas con Hyper-V, principalmente, porque muchas tarjetas de red no incluyen drivers para Windows Server 2008 (manda web, pa Linux sí, y para Windows Server 2008, que es lo que montan las empresas serias, nada de nada). Esto puede desembocar en diferentes posibilidades: Que Windows no disponga de drivers para la tarjeta (estamos jodíos), Que Windows detecte la tarjeta correctamente con los propios drivers de Windows Server 2008 pero perdamos funcionalidades como el VLAN Tagging (estamos semi-jodidos, no hay VLAN Tagging, pero al menos tenemos red, menos da una piedra), y Que Windows detecte la tarjeta correctamente y soporte VLAN Tagging (aquí hemos pillao lo que se denomina una Oferta, pero no nos ilusionemos demasiado, pues la instalación de unos drivers apropiados del fabricante podrían aportarnos funcionalidades adicionales, especialmente en Hyper-V R2).

    Recomendación: utilizar tarjetas de red en condiciones. Con esto, no quiero hacer ningún tipo de publicidad, pero probablemente con una tarjeta de red Intel, no tengamos problemas, y además podamos descargarnos drivers para Windows Server 2008, mientras que con una tarjeta de red más convencional (una SMC, una DLINK, una NVIDIA integrada en placa), podamos tener problemas de disponibilidad de drivers y no conseguir hacer funcionar VLAN Tagging (ojo, que no quiero decir que con una SMC, una DLINK, o una NVIDIA integrada en placa tengamos necesariamente estos problemas, y además, con el tiempo los fabricantes suelen ir publicando drivers para el resto de plataformas, pero con Intel la experiencia será más satisfactoria y más cara, evidentemente).

  • Disponer de un Switch de Red que soporte VLAN Tagging (802.1Q). Existe un amplio muestrario de Switches en el mercado, pero no todos soportan VLAN Tagging (802.1Q), por lo tanto, la primera en la frente. Así que, necesitaremos disponer de un Switch que soporte VLAN Tagging (802.1Q) y que sea gestionable, es decir, que nos podamos conectar por Telnet, SSH o Web, para configurar el Switch. Pero claro, cada Switch se gestiona de una forma diferente (la segunda en la frente también), ya que las opciones de configuración y comandos disponibles, varían entre modelos y fabricantes, por lo que en algún caso, puede requerir de algún esfuerzo excepcional para conseguir configurar nuestro entorno de red correctamente, especialmente en redes empresariales, formadas por múltiples switches geográficamente distribuidos, Switches Multi-Capa, configuraciones de Spannin-Tree, modelos de Switch diferentes (incluso de diferentes fabricantes), etc.

Con VMWare, la problemática no es muy diferente, ya que si no se dispone de una tarjeta de red soportada por VMWare, podremos encontrarnos con diferentes problemas, principalmente que VMWare no nos reconozca la tarjeta (ni VLAN Tagging, ni na de na).

Volviendo al tema de las tarjetas de red, últimamente he estado realizado pruebas con unas tarjetas de red Intel Gigabit CT Desktop Adapter, que me han gustado bastante, y que en Madrid pueden conseguirse por unos 26 euros en Alternate (el modelo BULK, es decir, sin caja ni drivers, a pelo). Inicialmente, tenía en mente adquirir unas Intel PRO/1000 GT Desktop Adapter (también disponibles en Alternate, por unos 25 euros), sin embargo, la Intel Gigabit CT Desktop Adapter se monta sobre un slot PCI Express, así que decidí adquirir esta en vez de la Intel PRO/1000 GT Desktop Adapter (esta última se monta sobre un slot PCI 32-bit).

Tarjeta de Red Intel Gigabit CT Desktop Adapter

La Intel Gigabit CT Dektop Adapter, tiene disponible drivers y software, tanto para Windows Server 2008 (en x86, x64 e IA64), como para Windows Server 2008 R2 (en x64 e IA64).

Un detalle curioso, es que Windows Server 2008 R2 detecta automáticamente esta tarjeta, sin embargo, Windows Server 2008 x64 detecta un nuevo dispositivo Ehernet Adapter pero no encuentra drivers para él, por lo que tendremos que instalar los drivers de Intel obligatoriamente, y tras ello, la tarjeta de red funcionará satisfactoriamente.

En cualquier caso, en Windows Server 2008 R2, también nos interesará instalar los drivers y software de Intel, por ejemplo, para poder aprovechar Virtual Machine Device Queues (VMDq). VMDq es una tecnología de Intel que permite descargar cierta activada de procesamiento de red al Hardware, liberando al Sistema Operativo (bueno, a Hyper-V) de dicha carga de trabajo, mejorando así el rendimiento de Red y del Host. En el caso de la Intel Gigabit CT Desktop Adapter que he estado probando, tiene la posibilidad de activar VMDq, y para ello es requisito instalar los Drivers y Software de Intel, y habilitar la opción Virtual Machine Queues (ojo, que sólo está disponible en Windows Server 2008 R2, y no lo está en Windows Server 2008). Aka va el correspondiente artículo de soporte de Intel: VLAN y VMDq en los adaptadores ethernet en Hyper-V.

Como se puede apreciar, la gran cantidad de Hardware disponible, tanto en lo referente a tarjetas de red como a electrónica de red (Switches), incluyendo drivers y software asociado, nos plantea una amplia variedad de escenarios, ante lo que resulta difícil poder concretar.

En relación con la configuración de los switches, como comentamos, podemos encontrar diferencias en el procedimiento de configuración entre un Switch y otro. A continuación, se incluye el caso de la configuración de un switch SMC 8024L2, un switch gestionable (por Web y por puerto serie, aunque no por Telnet ni por SSH), de 24 bocas gigabit de cobre (de forma opcional, es posible montarle hasta cuatro puertos de fibra gigabit) que soporta VLANs, 802.1Q, creación de hasta 8 Trunks, y muchas otras cosas más (muy chulo, para quién le interese, lo pillé en Ciudad WireLess, otra tienda indispensable de las de Madrid, por un precio inferior a 200 euros en la oferta que pillé en su día).

No es imprescindible configurar Switch Trunking para hacer funcionar VLAN Tagging, o al menos, en mi caso he conseguido hacerlo funcionar en ambos casos: utilizando Switch Trunking y sin utilizar Switch Trunking. A continuación se muestran las pantallas de configuración del Switch en ambos casos, teniendo en cuenta que en el SMC 8024L2 todos los puertos y Trunks por defecto pertenecen a la VLAN 1, la cual actúa como VLAN de gestión. Además, en nuestro caso de ejemplo, tenemos dos Host de Hyper-V, un Windows Server 2008 R2 conectado al puerto 13, y un Windows Server 2008 x64 conectado al puerto 14. Adicionalmente, existe un par de dispositivos (un punto de acceso WiFi y una interfaz de un ISA Server 2004) conectados a los puertos 1 y 3, pertenecientes a la VLAN 2, pero estos dispositivos no utilizan VLAN Tagging, estando configurados sus puertos con la VLAN 2 por defecto.

Configurar el Switch SMC 8024L2 para soportar VLAN Tagging (802.1Q) sin utilizar Switch Trunking, con Hyper-V

En este caso, no existirá ningún Trunk, o al menos, los puertos que nos interesan (el 13 y el 14, que son en los que están conectados los Host Hyper-V con sus tarjeta de red Intel Gigabit CT Network Adapter), no pertenecen a ningún Trunk.

En este caso, no existirá ningún Trunk, o al menos, los puertos que nos interesan (el 13 y el 14, que son en los que están conectados los Host Hyper-V con sus tarjeta de red Intel Gigabit CT Network Adapter), no pertenecen a ningún Trunk.

Comprobaremos la membresía de la VLAN ID 2, seleccionándola, y click sobre Modify.

Comprobaremos la membresía de la VLAN ID 2, seleccionándola, y click sobre Modify.

Seleccionaremos los puertos 13 y 14, como miembros de la VLAN ID 2, y aplicamos los cambios.

Seleccionaremos los puertos 13 y 14, como miembros de la VLAN ID 2, y aplicamos los cambios.

Mostramos la configuración VLAN de los puertos, que permanecerá por defecto. Podemos comprobar, como los puertos 1 y 3 tienen asignada la VLAN 2. Los puertos 13 y 14 están en la VLAN 1, pero como soportan VLAN Tagged y pertenecen a las dos VLAN que tenemos definidas, podrán acceder a la VLAN que necesiten, conforme se configuren las Redes Virtuales en las Máquinas Virtuales de Hyper-V.

Mostramos la configuración VLAN de los puertos, que permanecerá por defecto. Podemos comprobar, como los puertos 1 y 3 tienen asignada la VLAN 2. Los puertos 13 y 14 están en la VLAN 1, pero como soportan VLAN Tagged y pertenecen a las dos VLAN que tenemos definidas, podrán acceder a la VLAN que necesiten, conforme se configuren las Redes Virtuales en las Máquinas Virtuales de Hyper-V.

Configurar el Switch SMC 8024L2 para soportar VLAN Tagging (802.1Q) utilizando Switch Trunking, con Hyper-V

En este caso, crearemos dos Trunks. Recordemos que los Trunks se configuran para la conexión de Switch a Switch, por lo que configuraremos un Trunk para la conexión del Switch SMC 8024L2 al Switch Virtual del Host Windows Server 2008 R2, y del mismo modo, configuraremos otro Trunk para la conexión del Switch SMC 8024L2 al Switch Virtual del Host Windows Server 2008 x64.

En este caso, crearemos dos Trunks. Recordemos que los Trunks se configuran para la conexión de Switch a Switch, por lo que configuraremos un Trunk para la conexión del Switch SMC 8024L2 al Switch Virtual del Host Windows Server 2008 R2, y del mismo modo, configuraremos otro Trunk para la conexión del Switch SMC 8024L2 al Switch Virtual del Host Windows Server 2008 x64.

Comprobaremos la membresía de la VLAN ID 2, seleccionándola, y click sobre Modify.

Comprobaremos la membresía de la VLAN ID 2, seleccionándola, y click sobre Modify.

Asignaremos los nuevos Trunks creados, a la VLAN ID 2, ya que por defecto, ya pertenecían a la VLAN ID 1.

Asignaremos los nuevos Trunks creados, a la VLAN ID 2, ya que por defecto, ya pertenecían a la VLAN ID 1.

Actualizado 23/04/2010: Un problema adicional que he encontrado está en la utilización de la VLAN 1. Realizar la configuración del Switch como se comenta en este artículo, es correcto. Sin embargo, al configurar una Máquina Virtual de Hyper-V en la VLAN 1, dicha MV se me han quedado aislada. Es decir, al intentar hacer un ping desde dicha MV a un dispositivo conectado al Switch físico perteneciente a la VLAN 1 (o viceversa), no conseguía llegar. Esto no me ha ocurrido con la VLAN 2 (por poner un ejemplo), es decir, al configurar la misma Máquina Virtual de Hyper-V en la VLAN 2 (y cambiar el direccionamiento IP de la misma, evidentemente), si podía hacer un ping a cualquier otro dispositivo perteneciente a dicha VLAN. ¿Por qué este comportamiento? Ni puta idea, pa que mentir. Tengo claro que la VLAN 1 en el Switch SMC8024L2 (que es el utilizado en estas pruebas) es la VLAN de gestión (creo que otros Switches utilizan la VLAN 0, pero no pondría la mano en el fuego). Ahora, mi duda está, en que tengo entendido que en algunos casos (o switches) la VLAN de gestión puede tener algunas consideraciones especiales, en lo relacionado a su utilización y/o configuración, por lo que no tengo claro si esta problemática con la VLAN 1 se trata de algo específico de este Switch, si ocurre con otros o todos los demás Switches, o si no tiene nada que ver con el Switch y se trata de algún aspecto relacionado con la tarjeta de red o con Hyper-V. Sinceramente, no lo sé, lo que si tengo claro es las pruebas que he realizado y el resultado que he obtenido. Es bastante frustrante intentar hacer pruebas de configuración de VLAN Tagging con este Switch y utilizar la VLAN 1, al menos, en lo relacionado con Hyper-V, y por ello, quería aprovechar para plasmarlo aquí, ya que muchos no somos expertos en comunicaciones, y al enfrentarnos a tareas o proyectos que requieren este tipo de conocimientos, nos las damos una tras otra en la frente, y coño, duele. Confío que a alguien más le pueda ser de interés (para mí lo fue y mucho… demasiadas horas perdidas entre prueba y prueba, comprando y probando diferentes tarjetas de red, etc. ;-)

Otro apunte: si no recuerdo mal, en alguna de las pruebas que hice hace tiempo, me encontré que al configurar varias Máquinas Virtuales del mismo Host en la VLAN 1, estas se veían entre sí, pero no salían fuera, es decir, no eran capaces de comunicarse con otros dispositivos de red conectados a la VLAN 1, ya sean Máquinas Virtuales de otro Host configuradas en la VLAN 1 u otros dispositivos de red que no utilicen VLAN Tagging (es decir, que usen VLAN port based, por decirlo de algún modo). Creo, que si en dichas pruebas hubiese utilizado la VLAN 1, todo me habría funcionado a la primera... en fin... el tiempo lo cura todo...


[Fecha del Artículo (UTC): 16/04/2010]
[Autor: GuilleSQL]


Comentarios

Akuma - 15/02/2011 (UTC)
Una consideración muy importante que hay que tener en cuenta, es que las máquinas virtuales en Hyper-V SÓLO pueden utilizar VLANes si se escoge como adaptador de red el adaptador sintético. El adaptador de red emulado (Legacy Network Adapter) NO puede utilizar VLANes, ya que el dispositivo que emula (una DEC 21140) no soporta el protocolo 802.1q.

Salu2,
Akuma.



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas