콘텐츠로 이동

인터페이스 모델 및 아웃 오브 밴드 관리

Customer Edge (CE)에는 그 이름에 걸맞은 로컬 관리 평면(Management Plane)이 존재하지 않습니다. 부트스트랩 구성 및 진단을 제외하면 CE를 관리하는 모든 작업은 F5 Distributed Cloud 제어 평면에서 구동되며, 노드는 하나의 특정 인터페이스를 통해 해당 제어 평면에 도달합니다. 이 단 하나의 사실이 전체 인터페이스 모델을 결정하며, 이를 오해하는 것이 CE 배포가 단순히 고장 나는 것이 아니라 아키텍처적으로 잘못 설계되는 가장 흔한 원인입니다.

이 페이지에서는 “관리”라는 단어를 공유하지만 동일한 구조가 아닌 두 가지 개념을 구분합니다:

개요
Site Local Outside (SLO)CE가 등록되고 중앙 서버와 통신(Phone Home)을 수행하는 인터페이스입니다. 모든 모드의 모든 CE에 존재합니다. 등록 후에는 변경할 수 없습니다(불변). 일반적인 경우 이것이 바로 관리 경로입니다.
Management network자체 커널 Virtual Routing and Forwarding (VRF) 인스턴스에 진정한 아웃 오브 밴드(OOB) 인터페이스를 추가하는 별도의 최신 Secure Mesh Site v2 (SMSv2) 옵션입니다. 단일 노드 사이트 전용입니다.

Site Local Outside는 어쩌다 보니 첫 번째에 위치한 데이터 인터페이스가 아닙니다

섹션 제목: “Site Local Outside는 어쩌다 보니 첫 번째에 위치한 데이터 인터페이스가 아닙니다”

SLO는 CE 노드를 F5 Distributed Cloud Regional Edges (REs)에 연결하며, 등록, 업그레이드 및 제어 평면 연결이 실행되는 경로입니다. 또한 데이터 평면 Egress의 기본 경로 역할을 하며, 사이트 간 터널이 종료되는 지점입니다. 플랫폼이 F5 도달을 위해 이 인터페이스를 전용으로 예약하므로 애플리케이션 트래픽을 로드하지 말고 특별하게 다루어 이를 중심으로 설계하십시오.

이에 따라 두 가지 결과가 따르며, 두 가지 모두 권장 사항이 아닌 계약상의 필수 사항입니다:

  • SLO는 F5에 도달할 수 있어야 합니다. 도달 가능성 요구 사항은 CE IP Address and Domain Reference에 나열되어 있습니다. SLO 인터페이스가 F5에 도달할 수 없는 CE는 등록되지 않으며, 등록되지 않은 노드는 제어 평면을 통해서도 진단할 수 없습니다. 4가지 액세스 경로를 참조하십시오.
  • 노드가 등록되고 배포되면 SLO는 변경할 수 없습니다. F5는 CE Site가 배포된 후 SLO 인터페이스의 Internet Protocol (IP) 주소와 Media Access Control (MAC) 주소를 변경할 수 없다고 명시합니다. SLO 매개변수를 변경하려면 노드를 재배포해야 합니다.

세그먼트는 내부 네트워크를 위한 일반적인 해답입니다

섹션 제목: “세그먼트는 내부 네트워크를 위한 일반적인 해답입니다”

SLI는 선택 사항입니다. F5 자체 지침에서는 대신 Network Segments를 고려할 것을 권장하며, 이는 Console의 Multi-Cloud Network Connect > Networking > Segments에서 찾아볼 수 있습니다. 세그먼트는 인터페이스에 연결할 수 있는 전역 VRF로, 단일 CE Site 내부에서 네트워크를 격리하거나 여러 하이브리드 및 멀티 클라우드 CE Sites 전체로 해당 네트워크를 확장합니다. 따라서 “이러한 서비스는 자체 VRF로 제한되어야 한다”는 요구 사항이 있을 때 세그먼트가 적절한 도구가 됩니다.

이것은 SMSv2 사이트 개체의 Management Network 메뉴에서 활성화하는 구조이며, 단순히 이름만 바꾼 SLO가 아니라 실제 OOB 인터페이스입니다. 활성화되면 F5는 SLO나 SLI 인터페이스가 아닌 별도의 네트워크 인터페이스를 생성하여 데이터 평면 트래픽과 완벽히 격리되도록 자체 커널 VRF에서 작동시킵니다. 아웃 오브 밴드이므로 CE 노드 포워딩 평면에는 참여하지 않습니다. 의도된 용도는 서비스의 OOB 관리(Secure Shell (SSH) 및 로컬 웹 사용자 인터페이스)와 트러블슈팅(Site CLI 명령 실행 및 syslog 파일 외부 전송)입니다.

사용 가능 여부는 3가지 제약 조건에 따라 결정됩니다:

제약 조건
노드 수단일 노드 CE Sites 전용. 다중 노드 CE Site(클러스터)에서는 지원되지 않습니다.
소프트웨어 버전crt-20251001-0189 이상. 노드 소프트웨어 릴리스 노트를 참조하십시오.
기본값활성화되지 않음.

이를 활성화하면 인터페이스 순서도 고정되어 노드에서 이에 대한 잘못된 가정이 드러나게 됩니다:

  1. 관리 네트워크 인터페이스
  2. Site Local Outside (SLO) 인터페이스
  3. 추가 인터페이스(Site Local Inside (SLI) 인터페이스의 일부가 됨)

여기의 각 CE에는 3개의 Azure NIC가 있으며, 첫 번째 NIC는 terraform/modules/ce-node/main.tf에서 mgmt로 이름 지정되어 있습니다. 해당 이름은 NIC가 위치한 Azure 서브넷을 설명합니다. 이는 XC 관리 네트워크가 구성되었음을 의미하지 않으며, 이 문서의 어떤 페이지도 그렇게 해석되어서는 안 됩니다.

terraform/modules/xc-site/main.tf는 사이트 개체에 정확히 하나의 인터페이스를 선언합니다:

interface_list {
name = "eth0"
ethernet_interface {
device = "eth0"
mac = var.mgmt_nic_mac
}
# Site Local Outside (SLO) — required on every site; BGP peers from here.
network_option {
site_local_network {}
}
dhcp_client {}
}

site_local_network {}가 SLO입니다. 따라서:

이 배포에서실제 역할
mgmt NIC (eth0, VM의 첫 번째 NIC)SLO 인터페이스. 등록 및 제어 평면 트래픽을 F5로 전달하며, Azure Route Server가 피어링하는 Border Gateway Protocol (BGP) 로컬 주소입니다.
external NIC데이터 평면 인터페이스.
internal NICSLI 인터페이스.
관리 네트워크구성되지 않음. 사이트 개체에 enable_management_network 마커가 설정되어 있지 않습니다.

사이트는 단일 노드(disable_ha {}, 가용성 영역당 1개 사이트)이므로 3노드 클러스터와 달리 여기서는 관리 네트워크가 허용됩니다. 단지 활성화되지 않았을 뿐이며, 이를 활성화하면 위의 순서에 따라 인터페이스 번호가 다시 매겨져 BGP 피어 바인딩이 의존하는 설정에 영향을 미칩니다.

자체 IP 구성 및 VLAN 할당이 있는 별도의 아웃 오브 밴드 관리 인터페이스를 정의하려면 어떻게 해야 합니까?

섹션 제목: “자체 IP 구성 및 VLAN 할당이 있는 별도의 아웃 오브 밴드 관리 인터페이스를 정의하려면 어떻게 해야 합니까?”

단일 노드 CE Site에서는 소프트웨어 crt-20251001-0189 이상에서 SMSv2 사이트 개체의 Management Network 옵션을 활성화하십시오. 그러면 F5는 포워딩 평면 외부의 자체 커널 VRF에 별도의 인터페이스를 생성합니다.

다중 노드(3노드) CE Site에서는 이를 수행할 수 있는 지원되는 방법이 없습니다. 관리 네트워크는 클러스터에 대해 명시적으로 지원되지 않습니다. 클러스터의 경우 SLO를 관리 경로로 다루고(F5 Global Controller에 도달하며 이를 위해 예약되어 있음) 다른 모든 항목에 대해서는 SLI VRF 또는 자체 세그먼트에 추가 데이터 평면 인터페이스를 추가하십시오.

인터페이스별 IP 구성은 인터페이스가 정의될 때 사이트 개체에서 설정됩니다. VLAN 하위 인터페이스를 특히 관리 네트워크에 할당할 수 있는지 여부는 작성 시점에 F5에서 어느 쪽으로도 문서화되지 않았습니다. 현장 경험상 지원되지 않는 것으로 보이며, 안정적인 배치는 관리 VLAN에 속한 포트 그룹의 전용 인터페이스입니다. 이를 기반으로 설계하기 전에 F5에 확인하십시오.

3노드 사이트에서 Management Network를 활성화했는데 노드가 SLO로만 실행되었습니다. 이유는 무엇입니까?

섹션 제목: “3노드 사이트에서 Management Network를 활성화했는데 노드가 SLO로만 실행되었습니다. 이유는 무엇입니까?”

이 옵션이 다중 노드 CE Site에서 지원되지 않기 때문입니다. 사이트 개체는 설정을 승인하지만 클러스터는 추가 인터페이스를 생성하지 않으므로 외부 인터페이스가 정상적으로 작동하는 SLO 인터페이스로 표시됩니다. 이는 지원되는 구성 한계일 뿐 프로비저닝 오류가 아니며, 해당 사이트 개체에서 수정할 수 없습니다. High Availability는 생성 후 변경할 수 없습니다.

사이트 배포 후 관리를 SLO에서 다른 곳으로 이동할 수 있습니까?

섹션 제목: “사이트 배포 후 관리를 SLO에서 다른 곳으로 이동할 수 있습니까?”

아니요, SLO를 재구성하는 방식으로는 불가능합니다. 노드가 등록되고 배포된 후에는 SLO의 IP 및 MAC 주소를 변경할 수 없습니다. 가상 호스트, 로드 밸런서 및 오리진 디스커버리를 다른 인터페이스나 세그먼트에 배치하여 데이터 평면을 SLO에서 이동할 수는 있습니다.

인터페이스는 어떤 순서로 할당됩니까?

섹션 제목: “인터페이스는 어떤 순서로 할당됩니까?”

관리 네트워크가 활성화된 경우: 관리가 먼저, 그 다음 SLO, 그 다음 SLI로서의 추가 인터페이스. 활성화되지 않은 경우: SLO가 먼저, 그 다음 SLI로서의 추가 인터페이스. 게스트 속성이 설정되도록 첫 번째 전원을 켜기 전에 인터페이스를 연결하고, 나중에 인터페이스를 추가하거나 변경하기 전에 노드 전원을 끄십시오.

CE에는 몇 개의 인터페이스가 있어야 합니까?

섹션 제목: “CE에는 몇 개의 인터페이스가 있어야 합니까?”

플랫폼에서 요구하는 최소한의 인터페이스는 1개의 SLO 인터페이스입니다. 관리 트래픽이 애플리케이션 트래픽과 인터페이스를 공유해서는 안 되는 경우 제어 평면용 SLO와 최소 2개의 데이터 평면 인터페이스를 포함하여 3개를 계획하십시오. 이 배포는 SLO, external, internal의 해당 구조를 사용합니다.