VLAN은 어디까지 이어 두고 라우팅은 어디에서 시작할까

같은 VLAN을 다른 통신실까지 이어야 하는 이유부터 확인한다 ↑

VLAN을 다른 통신실까지 이어야 한다면, 단말들이 꼭 같은 L2 구간에 있어야 하는지부터 확인합니다. 애플리케이션이 IP로 통신한다는 사실만으로 여러 통신실을 하나의 방송 범위에 둘 필요가 생기지는 않습니다.

같은 VLAN 안의 단말은 로컬 링크에서 서로의 MAC 주소를 찾아 직접 프레임을 주고받을 수 있습니다. 라우팅 경계를 사이에 두면 단말은 원격 목적지 대신 자기 게이트웨이에 프레임을 보냅니다. 이 전달 방식의 차이가 실제 업무 요구에 영향을 주는지 먼저 확인해야 합니다.

장비 이동 뒤에도 같은 주소를 유지해야 한다거나 특정 L2 동작에 의존한다면 그 이유를 구체적으로 적습니다. 단순한 운영 관습과 애플리케이션의 필수 조건을 구분합니다. 요구를 바꿀 수 없는 경우에는 VLAN 확장의 범위와 그에 따른 장애·변경 영향을 함께 수용해야 합니다.

반대로 IP 연결만 필요하다면 VLAN을 각 접속 구간에 제한하는 대안을 검토할 수 있습니다. 다만 라우팅 경계 이동은 주소와 정책, DHCP 전달, 관리 방법을 바꾸는 작업입니다. 브로드캐스트 범위를 줄이는 이점과 주소·정책을 바꾸는 부담을 함께 비교해야 합니다.

단말의 서브넷 마스크가 잘못되면 같은 링크에서 직접 찾을지 게이트웨이로 보낼지의 판단부터 달라집니다. 따라서 목적지 MAC 주소만 보기 전에 출발지의 주소와 마스크, 선택한 다음 홉을 확인합니다. 주소 설정이 잘못된 문제를 스위치의 MAC 학습 문제로 오인하지 않으려면 이 순서로 확인하는 것이 좋습니다.

두 대안을 비교할 때는 PC-A와 App-S의 역할을 고정하고 경계 위치만 바꿉니다. 주소를 유지하는 교육용 비교와 실제 현장 이전 절차도 구분합니다. 여러 Access에 분산된 같은 서브넷을 어떻게 분리할지는 별도 주소 계획이 필요하며, 도면에서 게이트웨이 위치만 바꾸는 것으로 끝나지 않습니다.

Distribution이 게이트웨이일 때 프레임은 어디까지 갈까 ↑

L2 Access 사례에서는 PC-A가 만든 게이트웨이행 프레임이 Distribution까지 이어집니다. Access는 해당 VLAN의 L2 전달을 맡고, 게이트웨이는 목적지 IP를 보고 다음 네트워크로 보낼 경로를 선택합니다.

PC-A는 10.60.10.21/24, App-S는 10.60.20.10/24입니다. 목적지가 로컬 서브넷 밖이므로 PC-A는 게이트웨이 10.60.10.1의 MAC 주소를 ARP로 확인합니다. 이 사례에서는 게이트웨이가 D1에 있고 VLAN10이 A1에서 D1까지 이어집니다.

PC-A가 보내는 Ethernet 헤더의 목적지는 D1의 해당 게이트웨이 MAC이고, IP 헤더의 목적지는 App-S입니다. A1은 VLAN과 목적지 MAC에 맞는 전달 정보를 사용해 D1 쪽으로 보냅니다. A1도 ACL·QoS 처리를 위해 IP 필드를 읽을 수 있습니다. 다만 이는 목적지 IP로 다음 네트워크를 선택하는 라우팅과는 다른 동작입니다.

D1은 자신을 향한 프레임에서 패킷을 받아 목적지 IP에 맞는 전달 정보를 선택합니다. App-S의 서브넷이 직접 연결돼 있다면 App-S의 MAC을 인접 정보에서 찾고, 없으면 해당 링크에서 ARP로 해석합니다. 그 뒤 D1의 출력 인터페이스 MAC에서 App-S의 MAC으로 향하는 새 Ethernet 헤더를 구성합니다.

단말이 붙은 A1과 게이트웨이가 있는 D1 사이에 해당 VLAN이 실제로 이어져 있어야 합니다. 상향 케이블이 정상이어도 필요한 VLAN이 허용되지 않으면 게이트웨이와 통신할 수 없습니다. 따라서 케이블이 연결됐는지와 해당 VLAN의 프레임을 전달할 수 있는지는 따로 확인합니다.

IP 출발지와 목적지는 NAT가 없는 이 내부 사례에서 유지되지만 IPv4 TTL과 체크섬 같은 전달 관련 값은 라우터 처리에 따라 달라집니다. 응답은 App-S의 게이트웨이를 거쳐 PC-A 쪽으로 돌아갑니다. 장비는 먼저 경로를 고른 뒤, 그 경로로 패킷을 전달하는 데 필요한 MAC 주소를 ARP로 찾습니다.

D1이 게이트웨이인 구성에서 PC-A의 프레임을 따라갑니다. A1은 목적지 MAC을 따라 전달하고, D1은 라우팅한 뒤 App-S로 보낼 새 프레임을 만듭니다.

게이트웨이를 Access로 옮기면 다음 홉과 헤더가 달라진다 ↑

Routed Access에서는 단말의 게이트웨이를 접속 스위치에 두고 상향 연결을 라우팅 링크로 구성합니다. 단말의 첫 프레임을 벗기고 라우팅하는 위치와 그 뒤의 다음 홉이 앞의 대안과 달라집니다.

비교를 위해 PC-A의 게이트웨이 주소 10.60.10.1은 유지하되 그 주소를 A1이 맡는다고 하겠습니다. PC-A는 이제 A1의 게이트웨이 MAC으로 프레임을 보냅니다. 앞의 구성과 비교하려고 주소를 같게 둔 별도 설계안입니다. 실제 전환 때 D1과 A1에 같은 주소를 동시에 설정하라는 뜻은 아닙니다.

A1과 D1 사이에는 10.255.1.0/30 링크를 두고 A1을 .2, D1을 .1로 정합니다. A1은 App-S로 향하는 전달 항목에서 다음 홉 10.255.1.1을 선택합니다. Ethernet 링크이므로 그 다음 홉의 MAC을 인접 정보 또는 ARP 해석으로 구한 뒤, A1 상향 인터페이스에서 D1로 향하는 프레임을 만듭니다.

D1은 받은 IP 패킷을 다시 목적지와 전달 정보에 맞춰 App-S 구간으로 보냅니다. 이때도 App-S로 직접 연결된다면 App-S의 MAC을 사용하고, 다른 라우터를 더 거쳐야 한다면 그 다음 홉의 MAC을 사용합니다. 최종 목적지 IP와 현재 링크의 목적지 MAC을 분리해서 읽으면 경계가 바뀌어도 과정을 따라갈 수 있습니다.

이 예시의 D1은 App-S 서브넷에 직접 연결되어 있으므로 App-S의 MAC 주소를 확인합니다. 목적지까지 다른 라우터가 더 있다면 D1이 확인할 것은 그 다음 홉의 MAC 주소입니다. IP 목적지는 최종 서버를 가리키고, MAC 목적지는 현재 링크에서 프레임을 받을 장비를 가리킵니다.

응답이 돌아오려면 D1에도 10.60.10.0/24가 A1 쪽에 있다는 경로가 필요합니다. A1은 마지막에 PC-A의 MAC으로 프레임을 전달합니다. 도해의 게이트웨이 MAC·다음 홉 MAC은 역할을 구별하는 표기입니다. 실제 장비의 주소 값이나 첫 홉 이중화 프로토콜의 가상 MAC 형식을 나타내지는 않습니다.

게이트웨이를 A1에 둔 대안입니다. PC-A→A1, A1→D1, D1→App-S에서 IP 목적지와 각 링크의 목적지 MAC을 나란히 비교합니다.

게이트웨이를 옮기면 STP·이중화·정책을 적용할 위치도 달라진다 ↑

L2/L3 경계를 옮기면 사용하던 기능이 사라지기보다 필요한 위치와 범위가 달라집니다. 각 구성에서 링크 단절과 장비 고장을 어느 프로토콜로 처리하는지 다시 정리해야 합니다.

L2 상향 연결에서는 VLAN이 이어지는 범위와 루프 방지 동작을 확인합니다. 게이트웨이를 여러 Distribution 장비가 제공한다면 첫 홉 이중화와 프레임 전달 경로가 어떻게 맞물리는지도 봅니다. 장비 수만 같게 둔다고 정상·장애 경로가 일치하지는 않습니다.

상향 링크를 라우팅 연결로 바꾸면 그 링크의 대체 경로는 라우팅과 전달 정보의 갱신으로 다룰 수 있습니다. 그렇다고 Access 아래의 모든 L2 루프 위험이 없어지는 것은 아닙니다. 단말이 있는 구간의 연결과 보호 기능은 여전히 검토해야 합니다.

정책 위치도 옮겨질 수 있습니다. 이전에 Distribution 게이트웨이에서 적용하던 VLAN 간 ACL이 새로운 경로에서는 그 통신을 보지 못할 수 있습니다. DHCP 서버가 다른 네트워크에 있다면 중계 위치와 서버가 인식하는 클라이언트 서브넷도 확인합니다. 경계 이동은 전달·주소 설정·보안이 함께 바뀌는 설계 결정입니다.

정책을 다른 장비에 적용하면 트래픽과 카운터를 확인할 위치도 바뀝니다. 예전에는 D1에서 보이던 단말 사이 라우팅이 이제 A1에서 끝날 수 있습니다. 이전 장비의 카운터가 증가하지 않는다는 사실만으로 트래픽이 없다고 판단하지 말고, 새 경계에서 실제 요청을 관찰해야 합니다.

제품별 수렴이나 상태 유지 기능은 같은 이름만으로 비교하지 않습니다. 필요한 라우팅 기능과 자원, 운영자의 확인 방법이 해당 Access 장비에서 가능한지 확인합니다. 새 구조로 장애 범위를 줄일 수 있는지 시험하고, 운영자가 그 구성을 계속 관리할 수 있는지도 함께 검토합니다.

두 구성을 같은 PC-A와 App-S로 다시 그려 보겠습니다. 왼쪽은 VLAN10이 D1까지 이어지고, 오른쪽은 A1에서 끝납니다. 게이트웨이가 옮겨지면 PC가 찾는 MAC 주소의 주인과 D1이 응답을 돌려보내는 방법도 함께 달라집니다.

선택한 경계와 선택하지 않은 대안의 이유를 남긴다 ↑

L2/L3 경계를 정했다면 도면과 함께 선택한 이유를 남깁니다. 어느 구조가 더 새롭다는 설명보다, 우리 업무에 필요한 통신을 제공하고 장애의 영향을 줄이는 데 어떻게 도움이 되는지가 중요합니다.

L2 인접성이 실제로 필요한 구간은 그 범위를 제한해서 유지하는 안을 검토합니다. 서로 다른 구간을 IP로 연결하면 충분하고 접속 단계에서 장애 범위를 나눌 필요가 있다면 Routed Access를 비교합니다. 필요한 기능과 운영 역량, 주소·정책 이전 비용을 같은 기준으로 적습니다.

선택한 안에는 정상과 장애의 왕복 경로를 남깁니다. PC-A가 누구의 MAC을 찾는지, 어느 장비가 IP 전달 항목을 선택하는지, 응답이 어느 경로로 돌아오는지 확인합니다. 기본 경로가 존재한다는 사실과 실제 업무 정책이 허용한다는 사실을 따로 검증합니다.

선택하지 않은 대안도 이유를 한 줄 남깁니다. 특정 기능의 지원이 부족해서인지, 주소 이동 요구 때문인지, 현재 허용 영향에 비해 변경 부담이 큰지 구분합니다. 조건이 달라졌을 때 과거 결정을 다시 검토할 근거가 되며, 이전 설계가 당시 조건에서 왜 필요했는지도 이해할 수 있습니다.

같은 VLAN을 여러 위치에 이어야 한다는 요구도 구체적으로 확인합니다. 단말 주소를 유지하고 싶다는 편의와 반드시 동일한 L2 인접성이 필요한 애플리케이션 요구는 다릅니다. 주소 변경이나 서비스 설계로 해결할 수 있는지 검토한 뒤 실제로 필요한 연장 범위를 정합니다.

실제 망을 바꿀 때는 새 구성의 통신을 시험하고, 전환 중 문제가 생기면 이전 설정으로 되돌릴 절차를 준비해야 합니다. 앞의 도해들은 구조 비교용이므로, 서비스 중단을 줄이기 위한 전환 순서는 현장 조건에 맞춰 별도로 정합니다. 다음 여러 통신실의 Two-Tier 사례에서는 Routed Access를 선택해 실제 연결을 만들고, 그 뒤 이중화 글에서 첫 홉 전환과 상위 경로 전환을 구별하겠습니다.