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

El Protocolo Spanning-Tree (STP) mantiene la red física libre de bucles. Para la comunicación entre switches STP utiliza tramas multicast llamadas Bridge Protocol Data Units (BPDUs). No pienso torturar vuestras sobrecargadas mentes con una descripción profunda pero, os diré, que son las culpables de que cuando un camino se pierde entre dos switches, se active otro.

Lo que es menos conocido del STP son algunas funciones que debemos conocer y controlar cuando conectamos un host ESXi, me refiero al BPDU Guard y al BPDU Filter.

Cuando conectamos una NIC de un host ESXi a un switch Cisco, vemos como los leds del puerto se iluminan con una luz naranja durante más segundos de los que quisiéramos (casi un minuto) y luego se ilumina con luz verde.

Durante el periodo de luz naranja, STP analiza la NIC recién conectada para evitar bucles no esperados. Como estamos conectando un host ESXi cuyos vSwitches o dvSwitches no tiene STP por definición, ni pueden generar bucles, podemos evitar esta espera saltándonos el análisis de STP, configurando el puerto en un switch Cisco como portfast (en un Cisco Catalyst con IOS) o como edge port (en un Cisco Nexus con NX-OS), es decir:

sw_ios(config)# interface FastEthernet 0/20

sw_ios(config-if)# spanning-tree portfast trunk

… o bien …

sw_nxos(config)# interface Ethernet 0/20

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

Esta configuración es solo un medio para acelerar la puesta en servicio de un puerto físico que sigue estando bajo el dominio de STP, por tanto, si llegarán BPDUs a este puerto las procesaría como tal. Es decir, podríamos inducir al STP a realizar cambios en la topología de la red haciéndola impredecible.

Para evitar esto tenemos BPDU Guard, una función de los puertos portfast que controla la llegada de BPDUs, por donde no se las espera, bloqueando el puerto como mecanismo de seguridad para evitar males mayores, como un cambio inesperado de la topología de STP.

Un puerto portfast sigue dentro del dominio STP y, por tanto, sigue enviando BPDUs. Para evitarlo tenemos la función BPDU filter que permite no enviar tramas BPDUs por este puerto. Esto es lo que espera el host ESXi.

Se activa a nivel de interface con los comandos:

sw(config-if)# spanning-tree bpdufilter enable

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

Siendo los mismos comandos tanto en Cisco IOS como en Cisco NX-OS.

¿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 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.

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.