서브넷과 CIDR

앞 글에서 본 클래스 체계의 문제는 크기를 고를 수 없다는 것이었습니다. 호스트가 300대 필요한 조직에 C 클래스를 주면 모자라고, B 클래스를 주면 6만 개가 넘는 주소가 놀게 됩니다. 이 문제를 푼 것이 서브넷(subnet)과 CIDR(classless inter-domain routing)입니다. 필요한 만큼의 크기로 블록을 나누어 주고, 큰 블록을 다시 잘게 나누어 쓰는 것입니다.

CIDR 표기와 호스트 수

CIDR은 클래스에 얽매이지 않고 네트워크부의 비트 수를 자유롭게 정하는 방식으로, 1993년 RFC 1519로 도입되었습니다. 192.168.1.0/24는 앞의 24비트가 네트워크부라는 뜻이며, 서브넷 마스크 255.255.255.0과 같은 뜻을 더 짧게 적은 것입니다.

프리픽스 길이가 $n$이면 호스트부는 $32 - n$비트이고, 그 가운데 호스트부가 모두 0인 네트워크 주소와 모두 1인 브로드캐스트 주소는 장치에 주지 않으므로 장치에 줄 수 있는 주소는 다음과 같습니다.

$\text{호스트 수} = 2^{32-n} - 2$

예외도 있습니다. RFC 3021은 장치가 둘뿐인 지점 간 링크에서는 브로드캐스트가 필요 없으므로 /31의 두 주소를 모두 쓰도록 했고, /32는 주소 하나를 뜻하는 경로로 씁니다.

하나의 블록을 나누기

192.168.1.0/24를 같은 크기의 서브넷 네 개로 나누어 봅시다. 네 개를 구분하려면 2² = 4이므로 호스트부에서 2비트를 빌려 네트워크부를 26비트로 늘리면 됩니다.

import ipaddress

net = ipaddress.ip_network("192.168.1.0/24")
for sub in net.subnets(new_prefix=26):              # 호스트부에서 2비트를 빌려 넷으로 나눈다
    print(f"{sub}: 호스트 {sub[1]}부터 {sub[-2]}까지, 브로드캐스트 {sub.broadcast_address}")

192.168.1.0/26: 호스트 192.168.1.1부터 192.168.1.62까지, 브로드캐스트 192.168.1.63
192.168.1.64/26: 호스트 192.168.1.65부터 192.168.1.126까지, 브로드캐스트 192.168.1.127
192.168.1.128/26: 호스트 192.168.1.129부터 192.168.1.190까지, 브로드캐스트 192.168.1.191
192.168.1.192/26: 호스트 192.168.1.193부터 192.168.1.254까지, 브로드캐스트 192.168.1.255

빌린 2비트가 00, 01, 10, 11일 때 마지막 바이트가 0, 64, 128, 192에서 시작하므로, 서브넷은 64개씩의 주소로 고르게 나뉩니다. 서브넷마다 첫 호스트 주소를 게이트웨이로 쓰는 경우가 많지만, 이는 관례일 뿐 CIDR이 정한 규칙은 아닙니다. subnets()는 서브넷을 하나씩 만들어 내므로 큰 블록을 잘게 나누어도 괜찮지만, list(net.hosts())처럼 호스트를 모두 목록으로 만들면 큰 블록이나 IPv6에서는 메모리와 시간이 지나치게 듭니다.

같은 서브넷인지, 하나로 묶이는지

두 주소가 같은 서브넷에 속하는지는 프리픽스 길이에 따라 달라집니다. 반대로 여러 서브넷을 하나의 큰 블록으로 묶는 것을 경로 집약(route aggregation) 또는 슈퍼넷팅(supernetting)이라고 합니다.

import ipaddress

def same_subnet(a, b, prefix):
    return ipaddress.ip_address(b) in ipaddress.ip_network(f"{a}/{prefix}", strict=False)

print("/24에서 .100과 .200:", same_subnet("192.168.1.100", "192.168.1.200", 24))
print("/25에서 .100과 .200:", same_subnet("192.168.1.100", "192.168.1.200", 25))

four = [ipaddress.ip_network(f"192.168.{i}.0/24") for i in range(4)]
print("네 블록을 묶으면:", list(ipaddress.collapse_addresses(four)))
two = [ipaddress.ip_network("192.168.1.0/24"), ipaddress.ip_network("192.168.2.0/24")]
print("1과 2를 묶으면:", list(ipaddress.collapse_addresses(two)))

/24에서 .100과 .200: True
/25에서 .100과 .200: False
네 블록을 묶으면: [IPv4Network('192.168.0.0/22')]
1과 2를 묶으면: [IPv4Network('192.168.1.0/24'), IPv4Network('192.168.2.0/24')]

/25는 마지막 바이트를 0부터 127까지와 128부터 255까지로 나누므로 .100과 .200은 다른 블록에 놓입니다. strict=False는 .100처럼 호스트 비트가 섞인 입력을 그 네트워크 주소로 바꾸어 준다는 뜻입니다.

192.168.0.0/24부터 192.168.3.0/24까지의 네 블록은 192.168.0.0/22 하나로 묶였지만, 192.168.1.0/24와 192.168.2.0/24는 이어져 있는데도 하나로 묶이지 않았습니다. 하나의 프리픽스로 나타내려면 블록들이 이어져 있을 뿐 아니라 그 프리픽스의 크기 단위로 시작 주소가 맞춰져 있어야 하는데, .1과 .2를 담는 /23은 없기 때문입니다(/23은 .0과 .1, 또는 .2와 .3을 묶습니다). 또 경로를 묶으려면 묶이는 블록들이 같은 방향으로 나가고 같은 정책으로 다루어져야 합니다. 경로를 묶으면 라우터가 기억할 경로가 줄어 라우팅 표가 작아집니다.

클라우드 VPC의 서브넷 정하기

VPC(virtual private cloud)는 클라우드 안에 만드는 나만의 가상 사설망으로, 만들 때 10.0.0.0/16 같은 주소 블록을 정하고 그 안을 다시 서브넷으로 나누어 씁니다. 그래서 AWS의 VPC를 설계할 때도 이 계산이 그대로 쓰입니다. AWS의 문서에 따르면 IPv4 서브넷의 크기는 /16부터 /28까지 고를 수 있고, 서브넷마다 첫 주소 네 개와 마지막 주소 하나, 모두 다섯 개를 AWS가 예약합니다. 첫 주소는 네트워크 주소, 다음은 VPC 라우터, 그다음은 DNS 서버, 그다음은 앞으로를 위한 예약이고, 마지막은 브로드캐스트 자리입니다. 그래서 /24 서브넷에서 쓸 수 있는 주소는 254개가 아니라 251개입니다.

ipcalc 192.168.1.100/26                        # 네트워크, 첫 호스트, 마지막 호스트, 브로드캐스트, 호스트 수
docker network inspect bridge                  # Docker 브리지 네트워크의 서브넷과 게이트웨이(IPAM 항목)

192.168.1.100/26은 앞에서 나눈 네 블록 가운데 192.168.1.64/26에 속하므로, ipcalc는 이 블록의 첫 호스트 .65, 마지막 호스트 .126, 브로드캐스트 .127, 호스트 수 62를 알려 줍니다. 손으로 한 계산을 이렇게 도구로 맞춰 볼 수 있습니다. docker network inspect로 Docker가 쓰는 서브넷을 확인하는 이유는, 그 블록이 회사망이나 VPC의 블록과 겹치면 그쪽 주소로 가는 경로가 충돌해 접속이 되지 않기 때문입니다.

정리

• CIDR은 프리픽스 길이로 네트워크부의 크기를 자유롭게 정하며, 장치에 줄 수 있는 주소는 보통 2^(32-n) - 2개입니다. /31과 /32는 예외입니다.
• 서브넷팅은 호스트부의 비트를 빌려 하나의 블록을 같은 크기의 작은 블록들로 나누는 것입니다.
• 두 주소가 같은 서브넷인지는 프리픽스 길이에 따라 달라지므로, 주소만으로는 판단할 수 없습니다.
• 경로 집약은 이어져 있고 시작 주소가 프리픽스의 크기 단위에 맞춰진 블록들을 하나의 경로로 묶어 라우팅 표를 줄입니다.
• 클라우드의 서브넷은 제공자가 예약하는 주소를 빼고 크기를 정해야 하며, AWS는 서브넷마다 다섯 개를 예약합니다.

연습 문제

1. 단말 50대와 게이트웨이 하나

보통의 IPv4 LAN 하나에 단말 50대와 게이트웨이 하나를 넣으려 합니다. 모두 주소를 하나씩 쓰고 다른 예약은 없을 때, /27과 /26 가운데 어느 것이 가장 작은 충분한 크기인가요? 같은 블록을 AWS의 서브넷으로 쓴다면 어떻게 되나요?

2. 묶을 수 있는 블록

10.1.4.0/24, 10.1.5.0/24, 10.1.6.0/24, 10.1.7.0/24를 하나의 경로로 묶을 수 있나요? 묶을 수 있다면 어떤 프리픽스가 되나요? 10.1.5.0/24부터 10.1.8.0/24까지의 네 블록은 어떤가요?

3. 컨테이너가 주소를 다 썼다

AWS의 /24 서브넷에 Kubernetes 노드 10대를 두었는데, Pod마다 VPC 주소를 주는 네트워크 플러그인을 쓰고 노드마다 Pod를 최대 30개 띄웁니다. 이 서브넷의 주소로 감당할 수 있나요? 어떻게 해야 하나요?

다음 글 NAT와 DHCP에서는 사설 주소를 쓰는 장치들이 인터넷과 통신하게 해 주는 NAT와, 장치에 주소를 자동으로 나누어 주는 DHCP의 동작을 살펴봅니다.