[Network] 서브넷팅

2024. 11. 16. 17:38·Network
728x90
반응형

서브넷팅을 사용하는 이유? (feat. 회사 내부 네트워크 설계 예제)

다음의 회사 내부 네트워크를 설계하는 예시 상황을 보자.

  • 직원 수: 240
  • 4개의 부서: 기획팀, 편집팀, 회계팀, 행정팀

 

네트워크 설계를 하기 전 먼저 ISP를 통해 금액을 지불하여 IPv4 주소를 발급받아야 한다. 여기서는 국내 IP 주소는 아니지만, 200.100.100.0/24를 발급받았다고 가정하자!

 

그리고 각 부서에 IP 주소를 할당하기 위해 클래스 C 네트워크의 호스트 부분을 4로 나누어, 각 팀의 네트워크에 할당했다.

 

여기서 잠깐 클래스 C 네트워크의 호스트 사용 가능 범위를 복습하고 가자!

 

호스트 부분이 0 ~ 255로 총 256개의 디바이스를 연결시킬 수 있을 것 같지만, 사실 호스트부분에서 사용 가능한 부분은 1 ~ 254로 총 254개이다. 0과 255는 사용할 수 없는 주소이다. 그 이유는 0은 네트워크 고유의 주소이고, 255는 브로드캐스트 주소이기 떄문이다. 위 예제의 경우, 200.100.100.0.0과 200.100.100.0.255는 사용할 수 없다!

사실 실제로 사용할 수 있는 주소는 253개라고 봐야할 수도 있는데, 각 네트워크마다 Gateway를 위해 하나는 필수로 할당해주어야 하기 때문이다.

 

현재 상태에서도 네트워크 설계가 되었다고 볼 수 있다. 4개의 부서가 동일한 네트워크(1개의 네트워크)를 사용하며, 이들을 통합하는 1개의 스위치를 두고 254개의 디바이스를 모두 연결하는 것이다. -> [하나의 네트워크 사용 + 1개의 스위치]
즉, 하나의 거대한 LAN을 형성하는 것이다!

 

하지만, 이는 각 부서가 동일한 네트워크를 사용하기에 타 부서의 네트워크에 쉽게 접근할 수 있다는 보안상의 문제가 있을 수 있다. 뿐만 아니라, 하나의 네트워크를 사용한다는 것은 브로드캐스트 주소를 공유하기 때문에, 브로드캐스트 통신이 발생하면, 이 스위치에 연결된 모든 디바이스가 통신을 잠깐 정지하여 네트워크 효율이 크게 저하될 것이다.

브로드캐스트 트래픽은 네트워크의 모든 디바이스에 영향을 주며, 큰 네트워크에서는 과부하를 일으킬 수 있다.
서브넷팅으로 부서별 네트워크를 나누면, 이 트래픽이 부서 내부에서만 발생하여 효율성이 증가한다.

브로드캐스트를 사용하지 않을 수는 없을까?

네트워크 시스템 구조 상 브로드캐스트는 필연적으로 발생할 수밖에 없다.. DHCP, ARP 등등
하지만, 브로드캐스트의 범위가 클수록 네트워크 효율을 크게 떨어뜨리므로, 이 범위를 줄여주는 것이 네트워크 성능 상 매우 중요하다!

 

그렇다면, 이를 해결하기 위해 부서마다 각각 서로 다른 네트워크를 할당해주는 방식을 도입해볼 수 있을 것이다. 구조는 다음과 같다.

위처럼 구성하기 위해 200.100.100.0/24, 200.100.200.0/24, 200.100.300.0/24, 200.100.400.0/24를 사용 중이며 총 4개의 네트워크가 필요하다. 이러면 각 부서마다 사적 공간을 분리하여 타 부서에서의 접근을 제한할 수 있어 보안을 유지할 수 있으며, 브로드캐스트 주소 역시 제한되어 효율 저하를 최소화할 수 있을 것이다. 하지만, 여전히 문제는 남아있다.

 

각 부서마다, 즉 각 네트워크마다 사용 가능한 호스트 주소는 Class C 네트워크이므로 254개씩인데, 각 부서에는 60명씩 밖에 없으므로 194개의 호스트 주소가 낭비되는 상황이다. 기껏 비싼 돈을 들여서 네트워크를 4개나 구입했는데, 정작 호스트 주소는 3/4이나 낭비되고 있다.

 

절망적이다.. 어떻게 하면 다음의 요구사항을 모두 만족할 수 있을까?

  • 사적 공간의 분리
  • 브로드캐스트 주소의 제한
  • 주소 공간의 낭비 최소화

이를 위해 등장한 것이 서브넷팅(Subnetting)이라는 개념이다.

서브넷팅

서브넷팅이란 하나의 네트워크를 여러 개의 네트워크르 쪼개는 개념이다. 서브넷팅은 하나의 네트워크만을 사용하기에 효율적이며, 위의 요구사항도 모두 만족시킨다. 우리 예제에 서브넷팅을 적용하면 다음 그림과 같다.

잘 보면, 모두 주소가 200.100.100.?으로 동일하나 마지막 자리만 다르다. 또한, CIDR도 /24가 아니라 /26으로 변경되었다! 어떻게 된 것일까?

위 그림처럼 200.100.100.0/24라는 네트워크를 4개로 쪼개었다. 이때, 서브넷 마스크를 확인해보면 더 이상 255.255.255.0이 아니라, 255.255.255.192가 되었으며, CIDR도 /24가 아니라 /26이 된 것을 알 수 있다. 이는 서브넷팅이 Host ID 부분을 Network ID 부분으로 빌려오기 때문에 가능한 것이다.

 

서브넷 마스크의 호스트 부분이 원래라면 00000000이 기본적인 Class C 네트워크의 서브넷 마스크이겠지만, 서브넷팅을 통해 호스트 부분의 앞 2자리를 네트워크 부분으로 빌려준다면 11000000이 되게 된다. 10진수로는 호스트 부분이 0에서 192가 된다.

이렇게 호스트 부분을 빌려줌으로써 네트워크 부분이 확장되게 되는데, 위 예제에서는 2개의 비트를 빌려주었다. 그 말은 즉, 2^2 = 4개(00, 01, 10, 11)의 네트워크로 쪼갤 수 있다는 의미이다.

 

만약 1개의 비트만 빌려주었다면 2^1 = 2개의 네트워크로 쪼갤 수 있을 것이다. 이때의 서브넷 마스크는 호스트 부분이 10000000이 될 것이고 10진수로는 128일 것이다. CIDR는 /25가 될 것이다.

클래스 C 네트워크의 서브넷팅

위 그림은 클래스 C 네트워크에서 가능한 서브넷팅을 표로 정리한 것이다. 호스트에서 비트를 6개까지 빌려올 수 있으며, 빌려올 수록 CIDR은 1씩 증가한다는 것을 알 수 있다. 또한, 서브넷팅으로 1비트씩 Network ID로 끌어올 때마다, 네트워크의 수는 2의 거듭제곱만큼 늘어난다.

 

이때 중요한 것은, 사용한 가능한 호스트 수는, 총 범위에서 네트워크 주소와 브로드 캐스트 주소를 빼야 한다는 것이다. 호스트에서 빌려온 비트 수가 1인 경우, 128은 네트워크 주소(IP 주소)이고, 191은 브로드 캐스트 주소이므로 사용할 수 없다.

 

128은 2진수로 나타내면 10000000이고, 191은 2진수로 나타내면 10111111이다. 브로드캐스트 주소는 서브넷팅을 적용하면 각 서브넷마다 다르므로 이에 대해서는 따로 공부하도록 하자..!

 

이를 통해 알 수 있는 것은, 서브넷팅을 사용해서 주소 공간의 낭비를 줄일 수는 있지만, 1번 쪼갤 때마다 2개의 주소(네트워크 주소 & 브로드캐스트 주소)가 낭비되는 것은 필연적이라는 것이다. 즉, 너무 많이 쪼개게된다면 이 역시도 주소 공간의 낭비를 초래할 수 있다!

 

특정 부서의 필요에 따라 더 세분화된 서브넷이 필요하다면 가변 길이 서브넷 마스크(VLSM)를 사용할 수 있다. 예를 들어, 부서별로 다른 크기의 서브넷이 필요할 경우 CIDR 값을 다르게 적용하여 효율성을 더 높일 수 있습니다.

 

재미뗘 재미뗘

728x90
반응형

'Network' 카테고리의 다른 글

[Network] Application Layer Protocol  (1) 2024.11.18
[Network] IP 핵심 (IP 종류, NAT, 공유기, 포트 포워딩, DDNS)  (1) 2024.11.17
[Network] DNS, URI, URL  (0) 2024.11.14
[Network] L4 핵심 (TCP & UDP)  (10) 2024.11.13
[Network] L3 핵심  (11) 2024.11.12
'Network' 카테고리의 다른 글
  • [Network] Application Layer Protocol
  • [Network] IP 핵심 (IP 종류, NAT, 공유기, 포트 포워딩, DDNS)
  • [Network] DNS, URI, URL
  • [Network] L4 핵심 (TCP & UDP)
mxruhxn
mxruhxn
소소하게 개발 공부 기록하기
    반응형
    250x250
  • mxruhxn
    maruhxn
    mxruhxn
  • 전체
    오늘
    어제
    • 분류 전체보기 (152)
      • Java (21)
      • Spring (6)
      • Database (13)
      • Operating Syste.. (1)
      • Computer Archit.. (0)
      • Network (24)
      • Data Structure (6)
      • Algorithm (11)
      • Data Infra (7)
      • DevOps (12)
      • ETC (27)
      • Project (21)
      • Book (1)
      • Look Back (1)
  • 블로그 메뉴

    • 링크

      • Github
    • 공지사항

    • 인기 글

    • 태그

    • 최근 댓글

    • 최근 글

    • hELLO· Designed By정상우.v4.10.0
    mxruhxn
    [Network] 서브넷팅
    상단으로

    티스토리툴바