<문제> 218.55.9.0 C Class Network ID하나를 할당받았다. 회사에서는 6개의 물리적인 네트워크로 나뉘어 있다. 6개의 네트워크를 지원하기 위한 서브넷ID와 각 서브넷별 호스트ID의 범위를 구하면?

<계산>

(1) 6개의 네트워크를 지원하기 위해 필요한 비트의 개수 산출 : 3개 (2³)

(2) 사용자 정의 서브넷 마스크를 계산하면 : 아래의 <그림2-25>을 참고한다. 255.255.255.224가 된다.

(3) 서브넷 ID 계산 : <그림2-25>에서 두 번째 박스를 살펴보면 화살표로 표기된 부분이 서브넷ID부분인데 여기서 가장 낮은 자리수를 십진수로 바꿔보면 32가 나온다. 이것은 32씩 증가하는 서브넷ID임을 보여준다. 즉 0.32.64.96.....224 가 바로 서브넷 ID가 되는 것이다.

2-4-1. CIDR - Subnetting

회사의 전체직원이 210명인 회사가 있다고 가정을 해 보겠다. 회사에서는 1인당 1대의 컴퓨터를 사용하고 있다. 회사에서는 보다 빠른 회선으로 업그레이드를 하면서 새로운 ISP로부터 인터넷 서비스를 받게 되고, 207.46.230.0 이라는 C Class Network ID를 할당받았다. 당신은 이 Network ID를 이용해서 회사의 클라이언트들에게 IP Address를 할당하는 작업을 해야 한다.

C Class Network ID 하나를 가지고 지원되는 호스트의 수는 최대 254까지이다. 회사의 전체 호스트 숫자가 210대이므로 C Class 하나만 가지면 충분히 지원할 수 있지만 이들

전체를 하나의 네트워크로 만들어 사용을 하기보다는 네트워크를 보다 작게 여러 개로 나누어 효율성을 기하고 싶다.

네트워크에 호스트수가 많아질수록 바로 브로드캐스트 통신이 문제가 되는데 네트워크에서는 이러한 브로드캐스트를 줄이는 방법으로 OSI 3계층 장비인 라우터를 통하여 네트워크를 여러개의 브로드캐스트 도메인으로 세그먼트하는 방법을 사용한다. 네트워크를 여러개로 나누면 각각의 네트워크에서 발생되는 브로드캐스트 패킷은 해당 네트워크에 한정되기 때문에 그만큼 효율적인 네트워크의 사용이 가능해 지는 것이다.

당신의 회사 역시 네트워크를 4개로 나눠서 한 세그먼트에 호스트의 숫자를 60대 미만으로 셋팅하고자 한다. 이러한 상황을 고려해 보겠다.

여기에서 당장에 혼란이 생긴다. 앞에서 서로 다른 물리적인 네트워크에서는 반드시 서로 다른 네트워크ID를 사용해야 한다고 했는데 당신은 ISP로부터 하나의 C Class 네트워크ID를 할당받았을 뿐이다. 이 하나의 네트워크ID를 4개의 세그먼트에 나눠서 차례대로 할당할 수는 있지만 그렇게 했을 때 이들 서로간에는 서로 통신을 할 수가 없게 된다. 같은 네트워크ID를 가지고 물리적으로 서로 다른 네트워크에 위치해 있으니 통신이 안 되는 것은 당연한 일이다.

ISP에 추가로 C Class네트워크 ID 3개를 요청했지만 추가비용을 요구한다. 거기다가 가만히 생각해 보니, 각각 254개를 쓸 수 있는 C Class ID를 3개 더 받아서 하나의 네트워크당 60개만 사용한다고 가정하니 나머지 194개씩의 IP는 버려질 수밖에 없는 노릇이다. IP Address의 낭비가 너무 심하다는 생각이 든다.

이것이 Class 체계의 IP Address가 가지는 맹점인 것이다. 보다 효율적인 방법은 없을까? 물론 있다. CIDR(Classless Inter Domain Routing)이라는 기법을 이용하여 IP Address를 보다 효율적으로 관리할 수 있다. 구현하는 방법은 의외로 간단하지만 처음 접근할 때 많이들 어려워하는 개념이다. 차근차근 접근해 보도록 하겠다. 실제로는 대기업 환경이나, ISP에서 쓰임새가 많은 기술이지만 시스템관리자에게는 상식적인 사항이 될 수 있다.

CIDR은 Subnetting과 Supernetting이라는 두가지로 구분해 볼 수 있다. 위의 예제의 경우에는 Subnetting이 필요한다. 할당받은 C Class ID는 네트워크 ID로 3개의 옥텟(24bit)을 사용하고 호스트ID로 1개의 옥텟(8bit)가 사용된다. 현재의 상황은 네트워크ID가 더 필요한 상황임을 고려하자. 해결방법은 호스트ID가 사용할 8bit중 일부를 네트워크ID용도로 전환하면 문제는 간단해 진다.

<그림2-21. CIDR기법- subnetting>

<그림2-21>에서 보듯이 호스트ID 8비트중에서 3비트를 네트워크ID 용도로 전환하여 사용하려고 한다. 이때 이 3비트를 "서브넷ID"라고 부르게 된다. 크게 본다면 네트워크ID에 포함될 수 있다. 좀 더 단계적으로 전체적인 계산방법을 알아보겠다.

2-4-2.  Subnetting 계산 방법

Subnetting을 계산할 때 익숙해지면 암산으로도 가능해진다. 하지만 지금은 단계별로 접근해 볼 것이다. 다섯단계로 구분을 해서 계산을 해 볼 것이다. 차근차근 한단계씩 이해하고 넘어가도록 하자.

2-4-2-① 회사에서 필요로 하는 네트워크의 수 결정

서브넷팅을 하기전 가장 먼저 할 일은 회사에서 필요로 하는 네트워크의 수를 파악하는 일이다. 이때 고려할 사항은 당장 필요한 것도 중요하지만 향후 네트워크의 확장이 고려된다면 네트워크의 여유가 있을 때 그 부분을 미리 고려하는 것도 필요한 일이다. 위의 예제상황에서는 총 4개의 네트워크가 필요하다고 결정되었다.

2-4-2-② 필요한 네트워크ID를 만들기 위해 전환할 bit수의 결정

①에서 결정된 4개의 네트워크를 지원하려면 호스트ID가 사용하는 8개의 비트중에서 몇 개의 비트를 네트워크ID로 전환시켜 사용해야 할까? 2²⁼ 4라는 결과가 나오니 2개의 비트가 있으면 되겠다. ( 만일 6개의 네트워크가 필요하다면 어떻게 할까? 2³=8이 되니 3개의 비트가 있으면 된다)

2-4-2-③ 서브넷 마스크(User defined Subnet Mask, Custom Subnet Mask) 계산

다음 해야 할 작업은 변경된 서브넷 마스크를 계산해야 한다. C Class의 기본서브넷 마스크는 255.255.255.0이었다. 이것은 C Class IP Address중에서 네트워크ID부분은 1, 호스트ID부분은 0으로 채운 결과 나온 값이었는데, 지금은 상황이 조금 달라졌다. 서브넷ID가 할당됨으로써 네트워크ID가 변동이 생겼으니 서브넷 마스크도 달라져야 한다. <그림2-22>에서는 변경된 서브넷 마스크가 계산되는 과정을 보여준다. 네 번째 옥텟의 호스트ID가 8비트에서 6비트로 줄어들고 상대적으로 네트워크ID가 2비트가 늘어났다. 일반적인 서브넷 마스크는 255.255.255.0 이었지만 호스트비트중 앞의 두 비트가 1로 바뀌었으므로 다시 계산하면 사용자정의된 서브넷 마스크는 255.255.255.192가 된다.

<그림
<2-22.사용자 정의 서브넷 마스크 계산방법>

여기서 한가지 고려해 볼 것이 있는데, 서브넷 마스크가 바뀌었다는 것이 무엇을 의미할까? 앞에서 우리는 호스트가 TCP/IP통신을 하는 절차를 보았는데 그때 호스트는 목적지 호스트가 자신과 로컬에 있는지 원격지에 있는지를 결정하게 되었다. 그 방법으로 자신의 서브넷 마스크를 이용해서 자신과 목적지 호스트의 네트워크ID를 계산한 다음에 결과값을 살펴서 같으면 로컬, 다르면 원격지로 판단한다고 했다. 위에서 계산된 새로운 서브넷 마스크를 이용하면 하나의 C Class인 207.46.230.0을 사용하더라도 범위에 따라서 서로 다른 네트워크ID라는 결과를 얻을 수가 있게 된다. 결국 하나의 C Class ID로써 여러개의 네트워크ID를 가진 효과를 내게 되는 것이다. 

2-4-2-④ 서브넷 ID 계산

 <그림2-23. Subnet ID 계산>

서브넷팅된 Network ID (Subnet ID)를 계산해야 한다. 207.46.230.0 네트워크 ID는 건드릴 수 없다. 호스트 비트인 8비트 중에서 앞의 2비트를 서브넷ID로 사용하고자 하기 때문에 <그림2-23>에서 노란색부분인 Subnet ID 2비트로써 생성할 수 있는 모든 경우의 수를 구해본다. 위의 그림에서 보듯이 00, 01, 10, 11 이라는 4가지 경우의 수가 나온다. 이것을 십진수로 전환하면 각각 0,64,128,192가 된다. 결국 서브넷 ID를 정리하면 다음과 같다.

- 207.46.230.0

- 207.46.230.64

- 207.46.230.128

- 207.46.230.192

2-4-2-⑤ 서브넷별 호스트ID의 범위 계산

이제 마지막 단계이다. 각 서브네트워크별 사용할 호스트ID의 범위를 구해야 한다. ④에서 구한 4개의 서브넷ID마다 생성할 수 있는 호스트ID의 범위를 구하기 위해 <그림2-24>를 참고해 보겠다.

<그림2-24>의 ①번 서브넷을 예로 들면, 서브넷팅을 하기 전 호스트비트는 8개를 사용할 수 있었지만 서브넷팅을 하고 앞의 2비트를 서브넷 용도로 전환시켰기에 남은 것은 6비트가 있다. 서브넷ID인 처음의 00은 그대로 두고 나머지 6비트를 이용해서 생성할 수 있는 가장 작은 수와 큰 수를 각각 구하면 호스트ID의 범위가 나온다. 여기서 주의할 것은 호스트비트가 전체가 0이되는 경우와 전체가 1이 되는 경우 두 가지를 제외하여야 한다는 것이다.

이미 설명한 바 있지만 호스트비트 전체가 0이되는 주소는 해당네트워크 자신을 나타내고, 전체가 1이되는 수는 해당 네트워크의 브로드캐스트 ID로 사용되기 때문에 호스트에게는 할당할 수 없다. TCP/IP등록정보를 열고 이러한 주소를 입력해 보면 실제로 입력이 되지 않고 에러가 발생하는 것을 확인할 수 있다. 이것을 십진수로 전환해 보면 1과 62가 된다. 첫 번째 서브넷 ID인 207.46.230.0 네트워크에서 쓸 수 있는 호스트ID의 범위는 207.46.230.1부터 207.46.230.62까지로 총 62개의 호스트ID를 사용할 수 있는 것이다. (2⁶-2=62개)

같은 방법으로 2~4번째 서브넷ID의 호스트ID의 범위를 구해보면 다음과 같다.

- 207.46.230.65~207.46.230.126

- 207.46.230.129~207.46.230.190

- 207.46.230.193~207.46.230.254

지금까지 몇단계를 거쳐서 서브넷팅 작업을 해 보았다. 단순히 IP Address의 클래스를 알아보았던 것에 비하면 조금 어렵다는 생각이 들 것이다. 하지만 분명히 필요성이 있는 것이기에 잘 익혀 두어야 한다.

2-4-3. CIDR 표기법

CIDR은 이진표기법을 사용한다. 위의 예제와 같이 서브넷팅된 상황이라면 207.46.230.2 라는 IP Address를 쓰는 호스트는 다음과 같이 표기할 수 있다.

이것은 207.46.230.2 IP Address중에서 26비트가 네트워크ID임을 가리켜 준다. 결국 Subnet Mask는 255.255.255.192라는 것을 알 수 있다.

지금까지 Subnetting의 개념과 구현방법에 대해서 알아보았다. 가장 많이 접할 수 있는 네트워크ID인 C Class를 통해서 예제를 만들어 보았다. B Class라면 더더욱 작업은 쉬워진다. 위의 방법을 토대로 하여 B Class 예제를 하나쯤 다루어 보기 바란다.

2-4-4. CIDR - Supernetting

Subnetting과는 반대의 개념으로 Supernetting을 구현할 수 있다. 상대적으로 중소규모의 회사 차원에서 수퍼넷팅이 구현될 필요는 없다. 개념적인 것을 알아두는 차원에서 다루어 보고자 한다. 한 회사가 192.168.1.0부터 192.168.5.0까지 5개의 네트워크ID를 사용하고 있다고 가정한다. 인터넷상에서 네트워크가 동작하기 위해서는 이 하나의 회사를 위해서 라우팅 테이블이 5개가 추가되어야만 할 것이다.

이경우 보다 효율적인 네트워크를 위해서 라우팅 테이블을 최적화하기를 원한다. 비록 C Class Network ID가 5개라고 할지라도 라우팅 테이블에서는 5개가 아닌 1개의 라우팅 경로만으로 이 회사의 네트워크를 지원할 수 있다면 그만큼 인터넷의 라우터들은 성능의 향상을 가져올 수 있을 것이다. 이런 경우에 수퍼넷팅을 이용하여 라우팅 테이블을 최소화 하는 것이 가능한다.

보다 간단하게 이해를 돕자면 위의 회사에서 5개의 네트워크ID를 사용하는데 물리적으로 하나의 네트워크에 이 5개의 서로 다른 네트워크ID를 할당해서 사용하고 싶다는 뜻이다. 네트워크를 하나로 통합하고 싶다는 것을 의미한다. 어떻게 하면 될까? 역시 서브넷 마스크에 달려 있다는 생각이 들 것이다. 비록 서로 다른 네트워크이지만 서브넷 마스크를 가지고 계산을 했을 때 같은 네트워크ID라는 결과가 나오도록 서브넷 마스크를 조절한다면 이들은 서로 같은 네트워크에 있는 셈이 될 테니까. 어째 생각하면 쉬운 것 같다.

이것을 가리켜서 수퍼넷팅이라고 부른다. 수퍼네팅된 서브넷 마스크를 구하는 방법은 <그림2-26>과 같다.

<그림2-26. 수퍼넷팅 계산방법>

255.255.248.0을 서브넷 마스크로 사용한다면 5개 네트워크의 어떠한 호스트ID를 사용하더라도 하나의 물리적인 네트워크에서 통신이 가능해진다.  예를 들어 192.168.1.100을 쓰는 호스트와 192.168.4.200을 쓰는 호스트가 물리적으로 하나의 세그먼트에 물려 있더라도 255.255.248.0을 사용하면 통신이 가능하다는 것을 말한다. 서로 같은 네트워크 ID라는 결과가 나오기 때문이다.

수퍼넷팅의 이해를 돕기 위하여 위와 같은 설명을 했으나 내부적인 네트워크에서는 위와 같은 처리를 할 이유가 없다. 이것은 어디까지나 인터넷 상에서 네트워크 경로를 최소화하여 보다 원활한 라우팅을 구현하는데 의의가 있다. ISP와 같은 대형 서비스 벤더에서 구현되는 방식이라고 이해하는 편이 좋겠다.

2-4-5. VLSM (Variable Length Subnet Mask)

마지막으로 한가지만 설명을 하고 마칠까 한다. 아래의 <그림2-27>을 보겠다. 이 회사는 192.168.200.0 C Class Network ID를 사용한다. 회사의 네트워크는 그림에서 보듯이 6개의 네트워크로 나뉘어 있는데 각 네트워크마다 서로 다른 노드(컴퓨터,라우터 등 하나의 포트를 차지하는 모든 디바이스를 총칭)를 가지고 있다. 이러한 상황에서 Subnetting을 통해서 6개의 네트워크에서 사용할 수 있는 ID들을 계산해 보고자 한다.

 
<그림2-27. 6개로 세그먼트된 192.168.200.0 네트워크>

위의 상황을 지금까지 배웠던 서브넷팅의 방법으로 계산하려고 하면 뭔가 맞지 않는다는 것을 알 수가 있을 것이다. 6개의 네트워크를 지원해야 하니, 호스트비트 8비트중 3비트를 서브넷 비트로 써야 할 것이다. 거기까진 좋은데 3비트를 서브넷비트로 사용했을 경우 호스트ID로 사용할 비트가 5비트가 되니 5비트를 가지고 만들 수 있는 호스트ID의 수는 2⁵-2=30개가 된다. 그러면 <그림2-27>에서 60node가 있는 네트워크에는 IP Address가 부족하게 된다. 60개의 IP Address를 확보하려면 적어도 6비트는 필요하다.(2⁶-2=62개) 8비트중 나머지 2개의 비트로 서브넷팅을 하면 되는데 문제는 그럴 경우 서브넷ID가 4개밖에 나오지 않는다는 것이다. '응 안되는구나.. '라고만 판단하면 길은 정해져 있다. 네트워크의 수를 줄이거나, 추가로 C Class Network ID를 더 확보하거나, 사설 네트워크로 가는 방법이 있을 것이다.

그렇지만 회사의 전체 호스트수를 더해봐도 194대밖에 되지 않는데 최대 254개의 호스트를 지원하는 C Class 하나로써 이것을 지원하지 못한다는 것은 뭔가 석연치 않다. 이러한 경우 당신은 Subnetting을 효율적으로 운영할 수 있다. 각각의 네트워크에 필요한만큼만 호스트ID를 할당하는 방법을 사용하는데 방법은 다음과 같다.

전체의 서브넷ID를 한꺼번에 계산해서는 안된다. 필요한 부분마다 각각 계산을 해 나가는데 필요한 네트워크ID를 지원하기 위해 필요한 비트수를 계산하는 것이 아니라 필요한 호스트ID를 지원하기 위해 필요한 비트수를 먼저 계산한다. 호스트의 수가 많이 필요한 서브넷부터 먼저 계산해 나가는 편이 좋다.

(1) 60개 호스트를 지원하기 위한 서브네팅

 - 60개의 호스트를 지원하기 위해 필요한 호스트 비트수 = 6개 (2⁶-2=62)

 - 서브넷 마스크는 11111111.11111111.11111111.11000000 (남은 2비트로 서브네팅)

 - 서브넷ID는 서브넷ID중 낮은 자리수의 십진수를 구하면 -> 64 (64씩 증가하는 서브넷)

 - 호스트ID의 범위 2개를 구하면 -> 192.168.200.1~62, 192.168.200.65~126 / 26

(2) 30개 호스트를 지원하기 위한 서브네팅

 - 30개의 호스트를 지원하기 위해 필요한 호스트 비트수 = 5개 (2⁵-2=30)

 - 서브넷 마스크는 11111111.11111111.11111111.11100000 (남은 3비트로 서브네팅)

 - 서브넷ID는 서브넷ID중 낮은 자리수의 십진수를 구하면 -> 32 (32씩 증가하는 서브넷)

 - 호스트ID의 범위 2개를 구하면 -> 192.168.200.129~158, 192.168.200.161~190 / 27

   ( 1~127까지는 이미 앞의 네트워크에서 사용되었음을 유의한다.)

(3) 12개 호스트를 지원하기 위한 서브네팅

 - 12개의 호스트를 지원하기 위해 필요한 호스트 비트수 = 4개 (2⁴-2=14)

 - 서브넷 마스크는 11111111.11111111.11111111.11110000 (남은 4비트로 서브네팅)

 - 서브넷ID는 서브넷ID중 낮은 자리수의 십진수를 구하면 -> 16 (16씩 증가하는 서브넷)

 - 호스트ID의 범위 1개를 구하면 -> 192.168.200.193~206 / 28

   ( 1~191까지는 이미 다른 네트워크에서 사용되었음을 유의한다.)

(4) 2개 호스트를 지원하기 위한 서브네팅

 - 2개의 호스트를 지원하기 위해 필요한 호스트 비트수 = 2개 (2²-2=2)

 - 서브넷 마스크는 11111111.11111111.11111111.11111100 (남은 6비트로 서브네팅)

 - 서브넷ID는 서브넷ID중 낮은 자리수의 십진수를 구하면 -> 4 (4씩 증가하는 서브넷)

 - 호스트ID의 범위 1개를 구하면 -> 192.168.200.209~210 / 30

   ( 1~207까지는 이미 다른 네트워크에서 사용되었음을 유의한다.)

위와 같이 계산을 하여 아래의 <그림2-28>과 같이 IP Address를 배치하는 결과를 얻은 것이다. 가만히 살펴보면 이들 서브넷들은 앞에서의 일반적인 서브네팅과는 달리 서브넷마다 서브넷 마스크가 다르다는 것을 알 수가 있는데 이러한 기법을 가리켜서 "가변길이서브넷"(VLSM; Variable Length Subnet Mask) 기법이라고 한다.

 <그림2-28. VLSM을 이용한 서브네팅>

아직 서브넷팅이 익숙하지 않기 때문에 한꺼번에 4개의 서브넷팅이 부담스러울 수 있겠으나, 위와 같은 방법을 이용하면 보다 효율적인 IP Address 관리가 가능해진다. 전체 호스트에게 IP Address를 할당하고도 아직 192.168.200.212~254까지의 여분이 남아 있다. 추가로 네트워크가 더 생기더라도 할당할 여유가 있게 되었다. 앞의 서브넷팅을 완전히 이해하고 나면 VLSM의 필요성, 방법 등을 이해하기가 쉬울 것이다.

앞의 'IP Address의 이해'장에서 IP Address의 개요에 대한 설명을 한 바 있다. IP Address는 네트워크ID와 호스트ID로 나누어진 다는 것을 알았다. 저번 예제에서 동과 우체국으로 나뉘어졌던 것을 대신해서 이번에는 실제로 라우터와 컴퓨터를 놓고, IP Address를 할당해 보았다. <그림2-15>를 보면서 이야기한다. 예제는 131.107.0.0 과 1331.108.0.0 이라는 두 개의 네트워크로 구성된 환경이다. 이들 네트워크에는 A,B,C라는 세대의 컴퓨터가 있고 각각 적절한 IP Address, Subnet Mask, Default Gateway가 할당되어 있다.  

예제에서 131.107.0.0네트워크에 있는 "B"는 "C"와 통신을 하고자 한다. 통신의 종류는 너무나도 다양하다. 간단하게 B에서 "ping 131.108.0.2"라는 명령을 날릴 경우도 있을 것이고, C컴퓨터가 서비스하는 웹서비스에 B가 웹 브라우저를 띄우고 "http://131.108.0.2"를 입력한 경우도 있을 수 있다. 어떠한 종류의 작업이건 결국은 IP Address를 이용한 통신을 하는 것이기에 B는 C의 IP Address를 목적지로 하는 메시지를 날려 보내야만 한다.

이 단원의 처음에 "같은 동에 속한 사람들끼리는 직접 편지를 교환하고, 다른 동으로 편지를 보내기 위해서는 반드시 우체국을 이용해야 한다."라는 가정을 한 바 있다. 바꿔 말하면 컴퓨터는 TCP/IP통신을 할 때 자신과 같은 네트워크에 속한 컴퓨터와는 직접 통신을 하고, 다른 네트워크에 속한 컴퓨터와 통신을 할 때는 '라우터"를 이용해야 한다는 것을 말한다.

이러한 이유로 B가 C에게 메시지를 보내고자 할 때 첫 번째 해야 할 일은 "C"라는 컴퓨터가 자신과 같은 네트워크에 있는지(로컬인지), 아니면 다른 네트워크에 있는지(원격지인지)를 결정해야 한다는 것이다. 이것을 구분하는 컴퓨터는 IP Address중에서 Network ID부분을 가려낸 다음 Network ID를 서로 비교해 보게 된다. 자신의 네트워크 ID와 상대방 컴퓨터의 네트워크ID가 같다면 당연히 같은 네트워크 임을 의미하고, 네트워크ID가 서로 다르다면 서로 다른 네트워크에 존재한다는 것을 나타내기 때문이다.

문제는 IP Address중에서 도대체 어디까지가 네트워크ID가 차지하는 부분인지를 알 방법이 필요하다는 것이다. 조금 더 자세히 말한다면 IP Address로 사용되는 32비트의 숫자중에서 몇비트가 네트워크ID가 사용하는 부분인지를 알아내야 할 필요성이 있는 것이다. 그것을 가리켜주는 것이 바로 Subnet Mask의 역할이다.

2-2-1. Subnet Mask

Subnet Mask는 IP Address중에서 네트워크ID 부분을 가려내는 역할을 담당한다. Subnet Mask를 잘못 입력하는 것은 통신불가능이라는 문제점을 야기시킬 수 있다. 서브넷 마스크가 IP Address중에서 네트워크ID를 가려내는 일을 하므로 서브넷 마스크가 잘못 할당되어 있으면 IP Address중에서 네트워크ID가 틀리게 가려질 수 있다. 결국은 같은 네트워크에 존재하는 호스트와 서로 다른 네트워크ID를 사용하게 되는 등의 문제가 생길수 있는 것이다. 서브넷 마스크를 제대로 사용하는 것은 중요한 일이다.

좀더 구체적으로 Subnet Mask를 통해서 어떻게 상대방 컴퓨터가 로컬인지 원격지인지를 가려내는지를 알아보겠다. 아래의 <그림2-16>에서는 B의 네트워크ID와 C의 네트워크 ID를 계산하는 방법을 그림으로 표현하였다. B컴퓨터는 통신을 하고자 할 때 가장 먼저 자신의 서브넷 마스크를 이용해서 자신의 IP Address와 상대방의 IP Address로부터 Network ID를 계산한다.

<그림2-16>의 "(1)B의 네트워크ID계산"을 보면, 131.107.3.100을 이진수로 전환했다. 자신의 서브넷 마스크인 255.255.0.0역시 이진수로 전환을 한 다음 And연산을 이용해서 두 수(bit)를 결합시켰다. Bit 에 대한 And연산은 두 수가 1일 때만 1이라는 결과를 나타낸다. (And연산 -> 1=참, 0=거짓, 둘다 참일 때만 참).

값을 계산해 보면 세 번째의 그림인 Network ID결과값을 얻을 수 있다. 이것을 가만히 살펴보면 네트워크 ID결과값중에서 두 개의 옥텟은 IP Address의 두 개의 옥텟과 일치함을 알 수 있다. 서브넷 마스크의 두 개의 옥텟이 11111111.11111111 이므로 당연히 IP Address 쪽의 수자를 따라가게 된 것이다.  세, 네 번째 옥텟은 00000000.00000000 이라는 결과를 보여주는데, 서브넷 마스크의 세,네 번째 옥텟이 00000000.00000000 이므로 (두 수중 둘 다 1일 때만 1, 결국 한쪽이라도 0이면 0이 나온다는 Bit And연산에 따라) 결과값 역시 00000000.00000000 이 나온 것이다. 결국 나온 결과값은 이것을 십진수로 전환하면 131.107.0.0 이라는 네트워크ID를 얻어낼 수 있다.

10000011.01101011.00000000.00000000 이라는 결과값을 십진수로 전환하면 131.107.0.0 이라는 네트워크ID가 계산된다. 당연한거 아닌가 싶지만 우리는 전체적인 그림을 보니까 당연해 보이지만 호스트 입장에서는 IP Address만 가지고 목적지 컴퓨터가 도대체 어느 위치에 존재하는지 심지어는 자신이 어느 위치에 존재하는지도 알 턱이 없다. 이들이 알고 있는 것이라고는 단지 IP Address, Subnet Mask 등의 숫자 몇 개가 고작인 것이다.

같은 방법으로 (2)에서는 C의 네트워크ID를 계산했다. 그 다음에 할 일은 B는 자신의 네트워크ID와 상대방인 C의 네트워크ID를 비교하는 일이다. 이 결과값이 일치하다면 이들 둘은 같은 네트워크ID를 사용하고 있다는 것을(로컬) 의미하며, 다르다면 다른 네트워크ID를 사용하고 있다는(원격지) 것을 의미한다.

결과값이 같다면 직접 로컬에서 통신을 시도할 것이지만 결과가 다르다면 로컬의 라우터의 도움을 받아야 C와 통신을 할 수가 있게 된다. 예제에서는 131.107.0.0과 131.108.0.0이라는 서로 다른 결과를 보여준다. 서로 다른 물리적인 네트워크에 있다는 결과가 나왔다. 제대로 계산이 나왔다.

Subnet Mask가 잘못 입력된다면 통신이 실패한다는 말을 했는데 한가지 상황을 가정해 보겠다.

<그림2-15>에서 A와 B는 같은 네트워크에 있으며, 같은 네트워크ID인 131.107.0.0을 사용하고 있다. 만일 B컴퓨터의 Subnet Mask를 255.255.0.0이 아닌 255.255.255.0을 할당했다고 가정을 하고 결과를 살펴보겠다. B컴퓨터는 일단 A가 로컬에 있는지 원격지에 있는지를 알아내고자 시도를 할 것이고 자신의 서브넷 마스크인 255.255.255.0을 통해서 자신의 IP와 상대방의 IP중에서 네트워크 ID를 계산해 낼 것이다. <그림2-16>을 참고로 해서 결과값을 계산해 보면, B는 131.107.3.0이라는 결과가 나오고, A는 131.107.4.0이라는 결과가 나온다.

이것은 B와 A가 서로 다른 네트워크에 있음을 보여준다. 결국 실제로는 물리적으로 같은 네트워크에 있지만 서로 다른 네트워크ID를 가졌으므로 B는 직접 로컬통신을 시도하지 않고 라우터에게 패킷전송을 요청하게 된다. 이 패킷은 131.107.4.0 네트워크를 찾아서 외부로 나가게 되고, 결국 통신은 실패하게 된다. 이렇듯 잘못된 Subnet Mask를 부여했을 때에는 B는 A와 통신하는 것이 불가능하다. 같은 네트워크에 존재하면서도 네트워크ID가 다르다는 결과가 나왔기 때문이다.

또 한가지 경우, 만일 B의 서브넷 마스크가 255.0.0.0이 할당되어 있다면 어떻게 될까? 결과부터 말한다면 이번에는 같은 네트워크의 A와는 통신할 수 있지만 C와는 통신하는 것이 불가능하다. 차근차근 결과를 계산해보면 답이 나온다. 255.0.0.0 서브넷 마스크를 이용해서 B와 C의 IP Address에서 Network ID를 각각 계산해 보면 같은 결과인 131.0.0.0이 나온다. 물리적으로는 다른 네트워크에 위치해 있으면서 서로 같은 네트워크ID를 사용하게 되면 이들 둘은 통신을 할 수가 없게 되는 것이다.

이렇듯 Subnet Mask도 IP Address못지 않은 중요한 역할을 담당하고 있는데 이러한 Subnet Mask는 어떻게 할당되는 것일까? 이것도 기본적인 원칙이 있다.  

서브넷 마스크 결정방법 IP Address중 네트워크ID 부분은 1로 기록하고, 호스트ID  부분은 0으로 기록한다.

앞에서 각 클래스별로 Network ID가 사용하는 옥텟을 이야기한 바 있다. 거기에 따른 서브넷 마스크를 정리하면 <그림2-19>과 같다.

<그림2-19. Default Subnet Mask>

 

위와 같이 클래스별로 고정된 Subnet Mask를 할당하게 되는데 이것을 가리켜 "Default Subnet Mask"라고 부른다. 특별히 Default라는 표현을 썼다는 것은 뭔가 냄새를 풍긴다. 그렇지 않을 수도 있다는 것을 의미하는데, 각각 8비트, 16비트, 24비트 등으로 고정된 길이만큼 네트워크ID가 사용되는 것이 아닌, 클래스개념을 무시한 IP Address관리방법이 제공되기 때문이다. 이것을 CIDR(Classless Inter Domain Routing)이라고 한다. IP Address를 효율적으로 관리하기 위한 필수적인 개념인만큼 정리를 해 보도록 하겠다. 다음 장에서 CIDR, VLSM등에 대해서 설명한다.

 

2-2-2. Default Gateway

 

호스트가 TCP/IP통신을 할 때 가장 먼저 목적지 호스트가 자신과 같은 로컬에 있는지 원격지에 있는지를 판단한다고 했다. 이때 원격지에 있는 결과가 나오면 컴퓨터는 Default Gateway를 이용해서 통신을 하게 된다. 결국 Default Gateway를 정리하면 "자신의 네트워크에 있는 라우터의 로컬 인터페이스의 IP Address"라고 할 수 있다.

 

라우터도 역시 자신의 네트워크에 있는 하나의 호스트처럼 생각하면 된다. 하는일이 다를 뿐이지 통신에 있어서는 차이가 없다. 만일 목적지 호스트가 로컬에 있다면? 그때는 Default Gateway는 쓰임새가 없다. Default Gateway가 없어도 로컬네트워크와의 통신에는 아무런 문제가 없음을 말하는 것이다.

 

<그림2-20. 로컬 컴퓨터의 라우팅 테이블>

 

위의 그림은 Windows환경의 OS에서 라우팅 테이블을 확인해 보았다. Ipconfig 를 통해서 Default Gateway가 192.168.5.1인 것을 알 수 있다. 그 다음에 Route print 명령을 실행하니 라우팅 테이블을 보여준다. 하이라이트된 부분을 보니 다음과 같다.

Network Destination            Netmask              Gateway              Interface               Metric 0.0.0.0                    0.0.0.0              192.168.5.1           192.168.5.5                  1

0.0.0.0 이 Default Gateway를 나타내는 테이블이다. 만일 이 호스트에서 “Ping 192.168.6.200”이라고 명령을 실행하였다면 192.168.6.0네트워크는 라우팅 테이블에 명시되어 있지 않은 네트워크이기 때문에 어디로 패킷을 내 보내야 할지 모르게 된다.

이때 이 호스트는 0.0.0.0 으로 시작하는 이 테이블을 이용해서 통신을 시도하게 된다. 네트워크로의 통신은 이 테이블 항목을 사용해서 통신을 시도한다. 이것을 해석해 보면, 192.168.5.5로 셋팅된 네트워크 어댑터 카드를 통해서 192.168.5.1에게 패킷을 내 보내라는 것을 의미한다. 결국, 네트워크 경로에 명시되지 않은 모든 네트워크를 목적지로 하는 패킷은 192.168.5.1에게 보내서 통신을 처리하라는 것을 알 수 있다. 이것이 기본게이트웨이 이다.

간혹 TCP/IP 등록정보에서 볼때는 기본게이트웨이가 잘 셋팅되어 있지만 라우팅테이블이 없어지는 경우가 발생한다. 이럴 경우는 당연히 이 호스트는 외부 인터넷 환경으로는 접근이 되지 않게 되는데 그때는 문제해결이 쉽지 않다. 문제해결을 위해 TCP/IP등록정보를 확인해 봐도 아무런 문제가 없기 때문이다. 그때 route print 명령을 이용하여 0.0.0.0 경로가 잘 살아있는지를 확인해 볼 필요가 있다. 만일 없다면 기본게이트웨이가 설정이 되어 있지만 없는것과 마찬가지이다. 그럴 때는 route add 명령을 이용해서 직접 추가해 주거나, TCP/IP등록정보를 열고 기본게이트웨이를 지웠다가 다시 생성해 주면 해결된다. 라우팅 테이블에 0.0.0.0 경로가 살아났는지 확인하는 것은 당연한 일이다.

<그림2-7>에서의 호스트는 IP Address로써 "192.168.5.3"이라는 숫자를 사용하고 있다. 이 IP Address를 살펴보면 3자리 숫자가 4개가 모여있고, 사이사이에는 dot로써 구분을 해 주고 있다. 이 3자리 숫자는 우리에게 익숙한 10진법으로 표기가 되어 있는 것을 알 수 있다.

<그림2-7. TCP/IP 등록정보>

그렇다면 아래의 그림을 보자.

<그림2-8. IP Address 입력 오류 메시지>

TCP/IP 구성을 수동으로 하다 보면 가끔 <그림2-8>와 같은 메시지를 받는 경우가 있다. <그림2-8>의 메시지를 보면 256이라는 숫자를 입력하려고 시도했을 때 "256의 항목이 올바르지 않다. 0~255사이의 값을 지정하라"는 메시지를 보여주고 있다. 이상한 생각이 든다. 10진수라면 3자리를 가지고 만들 수 있는 가장큰 수는 999 여야 하는데, 256을 넣었더니 입력이 되지 않고 0부터 255사이의 값을 지정하라고 한다. 그렇다. 10진수로 표기를 하고 있지만 내부적으로는 10진수가 아닌 것이다. 그렇다면 어떻게 구성이 되어 있을까?

IP Address는 디자인될 때 32개의 비트를 사용하여 IP Address를 만들어졌다. 다시 말하면 0 아니면 1인 값이 32개가 나란히 늘어서 있는 것이 IP Address를 구성하고 있다는 것을 의미한다. 아래의 <그림2-9>를 보면서 설명한다.

<그림2-9>에서는 192.168.5.2 라는 IP Address를 예제로 보여주고 있다. IP Address는 십진수도 아니고 세자리 숫자 4개가 3개의 dot(.)로 구분된 것도 아니다. 단지 0 아니면 1인 비트가 32자리가 쓰여 있을 뿐인 것이다. 32bit이니 결국 4Byte이다. 현재 우리가 사용하는 IP Address의 버전은 "4(Four)"이고 이 버전 4는 32bit 즉 4Byte체계의 IP Address를 사용하고 있다. 이러한 32bit숫자를 그대로 시스템의 IP Address로 사용한다면 우리가 사용하기는 꽤 어려울 것이다. 0아니면 1인 숫자가 32자리가 배열이 되어 있으면 사용하기가 어려울 수 밖에 없다. 그런 이유로 보다 편한 표기법을 채택하고 있다. 일단 8bit씩 나눠서 구분을 한다. 8bit면 1Byte이니 구분하기가 한결 용이해진다. 이렇게 나뉜 하나하나의 단위를 "8"을 나타내는 "옥텟 (Octet)"라고 부른다. 32bit를 8bit씩 나누니 4개의 8bit. 즉 4개의 octet가 생겼다. 이들 octet와 octet를 구분하기 쉽게 하기 위해 dot(.)를 구분자로 사용하였다. 마지막으로 각각의 옥텟 단위별로 2진수를 10진수로 변환하여 놓은 것이 바로 우리가 사용하고 있는 IP Address이다.

아래의 <그림2-10>을 보겠다. 3단계로 나눠서 보면, 맨 위의 그림은 32개의 자리수를 가진 빈 상자가 있다. 여기에 0, 1 둘중의 한가지 숫자를 채울 수가 있을 것이다. 첫 번째의 옥텟만 가지고 계산을 해 보았다. 8bit 자리에 넣을 수 있는 가장 큰 숫자는 여덟 개의 비트 전체가 "1"로 만들어지는 숫자가 된다. "11111111"을 십진수로 계산하면 "255"라는 결과를 얻을 수 있다. 이렇게 되면 위에서의 의문이 풀린다. 왜 IP Address로 할당할 수 있는 최대숫자가 999가 아닌 255가 되는지를 알 수 있을 것이다. 그렇게 전체 옥텟을 채워보면 255.255.255.255가 나온다. 이것이 IP Address로 사용될 수 있는 가장 큰 주소이다.

위에서 우리는 IP Address가 32개의 bit로 이루어진 값이라는 사실을 알 게 되었다. 이제 그러면 이러한 IP Address가 어떠한 체계로 관리가 되는지 알아보도록 하자. 현재 IP Address는 IANA(Internet Assigned Numbers Authority)라는 기관에서 관리되고 있다. IANA는 전체 IP Address를 관리하며 ISP(Internet Service Provider)들에게 IP Address를 발급하고, 일반 사용자들은 그러한 ISP로부터 IP를 할당받아서 호스트에게 할당하고 인터넷에 액세스하게 되는 것이다. 당연히 IP Address가 무작위로 할당되지는 않는다. 이 IP Address는 Class 라는 특별한 개념에 근거하여 관리되고 있다. 자세히 알아보자.

네트워크 통신을 위해TCP/IP를 사용하는 모든 컴퓨터들은 IP Address를 가지고 있다. 이 IP Address는 당신의 컴퓨터를 네트워크에서 유일하게 구분해 줄 수 있는 고유번호를 의미한다. 굳이 TCP/IP를 전혀 모르더라도 집에서 전화, ADSL, 케이블모뎀 등을 통해서 인터넷에 접근한다거나,  친구에게 E-mail을 전송하고, PC방에서 어디 있는지 모르는 누군가와 채팅을 하거나, 네트워크 게임을 즐기고 있다면 이미 당신은 TCP/IP를 사용하고 있고 당신의 컴퓨터는 IP Address를 가지고 있어야만 한다. 네트워크 관리자가 이러한 IP Address의 체계에 대해서 잘 이해하고 관리할 수 있어야 한다는 것은 필수적이다.

이번 장에서는 TCP/IP를 구성하고 있는 IP Address, Subnet Mask, Default Gateway등의 역할들에 대해서 살펴보고, IP Address에 대해서 구체적으로 살펴보도록 한다.

컴퓨터에서 TCP/IP등록정보에 접근해 보면 아래의 <그림2-1> 혹은 <그림2-2>와 같은 두가지 유형의 설정을 확인할 수 있다.

분명히 위의 두 그림은 달라 보이지만, <그림2-2>의 경우도 보조프로그램의 명령프롬프트를 열고 "ipconfig"를 입력해 보면 TCP/IP의 구성을 확인할 수 있다.

이렇듯 TCP/IP를 사용하기 위해서는 IP Address, Subnet Mask, Default Gateway등의 정보들이 구성이 되어 있어야 하는데 네트워크 관리자라면 당연히 이들의 역할들에 대한 명확한 이해를 해야 할 것이다. 어려운 수학은 아니지만 아무래도 숫자만 나오면 머리가 아파지기 시작하는 우리들로서는 차근차근 접근해 볼 필요가 있다. 먼저 IP Address에 대한 설명을 하도록 한다.

IP Address는 Network ID와 Host ID로 구성되어 있다. 갑자기 무슨 소리인가 싶겠지만 이것은 IP Address를 공부하는데 아주 중요한 개념이다.

다른 통신도 마찬가지이긴 하지만 특히 TCP/IP통신은 우리들의 생활과도 아주 밀접한 연관성이 있다. 우리가 현실에서 외부 누군가와 편지를 주고 받는 과정이 TCP/IP통신과정과 아주 유사하다. 우리가 편지를 주고 받을 때의 상황을 상기하면서 이해를 하면 쉽다.

대한민국의 가구수가 얼마나 될까? 뭐 중요한 건 아니다. 얼마 전 뉴스를 보니 90년대 이후 빠르게 핵가족화가 진행 중이라는데, 남한의 가구수가 1,600만가구를 넘었다고 한다. 각 가구들을 구별하기 위해서 우리는 "번지"라는 개념을 사용하는데 그 번지가1번지부터 1,600만 번지까지 존재하는 것은 아니다. 행정구역이라는 개념으로 시, 도, 동... 등을 구분하여 사용하며 최종적으로 번지라는 단위로써 각각의 가구들을 구분해 주고 있다.

만일 이러한 세부적인 단위를 사용하지 않고 전체가구가 개별적인 번지수 하나만으로 주소를 이루고 있다면 어떻게 될까? 물론 이 경우도 편지를 주고 받는 데는 문제가 없다. 1번지에 사는 사람은 100번지에 사는 사람에게 편지를 보내기 위해 편지 겉봉에 받을 사람 주소를 쓰고 우체국에 편지를 부칠 것이며, 우체국에서는 100번지인 주소를 찾아서 편지를 배달해 줄 것이다. 이때 우체국에서는 큰 노력이 필요하다. 대한민국 전체를 오로지 "번지"로만 나누었기에 100번지가 어디쯤 있는지 지도책을 펴 놓고 찾을 것이며 직접 그곳까지 배달을 해야 할 것이다. 우체국 입장에서는 자신이 배달해야 할 경로가 총 1600만 가지의 경우의 수가 있는 것이다.

조금 더 편한 방법은 무엇일까? 당연히 그것은 그룹으로 나누는 방법에서 찾을 수 있다. 여러개의 번지를 묶어서 그룹으로 나누면 그만큼 경로의 수가 줄어들기 때문에 배달업무에 효율성을 기할 수 있게 될 것이다. 개별적인 번지수까지 신경 쓸 이유는 없어지고 다만 그 주소가 속해있는 그룹에게 편지를 배달해 주면 되기 때문이다. Network ID도 바로 그러한 것이다.

전체 IP Address를 따로 따로 관리하기 보다는 Network ID라는 이름으로 그룹을 만들어서 Network ID 단위로 IP Address를 관리하면 그만큼 효율적으로 IP Address를 관리하고 무엇보다도 보다 원활한 편지배달작업에 해당하는 라우팅(Routing)이 가능해질 수 있기 때문이다.

Network ID에 관련한 중요한 개념 한가지를 챙겨보도록 하겠다. 그림을 예로 들어 설명을 한다. 우리가 실생활에서 편지를 보낼 때의 절차를 통해서 정리를 할 것인데, 먼저 2가지를 가정한다.

(1) 편지의 주소는 "동"과 "번지"만으로 이루어져 있다.

(2) 같은 동에 속한 사람들끼리는 직접 편지를 교환하고, 다른 동으로 편지를 보내기 위해서는 반드시 우체국을 이용해야 한다.

예제에서는 "삼성동"과 "대치동"사이에 어떻게 편지가 교환이 되는지에 대한 그림을 보여준다. 예제에서 "동"에 해당하는 것이 "Network ID"이고, "번지"에 해당하는 것이 "Host ID"가 된다. 우체국은 다른 네트워크 패킷을 라우팅해 주는 "라우터(Router)"에 해당한다.

위의 <그림2-4>는 "삼성동 100번지"에 사는 사람이 "대치동 100번지"로 편지를 발송하는 상황이다.

"삼성동 100번지"에서는 편지(data)를 쓴 다음 겉봉투(packet)에 넣고 수신인 란에는 "대치동 100번지"라고 기록을 했다. 그 다음 편지를 발송하기 위해 첫 번째로 하는 일은 수신처가 자신과 같은 "동(Network ID)"에 있는지 다른"동"에 있는지를 파악하는 일이다(①). 같은 "동"이라면 직접 편지를 배달할 것이고, 다른 "동"이라면 "자신의 관할 우체국(로컬 라우터)"에게 편지배달을 요청해야 하기 때문이다. 

예제에서 수신처가 자신과는 다른 "대치동"관할에 있으므로 두 번째로 할 일은 "삼성동 우체국"으로 편지를 보내러 가야 한다(②).

삼성동우체국에서는 발신자의 주소는 중요하게 취급되지 않는다. 중요한 정보는 수신자의 주소인 "대치동 100번지"가 되는데, 그 중에서도 "대치동"이라는 "동(Network ID)"정보가 필요할 뿐이다. 100번지라는 "번지(Host ID)"수는 의미가 없다. 자신이 직접 최종목적지까지 편지를 배달할 것은 아니기 때문이다. 그래서 삼성동우체국에서는 "대치동"이라는 목적지를 확인한 다음 그 목적지로 가기 위한 경로(Routing Table)를 확인하여 대치동 우체국으로 편지를 발송한다. 이때 발송방법은 여러 가지가 있을 것이다. 비행기, 자동차, 선박 등을 이용해서 상대방 우체국까지 편지를 발송해주게 된다(③).

대치동 우체국에서 편지를 받고서 자신의 관할영역임을 확인한 다음, 편지겉봉의 수신처 주소중 "번지"를 확인하게 된다. "100번지"라는 번지를 근거로 "대치동 100번지"의 우체통에 편지를 배달해 줄 수가 있게 된다.(④) 이렇듯 다른 "동(Network ID)"으로 편지를 보내기 위해서는 반드시 자신의 관할 우체국(Local Router)의 도움을 받아야 하는 것을 확인할 수 있다.

<그림2-5>는 같은 "동"에 있는 "삼성동 200번지"로 편지를 배달하고 있다. 과정은 앞의 예제와 다를바가 없다. 다만 편지를 작성한 다음 가장 먼저 수신처가 자신과 같은 동에 있는지 다른 동에 있는지를 판단해서 같은 동에 있다는 판단을 하였기에 우체국에 편지를 부치지 않고 직접 편지를 배달하고 있다.

당연한 것을 왜 설명하는지 의아해 하는 독자가 있을 것이다. 하지만 여기서 중요한 원칙 하나가 나온다. 물리적으로 같은 "동"에 위치한 집들은 반드시 같은 "동"의 주소를 할당받아야 하고 다른 "동"에 위치한 집들은 반드시 다른 "동"의 주소를 할당받아야 한다는 것이다. 다시 정리하면 같은 네트워크에 존재하는 컴퓨터들은 반드시 같은 "Network ID"를 사용해야 하고, 다른 네트워크에 존재하는 컴퓨터는 반드시 다른 "Network ID"를 사용해야 한다는 것을 의미한다. 아래의 <그림2-6>을 통해서 설명하도록 한다.

<그림2-6>의 상황은 "삼성동200번지"에 살던 <B>라는 사람이 "대치동"으로 이사를 했다. 당연히 대치동에서 새로운 번지를 할당 받아야 하겠지만 고집스럽게도 <B>는 물리적으로는 "대치동"관할에 있으면서 주소는 예전 그대로 "삼성동200번지"를 사용하고 있다고 가정해 보겠다. 결과적으로는 <B>는 어느 누구와도 편지를 주고 받을 수 없다. 왜 그럴지 살펴보겠다.

먼저 "삼성동100번지"에 있는 <A>와의 통신을 고려해 보면 <A>는 <B>에게 편지를 보내기 위해 편지 겉봉에 "삼성동200번지"라는 주소를 기록할 것이다. 같은 "동(네트워크ID)"에 있는 사람이기에 우체국에 편지를 부치는 것이 아니라 직접 편지를 배달하려고 시도를 하겠지만 실제로는 다른 "동"으로 이사를 가 버린 <B>에게는 편지가 도착될 수가 없게 된다. 이번엔물리적으로 같은 "동"에 위치한 "대치동100번지"의 <C>와 <B>의 통신을 고려해 보겠다. <C>는 역시 <B>에게 편지를 부치기 위해 편지겉봉에 수신처주소에는 "삼성동200번지"를 사용할 것이다. 자신과 다른 "동"에 위치해 있다는 것을 알 게 되고 직접 발송하는 것이 아니라 "대치동 우체국"에 발송을 요청하게 될 것이다. 대치동우체국에서는 목적지가 "삼성동"으로 되어 있으므로 "삼성동우체국"으로 편지를 보낼 것이고, 우체국에서는 번지를 확인해서 "200번지"를 찾게 되지만 실제로는 이사를 해 버린 <B>를 찾을 수가 없게 된다. 역시 편지발송이 실패하게 된다.

위에서 예제에 따르면 "같은 동에 사는 사람들은 주소역시 같은 동의 주소를 가져야 하며, 다른 동에 사는 사람과는 다른 동의 주소를 사용하여야 한다"라는 결과가 나온다. TCP/IP통신에 맞춰서 얘기해 보면 다음과 같다.

"같은 물리적인 네트워크에 존재하는 컴퓨터들은 반드시 같은 "Network ID"를 사용해야 하고, 다른 네트워크에 존재하는 컴퓨터는 반드시 다른 "Network ID"를 사용해야 한다".

이것은 TCP/IP를 사용하는 컴퓨터들간의 통신을 위해서 반드시 지켜져야 하는 원칙이다. 예를 들면 192.168.5.0이라는 네트워크 ID를 할당한 세그먼트에 A와 B가 있다면 이들 둘의 통신을 위해서는 A와 B는 동일하게 192.168.5.0 네트워크 ID를 사용하는 Host ID가 할당되어야만 한다. A에게 192.168.5.1을 할당하고, B에게 192.168.5.20을 할당했다면 둘은 통신이 되겠지만, 만일 B에게 192.168.6.20을 할당했다면 둘은 통신을 할 수가 없게 된다. 물리적으로 같은 네트워크에 서로 다른 네트워크ID가 할당되었기 때문이다. 192.168.5.1과 192.168.6.20이 어디가 어떻게 다른 것인가? 이제부터 그런 내용을 배우게 된다.