Voz y Comunicaciones unificadas : Dispositivos de seguridad Cisco PIX de la serie 500

Funcionamiento de la conmutación por error (failover) en Cisco Secure PIX Firewall

22 Abril 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (30 Septiembre 2008) | Comentarios

Interactivo: Este documento ofrece un análisis personalizado de su dispositivo Cisco.


Contenidos

Introducción
Requisitos previos
     Requisitos
     Componentes utilizados
     Convenciones
Antecedentes
Cable de conmutación por error
Replicación de la configuración de PIX
Control de conmutación por error
Conmutación por recuperación
Prueba de interfaces
Tabla de decisión de hardware
Conmutación por error de funcionamiento en entornos conmutados
Conmutación por error con estado
Comandos de conmutación por error
Ejemplo de salida del comando show failover
     Ejemplo: Conmutación por error normal
     Ejemplo: Aún no se inició el examen de conmutación por error
     Ejemplo: Fallo en la unidad
     Ejemplo: Conmutación por error con estado
Conmutación por error basada en LAN
     Diagrama de fallo basado en la red LAN
     Configuración inicial mínima en el PIX principal
     Configuración mínima inicial en el PIX secundario
     Configuración restante – Conmutación por error con estado
Preguntas frecuentes
Información para recopilar si abre un Caso de soporte técnico
Discusiones relacionadas de la comunidad de soporte de Cisco
Información relacionada

Introducción

El uso de un par de dispositivos PIX idénticos (modelo, memoria, tarjetas de interfaz de red [NICS], versiones de sistema operativo), puede proporcionarse una alta disponibilidad sin intervención del operador.

Requisitos previos

Requisitos

No hay requisitos específicos para este documento.

Componentes utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software. Todos los modelos de PIX soportan la conmutación por error, excepto los modelos 501 y 506E.

Nota: Este documento no incluye las versiones 7.0 y posteriores del software en los dispositivos de seguridad de Cisco PIX serie 500. Consulte el capítulo Configuración de la conmutación por error de la Guía de configuración de CLI de dispositivos de seguridad de Cisco, versión 7.0 .

La información que contiene este documento se creó a partir de los dispositivos en un entorno de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración despejada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener todo comando.

Convenciones

Consulte las Convenciones de consejos técnicos de Cisco para obtener más información sobre las convenciones de los documentos.

Antecedentes

Se considera que un PIX es la unidad “Activa” mientras que el otro es la unidad “En espera”. Como el nombre implica, la unidad activa ejecuta las funciones de red normal mientras que la unidad en espera vigila, preparada para tomar el control si la unidad activa falla en la ejecución de su funcionalidad. Si el comando show version no indica que la conmutación por error está habilitada y usted está intentando realizar una conmutación por error, debe contactar a su equipo de cuenta de Cisco local para comprar una actualización de la licencia.

Cada una de las dos unidades tiene presencia en la red. La unidad activa utiliza la dirección IP del sistema y la dirección MAC de la unidad Primaria. La unidad Primaria está determinada por la unidad que posee el extremo del cable de conmutación por error marcado como “Primario” enchufado en ella o el PIX configurado con el comando failover lan unit primary. Este comando se introdujo en PIX OS versión 6.2. La unidad en espera usa la dirección IP de conmutación por error y las direcciones MAC de la unidad Secundaria. Si se produce una conmutación, la unidad cambia la dirección IP y las direcciones MAC que está utilizando para reemplazar la presencia de cada una de ellas en la red. Esta acción es invisible para la red. Las relaciones de dirección IP a MAC siguen siendo exactamente las mismas. Por lo tanto, las tablas ARP en la red no deben sobrepasar el tiempo de espera ni modificarse. Ningún otro equipo de la red necesita saber acerca de la redundancia o que se produjo una conmutación. Observe que la IP del sistema y las direcciones IP de conmutación por error deben estar en la misma subred, por lo tanto es posible que no haya un router entre las dos unidades.

Cable de conmutación por error

El cable de conmutación por error es el único hardware adicional necesario para soportar la conmutación por error de PIX. En PIX 6.2 y posteriores, usted también puede lograr una conmutación por error con o sin un cable de conmutación por error. El cable de conmutación por error es un cable de enlace en serie RS-232 modificado con una velocidad configurada de 9600 baudios.

Nota: En la versión 5.2 (5.1.2.201) del software PIX, la velocidad se cambia a 115.2 K baudios. Además, el cable de conmutación por error no puede prolongarse.

La comunicación de conmutación por error básica se realiza a través del cable de conmutación por error o a través de la interfaz LAN configurada con el comando failover lan interface interface_name en la versión 6.2 y posterior de PIX OS. La comunicación de conmutación por error a través del cable de conmutación por error está basada en mensajes y debe ser confiable. Cada mensaje enviado es reconocido (ACKed). Si el otro PIX no reconoce un mensaje en tres segundos, se retransmite ese mensaje. Después de cinco retransmisiones sin un ACK (para un total de 15 segundos), el PIX en modo de espera dispara una condición de conmutación por error.

Entre los fallos más comunes de comunicación a través del cable de conmutación por error se encuentran:

  • Intercambio de direcciones MAC

  • Saludo (una señal de mantenimiento)

  • Estado (Activo/En espera)

  • Estado de enlace de red

  • Replicación de la configuración

Replicación de la configuración de PIX

Las dos unidades deben tener exactamente la misma configuración y deben ejecutar la misma versión del software. Esto se logra fácilmente, ya que la replicación de la configuración ocurre por el cable de conmutación por error o desde la interfaz LAN configurada con el comando failover lan interface interface_name , desde la unidad activa hasta la unidad en espera en las siguientes maneras:

  • Cuando la unidad en espera completa su primer inicio, la unidad activa copia toda su configuración a la unidad en espera. Esto ocurre si utiliza un cable de conmutación por error ya que se necesita la configuración inicial en las unidades primarias y en las secundarias para identificarlas como tales. Esta función fue introducida para superar la longitud y velocidad del cable en serie.

  • A medida que los comandos se introducen en la unidad activa, se envían a la unidad inactiva.

  • Cuando se introduce el comando write standby en la unidad activa, se fuerza la configuración completa en la memoria de la unidad en espera.

La replicación de la configuración realiza una copia de "memoria a memoria". Una vez completo esto, se necesita ejecutar el comando write memory en la unidad activa para escribir la configuración en la memoria Flash de la unidad en espera. Durante esta operación se muestran los mensajes de consola "sync started" (sincronización iniciada) y "sync completed" (sincronización finalizada). Las configuraciones grandes pueden demorar un tiempo en transferirse. Si ocurre un intercambio durante la replicación, el nuevo PIX activo tendrá sólo una configuración parcial. Luego la unidad se reinicia para recuperar la configuración desde la memoria Flash o la otra unidad la vuelve a sincronizar.

La replicación de la configuración sólo ocurre desde una unidad activa a una unidad de reserva. Los cambios realizados en la unidad en espera no pasan a la unidad activa.

Control de conmutación por error

Hay un intervalo de consulta de conmutación por error de 15 segundos (después de la versión 5.0 se puede configurar) para vigilar la actividad de la red, las comunicaciones de conmutación por error y el estado de energía. Un fallo de cualquiera de estos parámetros en la unidad activa ocasionará que la unidad en espera tome el control activo. Cada vez que se determina que ha fallado una unidad, ésta cierra sus interfaces de red.

Las dos unidades envían paquetes de “saludo” de conmutación por error especiales entre sí a través del cable de conmutación por error y todas las interfaces cada 15 segundos (sin incluir a aquéllas que están inactivas administrativamente). Si cualquiera de las dos unidades no escucha el “saludo” en una interfaz durante dos comprobaciones de consulta consecutivas, PIX coloca esa interfaz LAN en el modo de prueba para determinar el lugar en el que reside el fallo. Si un PIX en espera no recibe un "saludo" desde el cable de conmutación por error durante dos comprobaciones de consulta consecutivas, el PIX en espera inicia una conmutación y declara en fallo al otro PIX. Si el PIX activo no escucha los mensajes de saludo, permanece activo y configura los PIX restantes como fallidos.

Se coloca una interfaz de la red en modo de prueba si no se recibe un paquete de “saludo”. Una prueba de la interfaz de red es no intrusiva. Esto significa que si bien ésta se encuentra en modo de prueba, sigue intentando pasar el tráfico normal. Es proceso de comprobación consiste en cuatro pruebas individuales (prueba del estado de NIC, prueba de la actividad de red, prueba del Protocolo de resolución de direcciones (ARP) y prueba de PING) destinadas a estimular el tráfico de red. Si una interfaz en el modo de prueba puede recibir tráfico, la interfaz se considera en funcionamiento. Si puede escuchar el tráfico de otra red, se supone que el error debe estar en la otra unidad y que ésta no puede enviar el paquete de "saludo". Esto genera un fallo en la otra unidad. Si se determina que la unidad bajo prueba no puede recibir tráfico de red mientras que la otra sí, la unidad bajo prueba falla.

Además de monitorear todas las interfaces de red, la función de conmutación por error también monitorea el estado de energía de la otra unidad, así como el estado del mismo cable de conmutación por error. El cable de conmutación por error permite detectar si la otra unidad se encuentra conectada y encendida. Si el cable está desconectado de cualquiera de las unidades, se inhabilita la conmutación. Si una unidad activa pierde energía, la unidad en espera toma el control dentro de los 15 segundos. Una unidad en estado “fallido” espera 15 segundos y luego trata de pasar al estado “en espera”. Si la transición desencadena un fallo, la unidad volverá a fallar. Puede usar el comando failover reset para reiniciar el PIX manualmente desde el estado fallido a en espera. Si la transición desencadena un error, la unidad volverá a fallar. Un PIX en estado fallido no puede cambiar a estado activo.

Si el fallo se debe a una condición de “enlace inactivo” en una interfaz, una condición de “enlace activo” elimina el estado fallido (por ejemplo, si una interfaz es desenchufada y más tarde enchufada).

Nota:  Consulte Configuración de la conmutación por error para obtener información detallada sobre las funciones de la conmutación por error versión 7.0 de PIX.

Conmutación por recuperación

En todos los casos en que se produzca una falla o conmutación, se generan los mensajes del syslog para indicar lo que ha acaecido. No se fuerza la conmutación por error hacia la unidad primaria. La conmutación por recuperación no es una actividad forzada ya que no existe razón para conmutar los roles activos e inactivos. Por lo tanto, cuando una unidad primaria fallida está fija y se vuelve a traer en línea, no se reanuda automáticamente como la unidad activa. Para hacer que una unidad sea la unidad activa, use el comando failover active en la unidad en espera o el comando no failover active en la unidad activa. Si se utiliza Conmutación por error con estado, la información de estado de conexión pasa de la unidad activa a la unidad en espera. De lo contrario, la información de estado no está rastreada y las aplicaciones deben restablecer las sesiones. Esto significa que todas las conexiones activas caen luego de una conmutación. Dado que la unidad activada recientemente supone la misma dirección IP y MAC que la unidad activada previamente, ninguna entrada ARP debe cambiar ni caducar en cualquier parte de la red.

En EFT 5.0 y posterior, el intervalo de consulta de conmutación por error de 15 segundos se modifica y puede configurarse. El intervalo puede establecerse entre 3 y 15 segundos, reconociendo la varianza en la detección de fallos de diferentes tarjetas de interfaz.

Prueba de interfaces

En el caso de que los paquetes de “saludo” no se reciban en una interfaz o una interfaz espere un “saludo” más de 2,5 minutos después de que la otra interfaz pasó al estado normal, la interfaz se coloca en el modo de “prueba” (si el estado de la interfaz no es inactivo y el estado del enlace es activo). Cuando esto ocurre, se informa a la otra unidad a través del cable de conmutación por error que la interfaz se encuentra en modo de prueba. Mientras que una interfaz se encuentra en modo de prueba, el tráfico normal puede fluir, siempre y cuando la interfaz funcione adecuadamente. Se comienza la prueba sólo si se ha dado una condición de error y, por lo tanto está basada en la idea "si yo estoy bien, entonces usted debe estar mal. La prueba comprende cuatro pruebas consecutivas:

  1. Prueba del estado NIC

    Esta prueba es un control de enlace ascendente/descendente del NIC mismo. Si no hay una tarjeta de interfaz enchufada en una red en funcionamiento, ésta se considera como fallida.

  2. Prueba de actividad de red

    Esta prueba es una prueba de la "actividad de red recibida". La unidad cuenta todos los paquetes recibidos por hasta 5 segundos. Si se recibe cualquier paquete durante este intervalo, la interfaz se considera operativa y la prueba finaliza. Si no se recibe tráfico alguno, la unidad realiza una prueba de ARP.

  3. Prueba ARP

    En la prueba ARP, la memoria caché ARP de la unidad se lee para las diez entradas adquiridas más recientemente. Entonces, una a la vez, la unidad envía peticiones ARP a estas máquinas en el intento de estimular el tráfico de la red. Luego de cada petición, la unidad cuenta todo el tráfico recibido por hasta 5 segundos. Si se recibe tráfico, la interfaz se considera en funcionamiento. Si no se recibe tráfico alguno, se envía una solicitud ARP a la máquina siguiente. Si al finalizar la lista no se ha recibido tráfico, la unidad realiza la prueba Ping.

  4. Prueba Ping

    Para realizar la prueba Ping, la unidad envía una petición de ping de difusión. Luego la unidad cuenta todos los paquetes recibidos por hasta 5 segundos. Si se recibe cualquier paquete durante este intervalo, la interfaz se considera operativa y la prueba finaliza. Si no se recibe tráfico, se vuelven a iniciar las pruebas con la prueba ARP.

Al inicio de cada prueba, ambas unidades eliminan la cuenta de recepción de la interfaz. Al finalizar cada prueba, la unidad bajo prueba primero verifica si ha recibido tráfico. Si es así, la unidad se considera a sí misma como en funcionamiento y a la otra unidad como fallida. De lo contrario, le pregunta a la otra unidad si ha recibido algún tipo de tráfico. Si es así, la unidad de prueba se considera a sí misma como fallida. Si ninguna unidad recibió tráfico, el proceso de prueba avanza a la siguiente prueba. Si en cualquier momento la unidad que hace la petición no escucha los resultados de la prueba de la otra unidad, se considera que existe un fallo en la otra unidad, de la misma manera que si no escuchó el mensaje de saludo a través del cable de conmutación por error. Si se detecta un fallo en la unidad activa, ocurre una conmutación. Si se determina que la espera falló, no se le permite tomar control activo. Los resultados de estas pruebas se envían a través de syslog por las unidades activa y en espera.

Tabla de decisión de hardware

En cada PIX, la conmutación por error mantiene una tabla de decisión de hardware (HDT) de ambos dispositivos PIX para decidir qué PIX es el dispositivo activo apropiado. Cuando se produce un cambio de estado en la interfaz NIC, se produce un sondeo de conmutación por error de la unidad del dispositivo, se actualiza el HDT local y el cambio se envía a otra PIX. Si bien las tablas HDT se comparan en cada ciclo de consulta, es la segunda consulta la que genera un estado en espera para asumir el control desde la activa al iniciar la conmutación.

Conmutación por error de funcionamiento en entornos conmutados

Hay dos problemas que deben tenerse en cuenta en los entornos conmutados. En primer lugar, el switch debe aprender que una dirección MAC en particular se ha trasladado de un puerto a otro. Cada unidad (a menos que se haya producido un error) transmite una serie de mensajes de conmutación por error en cada interfaz mediante sus direcciones MAC e IP nuevas. Esto permite al switch actualizar sus tablas MAC internas. Cisco recomienda vehemente que los clientes habiliten portfast en todos los puertos de conmutación que se conectan con las interfaces de PIX. Además, se debe inhabilitar la canalización y el enlace troncal en estos puertos. Así, si la interfaz de PIX cae durante una conmutación por error, el switch no tendrá que aguardar 30 segundos mientras el puerto pasa de escuchar a aprender y a un estado de reenvío.

Este bloqueo del tráfico de la red nos lleva al segundo problema. Si los paquetes de “saludo” enviados por conmutación por error no son reenviados, cada unidad piensa que algo está erróneo y comienza a probar sus interfaces. Esto genera el fallo de una unidad a porque los resultados de la prueba son "si yo estoy bien, entonces usted debe estar mal". Para evitar este problema, cada vez que ocurre un intercambio las unidades entran en un estado de "espera". En este estado el tráfico de red está libre para fluir a través de la unidad activa, pero la conmutación por error espera la recepción de dos mensajes de "saludo" antes de controlar las interfaces nuevamente. Esto permite al switch entrar en un estado de bloqueo sin interrumpir la conmutación por error. Una vez que se escucha el segundo mensaje de “saludo”, la conmutación por error reanuda la supervisión normal de sus interfaces.

Para la versión 5.2 y posteriores del software PIX, cuando un dispositivo cambia de estado inactivo a estado activo, o de activo a estado inactivo, se establece un ARP gratuito para cada interfaz de red para retransmitir las nuevas direcciones IP y MAC.

Conmutación por error con estado

Sin retener la información con estado del PIX, después de un traspaso, todas las conexiones existentes se caen y se requiere que la aplicación se reinicie. En su versión 5.0, el software PIX provee conmutación por error con estado de manera tal que la conexión existente pueda permanecer activa después de un intercambio.

Para poder utilizar la conmutación por error con estado, se requiere una interfaz LAN dedicada entre los dos dispositivos PIX. Logical Update (LU) es el módulo de software que transporta las aplicaciones PIX que soportan conmutación por error con estados. La actualización de estado ocurre del modo activo al modo en reserva a través de la interfaz LAN. La actualización de estado enviada a PIX en espera es desencadenada por la aplicación. El transporte de LU es similar a UDP, sin aplicaciones de bloqueo y retransmisión que demoren el procesamiento normal de paquetes. Los paquetes de actualización de estado se transmiten de modo asíncrono en segundo plano. No obstante, el protocolo de LU es en tiempo real y proporciona notificación de errores y notifica las actualizaciones de estado faltantes con fines de supervisión.

Se realiza la sincronización de estado inicial después de la replicación de la configuración. Esto se logra explorando los registros de las tablas de traducción y conexión. A continuación, tal vez se active una actualización del estado.

Los registros de conexión (conn) y traducción de direcciones PIX (xlate, estática y dinámica) son datos de estado esenciales y se transmiten a la unidad en espera desde la unidad activa junto con otra información de estado. Como la conmutación por error no puede programarse previamente, la actualización de estado para la conexión se basa en el paquete. Esto significa que todos los paquetes pasan a través del PIX y cambian el estado de una conexión, lo que puede activar un estado de actualización.

Se transfieren las tablas de estado TCP. No obstante, de forma predeterminada, HTTP (puerto TCP 80) no se duplica. En la versión 6.0 y posterior, puede usar el comando failover replicate http para permitir la replicación de estado del puerto TCP 80. La mayoría de las tablas de estado UDP no se transfieren, con la excepción de los puertos abiertos dinámicamente que corresponden a los protocolos multicanal como H.323 y VoIP. Por lo tanto, las resoluciones de DNS no se transfieren, ya que es un puerto de canal único.

Hay aplicaciones sensibles a la latencia y, en algunos casos, la aplicación se interrumpe antes de completarse la secuencia de conmutación por error. En estos casos, la aplicación debe reestablecer la sesión.

Nota: No hay una lista completa de aplicaciones que puedan caerse a causa del tiempo que se requiere para que el que se encuentra en espera asuma el control. Una buena regla a seguir es anticipar que el dispositivo en espera aguarde 10 segundos para tomar el control utilizando la conmutación por error con estado. Sin la conmutación por error con estado, puede tardar hasta un minuto en reestablecer las conexiones.

Nota: La única advertencia sobre la conmutación por error con estado es qué provoca la conmutación por error. Si ha establecido failover hello al máximo de 15 segundos y la interfaz interna falla, el dispositivo en espera no declara que la primaria ha fallado hasta que detecta la ausencia de dos saludos, 30 segundos. Algunas personas establecen los saludos de la conmutación por error al mínimo de 3 segundos, pero, en este caso, el PIX puede realizar la conmutación por error sin necesidad. Cisco recomienda establecer el saludo al máximo de 15 segundos.

Comandos de conmutación por error

  • [no] failover - Habilita o inhabilita la conmutación por error.

  • [no] failover active - Provoca que una unidad se vuelva activa/inactiva.

  • failover ip address #.#.#.# - Especifica la dirección IP para la conmutación por error.

  • failover reset - Borra el estado fallido de ambas unidades y reinicia la conmutación por error.

  • [no] failover link interface - Especifica qué interfaz se usará para transmitir la actualización del estado PIX de activo a inactivo en una conmutación por error con estado.

  • failover poll seconds - Especifica el intervalo de consulta de conmutación por error (Software PIX versión 5.2 y posterior).

  • failover lan unit primary | secondary - Utilizado en conmutación por error basada en LAN para definir primario/secundario (PIX versión 6.2 y posterior).

  • failover lan enable - Especifica la conmutación por error basada en LAN (PIX versión 6.2 y posterior).

  • failover lan interface lan_if_name - El nombre de la interfaz de firewall dedicada a la conmutación por error basada en LAN (PIX versión 6.2 y posterior).

  • failover lan key key_secret - Habilita el cifrado y la autenticación de mensajes de conmutación por error basada en LAN entre los firewall de PIX utilizando la clave secreta (PIX versión 6.2 y posterior).

  • failover mac address mif_name act_mac stn_mac - Permite configurar una dirección MAC virtual para un par de conmutación por error del firewall de PIX en lugar de contactar al otro para obtener la dirección MAC (PIX versión 6.2 y posterior).

Ejemplo de salida del comando show failover

Estos ejemplos presuponen que el cable de conmutación por error está instalado y en funcionamiento. También asumen que las unidades se han configurado con una dirección de IP del sistema 192.168.89.1 y una dirección de IP de conmutación por error 192.168.89.2.

Ejemplo: Conmutación por error normal

Este ejemplo es el resultado normal del comando show failover. Observe que se muestra la dirección IP de cada unidad. Si no se ha introducido ninguna dirección IP de conmutación por error, muestra 0.0.0.0 y el monitoreo de las interfaces queda en estado de "espera". Consulte la sección Ejemplo: Aún no se ha iniciado el examen de conmutación por error para obtener una explicación del estado “en espera”.

Failover On

Cable status: Normal

Reconnect timeout 0:00:00

	This host: Primary - Active

		Active time: 6885 (sec)

		Interface 0 (192.168.89.1): Normal

		Interface 1 (192.168.89.1): Normal

	Other host: Secondary - Standby

		Active time: 0 (sec)

		Interface 0 (192.168.89.2): Normal

		Interface 1 (192.168.89.2): Normal 

Ejemplo: Aún no se inició el examen de conmutación por error

Estos ejemplos demuestran lo que ocurre cuando la conmutación por error no ha comenzado a controlar las interfaces de la red. La conmutación por error no inicia la supervisión de las interfaces de la red hasta que escucha el segundo paquete de “saludo” de la otra unidad en esa interfaz. Esto lleva aproximadamente 30 segundos. Si la unidad está conectada a un switch de red que ejecuta el protocolo STP (Spanning Tree Protocol, protocolo del árbol de expansión), tardará el doble del tiempo de "retardo de reenvío" configurado en el switch (en general, 15 segundos), más este retardo de 30 segundos. Esto ocurre porque en el inicio del PIX y en el evento de conmutación por error que continúa inmediatamente, el switch de red detecta un bucle de bridge temporal. Después de la detección de este bucle, detiene el reenvío de paquetes en estas interfaces por el tiempo de "demora de reenvío". A continuación, entra en el modo de “escucha” durante un tiempo de “demora de reenvío” adicional, durante el cual el switch escucha los bucles de bridge pero no el tráfico de reenvío (y, por lo tanto, no reenvía los paquetes de "saludo" de la conmutación por error). Después del doble del tiempo de retardo de reenvío (30 segundos), el tráfico debe reanudar el flujo. Cada PIX permanece en modo “de espera” hasta que oye 30 segundos de paquetes de saludo de la otra unidad. Durante el tiempo en el que el PIX pasa el tráfico, no hace fallar a la otra unidad basándose en no escuchar los paquetes de saludo. Todos los demás monitoreos de conmutación por error continúan ocurriendo (es decir, Energía, Pérdida de enlace de la interfaz, y mensajes de saludo de cable de conmutación por error).

Failover On

Cable status: Normal

Reconnect timeout 0:00:00

	This host: Primary - Active

		Active time: 6930 (sec)

		Interface 0 (192.168.89.1): Normal (Waiting)

		Interface 1 (192.168.89.1): Normal (Waiting)

	Other host: Secondary - Standby

		Active time: 15 (sec)

		Interface 0 (192.168.89.2): Normal (Waiting)

		Interface 1 (192.168.89.2): Normal (Waiting)

Ejemplo: Fallo en la unidad

En este ejemplo, la conmutación por error detecta un fallo. Observe que la interfaz 1 en la unidad primaria es la fuente del fallo. Las unidades vuelven al modo "en espera" debido al error. La unidad fallida se ha eliminado a sí misma de la red (las interfaces están inactivas) y ya no envía paquetes de “saludo” en la red. La unidad activa se mantiene en un estado de "espera" hasta que se reemplace la unidad que ha fallado y hasta que las comunicaciones de transmisión de conmutación por error se reanuden.

Failover On

Cable status: Normal

Reconnect timeout 0:00:00

	This host: Primary - Standby (Failed)

		Active time: 7140 (sec)

		Interface 0 (192.168.89.2): Normal (Waiting)

		Interface 1 (192.168.89.2): Failed (Waiting)

	Other host: Secondary - Active

		Active time: 30 (sec)

		Interface 0 (192.168.89.1): Normal (Waiting)

		Interface 1 (192.168.89.1): Normal (Waiting)

Ejemplo: Conmutación por error con estado

Este ejemplo muestra el resultado del comando show failover con la conmutación por error con estado habilitada. Observe que se muestra “Frecuencia de consulta de 4 segundos”. La interfaz de red número 4 se encuentra administrativamente cerrada. FailLink de la interfaz de red es el enlace de la conmutación por error con estado.

Failover On

Cable status: Normal

Reconnect timeout 0:00:00

Poll frequency 4 seconds

	This host: Secondary - Active

			Active time: 167464 (sec)

			Interface gb (7.7.7.1): Normal

			Interface 4th (172.1.1.3): Link Down (Shutdown)

			Interface FailLink (8.8.8.1): Normal

			Interface pix/intf2 (100.2.1.3): Normal

			Interface outside (100.1.1.3): Normal

			Interface inside (10.1.1.3): Normal

	Other host: Primary - Standby

			Active time: 0 (sec)

			Interface gb (7.7.7.2): Normal

			Interface 4th (172.1.1.4): Link Down (Shutdown)

			Interface FailLink (8.8.8.2): Normal

			Interface pix/intf2 (100.2.1.4): Normal

			Interface outside (100.1.1.4): Normal

			Interface inside (10.1.1.4): Normal





Stateful Failover Logical Update Statistics

	 Link : FailLink

	 Stateful Obj    xmit       xerr       rcv        rerr

	 General        22501          0     34259           0

	 sys cmd        16007          0     33961          13

	 up time            4          0         2           0

	 xlate           5094          0         6           0

	 tcp conn         514          0       290           0

	 udp conn           0          0         0           0

	 ARP tbl          882          0         0           0

	 RIP Tbl            0          0         0           0

	 Logical Update Queue Information

			  Cur   Max    Total

	 Recv Q:    0     3    34259

	 Xmit Q:    0     7    22504

Hay disponible información adicional sobre conmutación por error en la Guía de configuración para el firewall PIX.

Si cuenta con el resultado de un comando show failover de su dispositivo Cisco, puede utilizar Output Interpreter (solamente clientes registrados) para que se muestren los problemas potenciales y sus soluciones.

Conmutación por error basada en LAN

Diagrama de fallo basado en la red LAN

failover_01.gif

Se recomienda que conecte los PIX primario y secundario a un switch dedicado. No utilice cables cruzados. En este diagrama, un switch Cisco Catalyst 3500 se conecta con los PIX primario y secundario. Los enlaces de la conmutación por error de LAN y conmutación por error con estado están en diferentes VLAN, VLAN 10 y VLAN 20, respectivamente. El router interno y el router externo se utilizan solamente para la prueba de conectividad.

Configuración inicial mínima en el PIX principal

Los siguientes son los comandos mínimos que resulta necesario configurar en el PIX primario:

Comandos básicos

pixfirewall(config)#hostname PIX

!--- La asignación de un nombre a PIX es opcional.

PIX(config)#nameif ethernet2 fo security20

!--- La asignación de un nombre a la interfaz es opcional. Se recomienda que 
!--- fuerce la velocidad/dúplex.

PIX(config)#interface ethernet2 100full

!--- Active la interfaz.

PIX(config)#ip address fo 192.168.1.1 255.255.255.0

!--- Asigne una dirección IP.

Comandos de conmutación por error

PIX(config)#failover ip address fo 192.168.1.2

!--- Dirección IP para el enlace de conmutación por error.

PIX(config)#failover lan unit primary

!--- Esta unidad es primaria.

PIX(config)#failover lan interface fo 

!--- La interfaz “fo” se utiliza para la conmutación por error de LAN. 

PIX(config)#failover lan key cisco 

!--- La clave previamente compartida.

PIX(config)#failover lan enable 

!--- Habilita la conmutación por error.

PIX(config)#failover

!--- Inicia el proceso de conmutación por error.

Este mensaje aparece en la consola.

LAN-based Failover: trying to contact peer

LAN-based Failover: Send hello msg and start failover monitoring 

Configuración mínima inicial en el PIX secundario

Los siguientes son los comandos mínimos que resulta necesario configurar en el PIX secundario:

Comandos básicos

pixfirewall(config)#hostname PIX 

PIX(config)#nameif ethernet2 fo security20

!--- Se recomienda que fuerce la velocidad/dúplex. 


PIX(config)#interface ethernet2 100full

PIX(config)#ip address fo 192.168.1.1 255.255.255.0 

Comandos de conmutación por error

PIX(config)#failover ip address fo 192.168.1.2

PIX(config)#failover lan unit secondary 

!--- Esta unidad es secundaria. 

PIX(config)#failover lan interface fo 

PIX(config)#failover lan key cisco 

PIX(config)#failover lan enable

PIX(config)#failover

!--- Esta unidad es secundaria porque la palabra clave “activa” no se utiliza.

Después de ejecutar estos comandos en el PIX secundario, aparecen estos mensajes en la consola:

LAN-based Failover: trying to contact peer??

LAN-based Failover: Send hello msg and start failover monitoring 

A continuación, en el PIX primario, estos mensajes aparecen en la consola:

LAN-based Failover: Peer is UP

Sync Started

Sync Completed

Nota: Si no ve estos mensajes, es posible que haya algún error. Para poder resolver este problema con rapidez, encienda los depuradores de rastreo ICMP en la unidad secundaria utilizando el comando debug icmp trace y haga ping desde la unidad primaria en la dirección IP de la conmutación por error.

Nota: Con el PIX Primario:

PIX(config)#ping 192.168.1.2

		192.168.1.2 response received -- 0ms

		192.168.1.2 response received -- 0ms

		192.168.1.2 response received -- 0ms

PIX(config)#



On Secondary Unit

PIX(config)#debug icmp trace

!--- Configure este comando antes de iniciar el comando ping.


ICMP trace on

Warning: this may cause problems on busy networks

PIX(config)# 1: ICMP echo request (len 32 id 9233 seq 0)

   192.168.1.1 > 192.168.1.2

2: ICMP echo reply (len 32 id 9233 seq 0) 192.168.1.2 > 192.168.1.1

3: ICMP echo request (len 32 id 9233 seq 1) 192.168.1.1 > 192.168.1.2

4: ICMP echo reply (len 32 id 9233 seq 1) 192.168.1.2 > 192.168.1.1

5: ICMP echo request (len 32 id 9233 seq 2) 192.168.1.1 > 192.168.1.2

6: ICMP echo reply (len 32 id 9233 seq 2) 192.168.1.2 > 192.168.1.1 

Nota: Una vez que termine, apague estos depuradores con el comando no debug icmp trace.

Si no puede hacer ping exitosamente, marque las configuraciones de VLAN y del puerto en el switch intermedio. Además, asegúrese de utilizar cables Cat 5 confiables.

Resultado de PIX principal:

PIX(config)#show failover lan



LAN-based Failover is Active

		interface fo (192.168.1.1): Normal, peer (192.168.1.2): Normal



PIX(config)#show failover

Failover On

Cable status: My side not connected

!--- El cable en serie de conmutación por error no se utiliza.

Reconnect timeout 0:00:00

Poll frequency 15 seconds

	This host: Primary - Active

			Active time: 4335 (sec)

			Interface intf5 (0.0.0.0): Link Down (Shutdown)

			Interface intf4 (0.0.0.0): Link Down (Shutdown)

			Interface intf3 (0.0.0.0): Link Down (Shutdown)

			Interface outside (0.0.0.0): Link Down (Shutdown)

			Interface inside (0.0.0.0): Link Down (Shutdown)

	Other host: Secondary - Standby

			Active time: 30 (sec)

			Interface intf5 (0.0.0.0): Link Down (Shutdown)

			Interface intf4 (0.0.0.0): Link Down (Shutdown)

			Interface intf3 (0.0.0.0): Link Down (Shutdown)

			Interface outside (0.0.0.0): Link Down (Shutdown)

			Interface inside (0.0.0.0): Link Down (Shutdown)



Stateful Failover Logical Update Statistics

		Link : Unconfigured.

!--- La conmutación por error con estado no está configurada aún. 





LAN-based Failover is Active

		interface fo (192.168.1.1): Normal, peer (192.168.1.2): Normal

Salida del PIX secundario:

PIX(config)#show failover lan 



LAN-based Failover is Active

		interface fo (192.168.1.2): Normal, peer (192.168.1.1): Normal





PIX(config)#show failover

Failover On

Cable status: My side not connected

!--- No se utiliza un cable en serie de conmutación por error.


Reconnect timeout 0:00:00

Poll frequency 15 seconds

	This host: Secondary - Standby

			Active time: 30 (sec)

			Interface intf5 (0.0.0.0): Link Down (Shutdown)

			Interface intf4 (0.0.0.0): Link Down (Shutdown)

			Interface intf3 (0.0.0.0): Link Down (Shutdown)

			Interface outside (0.0.0.0): Link Down (Shutdown)

			Interface inside (0.0.0.0): Link Down (Shutdown)

	Other host: Primary - Active

			Active time: 4485 (sec)

			Interface intf5 (127.0.0.1): Link Down (Shutdown)

			Interface intf4 (127.0.0.1): Link Down (Shutdown)

			Interface intf3 (127.0.0.1): Link Down (Shutdown)

			Interface outside (127.0.0.1): Link Down (Shutdown)

			Interface inside (127.0.0.1): Link Down (Shutdown)



Stateful Failover Logical Update Statistics

		Link : Unconfigured.

!--- La conmutación por error con estado no está configurada aún. 





LAN-based Failover is Active

		interface fo (192.168.1.2): Normal, peer (192.168.1.1): Normal 

Configuración restante – Conmutación por error con estado

El trabajo básico en los PIX primario y secundario está completo.

En este ejemplo, la interfaz E3 está siendo utilizada para transportar información de estado entre las dos unidades. Puede utilizar la interfaz E2 (que se utiliza para verificación de la integridad y replicación de la configuración) para este fin, si su PIX no está cargado en exceso. Se recomienda utilizar una interfaz distinta para este propósito.

En el PIX principal, configure los siguientes comandos:

ip address stateful-fo 172.16.1.1 255.255.255.0 interface ethernet3 100full
failover ip address stateful-fo 172.16.1.2 failover link stateful-fo 

En el PIX secundario, configure lo siguiente:

ip address stateful-fo 172.16.1.2 255.255.255.0 nameif ethernet3 stateful-fo
security30 interface ethernet3 100full

Compruebe el estado.

PIX(config)#show failover 
Failover On 
Cable status: My side not connected 
Reconnect timeout 0:00:00 
Poll frequency 15 seconds 
        This host: Primary - Active 
                Active time: 3945 (sec) 
                Interface intf5 (0.0.0.0): Link Down (Shutdown) 
                Interface intf4 (0.0.0.0): Link Down (Shutdown) 
                Interface stateful-fo (172.16.1.1): Normal 
                Interface outside (0.0.0.0): Link Down (Shutdown) 
                Interface inside (0.0.0.0): Link Down (Shutdown) 
        Other host: Secondary - Standby 
                Active time: 30 (sec) 
                Interface intf5 (0.0.0.0): Link Down (Shutdown) 
                Interface intf4 (0.0.0.0): Link Down (Shutdown) 
                Interface stateful-fo (172.16.1.2): Normal 
                Interface outside (0.0.0.0): Link Down (Shutdown) 
                Interface inside (0.0.0.0): Link Down (Shutdown) 

Estadísticas de actualización lógica de la conmutación por error con estado

 
Link : stateful-fo

!--- Interface stateful-fo is used for stateful failover
. 
Stateful Obj    xmit       xerr       rcv        rerr 
General         40         0          40         0 
sys cmd         40         0          40         0 
up time         0          0          0          0 
xlate           0          0          0          0 
tcp conn        0          0          0          0 
udp conn        0          0          0          0 
ARP tbl         0          0          0          0 
RIP Tbl         0          0          0          0 

Logical Update Queue Information 
                        Cur     Max     Total 
Recv Q:         0       1       41 
Xmit Q:         0       1       41 

LAN-based Failover is Active 
        interface fo (192.168.1.1): Normal, peer (192.168.1.2): Normal 
  

PIX(config)#show failover lan detail 

LAN-based Failover is Active 
This PIX is Primary 
Command Interface is fo 
My Command Interface IP is 192.168.1.1 
Peer Command Interface IP is 192.168.1.2 
My interface status is Normal 
Peer interface status is Normal 
Peer interface down time is 0x0

!--- This is good. 


Total cmd msgs sent: 2579, rcvd: 2241, dropped: 2, retrans: 19, send_err: 0 
Total secure msgs sent: 2760, rcvd: 2383 
bad_signature: 0, bad_authen: 0, bad_hdr: 0, bad_osversion: 0, bad_length: 0 
Total failed retx lck cnt: 0 
Total/Cur/Max of 1245:0:1 msgs on retransQ, 1239 ack msgs 
Cur/Max of 0:21 msgs on txq 
Number of blk allocation failure: 0, cmd failure: 0, Flapping: 0 

Current cmd window: 1, Slow cmd Ifc cnt: 0 
Cmd Link down: 0, down and up: 0, Window Limit: 4301 
Number of fmsg allocation failure: 0 
Cmd Response Time History stat: 
< 100ms:         1237 
100 - 250ms:     0 
250 - 500ms:     0 
500 - 750ms:     0 
750 - 1000ms:    0 
1000 - 2000ms:   7 
2000 - 4000ms:   5 
> 4000ms:        9 
Cmd Response Retry History stat: 
Retry 0 = 1242, 1 = 5, 2 = 5, 3 = 3, 4 = 3 
Failover enable state is 0x1 
Failover state is 0x7d 
Failover peer state is 0x58 
Failover switching state is 0x0 
Failover config syncing is not in progress 
Failover poll cnt is 0 
Failover Fmsg cnt is 0 
Failover OS version is 6.2(0)243 
failover interface 0, tst_mystat = 0x3, tst_peerstat = 0x3 
    zcnt = 0, hcnt = 0, my_rcnt = 0, peer_rcnt = 0 
    myflag = 0x0, peer_flag=0x0, dchp = 0x807696d8 
    act_ip: 0.0.0.0, stn_ip:0.0.0.0 
    act_mac: 00d0.b71d.2b4d, stb_mac: 00d0.b780.574f 
failover interface 1, tst_mystat = 0x3, tst_peerstat = 0x3 
    zcnt = 0, hcnt = 0, my_rcnt = 0, peer_rcnt = 0 
    myflag = 0x0, peer_flag=0x0, dchp = 0x80769738 
    act_ip: 0.0.0.0, stn_ip:0.0.0.0 
    act_mac: 00d0.b71a.e6fb, stb_mac: 00e0.b600.8673 
failover interface 2, tst_mystat = 0x0, tst_peerstat = 0x2 
    zcnt = 0, hcnt = 0, my_rcnt = 2271, peer_rcnt = 0 
    myflag = 0x0, peer_flag=0x0, dchp = 0x80769618 
    act_ip: 192.168.1.1, stn_ip:192.168.1.2 
    act_mac: 00e0.b600.a931, stb_mac: 00e0.b600.a931 
LAN-based Failover command link 
failover interface 3, tst_mystat = 0x0, tst_peerstat = 0x0 
    zcnt = 0, hcnt = 0, my_rcnt = 88, peer_rcnt = 54 
    myflag = 0x1, peer_flag=0x1, dchp = 0x80769558 
    act_ip: 172.16.1.1, stn_ip:172.16.1.2 
    act_mac: 00e0.b600.a930, stb_mac: 00e0.b600.8671 
failover interface 4, tst_mystat = 0x3, tst_peerstat = 0x3 
    zcnt = 0, hcnt = 0, my_rcnt = 0, peer_rcnt = 0 
    myflag = 0x0, peer_flag=0x0, dchp = 0x80769498 
act_ip: 0.0.0.0, stn_ip:0.0.0.0 
    act_mac: 00e0.b600.a92f, stb_mac: 00e0.b600.8670 
failover interface 5, tst_mystat = 0x3, tst_peerstat = 0x3 
    zcnt = 0, hcnt = 0, my_rcnt = 0, peer_rcnt = 0 
    myflag = 0x0, peer_flag=0x0, dchp = 0x807693d8 
    act_ip: 0.0.0.0, stn_ip:0.0.0.0 
    act_mac: 00e0.b600.a92e, stb_mac: 00d0.b780.564f 

Otras configuraciones en el PIX primario.

Ésta es otra configuración para el PIX primario.

  1. Asigne un código inalterable a la velocidad/dúplex de otras interfaces. Puede utilizar “auto” pero ha recomendado que fuerce la velocidad/dúplex.

    interfaz ethernet0 100full
    interfaz ethernet1 100full
  2. Asigne direcciones IP a otras interfaces.

    dirección IP externa 1.1.1.1 255.255.255.0
    dirección IP interna 10.10.10.1 255.255.255.0
  3. Agregue el comando failover ip address para todas las interfaces excepto aquéllas que están inactivas:

    dirección ip de conmutación por error fuera de 1.1.1.2
    dirección ip de conmutación por error dentro de 10.10.10.2

Otras configuraciones en el PIX secundario

A continuación se explica cómo configurar el PIX secundario.

  1. Asigne un código inalterable a la velocidad/dúplex de otras interfaces. Puede utilizar “auto” pero es recomendable que fuerce la velocidad/dúplex.

    interfaz ethernet0 100full
    interfaz ethernet1 100full
  2. Asigne direcciones IP a otras interfaces.

    dirección IP externa 1.1.1.2 255.255.255.0
    dirección ip dentro de 10.10.10.1 255.255.255.0 

A continuación se incluye el resultado del PIX secundario después de producirse la conmutación por error.

PIX(config)#show failover 
Failover On
Cable status: My side not connected
Reconnect timeout 0:00:00
Poll frequency 15 seconds
        This host: Secondary - Active 
                Active time: 315 (sec)
                Interface intf5 (127.0.0.1): Link Down (Shutdown)
                Interface intf4 (127.0.0.1): Link Down (Shutdown)
                Interface stateful-fo (172.16.1.2): Normal (Waiting)
                Interface outside (1.1.1.2): Normal (Waiting)
                Interface inside (10.10.10.2): Normal (Waiting)
        Other host: Primary - Standby 
                Active time: 8025 (sec)
                Interface intf5 (0.0.0.0): Link Down (Shutdown)
                Interface intf4 (0.0.0.0): Link Down (Shutdown)
                Interface stateful-fo (172.16.1.2): Normal (Waiting)
                Interface outside (1.1.1.2): Normal (Waiting)
                Interface inside (10.1.1.2): Link Down (Waiting)

Stateful Failover Logical Update Statistics
        Link : stateful-fo
        Stateful Obj    xmit       xerr       rcv        rerr      
        General         146        0          0          0         
        sys cmd         146        0          0          0         
        up time         0          0          0          0         
        xlate           0          0          0          0         
        tcp conn        0          0          0          0         
        udp conn        0          0          0          0         
        ARP tbl         0          0          0          0         
        RIP Tbl         0          0          0          0         

        Logical Update Queue Information
                        Cur     Max     Total
        Recv Q:         0       0       0
        Xmit Q:         0       1       146

LAN-based Failover is Active
        interface fo (192.168.1.2): Normal, peer (192.168.1.1): Normal

Otros comandos failover que se pueden configurar en PIX:

failover mac address <ifc_name> <act_mac> <stn_mac>
failover poll <seconds>
failover replication http
outside-router#write  terminal

interface FastEthernet3/1 
 ip address 1.1.1.200 255.255.255.0 
 duplex auto 
 speed auto 
  
  
inside-router#write  terminal
interface FastEthernet2/1 
 ip address 10.10.10.200 255.255.255.0 
 duplex auto 
 speed auto 
! 
ip route 0.0.0.0 0.0.0.0 10.10.10.1 

Siga configurando la unidad primaria y la configuración se duplicará en la unidad secundaria de forma automática.

Preguntas frecuentes

  1. ¿Cómo se logra la inicialización de arranque entre dos unidades?

    El valor predeterminado para la conmutación por error es inactivo (sin conmutación por error). No obstante, si el cable de conmutación por error está enchufado en una unidad en el momento del inicio, la conmutación por error detecta automáticamente el cable y activa la conmutación por error y establece el estado de la unidad a Primario o Secundario. Esto se da en el momento del inicio aun si las direcciones IP de la conmutación por error no están configuradas adecuadamente.

    Nota: Si el cable está instalado en un PIX en ejecución, debe ejecutar el comando failover para iniciar la conmutación por error. En el software PIX posterior a la versión 4.4.3, este valor puede modificarse. Esto se debe a que la replicación de la configuración puede inhabilitar accidentalmente la conmutación por error con el comando clear config. Si el cable de conmutación por error no está presente en el momento de inicio, la unidad se convierte de inmediato en la unidad activa. Sin embargo, la unidad se muestra como “Secundaria”.

    Estas discusiones asumen que la conmutación por error está habilitada y que ambas unidades tienen el cable de conmutación por error enchufado. Cuando la unidad se reinicia inicialmente, habilita la conmutación por error y pasa de forma predetermina al estado en espera si se detecta la energía desde la otra unidad. La unidad envía estado de tiempo de ejecución (en espera) y solicita una dirección MAC de la otra unidad. Si ninguna unidad ha tomado el control activo dentro del tiempo de sondeo de conmutación por error, la unidad cambia al estado activa.

    Nota: Para las versiones del software PIX anteriores a 5.2.1, el tiempo de consulta de la conmutación por error se forzó a 15 segundos.

    Normalmente, la otra unidad responde a la petición o envía mensajes de SALUDO de conmutación por error para cada sondeo de conmutación por error. Una vez que se inicie la comunicación con el cable de conmutación por error, ambas unidades comprueban el estado activo/en espera. La unidad primaria conmuta al estado activo si la unidad secundaria está en estado inactivo. Esto significa que si las unidades primaria y secundaria completan sus inicios dentro de la primera verificación de consulta de conmutación por error de cada una, la unidad primaria se convierte en activa. Si la secundaria ya está activa, la unidad primaria permanece en espera (asume la secundaria aprendida de la dirección MAC primaria anterior. La unidad primaria no asume el control activo automáticamente. Con la conmutación por error habilitada, no inicie la unidad secundaria sin iniciar antes la primaria, ya que la dirección MAC que se usa pertenece a la unidad primaria. Si una unidad se inicia sin el cable de conmutación por error, o si no existe comunicación de conmutación por error a través del cable de conmutación por error, ambas unidades se podrían activar y el tráfico de la red se interrumpirá.

    Con la conmutación por error habilitada, la replicación de la configuración completa ocurre desde la unidad activa hasta la unidad en espera cuando se inicia por primera vez la unidad en espera. A partir de este momento, los comandos pasan de activo a en espera a medida que se ejecutan. Para forzar una replicación de la configuración completa, use el comando write standby. La relicación de la configuración sólo ocurre desde la unidad activa a la de en espera. Los comandos emitidos en la unidad inactiva no se duplican en la unidad activa. Cuando se ejecutan comandos en la unidad de espera, aparece un mensaje de advertencia que le indica que las configuraciones ya no están sincronizadas.

  2. Qué se entiende por fallo

    La detección de fallo está basada en:

    1. El estado de la Tarjeta de interfaz de red (NIC). Si el estado de enlace de una NIC es inactivo, la unidad falla. “Inactivo” significa que la tarjeta NIC no está conectada en un puerto en funcionamiento. La configuración de una NIC como "desconectada", no frustra esta prueba.

    2. Comunicaciones de conmutación por error de la red. Las dos unidades se envían paquetes de “saludo” entre sí a través de todas las interfaces de red. Si no se escucharon paquetes de “saludo” en 30 segundos, la interfaz agresora se coloca en el modo de prueba para determinar de dónde proviene el fallo.

    3. Comunicación por cable de conmutación por error. Las dos unidades se envían mensajes de “saludo” mutuamente a través del cable de conmutación por error. Si el modo de espera no recibe señales del modo activo en un intervalo de 30 segundos y el cable de estado está en buen estado, la espera pasa al estado activo.

      Asimismo, si los comandos de conmutación por error enviados a través del cable de respaldo no se reconocen en 15 segundos, actúa el de reserva como activo.

    4. Errores de cable. El cable de conmutación por error está conectado de modo que cada unidad pueda distinguir entre:

      • Un fallo de energía en otra unidad.

      • Un cable desconectó esta unidad.

      • Un cable desconectó otra unidad.

      Si el modo en espera detecta que el activo está desconectado (o recargado/restablecido), toma el control activo. Si el cable de conmutación por error está desconectado, se genera un syslog, pero no se lleva a cabo ninguna conmutación. Una excepción se produce durante el inicio, cuando un cable desenchufado obliga a la unidad a activarse. Si ambas unidades están encendidas sin la instalación del cable de conmutación por error, se activan y crean una dirección IP duplicada con diferentes direcciones MAC, lo que produce un conflicto en la red. El cable de conmutación por error debe instalarse para que la conmutación por error funcione correctamente.

  3. ¿Cuánto tiempo requiere la detección de un fallo con los valores de intervalo de consulta predeterminados?

    • Los errores de comunicaciones de red se detectan en un lapso de 30 segundos.

    • Los errores de comunicaciones de la conmutación por error se detectan en un lapso de 30 segundos.

    • Se detecta el corte del suministro de electricidad (y el fallo del cable) dentro de los 15 segundos.

  4. ¿Qué sucede cuando se desencadena la conmutación por error?

    Cualquier unidad puede iniciar una conmutación. Cuando un switch asume el control, las unidades cambian sus estados además de la dirección IP y las direcciones MAC que utilizan. Desde la perspectiva de la red, el estado en espera reemplaza transparentemente la unidad previamente activa. Dado que la configuración ya está completa en el estado en espera, no es necesario realizar actualizaciones, dado que las dos unidades no comparten estados de conexión dinámicos. Cualquier conexión activa se caerá cuando se produzca una conmutación por error. Los clientes deben reestablecer las conexiones a través de la unidad ahora activa (a menos que la conmutación por error con estado esté en uso). Para cada conmutación, la nueva unidad activa envía un syslog por cada razón.

    Por ejemplo:

    Switching to ACTIVE (cause: no power detected from other side).

    Otros motivos:

    • “maestro normal”

    • “sin cable de conmutación por error”

    • "no se detectó energía del otro lado"

    • "no se puede hablar con el otro lado"

    • "interfaz de línea con fallo en el otro lado"

    • “no considerar el cambio del recuento de tráfico”

    • "el otro lado no solicita el cambio de control"

    • "fallo notificado por el otro lado"

    • “prueba de estado”

    • “configurado por el comando ioctl cmd”

  5. ¿Qué mantenimiento se requiere?

    Use el comando show fail para supervisar el estado de las dos unidades. Los syslogs se generan cuando se producen errores o conmutaciones.

  6. ¿Cómo se inhabilita la conmutación por error?

    Retire el cable de conmutación por error de la unidad y, a continuación, configúrelo con el comando no failover. El software para la conmutación por error detecta la ausencia del cable y desactiva la conmutación por error automáticamente.

  7. ¿En qué consiste el agrupamiento de conmutación por error?

    PIX-5XX-FO-BUN, consiste en un chasis, software y dos puertos de 10/100. Los clientes no necesitan comprar software coincidente para PIX 515. Este paquete incluye software PIX sin restricciones. Esta unidad se utiliza exclusivamente para la conmutación por error. Asegúrese de usar el comando write memory en la unidad de conmutación por error para guardar la información. Si no se guarda la configuración y se recarga la unidad inactiva, la unidad pierde la configuración copiada desde la unidad primaria.

Información para recopilar si abre un Caso de soporte técnico

Si aún necesita ayuda después de cumplir los pasos para la resolución de problemas de su PIX Firewall y desea abrir un caso en Soporte técnico, no olvide incluir la siguiente información para la resolución de problemas de su PIX Firewall.

  • Descripción del problema y detalles relevantes de la topología

  • Resolución de problemas realizada antes de abrir el caso

  • Resultado del comando show tech-support (de ambos firewall, primario y secundario)

  • Resultado del comando show log después de la ejecución del comando logging buffered debugging o capturas de consola que muestran el problema (si están disponibles)

Adjunte los datos recopilados a su caso en un texto sin formato (.txt), sin compactar. Puede vincular información a su caso transfiriéndola mediante la herramienta Case Query (solamente clientes registrados) . Si no puede entrar en la herramienta Case Query y desea adjuntar información pertinente a su caso, puede enviarla como documento adjunto de un correo electrónico a attach@cisco.com, recuerde escribir el número de su caso en el asunto del mensaje.‘


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 5220