넷스케일러 운영 중인 상태에서 현재 설정된 MIP 또는 SNIP에 대한 사용현황을 확인하는 쉬운 방법이 있다.
넷스케일러 CLI로 접속 후 SHELL MODE로 변경한 다음 아래의 명령어를 사용하면 현재의 MIP 또는 SNIP별로 사용 현황 및 가능한 여유를 확인 가능하다.
(CLI)
> SHELL
# nsapimgr -d mappedip
실제로 위 명령어를 사용하면 아래와 같은 결과화면을 확인할 수 있다.
09. 12. 11.
09. 11. 17.
넷스케일러에서의 사용자 IP 삽입
넷스케일러를 운영 중인 사이트에서 한번씩 아래와 같은 경우가 존재할 수 있다.
이미 내부의 목적에 의해 x-forwarded-for 또는 Client-IP를 사용하는 경우에 넷스케일러에서도 동일하게 사용자의 요청 헤더에 x-forwarded-for 또는 Client-IP를 사용할 경우 기존의 헤더 설정 값에 넷스케일러의 설정 값이 추가(ADD)되어 사용자의 IP가 두개가 기록되는 현상이 발생한다.
이럴 경우 다른 함수를 사용할 수도 있으나 그럴 상황이 허락되지 않을 경우 넷스케일러의 Rewrite 기능을 통해서 해결할 수 있는 방법이 있다. 내용은 기존에 이미 넷스케일러에서 사용하는 헤더 값과 동일한 값을 사용할 경우 기존 헤더 값을 지우고 넷스케일러의 해더 값을 삽입하는 방법이다.
add rewrite action del_x_forwarded_for delete_http_header x-forwarded-for
add rewrite action del_client_ip delete_http_header client-ip
add rewrite policy check_x_forwarded_for_policy 'HTTP.REQ.HEADER("x-forwarded-for").EXISTS' del_x_forwarded_for
add rewrite policy check_client_ip_policy 'HTTP.REQ.HEADER("client-ip").EXISTS' del_client_ip
add rewrite action insert_ns_client_header insert_http_header NS-Client 'CLIENT.IP.SRC'
add rewrite policy insert_ns_client_policy 'HTTP.REQ.HEADER("x-forwarded-for").EXISTS.NOT HTTP.REQ.HEADER("client-ip").EXISTS.NOT' insert_ns_client_header
bind rewrite global check_x_forwarded_for_policy 100 200
bind rewrite global check_client_ip_policy 200 300
bind rewrite global insert_ns_client_policy 300 END
위 설정은 global 정책으로 binding하였지만 경우에 따라서는 특정 virtual server에 정책을 binding하여 사용할 수 있다.
위 rewrite 설정은 로컬 랩에 구성된 넷스케일러 version 9.1 build 97.3 cl에서 확인결과 정상적으로 동작하였고 내부의 서버에서도 access_log 파일에 실제 사용자의 IP가 기록되었다. service의 IP insert 옵션을 사용하지 않도서도 사용자의 실제 IP를 입력하는 방법이기도 하다.
이미 내부의 목적에 의해 x-forwarded-for 또는 Client-IP를 사용하는 경우에 넷스케일러에서도 동일하게 사용자의 요청 헤더에 x-forwarded-for 또는 Client-IP를 사용할 경우 기존의 헤더 설정 값에 넷스케일러의 설정 값이 추가(ADD)되어 사용자의 IP가 두개가 기록되는 현상이 발생한다.
이럴 경우 다른 함수를 사용할 수도 있으나 그럴 상황이 허락되지 않을 경우 넷스케일러의 Rewrite 기능을 통해서 해결할 수 있는 방법이 있다. 내용은 기존에 이미 넷스케일러에서 사용하는 헤더 값과 동일한 값을 사용할 경우 기존 헤더 값을 지우고 넷스케일러의 해더 값을 삽입하는 방법이다.
add rewrite action del_x_forwarded_for delete_http_header x-forwarded-for
add rewrite action del_client_ip delete_http_header client-ip
add rewrite policy check_x_forwarded_for_policy 'HTTP.REQ.HEADER("x-forwarded-for").EXISTS' del_x_forwarded_for
add rewrite policy check_client_ip_policy 'HTTP.REQ.HEADER("client-ip").EXISTS' del_client_ip
add rewrite action insert_ns_client_header insert_http_header NS-Client 'CLIENT.IP.SRC'
add rewrite policy insert_ns_client_policy 'HTTP.REQ.HEADER("x-forwarded-for").EXISTS.NOT HTTP.REQ.HEADER("client-ip").EXISTS.NOT' insert_ns_client_header
bind rewrite global check_x_forwarded_for_policy 100 200
bind rewrite global check_client_ip_policy 200 300
bind rewrite global insert_ns_client_policy 300 END
위 설정은 global 정책으로 binding하였지만 경우에 따라서는 특정 virtual server에 정책을 binding하여 사용할 수 있다.
위 rewrite 설정은 로컬 랩에 구성된 넷스케일러 version 9.1 build 97.3 cl에서 확인결과 정상적으로 동작하였고 내부의 서버에서도 access_log 파일에 실제 사용자의 IP가 기록되었다. service의 IP insert 옵션을 사용하지 않도서도 사용자의 실제 IP를 입력하는 방법이기도 하다.
09. 7. 10.
CC-Attack의 필드 설명
정확한 출처는 기억이 나질 않지만 근래 많이 발생하는 HTTP Flooding 공격 유형의 하나로 CC-Attack이라는 공격이 있다.
이 CC-Attack이라는 공격 유형은 요청 시 Cache-Control 설정을 User-Agent 해더 필드에 첨부하여 서버의 부하를 발생시키는 특성을 가지고 있다. CC-Attack의 특성인 Cache-Control 설정 내용은 아래와 같다.
Cache-Control: no-store, must-revalidate
이 CC-Attack이라는 공격 유형은 요청 시 Cache-Control 설정을 User-Agent 해더 필드에 첨부하여 서버의 부하를 발생시키는 특성을 가지고 있다. CC-Attack의 특성인 Cache-Control 설정 내용은 아래와 같다.
Cache-Control: no-store, must-revalidate
- 캐시 저장 금지(no-store)
no-store 지시자의 목적은 부주의하게 민감한 정보를 백업테이프와 같은 곳에 보유하거나 배포하는 것을 방지하는 것입니다. no-store 지시자는 요구/응답 모두에 발송할 수 있습니다. 요구에 포함하여 발송하게 되면 캐시는 요구의 어떤 부분 또는 이 요구에 대한 어떠한 응답도 캐시해서는 안됩니다. 응답에 발송하게 되면 캐시는 이 응답의 어떤 부분 또는 응답을 이끌어 낸 요구를 저장해서는 안됩니다. 이 지시자는 비공유 및 공유 캐시에 모두 적용됩니다. - 캐시의 재검증(must-revalidate)
규약은 원서버가 계속되는 캐시 사용에 대한 캐시 엔트리 검증을 요구할 수 있는 메커니즘을 포함하고 있습니다. must-revalidate 지시자가 캐시가 수신한 응답에 포함되어 있고 캐시가 계속되는 요구에 응답하기에는 낡아진 이후에 캐시는 먼저 원서버에 이를 재검증하기 전에는 엔트리를 사용해서는 안 됩니다. must-revalidate 지시자는 특정 규약 기능의 안정된 운영을 위해서 필요합니다. 어떠한 경우이든 HTTP/1.1 캐시는 must-revalidate 지시자를 반드시 따라야 합니다.
좋은 글을 올려주신 분께 감사드리며, 출처가 확인되면 등록하겠습니다.
09. 6. 26.
Linux GDM problem(about unable authenticate messages)
어플리케이션 테스트를 위해 리눅스 시스템을 활용할 일이 많은 환경에서 가끔 새롭게 시스템을 설치하고 업데이트 한 이후 아래와 같은 문제가 발생할 수 있다.
(이 상황은 Fedora Core 10 버젼 설치 후 발생한 문제 임)
root 사용자로 GUI 화면에서 로그인을 시도하면 "Unable Authenticate users"라는 메세지가 뜨면서 로그인이 되지 않는 문제가 발생한다. 이는 보안상의 이유로 root 사용자의 로그인을 차단한 정책 때문이며, 아래와 같은 방법으로 문제를 해결할 수 있다.
(이 상황은 Fedora Core 10 버젼 설치 후 발생한 문제 임)
root 사용자로 GUI 화면에서 로그인을 시도하면 "Unable Authenticate users"라는 메세지가 뜨면서 로그인이 되지 않는 문제가 발생한다. 이는 보안상의 이유로 root 사용자의 로그인을 차단한 정책 때문이며, 아래와 같은 방법으로 문제를 해결할 수 있다.
- GUI에서 CLI 환경으로 변경한 후 root 사용자로 로그인
일반적으로 "Ctrl+Shift+F2" 키를 누르면 GUI기반에서 CLI 기반으로 변경되며, root 사용자로 로그인할 수 있다. - 로그인 후 아래의 경로의 파일을 수정
/etc/pam.d/gdm
(만약을 위해 gdm 파일을 백업한 후 수정 하는 것이 안정적인 방법이다.)
cp -aR /etc/pam.d/gdm /etc/pam.d/gdm.old
그리고 gdm 파일을 vi 편집기로 열어서 아래의 라인을 주석처리 한다.
# auth required pam_succeed_if.so user != root quiet - 수정을 다 하였으면 다시 GUI 모드로 변경 후 root로 로그인할 수 있다.
일반적으로 "Ctrl+Shitf+F7" 키를 누르면 CLI에서 GUI 모드로 변경할 수 있다.
이 방법은 root 사용자 로그인 문제 뿐만 아니라 다른 사용자의 문제점을 해결하는 방법으로도 유용하게 사용할 수 있는 방법이니 꼭! 숙지하고 있으면 좋은 것 같다.
09. 6. 18.
넷스케일러 TCPDUMP 사용법
넷스케일러의 기능 중에 현재 트래픽을 TCPDUMP 유틸을 통해 Packet Capture 기능을 제공하는데, NSTRACE 유틸을 사용하지 않고서도 패킷을 cap 또는 pcap 형식으로 Capture할 수 있다.
사용법 : nstcpdump.sh -w /var/nstrace/trace1.pcap -i 1/1 - i 1/2
원래 TCPDUMP 유틸은 실시간으로 트래픽을 확인하는 과정에 많이 사용되지만, 확인하는 트래픽을 cap 또는 pcap 형식으로 저장할 때 위 명령어를 사용하면 유용하게 Capture할 수 있다.
다른 nstrace.sh 또는 nstcpdump.sh 유틸 명령어에 대해서는 다른 메뉴얼을 확인하시기 바랍니다.
사용법 : nstcpdump.sh -w /var/nstrace/trace1.pcap -i 1/1 - i 1/2
원래 TCPDUMP 유틸은 실시간으로 트래픽을 확인하는 과정에 많이 사용되지만, 확인하는 트래픽을 cap 또는 pcap 형식으로 저장할 때 위 명령어를 사용하면 유용하게 Capture할 수 있다.
다른 nstrace.sh 또는 nstcpdump.sh 유틸 명령어에 대해서는 다른 메뉴얼을 확인하시기 바랍니다.
소규모 엔터프라이즈의 수요 해결을 위한 MPX 제품 출시!
5월 21일 인터롭에서 시트릭스는 500 메가바이트(Mbps)에서 3 기가바이트(Gbps)에 걸친 7개의 레이어와 함께 최고의 가격-성능을 가진 세 가지의 새로운 MPX 어플라이언스를 소개했습니다.
새로운 넷스케일러 MPX 7500과 MPX 9500 어플라이언스는 중소 엔터프라이즈에 현저한 향상을 가져다 주었으며 새로운 MPX 5000은 처음으로 소규모 엔터프라이즈에 진보한 넷스케일러 MPX 아키텍처를 제공했습니다.
새로운 모델은 최고급 넷스케일러 MPX 솔루션에서 이용할 수 있는 것과 동일한 풍성한 특징을 제공합니다. 하지만 소규모 업체에 걸맞게 가격 면에서 훨씬 경제적입니다.본 디자인은 향상된 멀티코어 MPX 아키텍처를 이용해 애플리케이션 가속화, 서버의 이용 가능성 그리고 통합된 애플리케이션 방화벽 및 SSL VPN 보안을 위해 완벽한 콘커런스 기능(Concurrency feature)를 제공하도록 고안되었습니다.
이 모든 기술은 저 전력 및 1U의 공간 효율적 디자인을 채택 함으로써 친환경적인 컴퓨팅을 지원합니다. 소규모 엔터프라이즈의 경우에는 대부분의 기능을 동시에 사용하고 경쟁적으로 제공하기 때문에 모듈 사용에 심각한 제한이 있었습니다.
MPX 5000은 지금 바로 사용 가능하며 유닛 당 12,000달러이고 전 세계적으로 수만 건의 젠앱 구현 해결했습니다. MPX 7500 주문도 곧 가능합니다.8월부터 MPX 9500이 이용 가능 하다는 소식과 함께, 6월 8일부터 새로운 모델을 세 가지 소프트웨어 에디션과 함께 이용할 수 있음을 알려드립니다.
참고 : 새로운 제품의 대략적인 Spec은 아래와 같습니다.
새로운 넷스케일러 MPX 7500과 MPX 9500 어플라이언스는 중소 엔터프라이즈에 현저한 향상을 가져다 주었으며 새로운 MPX 5000은 처음으로 소규모 엔터프라이즈에 진보한 넷스케일러 MPX 아키텍처를 제공했습니다.
새로운 모델은 최고급 넷스케일러 MPX 솔루션에서 이용할 수 있는 것과 동일한 풍성한 특징을 제공합니다. 하지만 소규모 업체에 걸맞게 가격 면에서 훨씬 경제적입니다.본 디자인은 향상된 멀티코어 MPX 아키텍처를 이용해 애플리케이션 가속화, 서버의 이용 가능성 그리고 통합된 애플리케이션 방화벽 및 SSL VPN 보안을 위해 완벽한 콘커런스 기능(Concurrency feature)를 제공하도록 고안되었습니다.
이 모든 기술은 저 전력 및 1U의 공간 효율적 디자인을 채택 함으로써 친환경적인 컴퓨팅을 지원합니다. 소규모 엔터프라이즈의 경우에는 대부분의 기능을 동시에 사용하고 경쟁적으로 제공하기 때문에 모듈 사용에 심각한 제한이 있었습니다.
MPX 5000은 지금 바로 사용 가능하며 유닛 당 12,000달러이고 전 세계적으로 수만 건의 젠앱 구현 해결했습니다. MPX 7500 주문도 곧 가능합니다.8월부터 MPX 9500이 이용 가능 하다는 소식과 함께, 6월 8일부터 새로운 모델을 세 가지 소프트웨어 에디션과 함께 이용할 수 있음을 알려드립니다.
참고 : 새로운 제품의 대략적인 Spec은 아래와 같습니다.
- MPX5500( DualCore, 4GRAM, 4x10/100/1000 base-T, 500Mbps throughtput)
- MPX7500( QuadCore, 8GRAM, 8x10/100/1000 base-T, 1Gbps throughput)
- MPX9500( QuadCore, 8GRAM, 8x10/100/1000 base-T, 3Gbps throughput)
자세한 Spec 내용은 아래의 링크를 통해 확인이 가능합니다.
접속한 IP 주소의 위치추적
네트워크 운영 또는 관리를 하다보면 많이 찾게되는 것중의 하나가 자신의 서비스 시스템에 접근할 또는 공격으로 추정될 때 해당 IP가 어느 나라인지 어디 지역인지를 궁금해한다.
이때 아래의 사이트를 이용하면 쉽게 찾을 수 있다.
이때 아래의 사이트를 이용하면 쉽게 찾을 수 있다.
- MaxMind의 GeoIP Test Demo
http://www.maxmind.com/app/loopup_city?type=geolite - IPligence의 Google Map Demo
http://www.ipligence.com/geolocation/?lang=en
IPlignece의 Goole Map Demo는 친정하게 지도까지 보여주어서 조금 더 쉽게 찾을 수도 있다.
아파치 ETag를 이용한 정적파일 최적화
ETag는 HTTP 1.1에서 새롭게 나온 HEADER Directive 입니다. 이는 브라우져의 Cache에 저장된 파일과 웹서버의 파일이 서로 일치하는지를 식별하기 위한 방법 중에 하나로 사용 됩니다.
일반적으로 ETag는 파일을 구분하기 위해 inode 값을 사용하는데 만약 여러 대의 웹서버를 운영하는 환경에서는 접근하는 서버에 따라 inode 값이 다르기 때문에 ETag 값도 달라집니다.
브라우져는 Cache된 파일의 갱신 여부를 확인하기 위해서 수정일자와 ETag 값을 사용하는데 우선 순위는 ETag 값을 먼저 비교한 후 수정일자를 이후에 확인하는 과정을 거친다. 만약 여러 대의 웹서버를 사용하는 환경에서는 ETag 값이 다르게 인식되어 다른 서버에 접근할 경우 기존의 Cache를 지우고 갱신하게되어 Cache의 효율성이 많이 떨어지게 된다.
Cache의 효율성이 떨어지면 사용자의 입장에서는 모든 Contents를 새롭게 갱신하는 과정을 거치게 됨으로 응답 속도의 저하를 초래할 수도 있다.
그래서 보통 운영 환경에서는 ETag 값을 제거하거나 inode 값을 빼는 방식을 사용하는 일반적으로는 ETag 값을 제거하는 방식을 사용한다.
제거하는 방법은 아래와 같다. 이때 주의할 점은 Apache의 Option에서 Indexes 설정이 추가되면 ETag 설정이 지워지지 않기 때문에 반드시 Indexes 속성을 함께 제거해 주어야 한다.
...
FileETag None
...
#
# Options FollowSymLinks MultiViews # Indexes 삭제해야 함
# AllowOvrride None
# Order deny, allow
# DirectoryIndex index.php
#
# Expire 설정
#
# ExpiresActive On
# ExpireDefault "access plus 1 years"
#
#Contents Compression 설정
#
# AddOutPutFilterByType DEFLATE text/html text/css application/x-javascript
#
...
Apache 웹서버의 기본 ETag 값은 inode, mtime, size 이며, 한대의 웹서버로 운영할 경우 문제가 발생하지 않지만, L4 등의 로드밸런스를 통해 서비스할 경우 각각의 서버별로 inode 값이 다르기 때문에 다른 웹서버로 요청할 때는 기존의 cache 정보가 다른기 때문에 서버에 재 요청을 하게 된다.
참조 : http://httpd.apache.org/doc/2.0/mod/core.html#fileetag
일반적으로 ETag는 파일을 구분하기 위해 inode 값을 사용하는데 만약 여러 대의 웹서버를 운영하는 환경에서는 접근하는 서버에 따라 inode 값이 다르기 때문에 ETag 값도 달라집니다.
브라우져는 Cache된 파일의 갱신 여부를 확인하기 위해서 수정일자와 ETag 값을 사용하는데 우선 순위는 ETag 값을 먼저 비교한 후 수정일자를 이후에 확인하는 과정을 거친다. 만약 여러 대의 웹서버를 사용하는 환경에서는 ETag 값이 다르게 인식되어 다른 서버에 접근할 경우 기존의 Cache를 지우고 갱신하게되어 Cache의 효율성이 많이 떨어지게 된다.
Cache의 효율성이 떨어지면 사용자의 입장에서는 모든 Contents를 새롭게 갱신하는 과정을 거치게 됨으로 응답 속도의 저하를 초래할 수도 있다.
그래서 보통 운영 환경에서는 ETag 값을 제거하거나 inode 값을 빼는 방식을 사용하는 일반적으로는 ETag 값을 제거하는 방식을 사용한다.
제거하는 방법은 아래와 같다. 이때 주의할 점은 Apache의 Option에서 Indexes 설정이 추가되면 ETag 설정이 지워지지 않기 때문에 반드시 Indexes 속성을 함께 제거해 주어야 한다.
...
FileETag None
...
#
# Options FollowSymLinks MultiViews # Indexes 삭제해야 함
# AllowOvrride None
# Order deny, allow
# DirectoryIndex index.php
#
# Expire 설정
#
# ExpiresActive On
# ExpireDefault "access plus 1 years"
#
#Contents Compression 설정
#
# AddOutPutFilterByType DEFLATE text/html text/css application/x-javascript
#
...
Apache 웹서버의 기본 ETag 값은 inode, mtime, size 이며, 한대의 웹서버로 운영할 경우 문제가 발생하지 않지만, L4 등의 로드밸런스를 통해 서비스할 경우 각각의 서버별로 inode 값이 다르기 때문에 다른 웹서버로 요청할 때는 기존의 cache 정보가 다른기 때문에 서버에 재 요청을 하게 된다.
참조 : http://httpd.apache.org/doc/2.0/mod/core.html#fileetag
09. 6. 15.
Connection Limitation 정보
L4장비(C社)는 일반적인 L4 장비와 다르게 TCP Proxy로 동작한다. 즉, L4장비를 기준으로 Client Connection과 Server Connection이 각각 독립적으로 관리된다.
사용자의 Connection 요청을 L4 장비가 받아서 3 Hand Shaking을 통해 Established Connection을 생성하고, 이렇게 생성된 Connection을 통해 Request가 전송될 때 L4 장비가 Server와의 3 Hand Shaking을 통해 Established Connection을 생성하여 해당 Request를 처리한다.
이렇게 TCP Proxy처럼 동작하는 L4 장비의 경우 L4 레이어에서 자신의 IP가 아닌 사용자가 최초 요청한 IP를 그대로 서버에게 전달하거나 자신의 IP(Proxy IP)를 사용하되 L7 레이어 HEADER 정보에 실제 사용자의 IP를 삽입하여 전달하는 방식으로 사용자의 IP를 전달하는데, 여기서 L4 레이어에서 사용자의 IP를 직접 넘기는 구성으로 설계할 경우 Server Connection의 Limitation에 존재한다.
이는 실제 사용자의 IP에 관리 Port를 붙여서 실제 사용자의 IP를 관리하기 때문에 Port정보로 사용할 수 있는 대략 65,000개까지 밖에 사용하지 못한다. 즉, Server Connection이 대략 65,000까지만 허용할 수 있다.
하지만 대용량 트래픽을 처리하는 환경에서 Server Connection이 65,000개를 넘어설 수 있는데 이때는 아래의 Hidden 명령어를 통해 해당 제약 사항을 제거 할 수 있다.
명령어 : nsapimgr -ys usip_noreuse_nolimit=0
구체적인 이유에 대해서는 조금 더 확인 후 댓글로 첨부를 할 예정이다.
사용자의 Connection 요청을 L4 장비가 받아서 3 Hand Shaking을 통해 Established Connection을 생성하고, 이렇게 생성된 Connection을 통해 Request가 전송될 때 L4 장비가 Server와의 3 Hand Shaking을 통해 Established Connection을 생성하여 해당 Request를 처리한다.
이렇게 TCP Proxy처럼 동작하는 L4 장비의 경우 L4 레이어에서 자신의 IP가 아닌 사용자가 최초 요청한 IP를 그대로 서버에게 전달하거나 자신의 IP(Proxy IP)를 사용하되 L7 레이어 HEADER 정보에 실제 사용자의 IP를 삽입하여 전달하는 방식으로 사용자의 IP를 전달하는데, 여기서 L4 레이어에서 사용자의 IP를 직접 넘기는 구성으로 설계할 경우 Server Connection의 Limitation에 존재한다.
이는 실제 사용자의 IP에 관리 Port를 붙여서 실제 사용자의 IP를 관리하기 때문에 Port정보로 사용할 수 있는 대략 65,000개까지 밖에 사용하지 못한다. 즉, Server Connection이 대략 65,000까지만 허용할 수 있다.
하지만 대용량 트래픽을 처리하는 환경에서 Server Connection이 65,000개를 넘어설 수 있는데 이때는 아래의 Hidden 명령어를 통해 해당 제약 사항을 제거 할 수 있다.
명령어 : nsapimgr -ys usip_noreuse_nolimit=0
구체적인 이유에 대해서는 조금 더 확인 후 댓글로 첨부를 할 예정이다.
L4 DSR 구성 시 ARP Issue에 대해서
일반적으로 L4 장비를 통해 내부 서버팜의 서버에 대해 균등하게 로드를 분배시키는데, 이전 게시한 게시물(DSR 구성)으로 구성하는 경우는 응답 트래픽이 L4 장비가 감당하기 어려울 경우 응답 트래픽이 L4를 경유하지 않도록 구성할 수 있다.
이렇게 동영상 또는 멀티미디어 데이터에 대한 DSR 구성 시 아래와 같은 이슈가 발생할 수 있다.
L2 Switch에서 L4 장비에 설정된 VIP의 MAC이 Announce되는게 아니라 Real Server의 Loopback에 설정된 VIP가 Announce되어 사용자의 요청 트래픽이 L4 장비의 VIP를 경유하지 않고 다이렉트로 Real Server로 전달되는 현상이 발생할 수 있다.(L2 Switch는 L2레벨 Switch)
이럴 경우 Real Server의 네트워크 설정을 약간 변경해야 하는데 아래와 같이 설정을 할 수 있다.(리눅스의 경우)
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
또는
만약 리눅스 시스템에 /etc/sysctl.conf 파일이 있다면 해당 파일을 열어서 아래와 같이 정보를 추가하거나 수정한다.
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
해당 설정 후 시스템을 재시작하면 eth0 인터페이스(현재 L2 스위치에 연결된)를 통해 Loopback VIP 정보가 Announce되거나 ARP 요청에 따른 Reply를 처리하지 않기 때문에 MAC이 중복되어 발생되는 ARP Issue를 해결할 수 있다.
참고 :
http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP
이렇게 동영상 또는 멀티미디어 데이터에 대한 DSR 구성 시 아래와 같은 이슈가 발생할 수 있다.
L2 Switch에서 L4 장비에 설정된 VIP의 MAC이 Announce되는게 아니라 Real Server의 Loopback에 설정된 VIP가 Announce되어 사용자의 요청 트래픽이 L4 장비의 VIP를 경유하지 않고 다이렉트로 Real Server로 전달되는 현상이 발생할 수 있다.(L2 Switch는 L2레벨 Switch)
이럴 경우 Real Server의 네트워크 설정을 약간 변경해야 하는데 아래와 같이 설정을 할 수 있다.(리눅스의 경우)
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
또는
만약 리눅스 시스템에 /etc/sysctl.conf 파일이 있다면 해당 파일을 열어서 아래와 같이 정보를 추가하거나 수정한다.
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
해당 설정 후 시스템을 재시작하면 eth0 인터페이스(현재 L2 스위치에 연결된)를 통해 Loopback VIP 정보가 Announce되거나 ARP 요청에 따른 Reply를 처리하지 않기 때문에 MAC이 중복되어 발생되는 ARP Issue를 해결할 수 있다.
참고 :
http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP
09. 6. 10.
넷스케일러 Troubleshooting 가이드 중 CPU 점유률 관련 TroubleShooting이 필요할 경우 이전에 언급된 nsprofmon이라는 CPU 프로파일링 스크립트(시트릭스에서 OS 버젼별로 제공)가 없을 경우 사용할 수 있는 방법에 대해서 정리한다.
명령어 : nsconmsg
사용법 : nsconmsg -K [해당날짜의 newnslog 파일] -s totalcount=[원하는 count정보] -g cpu_use -d current
사용예 :
명령어 : nsconmsg
사용법 : nsconmsg -K [해당날짜의 newnslog 파일] -s totalcount=[원하는 count정보] -g cpu_use -d current
사용예 :
- 특정 시간대의 newnslog 파일 중 CPU 점유률이 20%가 넘은 프로세스 정보를 확인할 경우 아래와 같이 사용함
#nsconmsg -K /var/nslog/newnslog.10 -s totalcount=200 -g cpu_use -d current - 현재 시점의 CPU 점유률이 10% 이상인 프로세스를 확인하고자 할 경우 아래와 같이 사용함.
#nsconmsg -s totalcount=100 -g cpu_use -d current
기타 유용한 TroubleShooting 가이드는 아래의 링크를 통해 다운로드 받아서 참조하시기 바랍니다. 넷스케일러 엔지니어라면 언제든지 사용하여 분석할 준비가 되어있어야 하지 않을까요??
09. 6. 8.
넷스케일러의 SIMPLE ACLs 설정 방법
넷스케일러의 SIMPLE ACLs의 설정은 아래와 같은 화면에서 간략한 정보 몇 가지만 입력하면 Block ACL을 설정할 수 있으며, 소스 IP만을 차단하는 환경에서는 유용하고 쉽게 적용할 수 있습니다.
위 그림과 같이 넷스케일러 GUI에서 Network > ACLs > Symple Acls 경로에서 Add 버튼을 클릭하면 볼 수 있으며, 자세한 내용은 아래와 같습니다.
위 그림과 같이 넷스케일러 GUI에서 Network > ACLs > Symple Acls 경로에서 Add 버튼을 클릭하면 볼 수 있으며, 자세한 내용은 아래와 같습니다.
- Name : 관리할 ACL 이름을 입력합니다.
- Action은 Block 정책만 설정이 가능합니다.
- Protocol 선택은 TCP 또는 UDP를 선택할 수 있으며, 선택하지 않을 경우 ANY가 됩니다.
- SourceIP는 필수 입력 요소로 실제 차단할 IP 주소를 입력할 수 있습니다.(범위입력 안됨)
- Destination Port 는 해당 사용자에 대한 특정 Destination Port만을 차단할 때 해당 포트 번호를 명시하면 됩니다.(범위입력 안됨)
- TTL은 해당 ACLs의 적용 시간을 설정할 수 있으며, 해당 사용자를 1시간 차단하려면 TTL 필드에 3600을 입력하시면 됩니다.(Sec단위)
그리고 SIMPLE ACLs은 Extended ACLs보다 우선순위에 있으며 아래와 같은 Diagram으로 처리가 됩니다.
잘되는 나!!
몽상이 아닌 꿈을 꾸는 사람과 어울려야 한다.
거대한 목표를 세우고 위대한 일을 이루려는 사람과 가까이하면 우리도 그렇게 된다.
우리가 잠재력을 온전히 발휘하도록 도와줄 사람을 사귀어야 한다.
- 조엘 오스틴의《잘되는 나》중에서 -
How to use CPU analysis script in the Netscaler
넷스케일러를 사용하다보면 특정 기능 또는 특정 상황에 CPU 점유률이 Peak를 치거나 CPU 점유률이 많이 올라가는 현상을 한번씩 볼 수 있는데, 이때 어떤 프로세스에 의해 CPU 점유률이 증가하는 가에 대한 분석을 할 수 있는 스크립트를 이용해서 원인 규명을 할 수 있다.
이 Script는 Case를 Open하여 본사에서 지원을 받을 수 있다.
사용 방법은 아래의 절차에 의거하여 실행하고 결과를 확인할 수 있다.
이 Script는 Case를 Open하여 본사에서 지원을 받을 수 있다.
사용 방법은 아래의 절차에 의거하여 실행하고 결과를 확인할 수 있다.
- 받은 파일의 압축을 해제
(파일을 /var/tmp 경로에 복사한 후 ns-8.1-56.7.tgz라면)
>shell
#cd /var/tmp/
#tar zxvf ns-8.1-56.7.tgz - Script 실행을 위한 메모리 Buffer를 할당
#/var/tmp/nsprofmon -ys profbuf=16k - Script를 실행
(2분 정도 실행하면 결과 화면을 볼 수 있다.)
#/var/tmp/profmon -K /var/tmp/ns-8.1-56.7 -s sort=2 -T 120 -recapture tee /var/tmp/cpu.log - 모든 Script 실행 후 메모리 Buffer를 비움(불필요한 메모리 점유를 해지)
#/var/tmp/nsprofmon -yS profbuf
(옵션의 -yS로 S를 대문자로 입력하면 Buffer 메모리를 해지 함)
실행 결과를 토대로 직접 분석을 하거나 TechSupport의 도움을 통해 직접적인 CPU 점유률에 대한 원인 분석을 진행할 수 있다.
멋지게 사는 10가지 방법
1. 힘차게 일어나라.
시작이 좋아야 끝도 좋다.
육상선수는 심판의 총소리에 모든 신경을 곤두세운다.
0.001초라도 빠르게 출발하기 위해서다.
2007년 365번의 출발 기회가 있다.
빠르냐 늦느냐가 자신의 운명을 다르게 연출한다.
시작은 빨라야 한다.
아침에는 희망과 의욕으로 힘차게 일어나라.
2. 당당하게 걸어라.
인생이란 성공을 향한 끊임없는 행진이다.
목표를 향하여 당당하게 걸어라.
당당하게 걷는 사람의 미래는 밝게 비쳐지지만,
비실거리며 걷는 사람의 앞날은 암담하기 마련이다.
값진 삶을 살려면 가슴을 펴고 당당하게 걸어라.
3. 오늘 일은 오늘로 끝내라.
성공해야겠다는 의지가 있다면 미루는 습관에서 벗어나라.
우리가 살고 있는 것은 오늘 하루뿐이다.
내일은 내일 해가 뜬 다해도 그것은 내일의 해다.
내일은 내일의 문제가 우리를 기다린다. 미루지 말라.
미루는 것은 죽음에 이르는 병이다.
4. 시간을 정해 놓고 책을 읽어라.
책 속에 길이 있다.
길이 없다고 헤매는 사람의 공통점은 책을 읽지 않는데 있다.
지혜가 가득한 책을 소화 시켜라.
하루에 30분씩 독서 시간을 만들어 보라.
바쁜 사람이라 해도 30분 시간을 내는 것은 힘든 일이 아니다.
하루에 30분씩 독서 시간을 만들어 보라.
학교에서는 점수를 더 받기 위해 공부하지만,
사회에서는 살아 남기 위해 책을 읽어야 한다.
5. 웃는 훈련을 반복하라.
최후에 웃는 자가 승리자다.
그렇다면 웃는 훈련을 쌓아야 한다.
자신을 돋보이게 하는 지름길도 웃음이다.
웃으면 복이 온다는 말은 그냥 생긴 말이 아니다.
웃다 보면 즐거워지고 즐거워지면 일이 술술 풀린다.
사람은 웃다 보면 자신도 모르게 긍정적으로 바뀐다.
웃고 웃자.그러면 웃을 일이 생겨난다.
6. 말하는 법을 배워라.
말이란 의사소통을 위해 하는 것만은 아니다.
자기가 자신에게 말을 할 수 있고,
절대자인 신과도 대화할 수 있다.
해야 할 말과 해서는 안될 말을 분간하는 방법을 깨우치자.
나의 입에서 나오는 대로 뱉는 것은 공해다.
상대방을 즐겁고 기쁘게 해주는 말 힘이 생기도록 하는
말을 연습해보자. 그것이 말 잘하는 법이다.
7. 하루 한가지씩 좋은 일을 하라.
이제 자신을 점검해 보자.
인생의 흑자와 적자를 보살피지 않으면 내일을 기약 수가 없다.
저녁에 그냥 잠자리에 들지 말라.
자신의 하루를 점검한 다음 눈을 감아라.
나날이 향상하고 발전한다.
인생에는 연장전이 없다.
그러나 살아온 발자취는 영원히 지워지지 않는다.
하루에 크건 작건 좋은 일을 하자.
그것이 자신의 삶을 빛나게 할 뿐 아니라 사람답게 사는 일이다.
좋은 일 하는 사람의 얼굴은 아름답게 빛난다.
마음에 행복이 가득 차기 때문이다.
8. 자신을 해방시켜라.
어떤 어려움이라도 마음을 열고 밀고 나가면 해결된다.
어렵다,안 된다,힘들다고 하지 말라.
굳게 닫혀진 자신의 마음을 활짝 열어보자.
마음을 열면 행복이 들어온다.
자신의 마음을 열어 놓으면 너와 내가 아니라 모두가
하나가 되어 기쁨 가득한 세상을 만들게 된다.
마음을 밝혀라. 그리고 자신을 해방시켜라.
9. 사랑을 업그레이드 시켜라.
사랑은 아무나 하는 것이 아니다.
그런데도 아무나 사랑을 한다.
말이 사랑이지 진정한 사랑이라고 할 수는 없는 일이다.
처음에 뜨거웠던 사랑도 시간이 흐름에 따라 차츰 퇴색된다.
그래서 자신의 사랑을 뜨거운 용광로처럼 업그레이드 시키는
것이 필요하다.지금의 사랑을 불살라 버리자.
그리고 새로운 사랑으로 신장 개업하라.
10. 매일매일 점검하라.
생각하는 민족만이 살아 남는다.
생각 없이 사는 것은 삶이 아니라 생존일 뿐이다.
시작이 좋아야 끝도 좋다.
육상선수는 심판의 총소리에 모든 신경을 곤두세운다.
0.001초라도 빠르게 출발하기 위해서다.
2007년 365번의 출발 기회가 있다.
빠르냐 늦느냐가 자신의 운명을 다르게 연출한다.
시작은 빨라야 한다.
아침에는 희망과 의욕으로 힘차게 일어나라.
2. 당당하게 걸어라.
인생이란 성공을 향한 끊임없는 행진이다.
목표를 향하여 당당하게 걸어라.
당당하게 걷는 사람의 미래는 밝게 비쳐지지만,
비실거리며 걷는 사람의 앞날은 암담하기 마련이다.
값진 삶을 살려면 가슴을 펴고 당당하게 걸어라.
3. 오늘 일은 오늘로 끝내라.
성공해야겠다는 의지가 있다면 미루는 습관에서 벗어나라.
우리가 살고 있는 것은 오늘 하루뿐이다.
내일은 내일 해가 뜬 다해도 그것은 내일의 해다.
내일은 내일의 문제가 우리를 기다린다. 미루지 말라.
미루는 것은 죽음에 이르는 병이다.
4. 시간을 정해 놓고 책을 읽어라.
책 속에 길이 있다.
길이 없다고 헤매는 사람의 공통점은 책을 읽지 않는데 있다.
지혜가 가득한 책을 소화 시켜라.
하루에 30분씩 독서 시간을 만들어 보라.
바쁜 사람이라 해도 30분 시간을 내는 것은 힘든 일이 아니다.
하루에 30분씩 독서 시간을 만들어 보라.
학교에서는 점수를 더 받기 위해 공부하지만,
사회에서는 살아 남기 위해 책을 읽어야 한다.
5. 웃는 훈련을 반복하라.
최후에 웃는 자가 승리자다.
그렇다면 웃는 훈련을 쌓아야 한다.
자신을 돋보이게 하는 지름길도 웃음이다.
웃으면 복이 온다는 말은 그냥 생긴 말이 아니다.
웃다 보면 즐거워지고 즐거워지면 일이 술술 풀린다.
사람은 웃다 보면 자신도 모르게 긍정적으로 바뀐다.
웃고 웃자.그러면 웃을 일이 생겨난다.
6. 말하는 법을 배워라.
말이란 의사소통을 위해 하는 것만은 아니다.
자기가 자신에게 말을 할 수 있고,
절대자인 신과도 대화할 수 있다.
해야 할 말과 해서는 안될 말을 분간하는 방법을 깨우치자.
나의 입에서 나오는 대로 뱉는 것은 공해다.
상대방을 즐겁고 기쁘게 해주는 말 힘이 생기도록 하는
말을 연습해보자. 그것이 말 잘하는 법이다.
7. 하루 한가지씩 좋은 일을 하라.
이제 자신을 점검해 보자.
인생의 흑자와 적자를 보살피지 않으면 내일을 기약 수가 없다.
저녁에 그냥 잠자리에 들지 말라.
자신의 하루를 점검한 다음 눈을 감아라.
나날이 향상하고 발전한다.
인생에는 연장전이 없다.
그러나 살아온 발자취는 영원히 지워지지 않는다.
하루에 크건 작건 좋은 일을 하자.
그것이 자신의 삶을 빛나게 할 뿐 아니라 사람답게 사는 일이다.
좋은 일 하는 사람의 얼굴은 아름답게 빛난다.
마음에 행복이 가득 차기 때문이다.
8. 자신을 해방시켜라.
어떤 어려움이라도 마음을 열고 밀고 나가면 해결된다.
어렵다,안 된다,힘들다고 하지 말라.
굳게 닫혀진 자신의 마음을 활짝 열어보자.
마음을 열면 행복이 들어온다.
자신의 마음을 열어 놓으면 너와 내가 아니라 모두가
하나가 되어 기쁨 가득한 세상을 만들게 된다.
마음을 밝혀라. 그리고 자신을 해방시켜라.
9. 사랑을 업그레이드 시켜라.
사랑은 아무나 하는 것이 아니다.
그런데도 아무나 사랑을 한다.
말이 사랑이지 진정한 사랑이라고 할 수는 없는 일이다.
처음에 뜨거웠던 사랑도 시간이 흐름에 따라 차츰 퇴색된다.
그래서 자신의 사랑을 뜨거운 용광로처럼 업그레이드 시키는
것이 필요하다.지금의 사랑을 불살라 버리자.
그리고 새로운 사랑으로 신장 개업하라.
10. 매일매일 점검하라.
생각하는 민족만이 살아 남는다.
생각 없이 사는 것은 삶이 아니라 생존일 뿐이다.
09. 6. 2.
linux에서의 interface bonding 설정 방법
서비스를 위한 웹서버의 구성 시 서비스의 안정성 및 지속적인 서비스의 유지 목적으로 웹서버의 인터페이스에 대해서 네트워크 이중화 구성을 한다.
이렇게 네트워크 이중화 구성 시 서버의 인터페이스는 2개 이상(최소 2개)이 필요하며, 유닉스 기반의 시스템에서는 bonding이라는 명칭을 사용하고, 윈도우 기반의 시스템에서는 teamming이라 명칭으로 사용하고 있다.
여기에서는 많이 사용하는 리눅스 기반의 시스템에서 bonding 설정을 하는 방법을 정리하고자 한다.
이렇게 네트워크 이중화 구성 시 서버의 인터페이스는 2개 이상(최소 2개)이 필요하며, 유닉스 기반의 시스템에서는 bonding이라는 명칭을 사용하고, 윈도우 기반의 시스템에서는 teamming이라 명칭으로 사용하고 있다.
여기에서는 많이 사용하는 리눅스 기반의 시스템에서 bonding 설정을 하는 방법을 정리하고자 한다.
- 우선 /etc/sysconfig/network-scripts/ifcfg-eth0(기본 인터페이스를 사용)를 사용하여 동일한 위치에 ifcfg-bond0를 생성
#cd/etc/sysconfig/network-scripts/
#cp ifcfg-eth0 ifcfg-bond0 - VI편집기 등을 이용하여 ifcfg-bond0의 설정 값을 아래와 같이 변경한다.
DEVICE=bond0
BOOTPROTO=static
IPADDR=111.111.111.111 (사용할 대표 IP 주소)
NETMASK=255.255.255.0
ONBOOT=yes - 다음 bond0에 연결할 인터페이스를 아래와 같이 수정한다.(만약 eth0 및 eth1일 경우 eth0를 master로 eth1을 slave로 설정한다고 할 경우)
ifcfg-eth0 내용 :
DEVICE=eth0
MASTER=bond0
SLAVE=yes
BOOTPROTO=no
ONBOOT=yes
TYPE=Ethernet
ifcfg-eth1 내용 :
DEVICE=eth1
MASTER=bond0
SLAVE=yes
BOOTPROTO=no
ONBOOT=yes
TYPE=Ethernet - 마지막 단계로 모듈(modprobe.conf)의 설정을 수정한다.
alias bond0 bonding
options bond0 mode=1 miimon=100 primary=eth0
여기서 주의할 내용은 만약 Linux Kernel 버젼이 2.4 이하 일 경우는 /etc/modules.conf 파일에 해당 내용을 수정해야 하며, Kernel 버젼이 2.6이상일 경우 /etc/modprobe.conf 파일을 수정해야 한다.
여기에서는 단순히 리눅스 기반의 시스템에서 간단하게 구성하는 방법을 정리하기 위함이며, 보다 자세한 bonding 설정은 리눅스 메뉴얼을 참고하시기 바람!!
09. 6. 1.
웹서버의 DSR(Direct Server Return)을 위한 Interface 설정
하드웨어 또는 소프트웨어(LVS)기반의 L4 장비를 통해 내부 웹서버의 DSR(Direct Server Return)을 구성하는 경우가 현업에서 종종 볼 수 있다.
이렇게 DSR로 웹서비스를 구성하는 이유는 다양하지만 크게는 L4 장비의 Transaction 부하 감소이거나 Inbound Traffice에 비해 Outbound Traffic의 양이 현저하게 많을 경우 Outbound Traffic이 L4 장비를 경유하지 않고 직접 사용자에게 전송할 때 사용한다.
기본적인 L4 스위치 장비에서는 DSR을 아래와 같이 구성을 한다.
이렇게 구성할 때 주의할 점은 L4 장비와 실제 웹서버는 L2 통신이 가능한 네트워크 환경이어야 한다. 그래서 L2 스위치를 사용하여 구성하는게 일반적이다.(요청한 IP가 변경되지 않도록 함이 목적)
그리고 윈도우 또는 유닉스 기반의 웹서버를 많이 사용하기 때문에 해당 서버에 VIP와 동일한 IP로 Loopback Interface를 설정해야 정상적인 통신이 가능하다. 아래는 리눅스 시스템에서 Loopback Interface를 설정하는 한 예이다.(윈도우 기반은 제어판에서 Loopback 인터페이스를 추가 생성하면 구성이 가능 함)
Loopback Interface 설정(Fedora Core 기반의 리눅스)
원래 구성된 Lo 인터페이스에 새로운 Alias를 할당하여 간단하게 구성할 수 있다.
# ifconfig Lo:0 192.168.100.1 netmask 255.255.255.255 up
(관련 설정은 리눅스 man페이지나 해당 메뉴얼을 참고하시기 바람)
09. 5. 25.
넷스케일러 Compression 적용 방법
Compression 정책 적용 방법 :
- 서비스 레벨의 정책 적용
A. Compression 정책의 Global binding 적용
B. 적용 대상 service 또는 servicegroup에 대한 CMP 옵션 적용
(GUI에서 server 선택 후 open > advanced > compression 체크하거나 CLI에서 해당 서비스에 대한 set service 서비스네임 –cmp YES로 적용)
C. Compression 기능 적용 됨 - VSERVER 레베리의 정책 적용
A. Compression 정책의 Global Binding 적용 해제
B. 적용 대상 service 또는 servicegroup에 대한 CMP 욥션 적용
C. 적용 가능한 VSERVER에 compression 정책 적용ㄷ(GUI에서 VSERVER 선택 후 open > policies > compression 정책 적용)
D. 해당 VSERVER에 대해서만 Compression 기능 적용 됨
적용 방법 또는 적용 범위의 차이일 뿐 기능이나 성능의 차이는 없다.
Compresion 설정 시 실제 Server의 중복 Compression 방지
실제 넷스케일러 시스템에서 Compression 정책을 적용 시 만약 서버에서도 동일하게 Compression을 적용되어 있다면 중복으로 Compression을 수행하여 불필요한 자원을 사용하게 된다.
이때 넷스케일러의 Rewrite 정책을 통해 사용자의 Request 해더 부분에서 Accept Enconding 부분을 제거하여 실제 사용자의 Request는 Accept Encoding 부분이 있지만 Compression 적용은 넷스케일러에서만 발생하도록 설정을 할 수 있다.
사용자의 Accept Encoding 제거 rewite 정책 샘플,
add rewrite action act_remAcceptEncoding delete_http_header Accept-Encoding
add rewrite policy pol_remAcceptEncoding TRUE act_remAcceptEncoding NOREWRITE
실제 서버의 Compression 기능의 적용 여부 확인이 어렵거나, 서버의 설정 변경 없이 넷스케일러에서 Compression 기능을 제공하기 위해서는 Rewrite 기능을 통해 쉽게 이런 문제를 해결할 수 있다.
이때 넷스케일러의 Rewrite 정책을 통해 사용자의 Request 해더 부분에서 Accept Enconding 부분을 제거하여 실제 사용자의 Request는 Accept Encoding 부분이 있지만 Compression 적용은 넷스케일러에서만 발생하도록 설정을 할 수 있다.
사용자의 Accept Encoding 제거 rewite 정책 샘플,
add rewrite action act_remAcceptEncoding delete_http_header Accept-Encoding
add rewrite policy pol_remAcceptEncoding TRUE act_remAcceptEncoding NOREWRITE
실제 서버의 Compression 기능의 적용 여부 확인이 어렵거나, 서버의 설정 변경 없이 넷스케일러에서 Compression 기능을 제공하기 위해서는 Rewrite 기능을 통해 쉽게 이런 문제를 해결할 수 있다.
넷스케일러의 정책설정과 성능관계
넷스케일러의 Policy Engine을 통해 정책을 설정할 때 CPU 성능과 밀접한 관계가 있기 때문에 상황에 따라 적절하게 정책을 설정하여 CPU 성능을 최적화할 필요성이 있다.
- Operator를 "=="을 사용할 때(equal condition)
Case Sensetive하며 wildcard(*)를 사용할 수 있고, CPU 영향을 최소화 할 수 있음. - Operator를 "Contains"를 사용할 때(contain condition)
Case Sensetive하지 않으며, wildcard(*)를 사용할 수 없고, CPU 성능에 밀접한 관계가 있음.
넷스케일러의 정책을 통해 많은 기능이 구현되는 특징을 가진 솔루션이기 때문에 많은 정책을 통해 CPU 성능에 영향을 줄 수 있으며, 이를 최소화하는 방법으로 최적화 할 필요성이 있다.
많은 테스트 및 연습을 통해 이를 최적화하는 정책을 학습해야 한다.
09. 5. 22.
HTTP chunked mode
HTTP mode 중에 chunked mode란 서버에서 사용자의 요청에 대한 응답을 일정 사이즈로 분할하여 전송하는 규약이다.
만약 사용자의 request가 아래와 같다면,
GET / HTTP/1.1
HTTP 서버에 chunked 설정이 되어 있다면 아래와 같이 서버의 응답이 발생한다.
HTTP/1.1 200 OK
Date : Fri, 21 March 2009 10:00:10 GMT
Server : Apache/xxx.xxx.xxx.xxx
Transfer-Encoding : chunked
Content-Type : text/html
이와 같은 HTTP 서버의 chunked 속성은 서버에서 한번에 사용자에게 보낼 데이터 량(contents)이 많을 경우 일정량씩 나누어서 전송하겠다는 속성이다.
본문의 첫번째 숫자는보낼 contents의 숫자를 의미하여 마지막 숫자는 남아있는 contents량을 의미하며 모두 16진수로 표기된다.
만약 사용자의 request가 아래와 같다면,
GET / HTTP/1.1
HTTP 서버에 chunked 설정이 되어 있다면 아래와 같이 서버의 응답이 발생한다.
HTTP/1.1 200 OK
Date : Fri, 21 March 2009 10:00:10 GMT
Server : Apache/xxx.xxx.xxx.xxx
Transfer-Encoding : chunked
Content-Type : text/html
이와 같은 HTTP 서버의 chunked 속성은 서버에서 한번에 사용자에게 보낼 데이터 량(contents)이 많을 경우 일정량씩 나누어서 전송하겠다는 속성이다.
본문의 첫번째 숫자는보낼 contents의 숫자를 의미하여 마지막 숫자는 남아있는 contents량을 의미하며 모두 16진수로 표기된다.
09. 5. 11.
넷스케일러 NTP 설정
넷스케일러의 설정 시 자동으로 NTP 서버와의 동기화를 통해 시간 차를 1/1000 이하로 줄일 수 있으며, 이는 넷스케일러 시스템의 운영 시 로그 기록 시간 등의 다양한 이유에서 필요로 한다.
매번 시간 차이가 발생할 때마다 메뉴얼하게 date 명령어를 통해서 수정할 수 있으나, 사이트의 특성에 따라 로그의 기록 시점 등의 시간이 중요한 요소로 적용될 경우 자동으로 시간을 동기화 할 수 있도록 설정을 하는 것이 좋다.
NTP 설정은 간단하게 한번 설정하여 시간을 동기화하는 방법과 자동으로 동기화가 되도록 설정하는 방법 2가지를 사용할 수 있으며, 한번만 동기화하여 적용하는 방법은 아래와 같다.
매번 시간 차이가 발생할 때마다 메뉴얼하게 date 명령어를 통해서 수정할 수 있으나, 사이트의 특성에 따라 로그의 기록 시점 등의 시간이 중요한 요소로 적용될 경우 자동으로 시간을 동기화 할 수 있도록 설정을 하는 것이 좋다.
NTP 설정은 간단하게 한번 설정하여 시간을 동기화하는 방법과 자동으로 동기화가 되도록 설정하는 방법 2가지를 사용할 수 있으며, 한번만 동기화하여 적용하는 방법은 아래와 같다.
- shell mode로 접속
>shell - 현재의 ntp 프로세스를 확인하여 동작 중이면 ntp 데몬을 kill 한다.
#ps -auxgrep ntpd
#kill pid - ntpdate 명령을 사용하여 ntp 서버와 시간을 동기화 한다.
(단, 명령어 실행 후 동기화 메세지가 제공되지 않으면 방화벽 등에 의해 해당 ntp 서버와의 연결에 문제가 없는지 확인한다.)
#ntpdate 118.219.234.251 (ntp서버를 입력)
1 Jun 11:04:43 ntpdate[61253]: step time server 118.219.234.251 offset -3809.780202 sec
NTP를 통한 자동 시간 동기화는 아래와 같은 단계로 설정이 가능하나, 적용을 위해서는 시스템의 재시작을 필요로 한다.
- /etc/rc.conf.default 파일을 /nsconfig/rc.conf로 복사
이때 NTP 설정 부분, ntpd_enable="NO" 설정을 vi 편집기로 ntpd_enable="YES"로 설정을 변경 - /etc/ntpd.conf 파일을 /nsconfig/ntp.conf로 복사
이때 실제 동기화를 위한 NTP 서버를 지정해야 하며, 한국에서 사용할 경우 time.bora.net NTP 서버와 잘 동작함을 확인하였음.
server 203.248.240.103 burst
restrict 203.248.240.103 mask 255.255.255.255
위 두개의 항목에 대해서만 수정을 하면 됨.
(여기서 203.248.240.103은 time.bora.net NTP서버 IP 주소)
설정 후 시스템을 정상적으로 재시작한 후 대략 3~5분 내로 시간이 동기화되어 정상적으로 운영됨을 확인할 수 있다. 만일 내부의 방화벽 등의 시스템에서 외부 NTP 서버와 차단이 발생할 경우 #nstcpdump host 203.248.240.103으로 정상적으로 통신이 이루어지는가에 대한 확인을 직접할 수 있다.
샘플 : ntpd.conf
# Netscaler NTP Configuration File
#
# Copy this file to /nsconfig, and make changes to /nsconfig/ntp.conf# Changes in /etc/ntp.conf will be lost following a reboot.
#
# Add the following line in /nsconfig/rc.conf to enable ntpd:
#
# ntpd_enable="YES"
#
# The following addresses are example addresses. There should be a# corresponding 'restrict' entry for every 'server' entry.
#
#example address
#server 1.2.3.4 burst
server 203.248.240.103 burst
restrict default ignore
#restrict 127.0.0.1 mask 255.255.255.255 (주석으로 해당 설정 해지)
#corresponds to 'server' entry above
#restrict 1.2.3.4 mask 255.255.255.255
restrict 203.248.240.103 mask 255.255.255.255
09. 5. 7.
citrix netscaler hardware and software compatibility guide
넷스케일러 하드웨어 및 소프트웨어 compatibility giude. 넷스케일러 하드웨어 모델 및 소프트웨어 호환성 관련 자료로써 현재 OS 7.0 이하 버젼은 모두 End of Service가되어 더 이상 지원을 하지 않습니다.
현재까지의 OS 버젼은 8.0 및 8.1 그리고 9.0 버젼을 서비스 중에 있습니다.
http://support.citrix.com/article/CTX113357?print
자세한 내용은 위 링크를 클릭하시면 됩니다.
현재까지의 OS 버젼은 8.0 및 8.1 그리고 9.0 버젼을 서비스 중에 있습니다.
http://support.citrix.com/article/CTX113357?print
자세한 내용은 위 링크를 클릭하시면 됩니다.
09. 3. 18.
넷스케일러 주요 SNMP OID 값
넷스케일러 시스템을 구성하거나 구성 후 시스템을 지속적으로 모니터링을 해야할 경우 넷스케일러는 아래와 같은 주요 항목에 대한 SNMP OID를 제공하고 있다.
- resCpuUsage (1.3.6.1.4.1.5951.4.1.1.41.1)CPU utilization percentage
- resMemUsage (1.3.6.1.4.1.5951.4.1.1.41.2)This represents the percentage of memory utilization on NetScaler.
- tcpCurServerConn (1.3.6.1.4.1.5951.4.1.1.46.1)Server connections, including connections in the Opening, Established, and Closing state.
- tcpCurClientConn (1.3.6.1.4.1.5951.4.1.1.46.2)Client connections, including connections in the Opening, Established, and Closing state.
- tcpSurgeQueueLen (1.3.6.1.4.1.5951.4.1.1.46.15)Connections in the surge queue. When the NetScaler cannot open a connection to the server, for example when maximum connections have been reached, the NetScaler queues these requests.
넷스케일러에서 제공하는 모든 기능에 대해서 SNMP OID값을 제공하는데 이 부분은 첨부 파일을 참조하길 바랍니다.
09. 3. 10.
Limit the number of requests per second from a URL
IPS 또는 UTM 솔루션에서 적용되고 있는 주요 기능 중의 하나로 초당 특정 URL에 대한 Request수를 제한하는 설정을 통해 무한 Refresh 등의 공격에 대해서 효과적으로 어플리케이션을 보호 할 수 있는 기능을 넷스케일러에서 제공할 수 있다.
넷스케일러는 Rate Limiting이란 새로운 기능을 통해 어플리케이션의 Request 뿐만 아니라 Connection 수 또는 bandwidth 설정까지도 제어할 수 있다.
우선 특정 사용자의 Request / sec수를 5개로 제한하는 설정에 대해서 한번 살펴보면 다음과 같이 설정할 수 있다.
넷스케일러는 Rate Limiting이란 새로운 기능을 통해 어플리케이션의 Request 뿐만 아니라 Connection 수 또는 bandwidth 설정까지도 제어할 수 있다.
우선 특정 사용자의 Request / sec수를 5개로 제한하는 설정에 대해서 한번 살펴보면 다음과 같이 설정할 수 있다.
- LimitSelector정책 생성
add ns limitSelector ip_limit_selector http.req.url "client.ip.src" - 트래픽 rate에 대한 thresthold 설정이 포함된 LimitIdentifier를 생성
add ns limitIdentifier ip_limit_identifier -threshold 4 -timeSlice 3600 -mode request_rate -limitType smooth -selectorName ip_limit_selector - 해당 사용자의 request를 redirect하기 위한 responder action 생성
add responder action my_web_site_redirect_action redirect "\http://www.mycompany.com/\" - Limit 설정이 포함된 내용을 적용할 responder 정책을 생성
add responder policy ip_limit_responder_policy "http.req.url.contains(\"myasp.asp\") && sys.check_limit(\"ip_limit_identifier\")" my_web_site_redirect_action - 생성된 정책을 global로 설정
bind responder global ip_limit_responder_policy 100 END -type default
해당 설정을 통해 특정 대상의 어플리케이션으로 유입되는 F5 공격에 대한 방어를 아주 유연하게 대응할 수 있다.
nstcpdump.sh 사용법
넷스케일러에서 특정 어플리케이션에 대한 문제를 확인하거나 넷스케일러 자체적인 패킷 처리 방향을 확인하는 유용한 방법 중의 하나로 nstcpdump.sh라는 도구가 있다.
이 도구를 사용하면 많은 문제에 대한 디버깅이 가능하지만 효과적으로 사용하기 위해서는 아래와 같이 제공되는 common option을 잘 활용할 수 있어야 한다.
common option :
이 도구를 사용하면 많은 문제에 대한 디버깅이 가능하지만 효과적으로 사용하기 위해서는 아래와 같이 제공되는 common option을 잘 활용할 수 있어야 한다.
common option :
- -c : 캡쳐할 패킷의 수를 지정할 수 있다. 지정된 패킷 수량이 수집되면 자동으로 수집이 중단된다.
- -X : 화면에 표시할 패킷의 내용은 16진수와 ASCII 코드로 표시 한다.
- -w
: 지정된 경로에 캡쳐된 패킷을 저장한다. 양은 cap 또는 pcap 형식으로 생성할 수 있다. - -i
: 특정 인터페이스에 대한 패킷만을 수집하고자 할 경우 인터페이스를 지정하여 수집할 수 있다. - host [ipaddress]
: 특정 host ip를 지정하여 수집한다. - net [address] mask [netmask]
: 특정 네트워크 범위에 대한 내용을 수집한다. - port [port #]
: 특정 포트에 대한 내용을 수집한다. - dst port
: 특정 destination 포트에 대한 패킷만을 수집한다. - src port
: 특정 source 포트에 대한 정보만을 수집한다. - tcp : tcp 패킷 정보만 수집한다.
- udp : ucp 패킷 정보만 수집한다.
예를 들어, 아래와 같이 옵션을 조합하여 적용할 수 있다.
root@ns# nstcpdump.sh -X dst host 1.2.3.4 and port 80
또는
root@ns# nstcpdump.sh -w /var/trace/trace1.pcap -i 1/1 -i 1/2
또는
root@ns# nstcpdump.sh -w /var/trace/trace2.cap host 1.2.3.4 and not port 443
여러 가지 common option을 조합하여 원하는 정보만을 수집할 수 있다면 조금 더 빠른 문제 해결이 가능할 것이 분명하다.
09. 3. 8.
HPING을 통한 공격 시뮬레이션
HPING은 TCL 기반 프로그램을 이용한 많은 UTILITY이다. 보안 관리자라면 이 툴을 통해 많은 시뮬레이션을 시도해 볼 수 있다.
기본적으로 많이 사용할 수 있는 기능은 아래와 같다.
기본적으로 많이 사용할 수 있는 기능은 아래와 같다.
- IP Spooping
#hping-a -S - LAND Attack
#hping -a-s <설정한 destip와 동일하게 설정> -p -S -c 1 - SYN Flooding
#hping-a -p -S -i u1000
u1000은 초당 1000개의 패킷을 생성한다는 의미 - TCP Packet Generate
#hping send "ip(saddr=xxx.xxx.xxx.xxx, daddr=xxx.xxx.xxx.xxx, ttl=255)+tcp(sport=123,dport=80,flag=s)"
www.hping.org 사이트에서 HPING 는 메뉴얼을 통해 다양한 기능에 대해서 효율적으로 사용하는 방법을 습득하여, 다양하게 이용할 수 있도록 준비해야 한다.
09. 3. 4.
cli prompt 변경
넷스케일러에서 제공하는 CLI(Common Line Command)에서 prompt 설정을 통해 보다 효율적으로 명령어 작업을 수행할 수 있다.
set cli prompt 명령을 통해서 설정 또는 변경이 가능하며, 설정된 내용을 삭제하고자 할 경우 clear cli promt 명령어를 통해서 기존의 설정을 제거할 수 있다.
그리고 현재 설정된 prompt 내용을 확인하고자 할 경우 show cli prompt 명령어를 통해서 확인이 가능하고, 어떤 설정이 있는가에 대한 정보가 필요할 경우 man set cli prompt 명령어를 통해 확인할 수 있다.
그럼 실제 man 페이지를 통해 내용을 확인해보면,
ARGUMENTS
promptString
The prompt string. The following special values are allowed:
%! - will be replaced by the history event number
%u - will be replaced by the NetScaler user name
%h - will be replaced by the NetScaler hostname
%t - will be replaced by the current time
%T - will be replaced by the current time (24 hr format)
%d - will be replaced by the current date.
This is a mandatory argument
위의 내용과 같이 확인할 수 있으며, 예를 들어 HA 구성일 경우 %s 명령어를 통해 CLI의 prompt에 HA node 정보를 표시할 수 있다.
set cli prompt %s
결과 : > set cli prompt %s
Done
Primary>
여러 가지 정보를 중복으로 표시할 경우도 있는데 이 때는 set cli prompt "%u %T"이런 방식으로 설정할 수 있다.
실제 많은 command를 cli를 통해 적용하는데 있어 간단한 정보지만, 적절하게 사용한다면 효율적인 cli 작업이 가능할 것 같다.
set cli prompt
그리고 현재 설정된 prompt 내용을 확인하고자 할 경우 show cli prompt 명령어를 통해서 확인이 가능하고, 어떤 설정이 있는가에 대한 정보가 필요할 경우 man set cli prompt 명령어를 통해 확인할 수 있다.
그럼 실제 man 페이지를 통해 내용을 확인해보면,
ARGUMENTS
promptString
The prompt string. The following special values are allowed:
%! - will be replaced by the history event number
%u - will be replaced by the NetScaler user name
%h - will be replaced by the NetScaler hostname
%t - will be replaced by the current time
%T - will be replaced by the current time (24 hr format)
%d - will be replaced by the current date.
This is a mandatory argument
위의 내용과 같이 확인할 수 있으며, 예를 들어 HA 구성일 경우 %s 명령어를 통해 CLI의 prompt에 HA node 정보를 표시할 수 있다.
set cli prompt %s
결과 : > set cli prompt %s
Done
Primary>
여러 가지 정보를 중복으로 표시할 경우도 있는데 이 때는 set cli prompt "%u %T"이런 방식으로 설정할 수 있다.
실제 많은 command를 cli를 통해 적용하는데 있어 간단한 정보지만, 적절하게 사용한다면 효율적인 cli 작업이 가능할 것 같다.
09. 2. 22.
Bridge Table Ageing Time
네트워크 장비에서 기본적으로 Layer2 패킷을 처리하는 방법으로 MAC주소 테이블을 참조하거나 MAC 주소가 없을 경우 ARP BroadCast를 통해 해당 MAC 주소를 찾는 방법(ARP Resolving)으로 통신을 한다.
ARP Resolving을 통해 얻은 MAC 주송는 Bridge Table이란 MAC 주소와 IP 주소 Mapping 테이블에 기록(Cache)되며, 매번 ARP Resolving을 하는 것이 아니라 Bridge Table을 먼저 확인하고 해당 조건이 테이블에 있을 경우 활용하는 방식을 사용한다.
넷스케일러라는 장비 또한 동일한 알고리즘을 사용하며, 아래의 명령어를 통해 해당 테이블의 상태를 확인하거나 Cache Time(Ageing Time)설정을 변경할 수 있다.
>show bridgetable
Ageing time for bridge table entries : 120 seconds
MAC Iface VLAN
--- ----- ----
1) 00:04:96:23:ae:70 1/3 3
2) 00:15:17:1f:7b:bc 1/3 3
3) 00:0a:5e:04:ae:06 LO/1 1
4) 00:04:96:21:dc:b0 1/3 3
Done
기본 값을 다른 값으로 갱신할 경우 아래의 명령어를 통해서 가능하다.
>set bridgetable -bridgeAge
(설정 값은 최소 60sec에서 최대 300sec까지 설정이 가능함)
ARP Resolving을 통해 얻은 MAC 주송는 Bridge Table이란 MAC 주소와 IP 주소 Mapping 테이블에 기록(Cache)되며, 매번 ARP Resolving을 하는 것이 아니라 Bridge Table을 먼저 확인하고 해당 조건이 테이블에 있을 경우 활용하는 방식을 사용한다.
넷스케일러라는 장비 또한 동일한 알고리즘을 사용하며, 아래의 명령어를 통해 해당 테이블의 상태를 확인하거나 Cache Time(Ageing Time)설정을 변경할 수 있다.
>show bridgetable
Ageing time for bridge table entries : 120 seconds
MAC Iface VLAN
--- ----- ----
1) 00:04:96:23:ae:70 1/3 3
2) 00:15:17:1f:7b:bc 1/3 3
3) 00:0a:5e:04:ae:06 LO/1 1
4) 00:04:96:21:dc:b0 1/3 3
Done
기본 값을 다른 값으로 갱신할 경우 아래의 명령어를 통해서 가능하다.
>set bridgetable -bridgeAge
(설정 값은 최소 60sec에서 최대 300sec까지 설정이 가능함)
09. 2. 20.
날짜(date) 및 시간(time) 설정
넷스케일러에 NTP 설정을 하지 않았을 때 초기 설치 후 시간 설정을 반드시 확인할 필요가 있으며, 시간 설정이 맞지 않는다면 기록되는 로그에 잘못된 시간이 표기되어서 향후 분석에 문제가 발생할 수 있다.
아래와 같이 넷스케일러 SHELL 명령어를 통해서 시간 및 날짜의 설정 확인 및 변경이 가능하다.
아래와 같이 넷스케일러 SHELL 명령어를 통해서 시간 및 날짜의 설정 확인 및 변경이 가능하다.
- 시간확인
>shell (shell mode로 변경)
#dateMon Jan 19 11:06:08 KST 2009 - 시간설정변경
>shell (shell mode로 변경)
#date ccyymmddHHMM- ccyy, 20(cc)09(yy)-mm, 월-dd, 일-HH, 시간(0~23시)-MM, 분(0~59분)
예제, 2009년 01월19일오전10시45분으로 변경 시
#date 200901191045
거의 모든 버젼의 넷스케일러 적용이 가능함을 확인하였습니다.
how to perform a netscaler core-dump
Document ID: CTX114430 / Created On: 2007. 8. 31 / Updated On: 2008. 2. 19
요약
이 문서는 넷스케일러에서 Core Dump를 강제적으로 생성하는 두 가지 방식에 대해서 설명함.
방법
콘솔에서 아래의 명령어를 통해서 Core Dump의 생성콘솔에서 "~"키를 한번 누른 후 "Ctrl + B"키를 누르면 db 프롬프트로 변경되며, db 프롬프트 상태에서 아래의 순서대로 명령을 입력 함.
db>trace* db>call panic
다른 하나의 방법은 내부명령어(nsapimgr)를 통해서 Core Dump를 생성
/netscaler/nsapimgr -B "w debugger_on_panic 0"/netscaler/nsapimgr -B "call 0"
적용범위
NetScaler Application Delivery Software 7.0 NetScaler Application Delivery Software 8.0 NetScaler Application Delivery Software 8.1
about fin_wait action method
일반적으로 fin_wait 상태는 zombie connection 상태라고 하며, 이는 웹서버에서 설정된 time out 설정을 통해서 메모리 할당을 해제하도록 설정되어 있다.
근래 발생하는 공격의 유형 중에 zombi connection을 많이 발생시켜 웹서버의 부하를 발생하는 case도 종종 볼 수 있는데, 이를 넷스케일러를 통해서 효율적으로 관리할 수 있다.
(기본 설정으로 Apache 웹서버는 15sec 그리고 IIS 웹서버는 120sec를 기준으로 메모리 할당을 해제함.)
넷스케일러의 내부명령어(nsapimgr)을 통해서 해당 설정을 아래와 같이 변경할 수 있으며 내부명령어(nsconmsg)를 통해서 설정 내용을 확인할 수 있다.
Displaying current counter value informationPerformance Data Record Version 2.0reltime:mili second between two records Wed Jan 14 09:48:20 2009Index reltime counter-value symbol-name&device-no 0 0 17 pcb_tot_force_zombie_timeout 1 0 12007 cfg_zombie_timeout_ticks 2 0 6000 cfg_natpcb_zombie_timeout_10msticks Done.
근래 발생하는 공격의 유형 중에 zombi connection을 많이 발생시켜 웹서버의 부하를 발생하는 case도 종종 볼 수 있는데, 이를 넷스케일러를 통해서 효율적으로 관리할 수 있다.
(기본 설정으로 Apache 웹서버는 15sec 그리고 IIS 웹서버는 120sec를 기준으로 메모리 할당을 해제함.)
넷스케일러의 내부명령어(nsapimgr)을 통해서 해당 설정을 아래와 같이 변경할 수 있으며 내부명령어(nsconmsg)를 통해서 설정 내용을 확인할 수 있다.
- 설정변경 : nsapimgr -ys zombie_timeout=6000 (60sec로 설정할 경우)
- 설정확인 : nsconmsg -g zombie_timeout -d stats설정확인결과 예제
Displaying current counter value informationPerformance Data Record Version 2.0reltime:mili second between two records Wed Jan 14 09:48:20 2009Index reltime counter-value symbol-name&device-no 0 0 17 pcb_tot_force_zombie_timeout 1 0 12007 cfg_zombie_timeout_ticks 2 0 6000 cfg_natpcb_zombie_timeout_10msticks Done.
패킷포워딩을 위한 설정
넷스케일러는 L2 및 L3 Mode를 통해 최종 목적지가 넷스케일러가 아닌 환경에서 해당 패킷을 포워딩할 수 있는 방법을 제공한다.
만약 특정 브리지 패킷이 넷스케일러를 지나서 포워딩되어야 하는 환경이라면, 넷스케일러는 L2 Mode 설정을 통해서 해당 패킷을 포워딩 한다. 라우팅 패킷에 대해서는 L3 Mode를 통해서 라우팅 패킷을 전달 한다.
아래의 그림은 넷스케일러의 포워딩 프로세스에 대해서 자세하게 보여주는 도식이다.
만약 패킷 포워딩 프로세스에서 MBF(Mac Based Forwarding) 기능을 사용한다면 넷스케일러는 L2 ARP 테이블 및 L3 Routing 테이블을 참조하지 않고 패킷을 효율적으로 프로세싱 할 수 있다.
하지만 MBF를 사용할 때는 기존의 네트워크 디자인이 Asymmetric 환경일 경우 이런 네트워크 디자인이 더 이상 유지되지 못한다. MBF 기능은 VPN이나 Firewall과 같이 동일한 장비로 패킷을 전달해야 할 경우 유용하게 적용될 수 있는 기능이다. 물론 ISP 이중화와 같은 환경에서도 잘 고려하여 구성할 수 있다.
단, ISP 이중화 회선을 이용하며 넷스케일러의 LLB 설정을 사용한다면 MBF 기능을 더 이상 사용할 수 없다.
위 그림은 넷스케일러 MBF 기능의 동작 방식에 대한 간단한 예제 화면이다.
피드 구독하기:
글 (Atom)
