BGP
BGP (Border Gateway Protocol) 는 ISP 사이의 통신 표준이다.
이 프로토콜을 따르지 않으면 다른 AS하고 통신할 방법이 없기 때문에, 모든 라우터 벤더들이 이 프로토콜을 따른다.
이 프로토콜은 인터넷을 연결시켜주는 접착제 역할을 한다.
intra-AS routing protocol 은 심지어 프로토콜 자체를 안써도 상관없다.
우리는 그냥 라우팅 프로토콜 없이 어떤 목적지로 갈 때는 static 하게 무조건 이 길로 간다라고 해도 상관이 없다.
하지만 그런 AS도 다른 AS와 연결되고 싶다면 이 프로토콜을 써야 한다.
가령 위 그림과 같이 네트워크가 구성되어 있다고 해보자.
AS X 에 속한 A 컴퓨터에서 트래픽을 발생시켰는데, 목적지를 가는 길에 AS Y 를 거쳐야 한다고 하면, AS X 에서는 AS X가 따르는 효율성으로 AS Y로 가는 게이트웨이에 도착하고, AS Y 에선 AS Y가 따르는 효율성을 따져서 목적지까지 갈 것이다.
따라서 자신의 AS를 벗어나면 그때부터는 그 AS에게 패킷 전송을 맡긴다고 볼 수 있다.
그래서 광고할 때는, 내가 여기있고 여길 통해서 나에게 도착할 수 있다는 광고를 한다.
(IP를 정리하면서 두 ISP 사이에서 광고하는 것을 이야기한 적이 있었다. 그 글에서의 '광고'가 사실은 AS에 대한 광고였던 것이다.)
그래서 BGP는 각각의 AS에게 다음을 제공한다.
- eBGP
이웃 노드(AS)들로부터, reachability 정보(서브넷)를 수신하는데 사용한다.
즉, 도착 가능한 목적지 주소들을 받는다.
- iBGP
reachability 정보를 AS 내부의 라우터들에게 뿌리는데 사용한다.
이때 intra-AS 프로토콜을 사용하지 않고 iBGP를 사용하는 이유는 reachability 정보는 intra-AS 라우팅 프로토콜이 관리하는 정보가 아니기 때문이다.
intra-AS 프로토콜은 AS 안에서 왔다갔다하는 최적의 경로를 찾는 알고리즘이다.
하지만 BGP를 통해서 얻은 정보는 여러 AS를 거쳐가는 정보로, 이 정보를 나누는 것은 intra-AS 프로톸로의 목표가 아니기 때문에 별도의 iBGP를 사용한다.
그리고 중요한 것은, 다른 목적지로 가는 최적을 선택하는게 아니라, 다른 목적지로 가는 길을 선택하는 것이 중요하다. 그래서 policy가 굉장히 중요하다.
이 정책에 따라서 목적지로 가기 위해 어떤 다음 AS로 전달할 것인지 판단하는 것이다.
예를 들어 러시아-우크라이나 전쟁을 생각한다면, 우크라이나가 어떤 정보를 보낼 때, 러시아에 있는 망을 거쳐서 보내는 것이 지리적으로 가까운 최적이라고 할 지라도, 민감한 정보가 러시아에게 넘어가면 안되기 때문에 그 AS는 선택하지 않도록 정책을 짤 수 있다.
다음과 같은 네트워크를 보면, AS와 AS 사이를 연결하는 border router 끼리는 eBGP 방식으로 연결되어 있고, AS 내부 라우터들은 논리적으로 iBGP로 연결되어 있다.
이때 논리적이라는 말은 물리적으로 연결이 되어있지 않더라도, 다른 라우터를 통해 갈 수 있는 경로가 존재하여 연결되어있다는 것을 의미한다.
여기에서 2a 라우터는 AS1 을 통하는 경우 얻을 수 있는 목적지 정보들을 eBGP를 통해 얻을 것이고,
이 정보들은 iBGP를 통해 내부의 모든 라우터에게 전달할 것이다.
그러면 2b 라우터는 AS1 을 목적지로 하는 트래픽을 발생시켰을 때, 이 정보를 2a로 보내야 한다는 것을 결정할 수 있다.
2a가 AS1을 통해서 갈 수 있는 목적지정보를 보내줬기 때문이다.
그래서 빨간색 동그라미친 boundary router 들은 모두 eBGP, iBGP를 동시에 실행시키고 있어야 한다.
BGP 동작 과정
BGP를 사용할 때는 BGP Session이 필요하다.
BGP 세션은 라우팅 프로토콜이기는 하지만 TCP를 사용한다.
(TCP는 4계층 프로토콜이지만 라우터에서 동작한다.)
BGP를 사용해서 데이터를 교환하는게 일순간에 잠깐 하는 것이 아니라, 연결이 계속해서 남아있기 때문에 연결을 게속 유지하기 위해 TCP를 사용한다. (IP는 연결이라는 개념이 없기 때문이다.)
내가 네트워크를 구축해서 AS를 하나 만들어서 다른 AS와 연결이 되었을 때, 이 연결이 하루아침에 바뀔 가능성은 굉장히 낮을 것이다. 꽤 오랫동안 해당 AS와 연결이 유지된다고 보는 것이 합리적이다.
따라서 한번 TCP 연결을 맺어놓으면 안정적으로 신뢰성 있게 그 연결을 계속 사용할 거기 때문에, 특별한 일이 있지 않은 이상 이 연결을 끊지 않는다.
그래서 BGP메세지를 교환하는 2개 BGP 라우터를 가리켜 'peer' 라고 부른다.
이 피어들끼리 연결된 BGP 연결 (TCP 연결)을 BGP 세션이라고 부른다.
그리고 이 세션을 통해 BGP의 reachability 정보가 상대방 AS에게 전달된다.
이떄 주고받는 정보는 AS 경로로서, 벡터를 주고받는다.
그래서 BGP를 'path vector protocol' 이라고도 부른다.
그림과 같이 3d 라는 AS3 라우터와 연결된 목적지 X가 있다고 하자.
그러면 AS3에서 BGP를 통해 광고할 때는 'AS3, X' 라고 하는 경로를 광고한다.
즉, X로 가는 트래픽은 나에게 보내라고 광고하는 것이다.
이 광고는 eBGP를 통해 AS2로 전달이 되어 2c 라우터가 받을 것이다.
그러면 2c라우터는 자신의 AS 내부로는 iBGP를 사용하여 그 내용을 전파할 것이다.
그리고 이 정보는 AS1까지 전달이 된다.
이때는 path에 AS2 정보가 붙어서 함께 전달될 것이다.
따라서 더 멀리있는 AS로 전파될 수록, 점점 AS패스의 길이가 늘어나면서 광고가 된다.
BGP가 광고하는 내용의 핵심은 AS패스이다.
AS패스는 prefix (목적지) + attribute 로 구성된다.
목적지는 목적지의 prefix 즉, 서브넷 주소를 말한다.
따라서 해당 서브넷에 위치하는 목적지 주소가 있다면 AS3로 보내라는 것을 광고한다.
다음으로 Next-Hop 이라는 것도 있다.
어떤 라우터가 위와 같이 구성되어 있다고 하자.
그러면 제일 왼쪽에 있는 라우터는, AS10으로 데이터를 전송하는 경로가 2개가 존재한다.
이렇게 2개 경로를 거쳐서 X라는 목적지에 도달할 수 있다.
이때 어떤 경로를 선택할지 결정하는데 Next-Hop을 사용한다.
맨 왼쪽 라우터에게 있어 Next-hop 은 8 또는 6을 선택할 수 있을 것이다.
따라서 BGP가 광고하는 내용의 첫번째 라우터를 지정하여 경로를 선택한다.
BGP는 policy-based routing을 사용한다.
intra-AS 에서는 효율성이 매우 중요하다. (최단 경로를 찾는 것)
하지만 이게 AS 범위를 벗어나게 되면 그때는 효율성보다 정책이 더 중요해진다.
(위에서 말한 우크라이나-러시아 예시)
따라서 어떤 정책상으로 AS-Y 로는 라우팅하지 않는다는 정책이 있다면, AS Y 가 광고를 하더라도 광고를 무시하고 포워딩을 시키지 않을 수도 있다.
또 이에 따라 어떤 걸 광고할지 결정하는데에도 policy를 사용할 수 있다.
물론 특정 정책에 맞는 상황 안에서는 BGP도 효율성을 따질 것이다.
(거쳐가는 AS가 몇 개인지, 줄일 수 있는지 등)
어떤 경로의 광고 과정을 살펴보자.
AS3을 통해서 X라는 목적지에 갈 수 있을 때, AS3은 AS2에 'AS3, X' 라는 AS path를 광고한다.
이때는 eBGP를 사용한다.
AS2 내부에서는 AS2의 정책을 기반으로 iBGP를 사용하여 이 정보를 AS2에 있는 각 라우터에게 전파한다.
그러면 AS2 내부의 라우터들은 X로 가야한다면 2c라는 게이트웨이 라우터로 보내면 된다는 것을 알 수 있다.
그리고 AS2는 다시 As2의 정책을 기반으로 eBGP를 사용하여 AS1에게 'AS2, AS3, X' 라는 as path를 광고한다.
AS1은 이 정보를 받아서 다시 AS1 내부에서 브로드캐스트한다.
이번엔 다른 상황을 보자.
위와 같은 상황에서는 AS1 과 AS3 사이에 갈 수 있는 경로가 2가지 존재한다.
직전 예시와 같은 과정을 거치면 AS1의 1c라우터는 위와 같이 'AS2, AS3, X' 라는 as path를 받을 것이다.
그리고 이에 더해 'AS3,X' 라는 또 다른 as path 도 전달받는다.
1c 게이트웨이 라우터는 2가지 정보를 받았고, 이제 policy에 기반해서 어디로 보낼지를 결정한다.
그러면 결정한 내용을 iBGP를 거쳐서 내부의 라우터들에게 알려준다.
BGP Message
BGP 메세지는 BGP Session (TCP connection) 으로 연결된 피어 사이에서 주고받는 데이터이다.
그 종류로는 아래와 같은 메세지들이 있다.
1. OPEN
최초로 BGP peer와 TCP 컨넥션을 설정하는 것이다.
내가 누구인지를 상대방에게 인식시키고, 상대방의 인증과정이 끝나면 연결을 수락한다.
이렇게 한번 연결이 설정되면, 상당 기간 연결이 유지된다.
따라서 이 메세지는 사용빈도가 매우 낮다.
2. UPDATE
새로운 AS-PATH가 발견되었을 때, 또는 기존 AS-Path를 사용하지 못하도록 취소할 때 (policy 정책의 변경) 사용한다.
3. KEEPALIVE
새로 업데이트할 경로의 변경이 없더라도, 내가 계속 살아있다는 것을 알리는 목적의 메세지를 보낼 수 있다.
OPEN에 대한 ACK로도 사용된다.
4. NOTIFICATION
주로 연결을 종료할 때 사용한다.
이전 메세지의 에러를 알리는 용도로도 사용되지만, 메세지의 에러가 발생하는 경우가 없기 때문에 (에러가 발생한 메세지를 보내는 경우가 없기 때문에) 이 용도로는 자주 사용하지 않는다.
연결 종료로 사용한다고 하더라도 AS 자체가 연결을 끊을 일이 많이 없기 때문에, 전체적인 빈도수로 봐도 사용 빈도는 낮다.
Example
이제 이전 예시 상황에 이어서, 각 라우터의 포워딩 테이블이 어떻게 업데이트 되는지도 살펴보자.
1a 에 연결된 호스트가 X를 목적지로 하는 트래픽을 발생시켰다고 하자.
그러면 1a는 X로 보내기 위해서는 1c로 패킷을 보내야 하는 것을 알고 있다.
그러면 1d 라우터는 아래와 같은 포워딩 테이블을 만들 것이다.
자신에게 연결된 link 2개 중에 1c로 가려면 1번 링크를 사용해야 한다는 것은 당연하다.
여기에 더해, X로 가려면 1번 링크를 사용하라는 정보도 추가로 저장한다.
만약 1a가 1c로 보낼 때 1d를 경유하기로 했다면 (OSPF로 판단), a1의 포워딩 테이블은 위와 같이 되어있을 것이다.
포워딩테이블에 이런 정보를 추가하는 방법은 당연히 intra-AS routing protocl (OSPF) 를 사용하여 만들었을 것이다.
구체적으로는, iBGP를 사용하면, X로 가기 위해서는 1c로 보내야 한다는 것을 알 수 있다.
그리고 ic로 가는 방법은 OSPF를 사용해서 포워딩테이블에 이미 저장되어있다.
따라서 이 둘을 조합하면 X로 가려면 1c로 보내는 방법과 같은 방법을 사용하면 된다는 것을 알게 되는 것이다.
왜 BGP와 OSPF로, intra-AS / inter-AS 로 프로토콜을 구분했는지 다시 정리해보자.
하나의 라우팅 프로토콜을 전체 인터넷 스케일로 적용하면 안되는 이유는, policy, 그리고 확장성 때문이다.
우선 policy 관점에서 보면 inter-AS 라우팅 프로토콜은 정책을 더 중요하게 보고, intra-AS 라우팅 프로토콜은 상대적으로 덜 중요하게 본다.
intra-AS 는 네트워크 관리자 입장에서는 프로토콜을 자신이 나름대로 정해서 돌려도 좋으니 효율성(성능)을 중시하지만, AS끼리 통신할 때는 표준을 따라야 하기 때문에, 효율성보다 policy를 더 중요하게 본다.
확장성 관점에서도 intra / inter 로 나누는 것이 효율적이다.
그렇지 않으면 전 세계의 인터넷이 하나의 라우팅 도메인이 될 것이고, 각각의 라우터가 교환하는 정보가 어마어마하게 많아질 것이기 때문이다. 그 말은 각각의 라우팅 테이블에 저장할 테이블의 크기가 매우 커지는 것을 의미한다.
그래서 라우팅 테이블의 크기, 라우팅 정보를 교환하는 정보의 양을 줄이기 위해서 어떻게보면 필연적인 선택인 것이다.
Hot-Potato Routing
만약 손에 뜨거운 감자가 주어졌다면 이걸 빨리 다른 사람한테 넘기고 싶을 것이다.
핫 포테이토 라우팅은 이런 의미로 지어진 이름이다.
어떤 라우터가 핫 포테이토, 그러니까 데이터 트래픽 패킷을 받았다고 해보자.
그러면 이걸 빨리 넘겨야 하니까, 별 생각없이 이걸 받을 수 있는 가장 가까운 이웃에게 전달하는 라우팅 방식이다.
AS2 가 목적지 X로 가는 AS-Path를 위와 같이 받았다고 해보자.
보통의 경우라면 policy가 영향을 미치지 않는 한 AS3을 통해서 직접 보낼 것이다.
그런데 2d 라우터 입장에서는 AS1 과 연결된 게이트웨이 라우터, AS3 과 연결된 게이트웨이 라우터를 선택할 수 있다.
즉, 2d라우터 입장에서는 X로 가는 Next-Hop이 2a가 될 수도, 2c가 될 수도 있다.
이때 그림과 같이 AS1의 게이트웨이 라우터에 대한 link cost가 더 낮다고 해보자.
사실 link cost는 intra-AS 라우팅에 대한 코스트이므로 AS-Path 에는 관여할 수 없는 값이다.
하지만 라우터 입장에서는 만약 2a, 2c의 Next Hop이 모두 동등하다고 여겨진다면, 그때는 내부적인 link cost를 같이 고려할 수 밖에 없어서 2a 라우터로 패킷을 보내게 된다.
이 결정은 AS-Path 관점에서는 효율적이지 않은 결정이다.
하지만 2d 라우터 입장에서는 이 패킷을 빨리 넘기고 싶어서 제일 가까운 link cost를 갖는 게이트웨이 라우터로 일단 보내는 것이다.
이런 방식을 Hot Potato Routing 이라고 한다.
BGP Achieving policy
다음과 같은 네트워크를 생각해보자.
크게 그려진 영역은 ISP 네트워크이고, 작은 영역이 ISP의 고객사 네트워크라고 보면 된다.
이때 AS A에서 그림과 같은 AS path 를 광고했다고 해보자.
ISP 입장에서 A, B, C 라는 ISP는 서로 경쟁자다.
B 입장에서 생각했을 때, y라는 고객사에서 출발해서 C, A를 경유해 w로 가는 트래픽을 B가 중계한다고 해보자.
그러면 B는 굉장히 바보같은 결정을 한 것이다.
왜냐하면 굳이 B를 거치지 않아도 A로 바로 갈 수 있으면서, y, w는 모두 B의 고객사가 아니기 때문이다.
따라서 다른 회사의 고객으로부터 출발한 트래픽을 굳이 B가 중계해줄 필요는 없다.
(물론 자신의 고객인 x로부터 출발한 트래픽이라면 당연히 중계해주어야 한다.)
따라서 B는 이 광고를 C에게 추가적으로 광고할 필요가 전혀 없다.
(B, A, w) 라는 경로를 광고할 필요가 없는 것이다.
하지만 A, C는 당연히 중계를 해야한다. w는 A의 고객사이고, y는 C의 고객사이기 때문이다.
C입장에서는 비록 B가 광고를 하지 않아서 B를 경유하는 길은 모르겠지만, 어차피 B를 경유하지 않아도 A를 거쳐 w로 가는 방법을 알고 있으니 상관이 없다.
그리고 다음과 같은 상황도 발생할 수 있다.
만약 x에서 네트워크 설정을 잘못하면, C에서 B로가는 트래픽이 x를 경유해서 가게 될 수도 있다.
말도 안되는 짓이다. x가 목적지도 아닌데, 경유를 위해서 트래픽이 들어오고 나가는 것이기 때문이다.
따라서 이런 설정은 절대로 하면 안된다.
이렇게 되면 내가 B, C에게 돈을 주고 있는데, B, C가 x를 이용한 것이나 마찬가지다.
x와 같이 두 군데 이상의 ISP에 고객으로 가입한 경우를 dual-homed 라고 한다.
(한군데 ISP만 사용하면 한쪽에서 문제가 생기는 순간 같이 네트워크에 문제가 생기기 때문에 보통 2군데와 계약을 하는 것이 흔한 일이다.)
이런 상황에서는 위와 같은 문제가 발생할 수 있으니 설정을 주의해서 해야 한다.
(x는 B, C에 자신을 경유해서 서로에게 갈 수 있다는 광고를 하면 안된다.)
BGP 경로 설정 과정
마지막으로 BGP의 경로 설정 과정을 살펴보자.
(경로 설정의 우선순위라고 보면 된다.)
위에서 본 예시와 같이, 내가 2군데 이상의 AS 패스를 사용할 수 있을 때, 어떤 패스를 사용할 지 결정하는 우선순위는 다음과 같다.
1. local preference value attribute (policy decision)
현재 사용하고 있는 정책을 1순위로 사용한다.
하지만 보통 모든 AS 패스가 같은 정책을 갖는 경우가 많다.
2. shortest AS-PATH
3. closest NEXT-HOP router (hot potato routing)
4. additional criteria
3번까지도 안되면 다른 기준을 사용해야 하는데, 보통 이 단계까지는 올 일이 없다.
'CS > 컴퓨터 네트워크' 카테고리의 다른 글
[컴퓨터 네트워크] 38. Network Layer (14) : ICMP (0) | 2024.06.14 |
---|---|
[컴퓨터 네트워크] 37. Network Layer (13) : SDN control plane (1) | 2024.06.14 |
[컴퓨터 네트워크] 35. Network Layer (11) : intra-ISP routing protocol (OSPF) (0) | 2024.06.14 |
[컴퓨터 네트워크] 34. Network Layer (10) : Distance Vector (0) | 2024.06.08 |
[컴퓨터 네트워크] 33. Network Layer (9) : Link State (0) | 2024.06.08 |