요약

  • RFC 3069는 서로 다른 고객 VLAN이 계층 2 브로드캐스트 도메인을 통합하지 않으면서도 하나의 IPv4 서브넷과 게이트웨이를 공유할 수 있게 했다.
  • 같은 프리픽스의 호스트는 먼저 ARP 해석을 시도하므로, 슈퍼-VLAN 라우터가 중개를 담당해야 한다. 마스크만으로는 인접성이나 권한을 증명할 수 없다.

주소는 줄이고, 중개는 늘어나는 방식

주소 계산은 설득력이 있었다. RFC의 예시에서 세 고객은 각각 16개의 호스트를 계획했다. 개별 서브넷을 사용하면 네트워크 주소, 지정 브로드캐스트 주소, 게이트웨이, 그리고 2의 거듭제곱 반올림까지 고려해 고객당 28개 주소를 소비했다. RFC 3069 모델은 19개만 사용했다. 세 개의 고객 서브-VLAN이1.1.1.0/24와 게이트웨이1.1.1.1을 공유하면서도 서로 분리된 호스트 범위를 유지했다. 사용하지 않은 주소는 고객의 재번호화 없이 다른 곳에 할당할 수 있었다.

이 절약이 고객들을 계층 2에서 이웃으로 만들지는 않았다. 각 서브-VLAN은 여전히 자신만의 브로드캐스트 도메인이었다. 그런데도 각 호스트는 슈퍼-VLAN의 프리픽스 길이를 사용했다. 따라서 일반적인 IP 논리는1.1.1.0/24의 주소를 직접 도달 가능한 것으로 간주하고, 패킷을 기본 게이트웨이로 보내는 대신 주소 해석을 시도했다. ARP는 로컬 네트워크에서 링크 계층 주소를 찾는 프로토콜이며, 서로 분리된 두 브로드캐스트 도메인을 하나로 묶지 않는다.

슈퍼-VLAN 라우터가 이 빠진 중계를 제공했다. RFC 3069는 이 라우터가 Proxy ARP와 유사한 기능을 수행할 수 있다고 명시한다. 다른 서브-VLAN에 있는 호스트의 주소를 요청하는 호스트에 응답하고, 프레임을 받아 패킷을 포워딩하는 방식이다. 호스트 입장에서는 목적지가 이웃처럼 보였다. 전달 시스템 내부에서는 라우터가 개입했다. 프리픽스는 주소 지정상의 관계를 표현했을 뿐, 물리적 사실이나 계층 2의 사실이 아니었다.

이 구분은 겉으로 보이는 단순함 뒤에 운영 상태를 놓는다. 라우터는 주소가 어느 서브-VLAN에 속하는지 알아야 하고, 요청자가 발신지 주소로 광고된 주소를 사용할 수 있는지 판단해야 하며, 일관되게 ARP에 응답하고, 의도된 경로로만 포워딩해야 한다. 그럴듯한 마스크나 ARP 응답 성공은 주소-VLAN 연관이 최신이거나 승인된 것임을 증명하지 않는다. RFC는 '고정(sticky)' 주소 범위를 권장한다. 즉, 어떤 서브-VLAN에서 수신한 IP 또는 ARP 패킷의 발신지 주소가 해당 서브-VLAN에 할당되지 않은 경우 그 패킷을 거부하고, 필요하면 이벤트를 기록하는 것이다. 이 규칙의 효과는 로컬 할당 및 연관 데이터에 달려 있다.

서브넷에서 익숙했던 일부 동작은 더 이상 하나의 브로드캐스트 도메인에서 성립하지 않는다. RFC는 지정 브로드캐스트를 지원하지 않는데, 올-원 주소가 서로 분리된 여러 계층 2 도메인을 동시에 지정할 수 없기 때문이다. 멀티캐스트도 주의가 필요하다. 분리된 도메인 사이에서 RPF 검사가 작동하려면 멀티캐스트 라우터에 호스트 경로 형태의 상태가 필요할 수 있다. 이후 RFC 4562는 멀티캐스트 복제의 어려움과 광대역 액세스 네트워크의 4096 VLAN 한계를 다루었다. 주소 절약은 운영 비용을 없앤 것이 아니라 라우터 상태와 네트워크 운영으로 옮겼을 뿐이다.

근거의 한계도 중요하다. RFC 3069는 informational 문서이며 인터넷 표준을 정의하지 않는다. 구현 세부사항은 의도적으로 생략되어 있다. 이 문서는 Extreme Networks가 공급자 데이터센터에서 1년 이상 운영 중인 작동하는 구현을 보유하고 있었다고 보고하는데, 이는 저자들의 진술이지 독립적인 도입 조사가 아니다. 다른 공급자의 작업은 소문 수준이었다. 이 문서는 상호 운용성, 실패율, 고객 결과에 대한 일반적인 측정값을 제공하지 않는다.

마스크뿐 아니라 패킷을 읽어라

같은 서브넷의 트래픽이 실패할 때 마스크는 단서일 뿐이다. 해당 서브-VLAN의 요청과 응답, 발신지 주소, 라우터의 주소-VLAN 할당, 프록시/ARP 판단, 포워딩 결과를 확인해야 한다. 멀티캐스트에서는 RPF 상태와 발신자별 요소도 고려 대상이다. 이러한 추적은 관측 지점에서 라우터가 무엇을 했는지 보여줄 뿐, 애플리케이션 성공이나 모든 경로의 격리를 자동으로 증명하지는 않는다.

출처