Seguridad : Dispositivos de seguridad Cisco PIX de la serie 500

Cómo el Failover trabaja en el Cisco Secure PIX Firewall

25 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Traducción Manual (22 Abril 2008) | Inglés (22 Abril 2015) | Comentarios


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


Contenido


Introducción

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

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no se restringe a las versiones de software específicas. Todos los modelos de PIX soportan la Conmutación por falla excepto 501 y los modelos 506E.

Nota: Este documento no cubre las versiones de software 7.0 y después el Dispositivos de seguridad Cisco PIX de la serie 500. Refiera al capítulo de la Conmutación por falla que configura de la guía de configuración CLI del dispositivo del Cisco Security, versión 7.0.

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

Convenciones

Consulte Convenciones de Consejos Técnicos de Cisco para obtener más información sobre las convenciones sobre documentos.

Antecedentes

Se considera que un PIX es la unidad “Activa” mientras que el otro es la unidad “En espera”. Mientras que el nombre implica, la unidad activa realiza las funciones de la red normal mientras que los monitores de la unidad de reserva, alistan para tomar el control si la unidad activa no puede realizar sus funciones. Si el comando show version no le muestra que la Conmutación por falla está habilitada e intenta hacer la Conmutación por falla, entre en contacto a su equipo de cuenta Cisco local para comprar una actualización de la licencia.

Para más información sobre la actualización de la licencia, refiera a la actualización de la llave de la licencia en las pares de fallas.

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 es determinada por la unidad que tiene el final del “primario marcada cable con fallas” conectado en ella, o el PIX que se configura con el comando failover lan unit primary. Este comando se introduce en el PIX OS de la versión 6.2. La unidad en espera utiliza la dirección IP de la Conmutación por falla y las direcciones MAC de la unidad secundaria. Si ocurre un intercambio, las unidades intercambian la dirección IP y las direcciones MAC que utilizan para substituir la presencia de cada uno en la red. Esta acción es invisible para la red. El IP a las relaciones de la dirección MAC sigue siendo exactamente lo mismo. Por lo tanto, ningunas tablas ARP en la red necesitan medir el tiempo hacia fuera o ser cambiadas. Ningún otro equipo de la red necesita saber acerca de la redundancia o que se produjo una conmutación. Observe que el sistema IP y los IP Addresses de la Conmutación por falla deben estar en la misma subred, tan hay la posibilidad que no pudo haber un router entre las dos unidades.

Cable failover

El cable con fallas es el único hardware adicional requerido para apoyar a la falla PIX. En PIX 6.2 y posteriores, usted también puede lograr una conmutación por error con o sin un cable de respaldo. El cable de transmisión por falla es un cable de link serial RS-232 modificado con una velocidad configurada de 9600 baudios.

Nota: En el software PIX versión 5.2 (5.1.2.201), la velocidad se cambia al baudio 115.2 K. También, el cable con fallas no puede ser extendido.

La comunicación básica de fallas está a través del cable con fallas o a través de la interfaz LAN que se configura con el comando failover lan interface interface_name en el PIX OS de la versión 6.2 y posterior. La comunicación de fallas a través del cable con fallas mensaje-se basa y necesita ser confiable. Cada mensaje enviado es reconocido (ACKed). Si un mensaje no es acked por el otro PIX en tres segundos, se retransmite el mensaje. Después de cinco retransmisiones sin un ACK (por un total de 15 segundos), una condición de la Conmutación por falla es accionada por el PIX en espera.

Entre las fallas más comunes de comunicación a través del cable de fallas se encuentran:

  • Intercambio de direcciones MAC

  • Saludo (una señal de mantenimiento)

  • Estado (Activo/En espera)

  • Estado de link de red

  • Réplica de la configuración

Replique la configuración PIX

Las dos unidades deben tener la misma configuración exacta y deben funcionar con la misma versión de software. Esto se logra fácilmente, puesto que la réplica de la configuración ocurre sobre el cable con fallas, o de la interfaz LAN configurada con el comando failover lan interface interface_name, de la unidad activa a la unidad en espera de estas 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 usted utiliza un cable con fallas porque usted necesita la configuración inicial en ambas las unidades primarias y secundarias para identificarlas como unidades primarias y secundarias. Esta función fue introducida para superar la longitud y velocidad del cable serial.

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

  • Cuando usted ingresa el comando write standby en la unidad activa, usted fuerza la configuración completa a la memoria en la unidad en espera.

La replicación de la configuración realiza una copia de "memoria a memoria". Una vez que esto completa, usted necesita publicar un 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 tomar un rato para transferir. Si un intercambio ocurre durante la replicación, el nuevo PIX activo tiene solamente 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 reiteració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.

Monitoreo de Failover

Hay un intervalo de consulta de fallas de 15 segundos (después de que la versión 5.0 él es configurable) para monitorear la actividad de la red, las comunicaciones de fallas, y el estado de la energía. Un error de ninguno de estos parámetros en la unidad activa hace la unidad en espera tomar el control activo. Cada vez que se determina que ha fallado una unidad, ésta cierra sus interfaces de red.

Las dos unidades envían a la falla especial “hola” paquetes el uno al otro sobre el cable con fallas y todas interconectan cada 15 segundos (excluye los que sean administrativo apaguen). Si cualquier unidad no oye “hola” en una interfaz para dos verificaciones de sondeo consecutivas, el PIX pone que interfaz LAN en el modo de prueba para determinar donde miente el incidente. Si un PIX en espera no recibe “hola” del cable con fallas para dos verificaciones de sondeo consecutivas, el PIX en espera inicia un intercambio y declara el otro PIX fallado. 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 la red es no intrusa. Esto significa que mientras que está en el modo de prueba, todavía intenta pasar el tráfico normal. El proceso de prueba consiste en cuatro pruebas individuales (prueba de estado, Prueba de actividad de la red, prueba del Protocolo de resolución de direcciones (ARP) y prueba de ping NIC) adaptadas hacia el stimluation del tráfico de la red. Si una interfaz que está en el modo de prueba puede recibir el tráfico, se considera operativo. Si puede oír el otro tráfico de la red, se asume que el error debe estar con la otra unidad no capaz de enviar “hola” el paquete. Esto da lugar a fallar la otra unidad. Si se determina que la unidad de prueba no puede recibir el tráfico de la red mientras que puede la otra, la unidad de prueba se 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 respaldo. El cable de failover 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 el poder, la unidad en espera asume el control en el plazo de 15 segundos. Una unidad en estado “fallido” espera 15 segundos y luego trata de pasar al estado “en espera”. Si la transición desencadena una falla, la unidad volverá a fallar. Usted puede utilizar el comando failover reset para reajustar manualmente el PIX del fallado al estado espera. Si la transición desencadena una falla, la unidad volverá a fallar. Un PIX en estado fallido no puede cambiar a estado activo.

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

Nota:  Refiera a configurar la Conmutación por falla para información detallada sobre las características de la Conmutación por falla de la versión de PIX 7.0.

Conmutación por recuperación

Siempre que ocurra un error o un Switch, se generan los mensajes de Syslog que indican qué sucedió. 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 principal defectuosa se repara y se trae detrás en la línea, no reanuda automáticamente como la unidad activa. Para forzar una unidad para ser la unidad activa, utilice el comando failover active en la unidad en espera o el comando no failover active en la unidad activa. Si utilizan a la falla de estado, después la información de estado de la 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 después de un intercambio. 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 fallas de 15 segundos se cambia para ser configurable. El intervalo se puede fijar entre 3 a 15 segundos, reconociendo la variación en la detección del error de diversas placas de interfaz.

Prueba de interfaces

En el evento “hola” los paquetes no se reciben en una interfaz, o las esperas de una interfaz para “hola” más de 2.5 minutos después de que la otra interfaz entró el estado normal, la interfaz se ponen en el modo probando (si la interfaz no es apagar y el estado de link está para arriba). Cuando esto ocurre, se informa a la otra unidad a través del cable de transmisión de falla que la interfaz se encuentra en modo de prueba. Mientras que una interfaz está en el modo de prueba, el tráfico normal puede fluir, con tal que funcione la interfaz correctamente. Se comienza la prueba solamente si una condición de error ha ocurrido y por lo tanto se basa en la idea que “si soy aceptable, después usted debe ser fallado.” La prueba consiste en cuatro pruebas consecutivas:

  1. Prueba de estado NIC

    Esta prueba es un control de link ascendente/descendente del NIC mismo. Si una placa de interfaz no está conectada en una red en funcionamiento, se considera fallado.

  2. Prueba de actividad de la red

    Esta prueba es “una prueba de la actividad de la red recibida”. Las unidades 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 recientemente adquiridas. Entonces, uno a la vez, la unidad envía los pedidos ARP a estas máquinas, en un intento por 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, una solicitud ARP es enviada a la máquina siguiente. Si en el extremo de la lista no se ha recibido ningún tráfico, la unidad realiza la prueba de ping.

  4. Prueba de ping

    Para realizar la prueba de ping, la unidad envía un pedido de ping de broadcast. 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 final de cada prueba, las en primer lugar controles de la unidad de prueba para ver si ha recibido algún tráfico. Si es así se considera operativo y falla la otra unidad. 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 peticionante no escucha los resultados de la prueba de la otra unidad, se considera que existe una falla en la otra unidad, de la misma manera que si no escuchó el mensaje de saludo a través del cable de falla. Si se detecta una falla 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 son enviados con el Syslog por ambas las unidades activas y en espera.

Tabla de decisión de hardware

En cada PIX, la Conmutación por falla mantiene una tabla de decisiones del hardware (HDT) de ambos dispositivos PIX para decidir a qué PIX es el dispositivo activo adecuado. Cuando se produce un cambio de estado en la interfaz NIC, se produce un sondeo de fallas de la unidad del dispositivo, se actualiza el HDT local y el cambio se envía a otra PIX. Aunque las tablas HDT se comparan en cada ciclo de interrogación, es la segunda encuesta que puede hacer a un recurso seguro usurpar el control del active iniciando el intercambio.

Falla operativa en entornos conmutados

Hay dos problemas a dirigir en los entornos conmutados. Primero, las necesidades del Switch de aprender que un MAC Address determinado se ha movido a partir de un puerto a otro. Cada unidad (a menos que se falla la unidad) transmite una serie de mensajes de falla en cada interfaz con el uso de su nuevos MAC y IP Addresses. Esto permite que el Switch ponga al día sus tablas MAC internas. Cisco recomienda fuertemente que los clientes habilitan el portfast en todos los puertos del switch que conecten con las interfaces PIX. Además, canalización y necesidad del enlace de ser inhabilitado en estos puertos. Así, si la interfaz del PIX va abajo durante la Conmutación por falla, el Switch no tiene que esperar 30 segundos mientras que las transiciones de puerto de escuchar el aprendizaje al estado de reenvío.

Este bloqueo del tráfico de la red nos lleva al segundo problema. Si “hola” los paquetes que son enviados por la Conmutación por falla no consiguen remitidos, cada unidad piensa que algo es mal y que comienza a probar sus interfaces. Esto da lugar al error de una unidad porque son los resultados de la prueba “si soy aceptable, después usted debe ser fallado.” Para conseguir alrededor de este problema, cualquier momento ocurre un intercambio, las unidades ingresan a un estado en espera. En este tráfico de la red del estado está libre de atravesar la unidad activa, pero las esperas de la Conmutación por falla para que dos “hola” mensajes sean recibidos antes de que monitoree las interfaces otra vez. Esto permite que el Switch ingrese a un estado de bloqueo sin la Conmutación por falla de interrupción. Una vez que se oye el segundo mensaje de saludo, la Conmutación por falla 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.

Stateful Failover

Sin la retención de la información stateful PIX, después de un intercambio, se caen todas las conexiones existentes y la aplicación se requiere para reinitiate. En la versión del software PIX 5.0, el PIX proporciona a la falla de estado de modo que una conexión existente pueda permanecer para arriba después de un intercambio.

Para apoyar a la falla de estado, una interfaz del LAN dedicado entre los dos dispositivos PIX se requiere. El logical update (LU) es el módulo de software que proporciona el transporte a las aplicaciones PIX que apoyan a la falla de estado. La actualización de estado ocurre del modo activo al modo en reserva a través de la interfaz LAN. La actualización del estado enviada al PIX en espera es accionada 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. Sin embargo, el protocolo LU es en tiempo real, y proporciona la notificación de error y los informes que faltan las actualizaciones del estado para monitorear los propósitos.

Se realiza la sincronización de estado inicial luego de la réplica de la configuración. Esto se logra explorando los registros de las tablas de traducción y conexión. Después de ese, una actualización del estado puede ser accionada.

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 falla no puede programarse previamente, la actualización de estado para la conexión se basa en el paquete. Esto significa los pasos de cada paquete con el PIX y cambia el estado de una conexión, que puede accionar una actualización del estado.

Se transfieren las tablas de estado TCP. Sin embargo, por abandono el HTTP (puerto TCP 80) no se replica. En la versión 6.0 y posterior, usted puede utilizar el HTTP de la réplica del comando failover para aplicar la replicación del estado del puerto TCP 80. La mayoría de las tablas de estado UDP no se transfieren, a excepción de los puertos dinámicamente abiertos que corresponden a los protocolos de varios canales tales como H.323 y VoIP. Por lo tanto, las resoluciones DNS no se transfieren pues es un puerto del solo canal.

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

Nota: No hay lista amplia de aplicaciones que se puedan caer debido al tiempo que toma para que el recurso seguro asuma el control. Una buena regla práctica es esperar que el recurso seguro tarde 10 segundos para asumir el control el usar de la falla de estado. Sin la falla de estado puede tomar hasta un minuto para restablecer las conexiones.

Nota: La única advertencia sobre la falla de estado es qué causa la Conmutación por falla. Si usted tiene Conmutación por falla hola fijada al máximo de 15 segundos y la interfaz interior va mala, después el recurso seguro no declara que el primario ha fallado hasta que falte por lo menos dos hellos, 30 segundos. Algunas personas fijan el hellos de la Conmutación por falla al mínimo de 3 segundos pero por otra parte el PIX puede Conmutación por falla innecesariamente. Cisco recomienda que usted fija hola al máximo de 15 segundos.

Comandos failover

  • [no] failover - Habilita o deshabilita 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 recuperación ante alguna falla.

  • reinicio de fallas - Borra al estado fallido de las unidades y recomienza la Conmutación por falla.

  • [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 de estado.

  • segundos del sondeo de fallas - Especifica el intervalo de consulta de fallas (versión de software PIX 5.2 y posterior).

  • unidad LAN primaria de la Conmutación por falla | secundario - Utilizado en la Conmutación por falla basado en LAN para definir primario/secundario (versión de PIX 6.2 y posterior).

  • permiso lan de la Conmutación por falla - Especifica la Conmutación por falla basado en LAN (versión de PIX 6.2 y posterior).

  • lan_if_name de la interfaz lan de la Conmutación por falla - El nombre de la interfaz de escudo de protección dedicó a la Conmutación por falla basado en LAN (versión de PIX 6.2 y posterior).

  • key_secret de la clave lan de la Conmutación por falla - Habilita la encripción y autenticación de los mensajes de falla basado en LAN entre los Firewall PIX usando la clave secreta (versión de PIX 6.2 y posterior).

  • stn_mac del act_mac del mif_name del MAC address de la Conmutación por falla - Le permite para configurar una dirección MAC virtual para las pares de fallas del firewall PIX en vez de entrar en contacto al otro par para conseguir la dirección MAC (versión de PIX 6.2 y posterior).

Ejemplo de salida del comando show failover

Estos ejemplos presuponen que el cable de transmisión por fallas 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 por error 192.168.89.2.

Ejemplo: Falla normal

Este ejemplo es la salida normal del comando show failover. Observe que se muestra la dirección IP de cada unidad. Si no se ha ingresado 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". Vea el ejemplo: El control de fallas no ha comenzado la sección para 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 fallas

Este los ejemplos demuestran qué sucede cuando la Conmutación por falla no ha comenzado a monitorear las interfaces de la red. El failover no comienza a monitorear las interfaces de red hasta haber escuchado el segundo paquete "hello" de la otra unidad en esa interfaz. Esto tarda cerca de 30 segundos. Si la unidad se asocia a un switch de red que ejecuta Spanning-Tree Protocol (STP), este tarda el doble del tiempo de “demora de reenvío” configurado en el switch (configurado típicamente como 15 segundos), más esta demora de 30 segundos. Esto ocurre porque en el inicio del PIX y en el evento de falla que continúa inmediatamente, el switch de red detecta un loop de puente temporal. Al detectar este loop, deja de enviar paquetes en estas interfaces durante el tiempo de “demora de reenvío”. Entonces ingresa al modo escuchar por un tiempo adicional del “retardo de reenvío”, mientras tanto el Switch está atento los Bridge Loop pero no el tráfico de reenvío (y así el envío de la Conmutación por falla “hola” paquetes). Después dos veces del tiempo de retardo de reenvío (30 segundos), el tráfico reanuda el fluir. 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. El resto del monitoreo de failover sigue teniendo lugar (es decir, Power, Interface Loss of Link y Failover Cable "hello").

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: Falla en la Unidad

En este ejemplo, la Conmutación por falla detecta un error. Observe que la Interfaz 1 en la unidad primaria es el origen de la falla. Las unidades vuelven al modo "en espera" debido a la falla. La unidad defectuosa se ha quitado de la red (las interfaces están abajo) y envía no más “hola” los paquetes en la red. Sigue habiendo la unidad activa en un estado en espera hasta que se substituya la unidad defectuosa y las comunicaciones de fallas comienzan otra vez.

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: Stateful Failover

Este ejemplo muestra la salida del comando show failover con la falla de estado habilitada. Observe que la “frecuencia de interrogación 4 segundos” está visualizada. La interfaz de red número 4 se encuentra administrativamente cerrada. La interfaz de la red FailLink es el link de la falla de 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 fallas en la Guía de configuración para el firewall PIX.

Si usted tiene la salida de un comando show failover de su dispositivo de Cisco, usted puede utilizar el Output Interpreter (clientes registrados solamente) para visualizar los problemas potenciales y los arreglos.

Conmutación por error basada en LAN

Diagrama de falla basado en la red LAN

/image/gif/paws/5220/failover_01.gif

Se recomienda que usted conecta el primario y los PIXe secundarios con un switch dedicado. No utilice los cables de par cruzados. En este diagrama, un Cisco Catalyst 3500 Switch conecta el primario y los PIXe secundarios. Los links de la falla de LAN y de la falla de estado están en diversos VLA N, VLAN10 y VLAN20, 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

Éstos son los comandos mínimos que necesitan ser configurados en el PIX principal:

Comandos básicos

pixfirewall(config)#hostname PIX                                

!--- Naming the PIX is optional.

PIX(config)#nameif ethernet2 fo security20                 

!--- Naming the interface is optional. It is recommended that you
!--- hardcode the speed/duplex.
 
PIX(config)#interface ethernet2 100full                            

!--- Bring up the interface.
 
PIX(config)#ip address fo 192.168.1.1 255.255.255.0  

!--- Assign an IP address.

Comandos failover

PIX(config)#failover ip address fo 192.168.1.2

!--- IP address for the failover link.

PIX(config)#failover lan unit primary                

!--- This unit is primary
. 
PIX(config)#failover lan interface fo                 

!--- The 'fo' interface is used for LAN failover. 

PIX(config)#failover lan key cisco                     

!--- The Pre-shared key.

PIX(config)#failover lan enable                          

!--- Enables failover.

PIX(config)#failover                                 

!--- Start the failover process.

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

Éstos son los comandos mínimos que necesitan ser configurados en el PIX secundario:

Comandos básicos

pixfirewall(config)#hostname PIX 
PIX(config)#nameif ethernet2 fo security20

!--- It is recommended that you hardcode the speed/duplex. 
 
PIX(config)#interface ethernet2 100full
PIX(config)#ip address fo 192.168.1.1 255.255.255.0 

Comandos failover

PIX(config)#failover ip address fo 192.168.1.2 
PIX(config)#failover lan unit secondary                    

!--- This unit is secondary. 

PIX(config)#failover lan interface fo 
PIX(config)#failover lan key cisco 
PIX(config)#failover lan enable 
PIX(config)#failover

!--- This unit is secondary because the "active" keyword is not used.

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

LAN-based Failover: trying to contact peer?? 
LAN-based Failover: Send hello msg and start failover monitoring 

Entonces, en el PIX principal, estos mensajes aparecen en la consola:

LAN-based Failover: Peer is UP
Sync Started
Sync Completed

Nota: Si usted no ve estos mensajes, después hay algo mal. Para resolver problemas rápidamente el problema, gire los debugs de la traza ICMP en la unidad secundaria usando el comando debug icmp trace y el ping de la unidad primaria a la dirección IP de la Conmutación por falla.

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 this command before you initiate 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 usted no puede hacer ping con éxito, marque el VLA N y las configuraciones del puerto en el Switch intermedio. También aseegurese que usted utiliza los cables confiables del CAT 5.

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   

!--- The failover serial cable is not used.
  
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.

!--- Stateful failover is not configured yet. 

  

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

PIX secundario hecho salir:

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           

!--- A failover serial cable is not used. 

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. 

!--- Stateful failover is not configured yet. 

  

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

Configuración restante – Falla de estado

El trabajo básico sobre el primario y los PIXe secundarios es completo.

En este ejemplo, la interfaz E3 se utiliza para llevar la información del estado entre las dos unidades. Usted puede utilizar el para este propósito de la interfaz E2 (que se utiliza para la revisión médica y la réplica de la configuración) también, si su PIX no se carga pesadamente. Se recomienda utilizar una interfaz distinta para este propósito.

En el PIX principal, configure estos 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 esto:

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

Marque el estatus.

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 del Logical Update de la falla de 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 principal.

  1. Asigne un código inalterable a la velocidad/dúplex de otras interfaces. Usted puede utilizar el “auto,” solamente recomendó que usted pone en hard-code la velocidad/el duplex.

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

    ip address outside 1.1.1.1 255.255.255.0 
    ip address inside 10.10.10.1 255.255.255.0
    
  3. Agregue el comando failover ip address para todas las interfaces excepto aquellas que están cerradas:

    failover ip address outside 1.1.1.2
    failover ip address inside 10.10.10.2
    

Otras configuraciones en el PIX secundario

Éste es cómo configurar el PIX secundario.

  1. Asigne un código inalterable a la velocidad/dúplex de otras interfaces. Usted puede utilizar el “auto,” solamente recomendó que usted pone en hard-code la velocidad/el duplex.

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

    ip address outside 1.1.1.2 255.255.255.0 
    ip address inside 10.10.10.1 255.255.255.0 
    

Esto se hace salir del PIX secundario después de que ocurra la Conmutación por falla.

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 

Continúe configurando la unidad primaria, y la configuración será replicada a la unidad secundaria automáticamente.

Preguntas Frecuentes

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

    El valor por defecto para la Conmutación por falla está apagado (ninguna Conmutación por falla). Sin embargo, si el cable con fallas está conectado en una unidad en el tiempo del inicio, la Conmutación por falla detecta automáticamente el cable y gira la Conmutación por falla y fija el estatus de la unidad a primario o a secundario. Esto es verdad en el tiempo del inicio incluso si los IP Addresses de la Conmutación por falla no se configuran correctamente.

    Nota: Si el cable está instalado a un funcionamiento PIX, usted debe publicar el failover command start failover. Para el software PIX más adelante que la versión 4.4.3, esto puede ser cambiada. Esto es porque la réplica de la configuración puede inhabilitar accidentalmente la Conmutación por falla con el comando clear config. Si el cable con fallas no está presente en el tiempo del inicio, la unidad se convierte en inmediatamente la unidad activa. Sin embargo, la unidad muestra como “secundario.”

    Estas discusiones asumen que la Conmutación por falla está habilitada y que ambas unidades tienen el cable con fallas enchufado. Cuando una unidad primero inicia, habilita la Conmutación por falla y omite el recurso seguro si el poder se detecta de la otra unidad. La unidad envía el estado de tiempo de ejecución (espera) y pide una dirección MAC de la otra unidad. Si ninguna unidad ha tomado el control activo dentro del tiempo de sondeo de fallas, la unidad cambia al estado activa.

    Nota: Para las versiones de software PIX anterior de 5.2.1, el tiempo de sondeo de fallas fueron cifrados difícilmente 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 comienza la comunicación por cable de fallas, ambas unidades marcan 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 fallas de cada una, la unidad primaria se convierte en activa. Si el secundario es ya activo, la unidad primaria sigue siendo recurso seguro (asuma que el secundario aprendió el MAC Address primario antes. La unidad primaria no toma automáticamente el control activo. 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 arranca sin el cable con fallas, o no hay comunicación de fallas a través del cable con fallas, ambas unidades pueden convertirse en active y se interrumpe el tráfico de la red.

    Con la Conmutación por falla habilitada, la replicación de configuración total ocurre de la unidad activa a la unidad en espera cuando la unidad en espera primero arranca. A partir de este momento, los comandos pasan de activo a en espera a medida que son ingresados. Para forzar una réplica total de la configuración, utilice el comando write standby. La réplica de la configuración sólo ocurre desde la unidad activa a la de en espera. Los comandos ingresados en la unidad inactiva no se duplican en la unidad activa. Cuando ingresa comandos a 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 falla

    La detección de falla se basa encendido:

    1. Estado de la Tarjeta de interfaz de la red (NIC). Si el estado de link de un NIC está abajo, la unidad falla. “Abajo” significa que el NIC no está conectado 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 envían “hola” los paquetes el uno al otro sobre todas las interfaces de la red. Si no se oye ningunos “hola” paquetes en 30 segundos, la interfaz agresora se pone en el modo de prueba para determinar quién es culpable.

    3. Comunicación por cable de conmutación por error. Las dos unidades se enviaron mensajes de saludo mutuamente a través del cable de falla. Si el recurso seguro no oye del active en el plazo de 30 segundos, y el estado de cable es AUTORIZACIÓN, el recurso seguro asume el control como active.

      Asimismo, si los comandos failover 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:

      • Una falla 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 a esto ocurre 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 respaldo, se activan y crean una dirección IP duplicada con diferentes direcciones MAC, lo que produce un conflicto en la red. El cable failover debe instalarse para que la detección de fallos funcione correctamente.

  3. ¿Cuánto tiempo toma para detectar un error con los valores predeterminados del intervalo de encuesta?

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

    • Los errores de las comunicaciones de fallas se detectan con 30 segundos.

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

  4. ¿Qué sucede cuando se acciona la Conmutación por falla?

    Cualquier unidad puede iniciar una conmutación. Cuando ocurre un Switch, las unidades cada cambio sus estados así como la dirección IP y las direcciones MAC que utilizan. Desde el punto de vista de la red, el estado en espera de forma transparente substituye previamente la unidad activa. Porque la configuración es ya completa en el recurso seguro, ningunas actualizaciones necesitan ser hechas. Puesto que las dos unidades no comparten al estado de la conexión dinámica. Cualquier conexión activa será caída cuando ocurre una Conmutación por falla. Los clientes deben reestablecer las conexiones a través de la unidad ahora activa (a menos que la falla de 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).

    Otras razones:

    • “master normal”

    • “ningún cable con fallas”

    • “ningún poder detectado del otro lado”

    • “incapaz de hablar con el otro lado”

    • “interfaz de línea fallada en el otro lado”

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

    • “el otro lado quisiera que asumiera el control”

    • “fall señalado por el otro lado”

    • “prueba de estado”

    • “fije por el cmd del ioctl”

  5. ¿Qué mantenimiento se requiere?

    Utilice el comando show fail de monitorear el estatus de las dos unidades. Los syslogs se generan cuando se producen errores o conmutaciones.

  6. ¿Cómo se deshabilita failover?

    Retire el cable failover de la unidad y luego 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 errores?

    PIX-5XX-FO-BUN, consiste en un chasis, software, y dos puertos de 10/100. Los clientes no necesitan comprar el software que corresponde con para el PIX 515. Este conjunto incluye el software PIX sin restricciones. Esta unidad se utiliza estrictamente para la Conmutación por falla. Asegúrese de usar el comando write memory en la unidad failover 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 que debe Obtener si Abre un Caso de Soporte Técnico

Si usted todavía necesita la ayuda después de seguir los pasos de Troubleshooting arriba y quiere abrir un caso con el Soporte técnico, esté seguro de incluir la siguiente información para localizar averías su firewall PIX.
  • Descripción del problema y detalles relevantes de la topología
  • Trobleshooting realizado antes de abrir el caso
  • Salida del comando show tech-support (de los Firewall primarios y secundarios)
  • Resultado del comando show log después de la ejecución con el comando logging buffered debugging o capturas de consola que muestran el problema (si están disponibles)
Adjunte los datos recolectados 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 (sólo para clientes registrados) . Si usted no puede acceder la herramienta del Case Query, usted puede enviar la información en un elemento adjunto de correo electrónico a attach@cisco.com con su número de caso en los asuntos de su 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.


Información Relacionada


Document ID: 5220