Chapter5 : Network Layer: Control Plane(2)

이 포스트는 2021.12~2022.09 기간동안 벨로그에 작성한 글을 티스토리에 옮겨 적은 것입니다.

5.3 Intra AS routing in the internet

RIP (Routing Information Protocol)

UDP위의 L5에서 돌아감.
※ 라우터도 L4,L5 존재한다. user pkt은 L3까지만 거쳐가고 RIP control msg는 L5까지 올라간다.

RIP 알고리즘 & msg format

DV 알고리즘: metrix=hop count (max=15hop)
→ 16이 오면 infinite로 인식.
30초마다 정보 주고받는다.

OSPF

ip 위에 바로 올라감.
다익스트라 알고리즘 사용.

metrix based on type of service

• fixed: BW,reliablility
• varialbe: RTT, max throughput (진동문제때문에 위험)

two level hierarchy: 토플로지 정보 다 알려주기 힘드니까 AS 안에 여러 area 두고 그 안에서만 브로드케스트

area border router: ABR
backbone router: ABR들을 연결
AS boundary router: ASBR

backbone area는 항상 area 0이고, 이 area에선 DV 알고리즘이라서 loop free 토플로지로 짜야함

RIV vs OSPF

5.4 Routing among the ISPs

ASBR은 learn하고 propagate(advertise)(나한테 forward해라..)

BGP(Border Gateway protocol)

inter AS routing 또는 inter domain routing 프로토콜로 불리며 ISP들을 연결. internet backbone에서 많이 쓰인다. policy based routing!

path vector routing protocol- 라우팅 루프 방지 위해 거쳐가는 AS들의 리스트를 적음
classless inter domaint routing- 클래스 A,B..이런거 안함
incremental updates-TCP 세션 맺고 나서 변화 있을 때만 advertise.

BGP-peering

peer끼리 정보 주고받는다.
다른 AS끼린 eBGP TCP 세션 (policy 기반. 직접 연결)
같은 AS 안에선 iBGP TCP 세션.
교과서엔 fully meshed 라고 되어있는데 실제로는 ASBR하고만 다 연결되면 된다고 한다. 단 루프 방지위해 ASBR이 하나 하나 직접 연결해서 알려줌!

BGP: inter AS routing

eBGP: learn
iBGP: propagate

BGP: message

tcp 위에서 돌아감.

OPEN: ASN 주고받고 eBGP인지 iBGP인지 판단
UPDATE: 새로운 path
kEEPALIVE: tcp 세션 유지 위해..
NOTIFICaTION: report (ex:루프있는걸 왜알려줌?)

path attribute and BGP route

BGP route=(dest prefix,path attribute to the dest)
dest prefix:dest subnet의 정보
path attribute

• AS path(path vector): a list of ASN
• Next hop: 다음 AS의 eBGP peer의 ip 주소

enforcing various policy

import policy: 정보를 learn 했으니 내 AS에서 나가는 traffic이 생기겠네

export traffic: 정보 줬으니까 incoming traffic 받아들일게! (싫었으면 애초에 advertisement 안했어야)

BGP route selection

루트 여러개일 때 고르는 우선순위

1. policy decision (운정정책 위반 안하는지 보기)
2. shortest AS PATH (hop 수가 적은 쪽으로..)
3. closest next hop router: hot potato routing- 내 AS를 가장 싸게(빨리) 벗어나는 경로. 내 AS 밖의 비용은 무시!
4. additional criteria(BGP ID): BGP ID 중에서 그냥 하나 찍는다.(ex: 아이디 가장 높은거~)

How different Intra, Inter AS routing?

inter은 policy 중심. intra는 성능 중심

5.5 ICMP:The Internet Control Message Protocol

ICMP 메세지는 ip datagram 안에서 carried(ip 바로 위에 올라감!)

ICMP는 호스트와 라우터가 에러 리포트하고 그에대한 request/reply를 주고받는데 쓰이는 프로토콜.

※ msg에 대한 error report는 그 msg를 처음 만든 애한테 보낸다!

ICMP message: type , code plus first 8 byte
ex)
type code description
(3,3,dest port unreachable)
(11,0,TTL expired)

Traceroute and ICMP

ICMP msg 쓰는 라우터는 trace router

※record RTT → src가 TTL 1로 해서 UDP segment 보낸다. → 다음 라우터는 trop 한 다음에 type11, code0 ICMP 메세지를 src에 보낸다. → src는 record하고 RTT=2로 해서 보낸다.
(한 홉 딜레이 같은 걸 재는데 씀)

5.6 The SDN Control palne

nw control app(라우팅+α)은 정교한 s/w로 프로그래밍 된다. 이렇게 하기 위해 high level api(north bound api)를 서버에서 쓴다. 근데 이 high level api들은 user traffic이 지나다니는 nw device로부터 멀고 분리되어있다.

SDN

control plane과 data plane이 분리되어 있다.

SDN motivation

traditional 라우터는 어플, OS, HW등등을 한 회사의 제품으로 통일해서 번들로 사야했음. 불편!
→ SDN을 이용하면 따로따로 구매하기 가능해짐

SDN: How?

몇몇 라우터들을 컨트롤하는 logically centralized control plane. 여러 서버가 마치 하나인것처럼 동작

이렇게 하는 이유는?
1. easier nw management
2. programmable router(프로그래밍 더 쉽다.)
3. open implementation of control plane

SDN logical structure

a. network control palne
b. SDN controller
c. SDN-controlled switch

Data plane switch

c번 위치.

fast,simple commodity switch(in hw)
nw control application이 계산한 switch flow를 전달 받음. controller와 소통하고 switch control 하기 위한 southbound api(ex:openFlow)

※ flow table은 SDN controller가 계산하는 것이 아님! nw control application이 계산한것.

network control application

a번 위치.

'brain' of control: northbound api 이용해 계산
unbundled: can be provided by 3rd party (다 다른 회사 제품으로 구성해도 됨!)

SDN controller

b번 위치.

1. maintain nw state information
2. nw control application과 northbound api로 통신
3. nw switch과 southbound api로 통신
4. implemented as distributed system for performance, scalability, fault-tolerance

vs. traditional routing

기존 라우터의 경우, 돌아서 가고 싶으면 그렇게 되도록 링크 코스트를 조정해야 했다. 하지만 SDN은 nw control applciation에 있는 sw 덕분에 돌아가기가 가능하고, load balancing 또한 가능하다.

OpenFlow protocol

operate between controller and switch. TCP 사용.

3가지 openFlow msg class

• controller to switch
• switch to controller
• symmetric