동일 네트웍에서 장비 2500대쯤 사용하려는데 고려해야 할 사항이 뭐가 있을까요?

정의석   
   조회 5408   추천 0    

 실제 장비는 1500대 정도인데,, 이중에서 1000대가 네트웍 포트가 2개씩이라(2개를 다 써야 하는 상황임) 총 2500개 정도가 되네요.

가능하면 라우팅이나 vlan을 사용하지 않으려고 합니다. (라우팅 할 수 있는 스위치는 메인스위치만 가능 합니다.)

외부와는 단절된 순수 내부 네트웍이고요...

서브넷을 255.255.0.0으로 해서 IP를 부여하니 기본적인 통신은 잘 됩니다.

의문1. 각 장비들이 네트웍 사용량이 많지는 않아서 속도문제는 없는것 같습니다. 속도문제 외에 발생할 문제가 있을까요? 예를들어,, 장기간 사용하다보면 네트웍장비에 이상이 온다던가 하는거요..

의문2. 각 장비들에 IP할당을 위해 Windows Server 2008 R2에 있는 DHCP서버를 사용하고 있습니다. MAC Address기반으로 지정된 IP를 할당해서 사용하고 있습니다. 그런데 전체 장비를 재부팅하면,, 이중에서 몇대정도가 IP충돌이 납니다. DHCP서버의 과부하로 보기엔,,, 시간이 지나도 정상적인 IP를 받오지 못하고 다른장비의 MAC Address에 배당된 IP를 받아왔다가,, 충돌나서 끊기고... 계속 이럽니다. 전체 장비를 다시 재부팅하면, 이번에는 다른장비 몇대에서 이런 증상이 발생합니다.

네트웍 구성은,

메인스위치(1대) - 층간스위치(2대) - 랙 스위치(각 랙당 2대, 랙 수량 32대, 랙당 32대의 장비)


짧은글 일수록 신중하게.
엠브리오 2016-05
자주 충돌이 일어 난다면 DHCP 서버에서 각 컴퓨터의 MAC 주소값을 전부 가지고 있는 것이 좋겠네요.
별도로 DHCP 서비스만 전담해서 처리하는 리눅스 컴퓨터를 한대 두는것도 좋겠구요.
     
정의석 2016-05
DHCP서버만 전담하는 Xeon 서버(Xeon 5500급 2CPU)가 한대 있고요, MAC주소값을 다 가지고 있습니다.
시스템을 가동하게 되면 1분안에 2000개의 IP를 할당해야 하는데,, 시스템 성능을 높이면 가능할까요?
시도니 2016-05
서브넷을 크게 가져가면 브로드캐스트에 대한 대책을 반드시 세우셔야 합니다.이 브로드캐스트가 네트워크에 많이 돌아다니면 네트워크의 효율만 떨어지는 게 아니라 해당 브로드캐스트 트래픽이 나를 찾는 트래픽인지를 cpu 가 확인해봐야 허기 때문에.. 전체적인 시스템 퍼포먼스에도 문제가 생깁니다.

왠만한 모든 트래픽은 유니캐스트로만 통신하도록 유도하십시요.
     
정의석 2016-05
Xeon 2CPU 서버가 오직 DHCP역할만 하기 때문에,, 서버의 퍼포먼스 문제는 상관없습니다.
다만,, 궁금한건 브로드캐스트가 많다면, 어떤 문제가 생기나요?
막연히 네트웍 퍼포먼스가 떨어진다는것은 아는데, 어느정도나 떨어지는거고, 만일 브로드캐스트가 네트웍에 돌아다닐 때 이 브로드캐스트를 어떻게 하면 제거 할 수 있을까요?(모든 네트웍장비와 서버를 다 꺼야 하나요?)
          
시도니 2016-05
브로드캐스트 트래픽 성격 자체가 문제입니다.

컴퓨터는 모든 장치와 BUS 로 동기화를 맞춥니다.

그런데 그 BUS 와 별도로 동기화 되는 것이 ethernet 카드 입니다.

만약 A 라는 PC 가 하나의 브로드캐스트를 날리면 그 네트워크 안에 있는 모든 PC 가 해당 패킷을 열기위해 cpu 를 사용해서 확인해야 합니다.

그런데 unicast 라면 A가 B 라는 곳에 보내는 패킷이라면 B 가 아닌 모든 시스템은 설사 flooding 되는 먹통허브에 의해서 전달된다 하더라도 NIC 단에서 discard 되면서 처리됩니다.

이 브로드캐스트를 통한 공격중에 대표적인 것이 웜이라고 할 수 있습니다.

만약 몇몇대가 웜에 걸렸다면 그 네트워크안에는 브로드캐스트 트래픽때문에 유니캐스트가 밀려 서비스가 중단되거나 이를 처리하기 위한 CPU 가 부하를 받아서 버퍼오버플로우로 뻗을 수 있습니다.

그러므로 어플리케이션을 만들 당시부터 브로드캐스팅 트래픽을 많이 사용하여 만드는 것은 좋지 않습니다.

물론 브로드캐스트를 전혀 안 쓸 수는 없습니다.

특정서버에 대한 정보가 없다거나 특정서버군을 찾는 다던가 한 그룹에 모든 데이터 전송이 필요할 시에 사용하면 좋지요. 안그러면 그 대수 만큼 시스템에 전송을 보내야 하니까요.  실시간성이나 전송효율이 떨어지니까요.
송진현 2016-05
서브넷을 /24로 만들고  목적에 따른 넷워크를 그룹화하고..
라우팅을 생성하는것이 더 좋을거 같습니다.
브로드와 멀티라는것이 2500대의 트래픽이라면.. 무시못할수준이고..
서브넷이 큰 네트워크의 경우는 백도어가 열린 컴퓨터를 찾을때 매우 복잡합니다...
하지만 그룹화된경우 그룹만 찾아서 네트워크에서 제외하고 나머지만 사용가능한 형태도 가능합니다..
그리고 2500대가 한개의 네트웍에 묶인다느것은...
스니핑 스푸핑등의 취약점에 노출되는 아주 위험한 형태라고 생각합니다..
즉 7층의 VIP만 접근가능한 데이터가 저장된 서버가 있는데.
6층에서 7층에 데이터를 저장하고있습니다만..
1층에서 패킷의 내용을 볼수도 있다는 생각입니다.

 IP충돌에 대해서는 저의 개인적인 견해입니다만..
서버가 다운된다음에 2500대가 동시에 켜질경우에 2500개의 컴퓨터가 DHCP를 찾기위하여 브로드캐스트를 이용하며
이때 DHCP의 버퍼가 오버된것이 아닐까 생각해봅니다..
     
정의석 2016-05
폐쇄망이기 때문에 보안에 대한 문제는 없습니다.
...
그리고 저도 DHCP서버의 버퍼문제를 생각했었는데, 버퍼 문제라면 어느정도 시간이 지나 버퍼가 비워진다면 정상적인 IP를 받아와야 하는데 엉뚱한 IP(할당 목록에 있는 IP중의 하나 입니다.)를 받아오는거 봐서는 버퍼 문제는 아니라고 보고있습니다.
ITES 2016-05
시도니님 말씀처럼 브로드캐스트 도메인이 커지게 되면 여러 문제가 발생할 소지가 있습니다.
대부분 네트워크 설계자들은 브로드캐스트 신호가 전체 트래픽의 10%를 넘지않도록 설계한다고 합니다.
와이어샤크 등의 툴을 가지고 며칠 분석해보시고 브로드 캐스트가 10% 이상이라면 세그먼트를 나누서야 할 것 같습니다.
PiPPuuP 2016-05
고정아이피 사용하면 안되나요?
의외로 괜찬은 방법입니다.
다만 저도 2500개의 nic라면 세그먼트를 나누어야 된다고 봅니다.

(이미 시도니님께서 탁월하게 설명하셨습니만) 브로드케스트에 대해 부연설명을 하자면, 브로드케스트 통신은 특정 목적으로 전체 네트웍 내의 모든 장비들과 동시에 통신하는 기법이라고 보시면 됩니다. (대표적으로 특정 서버의 IP주소를 알지 못하는 상태에서 통신해야 할 때) 말 그대로 구내 방송입니다. 그러니깐 10MB/s의 브로드케스트 신호량이 발생하면 네트웍 내의 모든 장비들이 10MB/s의 트래픽을 받아다가 CPU로 분석하고 있게 됩니다.

네트웍 내의 아무 단말기에서든 console 띄우시고 ping 255.255.255.255 해보세요. 네트웍 내의 모든 장비가 응답할겁니다. 이게 브로드케스트입니다.
https://en.wikipedia.org/wiki/Broadcast_address
내부에 있는 어떤 장비라도 (그게 스마트폰이든, ipTV이든, NAS이든, Server이든, (Interface를 가지는) Switch이든, 라우터이든, 프린터이든, IP 캠이든...) 브로드케스트 트래픽을 무시하도록 설계된 특별히 디자인된 NIC를 가진게 아니라면, 해당 트래픽은 항상 OS까지 오게되고, OS는 해당 트래픽을 처리하기 위해(무시할 것이든 아니든) CPU를 사용하게 됩니다.
브로드케스트 트래픽이 많아지면 네트웍 전체가 같이 느려지는 이유지요.


QnA
제목Page 2683/5709
2015-12   1683843   백메가
2014-05   5149309   정은준1
2005-11   5409   정성훈
2018-05   5409   나몰라1
2006-11   5409   심장현
2012-03   5409   2CPU최주희
2011-10   5409   임종열
2023-03   5409   오성기
2016-05   5409   정의석
2008-04   5409   문양호
2007-09   5409   김융기
2021-06   5409   늘파란
2007-10   5409   이승준
2005-12   5409   오상식
2016-10   5409   r이승원r
2008-07   5409   박재석
2006-03   5409   정영진
2020-11   5409   VSPress
2005-11   5409   방효문
2006-06   5409   김준성
2016-12   5409   하셀호프
2017-05   5409   성민박