나의 즐겨찾기 | 블로그홈 | 바로가기 바로가기 | 로그인
나도한다
블로그  |  사진갤러리  |  동영상갤러리 방명록  |   즐겨찾기 추가
하두세 (seattlewa1991)
프로필     
 인기도 :
 이 블로그 점수주기
71,467
전체 글보기(5055)
농경 생활과 작물 노하우 및 농업기술 정보
단군의 후예 지킴이가 역사를 바꾼다
우리 함께 지킵니다
구굴 애드 센스 Money !
홈페이지 만들기 강좌
방명록
Memory Travel Load
생활에 필요한 링크 사이트 리스트
드림위버 강좌
나만의 공간 만들기
윈도우 활용 배우기
컴퓨터 배우기 강좌
스위시 맥스 강좌
프래쉬 강좌
일러스트
포토샵 배우기
폰트로 글자 만드리 강좌
게 시판
대~한민국!
Seoul/서울
특종 사건 모음
오늘의 뉴스
스포츠 소식
정치는 이런 저런 아듀!
해외 뉴스 소식
해외 스포츠
히딩크의 이모 저모
아드보카드 이모 저모 새 댓글이 있습니다.
베어백의 이모 저모
코트비 코치의 이모 저모
코엘류의 이모 저모
해외 스포츠 프리미어 리거 활동과 소식
박근혜 대표의 소식
연예인의 기자활동
UCC 동영상
UFO,미스테리,사이언스 채널
컴퓨터 강좌
쇼핑몰 공개 강좌 안내
무료 다운로드 프로그램 사이트 안내
무료 관한 모든 정보 안내
아로마 테라피로 건강 삼매경에 폭빠져바!
아이콘모음
수집,정보
생활상식
나만의 펜사랑 카폐
Caffe's deport.com
e-world Club Zone
웃음이 터졌다!
해외 연예인 파파라치 월드
북한의 하루
한국사,세계사,유물,여행기
한국의 과학,우주 탐사
지구,우주,과학 탐험
멋진 풍경
애견클럽
개구리 사랑
공룡 사랑
나무 ,식물 사랑
부동산 정보/점포/임대/매매/
낙서노트
행복한 부엌
당신의 건강 체크
오늘의 한마디
40대 출발선언!
2635Newage세대
1000명의사랑!
머뭇 거리지 말고 시작해!
2007년 대선을 위한 설문 조사중 당신의생각을?
e세상의 소리
가족
기본폴더
동의보감
만화책 풍자 관람
비밀 일기장
창업/부업
재테크 활용
공지 사항 알림
유용한 공지 사항 알림
yahoo/야후 정보 알림
yahoo info/야후 정보 알림
관혼상제/세시풍속
생활 풍수학
새롭게하소서!
앞서가자!
새롭게 시작해!
토끼야 같이가!
시작일뿐야!
찾어바!
나눠바!
찡어바!
노력해!
중얼중얼누가알아!
영화/책/게임/꼿/기타등등...
소문난 맛집
맛의즐거움 바로이런것!
사랑과 햠께 떠나자
유머한마디 남기자
아이들을 위한 영어 학습 실천 이핵심
헤이,헬로,야,친구하자
영어 한마디
들려 주고싶은 시.한소리
운동은 무리하면 안되여!
건강 비법
쇼핑은 여기야!
심문고
설문
오늘 전체
방문자 19 1052810
구독자 0 21
댓글 0 2895
참조글 0 7486
HanRSS 로 구독하기Fish 로 구독하기
2010 02월
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28
최근 댓글 전체보기
이런 미친 또라이 시키..
이런 미친 또라이 시키..
존1내 불쌍해 ㅋㅋㅋㅋ..
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ..
쩐다
최근 참조글 전체보기
정종철 셋째 동영상 미..
이청용 동영상 자세히보..
조갑경 내꼬 만들기
Ice torture ..
Xanax withdr..
다녀간 블로거 더보기
- icyn
- witguy2002@Y
- bugsgift
- 수련
- 가입센타
 즐겨찾기
 즐겨찾기 글모음
개설일 : 2005/02/20
 

글로벌·DLC·DHCP의 트러블슈팅 가이드
2003.01.27 / AM 00:00

[콘퍼런스]에픽 팀스위니, 엑스엘게임즈 송재경이 말하는
게임 그래픽의 미래
- 2.25(목)
[지디넷코리아]많은 네트워크 관리자들이 스니퍼와 같은 네트워크 또는 프로토콜 분석기를 이용해 자신의 네트워크 문제점을 해결해 줄 수 있는 방법을 찾고 있다. 하지만 관리자들은 문제점을 해결하기 위한 자료들을 공유하지 못하고 있다. 그 이유는 동일한 네트워크 환경이라고 하더라도 사용자의 사용 방법이나 장비의 설정 내용에 따라 동작하는 상태가 달라, 동일한 증상이라고 하더라도 해결 방법이 다르기 때문이다. 또한 네트워크를 컨설팅하고 문제점을 찾아 해결했던 보고서는 해당 사이트의 보안과 관련된 내용이기 때문에 고객의 허가없이는 사이트와 자료를 공개할 수 없고, 특정 프로토콜 분석기를 사용해 문제점을 발견, 해결했다는 자료는 해당 제품의 판매와 관련돼 있기 때문에 업체에서도 특정 부류의 사람들만이 볼 수 있도록 허용돼 있다. 이외에도 여러가지 이유로 인해 현재까지도 네트워크 문제점 해결과 관련된 자료는 찾아보기 힘들다. 때문에 누군가가 알려주었으면 하는 생각보다는 서적을 찾거나 인터넷을 돌아다녀 보거나, 주위의 사람들과의 자료 공유를 통해 방법을 찾아가는 것도 좋을 듯 싶다.

이번에 연재하는 트러블슈팅 케이스스터디는 어떤 문제는 어떻게 해결해야 된다는 답안이 아니라, 스니퍼와 같은 프로토콜 분석기를 이용해 네트워크 문제를 해결하는 방법에 좀더 빨리 접근할 수 있는 방법을 제시하는 것이다. 그 첫번째로 스니퍼 엑스퍼트 글로벌 계층과 OSI 7계층 가운데 데이터링크 계층에 해당하는 스니퍼 엑스퍼트의 DLC 계층에서 발생하는 주요 Diagnosis, Symptoms과 DHCP에 대해 관리자들이 알아야 할 내용을 살펴보자. 물론 모든 내용은 이더넷과 관련된다.

스니퍼 엑스퍼트 글로벌 계층의 내용 분석
우선, 스니퍼 엑스퍼트의 글로벌 계층에서는 어떤 분석 결과들이 나오는지 알아보자. 이 계층에서는 스니퍼가 설치돼 있는 네트워크 세그먼트 전체 트래픽과 관련된 정보를 제공한다. 때문에 특정 계층이라기 보다는 전체 트래픽에 대한 분석 결과다. Bad CRC 및 콜리전(Collision)에 대한 내용은 DLC 계층 분석에서 다시 언급할 것이다. 이 계층에서 가장 자주 발생하는 증상 가운데 ‘Broadcast/Multicast Storm’와 ‘Spanning Tree Topology Change’에 대해 살펴보자.

스니퍼 엑스퍼트 화면에서는 해당 세그먼트에서 브로드캐스트 패킷이 초당 40개 이상 발생하면 이 알람을 화면에 등록하며, 120개 이상 발생하면 ‘Broadcast/Multicast Storm Diag.’ 알람이 등록된다. 이 알람의 중요도는 매우 심각(critical)이다. 브로드캐스트라고 하는 것은 네트워크에서 상대방 시스템을 찾거나 자기 자신의 존재를 상대방에게 알리기 위한 동작에서 발생하는 패킷이다. 흔히 알고 있는 ARP, DHCP, NetBIOS 브로드캐스트 패킷과 더불어 그 종류 또한 많다.

이런 브로드캐스트 패킷은 상위 계층에 어떤 프로토콜이 있으며, 어떤 정보가 포함돼 있는지 해석하기 위해 해당 네트워크 세그먼트에 있는 모든 시스템의 네트워크 어댑터에서 수신하고 처리해야 한다. 때문에 초당 수백 개의 브로트캐스트/멀티캐스트 패킷이 해당 세그먼트에서 발생하면 사용자의 워크스테이션이나 서버의 CPU에 부하를 많이 주며, 잠재적으로 서비스 응답시간이 늦어질 가능성도 있다. 또한 스위치의 한 포트에 연결된 세그먼트에서 발생하는 브로드캐스트 패킷은 전체 포트로 전달되기 때문에 스위치 자체에도 심각한 부하를 줄 수 있다. 때문에 사이트를 방문해 네트워크를 측정할 때마다 먼저 말하는 것이 IPX 브로드캐스트를 막거나 제거하라고 추천한다. 현재 이더넷에서 MAC, IP 계층의 브로드캐스트는 반드시 필요하지만, IPX 프로토콜은 특별한 경우를 제외하고는 거의 사용하지 않는다.
화면 1 | BDPU패킷 디코드 내용 / *클릭하면 확대이미지 확인 가능

패킷 전달의 목표점을 정의하는 스패닝 트리
대부분의 2 계층 브리지 또는 스위치들은 스패닝 트리(Spanning Tree) 구성 작업을 수행한다. 이것은 두개 이상의 네트워크 세그먼트 사이에 존재하는 다중 브리지나 스위치 사이에 패킷을 전달하는 과정에서 루프(loop)가 발생하지 않도록 하는 알고리즘이다. 흔히들 간단하게 즐기는 게임 가운데 ‘사다리 타기’ 정도로 생각하면 될 듯 싶다. 스패닝 트리는 어떤 패킷이 어느 포트로 전달돼야 하는가를 정의하게 된다. 여기에 관련된 자료는 네트워크 관련 서적에 많이 나와 있기 때문에 상세한 설명을 피한다. 여기서는 스니퍼에서 제공하는 도움말의 내용과 더불어 스패닝 트리를 구성하는 스위치들 사이에 주고 받는 MAC 계층, BPDU(Bridge Protocol Data Unit) 패킷을 예로 제공한다(그림 1, 화면 1).


  • 스니퍼상에 나타난 ‘Spanning Tree 토폴로지 변환’ 메시지 현상

    가. 논리적이 LAN의 어디에선가 브리지가 망가졌거나 동작하지 않는다.
    나. 누군가가 사용하고 있던 포트를 교체했거나 논리적인 LAN의 어딘가에서 브리지의 우선 순위가 바뀐다. 만약 이런 변화가 일정한 간격으로 발생한다면, 아마도 논리적인 LAN의 어딘가에 구성이 잘못된 브리지가 있다.
스패닝 트리 브리지는 트래픽이 진행하는 방향을 학습해야 할 책임이 있기 때문에 다른 말로 ‘투명한’ 또는 ‘학습하는’ 브리지라고 부르기도 한다. 네트워크에 있는 스테이션들은 논리적인 LAN으로 몇 개의 물리적이 세그먼트들을 연결한 상태에서 여전히 동작하고 있는 브리지들을 완벽하게 알 수 없다. 또한 브리지들은 BPDU 메시지를 사용해 스스로 통신한다. 이런 메시지들은 접속할 수 있는 “라우팅 루프(routing loop)들”이 있음을 확인하는 것이며, 브리지들은 이 경로를 통해 논리적인 LAN에 있는 세그먼트에서 세그먼트로 동일한 프레임을 계속 진행시킬 것이다. 브리지들은 루프를 제거하기위해 필요하다면 다른 브리지의 몇몇 포트들을 차단함으로써 여전히 연결된 상태에서 해당 루프로 트래픽이 진행하는 것을 막는다.

브리지들은 전체 논리적인 LAN을 위한 하나의 ‘루트 브리지’와 각각의 물리적인 세그먼트를 위한 하나의 ‘로컬로 설계된 브리지’를 선택한다. 통상적으로 루트 브리지는 우선 순위를 기반으로 선택된다. 가장 높은 우선 순위를 갖도록 구성된 브리지가 루트가 된다. 연결 관계는 브리지 ID에 의해서 구성된다.

로컬로 구성된 브리지는 ‘루트로의 경로 코스트’가 가장 낮은 것을 기반으로 선택된다. 여기에서 ‘경로 코스트’은 해당 브리지에서 루트 브리지까지 한 프레임을 전송할 때 사용하는 경로의 속도와 관련이 있다. 또한 전송 경로 코스트는 각 브리지에 있는 각 포트와 관련돼 있다. 일반적으로 높은 비용이라고 하는 것은 낮은 속도의 링크(예를 들어, 브리지 내에 특정 포트에 연결된 56Kbps WAN 접속)를 의미하며, 반대로 낮은 코스트는 빠른 속도의 링크를 의미한다. 이런 비용은 통상적으로 재구성할 수 있다. 특정 브리지에 대한 ‘루트로의 경로 코스트’는 한 프레임을 해당 브리지에서 루트로 전송하기 위한 코스트에 그 브리지와 루트 브리지 사이의 모든 브리지에 해당 프레임을 진행시키기 위한 코스트를 더한 것이다. 루트 경로 코스트가 ‘0’이라는 것은 해당 브리지가 루트라는 것이다.

BPDU로 LAN 상태 파악
스패닝 트리가 완성되면, 네트워크가 안정 상태가 되며 전송되는 BPDU 메시지는 단지 현재의 스패닝 토폴로지(topology)를 알려주는 헬로우(hello) 메시지들이다. 이 메시지들은 각각의 로컬로 설계된 브리지에 의해 주기적으로 전송된다(루트 브리지는 어느 정도의 주기로 헬로우 메시지가 전송돼야 하는가를 결정하는 헬로우 타임 패럼미터를 지정한다). 이런 헬로우 메시지는 나중에 추가될 수도 있는 다른 브리지들의 접속이 쉽도록 하는 것이며, 또한 만약 로컬로 구성된 브리지가 정지한 경우에는 이 메시지가 전송되지 않기 때문에 해당 세그먼트에 있는 다른 브리지들이 그 사실을 감지할 수 있다. 한 브리지의 동작이 멈췄다는 사실이 감지되면, 다른 브리지들은 고장난 브리지 주변으로 새로운 스패닝 트리 계산을 시도한다.

정상 상태에서 오직 로컬로 구성된 브리지만이 BPDU 메시지를 보낸다. 뿐만 아니라, BPDU 메시지는 결코 로컬 세그먼트 외부로 진행되지 않는다. 따라서 네트워크 분석기는 일반적으로 세그먼트 상에 구성된 브리지가 여러 개 있다고 하더라도 이들 가운데 연결돼 있는 단 하나의 브리지만 알 수 있다. 그러나 만약 어떤 중요한 브리지가 논리적인 LAN의 어딘가에서 추가됐거나 동작을 멈췄다면, 이것이 비록 해당 세그먼트의 외부에 있다해도 엑스퍼트 시스템은 그 사실을 감지할 것이다. 이것은 LAN 전역에 걸친 스패닝 트리 계산이 완수돼야 하기 때문이며, 엑스퍼트 분석 시스템은 위와 같은 변화에 대한 완전한 기록을 ‘Global Symptoms’에 표시할 것이다.

스패닝 트리의 변화를 알려주는 ‘local initiator’는 스패닝 트리 계산이 완료됐다는 사실을 엑스퍼트 시스템에게 처음으로 알려주는 패킷을 전송한 해당 세그먼트에 있는 장비다. 스패닝 트리의 변화는 다음과 같은 메시지들로 알 수 있다.

  • CHANGE 유형의 BPDU 메시지
  • 새로운 토폴로지 정보를 포함하고 있는 헬로우 패킷
  • 로컬로 구성된 브리지가 아닌 다른 누군가에 의해 전송된 헬로우 패킷.
스패닝 트리 계산 자체는 로컬 세그먼트 외부에서 초기화됐을 수도 있기 때문에, 이것은 원인을 제공한 실제 브리지나 또 다른 브리지가 될 수도 있다.

스니퍼 엑스퍼트 DLC 계층의 패킷 분석
데이터링크 계층의 주된 기능 가운데 하나는 수신된 패킷의 신뢰성을 파악하기 위한 CRC(Cyclic Redundancy Code) 확인 작업이다. 때문에 스니퍼 엑스퍼트의 DLC 계층에서는 CRC 에러와 같은 패킷 오류에 관련된 알람들이 많다. 패킷이 손상되는 경우는 선로의 단선, 케이블 구성 오류 또는 장비 및 포트 고장으로 인해 발생하기 때문에 몇 가지 테스트와 선로 측정 장비를 이용해 쉽게 찾아낼 수 있다.



일단 스위치와 브리지 환경에서 트래픽을 분석하기 위해 스니퍼를 설치하는 방법에 대해 잠시 살펴보자. 스위치 환경에서 스니퍼와 같은 프로토콜 분석기를 설치하는 가장 간단한 방법은 스위치 자체의 모니터링 또는 미러링 포트를 사용하는 것이다(그림 2). 물론 스위치 내에 포트 설정 기능이 있어야 한다. 그럼 미러링 포트 설정 기능이 없거나 모르는 스위치는 어떻게 트래픽을 측정하는가. (그림 2)의 2번 방법과 같이 더미 허브를 사용한다. 입출력 패킷을 따로 측정하거나 스위치 포트에 연결된 케이블 중간에 스니퍼를 연결하는 방법이 3번과 4번이다. 3번은 패킷을 복사해 다른 포트로 넘겨주는 스플리터 탭(Splitter tab)을 사용하는 방법이며, 4번은 2개 이상의 포트가 내장된 스니퍼 장비(Sniffer Distributed System)를 사용하는 것이다.
패킷 에러에 대해 설명하기 전에 우선 이더넷 프레임의 구조와 충돌이 발생하는 위치에 대해 잠시 알아보자. (그림 3)에서 데이터 링크 계층의 이더넷 프레임의 구조와 충돌이 발생할 수 있는 위치를 표시했다.


이더넷 프레임은 최소 64바이트에서 최대 1518바이트의 크기를 갖는다. 즉 DLC 계층에서의 프레임에는 12바이트의 주소 영역, 2바이트의 이더넷 형태와 범위 및 4바이트의 CRC와 더불어 46∼1500바이트의 데이터가 포함돼 있다. 더불어 실제 네트워크에 전송될 때에는 8바이트의 Preamble이 자동으로 프레임 앞에 추가된다. 이 8바이트의 Preamble은 콜리전에 의해 손상된 패킷 내부에서 확인할 수 있다. 즉, 손상된 패킷의 앞, 가운데 또는 뒷부분에서 16진수 값으로 55나 AA가 연속적으로 나타나는 것을 볼 수 있다. 이것이 Preamble이다. 2진수 값으로 ‘10101010…’이 반복되기 때문에 55(0101)나 AA(1010)이 연속적으로 보이는 것이다. 때문에 손상된 패킷의 내부에 이런 패턴이 있다면 충돌에 의해 손상됐음을 짐작할 수 있다.

화면 2 콜리전이 감지된 위치에 따른 패킷관련
*클릭하면 확대이미지 확인 가능
(그림 3)에서 보면 충돌이 발생하는 위치에 따라 패킷 내부의 데이터가 다르게 검출된다. 먼저 1번 위치에서 충돌이 감지되면, 패킷 전체가 preamble 패턴으로 검출되고, 2번 및 3번 위치에서 감지되면, 이더넷 헤더 부분은 일부 디코드 된다. 그리고 4번 위치에서 충돌이 발생하면, 사용자의 데이터 영역이 손상됐기 때문에 해당 프레임에 대한 재전송(retransmission)이 발생한다. 충돌의 위치에 따라 다르게 검출된 패킷은 (화면 2)를 참고하자.

  • 스니퍼 상에 나타난 ‘Collision after 64바이트(Late collision)’ 메시지
    원인 : 일반적인 이더넷에서의 패킷 충돌과 유사하지만, 차이점은 선로 상에 이미 프레임이 전송 중이라는 것을 모든 네트워크 스테이션에서 감지해 대기하고 있는 상태에서 충돌이 발생한 경우에 이 메시지가 발생한다. 즉, 프레임이 전송되고 있는 상태에서 후반부에 다른 프레임이 충돌된 것이다.
    현상
    가. 충돌을 야기시킨 스테이션까지의 이더넷 케이블의 길이가 한계를 초과해 프레임의 전송 지연 시간이 길어져 발생할 수 있다. 때문에 케이블 길이를 조절할 필요가 있다.
    나. 해당 스테이션에 대한 케이블 연결이 불량한 경우.
    다. 스테이션이 연결된 네트워크 하드웨어의 포트나 내부적으로 고장이 발생한 경우.
  • 스니퍼 상에 나타난 ‘DLC Source Address Broadcast’의 메시지
    원인 : 이 메시지는 소스 DLC 주소 필드가 브로드캐스트 주소인 경우에 생성된다.
    현상
    가. 프레임이 잘못 포장됐다. 이것은 패킷 충돌로 인해 발생할 경우
    - 만일 이같은 문제가 다시 발생한다면, 케이블, 트랜시버, 네트워크 어댑터 보드 등을 살펴본다.
    나. DLC 주소가 잘못됐을 경우.
    - 해당 프레임을 전송한 DLC 스테이션의 문제를 해결하기 위해 캡처된 패킷들 가운데 이 알람이 붙어있는 패킷의 주변에 있는 패킷들을 살펴본다.
    - 오류를 발생시키는 스테이션의 NIC을 바꾸거나 그 스테이션을 네트워크에서 제거한다.

    ‘충돌을 유발하는 장비를 추적하라’
    충돌을 발생시키는 장비를 찾는 방법에 대해 생각해보자. 먼저 충돌이 발생한 상태에서 캡처된 패킷을 보면, 에러 프레임 이후의 2∼3개 프레임에서 다른 주소들에 비해 지속적으로 많이 나타나는 주소를 찾을 수 있다. 만일 자주 발생하는 주소를 찾을 수 없다면, 해당 충돌은 불규칙하게 발생된 것으로 볼 수 있다. 하지만 일정한 주소들이 반복적으로 나타난다면, 그 주소에 해당하는 장비를 찾아보자.

    만일 라우터 주소라면, FTP와 같은 파일 전송 애플리케이션을 사용해 원격지에서 10MB이상 되는 파일을 다운로드하거나 업로드하면서 충돌 발생 상태를 관찰하자. 충돌이 증가한다면, 해당 라우터가 처리하지 못하는 것이다. 만일 발견된 주소가 일반 사용자 PC의 NIC 주소라면, 그 사용자의 PC에서 서버쪽으로 파일을 복사하거나 다운로드하면서 충돌 발생 상태를 확인하자. 이때 충돌이 증가한다면, 해당 시스템의 NIC이 고장났거나 케이블이 제대로 연결되지 않은 것이다.

    특정 포트에 연결된 모든 시스템에 대해 충돌이 지속적으로 검출된다면, 시스템들이 연결된 상단 스위치의 포트를 바꿔 보는 것도 한 방법이다. 만약 포트를 바꾼 상태에서 충돌이 발생하지 않는다면, 스위치의 포트에 문제가 있는 것이다. 포트를 바꿔도 똑같이 충돌이 발생한다면, 사용자들이 연결돼 있는 하단의 스위치를 바꿔보자.

    스니퍼에서 나타나는 패킷 에러에는 다음과 같이 Jabber, CRC, Runt, Fragment, Oversize, Alignment Error 등이 있다. 이런 패킷 에러들은 에러가 발생한 패킷의 크기와 패턴에 따라 정의된 것이다. 우선 에러가 발생한 패킷을 캡처하기 위해서는 스니퍼에서 제시하는 전용 카드와 드라이버를 사용해야 한다. 전용 카드의 종류는 스니퍼 매뉴얼에 나와 있으며, 드라이버는 스니퍼가 설치돼 있는 ‘./nai/Sniffer NT/Driver’ 폴더에 준비돼 있다. 각각의 에러에 대해 살펴보자.

    화면 3 | Jabber 프레임
    *클릭하면 확대이미지 확인 가능
    화면 4 | Runt 프레임
    화면 5 | 프래그먼트 프레임

    화면 6 | Oversize 프레임
    *클릭하면 확대이미지 확인 가능
    화면 7 | 얼라이먼트 에러 프레임
    *클릭하면 확대이미지 확인 가능

    • Jabber : Jabber 프레임은 전혀 쓸모없는 데이터를 포함하고 있는 프레임이다. 일반적으로 CRC 에러로 인식되며, (화면 3)과 같이 헤더 영역은 어느 정도 디코딩되지만, 데이터 영역에는 알아볼 수 없는 균일한 패턴을 포함하고 있다.
    • Runt : Runt 프레임은 CRC 에러가 없는 매우 작은 크기의 프레임이다. 일반적으로 플레임워크 프레임과 유사하지만, (화면 4)과 같이 헤더 부분에서 CRC 에러가 발견되지 않는 프레임이다. 플래그먼트 프레임과 함께 쇼 프레임으로 처리하기도 한다.
    • 프래그먼트 : (화면 5)과 같이 64바이트 보다 작고 CRC 에러가 발견된 프레임이다.
    • ·Oversize : (화면 6)과 같이 이더넷 최대 프레임 크기인 1518바이트보다 큰 프레임이다. (화면 6)에서 상단 우측의 Len(Bytes) 항목을 보면 1518로 돼 있다. 이 항목에서의 패킷 크기는 CRC 4바이트를 뺀 숫자이다. 때문에 (화면 6)에 있는 패킷의 크기는 1522로 계산된다.
    • 얼라이먼트 에러 : 프레임의 길이가 8비트(1바이트)의 배수가 아닌 경우다. 때문에 (화면 7)과 같이 정상적으로 바이트 단위의 데이터로 해석할 수 없다.
    화면 8 | 케이블 구성 오류와 포트 고장
    *클릭하면 확대이미지 확인 가능
    화면 9 | 호스트 테이블의 MAC계층 에러정보 / *클릭하면 확대이미지 확인 가능

    (화면 8)은 케이블을 잘못 구성했거나 장비의 포트 고장 또는 단선 등으로 인해 발생하는 패킷 에러 패턴이다. Runt나 얼라이먼트 에러 패킷들이 지속적으로 발생해 그 패턴을 알아볼 수 없다.
    화면 10 | Bootpc및 Bootps 패킷
    *클릭하면 확대이미지 가능
    스니퍼의 실시간 모니터 화면에서 CRC 에러 등과 같이 패킷 에러를 유발시키는 장비를 찾아낼 수 있다. 바로 호스트 테이블(Host Table)의 테이블 화면에서 MAC 탭을 선택해 보자. 사용자들이 자주 잊고 사용하는 것이 바로 스크롤 바이다. 하단에 있는 스크롤 바를 클릭해 화면을 좌우로 움직여 보면 상단에 Out Error, CRC, Jabber 등과 같은 제목이 (화면 9)와 같이 보일 것이다. 바로 이곳에서 에러를 유발시키는 스테이션을 확인할 수 있다. 리스트에 있는 모든 스테이션에서 전송한 패킷의 에러 상태를 보여주는 화면이다. 물론 관리자들이 MAC, IP 주소, 호스트 네임(Host Name)을 정리한 자료들이 있다면, MAC 주소만으로 어떤 스테이션인지 쉽게 확인할 수 있지만, 그렇지 않다면 스니퍼의 주소록 등록 기능을 사용해 특정 MAC의 IP 또는 호스트 네임을 찾아보자.

    패킷의 크기와 대역폭 효율성 높이기
    스니퍼에서 가장 많이 제공되는 정보 가운데 패킷 사이즈별 분포가 있다. 스니퍼와 같은 패킷 분석기를 사용하면서도 그냥 지나쳐 버리는 정보일 수도 있다. 하지만 패킷 크기별 분포에 관한 정보는 Dashboard, History Sample, Global Statistics에서 3번이나 제공한다. 우리들은 흔히 대역폭 사용량(utilization)과 패킷 개수에만 집중하는 경향이 있다. 대역폭 사용량, 패킷 개수와 패킷 크기별 분포는 네트워크 관리자들에게 매우 중요한 정보를 제공할 수 있다. 바로 현재 네트워크 대역폭의 효율성을 계산할 수 있다.

    화면 11 | DHCP Nak 패킷
    *클릭하면 확대이미지 가능
    일반적으로 이더넷에서 전송할 수 있는 최소 패킷의 크기를 64바이트 최대 패킷의 크기를 1518바이트로 알고 있다. 이것은 사용자가 전송하는 데이터와 각 계층의 헤더 및 CRC를 포함하는 패킷의 크기이다. 하지만 실제 이더넷 케이블을 통해 전송되는 패킷의 크기는 다르다. 즉 (그림 3)과 같이 패킷의 앞부분에는 8바이트(6바이트 Preamble+2바이트 SFD)의 Preamble과 패킷들 사이를 구분하기 위한 Interframe Gap 9.6us(96비트=12바이트)가 자동으로 추가된다. 따라서 실제 전송되는 패킷의 최소 크기는 64+8+12=80바이트이며, 최대 패킷은 1538바이트가 된다.

    초당 1,250,000바이트를 전송할 수 있는 10MB 대역폭에서는 64바이트 데이터 패킷을 초당 14,800개(100M 대역폭에서는 148,000) 전송할 수 있다. 그리고 1518바이트의 패킷은 초당 880개를 전송할 수 있다. 물론 작은 패킷을 전송하면 전송 시간이 빠르다고 느낄 것이다. 하지만 작은 크기의 패킷을 많이 사용하면, 그만큼 대역폭을 낭비하게 된다. 즉 64바이트 패킷만을 사용해 데이터를 전송한다면, 실제 데이터가 차지하는 대역폭은 64/84=0.76으로 76%뿐이다. 나머지 24%는 Preamble과 Interframe Gap으로 채워지게 된다. 하지만 1518바이트 패킷을 전송하면, 1518/1538=0.986으로 98.6%의 대역폭이 실제 데이터로 채워지게 되는 것이다. 어느 것이 더 효율적이겠는가.

    애플리케이션에서 이같은 상황을 확인할 수 있다. 가장 대표적인 예로 FTP와 HTTP, 텔넷을 생각해보자. 파일만을 전송하는 FTP는 한 패킷 크기를 거의 1KB 이상씩 할당한다. 때문에 파일 전송 속도면에서는 가장 빠른 프로토콜 가운데 하나이다. 그리고 HTTP와 텔넷처럼 실제 데이터를 화면에 보면서 패킷을 전송하는 프로토콜들은 화면에 뿌려지는 속도가 빨라야 하기 때문에 작은 크기의 패킷을 주로 사용한다.

    DHCP로 확인되는 패킷 분석
    IP 부족으로 인해 대부분의 네트워크에서 DHCP(Dynamic Host Configuration Protocol)를 많이 사용하고 있다. 정상적인 DHCP 네트워크라면, 세그먼트에 관계없이 어떤 상황에서도 각 시스템에 IP와 관련된 정보를 제공해야 한다. 하지만 가끔 IP 정보를 제공받지 못해 네트워크 접속에 실패하는 경우가 있기 때문에 이 프로토콜에 대해 전반적으로 살펴볼 필요가 있다.

    스니퍼에서 패킷을 캡처해 보면, DHCP라고 하는 프로토콜이 Bootps(DHCP/BOOTP Server)와 Bootpc(DHCP/BOOTP Client)로 표시된다. 물론 디코드 화면에서는 DHCP라고 표현을 하지만, 호스트 테이블 이나 매트릭스 화면에서는 위의 두 가지 프로토콜로 표시된다. DHCP 클라이언트가 서버와 정상적으로 정보를 주고받았다면, (화면 10)과 같은 4개의 패킷이 보여야 한다.

    a. DHCP Discover     b. DHCP Offer
    c. DHCP Request     d. DHCP Ack

    DHCP 환경에서 네트워크 접속에 실패하게 되면, 해당 클라이언트 측에서 패킷을 캡처해 위 4개의 패킷이 보이는지 또는 요청하는 IP나 기타 정보들이 올바르게 할당되는지를 살펴봐야 한다. 만약 DHCP 서버에서 할당할 수 없는 IP를 클라이언트가 요청한다면, 서버로부터 (화면 11)와 같은 ‘DHCP Nak(Negative acknowledgement)’ 패킷이 전달될 것이다. Nak 패킷이 전달되는 경우에는 클라이언트 측에서 어떤 IP를 요구했는지 살펴보자.

    DHCP 문제는 윈도우의 ‘ipconfig/release와 /renew’로 어느 정도 해결할 수 있다. IP 정보를 받을 수 없는 상황이 계속 발생한다면, DHCP 서버의 구성 내용을 살펴봐야 한다. 더 이상 할당할 수 있는 IP가 없거나 서버가 응답하지 않을 수도 있다. 물론 서버의 응답 패킷이 클라이언트에게 전달되기 전에 사라지는 것 같다면, 서버측과 클라이언트측에서 동시에 스니퍼로 측정해 패킷이 없어진 구간을 추적할 수 있다. @

    트랙백 주소 : http://www.zdnet.co.kr/Reply/trackback.aspx?key=00000010055872

'마이웨이' 필리핀에서 죽음의 곡이 된 사연은?

2010.02.09 00:45 | 해외 뉴스 소식 | 하두세

http://kr.blog.yahoo.com/seattlewa1991/6184 주소복사

'마이웨이' 필리핀에서 죽음의 곡이 된 사연은?
[조선일보] 2010년 02월 08일(월) 오후 11:03   가
| 이메일| 프린트
필리핀의 가라오케에서 프랭크 시나트라(Sinatra)의 ‘마이웨이(My way)’를 부르다간 자칫 목숨을 잃을 수도 있다. 가라오케의 대부분은 아예 노래책에서 이 노래를 지웠다.

필리핀에서는 지난 10년간 최소 6명이 가라오케에서 ‘마이웨이'를 불렀다가 희생돼, 아예 살인 항목의 서브 카테고리에 ’마이웨이 살인(My way killings)'을 설정하고 여기에 희생자들을 분류하기까지 한다고 미국의 뉴욕타임스가 7일 보도했다. 그 마이웨이가 죽음을 부르는 이유에 대해서는 해석이 분분하다.

가라오케가 선풍적인 인기를 끌고 있는 필리핀에서 '마이웨이'는 누구나 즐겨 부르는 노래다. 하지만 "노래를 못 부른다"는 다른 손님들의 비웃음이나 조롱에 격분해 시비를 벌이다 살인으로 이어지는 폭력사건이 늘고 있다는 것이다.

가사도 문제다. 남들이 뭐라 해도 내 식대로 한다는 노래 가사는 상대방에게 노래 순서를 기다리는 이들에게 오만하게 들릴 수도 있다. 노래교실 버치 알바라신 사장은 NYT에 “망설여질 때면…꿀꺽 삼켰다가 뱉어버렸지(When there was doubt…ate it up and spit it out)” “내 식대로 했다(I did it my way)”같은 가사는 자존심과 오만으로 비쳐 사람들을 자극하는 듯하다“고 설명했다.

그런가 하면, 다른 손님들이 기다려도 마이크를 오랫동안 잡고 놓지 않는 습관이 시비를 부른다는 분석도 있다. 필리핀의 이발사 로돌포 그레고리오(Gregorio)는 "'마이 웨이'의 문제는 모두가 그 노래를 알고 있고, 모두가 그에 대해 자신만의 의견을 갖고 있다는 점"이라고 말했다.

게다가 100만 정 이상의 불법 총기가 만연한 필리핀의 열악한 치안 상황도 ‘마이웨이 살인'의 이유로 꼽히고 있다.

이와 관련, 필리핀대 롤랜드 톨렌티노 교수는 "필리핀에 잠재되어 있던 폭력과 사회적 규율의 붕괴가 가라오케를 통해 촉발됐을 뿐"이라고 분석했다.

로버트 박 北서 심하게 맞았다"

[한국일보] 2010년 02월 09일(화) 오전 00:19   가
| 이메일| 프린트
對北인권단체 대표 주장
북한 억류 43일 만에 풀려난 한국계 미국인 로버트 박의 침묵은 북한 당국의 폭력과 북한에 남아있는 친척의 안위에 대한 걱정 때문이라고 박씨의 입북을 도왔던 대북인권단체 대표가 주장했다.

대북인권단체 팍스코리아나 조성래 대표는 8일 YTN과 인터뷰에서 박씨가 입국과 동시에 검거돼 의식을 잃을 정도로 심한 구타를 당했고, 그때 생긴 얼굴의 상처 때문에 석방 때까지 북한당국이 그의 모습을 공개하지 못했다고 주장했다. 조 대표는 "박씨가 3일 정도를 계속 구타당해 한달 정도 입조차 열 수 없는 지경이었다"고 전했다.

조 대표는 또 "박씨가 입북 전 자신의 할머니가 월남했으며 북한에 이산가족이 있다고 말했다"고 YTN에 밝혔으며, 남아있는 친척의 안위에 대한 걱정도 박씨가 입을 굳게 다물고 있는 이유 중 하나라고 덧붙였다.

이와 함께 로버트 박이 지난해 억류됐던 여기자들과 달리 비교적 빨리 석방된 것은 화폐개혁 실패 후 체제동요가 심해 내부단속을 위해 한시 바삐 추방한 것이라는 분석도 제기되고 있다.

한편 북한 당국은 박씨가 북한의 체제를 이해한 뒤 반성했다고 발표했다. 박씨가 북한에서 "평양 봉수 교회 예배에 참가해 보니 종교의 자유가 보장돼 있었다"며 "나는 창피를 느꼈고 북한에 진심으로 사과한다"고 발언했다는 것이다.

김이삭기자 hiro@hk.co.kr


아침 지하철 훈남~알고보니[2585+무선인터넷키]

이청용 한국인 프리미어리거 최다 연속 선발 출전 기록 -1

2010.02.08 16:23 | 해외 스포츠 프리미어 리거 활동과 소식 | 하두세

http://kr.blog.yahoo.com/seattlewa1991/6182 주소복사

이청용 한국인 프리미어리거 최다 연속 선발 출전 기록 -1

[스포츠조선] 2010년 02월 08일(월) 오후 01:52
10일 맨체스터 시티전…이영표 기록 도전

 한국인 프리미어리거 역사를 새롭게 작성하고 있는 이청용(22ㆍ볼턴)이 또 다른 신기록에 도전한다.

 한시즌 최다 연속 선발 출전 기록이다. '블루 드래곤'은 지난해 12월 6일(이하 한국시각) 울버햄턴전을 필두로 7일 풀럼전까지 12경기 연속 선발 출전했다. 그사이 한국인 프리미어리거 최초로 한 시즌 두 자릿수 공격포인트(5골-5도움) 달성에 성공했다. 최근 포항으로 이적한 설기현이 레딩 시절인 2006~2007시즌 기록한 4골-5도움을 넘어서며 최다 공격포인트 기록도 경신했다. 뿐만 아니라 박지성이 보유하고 있는 한국인 프리미어리거 한 시즌 최다골 기록(2006~2007시즌ㆍ5골)과도 타이를 이뤘다.

 넘지 못한 산이 바로 이영표(33)가 갖고 있는 한국인 프리미어리거 한시즌 최다 연속 선발 출전 기록이다. 이영표는 토트넘 시절인 2005~2006시즌 두 차례나 13경기 연속 선발 출전했다. 수비수라는 특성을 감안해야 하지만 기록은 기록이다.

 윙포워드인 박지성(29ㆍ맨유)은 5경기 연속 선발이 최고 기록이다. 맨유의 두터운 선수층으로 인한 로테이션 시스템으로 두 자릿수 연속 선발 출전 기회를 얻는 것은 불가능에 가깝다. 그래도 데뷔 시즌인 2005~2006시즌 5경기에서 연속 선발 출전한 것은 의미있는 기록이다. 2006~2007시즌 레딩에서 최고의 시즌을 보낸 설기현(31)도 5경기 연속 선발 출전 기록을 갖고 있다.

 이청용의 D-데이는 10일이다. 이영표의 기록에 한 경기 모자라는 그는 이날 오전 4시45분 맨체스터 시티와 원정경기를 갖는다.

 이청용은 풀럼전 직후 "온 몸이 쑤신다"고 했다. 60여일 동안 12경기를 소화하는 강행군으로 피로가 쌓였다. 오언 코일 볼턴 감독도 "이청용에게 휴식이 필요한 것이 사실이다. 기회가 오면 휴식 시간을 줄 것이다. 하지만 그는 현재 볼턴에서 가장 중요한 선수 중 한 명"이라고 강조했다. 팀의 주축인 이청용을 선발 진용에서 제외하는 데는 큰 고민이 필요하다는 것이다.

 맨시티전은 이청용의 또 다른 역사다. 선발 출전할 경우 이영표의 기록과 타이를 이루게 된다. 골을 터트리면 한 시즌 최다골 기록의 맨 꼭대기에 선다. 이청용은 올시즌 5골-5도움을 기록하고 있다.

신발끈 매는 12가지 법 [60]
여러장의 이미지가 포함되어 있습니다.


 






 






 






 






 






 






 






 






 






 

[ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 ] 다음 페이지 다음 10번째 페이지
 
최근 글
글로벌·DLC·DHCP..
'마이웨이..
로버트 박 北서 심하게..
이청용 한국인 프리미어..
신발끈 매는 12가지 ..
지난 글
2009년 4월
2009년 5월
2009년 6월
2009년 7월
2009년 8월
2009년 9월
2009년 10월
2009년 11월
2009년 12월
2010년 1월
2010년 2월