Intra-AS / Inter-AS routing

**

unicast: 1:1

multicast: 1:n

broadcast: 1:?

anycast: 1:n중 어느 하나

 

확장성 문제로 인해 라우팅 테이블에 전세계 대상으로 저장할 수는 없음

또한, 각 네트워크 관리자는 자신의 네트워크에서 라우팅을 제어하고 싶어할 수 있음(자율성)

실제로 라우터의 종류는 다양하고, 계층 구조임

 

AS(autonomous system) 단위로 관리됨

한 기관에서 관리하는 네트워크이며, 동일한 네트워크 ID를 가진 라우터의 집합임

 

intra-AS 라우팅

같은 AS 내부에서 호스트, 라우터 간 라우팅

같은 AS 안에서는 같은 프로토콜로 라우팅해야 함

다른 AS 간에는 프로토콜이 달라도 상관없음

게이트웨이: 다른 AS와 링크를 가진 가장자리의 라우터

 

inter-AS routing

AS 간 라우팅

게이트웨이가 수행함

 

포워딩 테이블은 인트라, 인터 AS 라우팅 둘 다 작용해서 구성됨

 

라우팅 알고리즘의 종류

IGP, EGP (프로토콜 이름이 아니라 프로토콜 들의 총칭)

 

IGP(Interior Gateway protocol)

- 독립적인 네트워크 관리 조직(AS)내에서 사용

- RIP, IGRP 등 (distance vector)

- OSPF 등 (Link State)

 

EGP(Exterior Gateway Protocol)

- AS 상호 간에서 사용하는 라우팅 프로토콜

- BGP (Path vector,, Distance vector랑 비슷한 방식)

---

IGP

 

RIP(Routing Information Protocol)

거리 벡터 라우팅 알고리즘

코스트는 링크 당 1

30초마다 거리 벡터 정보 공유

지금은 거의 안쓰고, 보안 문제도 취약함

최대 15개 라우터를 가진 네트워크에서만

Convergence(수렴) time : 네트워크 상의 변화가 생겼을 때 그 정보들을 서로 인식하고 수정하는 시간

 

OSPF(Open Shortest Path First)

연결 상태 라우팅 알고리즘

LSA Flooding .. IP를 타고 메시지가 나감 (TCP, UDP가 들어갈 자리- 페이로드에 대신 들어감)

모든 메시지는 인증됨(보안 문제)

링크 상태에 변화가 있으면 AS내 모든 라우터에게 알려줌

경로 비용이 다르게 설정 가능

 

 

Hierarchical OSPF

AS를 세부적으로 나눌 수 있음

boundary router / backbone router / area border router / internal router

바운더리 라우터가 게이트웨이, 에리어 보더 라우터는 각 에리어를 대표

백본 라우터는 그 사이에서 소규모의 에리어들을 관리

 

AS가 크면 하나의 OSPF로 운영 시 트래픽 부담이 심함

=> 지역화

2레벨 계층: 로컬 에리어와 백본

- LSA는 지역 AS에만 보냄

- 각 노드에는 세부 영역 토폴로지가 있음 (다른 영역 네트워크로 가는 최단 경로만 앎)

 

에리어 보더 라우터

- 자신의 지역 네트워크 거리를 요약하고 다른 에리어 보더 라우터에 광고

 

백본 라우터

- 백본으로 제한된 OSPF 라우팅 실행

 

바운더리 라우터

다른 AS와 연결됨

---

Inter-AS

BGP (Border Gateway Protocol)

- 표준임

- eBGP : 게이트웨이 끼리 정보 교환

- iBGP : 게이트웨이가 내부 라우터에 전달

 

BGP의 특징 중 하나는 policy에 의해 경로가 바뀔 수 있다는 것

 

게이트웨이 라우터는 eBGP, iBGP 둘 다 작동

BGP session: 두 BGP 라우터는 반영구적 TCP 커넥션을 통해 항상 연결됨

** 계층은 네트워크인데 상위 프로토콜인 TCP 사용이 확정됨

AS에 새 라우터가 들어오면 다른 AS의 게이트웨이에 알림

 

BGP 내용

프리픽스(NW id) + attributes = "route"

 

attribute

- AS_PATH : 거쳐야 하는 AS 프리픽스 목록

- NEXT-HOP : AS에서 다음에 거칠 라우터

 

Policy-based routing

관리자의 정책에 따라 라우팅을 제어할 수 있음

예를 들어 ISP A, B, C가 있다고 하면

B는 C한테 트래픽을 넘겨받기 싫을 수 있음

=> C한테 경로 안알려줌

 

BGP path advertisement

여러 게이트웨이한테 같은 곳으로 가는 경로를 여러개 받을 수 있음

-> 정책에 따라, 보통 그냥 빠른 걸로 설정

 

BGP messages

- OPEN: BGP 오픈

- UPDATE: 새 경로 advertise

- KEEPALIVE: 업데이트 없어도 연결 유지

- NOTIFICATION: 에러 메시지, 커넥션 종료

 

뜨거운 감자 문제

전체 경로를 고려하는게 아니라 자기 AS 내에서 가장 비용이 적게되는 게이트웨이로 빨리 내보냄(이기적)

 

BGP 루트 선택 기준

- policy (관리자 판단)

- 짧은 AS-PATH

- 가까운 NEXT_HOP -> 뜨거운 감자 문제 유발 가능

- 기타

 

 

 

왜 intra, inter AS 라우팅이 다른가

policy 관점

intra: 관리 주체가 하나 -> 정책이 특별히 필요 없음

inter: 관리자가 트래픽을 컨트롤하고 싶을 수 있음

 

scale 관점 (확장성 제일 중요)

라우팅 테이블의 크기를 작게할 수 있고, 업데이트 트래픽을 줄일 수 있ㅇ,ㅁ

 

performance 관점

intra는 속도가 많이 중요한데,

inter는 policy가 더 중요