CIDR

프리픽스 길이로 네트워크 경계를 자유롭게 정하는 주소 체계(Classless Inter-Domain Routing).

클래스 체계의 문제

8의 배수로만 나뉘어 중간이 없었다 → 주소 낭비가 극심

CIDR는 /1부터 /32까지 임의 길이를 허용해 이 경직성을 없앴다.

경로 집약

192.168.0.0/24

• 192.168.1.0/24 — 연속되고 경계에 정렬돼 있으면

• 192.168.2.0/24 — → 192.168.0.0/22 하나로 집약된다 192.168.3.0/24

• 라우팅 테이블 항목이 4개에서 1개로 준다

• 전 세계 라우터의 테이블 크기를 억제한 핵심 기술

연속되고 정렬돼야 집약할 수 있다. 불연속 대역을 묶으면 포함되면 안 될 주소까지 포괄한다.

집약의 계산

/24 두 개를 묶으면 프리픽스가 1비트 짧아진다 → /23 /24 네 개 → /22 /24 여덟 개 → /21

단, 시작 주소가 그 블록의 경계여야 한다

• 10.1.0.0/24 + 10.1.1.0/24 → 10.1.0.0/23 ✓
• 10.1.1.0/24 + 10.1.2.0/24 → 집약 불가 (경계가 아니다)

주소 계획에 주는 시사점

부서별로 '연속된' 대역을 배정해 두면 나중에 상위 프리픽스 하나로 광고할 수 있다

띄엄띄엄 배정하면 각각을 따로 광고해야 해 항목이 는다

면접 함정

• ❌ "프리픽스는 8의 배수" → 그 제약을 없앤 것이 CIDR다.
• ❌ 불연속 대역 집약 → 의도치 않은 주소까지 포함된다.

표기법이 곧 계산이다

10.0.0.0/8 이라 쓰면

• 네트워크 주소 10.0.0.0
• 마스크 255.0.0.0
• 범위 10.0.0.0 ~ 10.255.255.255
• 호스트 2^24 - 2

네 가지가 한 표기에서 전부 나온다 — 클래스 표기보다 정보량이 많다

슈퍼네팅

• 서브네팅 — 큰 블록을 작게 나눈다 (/16 → /24 여러 개)
• 슈퍼네팅 — 작은 블록을 크게 묶는다 (/24 네 개 → /22)

둘 다 CIDR 가 가능하게 한 것이다 클래스 체계에서는 경계가 고정이라 어느 쪽도 자유롭지 않았다

인터넷 라우팅 테이블의 현실

BGP 전체 경로(full table) 는 90만 항목을 넘는다 집약이 없었다면 훨씬 컸을 것이고, 라우터 메모리가 감당하지 못했을 것이다

그럼에도 계속 느는 이유

• 멀티호밍(여러 ISP 연결) 시 집약이 깨진다
• 트래픽 엔지니어링을 위해 일부러 잘게 광고한다

클라우드에서의 CIDR

VPC 를 만들 때 CIDR 를 정한다 — 나중에 바꾸기 어렵다

• 다른 VPC·온프레미스와 겹치면 피어링·VPN 이 불가능해진다
• 서브넷을 AZ 별로 나눌 여유를 남겨야 한다

그래서 조직 차원의 주소 계획이 먼저다