[Network] Network Layer(Control Plane) 4 - ICMP와 SNMP

chxghee·2024년 12월 7일

ICMP (Internet Control Message Protocol)

인터넷 제어 메시지 프로토콜로, 호스트나 라우터가 에러 레포팅 시 시용하는 메세지 프로토콜이다

예를 들어 IPv6에서는 fagmentation을 진행하지 않는데,
라우터에 MTU크기 이상의 패킷이 오면 Drop을 하고 sender에 에러 메세지를 ICMP를 통해 레포팅 한다.

  • IP레이어 위에서 동작한다.
    (IP datagram의 페이로드에 캡슐화 되어 전달된다.)

  • ICMP 메시지는 타입(type)과 코드(code) 필드가 있고,
    ICMP 메시지의 발생 원인이 된 IP 데이터그램의 헤더와 첫 8바이트를 갖는다.

이는 송신자가 오류를 발생시킨 패킷을 알 수 있도록 하기 위해서이다.

ICMP 메시지 타입

Traceroute 프로그램

송신자는 Traceroute를 이용하여 각 라우터들 혹은 수신자까지의 RTT를 계산할 수 있다.
(경로상에 있는 라우터의 정보와 개수또한 알 수 있다.)

출발지와 목적지 사이의 라우터 이름과 주소를 알아내기 위해
출발지의 Traceroute는 일련의 UDP 데이터그램을 목적지에 보낸다.

이때 각 데이터그램의 TTL을 다르게 설정하여 TTL만료시 패킷이 드랍되면 ICMP 경고 메세지를 받을수 있도록 한다.

동작

  1. 송신자는 데이터그램에 TTL을 설정하여 보낸다.
    (TTL 값은 첫 번째 데이터그램이 1, 두 번째는 2, 세 번째는 3, 이런 식이다.)

  2. 송신자는 각 데이터그램에 대해 타이머를 작동시킨다.

  3. n번째 데이터그램이 n번째 라우터에 도착하면 해당 라우터는 데이터그램의 TTL이 방금 만료되었음을 알게 된다.

  4. IP 프로토콜 규칙에 따라 라우터는 데이터그램을 폐기하고 ICMP 경고 메시지(타입 11, 코드 0)를 출발지에 보낸다.

도착한 ICMP 메세지로부터 얻을 수 있는 정보

  • 타이머로부터 왕복 시간(round-trip time, RTT),
  • ICMP 메시지로부터 n번째 라우터의 주소와 이름을 획득한다.

Q. Traceroute 출발지는 UDP 세그먼트 전송을 언제 멈춰야 하는지 어떻게 알까?

출발지가 자신이 보내는 각 데이터그램마다 차례로 TTL을 1씩 증가시키기 때문에
이들 데이터그램 중 하나는 결국 목적지 호스트에 도착하게 될 것이다.

이 데이터그램은 없을 것 같은 UDP 포트 번호를 가진 UDP 세그먼트를 포함하고 있으므로,
(일부로 목적지에서 에러가 나도록 포트 번호를 이상한 값으로 보낸다)
목적지 호스트는 포트 도달 불가능 ICMP 메시지(타입 3, 코드 3)를 출발지에 보낸다.

출발지 호스트가 이 ICMP 메시지를 받게 되면 추가적인 탐색 패킷을 보낼 필요가 없음을 알게 된다.



네트워크 management

SDN방식에서는 컨트롤러가 각 라우터를 메니지먼트가 가능했다.

하지만 SDN방식 이전에서, 각각의 네트워크(ISP)의 컴포넌트들의 관리가 필요할 때 어떻게 관리를 했을까?
(설정정보, 통계분석, 에러탐지)

네트워크 관리 구성요소

  1. Managing Server

    관리를 수행하기 위해 각 네트워크 디바이스에(라우터,스위치..) 쿼리를 보내 상태정보를 확인하고 분석한다.

  1. 네트워크 관리 프로토콜

    관리 서버와 각 디바이스의 에이전트끼리의 메세지의 포멧과 필드값을 정의한다.

  1. Managed Device

    관리 대상인 디바이스. 각 디바이스들은 쿼리가 오면, 혹은 에러가 나면 자신의 상태정보와 동작정보를 보낸다.

  2. data

    각 디바이스는 상태정보와 동작정보, 장치의 통계 데이터를 갖는다.

  • 상태정보 - IP주소, 전송속도... 등등
  • 동작정보 - LS에서 주변 라우터의 정보를 저장한 table과 같은 동작에 관련한 데이터

서버가 요청을 하고 각 디바이스가 응답하는 형태로 이루어 진다.
또한 에러가 발생할 경우 각 디바이스는 서버의 요청없이도 메시지를 보낼 수 있다.

디바이스 관리 방식

3가지가 존재한다.

  1. CLI(커멘드 라인 인터페이스)
    명령을 통해 각 디바이스에 직접 접근하여 설정 및 쿼리를 수행한다.
    (전문화된 관리자가 필요)
    ➡️ 하나하나 관리하기 때문에 힘듬

  2. SNMP/MIB
    SNMP - 서버 디바이스 사이 메세지 교환 위한 프로토콜.
    MIB - 각 디바이스의 data를 뜻함.

  3. NETCONF/YANG
    NETCONF - 서버 디바이스 사이 메세지 교환 위한 프로토콜.
    YANG - 설정 및 동작 데이터를 모델링하는 데 사용되는 데이터 모델링 언어
    SNMP/MIB 방식보다 더 대규모의 관리를 할 수 있다.
    (한번에 어려 디바이스 연결하여 데이터를 가져올 수 있음)

SNMP 프로토콜

UDP를 이용하여 메세지를 주고 받는다.

1.MIB(메세지)를 주고받는 두가지의 상황이 존재한다.

요청-응답 모드 / 트랩 메세지 가 있다.

2. 메세지 type

3. 메세지 포맷

MIB (Management Information Base)

각 디바이스는 자신의 동작정보와 설정정보들을 MIB로 가지고 있다.

SMI- data를 정의위한 언어이다. 즉, MIB 객체를 정의하는 일반적인 규칙들의 모음이다.

MIB는 다음과 같이 데이터를 가지고 있다.



NETCONF

SNMP보다 더 대규모의 관리가 가능한 프로토콜

SNMP와 거의 똑같지만, 몇가지 다른 점이 있다.

SNMP와 다른 점

  • TCP로 동작한다.(때문에 reliable transport가능)

  • 원격 프로시너 호출(remote procedure call, RPC) 패러다임
    ➡️ 메세지를 XML로 인코딩 하여 보낸다.
    ➡️ 때문에 TCP상의 TLS 프로토콜과 같은 안전한 연결 지향 세션을 통해 관리 서버와 피관리 장치 사이에서 교환된다.

  • atomic-commit
    모든 설정 변경이 성공해야만 커밋(commit)이 완료되며, 하나라도 실패하면 모든 변경 작업이 롤백(rollback)된다

  • 여러개 디바이스를 같이 관리 설정 할 수 있다.

다음과 같이 메세지를 주고 받는다.

RPC 메세지 예시


YANG

데이터를 모델링 하기 위한 언어이며(like SMI),
NETCONF와 호환된다.

profile
다 같이 화이팅! 🙋‍♂️

0개의 댓글