[ Network Tip ] Network Error, Layer 점검 Tip

■ Network Error, Layer 점검 Tip

(1) 물리층에서의 Trouble

① 케이블의 이상

② Network Interface Card(NIC)와 Transceiver 등의 하드웨어 장애

③ 물리적 접속 규격의 초과

▶ 케이블 이상

케이블의 장애에는 단선과 쇼트가 있다. Ethernet 에서 단선되면 신호의 전압이 -4V 이하로 떨어지

기 때문에 Collision(충돌)과 같은 상황이 발생한다. 케이블이 쇼트되면 Carrier loss 되고, 모든 노

드가 데이터를 송신할 수 없게 된다. 이런 상황의 경우에는 전용 케이블 테스터를 사용한다.

▶ 하드웨어 장애

NIC와 Transceiver의 장애는 일반적으로 터미널 한 대의 통신 불능으로 나타나지만, 가끔 드물게 모

든 노드가 사용할 수 없게 되기도 한다. 이것은 자버링 노드라고 부르는 Trouble로서 NIC와

Transceiver가 의미를 알 수 없는 데이터를 연속적으로 송신하기 때문에 발생한다. 자버링 노드의

구분은 어렵다. 하나 하나 노드의 전원을 끊는 방법 이외에 다른 방법이 없다.

▶ 물리적 접속 규격 초과

물리적 접속 규격의 초과에 의한 문제는 최대 케이블 길이의 규격 위반에 의한 전송 지연이 있다.

Ethernet에서는 각 노드가 데이터를 송신할 때 캐리어를 확인하고 Collision(충돌)을 피한다. 전송 지

연 상태에서는 Collision 이 증대한다. 만일 Analyzer로 Collision과 rent error (60Byte 미만의 쇼트

패킷)가 자주 일어나는 것을 확인했다면 그것은 전송 지연이 원인이다. 전송 지연은 네트워크를 분할

하는 등 네트워크 구성을 변경하면 해결된다

 

(2) 데이터 링크층에서의 Trouble

각층에서 주고 받는 데이터의 묶음을 일반적으로 Packet 이라고 부르지만, 

데이터 링크층의 패킷에 대해서는 특히 Frame」이라는 말을 사용한다. 

Ethernet의 프레임 길이는 60Byte 에서 1,514Byte 까지이며 

데이터내용에 따라서 변한다.

▶ 프레임 내용의 분석

데이터 링크층의 프레임에는 Destination Address 와 Source Address, 기 상위층의 타입(Type),

데이터 길이 등의 정보가 부가되며 이것들을 합쳐서 프레임의 「Header」라고 말한다.

프레임의 내용을 처음부터 보면 데이터 링크층의 헤더(MAC-PDU,LLC-PDU,SNAP-PDU), 네트워크

층의 헤더, Transport층의 헤더로 이어지며 끝으로 상위계층의 Application Data가 이어진다.

Analyzer을 사용하면 이러한 프레임 내용을 층별로 분석할 수 있다

▶ 프레임 길이에 따라 throughput 의 가변

데이터 링크층에서의 장애는 주로 트래픽에 관련된 것이다. Ethernet은 10 Mbps의 전송이 가능한

LAN 규격이지만 실제의 throughput( 단위시간당 처리능력)은 프레임의 길이에 따라 좌우된다.

1,514 Byte 의 프레임으로는 최대 약 9 Mbps, 60 Byte의 프레임에서는 3 Mbps가 한계이다.

프레임의 길이에 따라 네트워크의 전송 효율이 변하고 트래픽의 포화점이 달라진다. 한 예로 같은 도

로 환경에서 10명의 승객을 각각 버스와 승용차로 운송한다고 할 때, 버스가 한꺼번에 운송할 수 있

어서 효율이좋은것과 비슷하다.

프레임 길이의 평균이 60 Byte면 약 25%의 사용률로, 1,514 Byte면 약 85%의 사용률로 꽉 차 버린

다. 이 포화점을 넘으면 Collision 이 자주 일어나고 네트워크가 다운된다.

▶ 프레임 간격이 좁은 것도 장애 원인의 하나

프레임 간격도 데이터 링크층의 장애 원인이 된다. 프레임 간격이란 고속도로에서의 자동차와 자동

차사이의 거리에 비유할

수 있다. 가령 고속도로에서 정체되면 인터체인지로부터 진입하는 자동차는 급브레이크를 밟게 되고

타이밍이 맞지 않으면

충돌한다. 이와같이 Network 에서도 프레임 간격이 좁고 연속적으로 Collision 이 발생하는 상황으

로 이어지면 각 노드는

비정상 종료 상태가 되고 터미널이 움직이지 않게 된다. 통상 Collision이 16회 연속되면 데이터 링크

층에서 종료동작되고,

강제 종료 상태가 된다. 이 같은 데이터 링크층의 장애에 대해서 Analyzer의 통계 정보를 항상 보고

하도록 하고 평소 운용

상황을 파악하도록 해야 한다. 서버가 정기적으로 송신하는 Keep Alive 신호가 장애의 원인이 되고

있는 경우에는 그 타이머

값을 길게 설정해 보면 좋다. 만일 많은 ACK를 송신하는 프로토콜을 채용하고 있다면 그 세그먼트를

분리함으로써 문제를

회피할 수 있다.

(3) 네트워크층에서의 Trouble

네트워크층에서의 Trouble에는 Router의 동작에 기인하는 문제, 

Broadcast storm, IP 어드레스의 중복 등이 있다.

이들 Trouble도 Analyzer로 데이터를 분석함으로써 검출할 수 있다.

 

▶ Fragmenta tion Trouble

Router의 동작에 기인하는 장애의 예로는 Fragment가 있다. Router는 상위층의 데이터가 IP 패킷에

못들어가는 경우, 그것을 몇 개의 패킷으로 나눈다. 이러한 것을 Fragmentation 이라 하고 분할된 하

나 하나의 패킷을 fragment 라고 부른다.

문제가 되는 것은 데이터가 커서 Fragmentation 이 필요하지만 그 데이터에 분할 불가 (DF: Don't

Fragment)라고 하는 비트

신호가 나와 있는 경우이다. 이럴 때에 통상 ICMP(Internet Control Message Protocol)라고 부르는

TCP/IP의 에러 통지용

프로토콜을 사용해서 Router가 「분류하지 않으면 송신이 안됨」이라는 메시지를 Source

address로 보내고 정상적인 통신을 유지한다. 그런데 TCP/IP 소프트웨어 중에는 ICMP를 지원하지

않는 것이 있다. 이 경우 에러 통지가 되지 않기 때문에 Fragmentation 에서 Trouble이 발생한다. 동

작 상황을 Analyzer으로 확인하는 것이 좋다.

▶ Broadca s t s torm의 발생

Broadcast 란 모든 노드로 일제히 동시에 알리는 것이다. 이 메시지가 흐르면 각 노드는 현재의 작

업을 중단하고 Broadcast 처리를 우선 실행해야 한다.

Broadcast 가 자주 일어나면 각 노드에서의 처리가 실행되지 않아 네트워크 전체가 다운되는 장애

가 일어난다.

이 장애를 「Broadcast storm」이라고 말한다. Broadcast storm은 프로토콜의 버전 차이에 의해

서 발생하는 경우가 많다.

TCP/IP에서는 4.3 BSD와 4.2 BSD의 혼재, Appletalk Phase I과 Phase II의 혼재 등이 그 예이다.

또한 Router가 정기적으로 송신하는 Routing Protocol (예, RIP)의 정보가 그 프로토콜을 지원하지

않는 시스템에 의해서

잘못 인식되었기 때문에 Broadcast storm이 발생할 수도 있다.

Broadcast 의 패킷은 특정하게 보낼 곳의 어드레스를 가지고 있다. 때문에 네트워크 장애가

Broadcast 에 의한 것인지 아닌지는 Analyzer으로 각 데이터의 어드레스를 조사하면 쉽게 알 수 있

다. 

 

▶ IP 어드레스의 중복

IP 어드레스가 중복되면 그 중복된 노드는 통신이 안 된다. Broadcast storm에 이르지는 않지만 서

버로부터 정기적으로

어드레스를 조사하는 프로토콜(ARP: Address Resolution Protocol)이 흘러나가고 트래픽이 증가

한다.

4.3 BSD에서는 IP 어드레스의 중복을 발견하면 「보낼 곳에 보낼 수가 없다」라고 하는 ICMP의 메

시지를 송신한 곳으로 보낸다. 이 메시지를 포함한 프레임 바로 직전 프레임의 IP 어드레스에 대

해Analyzer로 필터를 걸어서 IP어드레스가 중복한 노드를 발견할 수 있다.

▶ TTL의 값을 조정한다

Route를 복수 접속하고 있는 네트워크의 경우, 패킷을 도중에서 분실하는 경우가 있다. 패킷의 생존

시간(TTL: Time To Live)을 짧게 설정해 둔 것이 문제를 일으킨 원인이다.

이를테면 TTL의 값이 5라면 그 패킷은 5초간만 존재한다. 하나의 Router 를 통과하는 데 1초가 걸린

다면 4개 이상의 Router는통과가 되지 않는다. 이 같은 장애는 TTL 값을 적당히 변경함으로써 해결

할 수 있다.

(4) Transport 층에서의 Trouble

Transport층에서는 네트워크층에서 분할된 데이터를 다시 구성하거나 

흐름의 제어와 재송신 제어를 실행한다.

또한 port라고 부르는 논리 채널을 프로세스별로 복수로 갖는다. 

서버와 호스트가 1대로서 복수의노드를 동시에 제어할 수 있는 것은 이 때문이다. 

이런 Transport층에서의 데이터의 주고받음도 Analyzer을 사용하여 분석할 수 있다.

▶ Window Size의 Tuning

「파일 전송 속도가 너무 늦다」, 「프린트아웃에 시간이 많이 걸린다」 등의 현상은 Transport층의

Tuning 이 나쁜 경우에

일어난다.

Transport층의 프로토콜에서는 수신이 되는 패킷 수를 Window Size에 의해서 상대에게 알린다. 어

떤 노드의 Window Size가 1인 경우, 그 노드에 대해서는 한번에 1 Packet 분의 데이터만 전송된다.

그렇지 않으면 Overflow되고 만다.

Broadcast 에 의한 것인지 아닌지는 Analyzer으로 각 데이터의 어드레스를 조사하면 쉽게 알 수 있

다.

▶ IP 어드레스의 중복

IP 어드레스가 중복되면 그 중복된 노드는 통신이 안 된다. Broadcast storm에 이르지는 않지만 서

버로부터 정기적으로

어드레스를 조사하는 프로토콜(ARP: Address Resolution Protocol)이 흘러나가고 트래픽이 증가

한다.

4.3 BSD에서는 IP 어드레스의 중복을 발견하면 「보낼 곳에 보낼 수가 없다」라고 하는 ICMP의 메

시지를 송신한 곳으로 보낸다. 이 메시지를 포함한 프레임 바로 직전 프레임의 IP 어드레스에 대

해Analyzer로 필터를 걸어서 IP어드레스가 중복한 노드를 발견할 수 있다.

▶ TTL의 값을 조정한다

Route를 복수 접속하고 있는 네트워크의 경우, 패킷을 도중에서 분실하는 경우가 있다. 패킷의 생존

시간(TTL: Time To Live)을 짧게 설정해 둔 것이 문제를 일으킨 원인이다.

이를테면 TTL의 값이 5라면 그 패킷은 5초간만 존재한다. 하나의 Router 를 통과하는 데 1초가 걸린

다면 4개 이상의 Router는통과가 되지 않는다. 이 같은 장애는 TTL 값을 적당히 변경함으로써 해결

할 수 있다.

(4) Transport 층에서의 Trouble

Transport층에서는 네트워크층에서 분할된 데이터를 다시 구성하거나 흐름의 제어와 재송신 제어를

실행한다.

또한 port라고 부르는 논리 채널을 프로세스별로 복수로 갖는다. 서버와 호스트가 1대로서 복수의

노드를 동시에 제어할 수

있는 것은 이 때문이다. 이런 Transport층에서의 데이터의 주고받음도 Analyzer을 사용하여 분석

할 수 있다.

▶ Window Size의 Tuning

「파일 전송 속도가 너무 늦다」, 「프린트아웃에 시간이 많이 걸린다」 등의 현상은 Transport층의

Tuning 이 나쁜 경우에

일어난다.

Transport층의 프로토콜에서는 수신이 되는 패킷 수를 Window Size에 의해서 상대에게 알린다. 어

떤 노드의 Window Size가 1인 경우, 그 노드에 대해서는 한번에 1 Packet 분의 데이터만 전송된다.

그렇지 않으면 Overflow되고 만다.

 

따라서 Window Size를 크게 하면 한꺼번에 복수의 패킷을 송수신할 수 있게 되고 전송 효율이 향상

된다.

파일 전송 등의 대량 데이터를 송신하는 경우에는 당연히 윈도우 사이즈를 크게 잡아두어야 한다.

반면 윈도우 사이즈를 너무 크게 해서도 안 된다. 아무리 기다려도 수신 응답이 돌아오지 않는 경우

가 있다. Telenet같이 노드로부터의 데이터가 적은 경우에는 호스트쪽의 Window Size를 작게 하는

등 애플리케이션에 따라 적당히 변경해야 한다.

윈도우 사이즈의 제어에서 한 가지 주의해야 할 것은 메이커에 따라 제어의 순서가 다른 경우가 있다

는 것이다.

오버플로우를 피하기 위하여 윈도우 사이즈를 0으로 해서 데이터의 송신을 멈추게 하도록 지시하는

일이 있으나, TCP/IP의 소프트웨어에 따라서는 이 상황을 판단할 수 없는 제품이 있다. 이 점을 무시

하고 파일 전송을 하면 오버플로우가 발생하고 노드의 갑작스런 정지와 호스트의 다운이 일어난다.

이런 Window Size의 상황은 Analyzer로 데이터의 주고받음을 분석하면 파악할 수 있다. 그 결과로

부터 적절한 튜닝을 하면 된다. 초기치인 상태에서 LAN을 실행하여 생각했던 것만큼의 효율을 올리

지 못해 고민하는 사용자가 많지만, 이럴 때에 Analyzer을 사용하면 효과가 아주 크게 나타난다.

▶ 타이머 값을 바꿔서 다시 발신하는 일을 줄인다

그 밖에 Transport층에서는 패킷을 재발신하는 빈도도 네트워크의 전송 효율을 좌우한다. 네트워크

의 각 노드는 재전송

타이머를 가지고 있으며, 이 타이머 값을 넘어서 수신 응답이 되돌아 오지 않으면 다시 한번 패킷을

보낸다.

몇 개의 Router에 걸쳐 있는 경우에는 당연히 같은 네트워크 내에서 실행하는 통신보다도 패킷을 주

고 받는데 시간이 더 많이 걸린다. 때문에 타이머 값이 너무 짧으면 패킷의 재송을 자주 하게 되고

네트워크의 전송 효율도 떨어진다.