논리적 디바이스 정보
논리적 디바이스를 사용하면 애플리케이션 인스턴스 하나(ASA 또는 FTD)와 선택적 데코레이터 애플리케이션(Radware DefensePro)을 실행하여 서비스 체인을 만들 수 있습니다 .
논리적 디바이스를 추가할 때는 애플리케이션 인스턴스 유형 및 버전 정의, 인터페이스 할당, 애플리케이션 구성으로 푸시되는 부트스트랩 설정 작업도 수행합니다.
참고 |
Firepower 9300의 경우 섀시 내의 개별 모듈에 서로 다른 애플리케이션 유형(ASA 및 FTD)을 설치할 수 있습니다. 개별 모듈에서 애플리케이션 인스턴스 유형의 서로 다른 버전을 실행할 수도 있습니다. |
독립형 논리적 디바이스와 클러스터형 논리적 디바이스
다음의 논리적 디바이스 유형을 추가할 수 있습니다.
-
독립형 — 독립형 유닛으로 또는 고가용성 쌍의 유닛으로 작동하는 독립형 논리적 디바이스입니다.
-
클러스터 — 클러스터형 논리적 디바이스에서는 여러 유닛을 함께 그룹화할 수 있으므로 처리량 증대 및 여러 디바이스의 이중화라는 목표를 달성하는 동시에 단일 디바이스(관리, 네트워크에 통합)의 모든 편의성을 제공합니다. Firepower 9300과 같은 다중 모듈 디바이스는 인트라 섀시 클러스터링(intra-chassis clustering)을 지원합니다. Firepower 9300의 경우 세 개 모듈 모두가 네이티브와 컨테이너 인스턴스 모두에 대해 클러스터에 참여해야 합니다. FDM에서는 클러스터링을 지원하지 않습니다.
논리적 디바이스 애플리케이션 인스턴스: 컨테이너 및 기본
다음 구축 유형으로 애플리케이션 인스턴스가 실행됩니다.
-
기본 인스턴스 — 기본 인스턴스는 보안 모듈/엔진의 모든 리소스(CPU, RAM 및 디스크 공간)를 사용합니다. 따라서 하나의 기본 인스턴스만 설치할 수 있습니다.
-
컨테이너 인스턴스 — 컨테이너 인스턴스는 보안 모듈/엔진의 리소스 하위 집합을 사용합니다. 따라서 여러 개의 컨테이너 인스턴스를 설치할 수 있습니다. 다중 인스턴스 기능은 FMC를 사용하는 FTD에 대해서만 지원되며, ASA 또는 FDM를 사용하는 FTD에 대해서는 지원되지 않습니다.
참고
다중 인스턴스 기능은 ASA 다중 컨텍스트 모드와 비슷하지만 구현은 서로 다릅니다. 다중 컨텍스트 모드에서는 단일 애플리케이션 인스턴스를 분할하는 반면 다중 인스턴스 기능 사용 시에는 독립적인 컨테이너 인스턴스를 사용할 수 있습니다. 컨테이너 인스턴스에서는 하드 리소스 분리, 별도의 구성 관리/다시 로드/소프트웨어 업데이트가 허용되며 전체 FTD 기능이 지원됩니다. 다중 컨텍스트 모드에서는 리소스가 공유되므로 지정된 플랫폼에서 더 많은 컨텍스트가 지원됩니다. FTD에서는 다중 상황 모드를 사용할 수 없습니다.
Firepower 9300의 경우 일부 모듈에서는 기본 인스턴스를, 다른 모듈에서는 컨테이너 인스턴스를 사용할 수 있습니다.
컨테이너 인스턴스 인터페이스
컨테이너 인스턴스에 대해 물리적 인터페이스를 유연하게 사용할 수 있도록 FXOS에서 VLAN 하위 인터페이스를 생성하는 동시에 여러 인스턴스 간에 인터페이스(VLAN 또는 물리적)를 공유할 수 있습니다. 기본 인스턴스는 VLAN 하위 인터페이스 또는 공유 인터페이스를 사용할 수 없습니다. 멀티 인스턴스 클러스터는 VLAN 하위 인터페이스 또는 공유된 인터페이스를 사용할 수 없습니다. 클러스터 EtherChannel의 하위 인터페이스를 사용할 수 있는 클러스터 제어 링크는 예외입니다. 공유 인터페이스 확장성 및 컨테이너 인스턴스에 VLAN 하위 인터페이스 추가를 참조하십시오.
참고 |
이 문서에서는 FXOS VLAN 하위 인터페이스에 대해서만 설명합니다. FTD 애플리케이션 내에 하위 인터페이스를 추가할 수 있습니다. 자세한 내용은 FXOS 인터페이스와 애플리케이션 인터페이스 비교를 참조하십시오. |
섀시가 패킷을 분류하는 방법
섀시에 들어오는 각 패킷은 분류되어야 합니다. 그러면 섀시에서 어떤 인스턴스에 패킷을 보낼지 판단할 수 있습니다.
-
고유 인터페이스 - 단 하나의 인스턴스가 인그레스 인터페이스와 연결된 경우 섀시는 해당 패킷을 해당 인스턴스로 분류합니다. 투명 모드 또는 라우티드 모드의 브리지 그룹 멤버 인터페이스, 인라인 집합 또는 패시브 인터페이스의 경우에는 항상 이 방법을 사용하여 패킷을 분류합니다.
-
고유 MAC 주소 - 섀시가 공유 인터페이스를 포함한 모든 인터페이스에 대해 고유한 MAC 주소를 자동으로 생성합니다. 여러 인스턴스가 인터페이스 하나를 공유하는 경우 분류자는 각 인스턴스의 인터페이스에 할당된 고유 MAC 주소를 사용합니다. 업스트림 라우터는 고유 MAC 주소가 없으면 인스턴스로 직접 라우팅할 수 없습니다. 또한 애플리케이션 내에서 각 인터페이스를 구성할 때 수동으로 MAC 주소를 설정할 수도 있습니다.
참고 |
대상 MAC 주소가 멀티캐스트 또는 브로드캐스트 MAC 주소인 경우 패킷이 복제되어 각 인스턴스에 배포됩니다. |
분류의 예
다음 그림은 외부 인터페이스를 공유하는 여러 인스턴스를 보여 줍니다. 분류자는 인스턴스 C에 패킷을 할당합니다. 라우터에서 패킷을 보내는 MAC 주소가 인스턴스 C에 포함되어 있기 때문입니다.
내부 네트워크에서 보낸 것을 비롯하여 모든 신규 수신 트래픽은 분류되어야 합니다. 다음 그림에는 인터넷에 액세스하는 네트워크 내의 인스턴스 C에 있는 호스트가 나와 있습니다. 분류자는 인스턴스 C에 패킷을 할당합니다. 인그레스 인터페이스가 인스턴스 C에 할당된 이더넷 1/2.3이기 때문입니다.
투명 방화벽의 경우 고유한 인터페이스를 사용해야 합니다. 다음 그림에는 인터넷의 네트워크 내 인스턴스 C에 있는 호스트로 전송되는 패킷이 나와 있습니다. 분류자는 인스턴스 C에 패킷을 할당합니다. 인그레스 인터페이스가 인스턴스 C에 할당된 이더넷 1/2.3이기 때문입니다.
인라인 집합의 경우에는 고유 인터페이스를 사용해야 하며, 해당 인터페이스는 물리적 인터페이스 또는 EtherChannel이어야 합니다. 다음 그림에는 인터넷의 네트워크 내 인스턴스 C에 있는 호스트로 전송되는 패킷이 나와 있습니다. 분류자는 인스턴스 C에 패킷을 할당합니다. 인그레스 인터페이스가 인스턴스 C에 할당된 이더넷 1/5이기 때문입니다.
연속 컨테이너 인스턴스
다른 인스턴스 바로 앞에 컨테이너 인스턴스를 배치하는 것을 연속 컨테이너 인스턴스라고 합니다. 하나의 인스턴스의 외부 인터페이스는 다른 인스턴스의 내부 인터페이스와 동일한 인터페이스입니다. 최상위 인스턴스에서 공유 파라미터를 구성함으로써 일부 인스턴스의 구성을 간소화하고 싶다면 인스턴스 캐스케이딩이 유용할 수 있습니다.
다음 그림에는 게이트웨이 뒤에 인스턴스가 2개 있는 게이트웨이 인스턴스가 나와 있습니다.
일반적인 다중 인스턴스 구축
다음 예에는 라우팅된 방화벽 모드의 컨테이너 인스턴스 3개가 포함되어 있습니다. 이러한 컨테이너 인스턴스는 다음 인터페이스를 포함합니다.
-
Management(관리) — 모든 인스턴스가 Port-Channel1 인터페이스(관리 유형)를 사용합니다. 이 EtherChannel에는 10기가비트 이더넷 인터페이스 2개가 포함됩니다. 각 애플리케이션 내에서 인터페이스는 동일한 관리 네트워크의 고유 IP 주소를 사용합니다.
-
Inside(내부) — 각 인스턴스가 Port-Channel2(데이터 유형)의 하위 인터페이스를 사용합니다. 이 EtherChannel에는 10기가비트 이더넷 인터페이스 2개가 포함됩니다. 각 하위 인터페이스는 별도 네트워크에 있습니다.
-
Outside(외부) — 모든 인스턴스가 Port-Channel3 인터페이스(데이터 공유 유형)를 사용합니다. 이 EtherChannel에는 10기가비트 이더넷 인터페이스 2개가 포함됩니다. 각 애플리케이션 내에서 인터페이스는 동일한 외부 네트워크의 고유 IP 주소를 사용합니다.
-
Failover(페일오버) — 각 인스턴스가 Port-Channel4(데이터 유형)의 하위 인터페이스를 사용합니다. 이 EtherChannel에는 10기가비트 이더넷 인터페이스 2개가 포함됩니다. 각 하위 인터페이스는 별도 네트워크에 있습니다.
컨테이너 인스턴스 인터페이스용 자동 MAC 주소
FXOS 섀시는 컨테이너 인스턴스 인터페이스용 MAC 주소를 자동으로 생성하며 각 인스턴스의 공유 인터페이스가 고유한 MAC 주소를 사용하도록 보장합니다.
애플리케이션 내의 공유 인터페이스에 직접 MAC 주소를 할당하는 경우 직접 할당한 MAC 주소가 사용됩니다. 나중에 수동 MAC 주소를 삭제할 경우 자동 생성 주소가 사용됩니다. 드물지만, 생성된 MAC 주소가 네트워크의 다른 사설 MAC 주소와 충돌할 경우 애플리케이션 내에서 인터페이스의 MAC 주소를 직접 설정하는 것이 좋습니다.
자동 생성 주소는 A2로 시작하기 때문에, 주소가 겹칠 위험이 있으므로 수동 MAC 주소를 A2로 시작해서는 안 됩니다.
FXOS 섀시는 다음 형식을 사용하여 MAC 주소를 생성합니다.
A2xx.yyzz.zzzz
여기서 xx.yy는 사용자 정의 접두사 또는 시스템 정의 접두사이고 zz.zzzz는 섀시에서 생성되는 내부 카운터입니다. 시스템 정의 접두사는 IDPROM에 프로그래밍되는 번인된 MAC 주소 풀의 첫 번째 MAC 주소의 하위 2바이트와 일치합니다. MAC 주소 풀을 확인하려면 connect fxos , show module 을 차례로 사용합니다. 예를 들어 모듈 1에 대해 표시되는 MAC 주소 범위가 b0aa.772f.f0b0~b0aa.772f.f0bf이면 시스템 접두사는 f0b0입니다.
사용자 정의 접두사는 16진수로 변환되는 정수입니다. 사용자 정의 접두사가 어떻게 사용되는지 예를 들어 설명하자면, 접두사를 77로 설정하는 경우 섀시에서는 77을 16진수 값 004D(yyxx)로 변환합니다. 접두사가 MAC 주소에서 쓰일 때는 섀시 기본 형식에 부합하도록 역전됩니다(xxyy).
A24D.00zz.zzzz
접두사가 1009 (03F1)일 때 MAC 주소는 다음과 같습니다.
A2F1.03zz.zzzz
컨테이너 인스턴스 리소스 관리
컨테이너 인스턴스당 리소스 사용량을 지정하려면 FXOS에서 리소스 프로파일을 하나 이상 생성합니다. 논리적 디바이스/애플리케이션 인스턴스를 구축할 때 사용할 리소스 프로필을 지정합니다. 리소스 프로파일은 CPU 코어 수를 설정합니다. RAM은 코어 수에 따라 동적으로 할당되며 디스크 공간은 인스턴스당 40GB로 설정됩니다. 모델당 사용 가능한 리소스를 확인하려면 컨테이너 인스턴스의 요구 사항 및 사전 요구 사항 섹션을 참조하십시오. 리소스 프로파일을 추가하려면 컨테이너 인스턴스에 대한 리소스 프로파일 추가 섹션을 참조하십시오.
다중 인스턴스 기능의 성능 확장 요인
플랫폼의 최대 처리량(연결, VPN 세션 및 TLS 프록시 세션)은 네이티브 인스턴스의 메모리 및 CPU 사용에 대해 계산됩니다. 이 값은 show resource usage 에 표시됩니다. 다중 인스턴스를 사용하는 경우 처리량은 인스턴스에 할당하는 CPU 코어의 비율을 기준으로 계산해야 합니다. 예를 들어, 코어가 50%인 컨테이너 인스턴스를 사용하는 경우, 처음에는 처리량의 50%를 계산해야 합니다. 또한, 컨테이너 인스턴스에 사용 가능한 처리량은 기본 인스턴스로 줄여야 합니다.
인스턴스의 처리량 계산에 대한 자세한 지침은 https://www.cisco.com/c/en/us/products/collateral/security/firewalls/white-paper-c11-744750.html의 내용을 참조하십시오.
컨테이너 인스턴스 및 고가용성
2개의 개별 섀시에서 컨테이너 인스턴스를 사용하여 고가용성을 사용할 수 있습니다. 예를 들어 각각 인스턴스가 10개인 섀시가 2개 있으면 고가용성 쌍 10개를 생성할 수 있습니다. FXOS에서 고가용성이 구성되지 않았으면 애플리케이션 관리자에서 각 고가용성 쌍을 구성합니다.
자세한 요구 사항은 고가용성 요구 사항 및 사전 요건 및 고가용성 쌍 추가의 내용을 참조하십시오.
컨테이너 인스턴스 및 클러스터링
보안 모듈/엔진당 하나의 컨테이너 인스턴스를 사용하여 컨테이너 인스턴스 클러스터를 생성할 수 있습니다. 자세한 요구 사항은 클러스터링의 요구 사항 및 사전 요구 사항의 내용을 참조하십시오.