5장 네트워크 계층(2)

(본 글은 “컴퓨터 네트워킹 하향식 접근” 도서 및 네트워크 프로그래밍 수업 내용을 정리한 글 입니다.)

5.3 SDN

5.3.1 개요

과거 인터넷 네트워크 계층
- 스위칭 하드웨어 기반
- 자체 라우터 운영체제 상에서 프로토콜 수행
- 각 장비마다 고유의 middleBoxe를 포함
SDN
- 외부에 컨트롤러(외부 제어기)가 존재
- 외부 제어가는 각 라우터의 제어 에이전트와 상호작용을 하며 테이블 작성
- 장점
  - 네트워크 관리가 쉽다 - 테이블 기반 전달은 프로그래밍 라우터 허용
  - 중앙집중식 프로그래밍이 분산형보다 구현하기 쉽다
  - 제어 평면의 개방형구현을 통해 다양한 애플리케이션 제공 가능
1. 일반 흐름기반 전달(각 라우터들은 flowTable을 보고 경로를 탐색)
2. 제어와 데이터평면 분리
3. 데이터 평면 외부에 컨트롤 평면 기능수행(flowTable 관리)
4. 프로그램 가능한 제어 응용(컨트롤러와 api를 주고받으며 컨트롤러 관리)

메인프레임의 진화에 대한 비유를 통해 알아보는 SDN 장점

자신만의 하드웨어를 만들고 그에 맞는 운영체제를 개발

특정 회사에 의존적이고 폐쇄적이다

수직적 통합

독점적 , 소규모 산업 & 느린 혁신

각 부품을 회사에서 구입하고 선택적으로 사용함

수평적

개방형 인터페이스

거대 산업 & 신속한 혁신

[교통공학 측면에서 바라본 전통적 라우팅의 한계점]

만약 기존의 경로가 아니라다른 경로로 전달되기를 원한다면?

전통적 라우팅 : 링크 가중치를 다시 정의하여 재계산을 해야 한다 (쉽지 않고 비효율적)

만약 두 경로로 트래픽을 분할하고 싶다면?

전통적 라우팅 : 불가능

만약 경로에 따라 트래픽을 분할하고 싶다면? (A에서 왔으면 B로, C에서 왔으면 D로 가게 하고싶다)

전통적 라우팅 : 불가능

5.3.2 데이터 평면 스위치

하드웨어로 일반 데이터 평면 전달
컨트롤러에 의해 계산된 스위치 흐름 테이블을 가지고 있다
테이블 기반 스위치 제어를 위한 API, 프로토콜이 존재한다
- OpenFlow

5.3.3 SDN컨트롤러

라우터 외부에 존재
네트워크 상태 정보 유지 (각 라우터가 어떤식으로 연결되어있는지)
NorthboundAPI를 통해 네트워크 제어 응용프로그램과 상호작용
- api를 제공해 어플리케이션에 필요한 데이터 자료구조등을 컨트롤
SouthboundAPI를 통해 네트워크 스위치와 상호작용
- 계산된 결과를 스위치에 알리고 컨트롤
일반적으로 중앙집중식이지만 확장성, 견고성을 위해 분산 시스템으로 구현

5.3.4 네트워크 제어 앱

제어의 두뇌역할 , 컨트롤러에서 제공하는 API를 사용해 제어기능 구현
번들되지 않는다(SDN컨트롤러와 같은 회사 제품이지 않아도 된다)

5.3.5 컨트롤러 구성요소

하부
- 하드웨어 스위치와 정보를 주고받고 제어
내부
- Link-state-info , ..flow tables
상단 : 인터페이스 api , 자료구조 정보 포함
- networkGraph, Restful API

5.3.6 OpenFlow 프로토콜

제어기와 스위치 사이에서 동작
메세지 전달에 TCP사용
종류
- Controller-to-switch
- Switch-to-controller

5.3.6.1 Controller-to-switch

설정 : 컨트롤러가 스위치 구성 파라메터쿼리를 설정
상태 수정 : OpenFlow 테이블의 흐름항목을 수정,삭제,추가
상태 읽기 : 통계정보와 카운터 값을 읽는다
패킷 전송 : 특정 스위치 포트에 패킷을 전송한다

5.3.6.2 Switch-to-Controller

패킷전달 : 플로우 테이블 항목이 일치하지 않는 등 필요에 따라 컨트롤러에게 패킷 전송
플로우 제거 : 플로우 테이블 항목이 만료 & 상태 수정 메세지의 결과로 삭제했음을 응답
포트 상태 : 특정 링크의 문제나 변화가 생기면 포트 상태의 변화를 알림

상호작용의 예시

특정 링크에 오류가 발생 → 스위치에서 “포트 상태”메세지를 사용해 컨트롤러에게 알린다
컨트롤러에서 수신 후 링크 상태 정보 수정 (link-state-info)
링크가 변하면 자동적으로 다익스트라 알고리즘이 수행
네트워크 제어 앱에서 컨트롤러의 그래프정보, 링크상태등에접근해서 새로운 경로를 계산
새로운 Flow Table을 생성
컨트롤러는 OpenFlow를 통해 업데이트가 필요한 스위치에 새 테이블 설치

5.4 네트워크 관리

적절한 비용으로 요구사항을 만족시키기 위해 네트워크 구성요소를 감시, 분석, 제어하는 SW, HW를 조정하는 것

5.4.1 네트워크 서버의 관리요소

관리서버 : 관리자와 상호 동작하는 애플리케이션 (그래픽, 통계자료를 한눈에 볼 수 있는 시스템)
피관리 장치 : 관리대상이 되는 장비
Data : 피관리 장치의 내부 데이터들 (설정데이터, 동작 데이터..)
네트워크 관리 프로토콜 : 서버와 장치사이에서 데이터를 주고받는 프로토콜

5.4.2 관리 접근 방법

CLI (명령줄 인터페이스)
- console, telnet을 통해 직접 명령하는 것
SNMP/MIB
- MIB : 피관리장치가 가지는 DB
- SNMP : 데이터를 주고받는 프로토콜
- SMI : 데이터 모델링 언어
NETCONF/YANG
- YANG : 데이터 모델링 언어
- NETCONF : 프로토콜
- 최근에 뜨고있고 SNMP에 비해 전체적관점을 가지므로 대규모에서 효과적

5.4.2.1 SNMP

명령어 전달 방법

request/response : 관리쪽의 요청 → 피장치의 응답을 일정주기로 반복한다
Trap Mode : 피관리 장치에 특정 이벤트가 발생하면 메세지를 관리측에 보낸다

메세지 타입

GetRequest : 하나 또는 그 이상의 MIB객체 값 가져옴

GetNextRequest : 다음 MIB 객체 값 가져옴

GetBulkRequest : 큰 블록 단위의 데이터를 가져온다

SetRequest : MIB객체의 값 설정

Response : 위 메세지의 응답

Trap : 예외적인 이벤트 발생을 알림

5.4.2.2 MIB

MIB : 피관리 장치의 동작 상태 데이터와 설정 데이터

각 MIB객체들은 MIB모듈로 합쳐진다
SMI 데이터 정의 언어를 사용한다 (Netconf의 Yang같은 것)
MIB아이디, 이름과 같은 정보가 모두 문서로 정의되어있다

5.4.3 NetConf

관리 서버와 피관리 네트워크 장치 사이에서 동작
- 설정데이터의 검색, 설정, 수정 및 동작 데이터의 통계 질의
- 생성된 알림기능을 구독하기 위한 메세지 전송기능 (SNMP의 trap같이)
CLI는 장비를 하나하나 연결 , SNMP는 모니터링 중심이였다면
모니터링 뿐 아니라 대량의 장비 설정도 고려하자는 취지에서 등장
Yang 데이터 모델링 언어 사용
원격 프로시저(RPC)사용
- 서버에서 요청을 하면 rpc에 대한 처리 후 결과를 알려줌
- 메세지는 xml로 인코딩
- TCP상의 TLS(암호화까지 지원)에서 교환됨

[예시) NETCONF를 통한 세션초기화, 데이터교환, 종료 과정]

세션을 초기화하고 hello메세지 교환
rpc태그를 이용해 다양한 명령어와 설정을 다룬다
끝나면 세션 종료

5.4.3.1 NetConf의 Operation

get-config : 설정의 일부나 전체를 검색함

running : 현재 설정되어 있는 정보
candidate : 테스트중이며 아직 안정화 전
start-up : 안정화가 되면 저장

get : 설정 상태 및 동작 상태 검색

edit-config : 특정 설정의 일부 변경

lock/unlock : 설정 정보 저장소를 잠그거나 해제

creat-subscription / notification : 관심 있는 특정 이벤트에 대한 정보를 비동기적으로 보내도록 지시

5.4.3.2 Yang

NETCONF를 사용할때 사용되는 데이터모델링 언어
XML문서는 YANG모듈에서 생성
SMI과 마찬가지로 내장 데이터 유형 제공

teawon