고객 사이트의 IP 주소가 부족하여 / 24에서 / 12 넷 마스크로 이동하고 싶습니다… 나쁜 생각입니까?


22

내 클라이언트 사이트 중 하나가 내가 관리하는 Linux 서버의 서브넷 마스크를 변경하도록 요청하면서 10.0.0.x 체계를 기반으로 네트워크의 넷 마스크를 다시 IP / 변경합니다.

"Linux 서버 넷 마스크를 255.255.255.0에서 255.240.0.0으로 변경할 수 있습니까?"

255.255.240.0?

"No, 255.240.0.0."

많은 IP 주소가 필요하십니까?

"그렇습니다. 우리는 IP 주소를 다 사용하고 싶지 않습니다."

서브넷 치트 시트 에 대한 빠른 검사 는 다음을 보여줍니다.

  • 255.255.255.0 넷 마스크는 / (24)는 256 개 호스트를 제공합니다. 조직이 그 수의 IP 주소를 소진 할 수 있음을 분명히 알 수 있습니다.
  • 255.240.0.0 넷 마스크는 / (12)는 1,048,576 호스트를 제공합니다. 이 사이트는 소규모 <200 사용자 사이트입니다. 400 개가 넘는 IP 주소를 할당했는지 의심 할 것입니다. 아마도 500 개일 것입니다. 그러나이 시점에서 더 많은 서브넷 / VLAN을 설정해야합니다.

나는 / 22 / 21 (각각 1024 및 2048 호스트)처럼, 적은 수의 호스트를 제공하는 것을 제안하지만, 특정 이유를 제공 할 수 없습니다 에 대한 은 / 12 서브넷을 사용합니다.

이 고객이 염려해야 할 것이 있습니까? 그들이 환경에서 엄청나게 큰 마스크를 사용해서는 안되는 특별한 이유가 있습니까?


이 인수는 미래의 모든 주소가 동일한 서브넷 내에 있어야하는지 또는 서브넷을 분할해야하는지 여부에 더 중점을 두어야합니다. 그런 다음 ARP 스케일링 문제를 제기하십시오.
Skaperen

3
당신은 분명히 이것을하고 싶지 않습니다. 서브넷의 모든 유효한 IP에 대해 ARP 할 응용 프로그램이 있습니다. 당신은 정말로 그것을 묶고 싶어합니다. 또한이 하나의 서브넷으로 더 많은 IP 주소를 사용함으로써 실제로 IP 주소가 부족할 가능성이 높아 집니다. (두 경우 모두 여전히 0에 가깝지만) 단일 서브넷이 이미 성장했는지 여부를 고려하기에 좋은시기입니다.
David Schwartz

2
IPv6으로 마이그레이션해야합니다. ;-).
Reinstate Monica-M. Schröder

게이트웨이의 IP 주소를 훔치면 해당 네트워크와 다른 네트워크 (및 인터넷)의 연결이 끊어 질 수 있습니다. 네트워크에서 이러한 문제가 발생하여 사용자, 게스트, 서버 등을 별도의 VLAN에 배치하는 이유 중 하나입니다. 다른 의견 (보안, ARP 등)은 다른 의견에 언급되어 있습니다.
0xFF

답변:


25
  • 다른 답변에서 언급했듯이 브로드 캐스트 도메인에 호스트가 너무 많으면 브로드 캐스트를 혼란스럽게 만들 수 있습니다.

    잠재적 인 문제가되기 전에 서브넷에서 많은 확장이 필요합니다.

  • 미래의 성장 계획은 엉망이됩니다.

    사용 가능한 공간에 불필요하게 많은 공간을 확보 한 경우 자체 IP 공간으로 추가 사이트를 추가하기가 어렵습니다.

  • 내부 네트워크 보안 경계가 불가능 해집니다.

    서로 다른 서브넷을 서로 다른 사용자 그룹에 할당하고 보안 수준이 낮은 서버 / 보안 수준이 높은 서버 / 서버 / 스토리지 / 네트워크 장치의 제한된 관리 인터페이스를 분할하면 문제가 해결됩니다.

    집에서 바이러스를 발견 한 모든 사용자의 랩톱은 ARP가 네트워크를 중독시키고 서버를 중단 시키거나 중간자 (man-in-the-the-middle)로 만들 수 있습니다. 서버의 대역 외 관리 인터페이스와 같이 민감한 네트워크 위치에서 손상된 장치를 멀리 할 수있는 방법이 없습니다. 무고한 네트워크 설정 재구성의 오타는 네트워크의 다른 장치와 IP 충돌을 일으킬 수 있습니다.

더 많은 서브넷이 필요한 방식으로 성장하지 않고 네트워크에 복잡성이나 보안을 추가하지 않을 계획이라면 현재 네트워크 구성과 효과적으로 동일하기 때문에 괜찮습니다. '이것을 요구하고, 그들은 분명히 확장을 계획하고 있습니다.

가장 좋은 것은 물론 최악의 경우에는 매우 나쁜 생각입니다.


훌륭한 설명!
ewwhite

7

아니요, 내부 호스트 수가 동일하게 유지되는 경우 더 큰 마스크를 사용하는 데 아무런 문제가 없습니다.

유일한 문제는 이렇게하면 네트워크 관리자가 게으르고 적절한 서브넷을 사용하지 않아서 많은 브로드 캐스트 도메인에 호스트가 많이 있다는 것입니다. 예를 들어, 각 ARP 요청은 브로드 캐스트이며 (동일한 브로드 캐스트 도메인에있는) 모든 머신은 (보통 하나가 응답하더라도)이를 처리해야합니다. 브로드 캐스트를 사용하는 다른 프로토콜도 마찬가지입니다.

다른 문제는 주소 공간 일 수 있습니다. 10/8에는 16/12 개의 네트워크 공간 만 있고, / 12 요청을 계속하면 15 개만 더 들어갈 수 있습니다.

실시간 호스트를 발견하기 위해 포트 / 핑 스캔을 수행하는 일부 보안 소프트웨어는 현재보다 많은 시간이 소요됩니다 (있는 경우).

그렇지 않으면 중요하지 않습니다. 호스트가 두 개인 경우 성능은 / 30 또는 / 8에서 동일합니다. 네트워크 크기는 성능 문제를 일으키지 않습니다.


나는 똑같은 것을 제안했고 그것을 위해 투표를 받았다. VLAN 기능을 사용하여 브로드 캐스트 문제를 제어 할 수 있습니다.
mdpc

이것은 단일 위치이므로 추가 / 12가 계획되지 않았다고 생각합니다. 보안 및 IP 카메라 소프트웨어가 혼합되어 있습니다.
ewwhite

3
@mdpc 모든 호스트가 하나의 서브넷에 있고 하나의 VLAN에있는 경우 VLAN을 사용하여 브로드 캐스트를 제어 할 수 없습니다.
HostBits

동일한 서브넷의 다른 VLAN은 단순히 잘못된 아키텍처이며 호스트가 서로 통신하려고 할 때 실제로 문제가 발생합니다.
팔콘 모모 트

6

내가 볼 수있는 논쟁은 더 큰 브로드 캐스트 도메인을 가지고 있으며 10.XXX에서 사용할 수있는 추가 서브넷이 많지 않다는 것입니다.

브로드 캐스트 주장에 대응하기 위해 미래 성장만을 계획하고 있다면 현재 네트워크에 미치는 영향은 무시할 수 있어야합니다. 또한 더 많은 IP가 필요할 때까지 사물을 제어하기 위해 전체 서브넷의 작은 부분 만 분배하도록 DHCP 서버를 제한 할 수도 있습니다.

나는 개인적으로 여전히 불필요하기 때문에 그렇게하지 말아야합니다. 필요한 호스트 주소 수를 식별하고 거대한 서브넷을 버리지 않고 향후 성장을 계획하십시오.


4

이전 고용주는 대규모 부서에서 부서 네트워크를 / 16 정도 재 설계하기로 결정했습니다. 비록이 특정 부서가 상대적으로 대기 시간이 긴 링크 (도시 지역 광대역)를 통해 여러 사이트를 가지고 있었지만. 그것들은 효과가 있었으며, 10 년 전에 Gig 링크가 데이터 센터와 배포 링크에서만 흔하게 사용되었습니다.

내가 아는 한 방송 문제는 전혀 없었습니다. 내가 말했듯이, 이것은 약 10 년 전에 브로드 캐스트 트래픽을 처리하는 훨씬 더 어리석은 장치가있었습니다. 최신 장치는 그것에 대해 두 번 생각해서는 안됩니다. 이 특정 네트워크에는 노드의 약 두 배가 있습니다.


즉, 네트워크가 처리 할 수 있는 한 큰 서브넷에는 아무런 문제가 없습니다 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.