[서론] “설정 한 줄”이 전사 장애로 번지는 순간, 다들 한 번쯤 겪어요

ESXi가 연결된 스위치 포트는 겉보기엔 단순합니다. switchport mode trunk 딱 치면 끝날 것 같죠.
그런데 현실은 “톨게이트(스위치 포트)에서 차선 규제(VLAN Allowed)를 제대로 안 하면” 예고 없이 사고가 납니다.

• DTP 협상 프레임이 의미 없이 날아다니거나(효율/보안)
• Native VLAN이 기본값(=VLAN 1)인 채로 남아있다가(보안/장애)
• allowed vlan add를 안 붙여서(휴먼에러) 허용 VLAN이 통째로 날아가고
• STP 지연 때문에 서버 부팅 후 네트워크가 30~50초 늦게 붙어(운영 이슈)
• BPDU가 들어와 루프가 시작되면(대형 장애) 네트워크가 흔들립니다

이 글(2탄)은 “장애는 예방하는 게 아니라, 실수할 수 없게 만드는 것”이라는 관점에서 스위치 쪽 표준 CLI를 템플릿으로 정리해요. (3탄은 ESXi 설정으로 이어집니다.)

[본론] 시스코 스위치 설정: 단계별 CLI + “왜 필요한가”

아래 예시는 ESXi Host01의 vmnic0 uplink가 스위치 Gi1/0/1에 연결된 상황으로 작성했어요.

목표: VST 표준(ESXi 포트그룹에서 VLAN 태깅) 기준으로, 스위치 포트는 트렁크 + 최소 허용 VLAN + 더미 Native + STP 최적화까지 한 번에 끝내기

1) 사전 준비: 더미 Native VLAN(999) 생성

Native VLAN은 “태그 없는(untagged) 트래픽의 귀속처”입니다.
기본 Native VLAN 1을 그대로 두는 건 보안/운영 둘 다 위험해요.

• VLAN Hopping(더블 태깅) 공격면을 줄이고
• “Native VLAN mismatch” 같은 L2 사고를 줄이려면
• 안 쓰는 VLAN을 Native로 바꾸고, allowed 목록에서 제외하는 게 가장 강력합니다.

conf t
vlan 999
 name DEAD_NATIVE_VLAN
 shutdown
end

conf t
vlan 999
 name DEAD_NATIVE_VLAN
 shutdown
end

2) 인터페이스: 트렁크 강제 + DTP 차단(switchport nonegotiate)

왜 DTP를 끄나요?

• ESXi는 DTP를 이해하지 못합니다 → 협상 자체가 의미가 없어요.
• DTP가 켜져 있으면 불필요한 제어 트래픽이 돌고,
• 최악의 경우 DTP 악용으로 “트렁크 강제 전환” 같은 공격 시나리오도 거론됩니다.

conf t
interface GigabitEthernet1/0/1
 description Uplink_to_ESXi_Host01_vmnic0
 ! (레거시 장비에서 필요할 수 있음)
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
end

conf t
interface GigabitEthernet1/0/1
 description Uplink_to_ESXi_Host01_vmnic0
 ! (레거시 장비에서 필요할 수 있음)
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
end

한 끗 차이: Catalyst 9000 계열(IOS-XE)은 dot1q 고정인 경우가 많아 switchport trunk encapsulation dot1q가 아예 없거나 필요 없을 수 있어요. (명령이 안 먹으면 “정상”일 때가 많습니다.)

3) VLAN Allowed 최소화 + “add 누락 방지” 운영법

트렁크 기본값은 “가능한 모든 VLAN”이 흘러갈 수 있는 형태입니다.
ESXi uplink에 그걸 그대로 열면, ESXi 쪽에서 쓸데없는 브로드캐스트/플러딩 처리로 CPU를 갉아먹는 상황이 생깁니다(브로드캐스트 라디에이션).

3-1. 최초 구성(명시적으로 필요한 VLAN만)

conf t
interface GigabitEthernet1/0/1
 switchport trunk allowed vlan 10,20,30,100-110
end

conf t
interface GigabitEthernet1/0/1
 switchport trunk allowed vlan 10,20,30,100-110
end

3-2. 운영 중 VLAN 추가(핵심: add)

여기서 “전사 장애 썰”이 정말 많이 나옵니다.
add를 안 붙이면 기존 허용 목록이 통째로 바뀝니다.

• ❌ 잘못된 예(기존 10,20,30… 삭제되고 50만 남음)

switchport trunk allowed vlan 50

switchport trunk allowed vlan 50

• ✅ 올바른 예(기존 목록에 50만 추가)

switchport trunk allowed vlan add 50

switchport trunk allowed vlan add 50

실무 팁: 조직마다 다르지만, 사고가 잦은 팀은 아예 “add 금지”하고 항상 전체 목록을 텍스트로 관리해서 붙여넣기도 해요. 중요한 건 “실수할 여지를 없애는 절차”입니다.

4) Native VLAN 999 적용 + allowed에서 제외(핵심 보안 패턴)

더미 VLAN을 만들었으면, 포트에 적용합니다.

conf t
interface GigabitEthernet1/0/1
 switchport trunk native vlan 999
 ! 주의: allowed vlan에 999 넣지 마세요
 switchport trunk allowed vlan 10,20,30,100-110
end

conf t
interface GigabitEthernet1/0/1
 switchport trunk native vlan 999
 ! 주의: allowed vlan에 999 넣지 마세요
 switchport trunk allowed vlan 10,20,30,100-110
end

이 구성이 의미하는 바:

• 태그 없는 프레임은 Native 999로 분류
• 그런데 트렁크는 999를 허용하지 않음
• 결과적으로 Untagged 트래픽은 즉시 드롭(가장 깔끔한 차단)

5) STP: PortFast + BPDU Guard로 “부팅 지연/루프” 둘 다 잡기

ESXi는 일반적으로 물리 루프를 만들지 않지만, 스위치는 그걸 모릅니다.
그래서 STP가 기본 절차(리스닝/러닝)를 타면 30~50초 지연이 생길 수 있어요. 부팅/재기동 때 은근히 사람을 괴롭힙니다.

• PortFast(Edge Trunk): 링크 올라오면 즉시 Forwarding
• BPDU Guard: BPDU가 들어오면 “루프 징후”로 보고 포트 차단(Err-disable)

conf t
interface GigabitEthernet1/0/1
 spanning-tree portfast trunk
 ! 또는(플랫폼에 따라 권장)
 ! spanning-tree portfast edge trunk
 spanning-tree bpduguard enable
end

conf t
interface GigabitEthernet1/0/1
 spanning-tree portfast trunk
 ! 또는(플랫폼에 따라 권장)
 ! spanning-tree portfast edge trunk
 spanning-tree bpduguard enable
end

6) (선택) 점보 프레임 대응: MTU 9216을 쓰는 이유

스토리지(iSCSI), vMotion, vSAN 같은 대용량 트래픽을 쓰면 점보(MTU 9000) 설계가 자주 들어옵니다.
스위치 쪽에서 9216을 잡는 이유는 실무적으로 이렇습니다.

• 9000 “딱 맞춤”은 VLAN 태그/추가 캡슐화/플랫폼 오버헤드에서 여유가 부족할 수 있어요.
• 그래서 스위치/플랫폼은 보통 9216 같은 여유값을 안전값으로 잡는 설계가 많습니다.

conf t
interface GigabitEthernet1/0/1
 mtu 9216
end

conf t
interface GigabitEthernet1/0/1
 mtu 9216
end

주의: Catalyst 2960/3560/3750 등 일부는 system mtu jumbo처럼 글로벌 적용 + 재부팅이 필요할 수 있어요. 장비 계열별 차이는 운영 환경에 맞춰 확인해야 합니다.

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

[패킷 플로우] 스위치 내부에서 “태깅이 붙어 나가는” 과정 (Step Table)

트렁크 포트 기준: Native VLAN만 Untagged, 그 외 VLAN은 802.1Q 태그를 붙여 나갑니다.

[장애/휴먼에러 주의] add 누락 시나리오 & 예방법 체크리스트

add 누락 사고 시나리오(현실 버전)

• 기존: allowed vlan 10,20,30
• 작업자: “VLAN 50만 추가하면 돼요” → allowed vlan 50 입력
• 결과: 10/20/30이 제거되고 50만 남음 → 대량 통신 두절

예방법 체크리스트(실수 불가능하게)

• 변경 전 show run interface gi1/0/1로 기존 allowed 목록 캡처
• 추가 작업이면 무조건 allowed vlan add X 사용
• 대규모 변경은 전체 목록을 텍스트로 작성 후 붙여넣기
• 변경 직후 show interface trunk로 허용 VLAN/Native/STP 상태 확인
• 장애 시 “원인 추적”보다 먼저 최근 변경 이력(누가/언제/무엇을)부터 확인

[한 끗 차이 팁] 운영 품질을 올리는 디테일 5개

1. Description은 “호스트명+vmnic+역할”로 고정 포맷을 쓰세요.
   예: Uplink_to_ESXi_Host01_vmnic0 → 장애 때 케이블 뒤지는 시간이 줄어요.
2. Native VLAN 999는 ‘만들기’가 끝이 아니라 ‘allowed에서 제외’가 완성입니다.
   둘 중 하나라도 빠지면 효과가 반감돼요.
3. show interface trunk는 변경 후 필수 의식입니다.
   Allowed VLAN, Native VLAN, STP forwarding 상태가 한 번에 보입니다.
4. MTU 9216은 “여유값”입니다.
   9000 딱 맞추면 VLAN 태그/추가 캡슐화에서 예민해질 수 있어요.
5. BPDU Guard는 ‘내가 루프를 안 만든다’가 아니라 ‘남이 실수해도 막는다’입니다.
   “실수할 수 없게 만드는 것”의 대표 기능이에요.

[ISMS-P 관점 체크]

2.6.2 네트워크 접근 통제 관점

• 허용 VLAN 최소화(Allowed VLAN): 네트워크 접근 경계를 “명시적”으로 설정(최소 권한)
• Native VLAN 더미화(999) + 미허용: 태그 없는 트래픽/예외 경로를 차단해 우회 가능성을 낮춤
• DTP 차단(nonegotiate): 불필요한 협상/자동 동작을 제거 → 통제 가능한 상태 유지
• BPDU Guard: L2 루프/비정상 브리징을 “사전에 차단” → 가용성/통제 강화

2.10.2 취약점 점검 관점(운영 점검 포인트)

정기 점검 때 아래 항목을 “표준 명령어”로 뽑아 비교하면, 구성 취약점을 빨리 잡아냅니다.

• 트렁크/허용 VLAN/Native 확인: show interface trunk
• DTP 상태 확인(플랫폼별): show dtp interface gi1/0/1
• STP/PortFast/BPDU Guard 확인: show spanning-tree interface gi1/0/1 detail
• MAC 학습 확인(정상 통신 여부 힌트): show mac address-table interface gi1/0/1

[결론] 3줄 요약 + 다음 편 예고

1. ESXi uplink 트렁크는 “열기”가 아니라 통제(Allowed/Native/DTP/STP)를 설계하는 작업이에요.
2. nonegotiate로 DTP 끄고, allowed vlan add로 휴먼에러를 막고, Native 999 더미화로 우회/사고를 줄이세요.
3. PortFast/BPDU Guard는 부팅 지연과 루프를 동시에 잡는 “실수 방지 장치”입니다.

다음 3탄에서는 ESXi(vSwitch/vDS) 포트그룹(VST/VGT), VLAN 4095 주의점, vmkping으로 점보 검증까지 “호스트 쪽 설정”을 이어서 정리하겠습니다.