Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

Hace unos meses escribí un post hablando de la conexión de un ESX a un switch físico con Cisco IOS.

Opsss… ¡¡hace más de un año que lo escribí!! Menos mal que sigue siendo válido…

Ahora ha llegado el momento de agarrar un servidor ESXi y conectarlo a un switch físico con Cisco NX-OS. Cisco NX-OS es la evolución de Cisco IOS adaptado a las necesidades del Datacenter. Concretamente, para el ejemplo, vamos a utilizar un Cisco Nexus de la familia 5000.

Pero antes, definiré el concepto BPDU para evitar que nadie se quede por el camino:

Bridge Protocol Data Units (BPDUs) son paquetes de red que contienen información del protocolo spanning tree (STP). Los switches mandan BPDUs usando la dirección MAC del switch como origen y la dirección MAC multicast 01:80:C2:00:00:00 como MAC destino.

Existen tres tipos de BPDUs: De configuración de la topología, de notificación de cambio topológico y de confirmación de notificación del cambio topológico. Por defecto se envían cada 2 segundos.

Volviendo al Cisco Nexus 5000, la configuración de cada puerto del switch físico donde se conecta una vmnic podría ser algo así:

router(config)# interface Ethernet 1/12

router(config-if)# switchport

Configura el puerto como un interfaz L2

router(config-if)# switchport mode trunk

Configura el puerto como trunk IEEE 802.1q

router(config-if)# switch trunk allowed vlan 11-14

Define las VLANs que permitimos pasar por este puerto de trunk

router(config-if)# spanning-tree port type edge trunk

Es un puerto que no emite BPDUs de spanning-tree y no participa en el cálculo de la topología de STP, ha de ser así, el servidor ESXi no sabe lo que es una BPDU de spanning tree

router(config-if)# spanning-tree bpduguard enable

Si recibimos BPDUs bloquea el puerto, de un ESXi no vendrán BPDUs, evitamos de esta manera que se conecte otro switch a este puerto

router(config-if)#

Aunque esta configuración es correcta, no es la habitual. Para evitar repetir esta configuración en cada puerto que tenga la misma configuración creamos un port-profile e incluimos en él los comandos comunes. Luego, asignamos puertos al port-profile, aplicándoles los comandos al interfaz. Facilita mucho el cambio de configuraciones.

router(config)# port-profile GRUPO1

router(config-ppm)# switchport

router(config-ppm)# switchport mode trunk

router(config-ppm)# switch trunk allowed vlan 11-14

router(config-ppm)# spanning-tree port type edge trunk

router(config-ppm)# spanning-tree bpduguard enable

router(config-ppm)# state enabled

router(config-ppm)# exit

router(config)# interface Ethernet 1/12

router(config-if)# inherit port-profile GRUPO1

Aplicamos los comandos del port-profile a este interface

router(config-if)# exit

router(config)# exit

¿Se pueden construir grandes infraestructuras de cloud sin switches diseñados para datacenter? ¿Qué opináis?

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo. En los últimos años hemos visto un fenómeno llamado la inversión de la pirámide, hace unos años el 70% de los usuarios estaba en la central de la organización y el 30% estaban en las oficinas remotas, ahora esto a cambiado, el 70% de los usuarios están en sedes remotas y usuarios móviles y el 30% en la sede central.

Además las migraciones de Datacenter Corporativo hacia Proveedores de Servicios hacen que cada vez mas empresas tengan un 100% de usuarios remotos.

Una de las tecnologías aplicadas para resolver el problema de la concentración de aplicaciones es la aceleración WAN.

Los aceleradores de WAN mitigan el problema de las latencias de las comunicaciones remotas, así como la aceleración con cachés, balanceo de servicios, tolerancia a fallos y técnicas de de-duplicación WAN, incluso me atrevería a decir que se utilizó esta técnica antes en aceleración WAN que en almacenamiento.

Veamos una tabla de mejoras:

¿Como podemos atender el cada vez mayor número de usuarios que pretenden conectarse a nuestra red?

La incorporación de la virtualización complican el escenario y supone nuevos retos a este cambio de habito en la entrega de servicios en las empresas.

Nuestro aceleradores de WAN basadas en appliances no están diseñados para entornos multi-tenant que encontramos en grandes compañías y proveedores de servicios. La solución es fácil, pasa por virtualizar también estos equipos.

Esto ha hecho Cisco con el Cisco Virtual WAAS, a partir de ahora vWAAS. Es un Virtual Appliance que acelera el tráfico WAN hacia servicios virtualizados o lo que es lo mismo, un vWAAS por cada entorno aislado o cliente.

Cisco vWAAS necesita la tecnología vPath de Cisco Nexus 1000V y utiliza el protocolo WCCP para hacer su trabajo.

Ya quedan pocas funciones por virtualizar ¿Cuál será la siguiente?

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

Hola amigos, soy Florián Murillo. Hoy hablamos de Cisco Virtual Security Gateway, o lo que es lo mismo la solución de Cisco para la creación de zonas seguras dentro de la infraestructura virtual, integrado con Cisco Nexus 1000V.

Cisco Virtual Security Gateway tiene dos dependencias, necesita:

• Cisco Nexus 1000V ya que utiliza la tecnología vPath del switch virtual para su desempeño.
• Cisco Virtual Network Management Center, o sea la consola desde donde se crean y aplican las zonas y las reglas de filtrado.

Veamos como funciona Cisco VSG integrado con Cisco Nexus 1000V, para ello utilizaremos un ejemplo de flujo que penetra en la zona.

1. El primer paquete de un flujo que llega a la zona es capturado por vPath

2. vPath retransmite el paquete al Cisco VSG para su análisis.

3. Cisco VSG responderá denegando el acceso y se acabó la conexión, o bien, permitiendo el tráfico.

4. En ese momento se aplican en caliente ACLs de acceso para permitir que este tráfico concretamente SI pueda penetrar en la zona.

5. El resto del flujo no pasa por el VSG, las ACLs se mantienen hasta que finaliza el flujo.

Me parece una estrategia hábil para un despliegue masivo de seguridad.

La disponibilidad de Cisco VSG se realiza con 2 virtual appliances en activo/standby.

En esta categoría de productos hay muchos competidores: VMware, Reflex Systems o Altor Networks (ahora parte de Juniper) entre otros. La competencia siempre enriquece la creatividad de los fabricantes y nos beneficiamos todos. ¿Crees que este tipo de productos son una necesidad real o de marketing?

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

Hola amigos, soy Florián Murillo. Las novedades aparecidas en la versión 1.4 (incluyo la 1.4a) de Cisco Nexus 1000V son importantes y a continuación detallaré las más destacadas desde mi punto de vista:

Cisco vPath: Es una novedad de la versión 1.4 y, su sola presencia, justifica la nueva versión.

Se integra con los VEM, por tanto se instala en todos los host que participan del switch distribuido.

Su misión es interceptar el tráfico, interrogar a los Virtual Service Nodes y ejecutar las políticas definidas. Los Virtual Service Nodes existentes en este momento son: Cisco vWAAS, el Cisco VSG y el Cisco ASA 1000V.

Class-Based Weighted Fair Queueing (CBWFQ): Es la respuesta de Cisco al Network Resources Pool de los switches distribuidos de VMware.

Las características destacadas de CBWFQ son:

• La estrategia de colas permite que una clase de tráfico no impida otros tráficos.
• Respeta el ancho de banda garantizado para cada clase de  tráfico.
• Optimiza la utilización del ancho de banda.

Dispone de varios protocolos ya definidos: vMotion, FT-Logging, iSCSI, NFS, ESX Management, N1K Control, N1K Packet y N1K Management.

Compatibilidad con vSphere 5: En la versión 1.4a de Cisco Nexus 1000V nos encontramos con soporte para vSphere 5, es importante, en especial si pensamos en migraciones futuras de arquitecturas existentes.

El resto son mejoras de funcionalidades ya existentes, algunas de ellas muy demandadas a nivel de seguridad. Por ejemplo la posibilidad de poner ACLs en el interfaz de gestión del switch distribuido, ya que el firewall de ESXi no lo contempla.

¿Qué nos depara el futuro de Cisco Nexus 1000V?

Apertura a nuevas plataformas de virtualización, VXLAN y otras sutilezas que llegarán pronto… Pero de eso hablaremos mas adelante.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

Hola amigos, soy Florián Murillo. Estamos en un entorno muy cambiante, tanto que lo DICHO este mes puede quedar obsoleto el mes próximo… Por ese motivo, durante las próximas semanas, desarrollaré el estado ACTUAL de las tecnologías Cisco relacionadas con el Virtual Networking.

¿Qué es Virtual Networking?

Es la virtualización de la capa de acceso de switches; aquellos switches donde están conectados los servidores que también vamos a virtualizar.

O lo que es lo mismo: Los switches virtuales donde están conectados los servidores (ahora virtuales).

Se esquematiza en la figura siguiente:

Esto es lo que hace que los responsables de configurar los switches físicos a los que se conectarán los hosts ESX/ESXi deban pensar en estos hosts como switches, ya que en realidad están conectados a switches (virtuales).

Características únicas de los switches virtuales:

1. Los switches virtuales no se pueden apilar entre ellos, solo podemos conectar a un switch virtual interfaces físicos del host, las vNICs de las VMs y los puertos de servicio del kernel (vmk y vswif).
2. Los switches virtuales no tienen spannning-tree (STP), por tanto recordar deactivar STP en los puertos de los switches físicos donde se conectan los hosts ESX.
3. Los switches son de nivel 2 (L2), es decir, requieren “ayuda” externa para encaminar tráfico entre VLANs.

Cisco entra en el Virtual Networking con la llegada de vSphere 4 y concretamente utilizando la vNetwork Appliance API.

El switch virtual distribuido (dvSwitch) es un elemento básico para la implantación de grandes infraestructuras virtuales y, por extensión, para el despliegue de soluciones IaaS bajo el modelo de cloud computing. El elemento diferencial es su arquitectura. Las configuraciones se despliegan automáticamente a todos los hosts que participan en el dvSwitch, sin necesidad de repetir el cambio host por host, como ocurre con el vSwitch clásico de VMware.

El dvSwitch aporta funcionalidades nuevas respecto a los vSwitches, que podemos resumir en Seguridad, QoS, Gestión y Arquitectura abierta.

Cisco basa su arquitectura de Virtual Networking en Cisco Nexus 1000V, que incorpora características adicionales respecto dvSwitch.

Desde su aparición en el 2009, han aparecido productos que extienden las funcionalidades de Cisco Nexus 1000V, como son:

• Cisco Virtual WAAS
  • Solución de aceleración WAN y balanceo.
• Cisco Virtual Security Gateway
  • Solución de firewall por zonas, de forma que tengamos varios servicios de clientes diferentes en el mismo segmento de red y poder definir que se puede ver y por quien…
• Cisco ASA 1000V (que describimos la semana pasada)
  • Firewall perimetral y de filtrado entre VMs dentro de una zona.

Estos elementos se complementan con funcionalidades y soluciones clave:

• Cisco Nexus vPath
• Cisco Virtual Network Management System

En los próximos post, hablaremos de las novedades que nos aporta cada producto, empezando por la base: Cisco Nexus 1000V y Cisco Nexus vPath. ¿Qué opináis de la estrategia de Cisco en el tema Virtual Networking?

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de abajo. Gracias por el apoyo.

Hola amigos, soy Florián Murillo. En el VMworld 2011 de agosto en Las Vegas, Cisco ha anunciado grandes novedades para la infraestructura virtual de VMware.

Me centraré en una de ellas, en el Cisco ASA 1000V cloud firewall,  es un virtual firewall en formato virtual appliance que se integra con Cisco Nexus 1000V, estará disponible en la primera mitad del 2012.

Como es habitual en Cisco (y otros fabricantes) primero llega el marketing y detrás el producto, las características principales del nuevo producto son:

Proporciona cortafuegos perimetral “multi-tenant”, o lo que es lo mismo, se puede utilizar para securizar varios clientes en entornos aislados.

Proporciona VPN site-to-site, las conexiones VPN de clientes remotos, como Cisco AnyConnect no están soportadas en esta primera versión.

Requiere para su funcionamiento, como pre-requisito, de Cisco Nexus 1000V, el switch distribuido de Cisco.

Se gestiona desde el Cisco Virtual Network Managemeng Center (VNMC) compartiendo consola con el Cisco Virtual Security Gateway (otro día hablamos de este producto).

La versión inicial no soportará vCloud Director, pero como Cisco Nexus 1000V está soportado por vCloud Director, no dudo que se soportará en siguientes versiones.

Está soportado desde vSphere 4.1 y se basa en la versión de software Cisco ASA v.8.4

El licenciamiento será por sockets, siguiendo la línea de Cisco Nexus 1000V y Cisco Virtual Security Gateway.

Resumiendo: Es una versión inicial que alegrará a muchos consumidores de tecnología Cisco, aunque con ausencias esperadas, las VPNs de usuarios remotos y la no integración de vCloud Director hacen que denominemos esta versión como “la primera”.

Seguimos esperando el precio final pero, me surge una duda: ¿Puede el mantenimiento y soporte de la versión virtual de un producto ser mas cara que su homónimo del mundo físico?

Lo sabremos en unas semanas

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

Hola, ¿que tal? Soy Jose Maria Gris y como cada martes vengo a comentar temas del ecosistema de la virtualización.

Vengo colaborando con el nuevo negocio de canal de Dell y si hasta ahora podíamos decir que sus productos eran buenos, ahora para ser honestos he de felicitar el esfuerzo de todos lo colaboradores de Dell, todos ellos orquestados magistralmente por Inma Martínez desde Magirus en su rama de canal.

Tengo que dejar claro que este no es un post esponsorizado, sino estaría tagueado como tal, y lo que comento aquí es fruto de mi experiencia.

En otro sentido, es impresionante el esfuerzo que está haciendo Michael Dell para preparar una empresa que pueda ofrecer toda la solución en cloud que cualquier empresa precise.

Si bien hace un tiempo Dell era conocido por “sus PCs” y su característica forma de comercializar a través de la Web (ha sido modelo de excelencia en escuelas de negocio por años), después sus servidores empezaron a “sonar” por ahí. Calidad, buen funcionamiento y precio muy competitivo, buena formula para ganarse al mercado. Siguió la adquisición de Equallogic y posteriormente Compellent. Dos sonadas adquisiciones por lo diferencial del producto.

Ahora ha adquirido Force10, empresa que desarrolla elementos de switching, networking y comunicaciones de alto rendimiento. Force10 ha anunciado que tiene un patente con importantes avances sobre backplanes de alto rendimiento.

Si Cisco ya construyó su vBlock con sus UCS, sus Catalyst, usando almacenamiento EMC dentro de su alianza, es de suponer que Dell presentará cara con muy buenos productos, quedaremos a la espera si van a paquetizar alguna solución para infraestructura de virtualización en un futuro próximo.

Michael, an incredible job!

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

Ya esta disponible online el episodio #22 en virtualizacion.tv, el programa de televisión web que ayuda a profesionales como tú, a entender la virtualización de sistemas y el cloud computing en españo.

En el episodio de esta semana, hablaremos de Cisco, un nuevo forastero en el mundo de los servidores de tipo blade, responderemos a la pregunta de un usuario en relación a la importancia de los heartbeats en la máquinas virtuales y te enseñare otra utilizad impresionante relacionada con el mundo de la virtualización y del could computing.

Gracias a todos los que dejaron su comentario en los episodios anteriores. Si aun no has tenido la oportunidad de hacerlo, por favor, entra en virtualizacion.tv hazlo ahora. Tu apoyo permitirá que este programa de televisión web sobre la virtualización de sistemas y el cloud computing en español, pueda continuar beneficiando a muchas personas.

¿Crees que este videopost puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y me gustaría hacer algunas reflexiones acerca de la “carrera” entre Cisco y Brocade por liderar el “transporte” del futuro.

Cisco es el líder en el transporte por Ethernet y Brocade en el transporte por Fibre Channel, solo hay que ver sus cuotas de mercado, son claramente dominadores en sus ámbitos naturales.

Por otro lado, la virtualización rompe las barreras que existen entre los equipos de especialistas, me refiero a comunicaciones, almacenamiento, seguridad, sistemas y aplicaciones entre otros, demandando al I/O velocidad e elasticidad.

Cisco presentó hace un tiempo ya, su familia Cisco Nexus, switches que integran las redes Ethernet y Fibre Channel, utilizando Ethernet (FCoE) como transporte a 10Gb/s pero evolucionará, con el estandar IEEE P802.3ba hacia 40Gb/s y 100Gb/s en el futuro, con total seguridad.

Por otra parte Brocade acaba de lanzar sus primeras soluciones con soporte de 16Gb/s en Fibre Channel, el chasis Brocade DCX 8510 Backbone y el atractivo Brocade 6510 con 48 puertos 16Gb/s en 1U, no está nada mal. Además de disponer del Brocade VDX 6720, producto que compite en el terreno de FCoE con Cisco Nexus.

Cada uno tiene un caballo ganador, Brocade conoce como nadie Fibre Channel y Cisco domina el atractivo mundo de la unificación de las redes, o como ellos lo llaman “Unified Fabric”.

Para hacer este tema mas divertido, ya se está trabajando en un estandar de Fibre Channel a 32Gb/s.

Mi pregunta es ¿el mercado que pide velocidad o integración?

Fibre Channel a 16Gb/s es una solución que cautivará a los administradores de almacenamiento de grandes sistemas, pero si pienso en arquitecturas cloud con aprovisionamiento dinámico de recursos, opino que FCoE es el ganador, permite aprovechar la virtualización del I/O, cosa que es mas complicado con las HBAs de Fibre Channel.

Por tanto, a mi modo de ver, en el futuro próximo, la capacidad de integración y la elasticidad de FCoE tendrá mas peso que la velocidad.

¿Que opináis amigos? Hasta la semana próxima.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigos, soy Florián Murillo. Los amigos de Cisco Systems, empeñados en liderar el mercado de tecnologías de Data Center, no dejan de aportar soluciones nuevas al mercado, hoy hablaremos de la Cisco UCS P81E Virtual Interface Card, que aporta virtualización a los interfaces de I/O.

Es una tarjeta para los Cisco UCS C-Series, servidores rack, aunque existe versión para los Cisco UCS B-Series, que son los servidores blades de la casa.

Con la tarjeta en la mano, nos encontramos con una PCI 8x con dos interfaces de 10Gb con conector SFP+. El hipervisor lo que ve son, hasta 2 interfaces HBA y hasta 16 interfaces ethernet, por cada placa física (en el futuro 128 interfaces virtuales).

Las tramas Fiber Channel se encapsulan en Ethernet (FCoE) y se transportan en una VLAN, por tanto necesitamos una infraestructura de red Unified Fabric, como lo llama Cisco, este concepto lo escucharemos mucho en los próximos años.

Este tipo de interfaz es ideal para ampliar un cluster con 8-12 interfaces de red, sin hipotecar nuestro futuro invirtiendo en tecnologías de 1Gb, cuando nuestro cuerpo nos pide invertir en 10Gb.

También es muy útil para entornos VDI con muchos segmentos de red, por permite asignar “bandwidth” a las VLANs en vez de interfaces.

Por ahora es compatible con vSphere 4.0 U1, amigos, los tiempos están cambiando …

Hola amigos, soy Florián Murillo y en los cursos de VMware que imparto como VCI detecto que los módulos de networking requieren mas esfuerzos que otros, por eso he pensado que podía ser de utilidad explicar con claridad y brevedad (a ver si lo consigo) como se ha de configurar un switch Cisco Catalyst para conectar sistemas ESX/ESXi.

¿Que nos recomienda VMware?

- Los puertos de los switches donde se conectan los ESX/ESXi se han de configurar con trunk VLAN 802.1q

switchport mode trunk

- Los puertos de los ESX/ESXi no participan de negociación en protocolos como DTP, PAgP o LACP, por tanto desactivar protocolos dinámicos de configuración en los puertos de los switches.

switchport nonegotiate

- Los puertos de los ESX/ESXi no participan en negociaciones de STP (spanning tree protocol) por tanto se ha de desactivar en lor puertos de los switches el envío de BPDUs de STP.

spanning-tree portfast trunk

- En Cisco, la native VLAN es la VLAN por la que circula el tráfico de protocolos de nivel 2, y los que no tiene un tagging de VLAN, por tanto, todos los port-groups han de tener VLAN ID para prevenir que algún tráfico se “cuele” en la native VLAN en vez de “circular” por la VLAN que le toca.

switchport trunk native vlan 99

- Otra cosa a cuidar es que ninguna VLAN tenga el mismo número de VLAN que la native VLAN.

- Todos los puertos de los switches donde se conecta un ESX/ESXi han de permitir, solamente, el paso de las VLANs que se han configurado en la infraestructura virtual.

switchport trunk allowed vlan 10-12, 20

Si vemos la configuración completa del puerto, queda de la siguiente manera:

description PUERTO DE ESX
switchport trunk native vlan 99
switchport trunk allowed vlan 10-12, 20
switchport mode trunk
switchport nonegotiate
spanning-tree portfast trunk

Estoy de acuerdo que esta configuración no engloba todas las posibilidades y diseños, pero en los temas cubiertos se ajusta a las Best Practices de VMware.

Espero que os sea de ayuda.

Me acaban de llegar a las manos las hojas técnicas de los nuevos servidores de Cisco.

Mucho hemos oído hablar de que Cisco quería entrar en el tema de Servidores de la mano de su coalición con VMware. Y aquí están.

Os presento al UCS C200 M1 High Density Rack-mount server. Servidor de 1U con 2 sockets y con 12 slots de memoria, llegando a poder instalar 96 Gb con alta densidad o bien llegar a tasas altas con precios asequibles.

Incorpora 2 Nics de 10 Gb y un nuevo chipset que es capaz de gestionar la memoria para ofrecer más memoria de la que realmente tiene (me han dicho un número de veces que quiero antes validar.)

A ver si me cae uno en demo y os cuento cosas bonitas sobre ellos….. también hemos de ver los precios.

Podéis ver una demo interactiva en este link

Según pública hoy eweek.com magazine, VMware y Cisco podrían estar trabajando sobre la idea de usar la tecnología VMware VMotion para poder mover maquinas virtuales en caliente desde un centro de datos a otro.

Esta nueva funcionalidad seria de especial interés para aquellos centros de datos que ya están virtualizados y quieren disponer de un plan de contingencias en caso de fallo del centro de datos primario.

Según se comenta en el artículo de eweek.com, VMware y Cisco ya han demostrado esta tecnología durante el evento de Cisco Live Show. Sin embargo, fuentes oficiales de VMware han comentado por activa y por pasiva, que esta nueva funcionalidad requiere aun mucho trabajo para que llegue a ser una realidad y pueda desplegarse en los centros de datos.

Si esta funcionalidad de migración de maquinas virtuales en caliente entre centro de datos llega a buen puerto, no podre llegar a imaginar cómo Cisco y VMWare habrán solucionado el problema de las altas latencias en las líneas entre los centros de datos y como habrán solventado el problema del “disk locking” en los volumenes VMFS. Supongo que usaran una tecnología similar a la que se usa hoy con Storage VMotion!.

Haz clic en este link para ver el artículo completo:

http://www.eweek.com/c/a/IT-Infrastructure/Cisco-VMware-Look-to-Move-VMs-Between-Data-Centers-583506/?kc=EWKNLINF07082009STR1

Cisco y VMware han anunciado recientemente que el nuevo switch virtual de Cisco, Cisco Nexus ® 1000V, estará soportado en VMware vSphere 4.

La solución combinada se ha diseñado para ayudar a los clientes a simplificar la virtualización y la gestión de servicios de red para entornos Cloud. Esto significa que a partir del 21 de abril, el Nexus 1000V estará disponible en la lista de precios de VMware pero no estará disponible hasta el 12 de Junio.

El Nexus 1000V es parte del paquete vSphere Enterprise Plus y estará disponible para todos los revendedores y distribuidores de VMware, incluso si estos distribuidores no son Partners de Cisco.

Puedes ver más detalles técnicos del switch virtual de Cisco Nexus 1000v en este link:

http://www.vmware.com/products/cisco-nexus-1000V/index.html

This blog post is part of Zemanta’s “Blogging For a Cause” campaign to raise awareness and funds for worthy causes that bloggers care about.

Cisco® y VMware®  anunciaron ayer un acuerdo OEM ( Original equipment manufacturer) el cual incorporara ingeniería de producto, ventas integradas y estrategias de soporte para la virtualización del centro de datos y la informática unificada.

El anuncio se hizo público ayer por John Chambers, CEO de Cisco,  y otros altos executivos como por ejemplo Paul Otellini, CEO de Intel, Paul Maritz, Presidente y CEO de  VMware, Joe Tucci, CEO de EMC.

“La combinación resultante de la solución de Computación de Sistemas Unificados de Cisco,   con la plataforma de virtualización de VMware,  proporcionará a los clientes una potente y única solución virtualizada así como un sistema informático físico inteligente y unificado”.

Veremos a ver cuántos clientes es capaz de ganar este  nuevo Blade de Cisco sobre los líderes del mercado de sistemas Blade; Dell,HP, IBM.