[서론] “스위치 설정은 끝났는데 왜 통신이 안 될까?” — 답은 ESXi 쪽 ‘태그/MTU/검증’에 있어요

2탄에서 스위치 포트는 트렁크로 깔끔하게 만들었죠.
그런데 현장에서는 여기서부터 삽질이 시작됩니다.

• 포트그룹 VLAN을 안 넣어서 태그가 엉뚱하게 가거나
• MTU는 9000이라고 해놓고, vmk가 1500이라 대용량에서만 끊기거나
• 마지막으로 vmkping 검증을 안 해서 “되는 줄 알았는데” 야간 장애로 이어지거나

오늘(3탄)은 한 문장으로 요약하면 이겁니다.

검증되지 않은 설정은 설정이 아니다.
ESXi는 “VLAN 태깅(VST)”과 “MTU End-to-End”를 맞춘 뒤, vmkping으로 끝장을 봐야 합니다.

[본론] ESXi에서 망분리(VST) + Jumbo(MTU 9000) + vmkping 검증까지 한 번에

1) VLAN 태깅 모드 3종 정리: EST vs VST vs VGT

✅ VST (Virtual Switch Tagging) — 표준/권장

• 스위치: 트렁크로 Tagged 프레임 전달
• ESXi vSwitch/vDS: 태그 확인 → 해당 포트그룹으로 분배(필요 시 태그 제거)
• 구성 포인트: 포트그룹에 VLAN ID(1~4094) 부여

EST (External Switch Tagging) — 거의 안 씀

• 스위치가 태깅/언태깅 다 처리 → ESXi에는 Untagged만 옴
• VLAN 늘수록 NIC/케이블도 늘어나는 구조라 확장성 최악

⚠️ VGT (Virtual Guest Tagging) — 특수 목적

• ESXi는 태그를 “건드리지 않고” VM에 그대로 전달
• 포트그룹 VLAN 4095(태그 보존/모든 VLAN 허용)
• 가상 라우터/방화벽/IDS처럼 “VM이 여러 VLAN을 직접 다뤄야 할 때만” 사용
  → 일반 VM에 4095 주면 망분리 취지가 흔들릴 수 있어요.

2) VST 구성: 포트그룹에 VLAN ID 부여하기 (GUI/CLI)

2-1. GUI(가장 흔한 흐름)

• vSwitch(Standard Switch) 또는 vDS(Distributed Switch)
• Port Group 생성 → VLAN ID 지정
  • 예: VM_Network_VLAN10 → VLAN ID = 10
  • 예: VM_Network_VLAN20 → VLAN ID = 20

주의(중요): VST 환경에서 스위치 쪽 Native(Untagged)가 들어오면 ESXi가 기대하는 형태(Tagged)와 어긋나서 드롭/미동작이 나올 수 있어요.
그래서 2탄에서 Native 999 더미화가 같이 붙는 겁니다.

2-2. CLI 예시(표준 vSwitch 기준)

# 포트그룹 생성
esxcli network vswitch standard portgroup add -p "VM_Network_VLAN10" -v vSwitch0
# VLAN ID 설정(VST)
esxcli network vswitch standard portgroup set -p "VM_Network_VLAN10" --vlan-id 10

# 포트그룹 생성
esxcli network vswitch standard portgroup add -p "VM_Network_VLAN10" -v vSwitch0
# VLAN ID 설정(VST)
esxcli network vswitch standard portgroup set -p "VM_Network_VLAN10" --vlan-id 10

3) Jumbo Frame(MTU 9000): ESXi “전 경로 일치”가 핵심

점보는 “한 군데만 9000” 해놓고 끝나는 게 아니라, End-to-End로 맞춰야 합니다.

3-1. ESXi에서 맞춰야 할 지점(필수 3곳)

1. vSwitch / vDS MTU: 9000
2. VMkernel Adapter(vmk) MTU: 9000 (vMotion/iSCSI/vSAN/관리망 등 해당 vmk)
3. (필요 시) VM 내부 MTU: 9000 (VM끼리 점보를 쓸 계획이면)

이거 하나라도 1500이면?
작은 통신은 되다가 대용량에서만 단편화/드롭으로 “조용히 장애”가 납니다.
이거 모르면 진짜 밤샙니다.

3-2. CLI 예시(표준 vSwitch MTU 설정)

# vSwitch MTU를 9000으로
esxcli network vswitch standard set -v vSwitch0 -m 9000

# vSwitch MTU를 9000으로
esxcli network vswitch standard set -v vSwitch0 -m 9000

4) vmkping 정밀 검증: -d와 -s 8972는 ‘공식 암기’ 급입니다

설정 후 검증은 ping 한 번으로 끝내면 안 됩니다.
점보는 반드시 DF(단편화 금지)를 걸고 “진짜 9000이 통과하는지” 봐야 해요.

4-1. 명령어

vmkping -I vmk1 -d -s 8972 <Target_IP>

vmkping -I vmk1 -d -s 8972 <Target_IP>

4-2. 옵션 의미

• -I vmk1 : 어느 VMkernel NIC로 보낼지 지정
• -d : Do Not Fragment(DF) 설정 → 중간에서 쪼개야 하면 실패하도록 강제
• -s 8972 : ICMP payload 크기 지정(핵심)

4-3. 왜 8972인가? (계산법)

• Payload 8972
  • ICMP Header 8
  • IP Header 20
    = 9000 bytes

즉, -s 8972가 “MTU 9000을 정확히 찌르는 값”입니다.

함정: -s 9000으로 때리면
9000(payload) + 28(header) = 9028이 되어 실패할 수 있어요.
“9000으로 했는데 안 되네?” 하고 삽질하는 대표 케이스입니다.

5) 표준 스위치(Standard vSwitch) vs 분산 스위치(vDS): Trunk Range가 갈라지는 포인트

표준 vSwitch

• VLAN 4095 = 사실상 “모든 VLAN 태그 보존” (VGT 성격)
• 범위를 제한하기 어렵고, 한 VM에 4095 주면 통제가 거칠어질 수 있어요.

vDS(Distributed Switch)

• 엔터프라이즈 환경에서 강력한 이유가 이거예요:
• Trunk Range 지정 가능 (예: 10-20,30)
  • VM이 여러 VLAN을 봐야 해도 필요한 범위만 열어줄 수 있음
  • 보안/감사 관점에서 설명이 훨씬 깔끔해집니다.

[용어 정리] (필수 테이블)

[패킷 플로우] vmnic → vSwitch/vDS → Port Group → VM (Step Table)

[장애/휴먼에러 주의] MTU 불일치 체크리스트(단편화/드롭)

아래 증상 중 하나라도 보이면 “점보 불일치”를 의심해요.

증상

• SSH/웹은 되는데 백업/복사/vMotion에서만 멈춤 또는 속도 급락
• 큰 패킷에서 재전송 증가, 지연 급증
• “가끔 되다가 가끔 끊김” 같은 애매한 현상

체크리스트(End-to-End)

• 스위치 포트/경로 MTU가 9000 이상(실무에선 9216 여유값)인가?
• ESXi vSwitch/vDS MTU = 9000인가?
• 해당 트래픽이 지나는 vmk MTU = 9000인가? (vMotion/vSAN/iSCSI 등)
• (필요 시) VM OS MTU도 9000인가?
• vmkping -d -s 8972가 성공하는가? (실패하면 아직 끝난 게 아님)

[한 끗 차이 팁] (실무 디테일 6개)

1. VLAN 4095는 “만능 VLAN”이 아니라 “통제 포기 버튼”에 가깝습니다.
   필요한 VM에만, 필요 범위는 vDS Trunk Range로 좁히는 게 정석이에요.
2. VST 환경에서는 데이터 VLAN을 Native(Untagged)로 쓰면 사고 확률이 올라갑니다.
   “태그가 있어야 할 곳에 태그가 없다”가 가장 흔한 미스매치예요.
3. vmkping은 반드시 -d를 붙이세요.
   단편화가 되면 ‘되는 것처럼’ 보일 수 있어서, DF로 강제 실패시키는 게 맞습니다.
4. -s 8972는 암기해도 손해가 없습니다.
   9000을 정확히 찌르는 값이라, 점보 검증의 표준값이에요.
5. 점보는 “설정”보다 “검증 자동화”가 중요합니다.
   변경 후 점보 검증을 체크리스트에 넣어두면 야간 장애가 확 줄어요.
6. VMkernel 트래픽을 목적별로 분리하면(관리/vMotion/iSCSI) 장애 분석이 쉬워집니다.
   망분리의 목적은 보안뿐 아니라 “문제 격리”에도 있어요.

[ISMS-P 관점 체크]

2.6.5 무선 및 원격접근 통제 / 관리망 분리 & 접근 증적

ESXi 관리 접점은 공격자 입장에선 “왕국 창고 관리자 키”입니다. 그래서 설계/운영에 증빙이 남아야 해요.

• 관리망 분리(Management VLAN 별도 운영)
  • 관리 트래픽(vmkmgmt)은 업무/서비스 VLAN과 분리
  • 방화벽/ACL로 접근 주체(관리자 PC, 점프서버) 제한
• 원격접근 통제(VPN/Jump Host 경유, MFA 등)
  • ESXi/ vCenter 직접 노출 금지(가능하면)
• 접근 증적/감사 로그
  • vCenter/ESXi 로그인, 설정 변경 이력, 네트워크 구성 변경 기록을 남기고 정기 점검(2.10.2 취약점 점검과도 연결)

정리: “VLAN 나눴습니다”만으로는 부족하고, 관리망 접근 경로를 제한하고 로그로 증빙해야 ISMS-P 관점에서 설계가 완성됩니다.

[결론] 시리즈 마무리 3줄 요약

1. ESXi 망분리는 VST(포트그룹 VLAN ID)로 완성되고, Native(Untagged)는 설계에서 제거하는 게 안전합니다.
2. Jumbo Frame은 vSwitch/vDS–VMkernel(vmk)까지 End-to-End MTU 9000 일치가 핵심입니다.
3. 검증은 vmkping -I <vmk> -d -s 8972로 끝장을 봐야 맘이 편합니다.