Garantizar la funcionalidad adecuada del grupo WSA HA virtual en un entorno VMware

Opciones de descarga

  • PDF     (122.0 KB)
    Visualice con Adobe Reader en una variedad de dispositivos
  • ePub     (87.8 KB)
    Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (75.9 KB)
    Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos
Actualizado:30 de julio de 2015
ID del documento:119188

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Introducción

Este documento describe el proceso que se debe completar para que la función de alta disponibilidad (HA) de Cisco Web Security Appliance (WSA) funcione correctamente en un WSA virtual que se ejecuta en un entorno VMware.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

  • Cisco WSA

  • HTTP

  • Tráfico Multicast

  • Protocolo común de resolución de direcciones (CARP)

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • AsyncOS para la versión 8.5 o posterior de Web

  • VMware ESXi versión 4.0 o posterior

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problema

Un WSA virtual que se configura con uno o más grupos HA siempre tiene el HA en el estado de respaldo, incluso cuando la prioridad es la más alta.

Los registros del sistema muestran constantes inestables, como se muestra en este fragmento de registro:

Tue May 19 08:05:52 2015 Info: Interface Failover Group 94 has changed
 role from Master to Backup (more frequent advertisement received)
Tue May 19 08:05:52 2015 Info: Interface Failover Group 94 is down
Tue May 19 08:06:01 2015 Info: Interface Failover Group 94 is up
Tue May 19 08:06:01 2015 Info: Interface Failover Group 94 has changed
 role from Master to Backup (more frequent advertisement received)
Tue May 19 08:06:01 2015 Info: Interface Failover Group 94 is down
Tue May 19 08:06:10 2015 Info: Interface Failover Group 94 is up
Tue May 19 08:06:10 2015 Info: Interface Failover Group 94 has changed
 role from Master to Backup (more frequent advertisement received)
Tue May 19 08:06:10 2015 Info: Interface Failover Group 94 is down
Tue May 19 08:06:19 2015 Info: Interface Failover Group 94 is up
Tue May 19 08:06:19 2015 Info: Interface Failover Group 94 has changed
 role from Master to Backup (more frequent advertisement received)
Tue May 19 08:06:19 2015 Info: Interface Failover Group 94 is down
Tue May 19 08:06:28 2015 Info: Interface Failover Group 94 is up
Tue May 19 08:06:28 2015 Info: Interface Failover Group 94 has changed
 role from Master to Backup (more frequent advertisement received)
Tue May 19 08:06:28 2015 Info: Interface Failover Group 94 is down
Tue May 19 08:06:37 2015 Info: Interface Failover Group 94 is up
Tue May 19 08:06:37 2015 Info: Interface Failover Group 94 has changed
 role from Master to Backup (more frequent advertisement received)

Si toma una captura de paquetes (para la dirección IP de multidifusión 224.0.0.18 en este ejemplo), puede observar un resultado similar a este:

13:49:04.601713 IP (tos 0x10, ttl 255, id 4785, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178283
13:49:04.601931 IP (tos 0x10, ttl 255, id 4785, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178283
13:49:04.602798 IP (tos 0x10, ttl 255, id 4785, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178283
13:49:04.602809 IP (tos 0x10, ttl 255, id 4785, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178283
13:49:13.621706 IP (tos 0x10, ttl 255, id 24801, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178284
13:49:13.622007 IP (tos 0x10, ttl 255, id 24801, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178284
13:49:13.622763 IP (tos 0x10, ttl 255, id 24801, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178284
13:49:13.622770 IP (tos 0x10, ttl 255, id 24801, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178284
13:49:22.651653 IP (tos 0x10, ttl 255, id 44741, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178285

Análisis de problemas

Los registros del sistema WSA que se proporcionan en la sección anterior indican que cuando el grupo HA se convierte en maestro en la negociación CARP, hay un anuncio que se recibe con una mejor prioridad.

También puede verificar esto desde la captura de paquetes. Este es el paquete que se envía desde el WSA virtual:

13:49:04.601713 IP (tos 0x10, ttl 255, id 4785, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178283

En un intervalo de tiempo de milisegundos, puede ver otro conjunto de paquetes de la misma dirección IP de origen (el mismo dispositivo WSA virtual):

13:49:04.602798 IP (tos 0x10, ttl 255, id 4785, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178283
13:49:04.602809 IP (tos 0x10, ttl 255, id 4785, offset 0, flags [DF],
 proto VRRP (112), length 56)
   192.168.0.131 > 224.0.0.18: carp 192.168.0.131 > 224.0.0.18: CARPv2-advertise 36:
    vhid=94 advbase=3 advskew=1 authlen=7 counter=15790098039517178283

En este ejemplo, la dirección IP de origen de 192.168.0.131 es la dirección IP del WSA virtual problemático. Parece que los paquetes multicast se vuelven a enviar en loop al WSA virtual.

Este problema ocurre debido a un defecto en el lado de VMware, y la siguiente sección explica los pasos que debe completar para resolver el problema.

Solución

Complete estos pasos para resolver este problema y detener el loop de paquetes multicast que se envían en el entorno VMware:

  1. Habilite el modo promiscuo en el switch virtual (vSwitch).

  2. Habilite los cambios de dirección MAC.

  3. Habilitar transmisiones falsificadas.

  4. Si existen varios puertos físicos en el mismo vSwitch, la opción Net.ReversePathFwdCheckPromisc se debe habilitar para solucionar un error de vSwitch donde el tráfico multicast vuelve a bucles al host, lo que hace que CARP no funcione con los estados de link mensajes combinados. (Consulte la sección siguiente para obtener más información).

Modificar la opción Net.ReversePathFwdCheckPromisc

Complete estos pasos para modificar la opción Net.ReversePathFwdCheckPromisc:

  1. Inicie sesión en el cliente VMware vSphere.

  2. Complete estos pasos para cada host VMware:

    1. Haga clic en host y navegue a la ficha Configuration.

    2. Haga clic en Software Advanced Settings en el panel izquierdo.

    3. Haga clic en Net y desplácese hacia abajo hasta la opción Net.ReversePathFwdCheckPromisc.

    4. Establezca la opción Net.ReversePathFwdCheckPromisc en 1.

    5. Click OK.

Las interfaces que están en modo Promiscuous deben configurarse o apagarse y luego volver a encenderse. Esto se completa por host.

Complete estos pasos para configurar las interfaces:

  1. Vaya a la sección Hardware y haga clic en Networking.

  2. Complete estos pasos para cada vSwitch o grupo de puertos de máquina virtual (VM):

    1. Haga clic en Propiedades desde el vSwitch.

    2. De forma predeterminada, el modo Promiscuous se establece en Rechazar. Para cambiar esta configuración, haga clic en editar y navegue a la ficha Seguridad.

    3. Seleccione Aceptar en el menú desplegable.

    4. Click OK.

Nota: Esta configuración se suele aplicar por grupo de puertos VM (que es más segura), donde el vSwitch se deja en el valor predeterminado (Rechazar).

Complete estos pasos para inhabilitar y luego volver a habilitar el modo Promiscuous:

  1. Vaya a Editar > Seguridad > Excepciones de política.

  2. Desmarque la casilla de verificación Modo promiscuo.

  3. Click OK.

  4. Vaya a Editar > Seguridad > Excepciones de política.

  5. Marque la casilla de verificación Modo promiscuo.

  6. Seleccione Aceptar en el menú desplegable.

Información Relacionada

TAC Authored

Con la colaboración de ingenieros de Cisco

¿Resultó útil este documento?

FeedbackComentarios

Contacte a Cisco

Este documento se aplica a estos productos