네트워크 인프라 이해하기 · 제2부 · 가까운 장비까지 데이터는 어떻게 전달될까
같은 스위치에 연결된 장비를 서로 직접 통신하지 못하도록 어떻게 나눌까
Access 분류와 802.1Q Tag로 하나의 물리망을 여러 Broadcast 도메인으로 나누는 법
같은 스위치에 연결된 포트라도 VLAN이 다르면 서로 다른 Broadcast Domain에 속합니다. 액세스 포트는 단말의 프레임을 한 VLAN에 넣고, Trunk는 802.1Q Tag를 사용해 여러 VLAN의 프레임을 스위치 사이로 운반합니다. 이 글에서는 프레임이 들어오고 나갈 때 VLAN 소속을 판단하는 순서와 Native VLAN·Allowed VLAN이 어긋나는 지점을 설명합니다.
한 대의 스위치 안에서 Broadcast가 서로 섞이지 않는 여러 네트워크를 만드는 방법↑
스위치가 VLAN을 사용하면 같은 MAC Address Table도 VLAN Context와 함께 조회합니다. VLAN 10의 Broadcast와 Unknown Unicast는 VLAN 20 포트로 플러딩되지 않습니다.
이 분리는 Broadcast 범위를 줄이고 조직·서비스별 정책 경계를 만드는 출발점입니다. VLAN 자체가 완전한 보안 정책은 아니며, 서로 다른 VLAN 사이의 통신 허용은 L3 Gateway와 방화벽·ACL에서 결정합니다.
포트 1과 포트 2가 같은 물리 스위치에 있어도 각각 VLAN 10과 VLAN 20이면 ARP Broadcast는 서로에게 전달되지 않습니다. 스위치는 MAC Address만 조회하지 않고 VLAN Context와 MAC을 함께 사용합니다. 동일한 MAC 값이 서로 다른 격리 환경에 나타나더라도 별도 전달 Entry로 다룰 수 있는 이유입니다. VLAN은 물리 상자를 나누는 것이 아니라 L2 전달과 플러딩의 논리적 범위를 나눕니다.
보통 VLAN 하나에 IP 서브넷 하나를 대응시키지만 두 개념이 같은 것은 아닙니다. 하나의 VLAN에 여러 IP 프리픽스를 둘 수도 있고, 서로 끊긴 VLAN에 같은 프리픽스를 설정할 수도 있습니다. 이런 구성은 일반적인 단말의 로컬 판단과 게이트웨이 설정을 복잡하게 만들 수 있으므로, 필요한 이유와 통신 조건을 따로 검토해야 합니다. 운영 문서에는 VLAN ID, IP 프리픽스와 게이트웨이의 대응을 함께 기록합니다.
VLAN은 보안 정책 그 자체가 아니라 분리된 전달 영역입니다. 서로 다른 VLAN이면 기본 L2 통신은 되지 않지만, Inter-VLAN 라우팅과 허용 정책이 있으면 통신할 수 있습니다. 설계에서는 사용자·서버·관리망을 나누는 목적, Gateway 위치, Broadcast·장애 범위와 L3 정책을 함께 정해야 VLAN 번호 목록이 실제 격리 요구로 이어집니다.
이 절의 근거 IEEE 802.1Q-2022
도해에서 확인할 내용 Flat 네트워크의 Broadcast 확산과 VLAN 10·20·30으로 분리한 Broadcast 도메인을 비교합니다. 플랫 네트워크의 ARP 요청 수신 범위와 VLAN 분리 뒤 VLAN 10 안에만 머무는 요청을 대조해, 다른 VLAN에는 같은 요청이 전달되지 않는다는 점을 확인합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
Untagged 프레임이 액세스 포트에 들어오면 스위치는 어느 VLAN으로 분류할까↑
일반 단말이 연결된 액세스 포트는 보통 Untagged Ethernet 프레임을 받습니다. 스위치는 포트 설정을 보고 그 프레임을 특정 VLAN에 속한 것으로 분류합니다. 내부 전달 과정에서는 VLAN ID와 출발지·목적지 MAC을 함께 사용합니다.
반대 방향으로 액세스 포트에 내보낼 때는 일반적으로 단말이 이해할 평범한 Ethernet 프레임으로 전달합니다. 따라서 사용자는 자신의 NIC에서 802.1Q Tag를 보지 못해도 VLAN 안에서 통신할 수 있습니다.
PC가 보낸 프레임에는 VLAN Tag가 없지만 스위치는 수신 포트의 Access VLAN 설정을 Ingress 분류 기준으로 사용합니다. 내부 스위칭 Pipeline에서는 이 프레임을 VLAN 10 소속으로 표시해 VLAN 10의 MAC 테이블과 전달 상태를 조회합니다. 다른 액세스 포트로 내보낼 때는 다시 Untagged 형태가 되므로 단말은 Tag 처리 기능 없이도 VLAN 10의 일원으로 통신합니다.
IP Phone 뒤에 PC가 연결된 환경에서는 Data VLAN과 Voice VLAN을 한 포트에서 다르게 분류하는 구현도 있습니다. Phone은 협상 정보를 받아 Voice 프레임에 Tag를 붙이고 PC 프레임은 Untagged로 보낼 수 있습니다. 이 경우 포트를 단순한 Access 하나로만 보면 캡처를 오해할 수 있습니다. 장비가 Ingress 프레임을 어떤 조건으로 어느 VLAN에 분류하는지, 허용되지 않은 Tag를 어떻게 처리하는지 플랫폼 정책을 확인해야 합니다.
따라서 패킷 캡처 위치에 따라 같은 통신이 Untagged 또는 Tagged로 보일 수 있습니다. 일반적인 호스트 NIC 앞에서는 Untagged로 보이지만, Trunk Mirror의 VLAN Tag 표시 여부는 미러링 설정과 캡처 장비의 태그 보존 동작에 따라 달라집니다. Voice VLAN, 인증 기반 동적 VLAN과 Tagged 서버 NIC처럼 Access 동작에 예외가 있을 수 있으므로 포트 Mode와 실제 Ingress 분류 결과를 함께 확인합니다.
이 절의 근거 IEEE 802.1Q-2022 · Cisco Configure VLAN Trunking
도해에서 확인할 내용 VLAN마다 별도 액세스 포트와 케이블을 쓰는 세 스위치의 연결을 비교합니다. Untagged 프레임이 오가는 이 예에서는 VLAN 10·20 케이블과 양 끝 포트의 VLAN 설정을 함께 확인합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
여러 VLAN의 프레임이 Trunk 하나를 건너면서도 소속을 잃지 않는 이유↑
스위치 사이 Uplink 하나로 여러 VLAN을 운반하려면 수신 스위치가 각 프레임의 소속을 구분해야 합니다. 802.1Q Tag에는 VLAN Identifier를 포함한 제어 정보가 들어갑니다.
Trunk는 모든 VLAN을 자동으로 허용한다는 뜻이 아닙니다. Allowed VLAN 목록에 없는 VLAN의 프레임은 전달하지 않을 수 있습니다. 양쪽 Uplink의 Mode, Allowed 목록과 VLAN 존재 여부가 함께 맞아야 합니다.
스위치 A가 VLAN 10 프레임을 Trunk로 내보낼 때 802.1Q 헤더의 VLAN ID에 10을 기록하면 스위치 B는 수신 후 같은 VLAN 10 Context에서 MAC 조회를 이어 갈 수 있습니다. Tag에는 Priority 정보도 포함되지만, VLAN 분리에서 핵심은 12비트 VLAN Identifier입니다. Tag 삽입으로 프레임 형식과 길이가 달라지고 FCS도 링크에서 새로 계산되므로 캡처 위치에 따라 Tag가 보이거나 NIC Offload로 숨을 수 있습니다.
양쪽이 Trunk여도 VLAN 10이 한쪽 Allowed List에서 빠져 있으면 프레임은 경계를 넘지 못합니다. 또한 스위치 B에 VLAN 자체가 존재하지 않거나 해당 STP Instance가 Uplink를 막고 있어도 같은 증상이 납니다. “Trunk Up”은 물리 링크와 Trunk Mode의 증거일 뿐 모든 VLAN의 전달 보장이 아닙니다. VLAN별 Tx·Rx 카운터와 Tag를 확인해야 어느 VLAN까지 실제로 통과하는지 알 수 있습니다.
Trunk라고 해서 모든 VLAN이 자동으로 통과하는 것은 아닙니다. 양쪽 링크의 Trunk Mode, Allowed VLAN 목록, VLAN의 생성·활성 상태가 맞아야 합니다. Port-Channel을 Trunk로 쓴다면 개별 Member가 아니라 논리 인터페이스에서 일관된 VLAN 정책을 확인하며, 중간 장비마다 같은 VLAN이 허용되는지 End-to-End로 추적합니다.
이 절의 근거 IEEE 802.1Q-2022 · Cisco Configure VLAN Trunking
도해에서 확인할 내용 IEEE 802.1Q Tag의 VLAN ID를 이용해 하나의 Trunk가 여러 VLAN 프레임을 운반하는 구조입니다. 링크 위의 Tag V10·Tag V20 표시와 양 끝의 Allowed 10,20 설정을 비교해 두 VLAN이 같은 케이블을 건너는 모습을 확인합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
Trunk 양쪽의 Native VLAN이 다르면 같은 Untagged 프레임을 다르게 해석한다↑
많은 Ethernet 스위치 구현은 Trunk에서 특정 Native VLAN의 프레임을 Untagged로 보낼 수 있습니다. 한쪽은 Untagged 프레임을 VLAN 10으로, 다른 쪽은 VLAN 20으로 해석하면 Broadcast와 제어 프레임이 예상치 못한 도메인으로 들어갈 수 있습니다.
Native VLAN을 쓰지 않는 설계처럼 보여도 장비의 기본 처리와 제어 프로토콜 요구를 확인해야 합니다. 양쪽 설정을 일치시키고 사용하지 않는 VLAN을 Native로 지정하는 운영 정책을 적용할 수 있지만, 구체적인 권고는 플랫폼과 보안 기준에 맞춥니다.
스위치 A의 Native VLAN이 10이고 스위치 B가 20이면 A가 Untagged로 보낸 VLAN 10 프레임을 B는 VLAN 20 소속으로 분류할 수 있습니다. 반대 방향도 다른 Context로 들어가므로 ARP와 제어 트래픽이 예상치 못한 Broadcast 도메인에 섞입니다. 사용자 Data가 우연히 적어 초기에는 드러나지 않다가 특정 Broadcast나 관리 프로토콜에서만 장애가 나타날 수 있습니다.
일부 플랫폼은 Native VLAN도 Tag를 붙이도록 설정할 수 있고, 제어 프로토콜의 Untagged 처리에는 별도 규칙이 있을 수 있습니다. 따라서 “Native VLAN을 사용하지 않는다”는 정책만 적지 말고 양쪽의 실제 Tagging Mode와 Untagged Ingress 처리값을 확인합니다. 사용하지 않는 VLAN을 Native로 두는 보안 권고도 모든 위험을 자동 제거하지 않습니다. Trunk Allowed List와 액세스 포트의 Tag 수용 정책이 함께 맞아야 합니다.
운영에서는 양쪽 Native VLAN을 동일하게 맞추고, 사용하지 않는 전용 VLAN을 선택하거나 모든 VLAN의 프레임에 Tag를 붙이는 정책을 장비 지원 범위에 맞게 적용합니다. Native VLAN Mismatch 경고만 지우는 데 그치지 말고, 캡처에서 실제 Untagged 프레임이 무엇인지와 양쪽 포트의 PVID·Allowed 목록을 확인해야 숨어 있는 연결을 찾을 수 있습니다.
이 절의 근거 IEEE 802.1Q-2022 · Cisco Configure VLAN Trunking
VLAN을 멀리까지 이어 놓을수록 Loop와 장애 범위도 함께 커질 수 있다↑
Trunk를 여러 경로로 연결하면 VLAN별 프레임이 Loop를 돌 수 있습니다. STP는 중복 L2 경로 중 일부를 대기시켜 Loop를 막고, Link Aggregation은 여러 물리 링크를 하나의 논리 링크로 보이게 합니다.
VLAN 설계에서는 Broadcast 도메인의 크기, STP 장애 범위, Trunk Allowed 목록과 Gateway 위치를 함께 봅니다. “어디서나 같은 VLAN을 연장”하면 이동은 쉬워도 장애와 변경 영향이 커질 수 있습니다.
한 VLAN을 여러 건물과 Data Center까지 연장하면 어느 한 포트의 Broadcast와 잘못된 Loop가 전체 범위로 퍼질 수 있습니다. STP는 Loop를 막지만 Root와 차단 링크가 예상과 다르면 트래픽이 먼 경로로 돌아가고 장애 전환 범위도 커집니다. Trunk에서 필요 없는 VLAN을 제거하면 플러딩 범위와 설정 노출을 줄일 수 있지만, Allowed List 관리가 불일치하면 연결 장애가 생깁니다.
Link Aggregation은 평행 링크를 하나의 논리 링크로 만들어 STP가 각 물리 링크를 별도 Loop로 보지 않게 합니다. 반면 서로 다른 두 경로를 단순히 Trunk로 추가하면 STP가 하나를 대기시키거나 구성 오류 시 Loop가 생깁니다. VLAN 확장 설계에서는 이동 편의뿐 아니라 Root 위치, 장애 도메인, Gateway와 복구 시간을 함께 봅니다. L3 경계를 가까이 두는 편이 장애와 변경 범위를 줄이는 경우도 많습니다.
VLAN을 연장할지는 애플리케이션의 실제 L2 인접성 요구, Gateway 위치, 이동 방식과 장애 격리 목표로 결정합니다. 같은 IP를 유지하려는 요구라면 DNS·Load Balancing으로 서비스 이름이나 가상 서비스 주소를 유지하는 것으로 충분한지 먼저 확인합니다. 호스트 주소 자체의 유지가 필요하다면 Route 이동 같은 L3 대안의 적용 조건을 따로 비교합니다. 연장이 필요하면 허용 경로를 최소화하고 Root 위치, Loop 방지, Broadcast 규모와 장애 시 차단 지점을 명시합니다.
이 절의 근거 IEEE 802.1Q-2022
VLAN 통신이 끊겼다면 두 Uplink에서 같은 프레임의 Tag를 비교한다↑
상황: 스위치 A의 VLAN 30 단말은 같은 스위치에서는 통신하지만 스위치 B의 VLAN 30 서버에는 도달하지 못합니다. 이 예에서는 Trunk가 VLAN 30을 태그하여 운반하고, 캡처가 그 태그를 보존한다고 가정합니다.
- 두 액세스 포트가 실제로 VLAN 30에 속하는지 확인합니다.
- Uplink 양쪽이 Trunk이며 VLAN 30이 Allowed 목록과 VLAN 데이터베이스에 있는지 봅니다.
- Uplink의 패킷 캡처나 장비 카운터에서 VID 30 프레임이 나가고 들어오는지 확인합니다.
- Native VLAN 불일치, STP 차단과 Port-Channel Member 불일치를 점검합니다.
- 수정 뒤 ARP Broadcast와 Unicast Reply가 같은 VLAN 안에서 왕복하는지 확인합니다.
문제 클라이언트의 ARP Request를 기준 패킷으로 잡습니다. 액세스 포트에서는 Untagged 프레임과 수신 VLAN 30 분류를, 스위치 A Uplink에서는 VID 30 Tag를, 스위치 B Uplink에서는 같은 Source MAC과 VID를 확인합니다. 스위치 B 액세스 포트에서는 Tag가 제거된 Broadcast가 나가야 합니다. 이 네 지점 가운데 처음 보이지 않는 경계가 Access 분류, Allowed VLAN, STP 또는 Trunk 문제의 위치입니다.
수정 뒤에는 Broadcast Request만 아니라 서버의 Unicast Reply와 이어지는 Data 프레임도 왕복하는지 봅니다. Uplink 양쪽의 Native VLAN, Allowed List와 Port-Channel Member 설정을 구성 Diff로 보존합니다. 캡처 NIC가 VLAN Tag Offload로 Tag를 숨기는지 확인하고 가능하면 스위치의 SPAN 위치와 VLAN 카운터를 함께 사용합니다. “VLAN 30을 추가했다”보다 어떤 프레임이 어느 Context로 통과했는지를 재검증해야 합니다.
핵심 증거는 “Trunk Up”이 아니라 특정 VLAN의 특정 프레임이 각 경계를 어떤 Tag로 통과했는지입니다. 이렇게 확인하면 VLAN 미허용, 잘못된 Access 분류, Native 불일치와 대상 호스트 문제를 서로 분리할 수 있습니다.
용어사전↑
출처와 검증
- IEEE 802.1Q-2022 — Bridge, VLAN과 Spanning Tree의 현행 표준 계열
- Cisco Configure VLAN Trunking — 802.1Q Trunk의 벤더 구현 예시
- IEEE 802.1Q Working Group — 802.1Q 표준과 개정 정보
Native VLAN, Allowed VLAN 기본값과 VLAN 데이터베이스 동작은 플랫폼에 따라 다릅니다. 구성 명령보다 프레임의 Tag와 VLAN 문맥을 기준으로 설명했습니다.