레이블이 netscaler인 게시물을 표시합니다. 모든 게시물 표시
레이블이 netscaler인 게시물을 표시합니다. 모든 게시물 표시

10. 4. 29.

넷스케일러의 정보를 추출하여 별도의 파일로 기록하는 방법

일부 고객사의 요청에 의해 넷스케일러에서 제공하는 SNMP 정보 외에 다른 정보를 주기적으로 별도의 파일에 기록하여 제공할 수 있는데, 이 방법은 기본적으로 제공하는 기능이 아닌 편법이기 때문에 권장하지는 않지만 꼭 필요할 때 활용할 수는 있을 것 같다.

[샘플]. VPN 사용자의 접속수를 5분 주기로 별도의 파일로 저장
LogDir="/var/temp/vpnuser"
CurrentDate=`date`
FinalDate=`date -j -f "%a %b %d %T %Z %Y" "${CurrentDate}" +"%Y-%m-%d %T"`
FileDate=`date -j -f "%a %b %d %T %Z %Y" "${CurrentDate}" +"%Y-%m-%d"`


vpn=`ssh nsroot@localhost 'sh vpn vserver' | sed -n '/Current AAA Users/p' | nawk '{print $4}'`
#sh vpn vserver 명령에 대한 결과 "Current AAA Users"라인만 프린트한 awk 명령어로 특정 field 대한 string 값을 출력한다.

if [ ! -e "${LogDir}/${FileDate}.txt" ]; then
        echo "TIME|Current VPN Users" >> ${LogDir}/${FileDate}.txt
fi
`echo "${FinalDate}|${vpn}" >> ${LogDir}/${FileDate}.txt`

이렇게 생성된 스크립트에 대해서 실행권한을 부여 후 넷스케일러의 SHELL MODE에서 CRONTAB을 활용하여 주기적인 배치 잡을 생성하면 필요한 데이터를 얻을 수 있다. 위 스크립트는 일반적인 스크립트이며, egrep이나 awk를 이용하여 보다 많은 정보를 수집할 수도 있다. 해당 스크립트를 자동으로 실행하기 위해서는 넷스케일러의 SHELL MODE에서 인증서 기반의 SSH 로그온 방법을 사용해야 합니다.

[넷스케일러의 인증서 기반 SSH로그온 방법]
SSH 로그온 시 비밀번호를 사용하지 않고 인증서를 이용하여 신뢰된 사용자로 등록하는 방법이며, 자세한 방법은 아래의 링크를 참조할 수 있다.
cd ~
mkdir .ssh 2> /dev/null
cd /root/.ssh
ssh-keygen -b 1024 -f identity -P '' -t dsa

# For each "target" Netscaler you wish to be able to login without passwords do:
scp identity.pub nsroot@<ip of target>:/root/.ssh/identity.pub
# enter password when prompted for the remote box

On each of the target machines, then do the following:
cd ~/.ssh
cat identity.pub >> authorized_keys
# 과정을 모드 마치면 넷스케일러에 SSH 비밀번호 인증없이 접속이 가능함.

egrep이나 awk에 대한 추가적인 정보는 인터넷에서 많이 제공하고 있으니 참조하면 충분히 유용한 스크립트를 만들 수 있다.

PS : 이 방법은 권장하는 방법이 아닌 편법으로 제공되는 방법이기 때문에 필요 사용 전에 유념하셔야 합니다.

09. 12. 11.

MIP 사용현황 체크


넷스케일러 운영 중인 상태에서 현재 설정된 MIP 또는 SNIP에 대한 사용현황을 확인하는 쉬운 방법이 있다.


넷스케일러 CLI로 접속 후 SHELL MODE로 변경한 다음 아래의 명령어를 사용하면 현재의 MIP 또는 SNIP별로 사용 현황 및 가능한 여유를 확인 가능하다.


(CLI)
> SHELL
# nsapimgr -d mappedip




실제로 위 명령어를 사용하면 아래와 같은 결과화면을 확인할 수 있다.

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를 입력하는 방법이기도 하다.

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 유틸 명령어에 대해서는 다른 메뉴얼을 확인하시기 바랍니다.

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

구체적인 이유에 대해서는 조금 더 확인 후 댓글로 첨부를 할 예정이다.

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

09. 6. 10.

넷스케일러 Troubleshooting 가이드 중 CPU 점유률 관련 TroubleShooting이 필요할 경우 이전에 언급된 nsprofmon이라는 CPU 프로파일링 스크립트(시트릭스에서 OS 버젼별로 제공)가 없을 경우 사용할 수 있는 방법에 대해서 정리한다.

명령어 : nsconmsg
사용법 : nsconmsg -K [해당날짜의 newnslog 파일] -s totalcount=[원하는 count정보] -g cpu_use -d current
사용예 :
  1. 특정 시간대의 newnslog 파일 중 CPU 점유률이 20%가 넘은 프로세스 정보를 확인할 경우 아래와 같이 사용함
    #nsconmsg -K /var/nslog/newnslog.10 -s totalcount=200 -g cpu_use -d current
  2. 현재 시점의 CPU 점유률이 10% 이상인 프로세스를 확인하고자 할 경우 아래와 같이 사용함.
    #nsconmsg -s totalcount=100 -g cpu_use -d current

기타 유용한 TroubleShooting 가이드는 아래의 링크를 통해 다운로드 받아서 참조하시기 바랍니다. 넷스케일러 엔지니어라면 언제든지 사용하여 분석할 준비가 되어있어야 하지 않을까요??

넷스케일러 troubleshooting guide 다운로드

09. 6. 8.

넷스케일러의 SIMPLE ACLs 설정 방법

넷스케일러의 SIMPLE ACLs의 설정은 아래와 같은 화면에서 간략한 정보 몇 가지만 입력하면 Block ACL을 설정할 수 있으며, 소스 IP만을 차단하는 환경에서는 유용하고 쉽게 적용할 수 있습니다.











위 그림과 같이 넷스케일러 GUI에서 Network > ACLs > Symple Acls 경로에서 Add 버튼을 클릭하면 볼 수 있으며, 자세한 내용은 아래와 같습니다.


  1. Name : 관리할 ACL 이름을 입력합니다.

  2. Action은 Block 정책만 설정이 가능합니다.

  3. Protocol 선택은 TCP 또는 UDP를 선택할 수 있으며, 선택하지 않을 경우 ANY가 됩니다.

  4. SourceIP는 필수 입력 요소로 실제 차단할 IP 주소를 입력할 수 있습니다.(범위입력 안됨)

  5. Destination Port 는 해당 사용자에 대한 특정 Destination Port만을 차단할 때 해당 포트 번호를 명시하면 됩니다.(범위입력 안됨)

  6. 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하여 본사에서 지원을 받을 수 있다.

사용 방법은 아래의 절차에 의거하여 실행하고 결과를 확인할 수 있다.
  1. 받은 파일의 압축을 해제
    (파일을 /var/tmp 경로에 복사한 후 ns-8.1-56.7.tgz라면)
    >shell
    #cd /var/tmp/
    #tar zxvf ns-8.1-56.7.tgz
  2. Script 실행을 위한 메모리 Buffer를 할당
    #/var/tmp/nsprofmon -ys profbuf=16k
  3. Script를 실행
    (2분 정도 실행하면 결과 화면을 볼 수 있다.)
    #/var/tmp/profmon -K /var/tmp/ns-8.1-56.7 -s sort=2 -T 120 -recapture tee /var/tmp/cpu.log
  4. 모든 Script 실행 후 메모리 Buffer를 비움(불필요한 메모리 점유를 해지)
    #/var/tmp/nsprofmon -yS profbuf
    (옵션의 -yS로 S를 대문자로 입력하면 Buffer 메모리를 해지 함)

실행 결과를 토대로 직접 분석을 하거나 TechSupport의 도움을 통해 직접적인 CPU 점유률에 대한 원인 분석을 진행할 수 있다.

09. 5. 25.

넷스케일러 Compression 적용 방법

Compression 정책 적용 방법 :
  1. 서비스 레벨의 정책 적용
    A. Compression 정책의 Global binding 적용
    B. 적용 대상 service 또는 servicegroup에 대한 CMP 옵션 적용
    (GUI에서 server 선택 후 open > advanced > compression 체크하거나 CLI에서 해당 서비스에 대한 set service 서비스네임 –cmp YES로 적용)
    C. Compression 기능 적용 됨
  2. 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 기능을 통해 쉽게 이런 문제를 해결할 수 있다.

넷스케일러의 정책설정과 성능관계

넷스케일러의 Policy Engine을 통해 정책을 설정할 때 CPU 성능과 밀접한 관계가 있기 때문에 상황에 따라 적절하게 정책을 설정하여 CPU 성능을 최적화할 필요성이 있다.

  • Operator를 "=="을 사용할 때(equal condition)
    Case Sensetive하며 wildcard(*)를 사용할 수 있고, CPU 영향을 최소화 할 수 있음.
  • Operator를 "Contains"를 사용할 때(contain condition)
    Case Sensetive하지 않으며, wildcard(*)를 사용할 수 없고, CPU 성능에 밀접한 관계가 있음.

넷스케일러의 정책을 통해 많은 기능이 구현되는 특징을 가진 솔루션이기 때문에 많은 정책을 통해 CPU 성능에 영향을 줄 수 있으며, 이를 최소화하는 방법으로 최적화 할 필요성이 있다.

많은 테스트 및 연습을 통해 이를 최적화하는 정책을 학습해야 한다.

09. 5. 11.

넷스케일러 NTP 설정

넷스케일러의 설정 시 자동으로 NTP 서버와의 동기화를 통해 시간 차를 1/1000 이하로 줄일 수 있으며, 이는 넷스케일러 시스템의 운영 시 로그 기록 시간 등의 다양한 이유에서 필요로 한다.

매번 시간 차이가 발생할 때마다 메뉴얼하게 date 명령어를 통해서 수정할 수 있으나, 사이트의 특성에 따라 로그의 기록 시점 등의 시간이 중요한 요소로 적용될 경우 자동으로 시간을 동기화 할 수 있도록 설정을 하는 것이 좋다.

NTP 설정은 간단하게 한번 설정하여 시간을 동기화하는 방법과 자동으로 동기화가 되도록 설정하는 방법 2가지를 사용할 수 있으며, 한번만 동기화하여 적용하는 방법은 아래와 같다.
  1. shell mode로 접속
    >shell
  2. 현재의 ntp 프로세스를 확인하여 동작 중이면 ntp 데몬을 kill 한다.
    #ps -auxgrep ntpd
    #kill pid
  3. 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를 통한 자동 시간 동기화는 아래와 같은 단계로 설정이 가능하나, 적용을 위해서는 시스템의 재시작을 필요로 한다.

  1. /etc/rc.conf.default 파일을 /nsconfig/rc.conf로 복사
    이때 NTP 설정 부분, ntpd_enable="NO" 설정을 vi 편집기로 ntpd_enable="YES"로 설정을 변경
  2. /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

자세한 내용은 위 링크를 클릭하시면 됩니다.

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.

nstcpdump.sh 사용법

넷스케일러에서 특정 어플리케이션에 대한 문제를 확인하거나 넷스케일러 자체적인 패킷 처리 방향을 확인하는 유용한 방법 중의 하나로 nstcpdump.sh라는 도구가 있다.

이 도구를 사용하면 많은 문제에 대한 디버깅이 가능하지만 효과적으로 사용하기 위해서는 아래와 같이 제공되는 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. 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 작업이 가능할 것 같다.

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까지 설정이 가능함)

09. 2. 20.

날짜(date) 및 시간(time) 설정

넷스케일러에 NTP 설정을 하지 않았을 때 초기 설치 후 시간 설정을 반드시 확인할 필요가 있으며, 시간 설정이 맞지 않는다면 기록되는 로그에 잘못된 시간이 표기되어서 향후 분석에 문제가 발생할 수 있다.

아래와 같이 넷스케일러 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