서브넷 0 및 모든 서브넷
목차
소개
서브넷을 적용하면 지정된 네트워크 주소를 더 작은 서브넷으로 분할합니다.NAT(Network Address Translation) 및 PAT(Port Address Translation)와 같은 다른 기술과 결합되어 사용 가능한 IP 주소 공간을 보다 효율적으로 사용할 수 있으므로 주소 감소의 문제가 크게 줄어듭니다.서브넷에는 첫 번째 서브넷과 마지막 서브넷(서브넷 0 및 모든 서브넷)의 사용에 대한 지침이 있습니다.이 문서에서는 서브넷 0 및 모든 서브넷 및 해당 용도에 대해 설명합니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
서브넷 0
네트워크 주소가 서브넷된 경우 네트워크 주소를 서브넷 서브넷 0이라고 합니다.
클래스 B 주소 172.16.0.0을 고려하십시오. 기본적으로 클래스 B 주소 172.16.0.0에는 호스트 부분을 나타내는 16비트가 예약되어 있으므로 65534(216-2) 유효한 호스트 주소가 허용됩니다.네트워크 172.16.0.0/16이 호스트 부분에서 3비트를 빌려서 서브네팅된 경우 8(23) 서브넷을 가져옵니다.아래 표는 주소 172.16.0.0, 결과 서브넷 마스크, 해당 브로드캐스트 주소 및 유효한 호스트 주소 범위를 서브넷에 서브넷을 서브넷으로 표시하는 예입니다.
| 서브넷 주소 | 서브넷 마스크 | 브로드캐스트 주소 | 유효한 호스트 범위 |
|---|---|---|---|
| 172.16.0.0 | 255.255.224.0 | 172.16.31.255 | 172.16.0.1~172.16.31.254 |
| 172.16.32.0 | 255.255.224.0 | 172.16.63.255 | 172.16.32.1~172.16.63.254 |
| 172.16.64.0 | 255.255.224.0 | 172.16.95.255 | 172.16.64.1~172.16.95.254 |
| 172.16.96.0 | 255.255.224.0 | 172.16.127.255 | 172.16.96.1~172.16.127.254 |
| 172.16.128.0 | 255.255.224.0 | 172.16.159.255 | 172.16.128.1~172.16.159.254 |
| 172.16.160.0 | 255.255.224.0 | 172.16.191.255 | 172.16.160.1~172.16.191.254 |
| 172.16.192.0 | 255.255.224.0 | 172.16.223.255 | 172.16.192.1~172.16.223.254 |
| 172.16.224.0 | 255.255.224.0 | 172.16.255.255 | 172.16.224.1~172.16.255.254 |
위의 예에서 첫 번째 서브넷(서브넷 172.16.0.0/19)은 서브넷 0이라고 합니다.
서브넷 0을 결정하는 데 네트워크 서브넷의 클래스와 서브넷 서브넷 서브넷 수 중에서 서브넷 0을 확인할 수 없습니다.네트워크 주소를 서브넷할 때 얻은 첫 번째 서브넷입니다.또한 서브넷 0 주소의 이진수에 해당하는 바이너리를 쓸 때 모든 서브넷 비트(이 경우 비트 17, 18 및 19)는 0입니다.서브넷 0은 모두 0 서브넷이라고도 합니다.
All-One 서브넷
네트워크 주소가 서브넷된 경우 마지막으로 얻은 서브넷을 모두-일 서브넷이라고 합니다.
위의 예와 함께 서브넷 172.16.0.0(서브넷 172.16.224.0/19)을 서브넷 서브넷 172.2)에서 얻은 마지막 서브넷을 모두-원 서브넷이라고 합니다.
네트워크 서브네팅의 클래스와 서브넷 서브넷 서브넷 수 등은 모든 서브넷 결정 역할을 하지 않습니다.또한 서브넷 0 주소에 해당하는 이진수를 쓸 때 모든 서브넷 비트(이 경우 비트 17, 18 및 19)는 1이므로 이름이 됩니다.
서브넷 0 및 전체 서브넷 문제
일반적으로 서브넷 0과 모든 서브넷 서브넷을 주소 지정에 사용하지 않는 것이 좋습니다.RFC 950 
에 따르면 "서브네팅 네트워크에서 이러한 특수(네트워크 및 브로드캐스트) 주소의 해석을 보존하고 확장하는 것이 유용합니다.즉, 서브넷 필드에 있는 모든 0과 모든 0의 값을 실제(물리적) 서브넷에 할당해서는 안 됩니다." 이것이 네트워크 엔지니어가 3비트를 빌려서 얻은 서브넷 수를 계산해야 하는 이유가 23(8)가 아니라 23-2(6)를 계산하는 것입니다. -2는 서브넷 0과 모든 서브넷 서브넷이 일반적으로 사용되지 않음을 고려합니다.
서브넷 0
주소 지정에 서브넷 0을 사용하는 것은 네트워크와 주소가 구분되지 않는 서브넷을 갖는 데 따르는 혼동으로 인해 바람직하지 않습니다.
위의 예와 함께 IP 주소 172.16.1.10을 고려하십시오. 이 IP 주소에 해당하는 서브넷 주소를 계산하면 서브넷 172.16.0.0(서브넷 0)이 응답합니다. 이 서브넷 주소는 처음에 서브넷된 네트워크 주소 172.16.0.0과 동일하므로, 서브넷(서브넷 0)을 수행할 때마다 구분할 수 없는 주소가 있는 네트워크와 서브넷(서브넷 0)을 얻을 수 있습니다.이것은 이전에는 엄청난 혼란의 근원이었다.
Cisco IOS® Software Release 12.0 이전에는 기본적으로 Cisco 라우터가 서브넷 0에 속하는 IP 주소를 인터페이스에서 구성할 수 없었습니다.그러나 12.0 이전의 Cisco IOS 소프트웨어 릴리스로 작업하는 네트워크 엔지니어가 서브넷 0을 사용하는 것이 안전한 경우 글로벌 컨피그레이션 모드에서 ip subnet-zero 명령을 사용하여 이 제한을 극복할 수 있습니다.Cisco IOS Software Release 12.0부터 Cisco 라우터는 기본적으로 ip subnet-zero를 활성화했지만 네트워크 엔지니어가 서브넷 0을 사용하는 것이 안전하지 않다고 판단하면 no ip subnet-zero 명령을 사용하여 서브넷 0 주소의 사용을 제한할 수 있습니다.
Cisco IOS Software 릴리스 8.3 이전 버전에서는 service subnet-zero 명령이 사용되었습니다.
All-One 서브넷
네트워크 및 동일한 브로드캐스트 주소를 가진 서브넷을 갖는 데 내재된 혼동으로 인해 과거에 주소 지정을 위한 올인원 서브넷을 사용하지 못하게 되었습니다.
위의 예와 함께 마지막 서브넷(서브넷 172.16.224.0/19)의 브로드캐스트 주소는 172.16.255.255입니다. 이는 네트워크 172.16.0.0의 브로드캐스트 주소와 동일하며, 이는 처음에 서브넷을 설정했기 때문에 서브넷을 수행할 때마다 동일한 브로드캐스트 주소를 가진 네트워크와 서브넷(모든 서브넷)을 얻게 됩니다.다시 말해, 네트워크 엔지니어는 라우터에서 주소 172.16.230.1/19을 구성할 수 있지만, 이 작업이 완료되면 로컬 서브넷 브로드캐스트(172.16.255.255(/19))와 완전한 클래스 B 브로드캐스트(172.16.255.255(/16))를 더 이상 구별할 수 없습니다.
이제 모든 서브넷을 사용할 수 있지만 컨피그레이션이 잘못되면 문제가 발생할 수 있습니다.발생할 수 있는 상황에 대해 알아보려면 다음을 고려하십시오.
참고: 자세한 내용은 호스트 및 서브넷 수량을 참조하십시오.
라우터 2~5는 각각 여러 개의 수신 비동기(또는 ISDN) 연결을 가진 액세스 라우터입니다.이러한 수신 사용자를 위해 네트워크(195.1.1.0/24)을 4개로 분할하기로 결정했습니다.각 부품은 액세스 라우터 중 하나에 제공됩니다.또한 비동기식 회선은 ip unnum e0으로 구성됩니다. 라우터 1에는 올바른 액세스 라우터를 가리키는 고정 경로가 있으며 각 액세스 라우터에는 라우터 1을 가리키는 기본 경로가 있습니다.
라우터 1 라우팅 테이블은 다음과 같습니다.
C 195.1.2.0/24 E0
S 195.1.1.0/26 195.1.2.2
S 195.1.1.64/26 195.1.2.3
S 195.1.1.128/26 195.1.2.4
S 195.1.1.192/26 195.1.2.5
액세스 라우터는 이더넷에 대해 동일한 연결 경로, 동일한 기본 경로 및 비동기 회선에 대한 여러 호스트 경로를 가집니다(PPP(Point-to-Point Protocol) 제공).
Router 2 routing table: Router 3 routing table:
C 195.1.2.0/24 E0 C 195.1.2.0/24 E0
S 0.0.0.0/0 195.1.2.1 S 0.0.0.0/0 195.1.2.1
C 195.1.1.2/32 async1 C 195.1.1.65/32 async1
C 195.1.1.5/32 async2 C 195.1.1.68/32 async2
C 195.1.1.8/32 async3 C 195.1.1.74/32 async3
C 195.1.1.13/32 async4 C 195.1.1.87/32 async4
C 195.1.1.24/32 async6 C 195.1.1.88/32 async6
C 195.1.1.31/32 async8 C 195.1.1.95/32 async8
C 195.1.1.32/32 async12 C 195.1.1.104/32 async12
C 195.1.1.48/32 async15 C 195.1.1.112/32 async15
C 195.1.1.62/32 async18 C 195.1.1.126/32 async18
Router 4 routing table: Router 5 routing table:
C 195.1.2.0/24 E0 C 195.1.2.0/24 E0
S 0.0.0.0/0 195.1.2.1 S 0.0.0.0/0 195.1.2.1
C 195.1.1.129/32 async1 C 195.1.1.193/32 async1
C 195.1.1.132/32 async2 C 195.1.1.197/32 async2
C 195.1.1.136/32 async3 C 195.1.1.200/32 async3
C 195.1.1.141/32 async4 C 195.1.1.205/32 async4
C 195.1.1.152/32 async6 C 195.1.1.216/32 async6
C 195.1.1.159/32 async8 C 195.1.1.223/32 async8
C 195.1.1.160/32 async12 C 195.1.1.224/32 async12
C 195.1.1.176/32 async15 C 195.1.1.240/32 async15
C 195.1.1.190/32 async18 C 195.1.1.252/32 async18
비동기 회선의 호스트를 255.255.255.192 마스크 대신 255.255.255.0 마스크으로 잘못 구성한 경우 어떻게 합니까?모든 것이 잘 작동합니다.
이러한 호스트 중 하나(195.1.1.24)이 로컬 브로드캐스트(NetBIOS, WINS)를 수행할 때 발생하는 상황을 살펴봅니다. 패킷은 다음과 같습니다.
s: 195.1.1.24 d: 195.1.1.255
패킷은 라우터 2에서 수신됩니다. 라우터 2는 라우터 1로 전송하고, 라우터 5로 전송하고, 라우터 1로 전송하여 라우터 5로 전송하고, TTL(Time To Live)이 만료될 때까지 전송합니다.
다음은 또 다른 예입니다(호스트 195.1.1.240).
s: 195.1.1.240 d: 195.1.1.255
이 패킷은 라우터 5에서 수신됩니다. 라우터 5는 라우터 1에 전송하고, 라우터 5로 전송하여 라우터 1에 전송하고, 라우터 5로 전송하여 TTL이 만료될 때까지 라우터 5로 전송합니다.이러한 상황이 발생하면 패킷 공격을 받았다고 생각할 수 있습니다.라우터 5의 부하를 고려할 때, 이는 불합리한 가정일 수 없습니다.
이 예에서는 라우팅 루프가 생성되었습니다.라우터 5가 올인원 서브넷을 처리하므로, 완전히 파괴됩니다.라우터 2~4에서는 "브로드캐스트" 패킷을 한 번만 볼 수 있습니다.라우터 1도 적중되었지만 Cisco 7513인 경우 이 상황을 처리할 수 있는 것은 무엇입니까?이 경우 올바른 서브넷 마스크로 호스트를 구성해야 합니다.
잘못 구성된 호스트로부터 보호하려면 루프백 주소에 대한 고정 경로 195.1.1.255으로 각 액세스 라우터에 루프백 인터페이스를 생성합니다.Null0 인터페이스를 사용할 수 있지만, 이로 인해 라우터가 ICMP(Internet Control Message Protocol) "unreachable" 메시지를 생성합니다.
서브넷 0 및 모든 서브넷 사용
그러나 서브넷 0 및 모든 서브넷 을 포함한 전체 주소 공간은 항상 사용 가능했습니다.Cisco IOS Software Release 12.0 이후로 모든 서브넷 사용을 명시적으로 허용했고 서브넷 0을 사용할 수 있습니다. Cisco IOS Software Release 12.0 이전에서도 ip subnet-zero 전역 구성 명령을 입력하여 서브넷 0을 사용할 수 있습니다.
서브넷 0 및 모든 서브넷 사용 문제에 대해 RFC 1878 은 "이 방법(all-zero 및 all-one 서브넷 제외)은 사용되지 않습니다.최신 소프트웨어는 모든 정의 가능한 네트워크를 활용할 수 있습니다." 현재 서브넷 0과 올인원 서브넷의 사용은 일반적으로 수락되며 대부분의 공급업체에서 사용을 지원합니다.그러나 특정 네트워크, 특히 레거시 소프트웨어를 사용하는 네트워크에서 서브넷 0과 모든 서브넷 을 사용하면 문제가 발생할 수 있습니다.
피드백