소개

이 문서에서는 Spanned EtherChannel 투명 모드 사이트 간 클러스터의 몇 가지 일반적인 문제에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• ASA(Adaptive Security Appliance) 방화벽
• ASA 클러스터링

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

ASA 버전 9.2부터는 사이트 간 클러스터링이 지원되며, 여기서 ASA 장치는 서로 다른 데이터 센터에 위치할 수 있으며 CCL(Cluster Control Link)은 DCI(Data Center Interconnect)를 통해 연결됩니다. 가능한 구축 시나리오는 다음과 같습니다.

•  개별 인터페이스 사이트 간 클러스터
•  Spanned EtherChannel 투명 모드 사이트 간 클러스터
•  Spanned EtherChannel 라우팅 모드 사이트 간 클러스터(9.5 이상에서 지원됨)

MAC 이동 알림

CAM(Content Addressable Memory) 테이블의 MAC 주소가 포트를 변경하면 MAC MOVE 알림이 생성됩니다. 그러나 MAC 주소가 추가되거나 CAM 테이블에서 제거될 때 MAC MOVE 알림은 생성되지 않습니다. VLAN10의 인터페이스 GigabitEthernet0/1을 통해 MAC 주소 X를 학습하고 일정 시간이 지난 후 VLAN 10의 GigabitEthernet0/2를 통해 동일한 MAC가 표시되면 MAC MOVE 알림이 생성됩니다.

스위치의 Syslog:

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

ASA의 Syslog:

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

네트워크 다이어그램

ASA가 투명 모드로 구성되어 VLAN 1535와 VLAN 35를 연결하는 사이트 간 클러스터 구축. 이미지에 표시된 것처럼 내부 VLAN 35는 OTV(Overlay Transport Virtualization)를 통해 확장되지만 외부 VLAN 1535는 OTV를 통해 확장되지 않습니다

스위치의 MAC 이동 알림

시나리오 1

이미지에 표시된 대로 ASA의 MAC 테이블에 해당 항목이 없는 MAC 주소로 향하는 트래픽:

투명 ASA에서 ASA에 도착하는 패킷의 목적지 MAC 주소가 mac-address 테이블에 없는 경우, 해당 목적지에 대한 ARP(Address Resolution Protocol) 요청(BVI와 동일한 서브넷에 있는 경우) 또는 소스 MAC을 BVI(Bridge Virtual Interface) MAC 주소로 하고 목적지 MAC 주소를 DMAC(Destination Media Access Controller)로 하는 TTL 1(Time To Live 1)을 사용하는 ICMP(Internet Control Message Protocol) 요청이 누락됩니다.

앞의 경우 다음과 같은 트래픽 흐름이 있습니다.

1. 데이터 센터 1의 ISP 라우터는 ASA 뒤에 있는 특정 대상에 트래픽을 전달합니다.
2. ASA 중 하나가 트래픽을 수신할 수 있으며, 이 경우 트래픽의 목적지 MAC 주소는 ASA에서 알 수 없습니다.
3. 이제 트래픽의 목적지 IP가 BVI와 동일한 서브넷에 있으며, 앞에서 언급한 것처럼 이제 ASA가 목적지 IP에 대한 ARP 요청을 생성합니다.
4. 스위치 1은 트래픽을 수신하고 요청이 브로드캐스트이므로 OTV 링크 전반은 물론 데이터 센터 2로 트래픽을 전달합니다.
5. 스위치 2는 OTV 링크의 ASA에서 ARP 요청을 볼 때, MAC MOVE 알림을 로깅합니다. 이전에는 ASA의 MAC 주소가 직접 연결된 인터페이스를 통해 학습되었고 이제는 OTV 링크를 통해 학습되었기 때문입니다.

권장 사항

이는 코너 시나리오입니다. MAC 테이블은 클러스터에서 동기화되므로 멤버가 특정 호스트에 대한 항목을 가지지 않을 가능성이 적습니다. 클러스터 소유 BVI MAC에 대한 MAC 이동이 간헐적으로 허용되는 것으로 간주됩니다.

시나리오 2

그림과 같이 ASA에 의한 중앙 집중식 흐름 처리:

ASA 클러스터 전반의 검사 기반 트래픽은 다음 세 가지 유형으로 분류됩니다.

• 중앙 집중식
• Distributed(분산됨)
• 반분포

중앙 집중식 검사의 경우, 검사해야 하는 모든 트래픽은 ASA 클러스터의 기본 유닛으로 리디렉션됩니다. ASA 클러스터의 보조 유닛에서 트래픽을 수신하면 CCL을 통해 기본 유닛으로 전달됩니다.

이전 이미지에서는 CIP(Centralized Inspection Protocol)인 SQL 트래픽으로 작업하며 여기에 설명된 동작이 모든 CIP에 적용됩니다.

ASA 클러스터의 보조 유닛만 있는 데이터 센터 2에서 트래픽을 수신합니다. 기본 유닛은 ASA 1인 데이터 센터 1에 있습니다.

1. 데이터 센터 2의 ISP 라우터 2는 트래픽을 수신하고 다운스트림에서 해당 사이트의 ASA로 전달합니다.
2. 어떤 ASA든 이 트래픽을 수신할 수 있으며, 이 트래픽을 검사해야 한다고 판단하면 프로토콜이 중앙 집중화되면 CCL을 통해 트래픽을 기본 유닛으로 전달합니다.
3. ASA 1은 CCL을 통해 트래픽 흐름을 수신하고, 트래픽을 처리하여 SQL Server로 다운스트림으로 전송합니다.
4. 이제 ASA 1이 트래픽을 다운스트림으로 전달할 때 데이터 센터 2에 있는 ISP 라우터 2의 원래 소스 mac 주소를 유지하여 다운스트림으로 전송합니다.
5. 스위치 1이 이 특정 트래픽을 수신하면 MAC MOVE 알림에 로그인합니다. 이는 원래 데이터 센터 2에 연결된 OTV 링크를 통해 ISP 라우터 2 MAC 주소가 표시되는데, 이제 ASA 1에 연결된 인터페이스에서 들어오는 트래픽이 표시되기 때문입니다.

권장 사항

그림과 같이 우선순위에 따라 기본 사이트를 호스팅하는 어떤 사이트에도 중앙 집중식 연결을 라우팅하는 것이 좋습니다.

시나리오 3

투명 모드의 DC(Inter Domain Controller) 통신의 경우 이 특정 트래픽 흐름은 포함되거나 문서화되지 않지만 ASA 흐름 처리 관점에서 이 특정 트래픽 흐름은 작동합니다. 그러나 스위치에서 MAC 이동 알림이 발생할 수 있습니다. 

1. VLAN 35의 호스트 1은 다른 데이터 센터에 있는 호스트 2와 통신을 시도합니다.
2. 호스트 1에는 라우터 1이라는 기본 게이트웨이가 있으며 라우터 1에는 대체 링크를 통해 라우터 2와 직접 통신할 수 있으므로 호스트 2에 연결할 수 있는 경로가 있습니다. 이 경우 MPLS(Multiprotocol Label Switching)를 가정하고 ASA 클러스터를 통하지 않습니다.
3. 라우터 2는 수신 트래픽을 수신하고 이를 호스트 2로 라우팅합니다.
4. 이제 호스트 2가 응답하면 라우터 2는 반환 트래픽을 수신하고 MPLS를 통해 전송하는 트래픽 대신 ASA를 통해 직접 연결된 경로를 찾습니다. 
5. 이 단계에서 라우터 2를 떠나는 트래픽은 라우터 2의 종료 인터페이스의 소스 MAC을 갖습니다.
6. 데이터 센터 2의 ASA는 반환 트래픽을 수신하고, 데이터 센터 1의 ASA에 의해 만들어지고 존재하는 연결을 찾습니다.
7. 데이터 센터 2의 ASA는 CCL을 통해 반환 트래픽을 데이터 센터 1의 ASA로 다시 전송합니다.
8. 이 단계에서 데이터 센터 1의 ASA는 반환 트래픽을 처리하고 스위치 1을 향해 전송합니다. 패킷은 라우터 2의 종료 인터페이스와 소스 MAC이 동일합니다.
9. 이제 스위치 1이 패킷을 수신하면 OTV 링크에 연결된 인터페이스 전체에서 라우터 2의 MAC 주소를 학습했기 때문에 MAC 이동 알림을 로깅하지만, 이 단계에서는 ASA에 연결된 인터페이스에서 MAC 주소를 학습하기 시작합니다.
   
   

시나리오 4

그림과 같이 ASA에서 생성된 트래픽:

ASA 자체에서 생성되는 모든 트래픽에 대해 이 특정 사례가 관찰됩니다. 여기서는 ASA가 BVI 인터페이스와 동일한 서브넷에 있는 NTP(Network Time Protocol) 또는 Syslog 서버에 연결하려고 시도하는 두 가지 상황이 고려됩니다. 그러나 이 두 가지 조건으로 제한되는 것은 아니며 BVI IP 주소에 직접 연결된 IP 주소에 대해 ASA에서 트래픽을 생성할 때마다 이러한 상황이 발생할 수 있습니다.

1. ASA에 NTP 서버/Syslog 서버의 ARP 정보가 없는 경우 ASA는 해당 서버에 대한 ARP 요청을 생성합니다.
2. ARP 요청이 브로드캐스트 패킷이므로 스위치 1은 ASA의 연결된 인터페이스에서 이 패킷을 수신하고 OTV의 원격 사이트를 포함한 특정 VLAN의 모든 인터페이스에서 패킷을 플러딩합니다.
3. 원격 사이트 스위치 2는 OTV 링크에서 이 ARP 요청을 받으며, ASA의 소스 MAC으로 인해 ASA에 직접 연결된 로컬 인터페이스를 통해 OTV에서 동일한 MAC 주소가 학습되므로 MAC 플랩 알림이 생성됩니다.

시나리오 5

 이미지에 표시된 대로 직접 연결된 호스트에서 ASA의 BVI IP 주소로 이동하는 트래픽입니다.

MAC MOVE는 트래픽이 ASA의 BVI IP 주소로 전송될 때도 관찰될 수 있습니다. 

시나리오에서는 ASA의 직접 연결된 네트워크에 호스트 머신이 있으며 ASA에 연결하려고 합니다.

1. 호스트에는 ASA의 ARP가 없으며 ARP 요청이 트리거됩니다.
2. Nexus는 트래픽을 수신하고 브로드캐스트 트래픽이므로 OTV를 통해 트래픽을 다른 사이트에도 전송합니다. 
3. 원격 데이터 센터 2의 ASA는 ARP 요청에 응답하고 원격 측의 스위치 2, 로컬 측의 스위치 1, 엔드 호스트와 동일한 경로(OTV, 스위치 1)를 통해 트래픽을 다시 전송할 수 있습니다.
4. ARP 응답이 로컬 측 스위치 1에 표시되면 OTV 링크에서 들어오는 ASA의 MAC 주소를 볼 때 MAC 이동 알림을 트리거합니다.

시나리오 6

ASA는 이미지에 표시된 대로 호스트에 RST를 전송할 때 함께 트래픽을 거부하도록 설정합니다.

이 경우 VLAN 35에 호스트 호스트 1이 있고, 동일한 레이어 3 VLAN에서 호스트 2와 통신하려고 하지만, 실제로 호스트 2는 데이터 센터 2 VLAN 1535에 있습니다.

1. ASA에 연결된 인터페이스를 통해 스위치 2에 호스트 2MAC 주소가 표시됩니다.
2. 스위치 1은 OTV 링크를 통해 호스트 2의 MAC 주소를 확인할 수 있습니다.
3. 호스트 1은 트래픽을 호스트 2로 전송하고, 이는 데이터 센터 2의 스위치 1, OTV, 스위치 2, ASA의 경로를 따릅니다.
4. 이 특정 패킷은 ASA에서 거부되며 ASA가 RST를 호스트 1로 다시 전송하도록 구성되었으므로 RST 패킷이 ASA의 소스 MAC 주소와 함께 반환됩니다.
5. 이 패킷이 OTV를 통해 스위치 1로 돌아가면 스위치 1은 ASA의 MAC 주소에 대한 MAC MOVE 알림을 로깅합니다. OTV에서 MAC 주소를 인식하기 때문입니다. MAC 주소는 직접 연결된 인터페이스에서 인식되기 전에 인식됩니다.

다음을 확인합니다.

현재 이 설정에 사용 가능한 확인 절차는 없습니다.

문제 해결

현재 이 설정에 사용할 수 있는 특정 문제 해결 정보가 없습니다.

관련 정보

• Cisco ASA Series CLI 컨피그레이션 가이드
• 기술 지원 및 문서 − Cisco Systems