[Nutanix AHV] 서비스망 VLAN 1만 통신이 안 될 때 — 계층별로 범위를 좁혀 찾은 AOS-CX 네이티브 VLAN 태깅 문제
들어가며
원인은 TOR 스위치 트렁크 포트의 vlan trunk native 1 뒤에 tag 옵션 한 단어가 빠진 것이었습니다. 증상은 “서비스망 VLAN 1 서브넷만 핑이 안 된다”였고, 처음엔 서버·하이퍼바이저·스위치 중 어디가 문제인지 알 수 없었습니다.
신규 인프라 구축 건으로 HCI 서버와 HCI TOR 스위치를 납품·구축한 뒤, 고객사 업링크 테스트 단계에서 접수된 장애입니다. 고객사 환경이라 작업 화면은 캡처하지 못했습니다. 이 글에서는 확인 순서와 각 단계에서 무엇을 배제했는지를 중심으로 정리합니다.
환경 구성
HCI 노드(Nutanix AHV)의 가상 스위치는 용도별로 3개로 나뉘어 있었고, 서비스망(vs1)만 트렁크로 구성되어 있었습니다.
| 가상 스위치 | 용도 | 사용 VLAN | 스위치 포트 모드 |
|---|---|---|---|
| vs0 | 클러스터망 (CVM·AHV) | 1개 | Access |
| vs1 | 서비스망 | VLAN 1, VLAN 5 | Trunk |
| vs2 | 개발망 | 1개 | Access |
TOR 스위치는 AOS-CX 계열이며, 서비스망 업링크는 interface 1/1/7 ~ 1/1/12 포트에 연결되어 있습니다.
증상
vs1의 VLAN 1 서비스용 서브넷에 할당한 VM에서 핑이 나가지 않는다.
고객사로부터 위와 같은 연락을 받았습니다. 구축 직후에는 드러나지 않았고, 이후 고객사 업링크 테스트 과정에서 확인된 증상입니다.
트러블슈팅 과정
4단계 만에 문제 범위를 “TOR 스위치의 VLAN 1 처리”로 좁혔습니다. 각 단계는 한 가지 가설을 확인하거나 배제하는 데 집중했습니다.
| 단계 | 확인한 것 | 결과 | 배제된 것 / 좁혀진 범위 |
|---|---|---|---|
| 1 | VLAN 1 VM → 게이트웨이, 같은 L2의 스위치 VIP로 핑 | 둘 다 실패 | L3 문제 아님 → L2 구간 문제 |
| 2 | CVM(vs0) → 게이트웨이 핑 | 정상 | 스위치 장비 자체·상위망 이상 아님 |
| 2-1 | vs1 물리 본딩 상태, 업링크 링크 상태 | 모두 정상 | 케이블·NIC·본딩 등 물리 계층 아님 |
| 3 | 같은 vs1의 VLAN 5 서브넷 통신 | 정상 | VLAN 1만 실패 → VLAN 태깅 처리 문제 |
| 4 | TOR 스위치 서비스망 포트 컨피그 확인 | 원인 발견 | 네이티브 VLAN 1에 tag 옵션 누락 |
1단계 — L3 문제인가, L2 문제인가
게이트웨이로만 핑이 안 된다면 라우팅이나 게이트웨이 쪽을 봐야 하고, 같은 L2 대역의 스위치 VIP까지 안 된다면 L2 구간을 봐야 합니다. 확인 결과 스위치 VIP로도 통신이 되지 않아 L2 구간 문제로 범위를 좁혔습니다.
2단계 — 스위치 전체 문제인가, 서비스망만의 문제인가
같은 스위치를 쓰는 클러스터망(vs0)의 CVM에서 게이트웨이로 핑을 보내니 정상 응답이 왔습니다. 스위치 장비 자체나 상위 네트워크의 문제는 아니라는 뜻입니다.
이어서 vs1의 물리 본딩 구성과 업링크 링크 상태를 확인했고, 모두 정상이었습니다. 물리 계층도 배제했습니다.
3단계 — vs1 전체 문제인가, VLAN 1만의 문제인가
같은 vs1 트렁크를 타는 VLAN 5 서브넷은 정상 통신이 됐습니다. 물리 경로·본딩·스위치 포트가 모두 같은데 VLAN 1만 안 된다면, 남는 차이는 VLAN 태깅을 처리하는 방식뿐입니다. 이 시점에서 스위치 포트의 VLAN 설정 문제라고 판단하고 컨피그를 확인했습니다.
4단계 — 스위치 컨피그 확인
서비스망 포트에는 vlan trunk native 1과 vlan trunk allowed 1,5가 설정되어 있었습니다. 처음에는 이 설정만 보고 트렁크가 정상이라고 판단했습니다. 하지만 AOS-CX에서는 네이티브 VLAN이 기본적으로 Untagged로 처리됩니다. 그래서 VLAN 1을 태그된 상태로 주고받으려면 tag 옵션을 별도로 넣어야 했습니다.
원인 분석
스위치는 VLAN 1을 Untagged로, AHV는 VLAN 1을 Tagged로 다루고 있어 양쪽의 VLAN 1 프레임 형식이 맞지 않았습니다. VLAN 5는 양쪽 모두 Tagged라 문제가 없었습니다.
AOS-CX 쪽 동작 (문서 기준)
vlan trunk native tag — 네이티브 VLAN에 태깅을 활성화한다. 해당 VLAN ID로 태그된 수신 패킷만 받고, 태그 없는 패킷은 BPDU를 제외하고 폐기하며, 송신 패킷에는 태그를 붙인다.
— HPE Aruba Networking AOS-CX CLI Reference (요약 번역)
즉 tag 옵션이 없으면 네이티브 VLAN은 Untagged로 송수신되고, 트렁크 포트의 기본 네이티브 VLAN은 VLAN 1입니다.
Nutanix AHV 쪽 동작
Nutanix에서 네이티브 VLAN은 0이다. VLAN 0으로 서브넷을 만들면 트래픽에 태그를 붙이지 않는다.
— Nutanix Community, “Nutanix Native VLAN on trunk link” (요약 번역)
따라서 AHV 서브넷의 VLAN ID를 1~4094로 지정하면 해당 트래픽에는 802.1Q 태그가 붙습니다.
두 동작을 맞춰 보면 (조치 결과로부터의 추론)
tag 옵션을 넣자 통신이 정상화됐습니다. 이는 스위치가 “VLAN 1로 태그된 프레임만 받는” 상태가 되자 통신이 됐다는 뜻입니다. 따라서 AHV는 VLAN 1 트래픽에 태그를 붙여 보내고 있었고, 수정 전 스위치는 VLAN 1을 태그 없이 주고받고 있어 양방향 형식이 어긋났던 것으로 판단합니다.
조치
서비스망 트렁크 포트(1/1/7~1/1/10, 1/1/12)의 vlan trunk native 1을 vlan trunk native 1 tag로 변경했습니다. 1/1/11은 Access 포트라 변경하지 않았습니다.
수정 전
interface 1/1/7
description Service
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed 1,5
interface 1/1/8
description Service
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed 1,5
interface 1/1/9
description Service
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed 1,5
interface 1/1/10
description Service
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed 1,5
interface 1/1/11
description Service
no shutdown
no routing
vlan access 1
interface 1/1/12
description Service
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed 1,5
수정 후
interface 1/1/7
description Service
no shutdown
no routing
vlan trunk native 1 tag
vlan trunk allowed 1,5
interface 1/1/8
description Service
no shutdown
no routing
vlan trunk native 1 tag
vlan trunk allowed 1,5
interface 1/1/9
description Service
no shutdown
no routing
vlan trunk native 1 tag
vlan trunk allowed 1,5
interface 1/1/10
description Service
no shutdown
no routing
vlan trunk native 1 tag
vlan trunk allowed 1,5
interface 1/1/11
description Service
no shutdown
no routing
vlan access 1
interface 1/1/12
description Service
no shutdown
no routing
vlan trunk native 1 tag
vlan trunk allowed 1,5
변경 후 VLAN 1 서브넷 VM에서 통신 테스트를 진행했고 정상 응답을 확인했습니다.
정리
이번 건의 핵심은 “되는 것과 안 되는 것을 비교해 차이를 좁혀 가는” 방식이었습니다. 서버·하이퍼바이저·스위치를 모두 직접 구축했기 때문에, 각 구간을 어떤 기준으로 나눠 확인해야 하는지 바로 정할 수 있었습니다.
- 같은 L2 내부 통신부터 확인해 L3 문제와 L2 문제를 먼저 갈랐습니다.
- 같은 스위치를 쓰는 다른 망(vs0)과 비교해 장비 전체 문제를 배제했습니다.
- 물리 본딩·링크를 확인해 물리 계층을 배제했습니다.
- 같은 트렁크의 다른 VLAN(VLAN 5)과 비교해 “VLAN 1만의 처리 방식”으로 범위를 좁혔습니다.
트렁크를 구성할 때는 네이티브 VLAN을 Tagged로 쓸지 Untagged로 쓸지를 하이퍼바이저 서브넷의 VLAN ID와 함께 맞춰 봐야 한다.
vlan trunk native 1과 allowed 1,5만 보고 트렁크 설정이 끝났다고 생각했던 부분이 아쉬웠습니다. 위 내용은 이번 건을 통해 확실히 익힌 점입니다.
참고자료
- HPE Aruba Networking AOS-CX CLI — vlan trunk native
https://arubanetworking.hpe.com/techdocs/AOS-CX/AOSCX-CLI-Bank/cli_6300-6400/Content/Chp_VLANs/VLAN_cmds/vla-tru-nat.htm - HPE Aruba Networking AOS-CX CLI — vlan trunk native tag
https://arubanetworking.hpe.com/techdocs/AOS-CX/AOSCX-CLI-Bank/cli_6300-6400/Content/Chp_VLANs/VLAN_cmds/vla-tru-nat-tag.htm - Nutanix Community — Nutanix Native VLAN on trunk link
https://next.nutanix.com/installation-configuration-23/nutanix-native-vlan-on-trunk-link-43268