이 세상에 장애 없는 서비스가 있다면 얼마나 좋을까요? 서버, 스토리지, 네트워크 어느 한 요소도 장애에서 자유롭지 않습니다. 이런 이유로 IT 운영 조직은 장애를 전제로 다양한 대응책을 마련합니다. 이야기를 네트워크로 좁혀 보죠. 네트워크 장비 관리자는 장애에 어떻게 대응하고 있을까요?
네트워크 장애 대응은 숙련된 전문가의 날카로움이 필요한 지루한 디버깅의 과정이라 말할 수 있습니다. 문제 해결 과정을 간단히 보죠.
어떤 문제이건 해결책을 찾으려면 원인을 알아야 합니다. 잘 돌아가던 서비스가 갑자기 패킷 손실, 지연 증가 등의 증상을 보인다면? 네트워크 관리자 역시 가장 먼저 원인을 찾아야 합니다.
그렇다면 원인은 어떻게 찾아야 할까요? 갑자기 아파서 병원에 가면 간단한 문진 후 바로 각종 정밀 검사를 하는 것을 떠올려 보십시오. 네트워크도 똑같습니다. 네트워크 서비스 장애의 원인은 패킷 분석으로 찾아야 합니다.
문제가 일어나면 네트워크 관리자는 가장 먼저 패킷을 획득하기 위해 덤프 작업을 합니다. 그러고 나서 문제를 재현합니다. 이 과정에서 문제의 원인이 무엇인지 밝혀지죠.
무엇이건 손에 익은 것이 편하죠. 펌킨네트웍스의 L4/L7 스위치 제품군은 너무나 유명한 tcpdump를 지원합니다. tcpcump는 패킷 덤프를 떠서 디버깅을 하기 위한 리눅스 명령어로 이를 사용해 TCP, UDP, IP 등에 대한 패킷을 캡처합니다.
펌킨네트웍스 장비의 경우 CLI 글로벌 모드에서 이 명령어를 지원합니다. 이번 포스팅에서는 펌킨네트웍스 장비에서 tcpdump 명령어를 사용할 때 꼭 알아야 하는 기본 옵션을 소개합니다.
- 주로 사용하는 옵션
-n : 주소(호스트 주소, 포트 번호 등)를 변환하지 않고 IP 정보만 출력할 때
-e : 각 덤프의 행에 링크 레벨 해더를 출력 ->MAC 정보를 표시하고 싶을 때
-i VLAN 이름 : 패킷을 확인하고 싶은 네트워크 인터페이스를 지정할 때
+ 조건식 : 옵션 뒤에 따라오는 조건식은 어떠한 패킷들을 출력할지를 선택하는데 쓰입니다.
- 방향 : src(Source IP), dst(Destination IP), src or dst, src and dst – 특정 데스티네이션과 같이 원하는 대상에 대한 IP 패킷만 덤프할
- 프로토콜 : arp, ether, tcp, fddi, icmp, udp, ip, rarp,
- 형식 : host, net, port – 특정 서비스를 대상으로 디버깅할 경우
* 사용 예시
- tcpdump -n -e -i [VLAN 이름] [프로토콜] [and/or] [방향] [형식 IP주소]
Ex1.) tcpdump -ne -i test icmp and host IP주소 and port 80 and not icmp
Ex2.) tcpdump -ne -i test tcp port 80 and src IP주소 and dst IP주소
Ex3.) tcpdump -ne -i test udp dst port not 53
Ex4.) tcpdump -ne -i test not arp
* 그 외 Tcpdump 에서 사용되는 옵션들
-A : 각 패킷을 아스키 형식으로 출력
-c <count> : 패킷 수 지정(지정한 수 만큼 보여진 후 종료)
-f : 숫자 형식의 IPv4 주소를 출력
-p : 인터페이스를 무차별 모드로 설정 하지 않음
-q : 퀵 모드로 출력(출력 정보가 적음)
-t : 각 덤프에 시간정보를 출력하지 않음
-v : 보다 자세한 정보를 출력
-w <file> : 출력되는 패킷들을 저장할 <file>을 지정
-x : 각각의 패킷을 헥사 코드로 출력
-X : 헥사 코드와 아스키 형태를 모두 출력
이외에도 다양한 옵션을 사용할 수 있는데요, 더 자세한 내용은 man 페이지나 tcpdump 공식 페이지를 참조 바랍니다.
