VMware Hands-on Labs - HOL-1703-SDC-1-ES


Descripción general del laboratorio: HOL-1703-SDC-1: Recorrido por las funciones de VMware NSX

Orientación sobre el laboratorio


Nota: Le llevará más de 90 minutos completar este laboratorio. Su expectativa debe ser solo la finalización de entre 2 y 3 módulos durante el tiempo del que disponga.  Los módulos son independientes unos de otros, por lo que puede empezar por el comienzo de cualquiera de los módulos y continuar desde allí. Puede utilizar el Índice para acceder a cualquier módulo que desee.

Se puede acceder al Índice en la esquina superior derecha del manual de laboratorio.

VMware NSX es la plataforma de virtualización de redes para el centro de datos definido por software (Software-Defined Data Center, SDDC) y el eje central de este laboratorio. Durante el laboratorio, lo guiaremos por el recorrido de las funciones básicas de NSX. Comenzaremos con la instalación típica de NSX y todos los componentes requeridos. Luego, seguiremos con Switching Lógico y Enrutamiento Lógico para que pueda comprender en profundidad estos conceptos. A continuación, analizaremos el Gateway de servicios de NSX Edge y la forma en la que se pueden suministrar servicios comunes, como DHCP, VPN, NAT, enrutamiento dinámico y balanceo de carga. Por último, aprenderemos a armar un bridge entre una VLAN física a una VXLAN y, luego, nos ocuparemos del firewall distribuido. La lista completa de los módulos del laboratorio se encuentra a continuación. Los módulos son independientes, por lo que podrá realizar cada módulo en el orden que desee.

Lista de los módulos del laboratorio:

Directores del laboratorio:

Este manual práctico se puede descargar desde el sitio de documentos de laboratorios prácticos que se encuentra en la siguiente página:

[http://docs.hol.vmware.com]

Este laboratorio puede estar disponible en otros idiomas.  Para configurar la preferencia de idioma y obtener un manual localizado con el laboratorio, puede usar este documento como ayuda para orientarse en el proceso:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Ubicación de la consola principal

 

  1. El área en el recuadro ROJO contiene la consola principal.  El manual de laboratorio se encuentra en la pestaña ubicada a la derecha de la consola principal.
  2. En algunos laboratorios en particular, pueden haber consolas adicionales en diferentes pestañas, en la esquina superior izquierda. Se le indicará que abra otra consola específica si es necesario.
  3. El laboratorio comienza con 90 minutos en el temporizador.  El laboratorio no se puede guardar.  Todo el trabajo debe llevarse a cabo durante la sesión del laboratorio.  Sin embargo, puede hacer clic en el botón EXTEND para prolongar el tiempo.  Si se encuentra en un evento de VMware, puede prolongar el tiempo del laboratorio dos veces, hasta 30 minutos.  Con cada clic, obtiene 15 minutos adicionales.  Fuera de los eventos de VMware, puede prolongar el tiempo del laboratorio hasta 9 horas y 30 minutos. Con cada clic, obtiene una hora adicional.

 

 

Métodos alternativos para el ingreso de datos por teclado

Durante este módulo, ingresará texto en la consola principal. Además de escribir directamente en la consola, hay dos métodos muy útiles para ingresar datos que facilitan el ingreso de datos complejos.

 

 

Haga clic y arrastre el contenido del manual práctico hacia la ventana activa de la consola

También puede hacer clic y arrastrar el texto y los comandos de la interfaz de línea de comando (Command Line Interface, CLI) directamente desde el manual práctico hacia la ventana activa de la consola principal.  

 

 

Acceso al teclado internacional en línea

 

También puede utilizar el teclado internacional en línea que se encuentra en la consola principal.

  1. Haga clic en el ícono del teclado que se encuentra en la barra de tareas del inicio rápido de Windows.

 

 

Haga clic una vez en la ventana activa de la consola.

 

En este ejemplo, usará el teclado en línea para ingresar el símbolo "@" que se utiliza en las direcciones de correo electrónico. En los diseños de teclados de EE. UU., el símbolo "@" se ingresa mediante Shift-2.

  1. Haga clic una vez en la ventana activa de la consola.
  2. Haga clic en la tecla Shift.

 

 

Haga clic en la tecla @

 

  1. Haga clic en la tecla"@".

Observe que se ha ingresado el símbolo @ en la ventana activa de la consola.

 

 

Observe el sector inferior derecho de la pantalla.

 

Asegúrese de que se hayan completado todas las rutinas de inicio del laboratorio y esté listo para comenzar. Si ve otro mensaje que no sea "Ready", aguarde unos minutos.  Si el laboratorio no ha cambiado a "Ready" luego de 5 minutos, solicite asistencia.

 

 

Marca de agua o petición de activación

 

Cuando inicie el laboratorio por primera vez, es probable que aparezca una marca de agua en el escritorio que indique que Windows no se activó.  

Una de las ventajas más importantes de la virtualización es que las máquinas virtuales pueden moverse y ejecutarse en cualquier plataforma.  Los laboratorios prácticos utilizan esta ventaja, por lo que podemos ejecutar los laboratorios en múltiples centros de datos.  Sin embargo, estos centros de datos pueden no tener procesadores idénticos, lo que genera una verificación de activación de Microsoft mediante Internet.

Tenga la seguridad de que VMware y los laboratorios prácticos se encuentran en cumplimiento normativo absoluto con los requisitos de licencia de Microsoft.  El laboratorio que utiliza es un pod autónomo y no posee acceso total a Internet, que es lo que Windows requiere a fin de verificar la activación.  Sin acceso total a Internet, este proceso automatizado falla y se muestra esta marca de agua.

Este problema superficial no afecta el laboratorio.  

 

Módulo 1: Descripción técnica de la instalación (15 minutos)

Introducción a la implementación de NSX


VMware NSX es la plataforma de virtualización de redes líder que suministra el modelo operacional de una máquina virtual para la red. De la misma manera que la virtualización de servidores permite el control extensible de las máquinas virtuales que se ejecutan en un depósito de hardware de servidor, la virtualización de redes con NSX proporciona una interfaz de programación de aplicaciones (Application Programming Interface, API) centralizada para aprovisionar y configurar redes lógicas aisladas que se ejecutan en una única red física.

Las redes lógicas separan los servicios de redes y la conectividad de las máquinas virtuales de la red física, lo que les brinda a las empresas y los proveedores de nube flexibilidad para colocar máquinas virtuales en cualquier parte del centro de datos, o para migrarlas allí, mientras siguen siendo compatibles con los servicios de red de capa 4 a 7 y conectividad de capa 2 y 3.

En este módulo, nos enfocaremos en cómo realizar la implementación propiamente dicha de NSX en el entorno. Dentro del entorno de laboratorio, ya se realizó la implementación propiamente dicha.

En este módulo, se incluyen las siguientes lecciones:


 

Componentes de NSX

 

Durante este laboratorio, realizará el proceso indicado para instalar los distintos componentes, entre los que se incluyen NSX Manager, controladores de NSX y, luego, la instalación de módulos del kernel dentro del hipervisor.

 

Simulación Interactiva de Hands-on Labs: Instalación y configuración de NSX


Esta porción del laboratorio es presentada como una Simulación Interactiva de Hands-on Labs.  Esta simulación guiará durante la instalación y configuración del NSX Manager.

  1. Hacer clic aquí para abri la simulación interactiva.  Abrirá un nuevo navegador o pestaña.
  2. Al finalizar, hacer click en el link "Return to the lab" en la esquina derecha superior de la ventana del navegador o cerrar la ventana para continuar con este laboratorio.

Conclusión del módulo 1


En este módulo, se demostró lo simple que es instalar y configurar NSX para comenzar a suministrar servicios de software a las capas dos a siete.

Primero, abordamos la instalación y configuración del dispositivo de NSX Manager, en el cual se incluía la implementación, la integración con vCenter y la configuración de registros y respaldos. Luego, abordamos la implementación de instancias de NSX Controller, como el plano de control y la instalación de los vSphere Installation Bundles (VIB), que son módulos de kernel que se transfieren al hipervisor. Por último, abordamos el proceso de implementación automatizada de los VXLAN Tunnel Endpoints (VTEP), la creación de una VXLAN Network Identifier (VNI) y la creación de una zona de transporte.


 

Ha finalizado el módulo 1.

Felicitaciones por completar el módulo 1.

Si desea obtener más información sobre la implementación de NSX, revise el centro de documentación de NSX 6.2 mediante la URL que se muestra a continuación:

Continúe con cualquiera de los siguientes módulos que sea de su interés:

Lista de los módulos del laboratorio:

Directores del laboratorio:

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Módulo 2: Conmutación lógica (30 minutos)

Descripción general del módulo Conmutación lógica


En este laboratorio, primero analizará los componentes clave de VMware NSX. A continuación, se detallan otros aspectos clave incluidos en este módulo:

1) Con la incorporación del clúster de NSX Controller, es posible prescindir de los requisitos de soporte para el protocolo de multicast en la estructura de conexión física. Entre las funciones de un clúster de controlador, se incluye la resolución de VTEP, IP y MAC.

2) Podrá crear un switch lógico y, luego, añadir dos VM al switch lógico que creó.

3) Por último, revisaremos la escalabilidad y la alta disponibilidad de la plataforma de NSX.


Conmutación lógica


En esta sección, realizará los siguientes procedimientos:

  1. Confirmación de la preparación para la configuración de los hosts
  2. Confirmación de la preparación de la red lógica
  3. Creación de un nuevo switch lógico
  4. Asociación del switch lógico al gateway de NSX Edge
  5. Incorporación de VM al switch lógico
  6. Prueba de la conectividad entre VM

 


 

Inicio de Google Chrome

 

Abra un navegador con doble clic en el ícono Google Chrome del escritorio.

 

 

Inicio de sesión en vSphere Web Client

 

Si aún no inició sesión en vSphere Web Client, haga lo siguiente:

(La página de inicio debe ser el vSphere Web Client. De lo contrario, haga clic en el ícono de la barra de tareas de vSphere Web Client para Google Chrome).

  1. Para iniciar sesión, marque la casilla "Use Windows Session Authentication".
  2. Haga clic en Login.

 

 

Navegación hacia la sección Networking  Security en Web Client

 

  1. Haga clic en la pestaña Networking & Security.

 

 

Visualización de los componentes implementados

 

  1. Haga clic en Installation.
  2. Haga clic en Host Preparation.

Aquí podrá ver que los componentes del plano de datos, también denominados componentes de virtualización de redes, se instalaron en los hosts de nuestros clústeres. Entre estos componentes, se incluyen los siguientes:  

Módulos de kernel en el nivel del hipervisor para seguridad de puertos, VXLAN, firewall distribuido y enrutamiento distribuido. Las funciones de firewall y VXLAN se configuran y habilitan en cada clúster una vez que se han instalado los componentes de virtualización de redes. El módulo de seguridad de puerto asiste a la función de VXLAN, mientras que el módulo de enrutamiento distribuido se habilita una vez que se configura la VM de control del enrutador lógico de NSX Edge.

 

 

Topología luego de la preparación del host con los componentes de la ruta de datos

 

 

 

Visualización de la configuración de VTEP

 

  1. Haga clic en la pestaña Logical Network Preparation.
  2. Haga clic en la pestaña VXLAN Transport.
  3. Haga clic en el marcador de lista desplegable para expandir los clústeres.

La configuración de VXLAN se puede dividir en tres pasos importantes:

Como se muestra en el diagrama, los host de los clústeres de procesamiento se configuran con el mismo VTEP. En el entorno, se utiliza la subred 192.168.130.0/24 para el pool de VTEP.

 

 

Topología luego de la configuración de los VTEP en los clústeres

 

Uno de los principales desafíos a los que los clientes se han enfrentado anteriormente con la implementación de VXLAN es que los dispositivos de red física requieren soporte para el protocolo de multicast. Este desafío se soluciona en la plataforma de NSX mediante el suministro de una implementación de VXLAN basada en el controlador y la eliminación de cualquier necesidad de configurar el modo de multicast en la red física. Este modo (Unicast) es el predeterminado, y los clientes no deben configurar ninguna dirección multicast cuando definen el depósito de red lógica.

Si se selecciona el modo de replicación de multicast para un switch lógico en particular, NSX dependerá de la capacidad nativa de multicast de L2 o L3 de la red física para asegurar que el tráfico con destino múltiple encapsulado de la VXLAN se envíe a todos los VTEP. En este modo, se debe asociar una dirección IP de multicast a cada segmento definido de L2 de VXLAN (por ejemplo, un switch lógico). La capacidad de multicast de L2 se utiliza para replicar el tráfico a todos los VTEP que se encuentran en el segmento local (es decir, a direcciones IP de los VTEP que son parte de la misma subred de IP). Además, se debría configurar IGMP snooping en los switches físicos para optimizar la entrega del tráfico de multicast de L2.

Mediante el modo híbrido, se ofrece una simpleza operacional similar a la del modo de unicast (es decir, no se requiere la configuración del enrutamiento de multicast de IP en la red física) a la vez que es posible aprovechar la capacidad de multicast de L2 de los switches físicos.

Los tres modos de configuración del plano de control son los siguientes:

 

 

Configuración de direcciones de grupos multicast y Segment ID

 

  1. Haga clic en Segment ID. Tenga en cuenta que la sección Multicast addresses de arriba está en blanco.  Como se mencionó anteriormente, utilizamos el modo predeterminado Unicast con una implementación de VXLAN basada en controladores.

 

 

Definición de los ajustes de la zona de transporte

 

  1. Haga clic en Transport Zones.
  2. Haga doble clic en RegionA0_TZ.

Una zona de transporte define la expansión de un switch lógico. En Transport Zones, se determinan los clústeres que pueden participar en el uso de una red lógica en particular. A medida que agrega clústeres nuevos al centro de datos, puede incrementar la zona de transporte y, de esta manera, la expansión de las redes lógicas. Una vez que haya expandido el switch lógico en todos los clústeres de procesamiento, elimine todas las barreras de ubicación y movilidad que tenía debido a los límites y restricciones de VLAN.

 

 

Confirmación de clústeres como miembros de la zona de transporte local

 

Confirme que los 3 clústeres se encuentran en la zona de transporte.

  1. Haga clic en la pestaña Manage para que se muestren los clústeres que pertenecen a esta zona de transporte.

 

 

Topología luego de la definición de la zona de transporte

 

Luego de analizar los diferentes componentes de NSX y la configuración relacionada con VXLAN, nos centraremos en la creación de una red lógica, también denominada switch lógico.

 

 

Retorno al menú de Networking  Security

 

  1. Haga clic enel botón de reloj para regresar a la última ventana que abrió, que, en su caso, es el menú Networking & Security.

Si por alguna razón hizo clic en alguna otra opción después de ver la zona de transporte, vuelva a la sección Networking & Security de Web Client mediante el menú Home, como se realizó en pasos anteriores.

 

 

Creación de un nuevo switch lógico

 

  1. Haga clic en Logical Switches en la parte izquierda.
  2. Haga clicen el signo "más de color verde" para crear un switch lógico nuevo.
  3. Asigne el nombre Prod_Logical_Switch al switch lógico.
  4. Asegúrese de que haya seleccionado la opción RegionA0_TZ como la zona de transporte. Nota: El modo Unicast se seleccionará automáticamente.
  5. El modo Unicast deberá seleccionarse automáticamente.
  6. Asegúrese de que la casilla Enable IP Discovery quede marcada.

IP Discovery habilita la supresión de ARP.

Si selecciona la opción Enable IP Discovery, se activará la supresión de ARP. El ARP se utiliza para determinar la dirección MAC de destino a partir de una dirección IP mediante el envío de una transmisión en un segmento de capa 2. Si el host ESXi con NSX Virtual Switch recibe tráfico ARP de una máquina virtual (Virtual Machine, VM) o una solicitud Ethernet, el host envía la solicitud a NSX Controller que dispone de una tabla ARP. Si la instancia de NSX Controller ya cuenta con la información en su tabla ARP, le responde con esta información al host, el cual le responde a la máquina virtual.

7.     Haga clic en OK.

 

 

Vinculación del switch lógico nuevo con el gateway de servicios de NSX Edge para acceso externo

 

  1. Resalte el switch lógico que se creó recientemente.
  2. Haga clic con el botón secundario del mouse en Prod_Logical_Switch y seleccione Connect NSX Edge.

 

 

Conexión del switch lógico a NSX Edge

 

El enrutamiento se presenta de manera más detallada en el siguiente módulo. Sin embargo, para que la VM de la consola principal u otra VM en nuestro laboratorio se conecte con las VM en nuestro switch lógico nuevo, debemos establecer conexión con el enrutador. Como se menciona en la sección de los componentes, NSX Edge puede instalarse de dos maneras diferentes: Distributed-Router y Perimeter-Gateway.  

En este ejemplo, usted conectará el switch lógico al gateway de servicios de NSX Edge (Perimeter-Gateway).

  1. Haga clic en el botón de selección junto a Perimeter‑Gateway.
  2. Haga clic en Next.

 

 

Asociación del switch lógico a NSX Edge

 

  1. Haga clic en el botón de selección junto a vnic7.
  2. Haga clic en Next.

 

 

Asignación del nombre de la interfaz y configuración de la dirección IP para la interfaz

 

  1. Asigne el nombre Prod_Interface a la interfaz.
  2. Seleccione la opción Connected.
  3. Haga clic enel signo más para configurar las subredes. (No modifique las otras configuraciones).

 

 

Asignación de IP a la interfaz

 

  1. En el cuadro Primary IP Address, ingrese 172.16.40.1. (Deje en blanco el cuadro Secondary IP Address).
  2. Ingrese el número 24 en la columna Subnet Prefix Length.
  3. Verifique que las configuraciones sean correctas y haga clic en Next.

 

 

Finalización del proceso de edición de interfaz

 

  1. Haga clic en Finish. (Verá que el switch lógico nuevo aparecerá en la lista de switches lógicos).

 

 

Topología luego de la conexión de Prod_Logical_Switch al gateway de servicios de NSX Edge

 

Una vez que se configuró el switch lógico y que se proporcionó el acceso a la red externa, es momento de conectar las máquinas virtuales de aplicación web a esta red.

 

 

Opción Hosts and Clusters

 

  1. Haga clic en el botón Home.
  2. Haga clic en Hosts and Clusters.

 

 

Conexión de VM a vDS

 

Para agregar las VM al switch lógico que creamos recientemente, debemos asegurarnos de que el adaptador de red de las VM esté habilitado y se conecte con el vDS que corresponda.

  1. Haga clic en el botón Hosts and Clusters.
  2. Expanda el marcador de lista desplegable debajo de RegionA01-COMP01.
  3. Seleccione Web-03a.
  4. Seleccione Manage.
  5. Seleccione Settings.
  6. Seleccione Edit.

 

 

Conexión y habilitación de la interfaz de red

 

  1. Junto a Network Adapter, haga clic en el menú desplegable de interfaces.
  2. Seleccione VM-RegionA01-vDS-COMP (RegionA01-vDS-COMP).
  3. Marque la casilla Connected que se encuentra en la parte superior.
  4. Haga clic en OK.

Realice los mismos pasos para Web-04a, que se encuentra en el clúster RegionA01-COMP2 .

 

 

Conexión de web-03a y web-04a al switch Prod_Logical_Switch creado recientemente

 

  1. Haga clic en el botón Home.

 

 

Retorno al menú Networking  Security

 

  1. Haga clic en Networking & Security.

 

 

Selección de la pestaña Logical Switches

 

  1. Seleccione la pestaña Logical Switches.

 

 

Incorporación de máquinas virtuales

 

  1. Haga clic en el switch lógico nuevo que se creó para resaltarlo.
  2. Haga clic con el botón secundario del mouse y seleccioneel elemento Add VM del menú.

 

 

Adición de máquinas virtuales para añadirlas al switch lógico nuevo

 

  1. Introduzca un filtro para localizar aquellas VM cuyos nombres comienzan con "web".
  2. Resalte las VM web-03a y web-04a.
  3. Haga clic en la flecha derecha para seleccionar las VM que desea agregar al switch lógico.
  4. Haga clic en Next.

 

 

Adición de NIC virtual de VM al switch lógico

 

  1. Seleccione las vNiC para las dos VM.
  2. Haga clic en Next.

 

 

Finalización de la incorporación de VM al switch lógico

 

  1. Haga clic en Finish.

 

 

Prueba de conectividad entre Web-03a y Web-04a

 

 

 

Visualización de hosts y clústeres

 

  1. Haga clic en el botón Home.
  2. Seleccione Hosts and Clusters en el menú desplegable.

 

 

Expansión de los clústeres

 

 

 

Apertura de Putty

 

  1. Haga clic en Start.
  2. Haga clic enel ícono de la aplicación Putty que se encuentra en el menú de inicio.

La conexión se establece desde la consola principal, que se encuentra en la subred 192.168.110.0/24. El tráfico pasará por NSX Edge y, luego, se dirigirá a la interfaz web.

 

 

Apertura de una sesión de SSH en web-03a

 

  1. Seleccione web-03a.corp.local.
  2. Haga clic en Open.

**Nota: Si, por alguna razón, web-3a no se muestra como opción, también puede intentar ingresar la dirección IP 172.16.40.11 en el cuadro Host Name.

 

 

Inicio de sesión en la VM

 

Nota: Si tiene problemas para establecer conexión con web-03a, revise los pasos anteriores y verifique que se hayan realizado correctamente.

 

 

Envío de pings al servidor web web-sv-04a para mostrar la conectividad de capa 2

 

Recuerde utilizar la opción SEND TEXT para enviar este comando a la consola. (Consulte la orientación sobre el laboratorio).

Escriba ping -c 2 web-04a para enviar dos pings, en lugar de un ping continuo.  NOTA: web-04a tiene 172.16.40.12 como IP; puede enviar pings por IP, en lugar de utilizar el nombre si es necesario.

ping -c 2  web-04a 

***Tenga en cuenta que podría ver paquetes DUP!. Esto se debe a la naturaleza del entorno de laboratorio anidado de VMware. Esto no ocurrirá en un entorno de producción.

****No cierre la sesión de Putty. Minimice la ventana para utilizarla luego.

 

Escalabilidad y disponibilidad


En esta sección, podrá observar la disponibilidad y escalabilidad del controlador. El clúster del controlador en la plataforma de NSX es el componente del plano de control responsable de la administración de los módulos de enrutamiento y conmutación en los hipervisores. El clúster del controlador está compuesto por nodos del controlador mediante los cuales se administran switches lógicos específicos. El uso de un clúster del controlador para administrar switches lógicos basados en VXLAN elimina la necesidad del soporte multicast de la infraestructura de red física.

Por cuestiones de adaptabilidad y rendimiento, las implementaciones de producción deben implementar un clúster del controlador con nodos múltiples. El clúster del NSX Controller representa un sistema distribuido de escalabilidad horizontal, donde a cada nodo del controlador se le asigna un conjunto de roles que definen el tipo de tareas que el nodo puede implementar.  Los nodos del controlador se implementan en número impares. La mejor práctica actual (y la única configuración compatible) es que el clúster tenga tres nodos de redundancia y uso compartido de carga activa-activa-activa.

Para incrementar las características de escalabilidad de la arquitectura de NSX, se utiliza un mecanismo de "segmentación" para garantizar que todos los nodos del controlador puedan estar activos en cualquier momento.

Si los controladores fallan, el tráfico del plano de datos (VM) no se verá afectado. Es decir, el tráfico no se detendrá. Esto se debe a que la información de la red lógica se transfirió a los switches lógicos (el plano de datos). No será posible hacer adiciones, transferencias ni cambios si el plano de control (clúster del controlador) no está intacto.


 

Disponibilidad y escalabilidad de NSX Controller

 

  1. Desplace el mouse sobre el ícono Home.
  2. Haga clic en Networking & Security.

 

 

Verificación de la configuración del controlador existente

 

  1. Haga clic en Installation.
  2. Haga clic en Management.

Examine los nodos de NSX Controller para verificar que se hayan implementado tres controladores. Las instancias de NSX Controller siempre se implementan con números impares para obtener alta disponibilidad y escalabilidad.

 

 

Visualización de las VM de NSX Controller

 

Para ver instancias de NSX Controller en el entorno virtual, haga o siguiente:

  1. Desplace el mouse sobre el ícono Home.
  2. Haga clic en VMs and Templates.

 

 

Se mostrarán las 3 instancias de NSX Controller.

 

  1. Expanda el contenedor RegionA01.
  2. Resalte uno de los NSX_Controllers.
  3. Seleccionela pestaña Summary.

Observe el host ESX al que se encuentra conectado este controlador. Es posible que los otros controladores se encuentren en un host ESX diferente en este laboratorio. En un entorno de producción, cada controlador residiría en un host diferente en el clúster con reglas de antiafinidad con DRS para evitar múltiples fallas de controladores por una interrupción en un solo host.

 

Conclusión del módulo 2


En este módulo, presentamos las siguientes ventajas clave de la plataforma de NSX:

La velocidad a la que puede aprovisionar los switches lógicos y conectarlos con máquinas virtuales y redes externas.

La escalabilidad de la plataforma se demuestra mediante la capacidad de escalar las zonas de transporte y los nodos del controlador.


 

Ha finalizado el módulo 2.

Felicitaciones por completar el módulo 2.

Si desea obtener más información sobre la conmutación lógica, ingrese a la siguiente URL:

Continúe con cualquiera de los siguientes módulos que sea de su interés:

Lista de los módulos del laboratorio:

Directores del laboratorio:

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Módulo 3: Enrutamiento lógico (60 minutos)

Descripción general del enrutamiento


Descripción general del módulo de laboratorio

En el módulo anterior, se mencionó que los usuarios pueden crear redes o switches lógicos aislados con unos pocos clics. Para proporcionar comunicación entre estas redes de L2 lógicas y aisladas, es esencial la compatibilidad del enrutamiento. En la plataforma de NSX, el enrutador lógico distribuido le permite enrutar el tráfico entre switches lógicos. Una de las funciones principales que diferencia a este enrutador lógico es que la capacidad de enrutamiento se distribuye en el hipervisor. Mediante la incorporación de este componente de enrutamiento lógico, los usuarios pueden reproducir topologías de enrutamiento complejas en el espacio lógico. Por ejemplo, en una aplicación de tres niveles conectada a tres switches lógicos, el enrutamiento entre los niveles se maneja mediante un enrutador lógico distribuido.

En este módulo, se mostrará lo siguiente:

1) De qué manera el tráfico fluye cuando el enrutamiento se maneja mediante un enrutador físico externo o un gateway de servicios de NSX Edge.

2) Luego, analizaremos la configuración de las interfaces lógicas (Logical Interfaces, LIF) en el enrutador lógico y realizaremos el enrutamiento entre los niveles de la aplicación y la base de datos (Data Base, DB) de las aplicaciones.

3) Después, configuraremos los protocolos de enrutamiento dinámico en el enrutador lógico distribuido y el gateway de servicios de NSX Edge. Le mostraremos de qué manera se controlan los anuncios de enrutamiento interno al enrutador externo.

4) Por último, analizaremos de qué manera pueden utilizarse los diferentes protocolos de enrutamiento, como el protocolo de enrutamiento ECMP (Equal Cost Multipath Routing), para escalar y proteger el gateway de servicios de NSX Edge.

Con este módulo, podremos comprender algunas de las capacidades de enrutamiento compatibles en la plataforma de NSX y, además, la manera en la que estas capacidades se pueden utilizar mientras se implementa una aplicación de tres niveles.


 

Instrucciones especiales para los comandos CLI

 

En muchos de los módulos, deberá ingresar comandos de interfaz de línea de comando (Command Line Interface, CLI).  Existen dos maneras de enviar comandos CLI al laboratorio.

En primer lugar, para enviar un comando CLI a la consola del laboratorio, siga los siguientes pasos:

  1. Resalte el comando CLI en el manual y use Control+C para copiarlo al portapapeles.
  2. Haga clic en el elemento del menú de la consola SEND TEXT.
  3. Presione Control+V para pegarlo del portapapeles a la ventana.
  4. Haga clic en el botón SEND.

En segundo lugar, en el escritorio del entorno, encontrará un archivo de texto (README.txt) para que pueda copiar y pegar con facilidad contraseñas o comandos complejos en las herramientas asociadas (CMD, Putty, consola, etc.). Algunos teclados no tienen ciertos caracteres.  Este archivo de texto también se incluye para diseños de teclados que no incluyen esos caracteres.

El archivo de texto se llama README.txt y se encuentra en el escritorio.  

 

Enrutamiento dinámico y distribuido


En este módulo, se mostrarán la configuración del enrutamiento distribuido y las ventajas de realizar un enrutamiento en el nivel del kernel.


 

Un análisis de la topología y del flujo de paquetes actuales

 

En la imagen anterior, observe que la VM de la aplicación y la VM de la base de datos residen en el mismo host físico, el cual es el escenario en el laboratorio.  Sin el enrutamiento distribuido, para que estas dos VM se comuniquen, podemos ver el flujo del tráfico que se indica con los pasos de flechas rojas.  Primero, vemos el tráfico que sale de la VM de la aplicación y, debido a que la VM de la base de datos no se encuentra en la misma subred, el host físico enviará dicho tráfico a un dispositivo de capa 3.  En este entorno, el dispositivo es NSX Edge (perímetro) que se encuentra en el clúster de administración.  NSX Edge envía el tráfico de vuelta al host, donde finalmente llega a la VM de la base de datos.  

Al final del laboratorio, volveremos a analizar un diagrama de flujo de tráfico similar para observar de qué manera hemos modificado este comportamiento una vez configurado el enrutamiento distribuido.

 

 

Acceso a vSphere Web Client

 

 

 

Inicio de sesión en vSphere Web Client

 

Para iniciar sesión en vSphere Web Client, use la autenticación de sesión de Windows.

  1. Haga clic en Use Windows session authentication. De esta manera, se completarán automáticamente las credenciales de CORP\Administrator / VMware1!.
  2. Haga clic en Login.

 

 

Confirmación de la funcionalidad de la aplicación de 3 niveles

 

  1. Abra una pestaña nueva del navegador.
  2. Haga clic en Customer DB App en los favoritos.

 

 

Aplicación web que brinda información sobre la base de datos

 

Antes de comenzar con la configuración del enrutamiento distribuido, verifiquemos que la aplicación web de tres niveles funcione correctamente. Los tres niveles de la aplicación (web, aplicación y base de datos) se encuentran en switches lógicos diferentes, y NSX Edge proporciona el enrutamiento entre los niveles.

 

 

Eliminación de interfaces de base de datos y aplicación de NSX Edge perimetral

 

Como observó en la topología anterior, los tres switches lógicos o los tres niveles de la aplicación terminan en NSX Edge perimetral. NSX Edge perimetral permite el enrutamiento entre los tres niveles. Vamos a modificar esa topología mediante la eliminación, en primer lugar, de las interfaces de capa de base de datos y capa de aplicación de NSX Edge perimetral. Una vez eliminadas las interfaces, las migraremos a NSX Edge distribuido.  A fin de ahorrar tiempo en la implementación de un componente, ya se desplegó el enrutador distribuido.

  1. Haga clic en el botón Networking & Security.

 

 

Selección de NSX Edge

 

  1. Haga clic en NSX Edges en el panel de navegación izquierdo.
  2. Haga doble clic en "edge-3 Perimeter-Gateway-01" para abrir la configuración de Perimeter-Gateway.

 

 

Selección de interfaces desde la pestaña Settings para mostrar las interfaces actuales

 

  1. Haga clic en la pestaña Manage.
  2. Haga clic en Settings.
  3. Haga clic en Interfaces en la pestaña de navegación Settings.

Se mostrarán las interfaces configuradas recientemente y sus propiedades.  La información incluye el número de vNIC, el nombre de la interfaz, si la interfaz se configuró como interna o como un enlace ascendente y el estado actual (activada o desactivada).

 

 

Eliminación de la interfaz de aplicación

 

  1. Resalte la interfaz App_Tier .  Verá que se iluminará la barra Actions, y allí aparecerán opciones específicas para la interfaz seleccionada.
  2. Haga clic en la X roja para eliminar la interfaz seleccionada de NSX Edge perimetral.  Aparecerá un cuadro de advertencia en el que deberá responder si desea confirmar la eliminación de la interfaz.
  3. Haga clic en OK para confirmar la eliminación.

 

 

Eliminación de la interfaz de la base de datos

 

  1. Resalte la interfaz DB_Tier.  Verá que se iluminará la barra Actions, y allí aparecerán opciones específicas para la interfaz seleccionada.
  2. Haga clic en la X roja para eliminar la interfaz seleccionada de NSX Edge perimetral.  Aparecerá un cuadro de advertencia en el que deberá responder si desea confirmar la eliminación de la interfaz.
  3. Haga clic en OK para confirmar la eliminación.

 

 

Topología luego de la eliminación de las interfaces de aplicación y base de datos de NSX Edge perimetral

 

 

 

Navegación hasta la página de inicio de NSX

 

Ahora que ya eliminó las interfaces de aplicación y DB de NSX Edge perimetral, debe regresar a la pantalla del dispositivo de NSX Edge para acceder al enrutador lógico distribuido.  

 

 

Agregado de interfaces de aplicación y base de datos al enrutador distribuido

 

A continuación, comenzaremos a configurar el enrutamiento distribuido mediante la adición de la interfaz de aplicaciones y DB al "enrutador distribuido".

  1. Haga doble clic en edge-6 para configurar el enrutador distribuido.

 

 

Visualización de las interfaces en el enrutador distribuido

 

  1. Haga clic en Manage.
  2. Haga clic en Settings.
  3. Haga clic en Interfaces para que se muestren todas las interfaces configuradas actualmente en el enrutador distribuido.

 

 

Agregado de interfaces al enrutador distribuido

 

  1. Haga clic en el signo más de color verde para agregar una interfaz nueva.
  2. Asigne el nombre App_Tier a la interfaz.
  3. Haga clic en Select en la sección Connected To.

 

 

Especificación de la red

 

  1. Seleccione el botón de selección App_Tier_Logical_Switch, que será la red mediante la cual se comunicará esta interfaz.
  2. Haga clic en OK.

 

 

Agregado de subredes

 

  1. Haga clic en el signo más de color verde para configurar las subredes.
  2. Haga clic en el cuadro Primary IP Address e ingrese la dirección 172.16.20.1 como dirección IP.
  3. Ingrese 24 en la columna Subnet Prefix Length.
  4. Luego, haga clic en OK para terminar de agregar la subred local.

 

 

Incorporación de la interfaz de la base de datos

 

Una vez que el sistema finalice la incorporación y configuración de DB_Interface,  verifique que las interfaces App_Tier y DB_Tier correspondan con la imagen de arriba.

 

 

Topología nueva luego del traslado de las interfaces de aplicaciones y bases de datos al enrutador distribuido

 

Una vez que se configuraron estas interfaces en el enrutador distribuido, esas configuraciones de las interfaces se envían automáticamente a cada host del entorno. A partir de ahora, el módulo cargable del kernel de enrutamiento distribuido (Distributed Routing, DR) del host maneja el enrutamiento entre las interfaces de aplicaciones y bases de datos. Por lo tanto, si se quieren comunicar las dos VM conectadas a dos subredes diferentes corriendo en el mismo host, el tráfico no elegirá una ruta que no sea óptima, como se mostró en el diagrama de flujo de tráfico anterior.

 

 

Retorno a la pestaña del navegador con aplicación web de 3 niveles

 

Una vez realizados los cambios, probará que el acceso a la aplicación de 3 niveles falla.  La razón de esta falla radica en que, si bien se configura el enrutamiento para que lo maneje el enrutador distribuido, aún no hay una ruta entre este y la ubicación de los servidores web.

Nota: Si cerró esa pestaña en pasos anteriores, abra una nueva pestaña del navegador y haga clic en Customer DB App en los favoritos.

 

 

Verificación de la detención del funcionamiento de la aplicación de 3 niveles

 

  1. Haga clic en el ícono para actualizar.

La aplicación tardará algunos segundos previo a dejar de estar disponible, por lo que es probable que deba seleccionar la "x" de color rojo para detener el navegador.  Si visualiza datos del cliente, es posible que se hayan almacenado en caché con anterioridad y que deba cerrar y volver a abrir el navegador para corregir esto.  

Cierre la pestaña creada para probar la conectividad al servidor web. Luego, configuraremos el enrutamiento para restaurar el servicio.

Nota: Si debe volver a abrir el navegador, una vez que haya verificado que la aplicación de tres niveles ya no está funcionando, haga clic en el marcador del navegador para abrir vSphere Web Client y vuelva a iniciar sesión con las credenciales "administrator@vsphere.local" como usuario y "VMware1!" como contraseña.  Luego, haga clic en Networking and Security, Edge Appliances y, por último, haga doble clic en "Distributed-Router".

 

 

Configuración del enrutamiento dinámico en el enrutador distribuido

 

  1. Haga clic en la pestaña Routing.
  2. Haga clic en Global Configuration.
  3. Haga clic en el botón Edit junto a Dynamic Routing Configuration.

 

 

Opción Edit Dynamic Routing Configuration

 

  1. Seleccione el ID del enrutador predeterminado, que es la dirección IP de la interfaz de enlace Uplink (en este caso, Transit_Network_01 - 192.168.5.2).
  2. Haga clic en OK.

Nota: El ID de enrutador es clave en la operación de OSPF, ya que indica la identidad de los enrutadores en un sistema autónomo.  Se trata de un identificador de 32 bits que se representa con una dirección IP, pero que puede ser específico de las subredes pertinentes al enrutador específico. En nuestro caso, utilizamos un ID de enrutador que es el mismo que la dirección IP de la interfaz de Uplink en el dispositivo NSX Edge, lo cual es posible pero innecesario.  La pantalla volverá a la pantalla principal "Global Configuration", y el cuadro de diálogo "Publish Changes" de color verde volverá a aparecer.

 

 

Publicación de cambios

 

  1. Vuelva a hacer clic en el botón Publish Changes, en el cuadro de diálogo, para enviar la configuración actualizada al dispositivo NSX Edge distribuido.

 

 

Configuración de los parámetros específicos de OSPF

 

Utilizaremos OSPF como nuestro protocolo de enrutamiento dinámico.

  1. Seleccione la opción OSPF en el árbol de navegación, debajo de Routing para abrir la página principal de configuración de OSPF.
  2. Haga clic en Edit a la derecha de OSPF Configuration para abrir el cuadro de diálogo de OSPF Configuration.

 

 

Opción Enable OSPF

 

  1. Haga clic en el cuadro de diálogo Enable OSPF.
  2. Ingrese 192.168.5.3 en el cuadro Protocol Address.
  3. Ingrese 192.168.5.2 en el cuadro Forwarding Address.
  4. Verifique que se haya seleccionado el cuadro de diálogo Enable Graceful Restart.
  5. Luego, haga clic en OK.

Nota: En el caso del enrutador distribuido, se requiere que el campo "Protocol Address" envíe el tráfico de control a la máquina virtual de control del enrutador distribuido. La dirección que se coloca en Forwarding Address representa la dirección a la que se enviará todo el tráfico de la ruta de datos.  La pantalla volverá a la ventana principal de configuración de "OSPF".  Se mostrará el cuadro de diálogo verde "Publish Changes".

Nota: Debido a la separación del plano de control y del tráfico del plano de datos en NSX, se crea la posibilidad de mantener la capacidad de reenvío de datos de la instancia del enrutador mientras se vuelve a iniciar o a cargar la función de control. Esta función se denomina "reinicio sin problemas" (Graceful Restart) o "reenvío sin interrupciones" (Non-stop Forwarding).

¡TODAVÍA NO PUBLIQUE LOS CAMBIOS!En vez de publicar los cambios en cada paso, continuaremos con los cambios de configuración y los publicaremos todos al mismo tiempo.

 

 

Configuración de la definición del área

 

  1. Haga clic en el signo más de color verde para ver el cuadro de diálogo New Area Definition.
  2. Ingrese el número 10 en el cuadro Area ID.  En los demás cuadros de diálogo, puede dejar las configuraciones predeterminadas.
  3. Haga clic en OK.

Nota: El campo Area ID es muy importante para la opción OSPF.  Existen varios tipos de áreas de OSPF.  Asegúrese de verificar cuál es el área correcta en la que deben ubicarse los dispositivos NSX Edge para que funcionen correctamente con el resto de la configuración de OSPF dentro de la red.

 

 

Opción Area to Interface Mapping

 

  1. Haga clic en el signo más de color verde debajo de "Area to Interface Mapping" para abrir el cuadro de diálogo "New Area to Interface Mapping".
  2. Seleccione Transit_Network_01 en el campo Interface.
  3. Seleccione 10 para Area.
  4. Haga clic en OK.

 

 

Publicación de cambios

 

  1. Vuelva a hacer clic en el botón Publish Changes, en el cuadro de diálogo, para enviar la configuración actualizada al dispositivo NSX Edge distribuido.

 

 

Confirmación de la habilitación del enrutamiento de OSPF en el enrutador distribuido

 

Ahora, podemos confirmar que hemos habilitado y configurado el protocolo OSPF en el perímetro distribuido.  Confirme si toda la información que se muestra es correcta.

 

 

Confirmación de la opción Route Redistribution

 

 

 

Verificación de la opción Route Redistribution

 

 

 

Incorporación del protocolo BGP a la tabla de redistribución de rutas de OSPF

 

  1. Haga clic en OSPF en Route Redistribution table.
  2. Haga clic en el ícono de lápiz para editar la configuración de OSPF.
  3. Marque el cuadro junto a BGP en la lista Allow learning from.
  4. Haga clic en OK.

 

 

Publicación de cambios

 

  1. Vuelva a hacer clic en el botón Publish Changes, en el cuadro de diálogo, para enviar la configuración actualizada al dispositivo NSX Edge distribuido.

 

 

Configuración del enrutamiento de OSPF en NSX Edge perimetral

 

Ahora, debemos configurar el enrutamiento dinámico en el dispositivo NSX Edge del perímetro para restaurar la conectividad a la aplicación de 3 niveles de prueba.  

 

 

Selección del NSX Edge perimetral

 

En la página principal de NSX Edge, se muestran los dispositivos NSX Edge configurados.  

 

 

Opción Global Configuration para NSX Edge perimetral

 

  1. Haga clic en la pestaña de navegación Manage.
  2. Seleccione el botón de navegación Routing para ir a la página de configuración de enrutamiento del dispositivo.
  3. Haga clic en OSPF.
  4. Haga clic en Edit, que se encuentra a la derecha del título OSPF Configuration, para abrir el cuadro de diálogo OSPF Configuration.

Notará que este dispositivo NSX Edge ya se configuró para el enrutamiento dinámico con BGP.  Esta configuración de enrutamiento se establece para que el NSX Edge perimetral pueda comunicar y distribuir rutas al enrutador que ejecuta todo el laboratorio.  A continuación, seguiremos con la conexión de este dispositivo NSX Edge al enrutador lógico distribuido.  Ya se completaron todas las configuraciones globales del BGP y del enrutador para el dispositivo NSX Edge.  

 

 

Opción Enable OSPF

 

  1. Haga clic en el cuadro de diálogo Enable OSPF.
  2. Verifique que se haya seleccionado el cuadro de diálogo Enable Graceful Restart.
  3. Luego, haga clic en OK.

 

 

Configuración de la definición del área

 

  1. Haga clic en el signo más de color verde para ver el cuadro de diálogo New Area Definition.
  2. Ingrese el número 10 en el cuadro Area ID. En los demás cuadros de diálogo, puede dejar las configuraciones predeterminadas.
  3. Haga clic en OK.

Nota: El campo Area ID es muy importante para la opción OSPF. Existen varios tipos de áreas de OSPF. Asegúrese de verificar cuál es el área correcta en la que deben ubicarse los dispositivos NSX Edge para que funcionen correctamente con el resto de la configuración de OSPF dentro de la red.

 

 

Adición de la interfaz de tránsito al Mapeo de Area to Interface

 

Ahora, solo debemos indicarle a OSPF que active la interfaz que se comunicará con los enrutadores distribuidos.

  1. Haga clic en el signo más de color verde que se encuentra junto al título Area to Interface Mapping.
  2. Seleccione la opción Transit_Network_01 en el campo vNIC.
  3. Seleccione 10 en el campo Area.
  4. Haga clic en OK.

 

 

Publicación de cambios

 

  1. Vuelva a hacer clic en el botón Publish Changes, en el cuadro de diálogo, para enviar la configuración actualizada al dispositivo NSX Edge distribuido.

 

 

Confirmación de la habilitación del enrutamiento de OSPF en el dispositivo NSX Edge perimetral

 

Ahora, podemos confirmar que hemos habilitado y configurado OSPF en el dispositivo NSX Edge perimetral. Confirme si toda la información que se muestra es correcta.

 

 

Configuración de la opción Route Redistribution

 

  1. Haga clic en Route Redistribution para abrir la página de configuración principal de la redistribución de rutas.
  2. Haga clic en Edit, a la derecha del título Route Redistribution Status, para abrir el cuadro de diálogo de Change redistribution settings.

 

 

Cuadro de diálogo Change Redistribution Settings

 

  1. Haga clic en el cuadro de diálogo OSPF.
  2. Verifique que se haya seleccionado el cuadro de diálogo BGP.
  3. Haga clic en OK.

Nota: BGP es el protocolo de enrutamiento que se utiliza entre Perimeter-Gateway-01 y el enrutador vPod.

 

 

Modificación de los criterios de redistribución de BGP

 

  1. En Route Redistribution table, resalte BGP , que se encuentra debajo de Learner.
  2. Haga clic en el ícono de lápiz para editar el protocolo Learner seleccionado desde el dispositivo NSX Edge perimetral.
  3. Haga clic en el cuadro de diálogo OSPF.
  4. Haga clic en OK.

 

 

Configuración de la redistribución de las rutas de OSPF

 

  1. Haga clic en el signo más de color verde que se encuentra debajo del título Route Redistribution table.
  2. Seleccione OSPF en el campo Learner Protocol.
  3. Haga clic en el cuadro de diálogo BGP.
  4. Haga clic en el cuadro de diálogo Connected.
  5. Haga clic en OK.

 

 

Publicación de cambios

 

  1. Vuelva a hacer clic en el botón Publish Changes, en el cuadro de diálogo, para enviar la configuración actualizada al dispositivo NSX Edge distribuido.

 

 

Revisión de la topología nueva

 

Si observa la disposición actual de la topología, podrá ver cómo se intercambia tráfico de las rutas entre el enrutador distribuido y el dispositivo NSX Edge perimetral.  Cualquier red que cree en el enrutador distribuido ahora se distribuirá hasta el NSX Edge perimetral, donde puede controlar cómo se enruta hacia a la red física.

En la siguiente sección, se desarrollará este tema de manera más detallada.

 

 

Verificación de la comunicación a aplicaciones de 3 niveles

 

Ahora, verifiquemos si el enrutamiento es funcional.  La información de enrutamiento ahora se intercambia entre el enrutador distribuido y Perimeter-Gateway y, de esta manera, se restablece la conectividad a la aplicación web.  Para verificar esto, volveremos a probar la aplicación web.

  1. Haga clic en la pestaña que abrió previamente para la aplicación web. Es posible que se muestre "503 Service Temp..." en la pestaña de la prueba fallida anterior.
  2. Actualice el navegador para verificar si la aplicación de tres niveles vuelve a funcionar.

Nota:: La propagación de la ruta podría tardar un minuto debido al entorno anidado.

 

 

Enrutamiento distribuido y dinámico finalizado

De esta manera, se completa la sección sobre configuración de enrutamiento distribuido y dinámico.  En la siguiente sección, revisaremos el enrutamiento centralizado con el dispositivo NSX Edge perimetral.

 

Enrutamiento centralizado


En esta sección, analizaremos diferentes elementos para observar cómo se realiza el enrutamiento en dirección norte desde NSX Edge.  Esto incluye la forma en la que el enrutamiento dinámico de OSPF se controla, actualiza y propaga por el sistema.  Verificaremos el enrutamiento en el dispositivo NSX Edge perimetral mediante el dispositivo de enrutamiento virtual que ejecuta y dirige todo el laboratorio.

Nota especial: En el escritorio, encontrará un archivo con el nombre README.txt.  Allí se muestran los comandos CLI que necesita para realizar los ejercicios del laboratorio.  Si no puede escribirlos, puede copiarlos y pegarlos en las sesiones de Putty.  Si ve un número con "comillas francesas - {1}", eso significa que debe buscar ese comando CLI para ese módulo en el archivo de texto.


 

Topología del laboratorio actual

 

En este diagrama, se muestra la topología actual del laboratorio, incluido el enlace en dirección norte al enrutador vPod.  Puede observar que el protocolo OSPF redistribuye las rutas desde el enrutador NSX Edge hasta el enrutador lógico distribuido.

 

 

Verificación del enrutamiento de OSPF en el gateway perimetral

En primer lugar, confirmaremos que la aplicación web sea funcional y, luego, iniciaremos sesión en el gateway perimetral de NSX para visualizar los vecinos del protocolo OSPF y la distribución de rutas existente. Con esto, se mostrará la manera en la que el gateway perimetral aprende las rutas, no solo del enrutador distribuido, sino también del enrutador vPod que ejecuta todo el laboratorio.

 

 

Confirmación de la funcionalidad de las aplicaciones de 3 niveles

 

  1. Abra una pestaña nueva del navegador.
  2. Haga clic en Customer DB App en los favoritos.

 

 

Aplicación web que brinda información sobre la base de datos

 

Antes de comenzar con la configuración del enrutamiento distribuido, verifiquemos que la aplicación web de tres niveles funcione correctamente. Los tres niveles de la aplicación (web, aplicación y base de datos) se encuentran en switches lógicos diferentes, y NSX Edge proporciona el enrutamiento entre los niveles.

 

 

Navegación a la VM de NSX Edge perimetral

 

 

 

Opción Launch Remote Console

 

  1. Expanda la carpeta RegionA01.
  2. Seleccione Perimeter-Gateway-01-0.
  3. Seleccione la pestaña Summary.
  4. Haga clic en Launch Remote Console.

 

 

Acceso a la consola remota

 

La ventana VMRC aparecerá en negro cuando se abra por primera vez.  Haga clic dentro de la ventana y presione Enter un par de veces hasta que aparezca la consola del protector de pantalla.

***NOTA*** Para sacar el cursor de la ventana, presione las teclas Ctrl+Alt.

 

 

Inicio de sesión en el gateway perimetral

 

Inicie sesión en el gateway perimetral con las siguientes credenciales:  Tenga en cuenta que todos los dispositivos NSX Edge tienen contraseñas complejas de 12 caracteres.

 

 

Instrucciones especiales para los comandos CLI

 

En muchos de los módulos, deberá ingresar comandos de interfaz de línea de comando (CLI).  Existen dos maneras de enviar comandos CLI al laboratorio.

En primer lugar, para enviar un comando CLI a la consola del laboratorio, siga los siguientes pasos:

  1. Resalte el comando CLI en el manual y use Control+C para copiarlo al portapapeles.
  2. Haga clic en el elemento del menú de la consola SEND TEXT.
  3. Presione Control+V para pegarlo del portapapeles a la ventana.
  4. Haga clic en el botón SEND.

En segundo lugar, en el escritorio del entorno, encontrará un archivo de texto (README.txt) para que pueda copiar y pegar con facilidad contraseñas o comandos complejos en las herramientas asociadas (CMD, Putty, consola, etc.). Algunos teclados no tienen ciertos caracteres.  Este archivo de texto también se incluye para diseños de teclados que no incluyen esos caracteres.

El archivo de texto se llama README.txt y se encuentra en el escritorio.  

 

 

Visualización de vecinos BGP

 

Lo primero que realizaremos es visualizar los vecinos BGP en el dispositivo NSX Edge perimetral, que se encuentra en medio de la capa de enrutamiento del laboratorio.

NOTA: La tabulación automática funciona en los dispositivos NSX Edge.

show ip bgp neighbor

 

 

Revisión de la información presentada de los vecinos BGP

 

Ahora, revisemos el contenido que se muestra y su significado.

  1. BGP neighbor is 192.168.100.1: esta es la ID del enrutador vPod que se encuentra en el entorno de NSX.
  2. Remote AS 65002: aquí se muestra el número del sistema autónomo de la red externa del enrutador vPod.
  3. BGP state = Established, up : aquí se informa que se completó la adyacencia del vecino BGP y que los enrutadores BGP enviarán paquetes de actualización para intercambiar información de enrutamiento.

 

 

Revisión de las rutas en NSX Edge perimetral y su origen

 

Escriba show ip route.

show ip route

 

 

Revisión de la información de las rutas

 

Revisemos el contenido de las rutas que se muestran.

  1. En la primera línea, se muestra nuestra ruta predeterminada, que se origina en el enrutador vPod (192.168.100.1), y la B al comienzo de las líneas representa que la ruta se aprendió mediante BGP.
  2. La línea 172.16.10.0/24 es el switch lógico Web-Tier y su interfaz.  Debido a que está directamente conectado al NSX Edge, verá la letra C al inicio de la línea.
  3. La sección que se indica con un "3" hace referencia a las otras dos partes de nuestra aplicación web, las cuales son los segmentos de red para la capa de aplicaciones y de DB.  Como se ve en la línea 1, se coloca una O al comienzo de la línea para indicar que las rutas se aprendieron mediante OSPF por medio del enrutador distribuido (192.168.5.2).

 

 

Control de la distribución de las rutas del BGP

En una situación particular, podría desear que las rutas de BGP se distribuyeran únicamente dentro del entorno virtual, pero no en el entorno físico.  Tenemos la capacidad de controlar la distribución de rutas con facilidad desde la interfaz del NSX Edge.

 

 

Navegación hacia NSX en vSphere Web Client

 

**NOTA** Debe presionar Ctrl+Alt para abandonar la ventana VMRC de Perimeter-Gateway.

 

 

Acceso al gateway perimetral

 

  1. Haga clic en NSX Edges.
  2. Haga doble clic en edge-3.

 

 

Acceso a la configuración de enrutamiento de BGP

 

  1. Seleccione la pestaña Manage.
  2. Haga clic en Routing.
  3. Haga clic en BGP, en el panel izquierdo.

 

 

Eliminación de la relación entre vecinos BGP con el enrutador vPod

 

Ahora, eliminaremos el mapeo del Sistema Autónomo (AS) 65002 de BGP. Si se hace esto, el gateway perimetral y el enrutador vPod ya no intercambiarán las rutas.

  1. Resalte la dirección IP del enrutador vPod, 192.168.100.1, en la sección Neighbors.
  2. Haga clic en la X de color rojo para eliminar la relación entre vecinos seleccionada.

 

 

Confirmación de la eliminación

 

 

 

Publicación del cambio

 

  1. Haga clic en el botón Publish Changes para enviar el cambio de configuración.

 

 

Navegación a la VMRC del gateway perimetral

 

Seleccione Perimeter-Gateway en la barra de tareas.

 

 

Visualización de vecinos BGP

 

**NOTA** Una vez que se muestre la ventana, es probable que deba hacer clic dentro de esta y presionar la tecla Enter para que la pantalla aparezca.

1. Escriba show ip bgp neighbor y presione Enter.

show ip bgp neighbor

Verá que el enrutador vPod (192.168.250.1) ya no se encuentra en la lista.

 

 

Visualización de rutas

 

1. Escriba show ip route y presione Enter.

show ip route

Ahora, puede observar que las únicas rutas que se aprendieron mediante OSPF son las del enrutador distribuido (192.168.5.2).

 

 

Verificación de la detención del funcionamiento de la aplicación de 3 niveles

 

**NOTA** Debe presionar Ctrl+Alt para abandonar la ventana VMRC de Perimeter-Gateway.

Ya que no existen rutas entre el centro de control y el entorno de redes virtuales, la aplicación web debería fallar.

  1. Haga clic en la pestaña HOL - Multi-Tier App.
  2. Haga clic en el ícono para actualizar.

La aplicación puede tardar unos minutos previo a dejar de estar disponible, por lo que es probable que deba seleccionar la "x" de color rojo para detener el navegador.  Si visualiza datos del cliente, es posible que se hayan almacenado en caché con anterioridad y que deba cerrar y volver a abrir el navegador para corregir esto.  

 

 

Restablecimiento del intercambio de tráfico entre las rutas

 

Ahora, volvamos a restablecer el intercambio de tráfico entre el gateway perimetral y el enrutador vPod.

 

 

Reincorporación de la configuración de vecino BGP

 

  1. Haga clic en el ícono más de color verde en el panel Neighbors.
  2. Escriba 192.168.100.1 en el campo IP Address.
  3. Escriba 65002 en el campo Remote AS.
  4. Haga clic en OK.

 

 

Publicación del cambio

 

  1. Haga clic en el botón Publish Changes para enviar el cambio de configuración.

 

 

Navegación a la VMRC del gateway perimetral

 

Seleccione Perimeter-Gateway en la barra de tareas.

 

 

Visualización de vecinos BGP

 

**NOTA** Una vez que se muestre la ventana, es probable que deba hacer clic dentro de esta y presionar la tecla Enter para que la pantalla aparezca.

1. Escriba show ip bgp neighbor y presione Enter.

show ip bgp neighbor

Verá que el enrutador vPod (192.168.100.1) aparece como vecino.

 

 

Revisión de las rutas en NSX Edge perimetral y su origen

 

Escriba "show ip route".

show ip route

 

 

Visualización de rutas

 

La ruta predeterminada y la red conectada desde el enrutador vPod (192.168.100.1) se encuentran nuevamente en la lista.

 

 

Verificación del funcionamiento de las aplicaciones de 3 niveles

 

**NOTA** Debe presionar Ctrl+Alt para abandonar la ventana VMRC de Perimeter-Gateway.

Una vez que las rutas se encuentren nuevamente en el lugar correcto, la aplicación web debe funcionar nuevamente.

  1. Haga clic en la pestaña HOL - Multi-Tier App.
  2. Haga clic en el ícono para actualizar.

Con esto, se completa esta sección del laboratorio. A continuación, analizaremos el ECMP y la alta disponibilidad mediante las instancias de NSX Edge.

 

Alta disponibilidad y ECMP


En esta sección, agregaremos otro gateway perimetral a la red y, luego, utilizaremos el enrutamiento ECMP (Equal Cost Multipath Routing) para escalar horizontalmente la capacidad de NSX Edge y aumentar su disponibilidad.  Con NSX, podemos realizar una adición local de un dispositivo NSX Edge y habilitar ECMP.

ECMP es una estrategia de enrutamiento mediante la cual se permite el reenvío de paquetes al próximo salto (next-hop) y hacia un único destino sobre múltiples rutas óptimas. Estas rutas óptimas se pueden agregar de forma estática o como resultado de cálculos de métricas mediante protocolos de enrutamiento dinámico, como OSPF o BGP. El gateway de servicios de NSX Edge utiliza el stack de redes de Linux, un algoritmo round robin con un componente de aleatoriedad. Una vez que se haya seleccionado el próximo salto para una dirección IP de origen a destino en particular, el caché de ruta almacena el próximo salto seleccionado. Todos los paquetes de ese flujo se envían al próximo salto seleccionado. El enrutador lógico distribuido utiliza un algoritmo XOR para determinar el próximo salto a partir de una lista de próximos saltos de ECMP posibles. El algoritmo utiliza esta dirección IP de origen y destino en el paquete saliente como fuentes de entropía.

Ahora, configuraremos un nuevo gateway perimetral y estableceremos el clúster de ECMP entre los gateways perimetrales para que el enrutador lógico distribuido aproveche una mayor capacidad y disponibilidad. Pondremos a prueba la disponibilidad mediante el cierre de uno de los gateways perimetrales y veremos los cambios que tendrán lugar en el tráfico.


 

Navegación hacia NSX en vSphere Web Client

 

**NOTA** Debe presionar Ctrl+Alt para abandonar la ventana VMRC de Perimeter-Gateway.

  1. Haga clic en el ícono Home.
  2. Haga clic en Networking & Security.

 

 

Adición de una instancia de NSX Edge gateway perimetral

 

El primer paso es agregar un dispositivo NSX Edge perimetral adicional.

  1. Haga clic en NSX Edges.
  2. Haga clic en el signo más de color verde.

 

 

Selección y designación del nombre de NSX Edge

 

  1. En el campo Install Type, haga clic en Edge Services Gateway.
  2. Ingrese Perimeter-Gateway-02 en el campo Name.
  3. Haga clic en Next.

 

 

Configuración de la contraseña

 

  1. Escriba la contraseña VMware1!VMware1!.
  2. Confirme la contraseña VMware1!VMware1!.
  3. Marque la casilla Enable SSH Access.
  4. Haga clic en Next.

NOTA: Todas las contraseñas de instancias de NSX Edge son complejas y tienen 12 caracteres.

 

 

Agregado de un dispositivo de NSX Edge

 

  1. Haga clic en el signo más de color verde debajo de NSX Appliances para que se muestre el cuadro de diálogo Add NSX Edge Appliance.
  2. Seleccione la opción RegionA01-MGMT01 en el campo Cluster/Resource Pool.
  3. Seleccione la opción RegionA01-ISCSI01-MGMT01 en el campo Datastore.
  4. Seleccione esx-04a.corp.local en el campo Host.
  5. Haga clic en OK.

 

 

Continuación de la implementación

 

  1. Haga clic en Next.

 

 

Agregado de la interfaz de Uplink

 

  1. Haga clic en el signo más de color verde para agregar la primera interfaz.

 

 

Selección del switch al que se conectará

 

Debemos elegir la interfaz del switch en dirección norte para esta instancia de NSX Edge, que es un port group distribuido.

  1. Haga clic en Select junto al campo Connected To.
  2. Haga clic en Distributed Portgroup.
  3. Seleccione la opción Uplink-RegionA01-vDS-MGMT.
  4. Haga clic en OK.

 

 

Designación de nombre y adición de IP

 

  1. Ingrese Uplink en el campo Name.
  2. En Type, seleccione Uplink.
  3. Haga clic en el signo más de color verde.
  4. Ingrese 192.168.100.4 en el campo Primary IP Address.
  5. Introduzca 24 en Subnet Prefix Length.
  6. Haga clic en OK.

 

 

Agregado de la interfaz de tránsito de la instancia de NSX Edge

 

  1. Haga clic en el signo más de color verde para agregar la segunda interfaz.

 

 

Selección del switch al que se conectará

 

Debemos elegir la interfaz del switch en dirección norte para esta instancia de NSX Edge, el cual es un switch lógico respaldado por VXLAN.

  1. Haga clic en Select junto al campo Connected To.
  2. Haga clic en Logical Switch.
  3. Seleccione Transit_Network_01_5006.
  4. Haga clic en OK.

 

 

Designación de nombre y adición de IP

 

  1. Ingrese Transit_Network_01 en el campo Name.
  2. En Type, seleccione Internal.
  3. Haga clic en el signo más de color verde.
  4. Ingrese 192.168.5.4 en el campo Primary IP Address.
  5. Introduzca 29 en Subnet Prefix Length.

NOTA: El número debe ser 29, no 24.  Asegúrese de ingresar el número correcto; caso contrario, el laboratorio no funcionará.

  1. Haga clic en OK.

 

 

Continuación de la implementación

 

IMPORTANTE. Antes de continuar, revise la información y verifique que los números en IP Address y en Subnet Prefix Length sean correctos.

  1. Haga clic en Next.

 

 

Eliminación del gateway predeterminado

 

Eliminaremos el gateway predeterminado, ya que recibimos dicha información mediante OSPF.

  1. DESMARQUE la casilla Configure Default Gateway.
  2. Haga clic en Next.

 

 

Configuración de firewall predeterminada

 

  1. MARQUE la casilla Configure Firewall default policy.
  2. Seleccione ACCEPT.
  3. Haga clic en Next.

 

 

Finalización de la implementación

 

 

 

Implementación de la instancia de NSX Edge

 

La implementación de la instancia de NSX Edge tardará algunos minutos.

  1. Veremos que el estado de Edge-7 es Busy y que se indica que se está instalando 1 elemento.  Esto significa que la implementación está en proceso.
  2. Podemos hacer clic en el ícono Refresh del Web Client para acelerar la actualización automática de esta pantalla.

Cuando se muestre Deployed en el estado, puede pasar al paso siguiente.

Nota: Si no puede ver el estado de Edge-7, desplácese hacia la ventana en la derecha y allí podrá ver el estado de la implementación.

 

 

Configuración del enrutamiento de una nueva instancia de NSX Edge

 

Debe configurar el OSPF en el nuevo dispositivo NSX Edge antes de habilitar el ECMP.

  1. Haga doble clic en la instancia edge-7 que implementó recientemente.

 

 

Configuración global del enrutamiento

 

Debemos establecer la configuración básica para identificar el enrutador de la red.

  1. Haga clic en la pestaña Manage.
  2. Haga clic en la pestaña Routing.
  3. Seleccione Global Configuration en el panel izquierdo.
  4. Haga clic en Edit junto a Dynamic Routing Configuration.
  5. Seleccione Uplink -192.168.100.4 en el campo Router ID.
  6. Haga clic en OK.

 

 

Publicación de cambios

 

  1. Vuelva a hacer clic en el botón Publish Changes, en el cuadro de diálogo, para enviar la configuración actualizada al dispositivo NSX Edge distribuido.

 

 

Opción Enable OSPF

 

  1. Seleccione OSPF en el panel izquierdo.
  2. Haga clic en Edit junto a OSPF Configuration.
  3. MARQUE la casilla Enable OSPF.
  4. Haga clic en OK.

 

 

Adición de un área nueva

 

  1. Haga clic en el signo más de color verde debajo de Area Definitions.
  2. Ingrese 10 en el campo Area ID.
  3. Haga clic en OK.

 

 

Adición de mapeo de la interfaz de tránsito

 

Ahora, debemos realizar los mismos pasos para la interfaz de enlace descendente en el enrutador distribuido.

  1. Haga clic en el signo más de color verde que se encuentra junto al título Area to Interface Mapping.
  2. Seleccione la opción Transit_Network_01 en el campo vNIC.
  3. Seleccione 10 en el campo Area.
  4. Haga clic en OK.

 

 

Publicación de cambios

 

  1. Vuelva a hacer clic en el botón Publish Changes, en el cuadro de diálogo, para enviar la configuración actualizada al dispositivo NSX Edge distribuido.

 

 

Habilitación del BGP

 

  1. Seleccione BGP en el panel izquierdo.
  2. Haga clic en Edit, junto a BGP Configuration.
  3. MARQUE la casilla Enable BGP.
  4. Ingrese 65001 en el campo Local AS.
  5. Haga clic en OK.

 

 

Incorporación de un nuevo vecino

 

  1. Haga clic en el signo más de color verde debajo del título Neighbors.
  2. Ingrese la dirección 192.168.100.1 en el campo IP Address.
  3. Ingrese 65002 en el campo Remote AS.
  4. Haga clic en OK.

 

 

Publicación de cambios

 

  1. Vuelva a hacer clic en el botón Publish Changes, en el cuadro de diálogo, para enviar la configuración actualizada al dispositivo NSX Edge distribuido.

 

 

Habilitación de la distribución de las rutas de BGP y OSPF

 

Ahora, debemos habilitar la redistribución de rutas de BGP y OSPF para poder acceder a las rutas mediante esta instancia de NSX Edge.

  1. Haga clic en Route Redistribution en el panel izquierdo.
  2. Haga clic en Edit junto a Route Redistribution Status.
  3. Seleccione OSPF.
  4. Marque la opción BGP.
  5. Haga clic en OK.

 

 

Tabla de distribución de las rutas de OSPF

 

  1. Haga clic en el signo más de color verde que se encuentra debajo de Route Redistribution table.
  2. Marque la opción BGP.
  3. Marque la casilla Connected.
  4. Haga clic en OK.

 

 

Tabla de distribución de las rutas de BGP

 

  1. Haga clic en el signo más de color verde que se encuentra debajo de Route Redistribution table.
  2. Seleccione BGP en el campo Learner Protocol.
  3. Seleccione OSPF.
  4. Marque la casilla Connected.
  5. Haga clic en OK.

 

 

Publicación de cambios

 

  1. Vuelva a hacer clic en el botón Publish Changes, en el cuadro de diálogo, para enviar la configuración actualizada al dispositivo NSX Edge distribuido.

 

 

Habilitación de ECMP

 

A continuación, vamos a habilitar ECMP en el enrutador distribuido y los gateways perimetrales.

  1. Haga clic en el botón para regresar a Networking and Security, que se encuentra en el panel Navigator.

 

 

Habilitación del ECMP en el enrutador distribuido

 

Primero, habilitaremos el ECMP en el enrutador distribuido.

  1. Haga clic en NSX Edges.
  2. Haga doble clic en edge-6.

 

 

Habilitación de ECMP en el DLR

 

  1. Haga clic en la pestaña Manage.
  2. Haga clic en la pestaña Routing.
  3. Haga clic en Global Configuration, que se encuentra en el panel izquierdo.
  4. Haga clic en el botón ENABLE ubicado junto a ECMP.

 

 

Publicación del cambio

 

  1. Haga clic en Publish Changes para enviar el cambio de configuración.

 

 

Retorno a los dispositivos NSX Edge

 

  1. Haga clic en el botón Networking & Security para volver a la página anterior.

 

 

Acceso a Perimeter-Gateway-01

 

  1. Haga doble clic en edge-3 (Perimeter-Gateway-01).

 

 

Habilitación del ECMP en Perimeter-Gateway-01

 

  1. Haga clic en la pestaña Manage.
  2. Haga clic en la pestaña Routing.
  3. Haga clic en Global Configuration, que se encuentra en el panel izquierdo.
  4. Haga clic en el botón Enable ubicado junto al campo ECMP.

 

 

Publicación del cambio

 

  1. Haga clic en Publish Changes para enviar el cambio de configuración.

 

 

Retorno a los dispositivos NSX Edge

 

 

 

Acceso a Perimeter-Gateway-02

 

 

 

 

Habilitación del ECMP en Perimeter-Gateway-02

 

  1. Haga clic en la pestaña Manage.
  2. Haga clic en la pestaña Routing.
  3. Haga clic en Global Configuration, que se encuentra en el panel izquierdo.
  4. Haga clic en el botón ENABLE ubicado junto a ECMP.

 

 

Publicación del cambio

 

  1. Haga clic en Publish Changes para enviar el cambio de configuración.

 

 

Descripción general de la topología

 

En esta etapa, la topología del laboratorio se ve de la siguiente manera. Aquí se incluye el nuevo gateway perimetral agregado, el enrutamiento configurado y el ECMP habilitado.

 

 

Verificación de la funcionalidad del ECMP desde el enrutador distribuido

 

Ahora, accedamos al enrutador distribuido para asegurarnos de que la comunicación de OSPF y el funcionamiento de ECMP sean correctos.

  1. Haga clic en el ícono Home.
  2. Seleccione VMs and Templates.

 

 

Opción Launch Remote Console

 

  1. Haga clic en el ícono Refresh.
  2. Expanda la carpeta RegionA01.
  3. Seleccione la opción Distributed-Router-01-0.
  4. Seleccione la pestaña Summary.
  5. Haga clic en Launch Remote Console.

 

 

Acceso a la consola remota

 

La ventana VMRC aparecerá en negro cuando se abra por primera vez.  Haga clic dentro de la ventana y presione Enter un par de veces hasta que aparezca la consola del protector de pantalla.

Nota: Para sacar el cursor de la ventana, presione las teclas Ctrl+Alt.

 

 

Inicio de sesión en el gateway perimetral

 

Inicie sesión en el enrutador distribuido con las credenciales que se mencionan a continuación.

  1. Nombre de usuario: admin
  2. Contraseña: VMware1!VMware1!

 

 

Visualización de vecinos OSPF

 

Lo primero que haremos es analizar los vecinos OSPF en el enrutador distribuido.

  1. Escriba show ip ospf neighbors y presione Enter.  (Recuerde utilizar la opción SEND TEXT).
show ip ospf neighbors 

Con este comando, se muestra que el enrutador distribuido tiene dos vecinos OSPF.  Los vecinos son Perimeter-Gateway-1 (192.168.100.3) y Perimeter-Gateway-2 (192.168.100.4).

Nota: La tabulación automática funciona en los dispositivos NSX Edge

 

 

Revisión de rutas del enrutador distribuido a las instancias de NSX Edge perimetrales

 

  1. Escriba show ip route y presione Enter.
show ip route

Nota: Los segmentos de la red del enrutador vPod y la ruta predeterminada se anuncian en ambas direcciones de la red del gateway perimetral.  Las flechas rojas apuntan a las direcciones de Perimeter-Gateway-01 y Perimeter-Gateway-02.

Deje esta ventana abierta para realizar los pasos siguientes.

 

 

Verificación de la funcionalidad del ECMP desde el enrutador vPod

 

Nota: Para sacar el cursor de la ventana, presione las teclas Ctrl+Alt.

Ahora, analizaremos el ECMP desde el enrutador vPod, el cual simula un enrutador físico en la red.

  1. Haga clic en el ícono PuTTY que se encuentra en la barra de tareas.

 

 

Apertura de una sesión de SSH en el enrutador vPod

 

  1. Use la barra de desplazamiento para desplazarse hacia abajo y seleccione vPod Router.
  2. Haga clic en Load.
  3. Haga clic en Open.

 

 

Inicio de sesión en el enrutador vPod

 

La sesión Putty debería iniciarse automáticamente con el usuario raíz.

 

 

Acceso al módulo de BGP

 

Debemos establecer una comunicación de tipo Telnet con el módulo que controla el BGP en el enrutador vPod.

1.  Ingrese telnet localhost 2605 y presione Enter.  (Recuerde utilizar la opción SEND TEXT).

telnet localhost 2605

2.  Escriba la contraseña VMware1!.

 

 

Visualización de vecinos BGP

 

Debemos establecer una comunicación de tipo Telnet con el módulo que controla BGP en el enrutador vPod.

  1. Escriba show ip bgp neighbors y presione Enter.
show ip bgp neighbors
  1. Veremos Perimeter-Gateway-01 (192.168.100.3) como BGP neighbor con el estado de BGP Established, up.

 

 

Verificación de la relación de Perimeter-Gateway-02

 

  1. Verifique en la lista de vecinos BGP que el Perimeter-Gateway-02 (192.168.100.4) aparezca como BGP neighbor con el estado Established, up.

 

 

Visualización de rutas

 

1. Ingrese el comando show ip bgp y presione Enter.

show ip bgp

2. En esta sección, verá que todas las redes disponen de dos enrutadores de próximo salto. Esto se debe a que el Perimeter-Gateway-01 (192.168.100.3) y el Perimeter-Gateway-02 (192.168.100.4) son vecinos establecidos para estas redes.

En este punto, todo tráfico conectado al enrutador distribuido puede salir por cualquiera de los gateways perimetrales con ECMP.

Deje esta ventana abierta para realizar los pasos siguientes.

 

 

Apagado de Perimeter-Gateway-01

 

Simularemos un nodo que sale de línea apagando Perimeter-Gateway-01.

  1. Expanda las carpetas RegionA01.
  2. Haga clic con el botón secundario del mouse en Perimeter-Gateway-01-0.
  3. Haga clic en Power.
  4. Haga clic en Shut Down Guest OS.

 

 

Confirmación de apagado

 

  1. Haga clic en Yes.

 

 

Prueba de alta disponibilidad con ECMP

 

Con ECMP, BGP y OSPF en el entorno, podemos cambiar las rutas de manera dinámica en caso de que ocurra una falla en una ruta en particular.  Ahora, simularemos la interrupción de una de las rutas de acceso y la redistribución de rutas.

  1. Haga clic en el ícono del símbolo del sistema en la barra de tareas.

 

 

Envío de pings al servidor de base de datos db-01a

 

  1. Escriba ping -t db-01a y presione Enter.
ping -t db-01a

Se mostrarán pings del centro de control al comienzo del servidor de base de datos (db-01a).  No cierre esta ventana cuando proceda con el paso siguiente.

 

 

Acceso a la consola remota del enrutador distribuido

 

 

 

Verificación de rutas actuales

 

  1. Ingrese show ip route y presione Enter.
show ip route

Nota: Solo el Perimeter-Gateway-02 está disponible para acceder a los segmentos de la red del enrutador vPod.

Deje esta ventana abierta para realizar los pasos siguientes.

 

 

Encendido de Perimeter-Gateway-01

 

  1. Expanda las carpetas RegionA01.
  2. Haga clic con el botón secundario del mouse en Perimeter-Gateway-01-0.
  3. Haga clic en Power.
  4. Haga clic en Power On.

 

 

Verificación de la conexión de Perimeter-Gateway-01

 

La VM puede tardar un minuto o dos en encenderse.  Una vez que se muestre que VMTools está en línea en el resumen de VM, puede proceder con el paso siguiente.  

  1. Haga clic en elícono para actualizar a fin de verificar las actualizaciones en el estado de VMTools.

 

 

Regreso a la prueba de ping

 

 

 

Emparejamiento de vecinos BGP

 

Si bien esta no es una representación clara de la falla del Perimeter-Gateway-02 al Perimeter-Gateway-01, el tráfico de pings migraría del Perimeter-Gateway-02 al Perimeter-Gateway-01 sin un impacto significativo en caso de que la ruta activa dejara de funcionar.

 

 

Acceso a la consola remota del enrutador distribuido

 

 

 

Visualización de rutas

 

Verifiquemos el estado de las rutas en Distributed-Router-01 ya que volvimos a activar Perimeter-Gateway-01.

  1. Ingrese show ip route y presione Enter.
show ip route

Nota: Debería ver que todas las redes del enrutador vPod han retomado la conectividad doble.

 

 

Nota final sobre ECMP

Una nota final sobre el ECMP y la alta disponibilidad (HA, High Availability) en este laboratorio.  Aunque apagamos Perimeter-Gateway-01, el resultado en caso de haber apagado Perimeter-Gateway-02 sería el mismo.  

La única consideración es que la aplicación Customer DB App no funciona si Perimeter-Gateway-01 se encuentra sin conexión porque las VM del servidor web están directamente conectadas a dicho gateway.  Para resolver este problema, recomendamos bajar la capa web a Distributed-Router-01 del mismo modo en que bajó las redes de la aplicación y la DB en la sección Enrutamiento dinámico y distribuido de este laboratorio.  Una vez que lo haya hecho, la aplicación Customer DB App comenzará a funcionar si Perimeter-Gateway-1 o 2 están sin conexión.  Es importante que tenga en cuenta que, al realizar esta migración, se anularán los demás módulos de este laboratorio.  Esta es la razón por la que esto no forma parte del manual.  Si no desea realizar otros módulos, la migración se puede llevar a cabo sin problemas.

 

Antes de pasar al módulo 3, realice los siguientes pasos de limpieza.


Si desea continuar con cualquiera de los otros módulos de este laboratorio luego de finalizar el módulo 2, debe completar los pasos siguientes o, de lo contrario, el laboratorio no funcionará de manera correcta a medida que se avanza.


 

Eliminación del segundo dispositivo NSX Edge perimetral

 

  1. Vuelva a vSphere Web Client.
  2. Haga clic en el ícono Home y, luego, en Networking and Security.

 

 

Eliminación de edge-7

 

Debemos eliminar la instancia de NSX Edge que acabamos de crear.

  1. Seleccione NSX Edges.
  2. Seleccione edge-7.
  3. Haga clic en la X de color rojo para eliminarlo.

 

 

Confirmación de la eliminación

 

  1. Haga clic en Yes para confirmar la eliminación.

 

 

Deshabilitación del ECMP en DLR y Perimeter Gateway-01

 

  1. Haga doble clic en edge-6.

 

 

Deshabilitación del ECMP en el enrutador distribuido

 

  1. Haga clic en la pestaña Manage.
  2. Haga clic en la pestaña Routing.
  3. Haga clic en Global Configuration, que se encuentra en el panel izquierdo.
  4. Haga clic en el botón DISABLE al lado de ECMP.

 

 

Publicación del cambio

 

  1. Haga clic en Publish Changes para enviar el cambio de configuración.

 

 

Retorno a los dispositivos NSX Edge

 

  1. Haga clic en el botón Networking & Security para volver a la página anterior.

 

 

Acceso a Perimeter-Gateway-1

 

  1. Haga doble clic en edge-3.

 

 

Deshabilitación del ECMP en Perimeter-Gateway-1

 

  1. Haga clic en la pestaña Manage.
  2. Haga clic en la pestaña Routing.
  3. Haga clic en Global Configuration, que se encuentra en el panel izquierdo.
  4. Haga clic en el botón DISABLE al lado de ECMP.

 

 

Publicación del cambio

 

  1. Haga clic en Publish Changes para enviar el cambio de configuración.

 

Conclusión del módulo 3


En este módulo, mostramos las capacidades de enrutamiento de NSX para el servicio de kernel del hipervisor, enrutador lógico distribuido, así como de las funciones de los servicios avanzados de los gateways de servicio de NSX Edge Gateways.

Cubrimos la migración de los switches lógicos desde el gateway de servicios de NSX Edge hacia el enrutador lógico distribuido (DLR) y la configuración de un protocolo de enrutamiento dinámico entre NSX Edge y el DLR. Además, revisamos las capacidades de enrutamiento centralizado del gateway de servicios de NSX Edge y la información de emparejamiento dinámico de rutas. Por último, pudimos demostrar la escalabilidad y la disponibilidad de los gateways de servicios de NSX Edge en una configuración de ruta ECMP. Implementamos un nuevo gateway de servicios de NSX Edge y establecimos el emparejamiento de rutas mediante el DLR y el enrutador vPod, a fin de aumentar la tasa de transferencia (throughput) y la disponibilidad mediante ECMP. También limpiamos la configuración del ECMP para poder seguir con el siguiente módulo del laboratorio.


 

Ha finalizado el módulo 3.

Felicitaciones por completar el módulo 3.

Si desea obtener más información sobre la configuración y las capacidades de enrutamiento de NSX, consulte el centro de documentación de NSX 6.2 mediante la URL que se muestra a continuación:

Continúe con cualquiera de los siguientes módulos que sea de su interés:

Lista de los módulos del laboratorio:

Capitanes del laboratorio:

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Módulo 4: Gateway de servicios de NSX Edge (60 minutos)

Introducción al gateway de servicios de NSX Edge


Mediante NSX Edge, se ofrecen seguridad del perímetro de la red y servicios de gateway para aislar una red virtualizada. Puede instalar una instancia de NSX Edge como un enrutador lógico (distribuido) o como un gateway de servicios.

Mediante el enrutador lógico (distribuido) NSX Edge, se establece un enrutamiento distribuido de este a oeste, con aislamiento del espacio de direcciones IP y la ruta de datos del cliente (tenant). Las máquinas virtuales o las cargas de trabajo que residen en el mismo host en subredes diferentes se pueden comunicar mutuamente sin tener que atravesar una interfaz de enrutamiento tradicional.

El gateway de NSX Edge conecta redes aisladas (stub) con redes compartidas (uplink) mediante la provisión de servicios de gateway comunes, como DHCP, VPN, NAT, enrutamiento dinámico y balanceo de cargas. Entre las implementaciones comunes de NSX Edge, se incluyen las siguientes: zona desmilitarizada (DMZ), VPN, Extranets y entornos de nube multiclientes, donde NSX Edge crea límites virtuales para cada cliente (tenant).

En este módulo, se incluyen las siguientes lecciones:


Implementación del gateway de servicios NSX Edge para Balanceo de cargas


El gateway de servicios de NSX Edge también puede ofrecer la funcionalidad de balanceo de cargas.  El uso de un balanceador de carga puede resultar provechoso, ya que conduce a una utilización más eficaz de los recursos. Entre los ejemplos, se incluyen la utilización más eficaz de throughput, tiempos de respuesta más cortos en las aplicaciones, capacidad de escalar y parte de una estrategia para asegurar la redundancia y la disponibilidad de los servicios.

Las cargas de las peticiones de TCP, UDP, HTTP o HTTPS se pueden balancear por medio del gateway de servicios NSX Edge. El gateway de servicios NSX Edge puede balancear cargas hasta la capa 7 del modelo de interconexión de sistemas abiertos (Open Systems Interconnection, OSI).  

En esta sección, implementaremos y configuraremos un nuevo dispositivo NSX Edge como un balanceador de carga "de un solo brazo".


 

Validación del estado completo del laboratorio

 

Mediante la validación del estado, es posible asegurarse de que todos los componentes del laboratorio se implementen de manera correcta. Una vez que se haya completado la validación, el estado se actualizará al color verde y aparecerá la palabra Ready para indicar que está listo. Es posible que la implementación del laboratorio falle debido a una restricción de recursos en el entorno.

 

 

Inicio de sesión en vSphere Web Client

 

Si aún no inició sesión en vSphere Web Client, haga lo siguiente:

Haga clic en el ícono de la barra de tareas de Google Chrome. Debe tener vSphere Web Client como página de inicio.

  1. Marque la casilla junto a Use Windows session authentication.
  2. Haga clic en el botón Login.

 

 

Contraiga el panel de tareas derecho para tener más espacio en la pantalla.

 

Si hace clic en los alfileres, se contraerán los paneles de tareas y tendrá más espacio en el panel principal.  También puede contraer el panel izquierdo para obtener el máximo espacio.

 

 

Ingreso a la opción Networking  Security

 

  1. Haga clic en "Networking & Security".

 

 

Creación de un nuevo gateway de servicios de NSX Edge

 

Configuraremos el servicio de balanceo de cargas de "un solo brazo" en un nuevo gateway de servicios de NSX Edge. Para comenzar con la creación de un nuevo gateway de servicios de NSX Edge, asegúrese de que se encuentra en la sección Networking & Security de vSphere Web Client:

  1. Haga clic en NSX Edges.
  2. Haga clic en el signo más (+) de color verde.

 

 

Definición del nombre y del tipo

 

Para el nuevo gateway de servicios de NSX Edge, realice los siguientes ajustes:

  1. Ingrese el nombre OneArm-LoadBalancer.
  2. Haga clic en el botón Next.

 

 

Configuración de la cuenta del administrador

 

  1. Establezca la contraseña VMware1!VMware1!.
  2. Haga clic en el botón Next.

 

 

Definición del tamaño de NSX Edge y la ubicación de la VM

 

Hay cuatro tamaños distintos de dispositivos que puede elegir para el gateway de servicios de NSX Edge, con las siguientes especificaciones (cantidad de CPU, memoria):

Elegiremos el tamaño Compact de NSX Edge para el nuevo gateway de servicios de NSX Edge, pero tenga en cuenta que también es posible aumentar el tamaño después de la implementación. Para continuar con la creación del gateway de servicios de NSX Edge, realice los siguientes pasos:

  1. Haga clic en el signo más (+) de color verde para abrir la ventana emergente Add NSX Edge Appliances.

 

 

Ubicación del clúster y del datastore

 

  1. Seleccione RegionA01-MGMT01 para el campo Cluster/Resource Pool.
  2. Seleccione RegionA01-ISCSI01-MGMT01 como la ubicación en el campo Datastore.
  3. Seleccione el host esx-05-a.corp.local.
  4. Haga clic en OK.

 

 

Configuración de la implementación

 

  1. Haga clic en el botón Next.

 

 

Ubicación de una nueva interfaz de red en NSX Edge

 

Debido a que es un balanceador de carga de un solo brazo, necesitará únicamente una interfaz de red.  Durante esta etapa del proceso de la nueva instancia de NSX Edge, deberemos asignarle a esta un nuevo adaptador de red y configurarlo.  

  1. Haga clic en el signo más (+) de color verde.

 

 

Configuración de la nueva interfaz de red para NSX Edge

 

Aquí, deberemos configurar la primera interfaz de red para este nuevo NSX Edge.  

  1. Asigne el nombre WebNetwork a la interfaz nueva.
  2. En Type, marque la opción Internal.
  3. Haga clic en el enlace Select.

 

 

Selección de la red para la nueva interfaz de NSX Edge

 

Esta interfaz del balanceador de carga de enlace único deberá estar en la misma red que los dos servidores web a los que esta instancia de NSX Edge les suministrará servicios de balanceador de carga.

  1. Seleccione la pestaña Logical Switch.
  2. Haga clic en el botón de selección de Web_Tier_Logical_Switch (5000).
  3. Haga clic en el botón OK.

 

 

Configuración de las subredes

 

  1. A continuación, configuraremos una dirección IP para esta interfaz. Haga clic en el signo más (+) de color verde.

 

 

Configuración de las ventanas emergentes de las subredes

 

Para agregar una dirección IP nueva a esta interfaz, haga lo siguiente:

  1. Ingrese la dirección 172.16.10.10 como dirección IP.
  2. En Subnet Prefix Length, escriba 24.
  3. Haga clic en OK.

 

 

Confirmación de la lista de interfaces

 

Revise las selecciones y los ajustes realizados.

  1. Haga clic en el botón Next para continuar.

 

 

Configuración del gateway predeterminado

 

En la siguiente sección sobre el aprovisionamiento de una nueva instancia de NSX Edge, podremos configurar el gateway predeterminado para este gateway de servicios de NSX Edge. Para configurar el gateway, haga lo siguiente:

  1. Ingrese la dirección 172.16.10.1 en el campo Gateway IP.
  2. Haga clic en el botón Next.

 

 

Configuración de las opciones de firewall y HA

 

Para ahorrar tiempo en el futuro, podemos configurar algunas opciones predeterminadas de firewall y habilitar el modo de alta disponibilidad (High Availability, HA) en el gateway de servicios de NSX Edge.  Ninguna función es relevante en esta sección específica del módulo. Por lo tanto, para continuar realice la siguiente configuración:

  1. Marque la casilla Configure Firewall default policy.
  2. Marque Accept en el campo Default Traffic Policy.
  3. Haga clic en Next.

 

 

Revisión y finalización de la configuración general

 

Verifique que la configuración sea como se muestra en la captura de pantalla.

  1. Haga clic en Finish.

 

 

Monitoreo de la implementación

 

Para monitorear la implementación del gateway de servicios de NSX Edge, realice los siguientes pasos:

  1. Haga clic en el botón Installing durante el proceso de implementación de NSX Edge para seguir el progreso de los pasos de instalación.

Después de eso, debería ver el progreso de la implementación de NSX Edge.  

 

Configuración del gateway de servicios de NSX Edge para el balanceador de carga


Una vez que hayamos implementado el gateway de servicios de NSX Edge, configuraremos los servicios de balanceo de carga.


 

Configuración del servicio de balanceador de carga

 

A continuación, se muestra la topología final del servicio de balanceador de carga suministrado por el gateway de servicios de NSX Edge que implementamos recientemente. Para comenzar, desde la opción NSX Edges del plug-in de Networking & Security de vSphere Web Client, haga doble clic en la instancia de NSX Edge que creamos para ir a la página de administración.

 

 

Configuración de la función de balanceador de carga en OneArm Load Balancer

 

  1. Haga doble clic en edge-7 (OneArm-LoadBalancer).

 

 

Navegación hasta la página de administración de la nueva instancia de NSX Edge

 

  1. Si todavía no está seleccionada, haga clic en la pestaña Manage.
  2. Haga clic en la subpestaña Load Balancer.
  3. Si todavía no está seleccionada, haga clic en la pestaña Global Configuration.
  4. Haga clic en el botón Edit para ir a la ventana emergente Edit Load balancer global configuration.

 

 

Ventana Edit Load Balancer Global Configuration

 

Para habilitar el servicio de balanceador de carga, realice los siguientes pasos:

  1. Marque la casilla junto a Enable Load Balancer.
  2. Haga clic en el botón OK.

 

 

Creación de un nuevo perfil de aplicación

 

Un perfil de aplicación es la manera en la que definimos el comportamiento de una clase típica de tráfico de red.  Estos perfiles se aplican luego a un servidor virtual (VIP) que controla el tráfico conforme a los valores especificados en el perfil de aplicación.  

Mediante la utilización de perfiles, las tareas de administración de tráfico son más eficaces y presentan menos errores.  

  1. Haga clic en Application Profiles.
  2. Haga clic en el signo más (+) de color verde para que se abra la ventana emergente New Profile.

 

 

Configuración de un HTTPS para el nuevo perfil de aplicación

 

Para el nuevo perfil de aplicación, configure los siguientes parámetros:

  1. Name: OneArmWeb-01
  2. Type: HTTPS
  3. Marque la casilla junto a Enable SSL Passthrough. Esto permitirá que el tráfico SSL sea terminado en el pool de servidores.
  4. Haga clic en OK cuando haya finalizado.

 

 

Modificación del monitor de HTTPS predeterminado

 

Por medio de los monitores, se verifica que los miembros del pool que brindan servicios al servidor virtual se encuentren funcionando de manera correcta. El monitor de HTTPS predeterminado realizará un comando de "GET" a la página de inicio "/". Modificaremos el monitor predeterminado para realizar una comprobación del estado en la URL específica de la aplicación. Esto ayudará a determinar que los servidores miembros del depósito y la aplicación están funcionando correctamente.

  1. Haga clic en Service Monitoring.
  2. Haga clic en default_https_monitor y resalte la opción.
  3. Haga clic en el ícono de lápiz.
  4. Escriba "/cgi-bin/hol.cgi" en el campo URL.
  5. Haga clic en OK.

 

 

Creación de un depósito nuevo

 

Un grupo de servidores del pool es la entidad que representa los nodos (servidores) hacia los cuales se balanceará el tráfico.  Agregaremos los dos servidores web web-01a y web-02a a un pool nuevo. Para crear un pool nuevo, primero debe hacer lo siguiente:

  1. Haga clic en Pools.
  2. Haga clic en el signo más (+) de color verde para abrir la ventana emergente Edit Pool.

 

 

Configuración de un Pool nuevo

 

Para configurar un Pool nuevo, ajuste estos parámetros:

  1. Name: Web-Tier-Pool-01
  2. Monitors: default_https_monitor
  3. Haga clic en el signo más (+) de color verde.

 

 

Incorporación de miembros al Pool

 

  1. Escriba web-01a en el campo Name.
  2. Ingrese 172.16.10.11 en el campo IP Address.
  3. Ingrese el número 443 en el campo Port.
  4. Ingrese el número 443 en el campo Monitor Port.
  5. Haga clic en OK.

Repita los pasos para agregar un miembro más al Pool con la información que se brinda a continuación.

 

 

Guardar la configuración del Pool

 

  1. Haga clic en OK.

 

 

Creación de un servidor virtual nuevo

 

Un servidor virtual es la entidad que acepta el tráfico que proviene del "front end" del servicio del balanceador de carga.  El tráfico de usuarios se dirige hacia la dirección IP que representa el servidor virtual y, luego, se redistribuye hacia los nodos en el "back end" del balanceador de carga. Para configurar un servidor virtual nuevo en este gateway de servicios de NSX Edge, primero debe hacer lo siguiente:

  1. Haga clic en Virtual Servers.
  2. Haga clic en el signo más (+) de color verde para abrir la ventana emergente New Virtual Server.

 

 

Configuración de un nuevo servidor virtual

 

Configure las siguientes opciones para el nuevo servidor virtual:

  1. Seleccione el servidor virtual Web-Tier-VIP-01 en el campo  Name.
  2. Ingrese la dirección 172.16.10.10 en el campo IP Address.
  3. Seleccione el protocolo HTTPS en el campo Protocol.
  4. Seleccione Web-Tier-Pool-01.
  5. Haga clic en OK para finalizar la creación del nuevo servidor virtual.

 

Verificación de la configuración del balanceador de carga del gateway de servicios NSX Edge


Una vez que hayamos configurado los servicios de balanceo de carga, verificaremos la configuración realizada.


 

Prueba de acceso al servidor virtual

 

  1. Haga clic en una nueva pestaña del navegador.
  2. Haga clic en el marcador favorito 1-Arm LB Customer DB.
  3. Haga clic en Advanced.

 

 

Omitir el mensaje de error SSL

 

  1. Haga clic en Proceed to 172.16.10.10 (unsafe).

 

 

Prueba de acceso al servidor virtual

 

A partir de ahora, deberíamos poder acceder al balanceador de carga de un brazo que acabamos de configurar.  

  1. Cuando haga clic en el botón actualización de página, podrá ver el mecanismo round robin de los dos miembros del depósito.

 

 

Visualización de estadísticas del Pool

 

Para ver el estado de los miembros del Pool, haga lo siguiente:

  1. Haga clic en Pools.
  2. Haga clic en Show Pool Statistics.
  3. Haga clic en "pool-1".

Aparecerá el estado actual de cada miembro.

  1. Haga clic en la X para cerrar la ventana.

 

 

Mejora del monitoreo de respuesta (Health Check)

 

Para facilitar la solución de problemas, el comando "show ...pool" del balanceador de carga de NSX 6.2 ofrecerá una descripción informativa de las fallas de los miembros del depósito. Crearemos dos fallas distintas y examinaremos la respuesta mediante los comandos show en el gateway de NSX Edge del balanceador de carga.

  1. Escriba "LoadBalancer" en la esquina superior derecha del cuadro de búsqueda de vSphere Web Client.
  2. Haga clic en OneArm-LoadBalancer-0.

 

 

Apertura de la consola del balanceador de carga de la consola

 

  1. Haga clic en la pestaña Summary.
  2. Haga clic en Launch Remote Console.

Nota: La consola se abrirá en una nueva pestaña del navegador.

 

 

Inicio de sesión en OneArm-LoadBalancer-0

 

  1. Inicie sesión con la siguiente información: user: admin y password: VMware1!VMware1!.

 

 

Instrucciones especiales para los comandos CLI

 

En muchos de los módulos, deberemos ingresar comandos de interfaz de línea de comando (CLI).  Existen dos maneras de enviar comandos CLI al laboratorio.

En primer lugar, para enviar un comando CLI a la consola del laboratorio, siga los siguientes pasos:

  1. Resalte el comando CLI en el manual y use Control+C para copiarlo al portapapeles.
  2. Haga clic en el elemento del menú de la consola SEND TEXT.
  3. Presione Control+V para pegarlo del portapapeles a la ventana.
  4. Haga clic en el botón SEND.

En segundo lugar, en el escritorio del entorno, encontrará un archivo de texto (README.txt) en el que se le proporcionan todas las cuentas de usuario y contraseñas.

 

 

Análisis del estado del Pool antes de una falla

 

Utilice el nombre de usuario "admin" y la contraseña "VMware1!VMware1!" para iniciar sesión.

show service loadbalancer pool

Nota: El estado del miembro del depósito web-sv-01a figura como "UP".

 

 

Inicio de PuTTY

 

  1. Haga clic en el acceso directo de PuTTY que se encuentra en la barra de inicio de Windows.

 

 

SSH a web-01a.corp.local

 

  1. Desplácese hasta web-01a.corp.local.
  2. Seleccione web-01a.corp.local.
  3. Haga clic en Load.
  4. Haga clic en Open.

 

 

Interrupción del servicio HTTPD

 

Desactivaremos el HTTPS para simular la primera falla.

  1. Escriba service httpd stop para interrumpir el servicio HTTPD.
service httpd stop

 

 

Consola del balanceador de carga

 

show service loadbalancer pool

Debido a que el servicio está caído, el detalle de la falla muestra que el cliente no pudo establecer una sesión SSL.

 

 

Reinicio del servicio HTTPD

 

Vuelva a la sesión SSH de Putty para el servidor web-01a.

1. Escriba service httpd start.

service httpd start

 

 

Apagado de web-01a

 

Regrese al navegador Chrome y a vSphere Web Client.

  1. Escriba "web-01a" en el cuadro de búsqueda que se encuentra en la esquina superior derecha de vSphere Web Client.
  2. Haga clic en web-01a.

 

 

Apagado de web-01a

 

  1. Haga clic en Actions.
  2. Haga clic en Power.
  3. Haga clic en Power Off.

 

 

Comprobación del estado del Pool

 

show service loadbalancer pool

Debido a que ahora la VM está apagada, el detalle de la falla muestra que el cliente no pudo establecer una conexión L4 en comparación con la conexión L7 (SSL) en el paso anterior.

 

 

Encendido de web-01a

 

  1. Haga clic en Actions.
  2. Haga clic en Power.
  3. Haga clic en Power On.

 

 

Conclusión

En este laboratorio, implementamos y configuramos un nuevo gateway de servicios de NSX Edge y habilitamos servicios de balanceo de carga para la aplicación 1-Arm LB Customer DB.

Aquí finaliza la lección sobre el balanceador de carga del gateway de servicios de NSX Edge. A continuación, exploraremos en profundidad el firewall del gateway de servicios de NSX Edge.

 

Firewall del gateway de servicios de NSX Edge


Con el firewall de NSX Edge, se monitorea el tráfico de norte a sur para proveer seguridad perimetral, incluyendo firewall, traducción de direcciones de red (Network Address Translation, NAT), VPN site-to-site IPsec así como VPN SSL. Los ajustes de firewall se aplican al tráfico que no corresponde con ninguna de las reglas de firewall definidas por el usuario. La política predeterminada de firewall de NSX Edge bloquea todo el tráfico entrante.


 

Aplicación de las reglas de firewall de NSX Edge

Podemos navegar hacia una instancia de NSX Edge para ver las reglas de firewall que se aplican. Las reglas de firewall que se aplican a un enrutador lógico solo protegen el tráfico en el plano de control que se dirige a la máquina virtual de control del enrutador lógico y el tráfico que proviene de esta. No ofrecen ningún tipo de protección en el nivel del plano de datos. Si desea proteger el tráfico en el plano de datos, debe crear reglas de firewall lógico para proteger el tráfico de este a oeste o crear reglas en el gateway de servicios de NSX Edge para proteger el tráfico de norte a sur.

Las reglas creadas en la interfaz de usuario del firewall que se aplican a esta instancia de NSX Edge se muestran en modo de solo lectura únicamente. Las reglas se muestran y se aplican en el siguiente orden:

  1. Reglas definidas por el usuario creadas en la interfaz de usuario del firewall (solo lectura)
  2. Reglas autoasociadas (reglas que permiten que el tráfico de control fluya para los servicios de NSX Edge)
  3. Reglas definidas por el usuario creadas en la interfaz de usuario del firewall de NSX Edge
  4. Regla por defecto (default).

 

 

Ingreso a la opción Networking  Security

 

  1. Haga clic en Networking & Security.

 

 

Apertura de una instancia de NSX Edge

 

  1. Seleccione NSX Edges.
  2. Haga doble clic en Perimeter Gateway-01.

 

 

Apertura de la pestaña Manage

 

  1. Seleccione la pestaña Manage.
  2. Seleccione Firewall.
  3. Seleccione Default Rule, la última regla en la tabla del firewall.

 

 

Edición de la acción de reglas de firewall

 

  1. Coloque el mouse en la celda Action de la regla y haga clic.
  2. Haga clic en el menú desplegable Action y seleccione Deny.

 

 

Publicación de cambios

 

No realizaremos cambios permanentes en la configuración del firewall del gateway de servicios de NSX Edge.

  1. Seleccione Revert para deshacer los cambios.

 

 

Adición de una regla de firewall del gateway de servicios de NSX Edge

 

Ahora que estamos familiarizados con la edición de una regla de firewall existente del gateway de servicios de NSX Edge, incorporaremos una nueva regla de firewall que bloqueará el acceso del centro de control a la aplicación de base de datos del cliente.

  1. Seleccione el símbolo (+) de color verde para agregar una nueva regla de firewall.
  2. En la columna Name, coloque el mouse en la esquina superior derecha y seleccione el símbolo (+).
  3. Ingrese el nombre de la regla: Main Console FW Rule
  4. Haga clic en OK.

 

 

Indicar Origen

 

En el campo Source, coloque el mouse en la esquina superior derecha y seleccione el símbolo (+).

  1. Haga clic en el menú desplegable Object Type y seleccione IP Sets.
  2. Haga clic en el hipervínculo New IP Set...
  3. Escriba Main Console en el cuadro de texto IP Set Name.
  4. Escriba la dirección IP del centro de control: 192.168.110.10
  5. Haga clic en OK.

 

 

Confirmación del origen

 

  1. Verifique que se muestre Main Console en Selected Objects.
  2. Haga clic en OK.

 

 

Ventana Specify Destination

 

En la columna Destination, coloque el mouse en la esquina superior derecha y seleccione el símbolo (+).

  1. Haga clic en el menú desplegable Object Type y seleccione Logical Switch.
  2. Haga clic en Web_Tier_Logical_Switch.
  3. Haga clic en la flecha derecha para mover Web_Tier_Logical_Switch a Selected Objects.
  4. Haga clic en OK.

 

 

Configuración de la sección Action

 

  1. En la esquina superior derecha de la columna Action, haga clic en el ícono (+).
  2. Haga clic en el menú desplegable Action y seleccione Deny.
  3. Haga clic en OK.

 

 

Publicación de cambios

 

  1. Haga clic en Publish Changes.

 

 

Prueba de la nueva regla de firewall

 

Ahora que ya hemos configurado una nueva regla de firewall que bloqueará el acceso del centro de control al switch lógico de nivel web, realicemos una prueba rápida:

  1. Abra una pestaña nueva del navegador Chrome.
  2. Haga clic en el marcador Customer DB App.
  3. Verifique que la consola principal no pueda acceder a la aplicación Customer DB App.

Después de unos minutos, debería aparecer una página del navegador que indique que no se puede acceder al sitio. Ahora, modifiquemos la regla de firewall para permitir que la consola principal acceda a la aplicación Customer DB App.

 

 

Cambio de la regla de firewall de la consola principal a Accept

 

Vuelva a la pestaña de vSphere Web Client.

  1. Haga clic en el símbolo (+), en la esquina superior derecha de la columna Action de la regla de firewall de la consola principal.
  2. Haga clic en el menú desplegable Action y seleccione la opción Accept.
  3. Haga clic en OK.

 

 

 

Publicación de cambios

 

1. Haga clic en Publish Changes.

 

 

Confirmación de acceso a Customer DB App

 

Ahora que la regla de firewall de la consola principal se ha cambiado a "Accept", la consola principal puede acceder a Customer DB App.

 

 

Eliminación de la regla de firewall de la consola principal

 

  1. Seleccione la fila correspondiente a la regla de firewall de la consola principal.
  2. Haga clic en el ícono rojo (x) para eliminar la regla de firewall.
  3. Haga clic en OK para confirmar la eliminación.

 

 

Publicación de cambios

 

1. Haga clic en Publish Changes.

 

 

Conclusión

En este laboratorio, aprendimos a modificar una regla de firewall del gateway de servicios de NSX Edge existente y a configurar una nueva regla de firewall del gateway de servicios de NSX Edge para bloquear el acceso externo a la aplicación Customer DB App.

Aquí finaliza la lección sobre el firewall del gateway de servicios de NSX Edge. A continuación, aprenderemos más sobre cómo el gateway de servicios de NSX Edge puede administrar servicios de DHCP (Dynamic Host Configuration Protocol).

 

Retransmisión de DHCP


En una red donde solo hay un segmento de red, los clientes de DHCP pueden comunicarse de manera directa con el servidor del DHCP. Los servidores DHCP también pueden suministrar direcciones IP a múltiples redes, aún a aquellas que no se encuentran en los mismos segmentos. Sin embargo, cuando el servidor provee direcciones IP para rangos de IP diferentes del suyo, no podrá comunicarse con aquellos clientes de manera directa. Esto se debe a que los clientes no cuentan de una dirección IP enrutable ni un gateway disponible.

En este tipo de situaciones, se necesita un agente de relay de DHCP para retransmitir el broadcast que se recibe de los clientes del DHCP al servidor del DHCP en modo Unicast. El servidor del DHCP seleccionará un scope de DHCP según el intervalo de donde provenga el Unicast y lo reenviará a la dirección del agente que luego se difundirá por broadcast nuevamente a la red original del cliente.

Las áreas que deben cubrirse en este laboratorio son las siguientes:

En este laboratorio, se preconfiguraron los siguientes elementos:


 

Topología del laboratorio

 

En este diagrama, se muestra la topología final que se creará y usará en este módulo del laboratorio.

 

 

Acceso a NSX mediante Web Client

 

Ingrese a la sección Networking & Security en Web Client.

  1. Haga clic en Networking & Security en el panel izquierdo.

 

 

Creación de un switch lógico nuevo

 

En primer lugar, es necesario crear un switch lógico nuevo que se ejecutará en la red nueva 172.16.50.0/24.

  1. Seleccione Logical Switches.
  2. Haga clic en el signo más (+) de color verde para crear un switch lógico nuevo.

 

 

Ingreso de los parámetros del switch nuevo

 

Para configurar el switch lógico, debemos establecer el nombre y la zona de transporte.

  1. En el campo Transport Zone, haga clic en Change.

 

 

Selección de la zona de transporte

 

  1. Seleccione RegionA0_TZ.
  2. Haga clic en OK.

 

 

Ingreso de los parámetros del switch nuevo

 

El nombre no es particularmente relevante, pero sirve para identificar el switch.

  1. Nombre: DHCP-Relay
  2. Haga clic en OK.

 

 

Conexión del switch lógico al gateway perimetral

 

En este paso, se añadirá el switch lógico a una interfaz en el gateway perimetral. Esta interfaz será el gateway predeterminado para la red 172.16.50.0/24 y la dirección será 172.16.50.1.

  1. Haga clic en NSX Edges en el panel izquierdo.
  2. Haga doble clic en edge-3, que es el gateway perimetral de este laboratorio.

 

 

Adición de la interfaz

 

En esta sección, se agregará el switch lógico a una interfaz en el gateway perimetral.

  1. Haga clic en Manage.
  2. Haga clic en Settings.
  3. Haga clic en Interfaces.
  4. Seleccione vnic9.
  5. Haga clic en el ícono de lápiz para editar la interfaz.

 

 

Selección del switch lógico al que se conecta la interfaz

 

Se seleccionará a qué switch lógico se conecta la interfaz.

  1. Haga clic en Select.

 

 

Selección del switch lógico que se creó recientemente

 

Seleccione el switch lógico nuevo que acabamos de crear en los pasos anteriores.

  1. En Logical Switch, seleccione DHCP-Relay.
  2. Haga clic en OK.

 

 

Adición de la dirección IP de la interfaz

 

Agregaremos una nueva dirección IP.

1. Haga clic en el signo más (+) de color verde.

 

 

Configuración de la dirección IP de la interfaz

 

Se asignará una dirección IP a la nueva interfaz.

  1. En el campo Primary IP address, ingrese 172.16.50.1.
  2. En el campo Subnet Prefix Length, ingrese 24.

 

 

Finalización de la configuración de la interfaz

 

Corrobore toda la información y finalice la configuración.

  1. Cambie el nombre del campo Name de vnic9 a DHCP Relay para facilitar la identificación más tarde.
  2. Haga clic en OK.

 

 

Configuración de la retransmisión del DHCP

 

En la ventana Perimeter Gateway, debemos establecer la configuración global de la retransmisión del DHCP.

  1. Haga clic en la pestaña Manage.
  2. Haga clic en el botón DHCP.
  3. Haga clic en la sección Relay , que se encuentra en el panel izquierdo.
  4. Haga clic en Edit.

 

 

Configuración global del DHCP

 

En la configuración global del DHCP, debemos seleccionar los servidores de DHCP que atenderán las solicitudes de DHCP desde las guest VM's.

Hay tres métodos con los que podemos configurar las direcciones IP del servidor de DHCP:

Conjuntos IP

Los conjuntos IP se configuran en la configuración global de NSX Manager y nos permiten especificar un subconjunto de servidores de DHCP mediante la creación un grupo denominado.

Direcciones IP

En este método, podemos especificar de forma manual las direcciones IP de los servidores de DHCP.

Nombres de dominio

Este método nos permite especificar un nombre de sistema de nombres de dominio (Domain Name Server, DNS) que podría ser una dirección única o diversas direcciones de servidores de DHCP.

 

En este laboratorio, utilizaremos una sola dirección IP.

  1. En el campo IP Addresses, ingrese 192.168.110.10, que sería la dirección IP del servidor de DHCP.
  2. Haga clic en OK.

 

 

Configuración del agente de retransmisión del DHCP

 

El agente de retransmisión del DHCP retransmitirá cualquier solicitud DHCP desde la dirección del gateway del switch lógico a los servidores DHCP configurados.  Debemos agregar un agente al switch lógico o al segmento que creamos en 172.16.50.0/24.

  1. En la sección DHCP Relay Agents, haga clic en el signo más de color verde.

 

 

Selección de la interfaz del gateway perimetral

 

Seleccione la interfaz del gateway perimetral que dispondrá del agente de retransmisión.

  1. Haga clic en el menú desplegable vNIC y seleccione la interfaz que creamos recientemente, DHCP Relay Internal.
  2. Haga clic en OK.

 

 

Publicación de la configuración en la configuración de retransmisión del DHCP

 

Ahora debemos publicar todos estos cambios realizados en el enrutador distribuido.

  1. Haga clic en Publish Changes.

 

 

Creación de una VM vacía para el arranque PXE

 

En esta instancia, crearemos una VM vacía que llevará a cabo un arranque PXE desde el servidor de DHCP al que realizamos la retransmisión.

  1. Haga clic en el ícono Home.
  2. Haga clic en Hosts and Clusters.

 

 

Creación de una nueva VM

 

  1. Expanda RegionA01-COMP01
  2. Seleccione esx-02a.corp.local
  3. Seleccione el menú desplegable Actions.
  4. Luego, haga clic en New Virtual Machine y New Virtual Machine

 

 

Configuración de la VM nueva

 

  1. Seleccione Create a New Virtual Machine.
  2. Haga clic en Next.

 

 

Asigne un nombre a la VM.

 

  1. Ingrese PXE VM como nombre de la VM.
  2. Haga clic en Next.

 

 

Selección del host

 

  1. Haga clic en Next.

 

 

Selección del almacenamiento

 

Deje la opción predeterminada.

  1. Haga clic en Next.

 

 

Selección de compatibilidad

 

Deje la opción predeterminada.

  1. Haga clic en Next.

 

 

Selección de SO invitado

 

Deje la opción predeterminada.

  1. En el campo Guest OS Family, seleccione Linux.
  2. En el campo Guest OS Version, seleccione Other Linux (64-bit).
  3. Haga clic en Next.

 

 

Especificación de hardware: eliminación del disco duro

 

Es necesario eliminar el disco duro predeterminado. Debido a que se realizará el arranque desde la red, no se necesita el disco duro.  Esto se debe a que la imagen PXE arranca y se ejecuta por completo en la memoria RAM.

  1. Pase el cursor del mouse por encima de la opción New Hard Disk y la X aparecerá a la derecha.  Haga clic en la X para eliminar el disco duro.

 

 

Especificación del hardware: selección de red

 

Ahora, seleccionaremos el switch lógico basado en VXLAN que creamos en pasos anteriores, DHCP-Relay.  Podemos seleccionarlo en esta sección o, de forma alterna, asignar la VM a ese switch lógico.  Para realizar este paso, se debe seleccionar el switch lógico y, luego, hacer clic en Add, en el menú NSX Logical Switch.

  1. Seleccione la red que contenga las palabras DHCP Relay.  Es posible que el valor UUID completo del switch lógico sea distinto del que se mostró en la captura de pantalla anterior, pero solo en una de las opciones se encontrarán las palabras DHCP-Relay. Si no puede ver la red en la lista, haga clic en "show more networks".
  2. Haga clic en Next.

 

 

Terminar la creación de la VM

 

  1. Haga clic en Finish.

 

 

Acceso a la VM recientemente creada

 

A continuación, abriremos una consola para esta VM, la encenderemos y veremos cómo arranca a partir de la imagen PXE.  La información se recibe por medio del servidor de DHCP remoto que se configuró previamente.

  1. Seleccione PXE VM en el panel izquierdo.
  2. Seleccione la pestaña Summary.
  3. Haga clic en Launch Remote Console.

 

 

Encendido de la VM

 

Encienda la nueva VM.

  1. Haga clic en el botón Play.

 

 

Obtención de DHCP desde un servidor remoto

 

Observe que la VM intenta arrancar y obtener una dirección de DHCP.

 

 

Arranque con imagen

 

La pantalla que se muestra a continuación aparecerá cuando la VM disponga de una dirección de DHCP y esté descargando una imagen PXE desde el servidor de arranque.  Esta pantalla durará un par de minutos. Proceda con el siguiente paso.

 

 

Verificación de la concesión de DHCP

 

Mientras esperamos que la VM arranque, podemos verificar la dirección que se utiliza en las concesiones de DHCP.

  1. Diríjase al escritorio de la consola principal y haga doble clic sobre el ícono DHCP.

 

 

Visualización de concesiones

 

Podemos ver las direcciones que tomó la VM desde el servidor de DHCP.

  1. Haga clic en las flechas para expandir las secciones.
  2. Seleccione Address Leases.
  3. Podrá observar la dirección 172.16.50.10, que se encuentra en el intervalo que creamos previamente.

 

 

Visualización de opciones

 

También podemos ver las opciones de intervalos utilizadas para arrancar la imagen PXE.

  1. Seleccione Scope Options.
  2. Notará que se utilizaron las opciones 66 y 67.

Ahora, puede cerrar la ventana DHCP.

 

 

Acceso a la VM encendida

 

  1. Para regresar a la consola de la VM con PXE, selecciónela en la barra de tareas.

 

 

Verificación de la dirección y la conectividad

 

En el widget que se encuentra en la esquina superior derecha de la VM, se mostrarán las estadísticas junto con la dirección IP de la VM. La dirección que se muestra debe ser la misma dirección IP que se mostró previamente en la ventana DHCP.

 

 

Verificación de la conectividad

 

Debido al enrutamiento dinámico ya implementado con la red virtual, hay conectividad disponible a la VM desde el momento de su creación.  A fin de verificar la conectividad, podemos hacer ping desde la consola principal.

  1. Haga clic en el ícono Command Prompt ubicado en la barra de tareas.

2.     Escriba ping 172.16.50.10 y presione Enter.   (Recuerde utilizar la opción SEND TEXT).

ping 172.16.50.10

Verá la respuesta de ping que envió la VM.  Ahora, puede cerrar esta ventana de comando.

 

 

Conclusión

En este laboratorio, hemos completado la creación de un nuevo segmento de red y, luego, hemos retransmitido las solicitudes de DHCP desde dicha red hasta un servidor de DHCP externo.  Al realizar estos procedimientos, pudimos acceder a opciones adicionales de arranque del servidor de DHCP externo y del servidor PXE en un sistema operativo Linux.

Este laboratorio ahora está completo. A continuación, exploraremos los servicios de VPN de capa 2 del gateway de servicios de NSX Edge.

 

Configuración de L2VPN


En este módulo, utilizaremos las capacidades L2VPN del gateway de NSX Edge para extender el límite de Capa 2 entre dos clústeres de vSphere distintos. Para demostrar un caso de uso basado en esta capacidad, implementaremos un servidor NSX Edge L2VPN en el clúster RegionA01-MGMT01 y un Cliente NSX Edge L2VPN en el clúster RegionA01-COMP01 y, finalmente, probaremos el estado del túnel para verificar que la configuración haya sido exitosa.

 


 

Apertura de Google Chrome y navegación a vSphere Web Client

 

  1. Abra el navegador Google Chrome desde el escritorio (si aún no se encuentra abierto).

 

 

Navegación hasta la sección Networking  Security de vSphere Web Client

 

  1. Haga clic en Networking & Security.

 

 

Creación de un gateway de NSX Edge para L2VPN-Server

 

Para crear el servicio del servidor L2VPN-Server, primero debemos implementar un gateway de NSX Edge donde se ejecute ese servicio.  

  1. Haga clic en NSX Edges.
  2. Haga clic en el signo más (+) de color verde para crear una instancia nueva de NSX Edge.

 

 

Configuración de un gateway nuevo de NSX Edge: L2VPN-Server

 

Se mostrará el asistente de la nueva instancia de NSX Edge, y la primera sección será "Name and Description".  Ingrese los siguientes valores que corresponden a los siguientes números.  Deje los otros campos en blanco o deje los valores predeterminados.

  1. Ingrese L2VPN-Server en el campo Name.
  2. Haga clic en Next.

 

 

Configuración del gateway nuevo de NSX Edge: L2VPN-Server

 

En la sección Settings del asistente de la nueva instancia de NSX Edge, realice las siguientes acciones:

  1. Ingrese "VMware1!VMware1!" en los campos Password y Confirm Password, y deje los valores predeterminados en las otras opciones.
  2. Haga clic en el botón Next para continuar.

 

 

Adición del nuevo dispositivo NSX Edge: L2VPN-Server

 

En la ventana emergente "Add NSX Edge Appliance", ingrese los siguientes valores:

  1. Haga clic en el signo más (+) de color verde para crear un dispositivo NSX Edge.
  2. En Cluster/Resource Pool, seleccione RegionA01-MGMT01.
  3. En Datastore, seleccione RegionA01-ISCSI01-MGMT01.
  4. En Host, seleccione esx-05a.corp.local.
  5. En Folder, seleccione Discovered virtual machine.
  6. Haga clic en el botón OK para enviar esta configuración.

 

 

Regreso a la configuración de la implementación del nuevo gateway de NSX Edge: L2VPN-Server

 

  1. Haga clic en el botón Next para continuar.

 

 

Adición de la interfaz

 

  1. Haga clic en el signo más (+) de color verde para agregar la interfaz.

 

 

Adición de una interfaz nueva al gateway de NSX Edge: L2VPN-Server

 

  1. Ingrese L2VPNServer-Uplink en el campo Name .
  2. Seleccione Uplink en el campo Type.
  3. Haga clic en el signo más de color verde para ver los campos de una dirección IP principal nueva.
  4. Ingrese 192.168.5.5 como la dirección IP.
  5. Ingrese 29 en el campo Subnet Prefix Length. Asegúrese de que la longitud ingresada sea 29 y NO 24.
  6. Haga clic en el enlace Select junto al cuadro de texto Connected To.

 

 

Conexión de la nueva interfaz a un switch lógico

 

Verifique que la pestaña Logical Switch esté seleccionada y realice las siguientes acciones:

  1. Haga clic en el botón de selección del switch lógico denominado Transit_Network_01 - 5006.
  2. Haga clic en el botón OK para continuar.

 

 

Confirmación de la configuración de la nueva interfaz: L2VPN-Server

 

Antes de continuar, revise los siguientes ajustes:

  1. Haga clic en OK para finalizar la configuración.

 

 

Continuación de la configuración del nuevo gateway de NSX Edge: L2VPN-Server

 

  1. Haga clic en el botón Next para continuar.

 

 

Configuración de los ajustes predeterminados del gateway de la nueva instancia de NSX Edge: L2VPN-Server

 

  1. Ingrese 192.168.5.1 en el campo Gateway IP.
  2. Haga clic en Next.

 

 

Configuración de firewall y de HA para el nuevo gateway de NSX Edge: L2VPN-Server

 

En las secciones Firewall y HA, configure las siguientes propiedades:

  1. Haga clic en la casilla de verificación de Configure Firewall default policy.
  2. Marque Accept en el campo Default Traffic Policy.
  3. Haga clic en el botón Next para continuar.

 

 

Revisión de la implementación y finalización del nuevo gateway de NSX Edge: L2VPN-Server

 

  1. Haga clic en el botón Finish para empezar a implementar la instancia de NSX Edge.

 

 

Preparación de la instancia de NSX Edge en L2VPN-Server para conexiones L2VPN

Antes de configurar la instancia de NSX Edge que se implementó recientemente para conexiones L2VPN, deben realizarse algunos pasos previos, incluidos los siguientes:

1.) Adición de una interfaz tipo trunk al gateway de NSX Edge de L2VPN-Server.

2.) Adición de una subinterfaz al gateway de NSX Edge de L2VPN-Server.

3.) Configuración del enrutamiento dinámico (OSPF) del gateway de NSX Edge de L2VPN-Server.

 

 

Configuración de la instancia de NSX Edge de L2VPN-Server

 

  1. Haga doble clic en el gateway de NSX Edge que creamos anteriormente, denominado "L2VPN-Server" para acceder a la sección de configuración.

 

 

Adición de la interfaz Trunk

 

  1. Haga clic en la pestaña Manage.
  2. Haga clic en la pestaña Settings.
  3. Haga clic en Interfaces.
  4. Seleccione la vNIC con el número "1" y el nombre "vnic1", como se muestra en la captura de pantalla.
  5. Haga clic en el ícono de lápiz para abrir el asistente Edit NSX Edge Interface.

 

 

Configuración de la interfaz de enlace troncal

 

En la ventana Edit NSX Edge Interface que aparece, ingrese los siguientes valores:

  1. Ingrese L2VPN-Server-Trunk en el campo Name.
  2. Configure el campo Type en Trunk.
  3. Haga clic en el enlace Select junto al cuadro de texto Connected To.

 

 

Selección del port group troncal

 

En la ventana emergente "Connect NSX Edge to a Network", realice las siguientes acciones:

  1. Haga clic en Distributed Portgroup.
  2. Haga clic en el botón de selección Trunk-Network-regionA0-vDS-MGMT.
  3. Haga clic en el botón OK.

 

 

Adición de una subinterfaz a la interfaz Trunk

 

  1. Haga clic en el signo más (+) de color verde debajo de la etiqueta Sub Interfaces.

 

 

Configuración de la subinterfaz

 

En la ventana emergente "Add Sub Interface", ingrese los siguientes valores:

  1. En el campo Name, ingrese L2VPN-Server-SubInterface.
  2. En el campo Tunnel Id, ingrese 1.
  3. En el campo Backing Type, ingrese Network.
  4. Haga clic en el signo más (+) de color verde.
  5. Ingrese 172.16.10.1 en el campo Primary IP Address.
  6. Ingrese 24 en el campo Subnet Prefix Length.
  7. Haga clic en el enlace Select junto al cuadro de texto Connected To.

 

 

Conexión de la subinterfaz a un switch lógico

 

  1. Asegúrese de que se haya seleccionado la pestaña Logical Switch.
  2. Haga clic en el botón de selección junto a Web_Tier_Logical_Switch (5000).
  3. Haga clic en el botón OK.

 

 

Confirmación de la configuración de la nueva interfaz de NSX Edge

 

  1. En la ventana emergente Edit NSX Edge Interface, deje el resto de las propiedades en los valores predeterminados y haga clic en el botón OK.

 

 

Configuración del ID del enrutador para esta instancia de NSX Edge

 

A continuación, configuraremos el enrutamiento dinámico en este gateway de NSX Edge.

  1. Haga clic en la subpestaña Routing del gateway de NSX Edge.
  2. Haga clic en Global Configuration, en la barra de navegación de la izquierda.
  3. Haga clic en el botón Edit, en la sección Dynamic Routing Configuration.Aparecerá una ventana emergente donde podemos configurar el ID del enrutador.

 

 

Ingreso de L2VPNServer-Uplink

 

  1. Haga clic en OK.

 

 

Opción Publish Changes para configurar el ID del enrutador

 

  1. Haga clic en el botón Publish Changes para enviar el cambio en la configuración de este gateway de NSX Edge.

 

 

Configuración de OSPF en la instancia de NSX Edge de L2VPN-Server

 

Quédese en la subpestaña Routing.

  1. Haga clic en el elemento OSPF, en la barra de navegación de la izquierda.
  2. Haga clic en el signo más (+) de color verde, en la sección Area to Interface Mapping.

 

 

Configuración de la opción Area to Interface Mapping

 

En la ventana emergente "New Area to Interface Mapping", configure los siguientes valores:

  1. En el campo vNIC, seleccione L2VPNServer-Uplink (si aun no se seleccionó).
  2. En el campo Area, ingrese 0.  
  3. Haga clic en el botón OK.

 

 

Habilitación de OSPF en la instancia de NSX Edge de L2VPN-Server

 

  1. Para habilitar la configuración de OSPF en este gateway de NSX Edge, haga clic en el botón Edit, en la sección OSPF Configuration.
  2. Marque la casilla de verificación junto a Enable OSPF.
  3. Haga clic en el botón OK.

 

 

Opción Publish Changes para la instancia de NSX Edge de L2VPN-Server

 

  1. Haga clic en el botón Publish Changes para enviar el cambio en la configuración de este gateway de NSX Edge.

 

 

Habilitación de la redistribución de las rutas de OSPF

 

  1. Haga clic en Route Redistribution.
  2. Haga clic en el botón Edit de la sección Route Redistribution Status.
  3. Marque la casilla junto a OSPF para habilitar OSPF.
  4. Haga clic en el botón OK.

 

 

Adición de una entrada en la tabla de redistribución de rutas

 

  1. A continuación, haga clic en el signo más (+) de color verde , en la sección Route Redistribution table.

 

 

Configuración de entradas en la tabla Route Redistribution

 

En la ventana emergente "New Redistribution criteria", configure los siguientes valores:

  1. Haga clic en la casilla de verificación Connected y deje el resto sin marcar.
  2. Haga clic en el botón OK.

 

 

Publicación de cambios

 

  1. Haga clic en el botón Publish Changes.

Una vez finalizado esto, se llevaron a cabo todos los prerrequisitos para continuar con la configuración de los servicios de VPN de C2 en este gateway de NSX Edge.

 

 

Configuración de los servicios de L2VPN en la instancia de NSX Edge de L2VPN-Server

Ahora que la dirección 172.16.10.1 ya pertenece al gateway de NSX Edge de L2VPN-Server y distribuye rutas dinámicamente mediante el OSPF, comenzaremos a configurar los servicios de L2VPN en este gateway de NSX Edge para que la instancia de NSX Edge actúe como "servidor" en L2VPN.

 

 

Navegación hasta la sección de servicios de VPN en la instancia de NSX Edge de L2VPN-Server

 

  1. Haga clic en la pestaña VPN.
  2. Haga clic en L2 VPN, que se encuentra en la barra de navegación de la izquierda.
  3. Haga clic en el botón Change como se muestra en la captura de pantalla.

 

 

Configuración de los ajustes del servidor VPN de C2

 

En la configuración del servidor VPN de C2, ingrese los siguientes valores:

  1. En el campo Encryption Algorithm, ingrese ECDHE-RSA-AES256-GCM-SHA384
  2. Haga clic en el botón OK para continuar.

 

 

Adición de una nueva configuración de sitio

 

  1. Haga clic en el signo más (+) de color verde.

 

 

Configuración de un nuevo sitio de L2VPN

 

  1. Marque la casilla de verificación junto a Enable Peer Site.
  2. Ingrese HOLSite1 en el campo Name.
  3. En el campo User ID, ingrese siteadmin.
  4. En el campo Password, ingrese VMware1!.
  5. Haga clic en el enlace Select Sub Interfaces.

 

 

Selección de una subinterfaz

 

En la ventana emergente "Select Object", realice las siguientes acciones:

  1. Seleccione el objeto L2VPN-Server-SubInterface.
  2. Haga clic en la flecha hacia la derecha para moverlo a la lista Selected Objects.
  3. Haga clic en el botón OK.

 

 

Confirmación de la configuración del nuevo sitio

 

  1. Haga clic en el botón OK para continuar.

 

 

Opción Publish Changes para la configuración de L2VPN

 

  1. Antes de hacer clic en el botón Publish Changes, asegúrese de que la opción L2VPN Mode esté configurada en "Server".
  2. Haga clic en el botón Publish Changes para enviar la configuración de L2VPN-Server.

 

 

Habilitación del servicio del servidor L2VPN

 

  1. Por último, para habilitar el servicio del servidor L2VPN, haga clic en el botón Enable, como se muestra en la captura de pantalla.  
  2. Haga clic en Publish Changes.

 

Aquí finaliza la configuración del servidor L2VPN. A continuación, implementaremos un nuevo gateway de NSX Edge que actuará como cliente L2VPN.

 

 

Implementación del gateway de NSX Edge de L2VPN-Client

Ahora que el lado del servidor de L2VPN está configurado, implementaremos otro gateway de NSX Edge que actuará como cliente L2VPN. Antes de implementar el cliente L2VPN del gateway de NSX Edge, debemos configurar los port groups distribuidos de Uplink y de Trunk en el switch virtual distribuido.

 

 

Configuración de los port groups Uplink y Trunk

 

  1. Regrese a la pantalla de inicio de vSphere Web Client y seleccione Networking.

 

 

Configuración del port group distribuido de Uplink

 

  1. Seleccione RegionA01-vDS-COMP.
  2. Haga clic en Create a new port group.

 

 

Nombre del nuevo port group distribuido

 

  1. Ingrese Uplink-RegionA01-vDS-COMP.
  2. Haga clic en Next.

 

 

Configuración

 

  1. Deje la configuración predeterminada y haga clic en Next.

 

 

Sección Ready to Complete

 

  1. Haga clic en Finish.

Repita los pasos anteriores para configurar Trunk-Network-RegionA01-vDS-COMP.

 

 

Finalización de la configuración de vDS

 

  1. Al finalizar, deberíamos ver los port groups distribuidos que se crearon recientemente.
  2. Haga clic en Home.

 

 

Regreso a la opción Networking  Security

 

  1. Haga clic en Networking & Security.

 

 

Opción NSX Edges

 

  1. Seleccione NSX Edges.

 

 

Creación de un nuevo gateway de NSX Edge para que se convierta en L2VPN-Client

 

  1. Haga clic en el signo más (+) de color verde para abrir el asistente New NSX Edge.

 

 

Nombre y descripción de L2VPN-Client para la instancia de NSX Edge

 

Para las opciones que se presentan, seleccione los siguientes valores:

  1. En el campo Install Type, ingrese Edge Services Gateway.
  2. En el campo Name, ingrese L2VPN-Client.
  3. Asegúrese de que la casilla junto a "Deploy NSX Edge" esté marcada y haga clic en el botón Next para continuar.

 

 

Configuración de NSX Edge

 

En la sección Settings, establezca los siguientes valores:

  1. En el campo User name, ingrese admin.
  2. En los campos Password y confirm password, ingrese VMware1!VMware1!.
  3. Haga clic en el botón Next para continuar.

 

 

Configuración de la ubicación de NSX Edge

 

En la ventana emergente "Add NSX Edge Appliance", configure los siguientes valores:

  1. Haga clic en el signo más (+) de color verde para crear un dispositivo NSX Edge.
  2. En el campo Cluster/Resource Pool, ingrese RegionA01-COMP02.
  3. En el campo Datastore, ingrese RegionA01-ISCSI01-COMP01.
  4. En el campo Host, ingrese esx-03a.corp.local.
  5. En el campo Folder, ingrese Discovered virtual machine.
  6. Haga clic en el botón OK para enviar esta configuración de ubicación de la máquina virtual de la instancia de NSX Edge.

 

 

Confirmación de la implementación de NSX Edge

 

  1. Corrobore que la configuración sea la misma que se muestra en esta captura de pantalla y haga clic en el botón Next para continuar.

 

 

Configuración de interfaces para la instancia de NSX Edge de L2VPN-Client

 

  1. En la sección Configure interfaces del asistente, haga clic en el signo más (+) de color verde.

 

 

Adición de una nueva interfaz

 

En los parámetros de esta interfaz, ingrese los siguientes valores:

  1. En el campo Name, ingrese L2VPN-Client-Uplink.
  2. En el campo Type, ingrese Uplink.
  3. Haga clic en el signo más (+) de color verde para agregar una dirección IP nueva.
  4. Ingrese 192.168.200.5 en la columna Primary IP Address.
  5. Ingrese 24 en el campo Subnet Prefix Length.
  6. Haga clic en el enlace Select , junto al cuadro de diálogo "Connected To", para abrir la lista de redes y elegir a cuál se conectará esta interfaz.

 

 

Conexión de la interfaz al port group distribuido

 

En la ventana emergente "Connect NSX Edge to a Network", realice las siguientes acciones:

  1. Haga clic en la pestaña Distributed Portgroup.
  2. Haga clic en el botón de selección Uplink-RegionA01-vDS-COMP.
  3. Haga clic en el botón OK para continuar.

 

 

Confirmación de la configuración de la interfaz

 

  1. Haga clic en OK para confirmar la interfaz nueva.

 

 

Haga clic en Next.

 

  1. Haga clic en Next.

 

 

Configuración del gateway predeterminado

 

En la sección Default Gateway Settings, establezca los siguientes valores:

  1. En el campo Gateway IP, introduzca 192.168.200.1.
  2. Haga clic en el botón Next para continuar.

 

 

Configuración de la sección Firewall and HA

 

En la sección "Firewall and HA", realice las siguientes acciones:

  1. Marque la casilla junto a Configure Firewall default policy.
  2. Haga clic en el botón de selección Accept junto a Default Traffic Policy.
  3. Haga clic en el botón Next para continuar.

 

 

Confirmación de la nueva configuración de NSX Edge

 

  1. Haga clic en el botón Finish para enviar la nueva configuración del gateway de NSX Edge y comenzar el proceso de implementación.

 

 

Configuración del gateway de NSX Edge de L2VPN-Client

 

  1. Haga doble clic en la entrada de la instancia de NSX Edge que se creó recientemente para ingresar al área de administración.

 

 

Adición de la interfaz Trunk

 

Al igual que con el gateway de NSX Edge de L2VPN-Server, se debe agregar una interfaz de tipo Trun en esta instancia de NSX Edge. Para abrir la ventana de configuración de la interfaz nueva, realice las siguientes acciones:

  1. Haga clic en la pestaña Manage.
  2. Haga clic en la subpestaña Settings.
  3. Haga clic en Interfaces , en la barra de navegación de la izquierda.
  4. Seleccione la interfaz denominada vnic1 en la columna Name.
  5. Haga clic en el ícono de lápiz para abrir el área de configuración de esta interfaz.

 

 

Configuración de la interfaz de enlace troncal

 

En la ventana emergente Edit NSX Edge Interface, ingrese los siguientes valores:

  1. En el campo Name, ingrese L2PVN-Client-Trunk.
  2. En el campo Type, ingrese Trunk.
  3. Haga clic en el enlace Select , junto al cuadro de diálogo "Connected To", para abrir la lista de redes de vSphere disponibles para añadir esta interfaz.

 

 

Conexión al port group distribuido de la red de enlace troncal

 

  1. Haga clic en la pestaña Distributed Portgroup.
  2. Haga clic en el botón de selección Trunk-Network-RegionA01-vDS-COMP.
  3. Haga clic en el botón OK.

 

 

Configuración de la subinterfaz

 

En la configuración de la subinterfaz, ingrese los siguientes valores:

  1. Haga clic en el signo más (+) de color verde para agregar una subinterfaz.
  2. En el campo Name, ingrese L2VPN-Client-SubInterface.
  3. En el campo Tunnel ID, ingrese 1.
  4. En el campo Backing Type, ingrese Network.
  5. Haga clic en el signo más (+) de color verde.
  6. Ingrese 172.16.10.1 en la columna Primary IP Address.
  7. Ingrese 24 en el campo Subnet Prefix Length.
  8. Haga clic en el enlace Select , junto al cuadro de diálogo "Network," para abrir la lista de redes disponibles para añadir esta subinterfaz.

 

 

Conexión de la subinterfaz a la red de la VM

 

  1. Seleccione la pestaña Distributed Portgroup.
  2. Haga clic en el botón de selección VM-RegionA01-vDS-COMP .
  3. Haga clic en el botón OK.

 

 

Confirmación de la configuración de la subinterfaz

 

  1. Verifique que la configuración de la subinterfaz sea similar a la que se muestra en esta captura de pantalla y haga clic en el botón OK para continuar.

 

 

Confirmación de la adición de la interfaz Trunk y de la subinterfaz

 

  1. Compruebe que la configuración de la interfaz Trunk sea similar a la que se muestra en la captura de pantalla y haga clic en el botón OK para continuar con la configuración del servicio de cliente L2VPN.

 

 

Configuración de los servicios de cliente L2VPN

 

Para empezar a configurar el cliente L2VPN, realice las siguientes acciones:

  1. Haga clic en la subpestaña VPN.
  2. Haga clic en L2 VPN, que se encuentra en la barra de navegación de la izquierda.
  3. Haga clic en el botón de selección Client, en la sección L2VPN Mode.
  4. Haga clic en el botón Change , en la sección Global Configuration Details.

 

 

Configuración del cliente L2VPN

 

Para la configuración del cliente, ingrese los siguientes valores:

  1. En el campo Server Address, ingrese 192.168.5.5.
  2. En el campo Encryption algorithm, ingrese ECDHE-RSA-AES256-GCM-SHA384.
  3. En los detalles de los usuarios, ingrese siteadmin en el campo User ID.
  4. Ingrese VMware1! en los campos Password y Confirm Password.
  5. Haga clic en el enlace Select Sub Interfaces para abrir la lista de subinterfaces disponibles para añadir al servicio.

 

 

Adición de la subinterfaz

 

Para añadir una subinterfaz nueva al servicio L2VPN, realice las siguientes acciones:

  1. Seleccione el objeto L2VPN-Client-SubInterface de la lista de objetos disponibles en la izquierda.
  2. Haga clic en la flecha hacia la derecha para mover el objeto a la lista Selected Objects.
  3. Haga clic en el botón OK.

 

 

Confirmación de la configuración del cliente L2VPN

 

  1. Verifique que la configuración sea similar a la que se muestra en la captura de pantalla y haga clic en el botón OK para continuar.

 

 

Habilitación del servicio de cliente L2VPN

 

  1. Para habilitar el servicio de cliente L2VPN, haga clic en el botón Enable como se muestra en la captura de pantalla.

 

 

Publicación de cambios

 

  1. Haga clic en Publish Changes.

 

 

Obtener estado de L2VPN

 

  1. Una vez habilitado, haga clic en el botón Fetch Status. Es posible que deba hacer clic en esta opción un par de veces luego de que se habilite el servicio.
  2. Expanda Tunnel Status.
  3. Verifique que el campo Status esté configurado en Up como se puede ver en la captura de pantalla a continuación.

Felicitaciones. Hemos configurado con éxito el servicio de L2VPN de NSX.

Aquí finaliza la lección sobre la configuración de los servicios L2VPN del gateway de servicios de NSX Edge.

 

Conclusión del módulo 4


Aquí finaliza el módulo 4: Gateway de servicios de NSX Edge. Esperamos que haya disfrutado el laboratorio. Cuando finalice, no olvide completar la encuesta.

Si desea obtener más información sobre la implementación de NSX, revise el centro de documentación de NSX 6.2 mediante la URL que se muestra a continuación:

Si le queda tiempo, eche un vistazo a la lista de los otros módulos que forman parte de este laboratorio y el tiempo estimado necesario para realizar cada uno.

Haga clic en el botón "Table of Contents" para ir rápidamente a un módulo en el manual.

Lista de los módulos del laboratorio:

Capitanes del laboratorio:


Módulo 5: Conexión de una red física a una red virtual (60 minutos)

Conexión nativa


Con NSX, se obtienen capacidades de conexión de L2 en software en el kernel que les permiten a las organizaciones conectar sin problemas cargas de trabajo tradicionales y VLANs legadas a redes virtualizadas mediante VXLAN. La conexión de L2 se utiliza mucho en entornos existentes para simplificar la introducción de redes lógicas y en otros escenarios que incluyen sistemas físicos que requieren conectividad de L2 a máquinas virtuales.

Los enrutadores lógicos pueden proporcionar conexión de L2 desde el espacio de redes lógicas dentro de NSX hacia la red física basada en VLAN. Esto permite la creación de una conexión de L2 mediante un componente conocido como L2 Bridge entre un switch lógico y una VLAN, lo que permite la migración de cargas de trabajo virtuales a dispositivos físicos sin afectar las direcciones IP. Una red lógica puede aprovechar un gateway físico de L3 y acceder a redes físicas existentes y recursos de seguridad mediante una conexión entre el dominio de broadcast del switch lógico y el dominio de broadcast de la VLAN. En NSX-V 6.2, esta función se ha mejorado debido a que los switches lógicos conectados pueden conectarse a enrutadores lógicos distribuidos. Esta operación no se permitía en versiones anteriores de NSX.

Mediante este módulo, se le guiará a través de la configuración de una instancia de conexión de L2 entre una VLAN tradicional y un switch lógico de acceso de NSX.


 

Introducción

 

En la imagen que se presenta arriba, se muestran las mejoras en la conexión de L2 de NSX 6.2:

Ahora, configurará la conexión de L2 de NSX con la nueva configuración soportada en la versión NSX 6.2.

 

 

Instrucciones especiales para los comandos CLI

 

En muchos de los módulos, deberá ingresar comandos de interfaz de línea de comando (CLI).  Existen dos maneras de enviar comandos CLI al laboratorio.

En primer lugar, para enviar un comando CLI a la consola del laboratorio, siga los siguientes pasos:

  1. Resalte el comando CLI en el manual y use Control+C para copiarlo al portapapeles.
  2. Haga clic en el elemento del menú de la consola SEND TEXT.
  3. Presione Control+V para pegarlo del portapapeles a la ventana.
  4. Haga clic en el botón SEND.

En segundo lugar, en el escritorio del entorno, encontrará un archivo de texto (README.txt) para que pueda copiar y pegar con facilidad contraseñas o comandos complejos en las herramientas asociadas (CMD, Putty, consola, etc.). Algunos teclados no tienen ciertos caracteres.  Este archivo de texto también se incluye para algunos teclados que no incluyan esos caracteres.

El archivo de texto se llama README.txt y se encuentra en el escritorio.  

 

 

Acceso a vSphere Web Client

 

 

 

Inicio de sesión en vSphere Web Client

 

Para iniciar sesión en vSphere Web Client, use la autenticación de sesión de Windows.

  1. Haga clic en Use Windows session authentication. De esta manera, se completarán automáticamente las credenciales de administrator@corp.local/VMware1!
  2. Haga clic en Login.

 

 

Verificación de la configuración inicial

 

Ahora, puede verificar la configuración inicial. En el entorno, hay un port group en el clúster Management & Edge denominado "Bridged-Net-RegionA0-vDS-MGMT". En este momento, las VMs del servidor web, denominadas "web-01a" y "web-02a", están conectadas al switch lógico Web-Tier-01 y están aisladas de la interconexión de red. En la imagen, se muestra la topología.

 

 

Acceso a la configuración de redes de vSphere

 

  1. Haga clic en el ícono Home.
  2. Haga clic en "Networking" para acceder a la interfaz de configuración de redes de vSphere.

 

 

Apertura del port group

 

  1. Expanda el árbol de objetos ("vcsa-01a.corp.local", "RegionA01", "RegionA01-vDS-MGMT").
  2. Haga clic en el port group "Bridged-Net-RegionA0-vDS-MGMT", que se encuentra en la lista.

 

 

Edición de la configuración de la interconexión de red

 

  1. Haga clic en Actions.
  2. Haga clic en Edit Settings.

Nota: Configuraremos la VLAN para que permita la presentación de la Red-puenteada al enrutador distribuido para una conexión de L2.

 

 

Edición de la configuración de la VLAN

 

  1. Haga clic en VLAN, que se encuentra en la lista Edit Settings.
  2. Haga clic en la lista desplegable del campo VLAN type.
  3. Seleccione VLAN.

 

 

Adición de la VLAN 101 a la interconexión de red

 

  1. Ingrese "101" en el campo VLAN ID.
  2. Haga clic en OK.

 

 

Verificación del ID de la VLAN

 

  1. Haga clic en la pestaña "Summary".
  2. Compruebe que el port group esté configurado en la VLANID101 física.

 

 

Migración de Web-01a al clúster RegionA01-MGMT01

 

  1. Haga clic en el ícono Home.
  2. Seleccione VMs and Templates.

 

 

Migración de Web-01a

 

  1. Expanda el menú desplegable vcsa-01a.corp.local de vCenter.
  2. Expanda el menú desplegable RegionA01 del centro de datos.
  3. Haga clic con el botón derecho en web-01a.corp.local.
  4. Haga clic en Migrate.

 

 

Opción Select the migration type

 

  1. Seleccione Change both compute resources and storage.
  2. Seleccione la opción Select compute resource first.
  3. Haga clic en Next.

 

 

Opción Select Compute Resource

 

  1. Expanda el menú desplegable vcsa-01a.corp.local de vCenter.
  2. Expanda el menú desplegable RegionA01 del centro de datos.
  3. Expanda el clúster RegionA01-MGMT01.
  4. Seleccione esx-04a.corp.local.
  5. Haga clic en Next.

 

 

Selección del almacenamiento

 

  1. Seleccione el almacenamiento RegionA01-ISCSI01-MGMT01.
  2. Haga clic en Next.

 

 

Selección de la red de destino

 

  1. Haga clic en el menú desplegable de Destination Network.
  2. Seleccione Browse.

 

 

Selección de Bridged-Net-RegionA0-vDS-MGMT

 

  1. Seleccione la red Bridged-Net-RegionA0-vDS-MGMT.
  2. Haga clic en OK.

 

 

Clic en Next para la opción Destination Network

 

  1. Haga clic en Next.

 

 

Clic en Next para la opción vMotion Priority

 

  1. Haga clic en Next.

 

 

Clic en Finish

 

  1. Haga clic en Finish.

 

 

Vista de las VMs conectadas

 

  1. Haga clic en el botón para volver atrás para ir a Networking.

 

 

Vista de objetos relacionados con la red-puenteada

 

  1. Seleccione el port group Bridged-Net-RegionA0-vDS-MGMT.
  2. Seleccione la pestaña Related Objects.
  3. Seleccione la vista Virtual Machines.

Nota: Ahora, debería ver web-01a.corp.local.

4.    Haga clic en web-01a.corp.local.

 

 

Apertura de la consola de la VM

 

  1. Haga clic en la pestaña Summary y verifique que la dirección IP de la VM sea 172.16.10.11.
  2. Haga clic en Launch Remote Console.

 

 

Verificación de que la VM está aislada

 

Una vez que la ventana de la consola esté abierta, haga clic en el medio de la pantalla y presione cualquier tecla para desactivar el protector de pantalla.

  1. Inicie sesión como "root", con la contraseña "VMware1!" (ingrese el nombre de usuario y la contraseña sin comillas).
  2. Ingrese "ping -c 3 172.16.10.1"     (Recuerde usar la herramienta SEND TEXT).
ping -c 3 172.16.10.1

Espere hasta que el ping haga una pausa: ya verificó que la VM está aislada, ya que no hay otros dispositivos en VLAN 101 y todavía no se configuró la conexión de L2.

 

 

Migración de Web_Tier_Logical_Switch al enrutador lógico distribuido

 

  1. Haga clic en el ícono Home.
  2. Seleccione Network & Security.

 

 

Eliminación de Web-Tier del gateway perimetral

 

  1. Haga clic en NSX Edges.
  2. Haga doble clic en edge-3 Perimeter-Gateway-01.

 

 

Eliminación de la interfaz de Web-Tier

 

  1. Haga clic en Manage.
  2. Haga clic en Settings.
  3. Seleccione Interfaces.
  4. Resalte Web_Tier.
  5. Haga clic en Delete para eliminar el switch lógico del gateway perimetral.

 

 

Haga clic en OK.

 

 

 

Regreso a Edges

 

  1. Haga clic en el botón Networking & Security para regresar a Edges.

 

 

Selección del enrutador distribuido

 

  1. Haga doble clic en Distributed-Router-01.

 

 

Adición del switch lógico Web-Tier

 

  1. Haga clic en Manage.
  2. Haga clic en Settings.
  3. Seleccione Interfaces en el menú de la izquierda.
  4. Haga clic en el signo más de color verde para agregar el switch lógico Web-Tier.

 

 

Adición de Web-Tier

 

  1. Ingrese "Web-Tier" en el campo Name.
  2. Haga clic en Select junto al campo Connected To.

 

 

Selección del switch lógico Web-Tier

 

  1. Seleccione Web_Tier_Logical_Switch.
  2. Haga clic en OK.

 

 

Adición de la dirección IP principal

 

  1. Haga clic en el signo más de color verde para configurar la dirección IP principal de la subred.
  2. Ingrese "172.16.10.1" en el campo Primary IP Address.
  3. Ingrese "24" en el campo Subnet Prefix Length.
  4. Haga clic en OK.

 

 

Confirmación de la adición del switch lógico al enrutador lógico distribuido

 

Verifique que el switch lógico Web-Tier se haya implementado correctamente.

 

 

Configuración de la conexión de L2 de NSX

 

Ahora, habilitaremos la conexión de L2 de NSX entre VLAN 101 y el switch lógico Web-Tier-01 para que la VM "web-01a" pueda comunicarse con el resto de la red. Con NSX-V 6.2, ahora se puede tener una conexión de L2 y un enrutador lógico distribuido conectados al mismo switch lógico. Esto representa una mejora importante, ya que simplifica la integración de NSX en entornos existentes y la migración de redes legadas a redes virtuales.

 

 

Creación de una conexión de L2 nueva

 

  1. Haga clic en la pestaña "Bridging".
  2. Compruebe que no haya instancias de conexión configuradas en la lista y haga clic en el signo más de color verde para agregar una.

 

 

Asignación de un nombre para la conexión

 

  1. Ingrese "Bridge-01" en el campo "Name".
  2. Luego, haga clic en el ícono para seleccionar el switch lógico al que se conectará la conexión.

 

 

Selección del switch lógico

 

  1. Seleccione Web_Tier_Logical_Switch.
  2. Haga clic en OK.

 

 

Apertura del cuadro de selección de la opción Distributed Port Group

 

 

 

Selección del port group distribuido

 

  1. Seleccione el port group distribuido Bridged-Net-RegionA0-vDA-MGMT.
  2. Haga clic en OK.

 

 

Confirmación de la configuración de la conexión

 

 

 

Publicación de cambios

 

 

 

Verificación de la habilitación del enrutamiento

 

Verifique la configuración publicada. Observará el mensaje "Routing Enabled", que quiere decir que esta conexión de C2 también está conectada a un enrutador lógico distribuido. Esto es una mejora de NSX-V 6.2.

 

 

Verificación de la conexión de L2

Se configuró la conexión de L2 de NSX. Ahora, verificará la conectividad de L2 entre la VM "web-01a", conectada a VLAN 101, y las máquinas conectadas al switch lógico "Web-Tier-01".

 

 

Verificación de la conectividad hacia el default gateway

 

  1. Abra la pestaña de la consola web-01a desde la barra de tareas y pruebe hacer ping al default gateway nuevamente.
  2. Ingrese ping -c 3 172.16.10.1
ping -c 3 172.16.10.1

El ping ha tenido éxito: usted verificó la conectividad entre una VM conectada a VLAN 101 y el enrutador lógico distribuido, que es el default gateway de la red, mediante una conexión de L2 proporcionada por NSX.

Nota: Durante esta prueba, puede experimentar pings "duplicados" (respuestas que aparecen como DUP). Esto se debe a la naturaleza del entorno del laboratorio y no ocurrirá en una situación real.

 

 

Limpieza del módulo de conexión de L2

Si desea continuar con los otros módulos de este laboratorio, asegúrese de seguir los pasos a continuación para deshabilitar la conexión de L2, ya que la configuración de ejemplo realizada en este entorno específico podría entrar en conflicto con otras secciones, como la VPN de L2.

 

 

Regreso a Web Client

 

  1. Haga clic en la pestaña vSphere Web Client del navegador.

 

 

Acceso a la página de configuración de NSX

 

  1. Haga clic en el ícono Home.
  2. Haga clic en "Networking & Security" en el menú.

 

 

Apertura de la página de configuración del enrutador lógico

 

  1. En el menú Navigator , que se encuentra a la izquierda, haga clic en "NSX Edges" y espere hasta que se cargue la lista de instancias de NSX Edge.
  2. Haga doble clic en "edge-6", denominado "Distributed-Router-01", para acceder a la página de configuración.

 

 

Eliminación de la instancia de conexión

 

  1. Si todavía no está seleccionada, haga clic en la pestaña "Manage".
  2. Luego, si todavía no está seleccionada, haga clic en la pestaña "Bridging".

Nota: Deberíamos ver solo la instancia "Bridge-01" que creó anteriormente y que se encuentra resaltada de manera predeterminada.

3.     Haga clic en el ícono Delete para eliminarla.

 

 

Publicación de cambios

 

  1. Haga clic en el botón "Publish Changes" para confirmar la configuración.

 

 

Verificación de la limpieza de la conexión

 

Verifique que la instancia de conexión se haya eliminado.

 

 

Migración de Web-01a de nuevo al clúster RegionA01-COMP01

 

  1. Haga clic en el ícono Home.
  2. Seleccione VMs and Templates.

 

 

Migración de Web-01a

 

  1. Expanda el menú desplegable vcsa-01a.corp.local de vCenter.
  2. Expanda en el menú desplegable el centro de datos RegionA01.
  3. Haga clic con el botón secundario en web-01a.corp.local.
  4. Haga clic en Migrate.

 

 

Opción Select the migration type

 

  1. Seleccione Change both compute resources and storage.
  2. Seleccione la opción Select compute resource first.
  3. Haga clic en Next.

 

 

Opción Select Compute Resource

 

  1. Expanda en el menú desplegable el vCenter vcsa-01a.corp.local.
  2. Expanda en el menú desplegable el centro de datos RegionA01.
  3. Expanda el clúster RegionA01-COMP01.
  4. Seleccione esx-01a.corp.local.
  5. Haga clic en Next.

 

 

Opción Select Storage

 

  1. Seleccione el almacenamiento RegionA01-ISCSI01-COMP01.
  2. Haga clic en Next.

 

 

Selección de la red de destino

 

  1. Haga clic en el menú desplegable de Destination Network.
  2. Seleccione vxm-dvs-43-virtualwire-1-sid-5000-Web_Tier_Logical_Switch.

 

 

Clic en Next para la opción vMotion Priority

 

 

 

Clic en Finish

 

 

 

Conclusión

Felicitaciones. Ha completado correctamente el módulo Conexión de L2 de NSX.  En este módulo, configuramos y probamos la conexión de un port group tradicional basado en VLAN a un switch lógico de VXLAN de NSX.

 

Introducción a VTEP de hardware con Arista


Las siguientes secciones del módulo sobre VTEP de hardware son de naturaleza informativa. Si desea ir directamente al laboratorio, avance al Módulo 6: Firewall distribuido.

En muchos centros de datos, algunas cargas de trabajo no se han virtualizado o no pueden virtualizarse. Para integrarlas a la arquitectura del centro de datos definido por software (Software Defined Data Center, SDDC), NSX ofrece la capacidad de extender las redes virtuales a la red física mediante gateways de capa 2 o capa 3. En esta sección, nos centraremos en la función de gateway de capa 2 y en cómo puede lograrse de manera nativa en un host que ejecuta NSX y mediante un dispositivo de hardware de terceros, como un switch de red Arista que puede controlarse por medio de NSX. Con NSX como plataforma, los socios pueden integrar su solución y optimizar las funcionalidades existentes. NSX también ofrece una infraestructura ágil de overlay para entornos de nubes públicas y privadas.

Como plataforma, NSX funciona de manera eficiente mediante el uso de una capa de "hipervisor de red" distribuida en todos los hosts. Sin embargo, en algunos casos, ciertos hosts de la red no están virtualizados y no pueden implementar los componentes de NSX de manera nativa. NSX ofrece la capacidad de establecer una conexión o una ruta con redes externas no virtualizadas. Con un enfoque en la solución de conexión, le mostraremos cómo un gateway de capa 2 puede extender una red lógica de capa 2 a una red física de capa 2, y también le mostraremos algunos casos de uso del gateway de capa 2.


 

Información de copyright de la guía de diseño de Arista y créditos de la demostración sin conexión

 

En esta sección del módulo del laboratorio, se utilizó y modificó material de la Guía de diseño Arista sobre NSX para vSphere con Arista CloudVision, versión 1.0, agosto de 2015.

También queremos agradecerle de manera especial a Francois Tallet, Sr. Technical Product Manager de la unidad de negocios Networking and Security de WMware, EE. UU., por guiarnos en su laboratorio para realizar la demostración sin conexión para la siguiente sección del módulo.

 

 

Revisión del caso de uso

 

NSX funciona de manera eficaz mediante el uso de una capa de "hipervisor de red", distribuida en todos los hosts. Sin embargo, en algunos casos, ciertos hosts de la red no están virtualizados y no pueden implementar los componentes de NSX de manera nativa. Por lo tanto, con NSX, se ofrece la capacidad de establecer una conexión o una ruta hacia redes externas no virtualizadas. Este módulo se enfoca específicamente en la solución de conexión, en la que un gateway de capa 2 puede extender una red lógica de capa 2 a una red física de capa 2.

La funcionalidad principal que se logra con un gateway de capa 2 es la siguiente:

Asignación de un switch lógico de NSX a una VLAN. La configuración y administración del gateway de capa 2 están integradas en NSX.

El tráfico que se recibe en el switch lógico de NSX se desencapsula y reenvía mediante un túnel al puerto/VLAN correspondiente en la red física. De manera similar, el tráfico VLAN en la dirección contraria se encapsula y reenvía adecuadamente en el switch lógico de NSX.

NSX incluye de manera nativa una versión del software de la funcionalidad del gateway de capa 2, con un plano de datos implementado por completo en el kernel del hipervisor, para un máximo rendimiento. Además de dicha funcionalidad, NSX como plataforma permite la integración de componentes de terceros para alcanzar la funcionalidad del gateway de capa 2 en hardware.

 

 

Descripción general de los componentes

 

Existen diversos componentes involucrados en la conexión del gateway de hardware a NSX. Estos están representados en la figura anterior.

El controlador de NSX se encarga de manejar la interacción con el gateway de hardware. Con este fin, se establece una conexión entre el controlador de NSX y un software dedicado llamado Hardware Switch Controller (HSC). HSC puede integrarse en el gateway de hardware o puede ejecutarse como un dispositivo independiente. HSC puede controlar uno o varios gateways de hardware. Por ejemplo, Arista aprovecha la plataforma CloudVision como un HSC, que actúa como único punto de integración a NSX para todos los gateways de hardware de Arista. El HSC ejecuta un servidor de la base de datos abierta de vSwitch (Open vSwitch Database, OVSDB), y el controlador de NSX se conecta como un cliente OVSDB. OVSDB es el protocolo de administración de la base de datos abierta de vSwitch detallado en RFC 7047. Es un proyecto de código fuente abierto que proporciona la capacidad de administrar una base de datos de manera remota.

El controlador de NSX empujará la asociación configurada por el administrador entre el switch lógico y el switch físico/puerto/VLAN y el gateway de hardware mediante HSC. El controlador de NSX también anunciará una lista de nodos de servicios de replicación (Replication Service Nodes, RSN) que el gateway de hardware aprovechará para reenviar tráfico de broadcast, unknown unicast y multicast (Broadcast, Unknown unicast, and Multicast, BUM). El controlador de NSX le anunciará a HSC la lista de hipervisores VTEP relevantes para los switches lógicos configurados en el gateway de hardware. El controlador de NSX también le anunciará a HSC la asociación entre las direcciones MAC de las VMs en la red virtual y el VTEP mediante el cual se las puede alcanzar.

Nota: Tenga en cuenta que pueden haber varios controladores de NSX es una implementación de NSX, a fin de proporcionar redundancia y escalabilidad horizontal. De hecho, las tareas que lleva a cabo el controlador de NSX son las mismas que las de todos los controladores de NSX en la red. HSC se conectará con todos los controladores.

 

 

Integración de NSX con Arista CloudVision y gateway de hardware

 

La plataforma de Arista CloudVision proporciona visibilidad de toda la red y un único punto de integración a NSX.

La base de CloudVision es un servicio de infraestructura que comparte y agrega el estado funcional de los switches físicos que ejecutan el software Arista EOS para proporcionar visibilidad de red y coordinación centralizada. El estado de cada nodo físico de EOS que participa se registra en CloudVision mediante la misma arquitectura de publicación/suscripción de la base de datos del sistema (System database, SysDB) de EOS. Por ejemplo, el servicio de control de VXLAN (VXLAN Control Service, VCS) de CloudVision añade el estado de VXLAN de toda la red para la integración y organización con VMware NSX: CloudVision también proporciona gateways de hardware de capa 2 redundantes para NSX con grupos de agregación de enlaces de chasis múltiple (Multi-Chassis Link Aggregation Group, MLAG) con funcionalidad VXLAN. En los switches de Arista, MLAG con VXLAN proporciona un reenvío activo-activo sin bloqueo y redundancia con conmutación de recuperación sin pérdida de datos en caso de fallas en los switches. Los switches de la parte superior del rack (Top of the Rack, ToR) y de Arista CloudVision también ejecutan internamente el VCS que cada VTEP de hardware utiliza para compartir estados entre ellos a fin de establecer túneles de VXLAN sin la necesidad de un plano de control multicast.

 

 

Punto de integración operacional

 

Cuando esté en funcionamiento, Arista CloudVision se registrará con el controlador de NSX y utilizará el protocolo OVSDB para sincronizar la información de topología, terminales MAC a VXLAN y enlaces de ID de VXLAN con NSX. CloudVision programará correctamente los pares de switches de Arista o MLAG, como el gateway de hardware de NSX. Esta integración del gateway de hardware permite la sincronización casi instantánea de estados entre terminales de túnel de VXLAN físicos y virtuales durante cualquier cambio de red o modificación de la carga de trabajo.

NSX Manager de VMware acerca al usuario toda la plataforma de virtualización de redes de NSX. Los usuarios también pueden administrar y operar cargas de trabajo que se extienden a sistemas virtuales y no virtualizados de NSX, como un panel de visualización único.

La plataforma de Arista CloudVision proporciona un conjunto de servicios que simplifica el monitoreo, la administración y la integración de NSX con switches de Arista en el centro de datos virtualizado. Los usuarios pueden aprovisionar los VTEP de Arista como nodos del gateway mediante la UI de NSX Manager. Esto acelera la entrega de servicios y ayuda a los negocios a satisfacer mejor sus necesidades de una manera programática y automatizada en todos los centros de datos.

La implementación de la plataforma de Arista CloudVision requiere dos pasos:

  1. Habilitación del servicio de control de VXLAN (VCS) en los switches ToR de Arista y en CloudVision.
  2. Habilitación del servicio de Hardware Switch Controller (HSC) en CloudVision.

 

 

Simulación interactiva del laboratorio: VTEP de hardware con Arista


Esta sección del laboratorio se presenta como una simulación interactiva. Esta simulación le permitirá navegar por la interfaz del software como si estuviera interactuando con un entorno en vivo.

  1. Haga clic aquí para abrir la simulación interactiva. Se abrirá en una nueva ventana o pestaña del navegador.
  2. Cuando finalice, haga clic en el enlace "Return to the lab", en la esquina superior derecha de la ventana del navegador, o cierre la ventana para continuar con este laboratorio.

Consideraciones de diseño de la conexión


Existe una diferencia importante entre los gateways de software y de hardware:

Esto tiene un efecto en la redundancia y en el alcance de la capa 2 en la red. En esta sección del módulo, se desarrollan las consideraciones de diseño en el momento de implementar una arquitectura de gateway de hardware con las consideraciones mencionadas anteriormente.  Se hará referencia a las mejores prácticas, pero se recomienda que los usuarios que planean implementar gateways de hardware con NSX consulten a un profesional de VMware acerca de las consideraciones específicas para su propio entorno.


 

Información de copyright de la guía de diseño de Arista

 

En esta sección del módulo del laboratorio, se utilizó y modificó material de la Guía de diseño Arista sobre NSX para vSphere con Arista CloudVision, versión 1.0, agosto de 2015.  

 

 

Alta disponibilidad con MLAG

 

Arista soporta MLAG para el procesamiento y VXLAN juntos en su gran variedad de switches, lo que proporciona redundancia de gateways de hardware de Capa 2 para NSX. MLAG con VXLAN en los switches de Arista proporciona reenvío y redundancia activo-activo sin bloqueo, con conmutación de recuperación sin pérdida de datos en caso de fallas en los switches. Arista CloudVision extrae los detalles del grupo de agregación de enlaces de chasis múltiple (Multi-Chassis Link Aggregation Group, MLAG) y presenta un par de switches de MLAG como un VTEP único.

El hecho de que varios gateways de hardware puedan estar activos al mismo tiempo también influye en el diseño de red. Por lo general, se extiende un switch lógico a una VLAN para proporcionar conectividad a algún servicio que no pueda virtualizarse. Este servicio suele ser redundante, es decir que su implementación física se extiende en diferentes racks en el centro de datos.

 

 

Impacto en el alcance de la capa 2 en la red

 

Si observa el lado izquierdo de la figura anterior, algunas máquinas virtuales están conectadas a un switch lógico y acceden a servidores físicos mediante un gateway de software (gateway de servicios de NSX Edge). Todo el tráfico desde el switch lógico a VLAN 10, donde se ubican los servidores físicos, debe atravesar una sola instancia de conexión. Esto quiere decir que VLAN 10 debe extenderse entre los racks para alcanzar todos los servidores físicos necesarios.

En los últimos años, la tendencia en redes del centro de datos ha sido intentar reducir tanto como sea posible la expansión de la conectividad de capa 2 para minimizar los riesgos y las limitaciones asociados. En la figura que se encuentra a la derecha de la figura anterior, se muestra de qué manera se puede lograr esto si se aprovecha un gateway de hardware activo. En este diseño alternativo, cada rack que aloja servidores físicos está configurado con un gateway de hardware. Gracias a este modelo, no hace falta extender la conectividad de capa 2 entre los racks, ya que los switches lógicos pueden extenderse directamente al gateway de hardware relevante cuando alcancen los servidores físicos.

Nota: Las VLAN definidas en los racks tienen importancia local (el ejemplo muestra que el switch lógico se extiende a VLAN 10 en un rack y a VLAN 20 en el otro).

 

 

Componentes de NSX y conectividad de los clústeres

 

Las funciones y la operación de los componentes de NSX se definen en la Guía de diseño para la virtualización de redes de VMware NSX for vSphere, versión 3.0 (disponible en https://communities.vmware.com/docs/DOC-27683). Se recomienda especialmente que el lector lea el documento para seguir el fundamento sobre la conectividad a una red física. Las funciones y la organización de los componentes de NSX se asignan al clúster correspondiente. La Guía de diseño para la virtualización de redes de VMware NSX for vSphere requiere la organización de los componentes de NSX, el procesamiento y la administración del entorno virtualizado.

En la Guía de diseño para la virtualización de redes de VMware NSX for vSphere, se recomienda la construcción de tres tipos de clústeres de vSphere diferentes. En la figura anterior, se muestra un ejemplo de los componentes lógicos del diseño de clústeres para la ubicación del rack físico.

Nota: Para configuraciones aun más pequeñas, se puede utilizar un solo rack para proporcionar conectividad al clúster de administración y NSX Edge. El concepto clave es que la configuración de clústeres de NSX Edge se localiza en un par ToR para reducir la expansión de los requisitos de capa 2. Esto también ayuda a localizar la configuración del enrutamiento de salida en un par de switches ToR. La localización de los componentes de NSX Edge también permite flexibilidad en la selección del hardware (CPU, memoria y tarjeta de interfaz de red [Network Interface Card, NIC]) y las funciones adecuadas conforme a funcionalidades centradas en la red, como firewall, NetFlow, NAT y enrutamiento de ECMP.

 

 

Switches de Arista y enrutamiento de NSX

El gateway de NSX Edge proporciona enrutamiento basado en ECMP, lo que permite hasta ocho VMs que presentan tráfico bidireccional de 8 vías que se reenvía desde el dominio lógico de NSX al core del centro de datos o a Internet. Esto representa hasta 80 Gbps (interfaces 8 x 10 GE) de tráfico que puede ofrecerse desde el dominio virtual de NSX a la red externa en ambas direcciones. Es escalable por cliente; por lo tanto, la cantidad de ancho de banda es elástica según se expandan o contraigan las cargas de trabajo según demanda o la modalidad multicliente. Los requisitos de configuración para proporcionar compatibilidad con el gateway de ECMP de NSX Edge para el enrutamiento norte-sur son los siguientes:

 

 

Diseño de enlaces ascendentes del VDS con host de ESXi en el clúster de NSX Edge

 

El rack de NSX Edge tiene diversos requisitos de conectividad de tráfico. En primer lugar, proporciona conectividad para el tráfico este-oeste al dominio de VXLAN mediante VTEP. En segundo lugar, proporciona una función centralizada para usuarios/tráfico externos que accedan a las cargas de trabajo en el dominio de NSX mediante port groups dedicados basados en VLAN. Esta última conectividad se logra mediante el establecimiento de adyacencias de enrutamiento con dispositivos de próximo salto de capa 3. En la figura de arriba, se muestran dos tipos de conectividad de enlaces ascendentes desde un host que contiene una VM con ECMP de NSX Edge.

 

 

Emparejamiento de ECMP de NSX Edge y diseño de VLAN

 

Una vez que se determina el modo de agrupamiento de enlaces ascendentes, lo asesoraremos sobre la configuración de VLAN y su mapeo a un enlace ascendente y sobre el emparejamiento con switches de Arista. La primera decisión que se debe tomar es cuántos enlaces ascendentes lógicos deberían implementarse en cada instancia de NSX Edge. La decisión de diseño recomendada es mapear siempre el número de enlaces ascendentes lógicos al número de enlaces ascendentes virtuales distribuidos (Distributed Virtual Uplinks, dvUplinks) del VDS definido en la VM de NSX Edge que está disponible en servidores ESXi que alojan las VMs de NSX Edge. Esto quiere decir que siempre se debe mapear una VLAN (port group) a un dvUplink del VDS, que luego se mapea a un enlace físico en el host ESXi que se conecta con el switch de Arista. Una VM de NSX Edge forma una relación paralela de enrutamiento con el switch de Arista.

En el ejemplo anterior, las VM con ECMP de NSX Edge (E1-E8) se implementan en hosts ESXi con dos enlaces ascendentes físicos conectados a los switches ToR de Arista. Por lo tanto, se recomienda implementar dos enlaces ascendentes lógicos en cada instancia de NSX Edge. Debido a que un enlace ascendente lógico de NSX Edge está conectado a un port group basado en VLAN, es necesario utilizar dos segmentos de VLAN externos para conectar los enrutadores físicos y establecer adyacencias de protocolo de enrutamiento. Como se muestra en la figura anterior, cada nodo con ECMP atraviesa su VLAN externa respectiva hacia un enrutador de Arista exactamente. Cada VLAN externa está definida solo en un enlace ascendente de ESXi (en la figura a continuación, la VLAN10 externa está habilitada en el enlace ascendente hacia R1, mientras que la VLAN20 externa, en el enlace ascendente hacia R2). Se hace de esta manera para que, en circunstancias normales, los dos enlaces ascendentes de ESXi puedan utilizarse simultáneamente para enviar y recibir tráfico norte-sur, incluso sin la necesidad de crear un canal de puerto entre el host ESXi y los dispositivos ToR.

Además, con este modelo, una falla física de una NIC de ESXi se correspondería con una falla en el enlace ascendente lógico de la instancia de NSX Edge que se ejecuta dentro de ese host, y dicha instancia continuaría con el envío y la recepción de tráfico mediante el aprovechamiento del segundo enlace ascendente lógico (la segunda interfaz física con NIC de ESXi).

 

 

Recomendaciones sobre el temporizador del protocolo de enrutamiento de NSX Edge

 

El enrutador lógico de NSX Edge permite un enrutamiento tanto dinámico como estático. Se recomienda utilizar un protocolo de enrutamiento dinámico para conectarse con los switches de Arista a fin de reducir la sobrecarga de definir rutas estáticas cada vez que se define la red lógica. Los enrutadores lógicos de NSX Edge admiten protocolos de enrutamiento OSPF y BGP. La configuración del modo ECMP de NSX Edge admite la reducción del temporizador de conexión/espera del protocolo de enrutamiento para mejorar la recuperación de fallas del tráfico en caso de que se produzca una falla en los nodos o los enlaces. En la tabla anterior, se muestra el temporizador mínimo recomendado para OSPF y BGP.

 

 

Ventajas de la arquitectura de NSX con la infraestructura de Arista

Con NSX, los usuarios pueden desarrollar servicios lógicos para redes y seguridad sin la necesidad de hacer cambios en la configuración de la infraestructura física. En este caso, una vez que se configuren los switches de Arista para proporcionar conectividad IP y se aprovisione la configuración de enrutamiento, podemos comenzar a implementar servicios nuevos con NSX.

 

 

Conectividad de capa lógica

 

Las opciones de conectividad de capa lógica para servidores en la infraestructura física les permite a los servidores estar en diferentes subredes y, al mismo tiempo, una red de overlay permite que las VM se ubiquen en la misma subred y se encuentren adyacentes a la capa 2. Esto proporciona, esencialmente, conectividad independiente de la topología y movilidad más allá de la restricción de la topología estructurada impuesta por las redes físicas.

 

 

Enrutamiento a la infraestructura física

 

Para hacer un enrutamiento de la red lógica a la red física, NSX puede aprender e intercambiar rutas con la infraestructura física para alcanzar recursos, como un servidor de base de datos o una aplicación no virtualizada, que podrían estar ubicados en una subred o red física diferente.

Como se muestra en la figura anterior, NSX proporciona una arquitectura de enrutamiento de escalabilidad horizontal con el uso de ECMP entre el enrutador distribuido de NSX y las instancias de enrutamiento de NSX Edge. Las instancias de NSX Edge pueden conectarse con los enrutadores físicos mediante protocolos de enrutamiento dinámico (OSPF o BGP) y proporcionar ancho de banda escalable. En el caso de la infraestructura de los switches de Arista, la conexión de enrutamiento puede ser cualquier ToR de Arista.

 

 

Operación y escalabilidad simplificadas

 

La solución de CloudVision de Arista simplifica la integración de entornos físicos y virtuales. CloudVision aprovecha una base de datos que abarca toda la red, la cual recopila el estado de toda la red física y presenta una única interfaz abierta para VMware NSX, a fin de lograr la integración con la red física. Con CloudVision como punto de integración, se pueden separar los detalles de la red física de los orquestadores de nube y los controladores de overlay. Además, CloudVision simplifica el esfuerzo de integración de NSX, ya que NSX solo necesita integrarse con CloudVision. Esto les permite a los clientes evitar la complicación de certificar NSX con las numerosas combinaciones de versiones de hardware y software. A su vez, CloudVision proporciona el estado agregado de la red física para alcanzar la sincronización física a virtual más eficaz. Este enfoque proporciona una estrategia más simple y escalable para la integración de controladores a la red física.

Nota: CloudVision se basa en API abiertas, incluida la base de datos abierta de vSphere (Open vSphere Database, OVSDB) y JavaScript Object Notation (JSON), que proporcionan una estrategia basada en estándares para esta integración.

 

 

Visibilidad de la red lógica y física con Arista VM Tracer

La función VM Tracer de Arista para NSX está integrada de manera nativa en Arista EOS. Automatiza el descubrimiento de la infraestructura virtual conectada de forma directa y optimiza el aprovisionamiento dinámico de VLAN relacionadas y perfiles de puertos en la red. Los switches de Arista utilizan las API de VMware vCenter y NSX Manager para recopilar información de aprovisionamiento. Luego, VM Tracer combina esta información con los datos de la base de datos de los switches para proporcionar un mapeo claro y conciso de la red virtual a la física. Los clientes pueden realizar un seguimiento en tiempo real de los switches lógicos y las VM de una única CLI en cualquier switch de Arista de la red.

 

 

Seguridad con firewall distribuido

 

NSX habilita de manera predeterminada el firewall distribuido en cada VM en el nivel de la tarjeta de interfaz de la red virtual (Virtual Network Interface Card, vNIC). El firewall está siempre en la ruta del tráfico que se origina en la VM y que se dirige a esta. La ventaja clave es que puede reducir los problemas de seguridad del tráfico este-oeste y no en una ubicación centralizada. Entre las ventajas adicionales del firewall distribuido, se incluyen las siguientes:

 

 

Escalabilidad flexible de las aplicaciones con balanceador de carga virtualizado

 

La escalabilidad elástica de las cargas de trabajo de las aplicaciones es uno de requisitos más importantes en los centros de datos actuales. La escalabilidad de las aplicaciones con un balanceador de carga físico puede ser insuficiente debido a la naturaleza dinámica de la TI de autoservicio y de las cargas de trabajo del estilo de desarrollo y operaciones (Development and Operations, DevOps). La funcionalidad de balanceo de carga que se admite nativamente en el gateway de servicios de NSX Edge cumple la mayoría de los requisitos prácticos de las implementaciones. Puede implementarse de manera programática conforme a los requisitos de las aplicaciones con la escalabilidad y las funciones adecuadas. El nivel de compatibilidad de la escalabilidad y las aplicaciones determina si el balanceador de carga se puede configurar con servicios de capa 4 o capa 7. Con respecto a la topología, el balanceador de carga puede implementarse en línea o en modo de un solo brazo (one-arm). El modo se selecciona según los requisitos específicos de las aplicaciones. Sin embargo, el diseño de un solo brazo ofrece amplia flexibilidad, ya que puede implementarse cerca del segmento de las aplicaciones y puede automatizarse con la implementación de las aplicaciones.

En la figura de arriba, se muestra el poder de un balanceador de carga basado en software en el que múltiples instancias del balanceador de carga funcionan en múltiples aplicaciones o segmentos. Cada instancia del balanceador de carga es un dispositivo NSX Edge que puede definirse dinámicamente mediante una API, según sea necesario, y puede implementarse en un modo de alta disponibilidad. El balanceador de carga también puede implementarse en un modo en línea (in-line) que puede brindar servicio a todo el dominio lógico. El balanceador de carga en línea puede escalar mediante la habilitación de una instancia de NSX Edge de múltiples niveles por aplicación. De esta manera, cada aplicación es un dominio dedicado para el cual el perímetro de nivel 1 es un gateway para una aplicación y el perímetro de nivel 2 puede ser un gateway con ECMP para proporcionar el ancho de banda norte-sur escalable.

 

 

Conclusión

La solución de virtualización de redes de VMware permite abordar los desafíos actuales con infraestructura de computación y redes físicas, y aporta flexibilidad, agilidad y escalabilidad a las redes lógicas basadas en la VXLAN. Además de la capacidad para crear redes lógicas según demanda usando  VXLAN, el gateway de NSX Edge permite que los usuarios implementen numerosos servicios de redes lógicas, como firewall, DHCP o NAT. Esto es posible debido a su capacidad para separar la red virtual de la red física y, luego, reproducir las propiedades y los servicios en el entorno virtual.

En conclusión, Arista y VMware ofrecen la primera y mejor solución escalable del sector para la virtualización de redes en el centro de datos definido por software. Los proveedores de nube, las empresas y los clientes web podrán acelerar de manera drástica los servicios empresariales y reducir la complejidad operacional y los costos. Todo esto se encuentra ahora disponible en una solución programática y completamente automatizada del centro de datos definido por software (Software Defined Data Center, SDDC) que conecta la infraestructura virtual y física.

 

Conclusión del módulo 5


En este módulo, demostramos la capacidad de NSX para conectar redes físicas basadas en VLAN con redes lógicas VXLAN.  Configuramos una conexión dentro del enrutador lógico distribuido de NSX para mapear una VLAN a una VXLAN.  También realizamos una migración de una VM desde un switch lógico a un dvPortGroup basado en una VLAN para simular la comunicación entre VM. Finalmente, hicimos un recorrido de una demostración fuera de línea de la integración de NSX con VTEP de hardware de Arista para mostrar la extensión de un gateway de Capa 2 en un switch de hardware.


 

Ha finalizado el módulo 5.

Felicitaciones por completar el módulo 5.

Si desea obtener más información sobre la implementación de NSX, revise el centro de documentación de NSX 6.2 mediante la URL que se muestra a continuación:

Continúe con cualquiera de los siguientes módulos que sea de su interés:

Lista de los módulos del laboratorio:

Directores del laboratorio:

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Módulo 6: Firewall distribuido (45 minutos)

Introducción al firewall distribuido


Firewall distribuido (DFW, Distributed Firewall) de NSX. Uno de los componentes de NSX, es un firewall distribuido que se habilita como módulo kernel.  El firewall distribuido se instala en cada host de vSphere para habilitar la funcionalidad. El firewall distribuido se encuentra cerca de la velocidad line-rate (tasa de transmisión del enlace) y posee la confiabilidad y disponibilidad de la plataforma host de vSphere. Además, cuenta con reconocimiento de identidad de usuario y herramientas de monitoreo de actividad únicas.

En este módulo, exploraremos de qué manera el firewall distribuido ayuda a proteger una aplicación de 3 niveles.  También mostraremos el proceso de creación de reglas de firewall basado en grupos de seguridad e identidad, en lugar de reglas basadas en direcciones IP.  Mediante las reglas basadas en direcciones IP, se imponen fuertes límites en la movilidad de las VM y se reduce la flexibilidad a la hora de utilizar recursos comunes (pool).

Este módulo se basa en cuatro VMs huésped que componen una aplicación común de 3 niveles.  El nivel web posee dos servidores web (web-01a y web-02a). El nivel web se comunica con una VM denominada app-01a que ejecuta un software de aplicación, lo que funciona como el nivel de aplicación.  A su vez, la VM del nivel de aplicación se comunica con una VM denominada db-01a que ejecuta MySQL en el nivel de la base de datos.  El firewall DFW de NSX aplica las reglas de acceso entre los niveles.  

A continuación, se presenta la descripción general de este módulo:

Funcionalidad básica de firewall distribuido

Comience el módulo desde el escritorio.  El escritorio es el jumpbox del centro de control en el entorno virtual.  Desde este escritorio, podrá acceder a vCenter Server Appliance que se implementó en el centro de datos virtual.

Nota especial: En el escritorio, encontrará un archivo con el nombre README.txt.  Allí se muestran los comandos CLI que necesita para realizar los ejercicios del laboratorio.  Si no puede escribirlos, puede copiarlos y pegarlos en las sesiones de Putty.  Si ve un número con "comillas francesas - {1}", eso significa que debe buscar ese comando CLI para ese módulo en el archivo de texto.


Confirmación de la habilitación del firewall distribuido (DFW)


Utilice vCenter Web Client para verificar que el DFW esté instalado y habilitado.


 

Inicio del navegador Google Chrome

 

  1. Haga clic en el ícono del navegador Chrome, que se encuentra en la barra de tareas o en el escritorio de la consola principal.

 

 

Confirmación de la habilitación del firewall distribuido (DFW)

 

Primero, explorará el firewall distribuido de NSX.

Si aún no inició sesión en vSphere Web Client, haga lo siguiente:

Haga clic en el ícono de la barra de tareas de Google Chrome. Debe tener vSphere Web Client como página de inicio.

  1. Para iniciar sesión, marque la casilla "Use Windows Session Authentication".

 

 

Contraiga el panel de tareas derecho para tener más espacio en la pantalla.

 

 

 

Explore el nuevo firewall distribuido de NSX

 

  1. Haga clic en Networking & Security.

 

 

Apertura de la opción Installation

 

  1. Primero haga clic en Installation.
  2. Haga clic en la pestaña Host Preparation.  En la tabla, se mostrarán los clústeres del centro de datos virtual.

 

Configuración de reglas para el acceso a aplicaciones web


Ahora, configurará el acceso del firewall distribuido a una aplicación de 3 niveles (Customer-DB-app).  La aplicación tiene dos servidores web: un servidor de base de datos y uno de aplicación.  Además, posee un balanceador de carga que respalda los dos servidores web.


 

Prueba de conectividad de VM a VM de Customer-DB-app mediante Putty

 

A continuación, probará la comunicación y el acceso entre los segmentos de red y las VM huésped que componen la aplicación de 3 niveles. La primera prueba consistirá en abrir una consola para web-01a.corp.local y enviar pings a los otros miembros.

  1. Haga clic en el acceso directo de PuTTY, en la barra de tareas del escritorio.

 

 

Apertura de una sesión de SSH en web-01a

 

  1. Encuentre y haga clic en web-01a.corp.local en la lista Saved Sessions.
  2. Haga clic en Open para conectar la sesión SSH a web-01a.

 

 

Envío de pings desde web-01a hacia otros miembros de 3 niveles

 

  1. Primero, mostrará que web-01a puede enviar pings a web-02a si se introduce lo siguiente:
ping -c 2 172.16.10.12
  1. Ahora haga ping en app-01a.
  2. Haga una prueba de ping en db-01a.
ping -c 2 172.16.20.11
ping -c 2 172.16.30.11 

(Nota: Puede ver paquetes DUP! al final de una línea de ping.  Esto se debe a la naturaleza del entorno del laboratorio virtual que utiliza virtualización anidada y modo promiscuo en los enrutadores virtuales. Esto no ocurrirá en un entorno de producción).

No cierre la ventana, solo minimícela para utilizarla luego.

 

 

Demonstración de la aplicación Customer DB con un navegador web

 

Mediante la utilización de un navegador, accederá a la aplicación de 3 niveles para mostrar el funcionamiento entre las 3 partes.  

  1. Abra una pestaña nueva del navegador.
  2. Haga clic en el marcador "Customer DB-app".

 

 

Demonstración de la aplicación Customer DB con un navegador web (continuación)

 

Debe visualizar datos que pasaron desde el nivel web a la VM app-01a y, finalmente, consultaron a la VM db-01a.

A.  Observe la conexión HTTPS al nivel web.

B.  Observe la conexión TCP en el puerto 8443 con el nivel de aplicación.

C.  Observe la conexión TCP en el puerto 3306 con el nivel de base de datos.

Observe el servidor web real que responde. Observe que este servidor puede ser diferente del que se muestra.

 

 

Cambio en la política de firewall predeterminada de Allow a Block

 

En esta sección, cambiará la regla predeterminada Allow a Block y mostrará la interrupción de la comunicación con la aplicación Customer-DB de 3 niveles.  Una vez que realizó esto, creará nuevas reglas de acceso para volver a establecer la comunicación de manera segura.

  1. Haga clic en la pestaña del navegador para vSphere Web Client.
  2. Seleccione Firewall en el área izquierda.  

Se mostrará Default Section Layer 3 en la sección General.

 

 

Examinación de las reglas predeterminadas

 

  1. Expanda la sección con el "marcador de lista desplegable".  

Tenga en cuenta que las reglas poseen marcas de verificación de color verde.  Esto significa que se habilitó una regla.  Las reglas se crean de forma habitual con los campos source, destination y service.  Los servicios son una combinación de protocolos y puertos.  

La última Default Rule es un permitir de cualquiera a cualquiera (any-to any-allow).

 

 

Análisis de la última Default Rule

 

Desplácese hacia la derecha, donde encontrará las opciones de Action para Default Rule. Para ello, coloque el cursor en el campo de Action:Allow.  Luego de esto, aparecerá un lápiz que le permitirá ver las opciones para este campo.

  1. Coloque el curso sobre el lápiz y haga clic.

 

 

Cambio en Action de Allow a Block en la última Default Rule

 

  1. En Action, seleccione la opción Block.
  2. Haga clic en Save.

 

 

Publicación de cambios en Default Rule

 

Se mostrará una barra de color verde mediante la que se le solicitará que elija Publish Changes, Revert Changes o Save Changes.  Con Publish, los cambios se enviarán al firewall distribuido (Distributed Firewall, DFW).  Con Revert, se cancelan las ediciones.  Con Save Changes, los cambios se guardan para publicarse luego.

  1. Seleccione Publish Change para guardar la regla de bloqueo.

 

 

Reapertura de una sesión de PuTTY

 

  1. En la barra de tareas, haga clic en la sesión de PuTTY para web-01a.

 

 

Verificación de que el cambio de regla bloquea la comunicación

 

Para probar la regla de bloqueo con las sesiones del navegador y de PuTTY previas, haga lo siguiente:

PuTTy: en unos momentos, si abre PuTTY, se mostrará que la sesión ya no está activa debido a la regla predeterminada que ahora bloquea todo, incluida la sesión de SSH.  Vuelva a minimizar la consola.

 

 

Verificación de la denegación del acceso con el navegador

 

  1. Haga clic en la pestaña webapp.corp.local.
  2. Haga clic en el botón Refresh.

El sitio se detendrá en algunos segundos para demostrar que se ha bloqueado el acceso mediante la opción Block de Default Rule.

 

Creación de grupos de seguridad


Ahora, crearemos grupos de seguridad. Los grupos de seguridad nos permiten crear contenedores reutilizables de VM a los que podemos aplicarles las políticas. La membresía en los grupos puede establecerse de manera estática o dinámica.


 

Creación de grupos de seguridad de 3 niveles

 

  1. Haga clic en la pestaña del navegador de vSphere Web Client.
  2. Luego, haga clic en Service Composer.

Gracias a Service Composer, se define un modelo nuevo para el consumo de servicios de redes y seguridad en entornos virtuales y de nube. Las políticas son ejecutables mediante la simple visualización y el consumo de servicios que se integran o mejoran mediante soluciones de terceros. Estas mismas políticas pueden hacerse repetibles mediante las capacidades de exportación e importación, que podrían facilitar la implementación y recuperación de un entorno cuando surge un problema. Uno de esos objetos para uso repetible es un grupo de seguridad.

 

 

Adición de un grupo de seguridad

 

  1. Seleccione Security Groups.Nota: Pueden haber grupos de seguridad existentes para utilizarse en otro módulo del laboratorio.
  2. Para agregar un grupo de seguridad nuevo, haga clic en el ícono New Security Group.

 

 

Grupo de seguridad nuevo: web

 

  1. A este primer grupo, póngale el nombre Web-tier.
  2. Haga clic en la sección "Select objects to include".

 

 

Opción Select objects to include

 

  1. Despliegue Object Types y seleccione Virtual Machines.
  2. Para usar el filtro, escriba web en la ventana de búsqueda.
  3. Seleccione web-01acorp.local.
  4. Haga clic en la flecha que señala hacia la derecha para enviar la VM a la ventana Selected Objects.
  5. Realice los mismos pasos para web-02a.corp.local.
  6. Haga clic en Finish.

Nota: Como acceso directo, puede hacer doble clic en las VM ubicadas en la parte izquierda y se moverán hacia la derecha en un solo paso.

 

 

Verificación de la creación de grupos de seguridad

 

Ha creado un grupo de seguridad con el nombre Web-tier al que se asignaron 2 VM.

Observe el grupo de seguridad de Web-tier.

Observe el número de VMs que hay en el grupo de seguridad.

 

Creación de reglas de acceso


Cree reglas de acceso de 3 niveles para la aplicación Customer-DB.


 

Creación de reglas de acceso de 3 niveles

 

A continuación, agregará reglas nuevas para permitir el acceso a la VM web y, luego, configurará el acceso entre los niveles.  

  1. En el menú de la izquierda, seleccione Firewall.

 

 

Adición de una nueva sección de reglas para aplicaciones de 3 niveles

 

  1. En el extremo derecho de la fila "Flow Monitoring & Trace Flow Rules-Disabled by Default (Rule1)", haga clic en el ícono Add Section, que tiene forma de carpeta.
  2. Asigne a la sección el nombre "Customer DB-app".
  3. Haga clic en Save.

 

 

Adición de una regla a la nueva sección

 

  1. En la fila de la nueva sección "Customer DB-app", haga clic en el ícono Add rule, que es un signo más de color verde.

 

 

Edición de nuevas reglas

 

  1. Haga clic en el marcador de lista desplegable para abrir la regla.
  2. Mantenga el cursor sobre la esquina superior derecha del campo "Name" hasta que aparezca un ícono con forma de lápiz; luego, haga clic en el lápiz.
  3. Ingrese "EXT to Web" como nombre.
  4. Haga clic en Save.

 

 

Establecimiento del origen y destino de la regla

 

Source:Deje el origen de la regla establecido en cualquier opción.

  1. Mantenga el puntero del mouse sobre el campo Destination y seleccione el ícono de lápiz.

 

 

Establecimiento de los valores del grupo de seguridad

 

Especificación del destino:

  1. Despliegue Object Type y desplácese hacia abajo hasta que encuentre Security Group.
  2. Haga clic en Web-tier.
  3. Haga clic en la flecha superior para mover el objeto hacia la derecha.
  4. Haga clic en OK.

 

 

Configuración de la opción Service

 

  1. Pase el mouse por encima del campo Service y haga clic en el ícono de lápiz.

 

 

Establecimiento del servicio de la regla

 

Vuelva a mantener el puntero sobre el campo Service y haga clic en el ícono de lápiz.  

  1. En el campo de búsqueda, puede buscar coincidencias de patrones de servicios.  Escriba "https" y presione Enter para ver todos los servicios asociados con el nombre https.
  2. Seleccione el servicio HTTPS simple.
  3. Haga clic en la flecha superior.
  4. Nota: Repita los pasos anteriores del 1 al 3 para buscar y agregar SSH.  (Más adelante en el módulo veremos que necesitaremos un SSH).
  5. Haga clic en OK.

 

 

Creación de reglas que permitan el acceso de grupos de seguridad web al switch lógico de la aplicación

 

Ahora, agregará una segunda regla que le permita al grupo de seguridad web acceder al grupo de seguridad de la aplicación mediante el puerto de la aplicación.  

  1. Para empezar, abra el ícono de lápiz.
  2. Esta regla deberá procesarse debajo de la regla anterior; por lo tanto, seleccione Add Below en el cuadro desplegable.

 

 

Ingreso de datos en los campos Name y Source de la segunda regla

 

  1. Como ya hizo antes, mantenga el mouse sobre el campo Name y haga clic en el signo más.  Escriba "Web to App" como nombre.
  2. Seleccione el grupo de seguridad Object Type: Web-tier para el campo Source.

 

 

Configuración del campo Destination

 

  1. Pase el mouse por encima de la columna Destination y haga clic en el ícono de lápiz.

 

 

Ingreso de información en el campo Destination de la segunda regla: elección de una red lógica

 

En la primera regla, usó el grupo de seguridad Web-tier como destino.  Podría aplicar los mismos pasos con las reglas restantes.  Sin embargo, como se ve en el cuadro desplegable, se pueden usar varios objetos de vCenter ya definidos.  Un aspecto importante de vSphere integrado con la seguridad de NSX que permite ahorrar tiempo es que puede usar los objetos actuales del centro de datos virtual para las reglas en lugar de comenzar desde cero.  Aquí, usará un switch lógico de VXLAN como destino. Esto le permite crear una regla que se aplica a cualquier VM adjunta a esta red.

  1. En el cuadro desplegable Object Type, desplácese hacia abajo y haga clic en la opción Logical Switch.
  2. Seleccione App_Tier_Logical_Switch.
  3. Haga clic en la flecha superior para mover el objeto hacia la derecha.
  4. Haga clic en OK.

 

 

Configuración del campo Service

 

  1. Pase el mouse por encima de la columna Service y haga clic en el ícono de lápiz.

 

 

Ingreso de información en el campo Service de la segunda regla: servicio nuevo

 

En la aplicación de 3 niveles, se usa el puerto TCP 8443 entre los niveles web y de aplicaciones.  Creará un servicio nuevo llamado MyApp, que será el servicio permitido.

  1. Haga clic en New Service.
  2. Escriba MyApp como nombre del nuevo servicio.
  3. Seleccione TCP en el campo Protocol.
  4. Escriba 8443 como número de puerto.
  5. Haga clic en OK.

 

 

Haga clic en OK.

 

  1. Haga clic en OK.

 

 

Creación de una tercera regla: permitir el acceso del switch lógico App al switch lógico Database

 

Repetición de los pasos: cree la tercera y última regla, mediante la cual tendrá acceso entre el nivel de aplicaciones y el nivel de base de datos.

  1. Cree la regla final, la que permitirá que el switch lógico de la aplicación se comunique con el switch lógico de la base de datos por medio del servicio predefinido de MySQL.  El servicio viene predefinido; solo deberá buscarlo en lugar de crearlo.
  2. Opción Publish Changes.

 

 

Verificación de que la nueva regla permita la comunicación entre las capas de la aplicación de la base de datos del cliente

 

  1. Abra el navegador y regrese a la pestaña que ya usó para la aplicación web.  
  2. Actualice el navegador de manera que se muestre que se están recibiendo datos mediante la aplicación de la base de datos del cliente.

NOTA: Si no tiene una pestaña ya abierta o cerró la pestaña anterior,  use el favorito "Customer DB-App Direct Connect" en la barra de favoritos.

 

 

Reinicio de la sesión PuTTY para web-01a

 

  1. Haga clic en el ícono Session, en la esquina superior izquierda.
  2. Haga clic en Restart Session.

 

 

Prueba de ping entre niveles

 

Pruebe hacer ping a las VM invitadas con aplicaciones de 3 niveles.

Nota: Recuerde usar la opción SEND TEXT.

  1. Ping w.eb-02a
ping -c 2 172.16.10.12 
  1. Ping app-01a.
ping -c 2 172.16.20.11
  1. Ping db-01a.
ping -c 2 172.16.30.11

Los pings no están permitidos, por lo que ocurrirá una falla, ya que, en sus reglas, no se permite el protocolo de mensajes de control de Internet (Internet Control Message Protocol, ICMP) entre niveles ni entre los miembros de los niveles.  Como no se permite el ICMP entre los niveles, la regla predeterminada bloqueará todo el tráfico restante.

Minimice la sesión de PuTTY a web-01a.

 

 

Topología después de la adición de reglas del firewall distribuido para la aplicación de base de datos del cliente de 3 niveles

 

En este diagrama, se muestra el punto de cumplimiento relativo del firewall en el nivel de la vNIC.  Aunque el DFW es un módulo cargable del kernel (Kernel Loadable Module, KLM) del host de vSphere ESXi, el cumplimiento de las reglas se realiza en la vNIC de la VM huésped.  Esta protección se mueve con la VM durante vMotion para otorgar una protección completa en todo momento, lo que impide la aparición de una "ventana de oportunidad" en la que la VM puede ser atacada.

 

Conclusión del módulo 6


En este módulo, hemos utilizado la función de firewall distribuido (DFW) en NSX para proporcionar políticas de seguridad para una aplicación típica de 3 niveles. Se muestra también de qué manera podemos proporcionar un pequeño conjunto de reglas que pueden aplicarse a un gran número de VM. Podemos utilizar la microsegmentación para asegurar miles de VM en nuestros entornos con muy poca intervención administrativa.


 

Ha finalizado el módulo 6.

Felicitaciones por completar el módulo 6.

Si desea obtener más información sobre la implementación de NSX, revise el centro de documentación de NSX 6.2 mediante la URL que se muestra a continuación:

Continúe con cualquiera de los siguientes módulos que sea de su interés:

Lista de los módulos del laboratorio:

Directores del laboratorio:

 

 

Finalización del laboratorio

 

Para finalizar el laboratorio, haga clic en el botón END.  

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1703-SDC-1-ES

Version: 20161212-050853