네이버 카페 네.전.따와 함께하는 네트워크 이야기 1

제로의 네트워크 이야기 라우팅 프로토콜 - BGP Ⅴ

꽃을 심을 때 꽃삽이 필요하고 도로 공사를 할 때는 포크레인 등의 중장비가 필요하듯이 라우팅 프로토콜 또한 사용 용도와 규모에 따라 각각 IGP(Interior Gateway Protocol)와 EGP(Exterior Gateway Protocol)로 나눠진다. IGP는 기업 내부에서 사용하는 프로토콜로서 RIP, OSPF 등이 있고, EGP는 기업과 기업 간에 사용하는 프로토콜로서 BGP(Border Gateway Protocol) 등이 있다. 우리가 사용하고 있는 인터넷은 전 세계를 연결하는 광대한 네트워크로 구성돼 있다. 이번 리포트에서는 이러한 거대한 네트워크를 운영하는 데 사용되는 라우팅 프로토콜인 BGP에 대해 살펴보는 시간을 갖고자 한다.

블랙홀(Black hole) 라우팅


<그림 1>에서 서울 라우터는 천안 라우터에게 강남 정보를 알려주고, 천안 라우터는 부산 라우터에게 강남 정보를 알려준다. 물론 대전 라우터는 강남에 대한 정보를 받은 적이 없기 때문에 강남에 대해서는 모르게 된다. 이때 부산 라우터에서 강남 쪽으로 데이터를 보내려고 한다. 어떤 일이 일어나게 될까
부산 라우터의 라우팅테이블에는 강남으로 갈려면 천안으로, 천안으로 가기 위해서는 대전으로 가라고 나와 있다. 따라서 부산 라우터는 대전으로 패킷을 전달한다. 그러나 대전 라우터의 라우팅 테이블에는 강남이 존재하지 않으므로 목적지 주소가 강남인 패킷은 폐기된다. 이러한 현상을 혹자는 블랙홀 라우팅이라는 표현을 쓰기도 한다. 왜냐면 부산에서 강남으로 보낸 패킷은 대전 라우터에서 블랙홀처럼 전부 다 흡수해 없애버리기 때문이다.
이번에는 ISP처럼 경유하는(transit) AS인 경우를 생각해 보자. 이럴 경우 심각한 문제가 발생할 수 있다.
서울에서 부산으로 가기 위한 경로는 두 가지가 있다. 두 개 중에서 ISP-B를 이용한 AS 경로가 더 짧으므로 서울 라우터의 라우팅 테이블에는 넥스트 홉으로써 천안이 등록된다. 물론 부산 라우터에서도 서울에 가기 위한 경로는 대전으로 등록된다. 그리고 앞에서 나왔듯이 서울~부산 트래픽은 모두 청주 라우터에서 폐기된다.

BGP 동기화(synchronization)


<그림 2>에서 문제가 발생한 원인은 청주 라우터가 서울 라우터에 대한 정보를 갖고 있지 않았기 때문이다. 따라서 청주 라우터가 서울 라우터 정보를 알고 있을 때만 iBGP 정보를 유효하게 만든다면 위와 같은 문제는 발생하지 않을 것이다.
즉, 청주 라우터가 서울에 대한 라우팅 정보를 가지고 있다는 확신이 들 경우에만 iBGP 정보를 이용하면 된다는 것이다.
여기서 청주 라우터가 서울 정보를 가지고 있다는 확신이 든다는 점을 다른 말로 정리하면, ISP-B의 IGP에 서울 정보가 있을 경우에만 BGP 정보가 유효하다는 것으로 풀이된다.
만약 ISP-B의 IGP에 서울 정보가 없을 경우에는 대전 라우터는 이것을 유효하지 않는 것으로 판단하고 라우팅 테이블에 등록하지 않는다. 따라서, 부산 라우터에서는 광주로 가는 경로를 이용하게 된다. 이것을 바로 동기화(synchronization)라고 하며sync란, iBGP로 받은 정보가 IGP 정보로 올라올 경우에 sync (같을) 때만 BGP 정보를 이용하게 된다는 것을 말한다.
이제 지금까지 블랙홀 라우팅 문제로 인하여 sync가 필요하다는 점에 대해 알아보았다. 이번에는 동기화가 셋팅되어 있을 때의 BGP 정보를 사용할 수 있도록 하려면 어떻게 해야 될지 알아보자.
먼저 모든 라우터가 BGP를 다 돌려야 한다. <그림 2>에서 청주라우터가 BGP를 돌리지 않기 때문에 발생한 문제이기 때문이다. 두번째는 BGP 정보를 IGP로 재분배해야 한다. 이렇게 하면 BGP 정보가 IGP로 다 보이기 때문이다.

BGP no synchronization이 대세
앞서 동기화가 필요한 이유와 방지책에 대해서 알아보았다. 그런데 IOS 12.2(8)T 이후 버전부터는 디폴트가 no synchroniztion이다. 왜 그런 것일까


<그림 3>에서 라우터와 각각의 ISP는 eBGP로 라우터와 백본 스위치는 iBGP로 각각 연동되어 있다. 물론 방화벽은 BGP를 지원하지 않기 때문에 스태틱으로만 설정되어 있다.
이 상태에서 방화벽은 BGP를 돌리지 않고 있지만, 앞에서 나온 블랙홀 라우팅 문제는 존재하지 않는다. 그 이유는 방화벽에서 디폴트 라우팅을 라우터 쪽으로 설정했기 때문이며, 이러한 경우에는 통신에 문제가 되지 않는다. 그리고 ISP에서는 네트워크 설계부터 아예 블랙홀 라우팅이 존재하지 않도록 설계를 한다.
그런데 동기화를 사용할 경우 문제 해결을 하기 위해서 BGP 정보를 IGP로 재분배하면 된다는 것에 대해 한번 생각해 보자. BGP는 라우팅 프로토콜 중에서 가장 덩치가 큰 것으로서 수십 만개 이상의 라우팅 정보를 운영한다.
반면, IGP는 보통 몇 백개 정도의 소규모 라우팅을 운영한다. BGP 정보를 IGP로 재분배한다는 것은 마치 어린이가 체중 200kg 씨름 선수를 세발 자전거로 뒤에 태우고 다니는 것과 똑같다고 말할 정도로 어려운 것이다.
그런데 왜 예전에 sync를 사용할 때에는 BGP 정보를 IGP로 재분배하라고 했을까 그 이유는 이렇다.
예전에 sync라는 개념이 도입되었을 때, 일반인들은 인터넷을 사용하지 않았고 인터넷 사용자 자체가 얼마 되지 않았다. 때문에 BGP 정보가 많지 않았으며, IGP로 넘겨서 사용해도 별다른 무리가 없었기 때문이다. 이제 실제 라우터에서 살펴보자. R1,R2는 eBGP로 R2와 R4는 iBGP로 연동되어 있으며, R1은 BGP로 1.1.1.0/24를 광고하고 있다.


<리스트 1>에서 보면 BGP 테이블에서 보이긴 하지만 no best path이므로 사용할 수 없다. 또한 라우팅 테이블에 등록되지 않는다. <리스트 2>는 동기화를 사용하지 않을 때의 결과로, BGP 테이블에서 best로 등록된다. 따라서 이를 라우팅 테이블에 등록할 자격이 주어진다. <리스트 1>과 <리스트 2>는 이달의 디스켓을 통해 확인할 수 있다.

* BGP 테이블에서 best 정보만 사용 가능하다. no best path는 사용할 수 없다.
* 여러 가지 라우팅 정보 중에서 가장 좋은 경로만 라우팅 테이블에 등록이 된다.