네트워크 인프라 이해하기 · 제2부 · 가까운 장비까지 데이터는 어떻게 전달될까

서로 다른 VLAN에 연결된 장비는 어떻게 통신할까

Gateway가 VLAN 경계에서 Route를 조회하고 새 L2 헤더로 패킷을 전달하는 과정

서로 다른 VLAN의 단말은 L2 스위칭만으로 직접 통신할 수 없습니다. 단말은 패킷을 Default Gateway로 보내고, SVI나 Router-on-a-Stick이 Route와 정책을 적용한 뒤 목적지 VLAN에 맞는 새 L2 헤더로 전달합니다. 이 글에서는 두 방식의 왕복 경로와 VLAN 경계에서 유지되는 값·바뀌는 값을 비교하고 장애 확인 지점을 정리합니다.

다른 VLAN의 서버로 보낼 때 PC가 먼저 찾는 것은 Gateway의 MAC이다↑

PC 10.10.10.25/24가 서버 10.20.20.80/24를 비교하면 네트워크가 다릅니다. PC는 서버 MAC을 ARP로 묻지 않고 Default Gateway 10.10.10.1의 MAC을 찾습니다.

Ethernet Src  PC MAC
    Ethernet Dst  VLAN 10 Gateway MAC
    IP Src        10.10.10.25
    IP Dst        10.20.20.80

Access 스위치는 이 프레임을 VLAN 10 안에서 Gateway가 있는 포트 또는 논리 인터페이스 방향으로 전달합니다.

PC가 만드는 첫 프레임 안에는 두 계층의 목적지가 함께 있습니다. Ethernet Destination은 VLAN 10의 Gateway MAC이고, IP Destination은 VLAN 20의 서버 10.20.20.80입니다. 스위치는 Gateway MAC으로 L2 전달하고, Gateway만 IP 헤더를 열어 Route 조회를 수행합니다. PC는 VLAN 20의 Tag나 서버 MAC을 알 필요가 없습니다. 현재 Broadcast 도메인 밖의 전달 책임을 Gateway에 넘기는 구조입니다.

PC의 ARP Cache에서 서버 IP가 아니라 10.10.10.1의 Entry가 보여야 정상입니다. 서버 IP를 ARP로 묻는다면 Mask나 더 구체적인 On-Link Route가 잘못되었을 수 있습니다. Gateway MAC을 알아냈어도 VLAN 10 Uplink가 끊기거나 Virtual Gateway가 다른 MAC으로 이동하면 첫 프레임이 도달하지 못합니다. Route 장애를 보기 전에 클라이언트의 로컬 판단과 Gateway L2 Reachability를 먼저 확인하는 이유입니다.

Gateway MAC을 못 찾으면 라우팅은 시작되기 전에 로컬 VLAN에서 멈춥니다. 이때 서버 VLAN의 MAC 테이블부터 조사해도 첫 실패 지점과 맞지 않습니다. PC의 주소·Mask·Route 결과, ARP Target과 VLAN 10에서 Gateway SVI까지 Request·Reply가 오가는지를 먼저 확인합니다. ARP가 완성된 뒤에야 SVI의 L3 카운터와 Route 조회를 조사합니다.

이 절의 근거 IEEE 802.1Q-2022 · IETF RFC 1812

서로 다른 VLAN이 만나는 L3 경계에서 통신 허용과 Log를 확인하기 쉽다↑

같은 VLAN 안의 일반 Unicast는 Gateway를 지나지 않으므로 Gateway ACL이 직접 보지 못합니다. 서로 다른 VLAN 사이의 트래픽은 L3 경계를 지나므로 Source·Destination Prefix와 L4 포트를 기준으로 정책을 적용하기 쉽습니다.

모든 정책을 SVI ACL 하나로 해결하려 하지 않습니다. Stateful Inspection, 사용자 식별과 애플리케이션 제어가 필요하면 방화벽 경로를 설계할 수 있습니다. 정책 위치가 바뀌면 비대칭 경로와 로그의 원래·변환 주소도 확인합니다.

VLAN 10에서 VLAN 20으로 가는 패킷은 반드시 Gateway의 Route·정책 지점을 지나므로 Source 10.10.10.25, Destination 10.20.20.80과 L4 포트를 기준으로 ACL을 적용할 수 있습니다. Ingress ACL과 Egress ACL은 패킷을 보는 방향과 인터페이스가 다르므로 같은 Rule도 위치에 따라 Match가 달라집니다. Implicit Deny, Established Keyword와 Fragment 처리 같은 플랫폼 조건도 확인해야 합니다.

같은 VLAN의 호스트끼리 직접 보내는 트래픽은 이 Gateway를 거치지 않습니다. 따라서 “VLAN 10 사용자끼리도 SVI ACL이 막는다”는 가정은 일반적인 L2 전달에서는 맞지 않습니다. East-West Inspection이 필요하면 Private VLAN, 호스트 방화벽, Inline 방화벽 또는 Fabric 정책처럼 실제 경로에 있는 제어 지점을 설계해야 합니다. 정책 목표와 패킷이 반드시 지나는 경계를 먼저 맞추는 것이 기능 선택보다 중요합니다.

모든 정책이 SVI에 있는 것은 아닙니다. 중앙 방화벽으로 Hairpin 라우팅하거나 VRF 간 Route Leaking, Distributed 방화벽을 사용할 수 있습니다. 실제 패킷 Path에서 어느 장비가 조회와 정책을 수행하는지 확인하고, Log의 Original Tuple과 Return 상태를 연결해야 한 방향 ACL과 서버 응답 문제를 구분할 수 있습니다.

이 절의 근거 IETF RFC 1812 · Cisco Inter-VLAN Routing

SVI가 Up 상태인데도 통신이 안 된다면 돌아오는 Route와 호스트 설정을 확인한다↑

SVI 상태는 해당 VLAN의 L2 활성 조건과 플랫폼 규칙에 영향을 받을 수 있습니다. SVI가 Up 상태이고 Route가 있어도 서버 Default Gateway가 다른 장비를 가리키면 응답이 다른 길로 나가 통신이 실패할 수 있습니다.

VRF가 다르거나 ACL이 한쪽 방향만 허용해도 같은 증상이 납니다. Source PC에서 Gateway ARP, L3 장비의 Route·Adjacency, 서버의 Gateway와 반환 Route를 순서대로 연결합니다.

일부 스위치는 VLAN이 생성되어 있고 그 VLAN에서 전달에 참여하는 포트가 하나 이상 Up 상태여야 SVI의 Line 프로토콜도 Up 상태로 유지합니다. 다른 플랫폼이나 가상 환경은 활성 조건이 다를 수 있습니다. 따라서 SVI IP에 접근할 수 있다는 사실만으로 VLAN 20 서버의 ARP까지 해결되었다고 볼 수는 없습니다. SVI 상태, Connected Route, Neighbor 항목과 실제 액세스 포트 상태를 각각 확인해야 합니다.

요청이 서버까지 도착해도 서버의 Mask나 Default Gateway가 틀리면 응답이 돌아오지 않습니다. 서버가 다른 라우터를 Gateway로 쓰면 Asymmetric Path가 생기고 중간 Stateful 방화벽이 응답을 거부할 수 있습니다. VRF가 다르면 같은 Prefix가 보여도 별도 라우팅 테이블을 조회합니다. 양 끝 호스트의 Route, 두 SVI의 VRF와 중간 정책을 왕복 방향으로 연결해야 “Gateway는 Up”이라는 한 상태가 가린 문제를 찾을 수 있습니다.

한 방향 패킷이 서버에 도착했다면 서버의 IP·Prefix·Gateway와 반환 Route를 확인합니다. 서버가 출발지 PC를 On-Link로 잘못 판단하면 같은 VLAN에 없는 호스트에 ARP하고, 다른 Gateway로 응답하면 Stateful 방화벽 정책이 비대칭을 거부할 수 있습니다. 양쪽 SVI의 ARP/Adjacency, FIB와 ACL 카운터를 같은 5-Tuple로 맞춥니다.

이 절의 근거 IETF RFC 1812 · Cisco Inter-VLAN Routing

용어사전↑