Introducción

Este documento describe algunos de los problemas comunes con el clúster entre sitios de modo transparente de EtherChannel expandido.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Firewall Adaptive Security Appliance (ASA)
• Clustering ASA

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

A partir de la versión 9.2 de ASA, se admite la agrupación en clúster entre sitios, en la que las unidades ASA pueden ubicarse en diferentes Data Centers y el enlace de control de clúster (CCL) está conectado a través de una interconexión de Data Center (DCI). Los escenarios de implementación posibles son:

•  Clúster entre sitios de interfaz individual
•  Clúster entre sitios en modo transparente de EtherChannel expandido
•  Clúster entre sitios en modo de routing EtherChannel extendido (compatible a partir de 9.5)

Notificaciones de MAC MOVE

Cuando una dirección MAC en la tabla Content Addressable Memory (CAM) cambia de puerto, se genera una notificación MAC MOVE. Sin embargo, no se genera una notificación MAC MOVE cuando se agrega o se elimina una dirección MAC de la tabla CAM. Suponga que si una dirección MAC X se aprende a través de la interfaz GigabitEthernet0/1 en VLAN10 y después de algún tiempo la misma MAC se ve a través de GigabitEthernet0/2 en VLAN 10, entonces se genera una notificación MAC MOVE.

Registro del sistema desde el switch:

NEXUS7K %L2FM-4-L2FM_MAC_MOVE: Mac 000c.8142.2600 in vlan 10 has moved from GigabitEthernet0/1 to GigabitEthernet0/2

Syslog de ASA:

ASA-4-412001: MAC 003a.7b58.24c5 moved from DMZ to INSIDE

Diagrama de la red

Implementación de clúster entre sitios en la que los ASA se configuran en modo de puente transparente entre VLAN 1535 y VLAN 35. La VLAN 35 interna se extiende sobre Overlay Transport Virtualization (OTV), mientras que la VLAN 1535 externa no se extiende sobre OTV, como se muestra en la imagen

Notificaciones de movimiento de MAC en el switch

Escenario 1

Tráfico destinado a una dirección MAC cuya entrada no está presente en la tabla MAC del ASA, como se muestra en la imagen:

En un ASA transparente, si la dirección MAC de destino del paquete que llega al ASA no está en la tabla de direcciones MAC, envía una solicitud de protocolo de resolución de direcciones (ARP) para ese destino (si está en la misma subred que BVI) o una solicitud de protocolo de mensajes de control de Internet (ICMP) con tiempo de vida 1 (TTL 1) con MAC de origen como la dirección MAC de interfaz virtual de puente (BVI) y la dirección MAC de destino como controlador de acceso de medios de destino (DMAC) se pierde.

En el caso anterior, tiene estos flujos de tráfico:

1. El router ISP del Data Center 1 reenvía el tráfico a un destino específico que se encuentra detrás del ASA.
2. Cualquiera de los ASA puede recibir el tráfico y, en este caso, ASA no conoce la dirección MAC de destino del tráfico.
3. Ahora, la IP de destino del tráfico está en la misma subred que la de la BVI y, como se mencionó anteriormente, ASA ahora genera una solicitud ARP para la IP de destino.
4. El switch 1 recibe el tráfico y, dado que la solicitud es una transmisión, reenvía el tráfico al Data Center 2, así como a través del enlace OTV.
5. Cuando el Switch 2 ve la solicitud ARP del ASA en el link OTV, registra una notificación MAC MOVE porque anteriormente la dirección MAC del ASA se aprendía a través de la interfaz conectada directamente y ahora se aprende a través del link OTV.

Recomendaciones

Es un escenario de esquina. Las tablas MAC están sincronizadas en clústeres, por lo que es menos probable que un miembro no tenga una entrada para un host determinado. Un movimiento MAC ocasional para BVI MAC propiedad del clúster se considera aceptable.

Escenario 2

Procesamiento de flujo centralizado mediante ASA, como se muestra en la imagen:

El tráfico basado en inspección a través de un clúster ASA se clasifica en tres tipos:

• Centralizado
• Distribuido
• Semidistribuido

En el caso de la inspección centralizada, todo el tráfico que deba inspeccionarse se redirige a la unidad principal del clúster ASA. Si una unidad secundaria del clúster ASA recibe el tráfico, se reenvía a la principal a través de CCL.

En la imagen anterior, se trabaja con tráfico SQL que es un protocolo de inspección centralizada (CIP) y el comportamiento descrito aquí es aplicable a cualquier CIP.

Recibirá el tráfico en el Data Center 2, donde solo tiene unidades secundarias del clúster ASA; la unidad principal se encuentra en el Datacenter 1, que es el ASA 1.

1. El router ISP 2 del Data Center 2 recibe el tráfico y lo reenvía a los ASA de su sitio.
2. Cualquiera de los ASA puede recibir este tráfico y una vez que determina que este tráfico debe ser inspeccionado y a medida que el protocolo se centraliza reenvía el tráfico a la unidad primaria a través de CCL.
3. ASA 1 recibe el flujo de tráfico a través de CCL, procesa el tráfico y lo envía a SQL Server.
4. Ahora, cuando ASA 1 reenvía el tráfico en sentido descendente, conserva la dirección MAC de origen original del Router ISP 2 que se encuentra en el Datacenter 2 y lo envía en sentido descendente.
5. Cuando el Switch 1 recibe este tráfico específico, inicia sesión en una notificación MAC MOVE porque originalmente ve la dirección MAC del Router ISP 2 a través del link OTV que está conectado al Datacenter 2 y ahora ve el tráfico que entra desde las interfaces conectadas al ASA 1.

Recomendaciones

Se recomienda enrutar las conexiones centralizadas a cualquier sitio que aloje el principal (según las prioridades), como se muestra en la imagen:

Escenario 3

Para una comunicación entre controladores de dominio (DC) en modo transparente, este flujo de tráfico específico no está cubierto ni documentado, pero este flujo de tráfico específico funciona desde un punto de vista de procesamiento de flujo ASA. Sin embargo, puede dar lugar a notificaciones de movimiento de MAC en el switch. 

1. El Host 1 en la VLAN 35 intenta comunicarse con el Host 2 que está presente en el otro Datacenter.
2. El Host 1 tiene una gateway predeterminada que es el Router 1 y el Router 1 tiene una trayectoria para alcanzar el Host 2 al poder comunicarse con el Router 2 directamente a través de un link alternativo y en este caso asumimos Multiprotocol Label Switching (MPLS) y no a través del clúster ASA.
3. El Router 2 recibe el tráfico entrante y lo rutea hacia el Host 2.
4. Ahora, cuando el host 2 responde, el router 2 recibe el tráfico de retorno y encuentra una ruta conectada directamente a través de los ASA en lugar del tráfico que envía a través de MPLS. 
5. En esta etapa, el tráfico que sale del Router 2 tiene la MAC de origen de la interfaz de salida del Router 2.
6. Los ASA del Data Center 2 reciben el tráfico de retorno y encuentran una conexión que existe y que es realizada por los ASA del Data Center 1.
7. Los ASA del Data Center 2 envían el tráfico de retorno a través de CCL a los ASA del Data Center 1.
8. En esta etapa, los ASA en el centro de datos 1 procesan el tráfico de retorno y lo envían hacia el switch 1. El paquete todavía tiene la misma MAC de origen que la interfaz de salida del router 2.
9. Ahora, cuando el Switch 1 recibe el paquete, registra una notificación de movimiento de MAC porque inicialmente aprendió la dirección MAC del Router 2 a través de la interfaz que está conectada al link OTV, sin embargo en esta etapa comienza a aprender la dirección MAC de la interfaz conectada a los ASA.
   
   

Situación 4

Tráfico generado por ASA, como se muestra en la imagen:

Este caso específico se observará para cualquier tráfico generado por el propio ASA. Aquí se consideran dos situaciones posibles, en las que el ASA intenta alcanzar un protocolo de tiempo de red (NTP) o un servidor Syslog, que están en la misma subred que la de su interfaz BVI. Sin embargo, no solo está limitado a estas dos condiciones, esta situación puede ocurrir siempre que el ASA genere tráfico para cualquier dirección IP que esté conectada directamente a las direcciones IP BVI.

1. Si ASA no tiene la información ARP del servidor NTP/servidor Syslog, el ASA generará una solicitud ARP para ese servidor.
2. Dado que la solicitud ARP es un paquete de difusión, el Switch 1 recibirá este paquete de su interfaz conectada del ASA y lo inundará a través de todas las interfaces en la VLAN específica, incluido el sitio remoto a través del OTV.
3. El switch 2 del sitio remoto recibirá esta solicitud ARP del enlace OTV y, debido al MAC de origen del ASA, genera una notificación de inestabilidad MAC, ya que la misma dirección MAC se aprende a través del OTV a través de sus interfaces conectadas directamente al ASA.

Situación 5

 Tráfico destinado a la dirección IP BVI del ASA desde un host conectado directamente, como se muestra en la imagen:

También se puede observar un MAC MOVE en momentos en que el tráfico está destinado a la dirección IP BVI del ASA. 

En esta situación, tenemos una máquina host en una red conectada directamente del ASA y estamos intentando conectarnos al ASA.

1. El host no tiene el ARP del ASA y activa una solicitud ARP.
2. El Nexus recibe el tráfico y, como se trata de un tráfico de difusión, también envía el tráfico a través de OTV al otro sitio. 
3. El ASA en el Datacenter 2 remoto puede responder a la solicitud ARP y envía el tráfico de vuelta a través de la misma trayectoria que es el switch 2 en el lado remoto, OTV, el switch 1 en el lado local y luego el host final.
4. Cuando la respuesta ARP se ve en el switch 1 del lado local, dispara una notificación de movimiento MAC ya que ve la dirección MAC del ASA que entra desde el link OTV.

Situación 6

ASA configurado para denegar el tráfico junto con el cual envía un RST al host, como se muestra en la imagen:

En este caso, tenemos un host 1 en la VLAN 35, que intenta comunicarse con el host 2 en la misma VLAN de Capa 3, sin embargo, el host 2 está en realidad en la VLAN 1535 del Data Center 2.

1. La dirección MAC del host 2 se vería en el switch 2 a través de la interfaz conectada a los ASA.
2. El switch 1 vería la dirección MAC del host 2 a través del enlace OTV.
3. El host 1 envía tráfico al host 2 y este sigue la ruta del switch 1, OTV, switch 2 y ASA en el Data Center 2.
4. El ASA rechaza esta información específica y como el ASA está configurado para enviar un RST al Host 1, el paquete RST regresa con la dirección MAC de origen del ASA.
5. Cuando este paquete vuelve al Switch 1 a través de OTV, el Switch 1 registra una notificación MAC MOVE para la dirección MAC de ASA porque ahora ve la dirección MAC a través de OTV, en donde antes ve la dirección desde su interfaz conectada directamente.

Verificación

Actualmente, no hay un procedimiento de verificación disponible para esta configuración.

Troubleshoot

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Información Relacionada

• Guía de configuración CLI de la serie Cisco ASA
• Soporte Técnico y Documentación - Cisco Systems