[SDN: 소프트웨어 정의 네트워크]
[SDN의 제어평면]
⤷하나의 라우터에서 전통적으로 이루어졌던 라우팅과 포워딩 기능을 제어평면과 데이터평면으로 나누어서 역할을 수행.
- 제어평면 : 라우팅(경로찾기)
- 데이터평면: 포워딩(전달기능)
⤷SDN: Software defined networking
⤷네트워크 계층의 기능 : 라우팅, 포워딩
⤷라우팅과 포워딩이 각 라우터별로 구현이 되었었다. 모듈들이 다 구현이 되어있어야 하기 때문에 데이터 평면과 제어 평면이 한꺼번에 구현이 되어있었다. 그래서 복잡하고 라우터 장비가 비쌌다.
(IP,RIP,IS-IS, OSPF, BGP 정보들 다 가지고 있었음)
⤷다른 네트워크 계층 기능에 대한 middleboxes :방화벽, 로드밸런서, NAT 박스 등
<라우터마다 있는 제어 평면>
⤷모든 라우터별로 기능을 각각 가지고 있다.
⤷각 라우터에 데이터평면과 제어평면이 다 구현되어 있음
⤷각 라우터의 개별 라우팅 알고리즘 구성 요소는 제어 평면에서 서로 상호작용하여 포워
딩 테이블을 계산한다.
⤷각 라우터에 있는 라우팅 알고리즘이 포워딩 테이블을 만들어 준다.
<논리적으로 중앙집중화된 제어 평면>
⤷구별되고 멀리 떨어져 있는 컨트롤러가
각각에 라우터에는 local control agent
(CAs)가 있다.
⤷컨트롤러가 CA를 통해서 각 라우터에게 포워딩 테이블을 계산을 해서 알려준다.
⤷제어평면과 데이터평면이 나눠져있는 구조
⤷이게 SDN
[이러한 논리적으로 중앙집중화된 제어 평면으로 구현된 SDN이 왜 필요한가?]
⤷네트워크 관리가 쉽다.
라우터가 정보를 잘못 세팅하거나 잘못 계산할 수 있는데 이것을 피할 수 있다.
⤷open flow라는 프로토콜 표준을 통해서 같은 출발지와 목적지더라도 내가 원하는 길을 다르게 설정해서 보낼 수 있다.
라우터의 오작동을 막을 수 있고 트래픽 흐름별로 더 유연하게 제어를 가할 수 있다.
⤷라우터에 프로그램을 추가하는 것이 가능하다.
⤷라우터에 테이블 엔트리를 추가함으로써
트래픽 흐름별로 라우팅 경로를 설정, 우선순위, 드롭 등의 다양한 제어가 가능하다.
⤷훨씬 쉽게 중앙집중 프로그램이 가능.
⤷제어 평면이 공개된 매커니즘이다.(표준화)
[SDN 구조의 4가지 특징] 373p
플로우 기반 포워딩
데이터 평면과 제어 평면의 분리
네트워크 제어 기능이 데이터 평면 스위치 외부에 존재
프로그램이 가능한 네트워크
<플로우 기반 포워딩>
⤷SDN으로 제어되는 스위치들에서의 패킷 포워딩은 전송 계층, 네트워크 계층, 또는 링크 계층 헤더의 어떤 값들을 기반으로도 이루어질 수 있다.
⤷오픈 플로우를 사용해서 포워딩이 각 링크 계층의 헤더의 값들을 이용해서 내가 원하는 경로를 가지고 보낼 수 있게 포워딩이 된다.
(전통적인 라우터는 shortest path밖에 안됨)
⤷IP 데이터그램의 포워딩이 온전히 데이터그램의 목적지 주소만을 기반으로 이루어지는 전통적인 라우터 기반 포워딩과는 매우 대조적인 특성이다.
⤷패킷 포워딩 규칙은 스위치의 플로우 테이블에 기록된다.
<데이터 평면과 제어 평면의 분리>
⤷데이터 평면은 네트워크 스위치들로 구성되는데 이들은 상대적으로 단순한 장치들로 자신들의 플로우 테이블 내용을 기반으로 비교와 실행을 수행한다.
⤷제어 평면은 서버와 스위치들의 플로우 테이블을 결정, 관리하는 소프트웨어로 이루어진다.
<네트워크 제어 기능이 데이터 평면 스위치 외부에 존재>
⤷SDN 제어 평면은 당연히 소프트웨어로 구현되어 있지.
⤷전통적인 라우터와 달리 이 소프트웨어는 네트워크 스위치로부터 멀리 떨어진 별도의 서버에서 수행된다.
<프로그램이 가능한 네트워크>
⤷제어 평면에서 수행중인 네트워크 제어 응용을 통해 네트워크를 프로그램 할 수 있다.
⤷예를 들어 라우팅 네트워크 제어 응용은 출발지와 목적지 사이의 종단 간 경로를 결정한다.
⤷어떤 네트워크 응용은 어떤 패킷을 스위치에서 막을지 결정하는 접근 제어를 수행할 수 있다.
⤷또 다른 응용은 서버의 부하를 분산시키는 방식으로 패킷을 포워딩할 수도 있다.
chapter 4에 오픈 플로우 관련 내용이 있음
중용행중용행@@@@
[전통적인 라우터에서 SDN 내용을 메인 프레임에서 PC로의 진화로 설명 가능]
->메인 프레임 : 특화된 하드웨어, 특화된 운영체제, 특화된 어플리케이션 프로그램.
⤷수직적, 독자적으로 동작, 느린 혁신, 소규모 사업
->PC : 마이크로프로세서, 운영체제, 동작하는 어플리케이션
⤷수평적, 개방형 인터페이스, 신속한 혁신, 거대한 산업, 가격도 저렴해짐
[트래픽 엔지니어링]
⤷원하는 라우터 거쳐서 갈 수 있도록 경로를 찾아주는 것.
⤷전통적인 라우터에서는 하기 어려웠음.
->u에서 z로 가길 원한다.
경로는 uvwz.
->x에서 z로 가길 원한다.
경로는 xwyz.
⤷전통적인 라우터는 shortest path이기 때문에 이렇게 갈 수 없다. (링크의 cost를 바꿈으로써 가능.)
⤷uxyz로 동작. xyz로 동작.
⤷근데 이렇게 동작하는게 아니라
SDN에서는 내가 지정한 경로로 보내는 것이 가능하다.
아니면 이렇게 안해도 되는 새로운 알고리즘이 필요하다. 그게 SDN이다.
->u에서 z로 가는데 예를들어
웹트래픽은 uvwz 경로로 보내고
스트리밍트래픽은 uxyz 경로로 보내고 싶어
이렇게 두 경로로 보내고 싶어(로드 밸런싱)
⤷전통적인 라우터에서는 이게 불가능함.
⤷이런 길을 w가 받았을 때 빨간거는 저렇게 보내고 싶고 파란거는 저렇게 보내고 싶어
⤷근데 실제로 전통적인 라우터에서 w는 shortest path는 z로 가려면 무조건 y를 거쳐서 z를 가는 길 밖에 없었다.
[SDN, software defined networking]
⤷제어 평면과 데이터 평면이 나누어져 있다.
⤷일반화된 flow 기반 전달. 플로우 기반으로 포워딩이 가능.
⤷각 라우터에서 데이터 수집을 해서 Remote Controller가 계산을 수행한다. 제어 평면이 외부에서 라우팅 테이블을 만들어서 각 라우터에서 CA를 통해서 포워딩 테이블을 만들어서 전달해 준다.
⤷각 어플리케이션 별로 원하는 대로 제어가 가능하다.
[SDN 제어 평면]
⤷데이터 평면과 제어 평면으로 나누어져 있다.
⤷제어 평면은 레이어가 2개.
⤷각 데이터 평면은 SDN에서 명령을 받아서 제어가 가능한 스위치가 있고 여기 안에는 CA들이 있어서 openflow가 이 안에 돌고 외부에 있는 remote controller가 명령을 주면 그거에 따라 포워딩 역할을 담당한다.
<데이터 평면 스위치>
⤷스위치는 input 포트로 들어온걸 output 포트로.
⤷데이터 평면의 라우터들은 길 찾아주는 포워딩 기능을 담당하기 때문에 스위치라고 표현.
⤷스위치들은 빠르고 간단하고 open flow 기반의 하드웨어에서 포워딩 기능만 담당하는 일반화된 데이터 평면이다.
⤷스위치는 외부에 있는 컨트롤러가 계산을 해준 라우팅 경로에 따라 flow(포워딩) 테이블을 계산해서 보내준다.
⤷컨트롤러가 openflow에게 명령을 줘서 테이블에 엔트리를 추가하거나 삭제하거나 할 수 있다. 사이에 API가 존재한다.
⤷어떤게 제어가 가능하고 불가능한지가 openflow 기반으로 정의된다.
⤷데이터 평면의 컨트롤러와 스위치들은 openflow를 가지고 통신을 하고 이 openflow가 테이블을 기반으로 동작하면서 포워딩이 (액션이) 실행된다.
<SDN 컨트롤러 (네트워크 OS)>
⤷네트워크 장비에서 동작하는 OS.
⤷네트워크 상태 정보를 모으고 유지 관리한다. 그래야 라우팅 경로를 계산할 수 있기 때문.
northbound API : 위쪽에 향하는 API
⤷다양한 어플리케이션이 동작하는데 상위 에있는 어플리케이션과 소통하기 위해서 northbound API가 필요하다.
southbound API : 아래쪽에 향하는 API
⤷SDN 컨트롤러가 각각의 라우터 장비(스위치) 안에 있는 CA 모듈과 통신을 south bound API로 한다.(대표적 open flow.)
⤷이렇게 중앙집중식이 아닌 분산 시스템으로 구현하면 성능이나 확장성, 결함 허용, 견고성에 있어서 더 좋다.
<제어 응용 프로그램>
⤷경로를 찾는거, 누구는 접근되고 누구는 접근 안되고, 로드 밸런싱
⤷이런 기능들이 있고 그걸 어떻게 동작하게 할지는 SDN 컨트롤러가 결정하는 것이다.
⤷이건 이 경로로 보내고 싶어 이런 결정은 여기서 한다. (상위 레벨의 결정)
⤷제 3자의 회사에서 네트워크 어플리케이션을 개발. 라우팅 공급 업체 또는 SDN 컨트롤러와 구분. 묶음 상품이 아니라는 것.
⤷개발하면 SDN 컨트롤러나 스위치가 동작하도록 개발.
=> northbound API나 southbound API가 표준화되서 그거에 맞춰서 동작해야 한다.
네트워크 제어 응용 계층과의 인터페이스 : 컨트롤러는 northbound 인터페이스를 통해서 네트워크 제어 응용들과 상호작용한다.
네트워크 전역 상태 관리 계층 : SDN 제어 평면의 궁극적인 제어 결정
통신 계층 : SDN 컨트롤러와 제어받는 네트워크 장치들 사이의 통신. southbound
[SDN 컨트롤러의 요소]
⤷southbound API : openflow, SNMP
⤷northbound API : RESTful API, intent
⤷네트워크 전역에 분산되고 견고한 상태관리 : 통계, 플로우 테이블, 링크상태 정보, 호스트 정보, 스위치 정보 등
⤷각각에 대한 정보를 기반으로 SDN 컨트롤러가 동작.
⤷아래부터
- 네트워크 제어 앱에 대한 인터페이스 계층
- 네트워크 상태관리 계층
(분산된 데이터베이스)
- 통신 계층
SDN 컨트롤러는 이렇게 큰 3가지 모듈로 이루어져 있다.
[Openflow 프로토콜] 중요@@
⤷southbound API에서 가장 중요하다.
⤷SDN 컨트롤러와 스위치 사이에서 동작한다.
⤷TCP 기반이다.
⤷옵션에 따른 암호화도 가능하다.
-> openflow 메시지는 3가지 타입이 있다.
컨트롤러가 스위치한테 명령.
스위치가 컨트롤러에게 알림.
대칭적으로 묻고 답하는 것. (나머지)
[컨트롤러에서 스위치로 전달되는 중요한 메시지 4가지] (컨트롤러->스위치)
설정 : 컨트롤러가 스위치 설정 파라미터들을 문의하거나 설정할 수 있도록 한다.
상태 수정 : 컨트롤러가 스위치 플로우 테이블의 엔트리를 추가/제거 또는 수정하거나 스위치 포트의 특성을 설정하기 위해 사용된다.
상태 읽기 : 컨트롤러가 스위치 플로우 테이블과 포트로부터 통계 정보와 카운터 값을 얻기 위해 사용한다.
패킷 전송 : 컨트롤러가 제어하는 스위치의 지정된 포트에서 특정 패킷을 내보내기 위해 사용된다. 이 메시지 자체는 페이로드 부분에 보낼 패킷을 포함한다.
[SDN으로 제어되는 스위치에서 컨트롤러로 전달되는 중요한 메시지 3가지]
(스위치->컨트롤러)
1. 플로우 제거 : 컨트롤러에게 어떤 플로우 테이블 엔트리가 시간이 만료되었거나 상 태 수정 메시지를 수신한 결과로 삭제되 었음을 알린다.
2. 포트 상태 : 스위치가 컨트롤러에게 포트 의 상태 변화를 알리기 위해 사용된다.
3. 패킷 전달 : 스위치 포트에 도착한 패킷 중에서 플로우 테이블의 어떤 엔트리와도 일치하지 않는 패킷은 처리를 위해 컨트 롤러에게 전달된다고 했다. 어떤 엔트리 와 일치한 패킷 중에서도 일부는 그에 대 한 작업을 수행하기 위해 컨트롤러에게 보내지기도 한다. 이 메시지는 그러한 패 킷을 컨트롤러에게 보내기 위해 사용한 다.
->다행히 네트워크 operator들은 openflow 메시지를 직접 생성/전송하여 스위치를 프로그래밍하지 않는다. 대신 컨트롤러에서 더 높은 수준의 추상화를 사용한다.
[SDN의 도전과제]
⤷제어 평면을 강화해야 한다.
: 신뢰할 수 있으며 성능 확장이 가능한 안전한 분산 시스템.
- 실패에 대한 견고성 : 제어 평면에 대 해 신뢰할 수 있는 분산 시스템에 대한 활용.
- 신뢰성, 보안이 처음부터 완전하다가 가능? 씹불가능ㅎ
⤷네트워크, 특정한 상황별 요구사항을 충족하는 프로토콜
(실시간, 군사용 이런데에 100% 충족하는지) 해킹이나 이런거에 완전히 안전한가.
⤷인터넷 확장
[SDN: 제어평면과 데이터평면 상호작용]
⤷여기서는 다익스트라 알고리즘이 최단 경로를 결정하기 위해 사용된다.
① s1에서 s2로 가는 빨간 링크가 오류가 있다. 스위치에서 컨트롤러로 포트 정보를 보낸다.
② southbound API인 openflow를 통해서 링크 정보를 컨트롤러가 받는다. 그리고 컨트롤러는 Link-state info 데이터베이스를 업데이트한다.
③ 이렇게 바뀐걸 라우팅 어플리케이션한테 알려준다. 그러면 다익스트라 라우팅 알고리즘은 링크 상태가 바뀐걸 알게된다.
④ 상태가 바뀐걸 알고 다익스트라 라우팅 알고리즘은 다시 작동한다. 토폴로지 정보, 링크상태정보가 필요한데 이 정보를 가져다가 다시 라우팅을 계산한다.
⑤ 링크 상태 라우팅 어플리케이션은 갱신되어야 할 플로우 테이블을 결정하는 플로우 테이블 관리자와 접촉한다.
⑥ 플로우 테이블 관리자는 오픈플로우 프로토콜을 사용하여 링크 상태 변화에 영향을 받는 스위치들을 플로우 테이블을 갱신한다.
(이 예에서는 s1,s2,s4가 해당.)
[OpenDaylight(ODL) 컨트롤러]
⤷SDN 컨트롤러를 구현하고 있는 오픈 프로젝트이다.
⤷northbound API: REST API
⤷southbound API: openflow 1.0, SNMP
⤷SAL: southbound API들하고 사용하기 위한 표준화된 것. 어떤 API들이 와도 사용할 수 있도록. openflow가 오든 SNMP가 오든. 다양한 프로토콜들이 네트워크 장비와 소통하기 위함.
⤷지금 이거는 리튬 버전임. 원소 기호 이름으로 버전을 표현함.
⤷자바 기반으로 구현되어 있음.
[ONOS 컨트롤러] 383p
⤷ODL은 약간 프리하게 배포된건데
ONOS는 돈 많은 쪽에서 SDN 컨트롤러 만드는 프로젝트 같은 거다.
⤷어플리케이션들과 컨트롤러를 완전히 구분함.
⤷northbound 쪽에 intent 프레임워크가 있다. 무엇을 해야된다. 라고 해주는 상위 레벨의 서비스가 추가되었다.
⤷southbound도 더 다양.
⤷분산된 코어를 더 정확히 강조한다.
(서비스 안정성, 복제 성능 확장)
-> 3개의 계층으로 구분된다.
northbound 추상화와 프로토콜
분산 코어 : 서버의 개수가 늘어날수록 서버의 용량도 증가한다.
southbound 추상화와 프로토콜
[인터넷 제어 메시지 프로토콜, ICMP]
⤷Internet Control Message Protocol
⤷명령어 ping, traceroute 이런거.
⤷호스트와 라우터가 서로 간에 네트워크 계층 정보를 주고받기 위해 사용된다.
⤷가장 전형적인 사용 형태: 오류 보고
⤷네트워크의 어떤 지점에서 IP라우터가 HTTP 요청 메시지에 명시된 호스트로 가는 경로를 찾을 수 없었다. 그 라우터가 나에게 오류가 발생했음을 알리기 위해 ICMP 메시지를 만들어서 보낸 것이다.
⤷TCP나 UCP는 IP헤더가 붙어서 전송된다.
⤷ICMP도 IP헤더가 붙어서 전송된다.
⤷그래서 얘도 다중화, 역다중화 함.
⤷ICMP 메시지: 타입, 코드 필드
⤷ICMP 메시지가 처음 생성되도록 한 IP 데이터그램의 헤더(출발지의 헤더, 20바이트)와 첫 8바이트를 가진다.
(송신자가 오류를 발생시킨 패킷을 식별할 수 있도록 하기 위해)
->그렇다고 ICMP 메시지가 오류 상태를 알리기 위해서만 사용되는 것은 아니다.
<ICMP 메시지: 출발지 억제 메시지>
(혼잡제어) 중요행중용행@@@@@
⤷ICMP타입: 4 코드: 0
⤷이 메시지는 실제로 잘 사용되지 않는다.
⤷원래 목적은 혼잡제어를 수행하기 위한 것
⤷목적지가 나 처리 못하겠어 천천히 보내ㅠ
(TCP에도 이거 있음)
⤷즉, 혼잡이 발생한 라우터가 호스트의 전송속도를 늦추도록 ICMP 출발지 억제 메시지를 해당 호스트에 보낸다.
[Traceroute와 ICMP]
⤷Traceroute: 출발지에서 목적지까지 거쳐가는 라우터의, 첫 번째 라우터까지 가는 시간은 얼마, 두 번째 라우터까지는 얼만큼 걸리는지 시간을 체크해주는 명령어.
⤷이 명령어는 ICMP 메시지를 쓰는데 실제로 거기의 전송 계층은 UDP를 쓴다.
⤷출발지와 목적지 사이의 라우터 이름과 주소를 알아내기 위해 출발지의 Traceroute는 평범한 일련의 IP 데이터그램을 목적지에 보낸다.
⤷이 각각의 데이터그램은 없을 것 같은 UDP 포트 번호를 가진 UDP 세그먼트를 운반한다.
⤷TTL=1 -> 첫 번째 라우터까지 갔는데 목적지에 도착했어?
⤷TTL을 1로 세팅해서 보냈는데 첫 번째 라우터에서 TTL이 만료되었음을 알린다. 이걸 3번씩 한다. (3 probes)
⤷라우터는 이 데이터그램을 폐기하고
(타입 11, 코드 0) 경고메시지를 출발지에 알림. 이 메시지는 라우터의 이름과 IP 주소를 포함한다.
⤷이 ICMP 메시지가 출발지에 도착하면, 출발지는 타이머로부터 왕복시간(RTT), ICMP 메시지로부터, 첫 번째 라우터의 주소와 이름을 획득한다.
⤷그다음 TTL=2로 설정하면 2번째 라우터가고 TTL이 0이 되면서 만료되었다는 메시지를 다시 출발지로 보냄. (TTL값을 하나씩 증가시키면서 측정하는 것이다.)
⤷이게 갔다가 오는 시간인 RTT를 측정한다. 이걸 3번씩 한다. 왜?
-> 이 시간을 평균을 내면 각 라우터 별까지 갔다 오는 시간을 알게 되는 것이다.
<어떻게 동작할까?>
⤷출발할 때 UDP의 포트번호를 잘 안쓰일 것같은 번호로 한다.
⤷목적지는 포트 도달 불가능 ICMP 메시지(타입 3, 코드 3)를 출발지에 보낸다.
(목적지 왔는데 나 그런 포트 안써)
⤷출발지가 이 ICMP 메시지를 받게 되면 추가적인 탐색 패킷을 보낼 필요가 없음을 알게 된다. (아하 목적지에 도착했구나)
⤷그러고 Traceroute 메시지를 멈춘다.
⤷이런 방식으로 Traceroute가 ICMP를 기반으로 동작한다.
⤷같은 TTL을 가진 패킷을 3개씩 보내기 때문에 Traceroute 결과는 각 TTL에 대해 3개의 결과를 제공한다.
[네트워크 관리와 SNMP]
⤷Simple Network Management Protocol
⤷어플리케이션 계층 프로토콜이다.
⤷전송 계층으로는 UDP 사용.
⤷네트워크 관리는 모니터링, 잘 동작하는 지 지켜보고 문제가 있으면 제어하는게 핵심 기능이다.
⤷네트워크 관리를 하기 위한 프로토콜이 SNMP이다.
⤷제품들이 막 만들어 지면서 산업체 주도적으로 표준이 이루어졌다.
⤷꼭 필요하게 전달되면 그 메시지를 여러번 보내는 방법으로 구현됨.
[네트워크 관리]
⤷autonomous system (=network)
⤷하드웨어가 소프트웨어가 약 천 개 이상 연결된 것
=> 정의: 네트워크 관리는 적정한 비용으로 실시간, 운용성능, 서비스 품질 등의 요구사항을 만족시키기 위하여 네트워크와 구성요소 자원들을 감시, 테스트, 폴링, 설정, 분석, 평가, 제어하는 하드웨어, 소프트웨어, 인간요소 등을 배치하고, 통합, 조정하는 것이다.
[네트워크 관리의 구조]
⤷managed device : 관리하고 싶은 장비
⤷이 장비에는 에이전트가 있어야 한다.
⤷에이전트는 관리하고 싶은 대상인 데이터를 관리한다.
⤷managing entity(관리 서버)가 내가 관리하고자 하는 대상들의 데이터를 모니터하고 제어한다.
⤷관리자가 매니저, 관리 대상이 에이전트
⤷각 장비들은 관리되는 객체들이 있다.
이 관리되는 데이터들을 밉
(MIB, Management Information Base)
라고 한다.
⤷장비마다 데이터가 다른데 각 역할에 특화된 MIB이 존재한다.
⤷여기서 사용되는 네트워크 관리 프로토콜이 SNMP 프로토콜이다.
[SNMP 프로토콜]
⤷MIB 정보와 명령어를 운반하는 역할.
⤷관리 서버와 그 관리 서버를 대표하여 실행되고 있는 에이전트 사이에서 네트워크 관리 제어 및 정보 메시지를 전달하기 위해 사용된다.
<요청/응답 모드>
⤷SNMP의 가장 흔한 사용 형태
⤷여기서 SNMP 관리 서버는 에이전트에게 요청을 보내고 이를 받은 SNMP 에이전트는 이를 수행한 후 요청에 대한 응답을 보낸다.
⤷일반적으로 요청은 관리당하는 장치와 관련된 MIB 객체 값들을 검색 또는 수정을 하기 위해 이용된다.
=> 매니저가 먼저 요청을 시작!
에이전트가 대답!
<트랩 모드>
⤷에이전트가 요구받지 않았더라도 트랩 메시지라는 이름의 메시지를 관리 서버에게 전송하는 것이다.
⤷트랩 메시지들은 관리 서버들에게 MIB 객체 값들을 변화시킨 예외 상황 (ex. 링크 인터페이스의 활성/비활성)의 발생을 통지하기 위해 이용된다.
=> 에이전트가 먼저 요청!
[SNMP 프로토콜의 메시지 타입]
ppt는 SNMP 버전 1 메시지이다. 책388p
⤷GetRequest
⤷GetNextRequest
⤷SetRequest: IP주소 값을 이거에서 이걸로 바꿔라. 포트 on/off를 바꿔라.
⤷Response
⤷Trap: 트랩 모드
⤷GetBulkRequest
⤷InformRequest
⤷버전 1보다 버전 2는 성능적인 부분을 향상시킨 것.
⤷SNMP의 요청-응답 특성을 감안할 때, 비록 SNMP PDU들이 많은 다른 전송 프로토콜들에 의해 운반될 수 있기는 하지만 일반적으로는 UDP 데이터그램의 페이로드 부분에 실린다는 것을 주목할 필요가 있다.
[SNMP 프로토콜의 메시지 포맷]
⤷PDU 타입이 4면 트랩 메시지이다.
PDU 타입이 0~3이면 Get/Set이다.
(GetRequest, GetNextRequest,
GetBulkRequest, SetRequest)
⤷Get/Set 은 161번
트랩은 162번 포트 번호를 사용한다.
⤷요청 ID는 필드는 관리 서버가 요청 또는 응답의 분실을 검출하는 데 이용될 수 있다.
<5장 요약>
⤷네트워크의 제어 평면
- 라우터별 제어 (전통적)
논리적으로 분산된 제어 (SDN)
⤷전통적인 라우팅 알고리즘
OSPF(intra), BGP(inter)
⤷SDN 컨트롤러
ODL, ONOS
⤷ICMP
⤷네트워크 관리
SNMP