[컴퓨터 네트워크] 4,5. Network Layer(2)

김민석·2021년 5월 21일

목록 보기

12/12

Border Gateway Protocols

Border gateway protocols(BGP)는 inter domain 라우팅에 사용되는 프로토콜이다.

-> 인터넷을 이루는 망 단위
-> 같은 라우팅 policy가 적용되는 라우터의 집합(망)
-> 한 AS 는 한 라우팅 프로토콜을 사용
-> 하나의 관리 주체에 의해 관리된다.

local 망 위에 지역, 나라를 커버하는 망, 그 위에 전 세계를 커버하는 망이 존재한다.
-> 티어 별로 나눔
AS들이 연결 될 때 provider/customer 관계로 연결되어 있는 것도 있고, peer 관계로 연결되어 있는 것도 있다.
-> provider/customer : 한쪽이 다른쪽에 서비스를 제공해 주는 형태(더큰망이 provider, 더 작은 망이 customer 느낌)
-> peers : 동등한 수준의 망끼리 서로 연결돼서 서로 라우팅 할 수 있도록, 서로 데이터를 주고받게 할 수 있도록 계약한거

인트라 도메인 : RIP, OSPF
-> 한 AS 내
RIP/OSPF는 망이 커지면 scalability 문제 발생한다.
-> RIP의 경우 Count-to-infinity 문제.
-> OSPF의 경우 모든 노드들에 flood 해 줘야함.
망과 망을 연결해 주는 인터 도메인은 다른 프로토콜이 필요하다
-> BGP(Border Gateway Protocol)

border 라우터끼리의 라우팅이다.
-> border 라우터 : 라우터 중 다른 as와 연결되어 잇는 라우터들(그림에서 노란색)
-> 둘로 나눌 수 있다 : eBGP, iBGP
eBGP(extermal BGP) : border 라우터들이 있는데, 다른 망으로 가기 위해서는 어떤 망을 거쳐서 가야 하는지 기억하고 있는거(다른 망의 border 라우터와의 라우팅)
iBGP : 한 as에 border 라우터가 하나는 아님(여러개 존재)
-> 그 border 라우터 사이에 어떤 식으로 라우팅 되는가
-> 같은 as 내의 border 라우터끼리 어떤 보더라우터에 가야지 어떤 as로 갈 수 있는지 서로 알려주면서 경로 설정하는거(같은 망의 border 라우터 끼리의 라우팅)
iBGP vs 인트라 도메인 라우팅 : 인트라 도메인은 모든 라우터에 대해 돌리는 건데, iBGP는 보더 라우터 끼리만 하는거
-> iBGP로 A에서 B로 보내야 한다는거 알면 실제 패킷의 이동은 인트라 도메인 라우팅 프로토콜을 통해 구해진 경로를 따라 이동하는거.

Path vector routing 사용 한다.
-> distance vector의 일종
-> next hop 대신 path 사용하는거
BGP routing table

-> Prefix : ip 주소의 집합(목적지)
-> Origin AS : ip 주소들(prefix의)이 속해있는 as 번호
-> Path : as 번호들로 경로 구한거
path vector routing 쓰는 이유 : next만 기억하면 루프가 생길 수 있으니까 경로를 다 기억해서 루프 방지 하기 위함
-> 망이 너무 커지면 저장해야 할 양이 너무 많아짐 -> as 단위로 하기 때문에 생각보다 안큼(전세계에 as는 10만개 정도 뿐)
똑같은 주소에 대해 다른 경로 존재 가능(한 목적지에 대해 여러 경로 저장 가능)
-> 어떤 것을 사용할지는 여러 기준 적용

동작과정

Distance vector routing 처럼 정보를 교환한다.
-> 이웃한 BGP 라우터한테 route advertisement를 전달해줌
경로 정보를 전부 가지고 있기 때문에 루프를 방지할 수 있다.
-> 경로상 존재하는 as로는 테이블을 보내지 않음으로써 루프 방지
-> 그림 예로 보면 500이 100으로 테이블을 보냈는데, 100 입장에서 업데이트 결과 500을 다음으로 업데이트 하게 된다면 500 300 200 100 500 이렇게 루프 생길 수 있음

iBGP 도 eBGP랑 동작은 같다.(Path vector routing 사용)
-> 근데 as 번호로 경로 나타내기 때문에 같은 as 내의 정보들도 포함되어야 함
-> 그니까 다음으로 어느 as로 가야하는 지는 알지만 같은 as 내의 border 라우터 끼리 어느 라우터로 가야할지 모르기 때문에 iBGP를 해야한다.
특징 : 모든 iBGP 라우터는 fully connected 되어 있어야 한다. (다른 iBGP 라우터를 통해 전달 받는 것이 아니라 직접 받아야 한다.(다른 일반 라우터 경로는 상관 없음))
-> 다른거 거쳐 가면 count to infinity 문제가 발생할 수 있기 때문에 이런 문제를 원천 봉쇄한거.
-> 무조건 직접 연결 되어야 한다.
R3가 R1과 R2에게 R4로부터 전달받은 라우팅 테이블을 iBGP를 통해 알려준다.
R3가 R4쪽으로 R1과 R2의 정보를 eBGP를 통해 전달해준다.
R3는 R2에게 R1으로 부터 받은 정보를 원칙적으로 전해 줄 수 없다.
-> 직접 알려줘야함(R2는 R1으로부터 직접 정보를 받아야 함)
-> iBGP는 fully connected(믈리적 직접 연결을 의미하는 것이 아닌 연결성을 의미하는거, border 라우터를 안거치고 다른 라우터를 통해 갈 수 있으면 됨)

best path 고르기
-> shortest path가 가장 좋은 경로는 아님
-> 관리주체가 다른 망을 거쳐 가기 때문에 금전적 관계가 있을 수 있기 때문
경로 선택 우선순위
-> Customer > peer > provider
Transit traffic에 대한 정책
-> transit traffic : 나의 customer 쪽으로 가지 않는 트래픽
-> provider는 transit traffic을 받아줌
-> customer나 peer는 받아들이지 않음
-> 뭔말이냐면 내 customer한테 가는게 아니라 그냥 다른곳으로 가기 위해 거치는거 뿐이라면 안받아줌, 전달 위해 거치는 거면 provider 통해서 돈내고 써라 이거임
이것 말고도 다른 많은 정책 존재
-> 정책에 의해 best 경로를 고른다 이말

-> M 모양의 invalid : 11번 입장에서 자기의 customer로 가는 것이 아니기 때문에 불가
-> n 모양의 invalid : 12번 입장에서 자기의 customer로 가는 것이 아니기 때문에 불가

Route advertisement를 통해 valid 한 라우트를 통해 패킷이 전달되도록 해서 위의 invalid한 문제들 을 해결할 수 있다.

Multi-homed AS : 하나의 customer가 여러개의 provider와 연결되어 있는거(경로가 여러개일때)
-> 라우팅 테이블에는 여러 경로들 모두 저장함, 선호도(local preference)가 높은 쪽으로 데이터 트래픽 전달함

-> AS 300의 선호도가 800으로 더 높으니까 300으로 보냄

같은 as로 연결되어 있는 border 라우터가 여러개일 때
-> MED 값을 포함 시켜서 med가 더 작은 쪽으로 데이터 트래픽을 전달함
-> 한 as로 부터 받는 라우터가 여러개 일 때 그 중 하나를 통해서 받고 싶을 때 사용

-> B의 MED가 A보다 더 작으니까 AS 200은 B를 통해 트래픽을 전달함.