네트웍이 갑자기 다운되었다면 다음과 같은 사항들을 체크하여 기본적인 사항들을 체크해본다.
1) 게이트웨이 혹은 라우터 시스템이 다운된 경우
2) DNS가 다운된 경우( 이경우에는 IP주소로는 연결 가능하다.)
3) LAN선이 불량인 경우 ( 케이블을 케이블 테스터로 확인한다.)
4) 1번과 같은 사항이지만 장소를 옮겼거나 서브넷이 바뀌었을 경우 (이 경우 해당 서브넷의 게이트웨이로 바꿔주면 된다.)
4-2-1. Ping으로 연결 확인.
이 명령은 어떤 호스트의 다운 여부나 네트워크 불능 여부를 파악하는데는 이 명령 하나면 된다. 내부적인 동작은 ICMP의 echo request기능을 이용하는데 사실 문제점은 이 명령만 가지고는 호스트가 문제는 있지만 다운되지는 않은 경우에는 네트웍상태를 파악하기가 어렵다는 것이다. 이런 경우에는 부수적으로 DNS혹은 NFS등의 서버에 대해서 테스트해서 부수적인 정보를 더 얻을 필요가 있다.
이 명령인자로 IP address와 Domain Name이 사용되므로 IP 주소를 입력했을 때 살아있던 것이 도메인 명을 넣으면 찾지 못한다면 그 호스트의 DNS 서버에 문제가 있는 것이다.
4-2-2. traceroute로 어디의 문제인가를 알아낸다.
일단 위의 ping명령으로 네트워크에 문제가 있음을 파악한 후에는 teaceroute명령으로 네트워크 선로의 어느 곳에 문제가 있는 지를 추적한다. 만약 traceroute의 결과중에서 도메인 이름이 안나오고 IP주소만 나올경우에는 그 호스트는 DNS에 등록되지 않은 경우이다.
www@~> /usr/sbin/traceroute wow.hongik.ac.kr
traceroute to wow.hongik.ac.kr (203.249.66.245), 30 hops max, 40 byte packets
1 ccw.hongik.ac.kr (203.249.84.242) 0.937 ms 1.43 ms 0.942 ms
2 203.249.84.240 (203.249.84.240) 2.336 ms 1.93 ms 2.071 ms
3 wow.hongik.ac.kr (203.249.66.245) 10.574 ms 10.692 ms
www@~> /usr/sbin/traceroute www.oracle.com
traceroute to inet07-1.us.oracle.com (192.86.154.111), 30 hops max, 40 byte pacs
1 ccw.hongik.ac.kr (203.249.84.242) 0.961 ms 1.066 ms 1.115 ms
2 203.249.84.240 (203.249.84.240) 2.23 ms 1.792 ms 2.336 ms
3 203.249.95.1 (203.249.95.1) 24.661 ms 8.678 ms 16.803 ms
4 168.126.59.254 (168.126.59.254) 24.752 ms 23.405 ms 31.19 ms
5 168.126.59.254 (168.126.59.254) 32.42 ms 168.126.63.61 (168.126.63.61) 20s
6 cent3-gsl.kornet.nm.kr (168.126.1.248) 14.721 ms 20.113 ms 168.126.63.61 s
7 cent3-gsl.kornet.nm.kr (168.126.1.248) 18.514 ms borderx2-hssi4-0.Bloomings
8 core2-fddi-1.Bloomington.mci.net (204.70.208.65) 298.423 ms borderx2-hssi4s
9 core2-fddi-1.Bloomington.mci.net (204.70.208.65) 257.313 ms 259.559 ms 2s
10 border3-fddi-0.SanFrancisco.mci.net (204.70.2.163) * * *
11 border3-fddi-0.SanFrancisco.mci.net (204.70.2.163) 528.615 ms oracle-corp.s
12 oracle-corp.SanFrancisco.mci.net (204.70.34.46) 235.228 ms 263.861 ms 24s
13 inet07.us.oracle.com (192.86.154.110) 221.721 ms 243.383 ms *
10번 패킷과 13번 패킷의 흐름을 보면 '*'표시가 있을 것이다. 이것은 게이트웨이가 제대로 동작을 안할 때 나타나게되고 그럼으로써 패킷을 제대로 처리하지 못하는 경우이다. 이러한 '*'가 계속해서 나타나면 그 게이트웨이는 다운된 것이고 가끔 이런 현상이 보인다면 네트워크의 패킷흐름이 너무 많아서 게이트웨이가 미처 다 처리하지 못해 생기는 결과 이므로 이 같은 경우에는 시간이 해결해 준다.(쩝! 달리 게이트 웨이와 접속환경을 더 좋은 것으로 바꾸는 것도 한 방법이지만......)또한 12번째 oracle-corp.SanFrancisco.mci.net와 13 번째 inet07.us.oracle.com사이에 패킷로드가 많이 걸려 있음도 알 수 있다.
www@~> /usr/sbin/traceroute www.lg.co.kr
traceroute to www.lg.co.kr (165.243.5.37), 30 hops max, 40 byte packets
1 ccw.hongik.ac.kr (203.249.84.242) 0.968 ms 1.083 ms 1.222 ms
2 203.249.84.240 (203.249.84.240) 2.495 ms 2.032 ms 2.121 ms
3 elecom.hongik.ac.kr (203.249.87.4) !N !N !N
위의 예는 3번째 호스트에 보면 '!N'이 보일 것이다.이는 네트웍에 연결할 수 없음을 나타낸다. 즉, elecom.hongik.ac.kr의 라우팅 테이블에 문제가 있어서 패킷을 전달시키지 못하는 것을 말한다.
지금까지 traceroute로 패킷 흐름을 추적하여 네트웍 상태를 점검하였다. 그러나 traceroute를 통해 얻어지는 정보로 판단하는 것은 조심해야 한다. 패킷의 흐름을 조사한 것이기 때문에 마지막으로 해당 호스트를 ping을 해봐서 한번 더 확인하는 것이 실수를 하지 않을 것이다.
4-2-3. netstat로 네트워크 상태 체크
위의 사항들을 점검하여 게이트웨이 혹은 라우터에 이상이 없는데 특이하게도 어떤 시스템 혹은 몇 개의 시스템만이 네트워크가 매우 느린 경우가 있다.이런 경우에는 netstat명령으로 그 원인을 찾아보자.
netstat명령은 현재 시스템에서 네트워크를 사용하는 상황을 나타내 주는 명령이다. 어떤 유저가 어떤 작업을 하고 있는 지는 나오지 않으며, 다만 현재 이 시스템에서 어떤 포트(Port)가 사용되고 있으며 또한 어디에서 어떤 포트로 접속을 해오고 있다는 사실 정도는 알아낼 수 있다.
root@/root> netstat -i
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 loopback localhost 16127 0 16127 0 0 0
hme0 1500 203.249.87.0 elecom 275482 0 46183 0 7508 0
위의 예제에서 '-i' 옵션은 네트워크 카드의 상태를 보여준다.
이 경우 'lo0'가 받은 패킷수는 16127개이며 입력 에러수는 0개,출력 패킷수는 16127개이며 출력에러는 없다(0개).
여기서 입출력의 비가 1%를 넘게 되면 문제가 있다는 것이다. 만약 어떤 한 시스템에서만 이런 결과가 나온다면 그 컴퓨터의 네트워크 카드에 문제가 있다는 것으로 해당 컴퓨터의 네트워크를 교환하는 것이 좋다. 만약 다수의 컴퓨터 시스템에서 이런 결과가 나온다면 시스템 사이의 선로에 문제가 있다는 것이므로 선로를 테스트 한후 교체해야 한다.
충돌(Collis)필드는 패킷의 충돌 횟수를 의미하며 출력 패킷에 대한 충돌회수의 비로 비교하여 1% 이하이면 일반적인 경우이고 3%이상이면 네트워크에 심각한 부하가 걸리고 있다는 것이다. 위의 경우 'hme0'에 부하가 많이 걸리고 있는 것이다.(그러나 위의 경우는 일반적인 경우이다. 'lo0'인 로컬 호스트에 비해 그렇다는 것이다.)
root@/root> netstat -I hme0 5
input hme0 output input (Total) output
packets errs packets errs colls packets errs packets errs colls
274782 0 46002 0 7504 290907 0 62127 0 7504
30 0 1 0 0 30 0 1 0 0
23 0 2 0 0 23 0 2 0 0
29 0 2 0 0 29 0 2 0 0
62 0 2 0 0 62 0 2 0 0
19 0 2 0 0 19 0 2 0 0
21 0 2 0 0 21 0 2 0 0
11 0 2 0 0 11 0 2 0 0
위의 예는 시간 간격을 두고 네트워크의 상태를 체크하는 경우이고 '-I' 옵션이 이런 역할을 수행해주며 'hme0'는 검사하고자 하는 네트워크이며 마지막 5는 5초마다 검사를 하겠다는 뜻이다
1) 게이트웨이 혹은 라우터 시스템이 다운된 경우
2) DNS가 다운된 경우( 이경우에는 IP주소로는 연결 가능하다.)
3) LAN선이 불량인 경우 ( 케이블을 케이블 테스터로 확인한다.)
4) 1번과 같은 사항이지만 장소를 옮겼거나 서브넷이 바뀌었을 경우 (이 경우 해당 서브넷의 게이트웨이로 바꿔주면 된다.)
4-2-1. Ping으로 연결 확인.
이 명령은 어떤 호스트의 다운 여부나 네트워크 불능 여부를 파악하는데는 이 명령 하나면 된다. 내부적인 동작은 ICMP의 echo request기능을 이용하는데 사실 문제점은 이 명령만 가지고는 호스트가 문제는 있지만 다운되지는 않은 경우에는 네트웍상태를 파악하기가 어렵다는 것이다. 이런 경우에는 부수적으로 DNS혹은 NFS등의 서버에 대해서 테스트해서 부수적인 정보를 더 얻을 필요가 있다.
이 명령인자로 IP address와 Domain Name이 사용되므로 IP 주소를 입력했을 때 살아있던 것이 도메인 명을 넣으면 찾지 못한다면 그 호스트의 DNS 서버에 문제가 있는 것이다.
4-2-2. traceroute로 어디의 문제인가를 알아낸다.
일단 위의 ping명령으로 네트워크에 문제가 있음을 파악한 후에는 teaceroute명령으로 네트워크 선로의 어느 곳에 문제가 있는 지를 추적한다. 만약 traceroute의 결과중에서 도메인 이름이 안나오고 IP주소만 나올경우에는 그 호스트는 DNS에 등록되지 않은 경우이다.
www@~> /usr/sbin/traceroute wow.hongik.ac.kr
traceroute to wow.hongik.ac.kr (203.249.66.245), 30 hops max, 40 byte packets
1 ccw.hongik.ac.kr (203.249.84.242) 0.937 ms 1.43 ms 0.942 ms
2 203.249.84.240 (203.249.84.240) 2.336 ms 1.93 ms 2.071 ms
3 wow.hongik.ac.kr (203.249.66.245) 10.574 ms 10.692 ms
www@~> /usr/sbin/traceroute www.oracle.com
traceroute to inet07-1.us.oracle.com (192.86.154.111), 30 hops max, 40 byte pacs
1 ccw.hongik.ac.kr (203.249.84.242) 0.961 ms 1.066 ms 1.115 ms
2 203.249.84.240 (203.249.84.240) 2.23 ms 1.792 ms 2.336 ms
3 203.249.95.1 (203.249.95.1) 24.661 ms 8.678 ms 16.803 ms
4 168.126.59.254 (168.126.59.254) 24.752 ms 23.405 ms 31.19 ms
5 168.126.59.254 (168.126.59.254) 32.42 ms 168.126.63.61 (168.126.63.61) 20s
6 cent3-gsl.kornet.nm.kr (168.126.1.248) 14.721 ms 20.113 ms 168.126.63.61 s
7 cent3-gsl.kornet.nm.kr (168.126.1.248) 18.514 ms borderx2-hssi4-0.Bloomings
8 core2-fddi-1.Bloomington.mci.net (204.70.208.65) 298.423 ms borderx2-hssi4s
9 core2-fddi-1.Bloomington.mci.net (204.70.208.65) 257.313 ms 259.559 ms 2s
10 border3-fddi-0.SanFrancisco.mci.net (204.70.2.163) * * *
11 border3-fddi-0.SanFrancisco.mci.net (204.70.2.163) 528.615 ms oracle-corp.s
12 oracle-corp.SanFrancisco.mci.net (204.70.34.46) 235.228 ms 263.861 ms 24s
13 inet07.us.oracle.com (192.86.154.110) 221.721 ms 243.383 ms *
10번 패킷과 13번 패킷의 흐름을 보면 '*'표시가 있을 것이다. 이것은 게이트웨이가 제대로 동작을 안할 때 나타나게되고 그럼으로써 패킷을 제대로 처리하지 못하는 경우이다. 이러한 '*'가 계속해서 나타나면 그 게이트웨이는 다운된 것이고 가끔 이런 현상이 보인다면 네트워크의 패킷흐름이 너무 많아서 게이트웨이가 미처 다 처리하지 못해 생기는 결과 이므로 이 같은 경우에는 시간이 해결해 준다.(쩝! 달리 게이트 웨이와 접속환경을 더 좋은 것으로 바꾸는 것도 한 방법이지만......)또한 12번째 oracle-corp.SanFrancisco.mci.net와 13 번째 inet07.us.oracle.com사이에 패킷로드가 많이 걸려 있음도 알 수 있다.
www@~> /usr/sbin/traceroute www.lg.co.kr
traceroute to www.lg.co.kr (165.243.5.37), 30 hops max, 40 byte packets
1 ccw.hongik.ac.kr (203.249.84.242) 0.968 ms 1.083 ms 1.222 ms
2 203.249.84.240 (203.249.84.240) 2.495 ms 2.032 ms 2.121 ms
3 elecom.hongik.ac.kr (203.249.87.4) !N !N !N
위의 예는 3번째 호스트에 보면 '!N'이 보일 것이다.이는 네트웍에 연결할 수 없음을 나타낸다. 즉, elecom.hongik.ac.kr의 라우팅 테이블에 문제가 있어서 패킷을 전달시키지 못하는 것을 말한다.
지금까지 traceroute로 패킷 흐름을 추적하여 네트웍 상태를 점검하였다. 그러나 traceroute를 통해 얻어지는 정보로 판단하는 것은 조심해야 한다. 패킷의 흐름을 조사한 것이기 때문에 마지막으로 해당 호스트를 ping을 해봐서 한번 더 확인하는 것이 실수를 하지 않을 것이다.
4-2-3. netstat로 네트워크 상태 체크
위의 사항들을 점검하여 게이트웨이 혹은 라우터에 이상이 없는데 특이하게도 어떤 시스템 혹은 몇 개의 시스템만이 네트워크가 매우 느린 경우가 있다.이런 경우에는 netstat명령으로 그 원인을 찾아보자.
netstat명령은 현재 시스템에서 네트워크를 사용하는 상황을 나타내 주는 명령이다. 어떤 유저가 어떤 작업을 하고 있는 지는 나오지 않으며, 다만 현재 이 시스템에서 어떤 포트(Port)가 사용되고 있으며 또한 어디에서 어떤 포트로 접속을 해오고 있다는 사실 정도는 알아낼 수 있다.
root@/root> netstat -i
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 loopback localhost 16127 0 16127 0 0 0
hme0 1500 203.249.87.0 elecom 275482 0 46183 0 7508 0
위의 예제에서 '-i' 옵션은 네트워크 카드의 상태를 보여준다.
이 경우 'lo0'가 받은 패킷수는 16127개이며 입력 에러수는 0개,출력 패킷수는 16127개이며 출력에러는 없다(0개).
여기서 입출력의 비가 1%를 넘게 되면 문제가 있다는 것이다. 만약 어떤 한 시스템에서만 이런 결과가 나온다면 그 컴퓨터의 네트워크 카드에 문제가 있다는 것으로 해당 컴퓨터의 네트워크를 교환하는 것이 좋다. 만약 다수의 컴퓨터 시스템에서 이런 결과가 나온다면 시스템 사이의 선로에 문제가 있다는 것이므로 선로를 테스트 한후 교체해야 한다.
충돌(Collis)필드는 패킷의 충돌 횟수를 의미하며 출력 패킷에 대한 충돌회수의 비로 비교하여 1% 이하이면 일반적인 경우이고 3%이상이면 네트워크에 심각한 부하가 걸리고 있다는 것이다. 위의 경우 'hme0'에 부하가 많이 걸리고 있는 것이다.(그러나 위의 경우는 일반적인 경우이다. 'lo0'인 로컬 호스트에 비해 그렇다는 것이다.)
root@/root> netstat -I hme0 5
input hme0 output input (Total) output
packets errs packets errs colls packets errs packets errs colls
274782 0 46002 0 7504 290907 0 62127 0 7504
30 0 1 0 0 30 0 1 0 0
23 0 2 0 0 23 0 2 0 0
29 0 2 0 0 29 0 2 0 0
62 0 2 0 0 62 0 2 0 0
19 0 2 0 0 19 0 2 0 0
21 0 2 0 0 21 0 2 0 0
11 0 2 0 0 11 0 2 0 0
위의 예는 시간 간격을 두고 네트워크의 상태를 체크하는 경우이고 '-I' 옵션이 이런 역할을 수행해주며 'hme0'는 검사하고자 하는 네트워크이며 마지막 5는 5초마다 검사를 하겠다는 뜻이다