고가용성 구성의 유닛 2개에서 충족해야 하는 조건은 다음과 같습니다.

• 같은 모델이어야 합니다. 또한 컨테이너 인스턴스에 동일한 리소스 프로파일 속성을 사용해야 합니다.

  Firepower 9300의 경우 고가용성은 동일한 유형의 모듈 간에만 지원되지만, 두 섀시는 혼합된 모듈을 포함할 수 있습니다. 각 섀시에 SM-36 및 SM-44가 있는 경우를 예로 들 수 있습니다. SM-36 모듈 간 SM-44 모듈 간에 고가용성 쌍을 생성할 수 있습니다.

  고가용성 쌍을 FMC에 추가한 후 리소스 프로파일을 변경하는 경우 Devices(디바이스) > Device Management(디바이스 관리) > Device(디바이스) > System(시스템) > Inventory(인벤토리)대화 상자에서 각 유닛의 인벤토리를 업데이트합니다.

• 인터페이스 개수와 유형이 같아야 합니다.

  의 Firepower 4100/9300 섀시의 경우, 고가용성 기능을 활성화하기 전에 FXOS에서 동일하게 모든 인터페이스를 사전에 구성해야 합니다. 고가용성 기능을 활성화한 후에 인터페이스를 변경하는 경우, 스탠바이 유닛의 FXOS에서 인터페이스를 변경하고 나서 활성 유닛에서 동일하게 변경을 수행합니다.

고가용성 구성에서 플래시 메모리 크기가 다른 유닛을 사용 중인 경우, 플래시 메모리 용량이 작은 유닛에 소프트웨어 이미지 파일 및 구성 파일을 수용할 수 있는 충분한 공간이 있는지 확인해야 합니다. 그렇지 않을 경우 플래시 메모리 용량이 큰 유닛에서 플래시 메모리 용량이 작은 유닛으로 컨피그레이션을 동기화할 수 없습니다.

고가용성 구성의 유닛 2개에서 충족해야 하는 조건은 다음과 같습니다.

• 같은 방화벽 모드에 있어야 합니다(라우팅 또는 투명).

• 같은 소프트웨어 버전을 사용해야 합니다.

• FMC에서 동일한 도메인 또는 그룹에 속해야 합니다.

• NTP 구성이 같아야 합니다. Threat Defense를 위한 NTP 시간 동기화 구성의 내용을 참조하십시오.

• 커밋되지 않은 변경 사항 없이 FMC에서 완전히 구축되어야 합니다.

• DHCP 또는 PPPoE가 인터페이스에 구성되어 있지 않아야 합니다.

• (Firepower 4100/9300) 같은 플로우 오프로드 모드가 있으며, 둘 다 활성화하거나 비활성화해야 합니다.

장애 조치 쌍의 유닛 2개에서는 장애 조치 링크를 통해 지속적으로 통신을 수행하여 각 유닛의 작동 상태를 확인합니다.

스테이트풀 장애 조치를 사용하려면 연결 상태 정보를 전달할 스테이트풀 장애 조치 링크(상태 링크라고도 함)를 구성해야 합니다.

페일오버 링크 및 데이터 인터페이스가 다른 경로를 통해 이동하도록 설정하여 모든 인터페이스에 동시 다발적으로 오류가 발생하는 가능성을 줄이는 것이 좋습니다. 페일오버 링크가 중단될 경우 Firepower Threat Defense 디바이스는 데이터 인터페이스를 사용하여 페일오버가 필요한지 여부를 확인할 수 있습니다. 그런 다음 페일오버 링크 상태가 복원될 때까지는 페일오버 작업이 보류됩니다.

복원력이 뛰어난 페일오버 네트워크를 설계하려면 다음 연결 시나리오를 참조하십시오.

시나리오 1 — 권장하지 않음

단일 스위치 또는 스위치 집합을 사용하여 두 Firepower Threat Defense 디바이스 간의 페일오버 및 데이터 인터페이스를 모두 연결한 상태에서 스위치 또는 스위치 간 링크가 중단될 경우 두 Firepower Threat Defense 디바이스 모두 액티브 상태가 됩니다. 따라서 아래의 그림에 있는 다음 2가지 연결 방법은 권장하지 않습니다.

시나리오 2 - 권장함

페일오버 링크에서는 데이터 인터페이스와 같은 스위치를 사용하지 않는 것이 좋습니다. 대신 다음 그림에 나와 있는 것처럼 다른 스위치를 사용하거나 다이렉트 케이블을 사용하여 페일오버 링크에 연결합니다.

시나리오 3 — 권장

Firepower Threat Defense 데이터 인터페이스가 여러 개의 스위치 집합에 연결되어 있는 경우, 페일오버 링크는 이러한 스위치 중 하나에 연결될 수 있으며 다음 그림에 나온 것처럼 주로 네트워크의 보안(내부) 측에 있는 스위치일 가능성이 높습니다.

시나리오 4 — 권장

가장 안정적인 페일오버 컨피그레이션에서는 다음 그림에 나와 있는 것처럼 페일오버 링크에서 이중 인터페이스를 사용합니다.

스테이트풀 페일오버에서는 다음 상태 정보가 스탠바이 FTD 디바이스로 전달됩니다.

• NAT 변환 테이블.

• TCP 및 UDP 연결과 상태(HTTP 연결 상태 포함). 다른 유형의 IP 프로토콜과 ICMP는 새 패킷이 도착하면 새 액티브 유닛에서 설정되므로 액티브 유닛에서 구문 분석되지 않습니다.

• Snort 연결 상태, 검사 결과 및 핀홀 정보(엄격한 TCP 적용 포함).

• ARP 테이블

• 레이어 2 브리지 테이블(브리지 그룹용)

• ISAKMP 및 IPsec SA 테이블

• GTP PDP 연결 데이터베이스

• SIP 시그널링 세션 및 핀홀.

• 정적 및 동적 라우팅 테이블 - 스테이트풀 페일오버는 OSPF 및 EIGRP 같은 동적 라우팅 프로토콜에 참여하므로, 액티브 유닛에서 동적 라우팅 프로토콜을 통해 확인한 경로는 스탠바이 유닛의 RIB(Routing Information Base) 테이블에 유지됩니다. 페일오버 이벤트 발생 시 액티브 보조 유닛에서는 초기 규칙에 따라 기본 유닛을 미러링하므로 트래픽 중단을 최소화면서도 패킷이 정상적으로 이동됩니다. 페일오버가 끝난 직후에는 새 액티브 유닛에서 재통합 타이머가 시작됩니다. 그러면 RIB 테이블의 시간대 숫자가 늘어납니다. 재통합을 수행하는 동안 OSPF 및 EIGRP 경로는 새 시간대 숫자로 업데이트됩니다. 타이머가 만료되면 오래된 경로 항목(시간대 숫자에 의해 결정됨)이 테이블에서 제거됩니다. 그런 다음 RIB에 새 액티브 유닛에 대한 최신 라우팅 프로토콜 전달 정보가 포함됩니다.

  참고	경로는 액티브 유닛의 링크 작동 또는 링크 중단 이벤트가 있을 경우에만 동기화됩니다. 스탠바이 유닛에서 링크가 작동하거나 중단될 경우, 액티브 유닛에서 전송된 동적 경로가 손실될 수 있습니다. 이는 일반적이고 정상적인 동작입니다.

• DHCP 서버 - DHCP 주소 임대는 복제되지 않습니다. 그러나 인터페이스에 구성된 DHCP 서버는 ping을 전송하여 특정 주소가 사용 중이지 않음을 확인한 후에 DHCP 클라이언트에 해당 주소를 부여하므로 서비스에는 영향이 없습니다. 상태 정보는 DHCP 릴레이 또는 DDNS와 관련이 없습니다.

• 액세스 제어 정책 결정 - 트래픽 일치(URL, URL 카테고리, 지리위치 등), 침입 탐지, 악성코드 및 파일 유형과 관련된 결정은 페일오버 중에 그대로 유지됩니다. 그러나 페일오버 시점에서 평가 중인 연결의 경우 다음 경고가 적용됩니다.

  • AVC - 앱-ID 판정은 복제되지만 탐지 상태는 복제되지 않습니다. 페일오버가 수행되기 전에 앱-ID 판정이 완료 및 동기화되면 적절한 동기화가 수행됩니다.

  • 침입 탐지 상태 - 페일오버 시 중간 플로우 픽업이 발생하면 새 검사는 완료되지만 이전 상태는 손실됩니다.

  • 파일 악성코드 차단 - 페일오버 전에 파일 상태를 확인할 수 있어야 합니다.

  • 파일 유형 탐지 및 차단 - 페일오버 전에 파일 유형이 식별되어야 합니다. 원래 액티브 디바이스가 파일을 식별하는 중에 페일오버가 수행되면 파일 유형이 동기화되지 않습니다. 따라서 파일 정책에서 해당 파일 유형을 차단하더라도 새 액티브 디바이스는 파일을 다운로드합니다.

• ID 정책의 사용자 ID 결정( ISE 세션 디렉터리에서 수동으로 수집한 사용자-IP 주소 매핑과 캡티브 포털을 통한 액티브 인증 포함). 페일오버 시점에서 활성 인증 중인 사용자의 경우 다시 인증하라는 프롬프트가 표시될 수 있습니다.

• 네트워크 AMP - 클라우드 조회는 각 디바이스와 독립적으로 작동하므로 페일오버는 일반적으로 이 기능에 영향을 주지 않습니다. 구체적으로 말씀드리면,

  • 서명 조회 - 파일 전송 중에 페일오버가 수행되면 파일 이벤트가 생성되지 않으며 탐지도 수행되지 않습니다.

  • 파일 스토리지 - 파일을 저장하고 있을 때 페일오버가 수행되면 해당 파일은 원래 액티브 디바이스에 저장됩니다. 파일을 저장하는 중에 원래 액티브 디바이스가 중단된 경우에는 파일이 저장되지 않습니다.

  • 파일 사전 분류(로컬 분석) - 사전 분류 중에 페일오버가 수행되면 탐지에 실패합니다.

  • 파일 동적 분석(클라우드 연결) - 페일오버가 수행되는 경우 시스템이 클라우드에 파일을 제출할 수 있습니다.

  • 아카이브 파일 지원 - 분석 중에 페일오버가 수행되면 시스템에서 파일/아카이브에 대한 가시성을 잃게 됩니다.

  • 맞춤형 차단 — 페일오버가 수행되면 이벤트가 생성되지 않습니다.

• 보안 인텔리전스 결정. 그러나 페일오버 시점에서 처리 중인 DNS 기반 결정은 완료되지 않습니다.

• RA VPN - 원격 액세스 VPN 최종 사용자는 페일오버 후 VPN 세션을 다시 인증하거나 다시 연결하지 않아도 됩니다. 그러나 VPN 연결을 통해 작동하는 애플리케이션의 경우 페일오버 프로세스 도중 패킷이 손실될 수 있으며 패킷이 손실되면 복구되지 않습니다.

• 모든 연결 중에서 설정된 연결만 스탠바이 ASA에 복제됩니다.

스테이트풀 페일오버에서는 다음 상태 정보가 스탠바이 FTD 디바이스로 전달되지 않습니다.

• GREv0 및 IPv4-in-IP가 아닌 일반 텍스트 터널의 세션. 터널 내의 세션은 복제되지 않으며, 새 액티브 노드는 기존 검사 판정을 재사용하여 정확한 정책 규칙 일치 여부를 확인할 수 없습니다.

• 암호 해독된 TLS/SSL 연결 - 암호 해독 상태가 동기화되지 않고 만약 액티브 유닛에 장애가 발생하면 암호 해독된 연결이 재설정됩니다. 새 활성 유닛에 새 연결을 설정해야 합니다. 암호 해독되지 않은 연결(TLS/SSL 암호 해독 안 함 규칙 작업과 일치하는 연결)은 영향을 받지 않으며, 올바르게 복제됩니다.

• TCP 상태 우회 연결

• 멀티캐스트 라우팅.

FTD 디바이스에서는 hello 메시지가 있는 장애 조치 링크를 모니터링하여 다른 유닛의 상태를 확인합니다. 장애 조치 링크에서 hello 메시지가 유닛에 3번 연속으로 수신되지 않는 경우, 유닛에서는 장애 조치 링크를 비롯한 각 데이터 인터페이스에 LANTEST 메시지를 전송하여 피어의 응답 여부를 확인합니다. FTD 디바이스에서 취하는 조치는 다른 유닛의 응답에 따라 달라집니다. 아래의 가능한 조치를 참조하십시오.

• FTD 디바이스에서 장애 조치 링크에 대한 응답을 수신하지 못할 경우 장애 조치가 이루어지지 않습니다.

• FTD 디바이스에서 장애 조치 링크에 대한 응답은 수신하지 못했으나 데이터 인터페이스에 대한 응답은 수신한 경우, 유닛에서 장애 조치를 수행하지 않습니다. 페일오버 링크가 실패한 것으로 표시됩니다. 페일오버 링크가 중단된 동안에는 유닛에서 스탠바이 유닛으로 페일오버할 수 없으므로 최대한 빨리 페일오버 링크를 복원해야 합니다.

• FTD 디바이스에서 인터페이스에 대한 응답을 받지 못한 경우 스탠바이 유닛은 액티브 모드로 전환되고 다른 유닛을 실패한 것으로 분류합니다.

15초 동안 모니터링된 인터페이스에 대한 hello 메시지가 유닛에 수신되지 않을 경우 인터페이스 테스트가 실행됩니다. 인터페이스에 대한 단일 인터페이스 테스트가 실패하였으나 다른 유닛에 있는 이 동일한 인터페이스에서는 지속적으로 트래픽을 전달할 수 있다면, 해당 인터페이스는 오류가 발생한 것으로 간주되며 디바이스는 테스트를 중단합니다.

오류가 발생한 인터페이스 수에 정의한 임계값이 충족된다면(Devices(디바이스) > Device Management(디바이스 관리) > High Availability(고가용성) > Failover Trigger Criteria(페일오버 트리거 기준))를 참조하십시오. 액티브 유닛이 대기 유닛보다 오류가 발생한 인터페이스가 많으면 페일오버가 발생합니다. 두 유닛의 인터페이스가 모두 실패하면, 두 인터페이스 모두 'Unknown(알 수 없음)' 상태가 되며 페일오버 인터페이스 정책에서 정의하는 페일오버 한도에 합산되지 않습니다.

트래픽이 수신될 경우 인터페이스는 다시 작동을 시작합니다. 인터페이스 장애 임계값이 더 이상 충족되지 않을 경우 장애가 발생한 디바이스는 스탠바이 모드로 돌아갑니다.

인터페이스에 구성된 IPv4 및 IPv6 주소가 없는 경우 디바이스에서는 IPv4 주소를 사용하여 상태 모니터링을 수행합니다. 인터페이스에 IPv6 주소만 구성되어 있으면 디바이스에서는 ARP 대신 IPv6 네이버 검색을 사용하여 상태 모니터링 테스트를 수행합니다. 브로드캐스트 ping 테스트의 경우 디바이스에서는 IPv6 모든 노드 주소를 사용합니다(FE02::1).

액티브/스탠 바이 페일오버를 설정할 때는 한 유닛을 기본 유닛으로, 다른 유닛을 보조 유닛으로 구성합니다. 컨피그레이션 중에는 기본 유닛의 정책이 보조 유닛에 동기화됩니다. 이 시점에서 두 유닛은 디바이스 및 정책 컨피그레이션을 위해 단일 디바이스로 작동합니다. 하지만 이벤트, 대시보드, 보고서 및 상태 모니터링의 경우에는 계속해서 별도의 디바이스로 표시됩니다.

페일오버 쌍의 두 유닛의 주된 차이점은 어느 유닛이 액티브 유닛이고 어느 유닛이 스탠바이 유닛인지와 관련 있습니다. 즉, 어떤 IP 주소를 사용하고 어떤 유닛이 트래픽을 능동적으로 전달하는지에 달려 있습니다.

그러나 유닛 간의 몇몇 차이점은 어느 유닛이 기본(컨피그레이션에 지정된 사항에 따라) 유닛이고 어느 유닛이 보조 유닛인지에 따라서도 결정됩니다.

• 두 유닛이 동시에 시작되고 둘 다 정상적인 상태로 작동될 경우 기본 유닛은 항상 액티브 유닛이 됩니다.

• 기본 유닛의 MAC 주소는 액티브 IP 주소와 항상 연계됩니다. 보조 유닛이 액티브 유닛이 되고 페일오버 링크를 통해 기본 유닛의 MAC 주소를 획득할 수 없는 경우에는 이러한 규칙에 예외가 발생합니다. 이 경우 보조 유닛의 MAC 주소가 사용됩니다.

액티브 유닛은 다음에 따라 결정됩니다.

• 유닛이 부팅되고 이미 액티브로 실행 중인 피어가 감지된 경우, 해당 유닛은 스탠바이 유닛이 됩니다.

• 유닛이 부팅되고 피어가 감지되지 않은 경우 해당 유닛은 액티브 유닛이 됩니다.

• 두 유닛이 동시에 부팅될 경우 기본 유닛이 액티브 유닛이 되고 보조 유닛은 스탠바이 유닛이 됩니다.

액티브/스탠바이 페일오버 시 페일오버는 유닛을 기준으로 실행됩니다.

다음 표에서는 각 페일오버 이벤트에 대한 페일오버 작업을 보여줍니다. 이 표에는 각 페일오버 이벤트에 적용되는 페일오버 정책(페일오버 실행 또는 페일오버 없음), 액티브 유닛에서 시행한 조치, 스탠바이 유닛에서 시행한 조치, 페일오버 조건 및 각 조치에 대한 특별 참고 사항이 나와 있습니다.