현재 한가지 문제 때문에 골치가 아픕니다.
다름이 아니라...사내 네트워크가 불안정한 현상인데요...원인을 찾기가 참 애매합니다.
일단 사내 네트워크는 대략 다음과 같이 구성되어 있습니다.
방화벽
|
|
스위치---------------서버용 허브-------------서버들...
|
|
클라이언트용 허브(대략 100여개 이상)--------------클라이언트들...(대략 400여대 정도)
문제는 같은 IP 대역에서는 전혀 문제가 없지만 다른 IP 대역으로 가는 트래픽이 드랍되거나 지연되는 현상입니다.
첨부된 스크린샷을 보면 서버용 허브에 물려있는 1번 서버에서 2번 서버로 핑 테스트를 한 것인데 (1번과 2번은 서로 IP 대역이 다릅니다.)
지연은 둘째치고...드랍까지 일어나고 있습니다. 대략 심할땐 10%가 드랍되더군요.
사용하는 서비스의 특성상 지연이나 드랍에 굉장히 민감해서 이런 현상이 발생하면 로그인조차 제대로 되지 않습니다.
각 IP 대역간 트래픽을 중개해주는 방화벽에 부하가 걸리는 것도 아니고...
그나마도 내부간 UDP는 필수적인거 몇 개 제외하고 다 막아버렸습니다.(문제가 생긴 경우가 있어서요)
이런 현상이 발생하면 임시방편으로 방화벽에서 세션을 초기화하는데...그러면 정상적으로 돌아오긴 합니다.
일단 클라이언트 단에서 문제가 있을거라는 추측이 드는데...마땅히 확인할 방법이 없더군요.
이런 경우 어떻게 원인을 찾고 대처하는 것이 좋을지 회원 여러분들의 고견을 듣고 싶습니다.
제가 보기엔 클라이언트 PC가 좀비가 있는걸로 보입니다. 특정 PC가 아웃바운드 UDP 세션을 잡은거 같아요. UDP포트를 차단했다고 UDP 아웃바운드가 안되는것이 아닙니다. 방화벽 실시간 로그 돌려보면 잡을수 있을거 같음. 전 ISA단에서 그 좀비 PC 잡았었죠. 클라이언트는 정말 아무것도 모르고 있었습니다. 백그라운드 서비스에서 대량으로 외부 아무데나 악성 스팸을 보내고 있었다는걸...
근데 저희가 내.외부 UDP 아웃바운드를 필수적인거 빼구 다 막았는데 아웃바운드가 되나요?
허용된 포트가 아니면 다 패킷을 드랍시키도록 해놨는데...
좀비가 있는 건 맞을겁니다. 얼마전에 사내에서 디도스 공격 트래픽이 발생해서 문제가 된 경우가 있었거든요.
특정 서버만 그렇거나한다면 케이블 테스트도 해보셔야 할 겁니다.
위의 회선도에서 클라이언트용 허브 100여개 정도는 한곳에 뭉쳐있는게 아니라 이곳 저곳에 분산되어 있는 EPS실에 있는 허브의 갯수라서요.
뭐 그렇다고 서버가 수백대씩 있는 그런 곳도 아니니까요.
TCP 덤프만 떠봐도 어느정도 상태를 가늠할 수 있습니다.
별 문제가 없다면 Link negotiation 도 확인해 보시기 바랍니다.
VLAN을 사용하시나요?
아니라면 저런 물리적 구성에서 네트워크 대역이 두개인 이유가 뭔가요?
제가 보기엔,
VLAN을 사용하지 않는다면 저런 구성에서 문제없이 정상적으로 동작한다면 그게 더 이상할 것 같군요.
IP 대역을 나누는 이유를 생각해보세요.
저런 환경에서 한 사용자가 자신의 IP를 서버대역으로 맞추고 통신을 하면
ISA가 도대체 뭘 할 수 있죠?
물리적 환경이 이미 잘못되었는데 ISA가 아니라 ISA 할아버지가 온들 무슨 소용이 있습니까?
그다지 좋은 구성은 아닌건 부인하기 힘드니 열내지 마세요... ^^;
하다못해 VLAN도 구성되어 있지 않으니...
방화벽에서 하단의 스위치로 연결되고 여기서 서버용 허브, 클라이언트 허브 등으로 분화되었기에
물리적으로 분할되었다고 보기는 힘들죠.
방화벽의 LAN 인터페이스가 다중 IP 대역을 지원하기도 하고...기존에 설치된 물리회선을 건드릴 수 없어 이렇게 구성이 된것이죠.
IP 대역 역시 기존에 사용하던 대역을 사용할 수 밖에 없는 상황이라 그렇구요.
설비 등에 설정된 IP 정보를 바꾸는 것도 일입니다.
여러 서비스와 얽혀 있어서 바꾸는게 어려운 설비도 있구요.
그래서 기존 대역에 추가로 대역을 더 붙여서 6개로 사용중입니다.
차후 확장을 대비해서 각 팀별로 넉넉하게 대역을 할당했거든요.
다만 말씀하신 것처럼 IP를 임의적으로 변경하는 것을 막고자 MAC Binding을 적용하려고 하고 있습니다.
IP 및 MAC 정보의 정리가 거의 끝났으니 등록하고 정책 적용만 해주면 됩니다.
Binding 정보를 계속 관리해줘야 하는 점이 귀찮지만...웹 차단 정책을 적용받지 않는 IP로 임의로 바꾸는 것을
막기 위해서도 MAC Binding이 필요하긴 합니다.
음, VLAN 구성이 되어 있지 않다면 현재 구성은 문제점이 발생할 소지가 많습니다.
우선 네트워크에 참여하고 있는 시스템 수가 상당히 많은데요.
이렇게 되면 브로드캐스트가 너무 많이 발생하게 됩니다.
네트워크가 물리적으로 분리되어 있지 않기 때문에 브로드캐스트가 네트워크 대역을 가로 지르게 되는 구조예요.
네트워크가 규모가 크고 물리적 환경이 이상해서 지연이 생기고 패킷 드랍이 발생하는 것도 무리가 아닙니다.
힘드시겠지만, 현재 환경에서 자꾸 드러나는 문제점을 막기보다는
전체적인 구성을 제대로 구축하는 작업을 진행해 나가시는게 좋으실 것 같습니다.
전체적으로 사내의 회선을 다 뜯어 고치는 작업은 힘들 것 같습니다.
각각의 EPS실에 있는 허브가 어디랑 연결되는지 아는 사람이 없는 건 둘째치고...위의 구성도에서
방화벽 하단의 스위치에 물려있는 회선이 어디로 가는지도 아는 사람이 없어요.
그렇다고 하나씩 뽑아보면서 테스트 할 수도 없고...난감합니다.
지금 가장 심플한 해법은 방화벽 하단의 스위치를 성능 좋은 관리기능이 포함된 스위치로 변경하고 VLAN을 구성하는 것인데 이것은 내년초에 일정이 잡혀 있습니다.
라인이 쉬는 구정에 일정이 잡혀 있는데 그때 상황에 따라 라인이 쉬지 않는다면 또 연기되겠네요.
제가 아는 한도에서는 이게 가장 나은 해법인데 더 좋은 해법이 있다면 기탄없이 말씀해 주시면 좋겠습니다.
어쨌거나 제가 이 질문을 한 요지는 지금 상태에서도 지연이나 드랍은 없이 양호하게 사용중인데 가끔가다
드랍이나 지연이 생기는 이유가 궁금해서 입니다.
브로드캐스트 트래픽 때문에 발생한다기에는 종종 새벽에도 발생하는 이 현상을 설명하기가 어렵네요.
예전에 회사 입사하면 늘 네트워크부터 전부 정비하던 생각이 나네요.
그쪽일을 하는 사람도 아닌데...
물리적으로 전체 환경을 바꿀 수 없다면 라우팅을 스위치단으로 분산시키도록 VLAN을 이용하는 것이 답일 거 같습니다.
다만 VLAN으로는 보안의 문제를 해결할 수 없다는 점은 염두에 두셔야겠죠.
그리고 현재 환경에서 문제가 발생할 수 있는 부분이 여러 곳이라 딱히 이게 문제다라고 말씀드리기 힘드네요.
라우터 역할을 하는 방화벽의 문제일 수도 있고 스위치의 문제일 수도 있습니다.
스위치가 여러 대역의 MAC을 learning하게 되는데 오동작을 일으킬 확률도 있을거 같네요.
중추 스위치의 경우 MAC table이 full이 날 확률도 높겠죠.
환경이 복잡해서 문제가 날 소지가 많고 또한 해결하기도 힘든 상황으로 보여집니다.
그다지 도움이 되는 답변 드리지 못해서 죄송스럽네요.
뭐가 어이 없다는건지 이상한데요? ISA가 그리 만만한 제품이 아닌데요. 직접 설계하고 라우팅하고 서버와 클라이언트간의 거의 완벽한 통제 정책중 하나입니다. ISA써보면 다른제품 눈에도 안들어옵니다.
너무 기본적인 내용이라 아예 언급을 안하는 것인데,
이걸 물리적으로 동일한 네트워크에 대역을 나누라고 이해하셨나보네요. ^^;
네트워크가 분리되어 패킷이 라우터인 ISA서버로 지나가야 정책등이 적용되죠.
글쓴님께서 그려주신 네트워크 구성도를 가만히 한번 살펴보세요.
뭐가 문제인지 이해가 안가시면 ISA가 아니라 네트워크의 원리에 대해서 좀 살펴보시고 생각해보시면 좋겠네요.
이전 댓글에서 말씀드렸는데 이해가 안가신다면 글로는 설명 드리기 힘들 것 같네요.
그리고 ISA가 나오기 훨씬 전에도 리눅스에서는 저런 기능을 전부 구현했었고 활용하여 사용을 했습니다.
훨씬 전부터 PC기반에서 저런 기능을 하는 제품이 있었다는 것을 모르셔서 ISA에 그리 환호하시는거 같은데요.
예전부터 활용하던 입장에서는 뭐 그다지 신선할 것도 없는 다만 마우스로 똑닥거릴 수 있는 또 하나의 제품이라 생각되어질 뿐이네요. 뻑하면 리붓해도 되는 환경이라면 뭐 쓸만도 하겠지만요...
뻑하면은 시스템이 다운됐다는 의미가 아니라 '자주' 라는 의미로 썼습니다.
윈도 시스템도 좀 사용하는데 업데이트 리붓때문에 힘들더군요.
특히 ISA서버와 같은 역할은 라우터로 기능을 하게 되는데 이걸 자주 리붓을 해야 한다면
굉장히 관리가 어렵겠다는 생각이 들어서 한 소리입니다.
뭐 리눅스가 좋다 윈도우가 좋다 그런 내용은 아닙니다.
뭐 사용하는 입장에서 더 쉽게 목적을 달성할 수 있는 솔루션을 사용하는게 당연하지 않겠습니다.
대부분 특정 시스템이 굉장이 좋다던지 그것이 답이라고 우기는 사람들을 보면 그것밖에 모르는 경우가 많더군요.
1. 방화벽의 내부셋팅(예:MTU사이즈, 보안설정 등) 문제 또는 Nic인터페이스 불량
2. 사용하시는 구성이 허브라면 팻킷콜리젼(충돌)이 발생하는지 확인(모니터LED등이 있다면..)
만약, 특정 허브나 포트에서 발생한다면 해당 허브나, 포트를 제거(Off) 시키고 테스트 해보세요
저도 약 10년전에 그런 구성으로 운영했지만 NT기반 방화벽(라우터)으로 사용시 트래픽 처리엔 문제가 없었습니다
요즘 나오는 허브는 기존처럼 더미 허브가 아닌 전부 스위칭 허브라고 하더군요...
클라이언트용 허브가 3COM 또는 넷기어 허브로 대부분 구성되어 있는걸 확인했는데 가장 오래된 허브가 2006년도 구입품이니 더미 허브는 없다고 생각합니다.
차이점이라면 방화벽 하단의 스위치는 업링크 포트가 있는 제품이고 서버용이나 클라이언트용은 업링크 포트가 따로 없는 24포트 또는 8포트 등의 제품입니다.
그리고 특정 허브에서 발생하는 것은 아니고...드랍이나 지연이 일어나면 사내의 모든 컴퓨터 및 서버에서 발생합니다.
그래서 대역간 트래픽을 중개해주는 방화벽이 의심스러운데...문제는 뭐가 원인인지 찾을 방법이 딱히 없다는겁니다.
방화벽에서 세션 초기화를 하면 거의 대부분 정상으로 돌아오니 분명 이 부분과 관련이 있는데...
방화벽을 초기화 하면 정상으로 된다는것을 봤을때, 방화벽 성능적 요인인것 같은데요.
현재의 방화벽 말고 다른 방화벽으로 테스트를 해보거나 Linux, Unix등 으로 만든 PC 방화벽을 한번 테스트 해보세요.
iptable, pf 등 PC를 활용하여 방화벽을 만들어서 테스트 해보시는것도 한 방법 이겠네요.
만든 방화벽에서는 문제가 없다면, 방화벽의 성능 문제 입니다.