[#3-8]BGP의 빠른 Take-over(1/2)

네트워크를 업으로 삼으시는 분이라면 누구라도 들어왔을만한 주제를 들고 왔습니다. 

 

'더 빠르게 서비스 정상화 안되냐!!! '  혹은 '더 빨리 라우팅이 넘어갈 수 없냐!!!' 

 

바로 Take-over에 대한 이야기를 시작해볼까 합니다. 

그중에서도 가장 많이 사용되고 있다고 봐도 무방한 BGP의 빠른 Take-over를 위해선 무엇을 해야하나 입니다.  

 

시작해보겠습니다.

 

 

0. 개요 

 

사실 BGP는 라우팅 프로토콜 중에서도 세부적인 정책 적용이 가능하다는 점에서 많은 ISP에서 사용하고 있고, 

기업 입장에서는 이러한 ISP와 연결되는 구간에서 BGP를 사용하곤 합니다. 

 

물론 꼭 ISP만 쓰라는 법은 없고, 내부에서도 BGP를 사용하는 경우도 있죠. 

상황에 따라서, 용도에 따라서, iBGP던 eBGP던 내부던 외부던 다양한 곳에서 사용합니다. 

 

내부에서 사용하던, 외부에서 사용하던 반드시 지켜야하는 한가지가 바로 Take-over 즉 fail over가 정상적이여야 한다는 것입니다. 

제가 정상적이여야된다는 것 이외에, 이번 주제인 빠른 Take-over를 언급하지 않은 이유가 있습니다. 

 

혹자들은 BGP가 너무 빠르게 Take-over된다면 너무 잦은 BGP 프로세스 진행과 그로인한 내부 라우팅이 꼬일 수 있다고 합니다. 

(Split-horizon 등등) 

Interface가 모종의 이유로 잦게 Flapping되는 경우가 그런 경우겠네요. 저도 동의하는 부분입니다. 

 

그렇기때문에 BGP는 라우팅 프로토콜 중에서도 손에 꼽힐정도로 큰 Keepalive/Holdtime을 가지고 있습니다. (Cisco 기준 60/180초) 

Peer와의 경로가 불안정한 상황에는 붙었다가 떨어졌다를 반복하면 반드시 서비스가 문제가 생길겁니다. 

 

이외에도 제가 모르는 다양한 상황이 있기때문에, BGP에서 빠른 Take-over가 꼭 좋은 경우만 있는것은 아니지만, 

그래도 할 줄 알면 다양한 상황에서 활용할 수 있으니, 제가 아는 두가지 방법을 공유드리고자 합니다. 

 

1. 구성도 

 

그냥 말을 시작하면 지루할 수 있으니, 제가 이번 실습을 위해 준비한 구성도를 우선 보겠습니다. 

 

 

보편적인 인터넷 관문을 간략히 구성해보았고, CE <> PE간 전용선이 아닌 이상, 기타 네트워크 장비와 Connect된다는 가정하에, 

중간 L2를 두었습니다. 

ISP 이중화도 정상적으로 되어있고, 각 ISP들은 자신의 Connected대역과 Default-originate를 통해

0.0.0.0(디폴트 라우팅)을 Router쪽에 광고하고 있습니다. 

 

Router쪽은 ISP와 eBGP, Router간에는 iBGP를 활용하여, 서비스 연속성을 가져갔습니다. 

 

그럼 본격적으로 시작하도록하겠습니다. 

(말하고 싶은 내용이 많아서 내용이 갑자기 이리튀고 저리튀더라도 이해해주세요, 저도 모르는 내용들을 실습을 통해 검증하고 포스팅 하는거라, 길을 종종 잃습니다.. ) 

 

2. BGP의 동작 방식과 Fall-over 

 

IP Protocol에서 동작하는 OSPF와는 달리, BGP는 TCP/IP 기반 port 179를 이용하여 세션을 생성한 후, 

그 다음 필요한 정보들을 왔다갔다하면서 관계가 성립됩니다. 

 

지난 BGP때 언급했었는데, 별도의 Config가 없는 이상 BGP가 설정된 Router는 기본적으로 Server임과 동시에, Client입니다. 

아시다시피 TCP는  요청하는 Client가 있고, 요청을 받아 응답하는 Server가 있습니다. 

 

일단 neighbor 설정을 하면서 해당 IP로부터 받을 tcp 179를 오픈하고, 자신이 Neighbor로 TCP 통신을 시도합니다. 

Server처럼 동작하면서 동시에 Client로 동작하는것이죠. 

 

 

                                                                             == 각설==

사실 저는 라우터에 'router bgp <ASN>'을 입력하는 순간 전역으로 179 port를 열줄 알았는데,

무분별한 TCP connection을 막기위해서인지 Telnet오픈이 안되더라구요. 

그리고 TCP hand-shaking 과정에 따른 매개변수를 보는지, 아무리 neighbor에 IP를 넣어놔도 Telnet 세션 연결이 안되더라구요.. 

이 것에 대해서 잘 아시는 분은 공유좀 부탁드립니다. 

                                                                           == 각설 끝==

 

이어서 하자면, 어쨋든 정상적으로 Remote-as와  source-interface가 등록된 두 라우터 모두 TCP의 client이면서 server이고,

TCP hand-shaking 이후 BGP 프로세스를 진행하면서, 높은 라우터 ID를 가진 라우터가 Server를 차지하며, 그 외 세션은 끊어버립니다.

 

이러고나서 BGP의 각종 메세지를 이용해서 BGP 프로세스를 진행합니다.

 

이제 제가 ISP1의 Downlink port(e0/0)을 한번 끊고나서, Router1에서 얼마나 자주 TCP connection try가 이뤄지는지 디버그를 한번 봤습니다.  아래 로그를 봐주세요  

 

 

굉장히 많은 정보를 내포하고 있어서, 저도 처음보는 내용이 많았습니다. 

 

일단 1,2 행을 보시면, Idle 상테에서 Active로 변하고, 곧이어, Local address가 10.10.10.2 로 되었습니다. 

여기서 알수 있는 한가지는 IDLE상태는 TCP connection이 이뤄지지않은 상태라는점, 그리고 Active상태에서는 TCP connection try가 이뤄졌습니다. 

 

일단 저는 Router1에서 update-source를 지정하지도 않았는데,

어째서 Local address가 Peer와 연결된 interface의 IP(10.10.10.2)일까요? 

제 예상으로는 Peer까지의 Routing table을 우선 참고하여, Local address를 Outgoing 인터페이스의 IP로 설정하는것이 아닌지 싶습니다. 

더 깊게 들어가서, Routing table에 Peer에 대한 라우팅이 존재하지 않는다면?

Local address를 어떤것으로 설정할지 확인하기 이전에, Peer에 대한 라우팅이 없는데 과연 Idle에서 Active로 바뀔지 모르겠습니다. 

 

 

제 예상이 맞았습니다. 

설명하고 있는 로그와는 확연한 차이가 보이시죠? 

Active를 오픈조차 하지 못합니다. 다른말로하면 Idle 상태로 계속 머무는 것이죠.  

 

다시 돌아와서, 3행을 보시죠. 1,2 행 로그가 발생하고 30초가 후, Connection timeout로그가 찍혔습니다. 

다른말로 얘기하면 30초 동안 Peer와 TCP connection을 위해 Try하고 있었다는 말이죠. 

30초 동안 시도하다가, '도저히 못해먹겠다 나 이제 그만할래' 하고, Idle로 돌아갑니다. 

하지만 또 일정 시간이 지난후에 다시 '이제 다시 한번 해볼까'하고 계속해서 Try하는 모습입니다. 

 

사실 Active단계는 시도하는 단계이기도 하며, Connection이 맺히고 나서 Neighborship이 맺히기 전에 거쳐가는 단계라고 생각하면 됩니다. 

자꾸 다른 곳으로 새는데, 딱 여기까지만 하겠습니다. 

 

trouble shooting을 하는데, 'sh ip bgp summary'를 1초 간격을 했을때,

- 계속 IDLE 상태이면, 해당 라우터에서 Peer로 가는 라우팅을 점검해야하고,

- Active 30 초, Idle 10몇초 이렇게 반복되면, 정상적으로 TCP 세션이 맺지못하는 것이니 경로상 라우팅을 봐야하고,

- Active단계에서 오랫동안 지속하고 있으면, TCP session은 정상적이나, AS-Number나 보안 String 혹은 eBGP-multihop과 같은 매개변수로 인해 안맺혀있다고 볼 수 있겠네요 

 

자 TCP 얘기는 여기까지 하고, 이제 본론으로 들어가겠습니다.

TCP 연결도, 변수도 정상적이여서, Peer로부터 몇몇 Prefix를 광고받고 있습니다.

Fail-over라 함은 기존의 경로가 문제가 생겼다는 것을 인지하고, 다른 경로로 전환을 의미하는데, 

BGP는 기본적으로 어떻게 인지할까요?

 

작성해놓은 구성도를 바탕으로 예를 들어서 설명하겠습니다. 

구성도에서 L2A의 업링크(e0/0)을 다운시켰을 때, ISP1의 e0/0이 다운으로 바뀌겠죠 ?

보시다시피 인터페이스 Down전에 먼저 BGP process의 reset이 먼저 동작합니다.

Peer로 가는 제일 낮은 AD의 라우팅이 사라졌으니, 다른 경로를 탐색하고자 일단 Reset 후 곧바로 Down으로 바뀌었습니다.

그럼 바로 다음행과 같이, 10.10.10.2(Peer)로부터 받아온 모든 IPv4 unicast prefix들이 topology에서 삭제됩니다.

왜냐하면 Peer와 BGP를 맺은 ISP의 Local address가 10.10.10.1이기 때문입니다. 

자연스럽게 Routing table 에서도 삭제됩니다.                  이것은 ISP1의 입장입니다. 

 

그럼 Router1의 입장은 어떨까요? 

10.10.10.2가 설정된 인터페이스는 Down되지 않습니다. 왜냐하면 L2 switch와 잘 연결되어있기 때문입니다. 

그럼 ISP처럼 Source interface가 Down되서 싹 라우팅 테이블에서 날아가지도 못하고, 

BGP의 기본 로직중 하나인 scan으로도 지우려고 해도 Next-hop(10.10.10.1)에 대한 라우팅은 여전히 Connected로 살아있습니다. 

*여기서 scan이란, BGP로부터 받아온 Prefix의 Next-hop에 대한 라우팅이 있는지를 확인하는 절차인데 60초마다 동작합니다.

**제가 생각했을때, RR을 이용한 반 mesh 구조에서, 받아온 라우팅에 대한 Next-hop 경로가 살아있지않을때, 삭제하는 용도지 않을까 생각해봅니다. 

 

결국은 위와 같이 Hold time expired로 인해 Reset되고, Down되고 BGP table과 라우팅 테이블에서 삭제됩니다.

여기서 ISP1의 인터페이스 Down시킨 시간과 Router1에서 라우팅이 삭제된 시간의 차이를 보시면, 대략 2분 20초의 시간이 걸렸습니다.

60초에 한번씩 keepalive를 보내고 있었으니, keepalive를 받은지 40초가 지난 시점에 ISP1이 Down되었기 때문에, 140초가 추가로 더 지나서야 Hold time expire되었습니다.  (아다리가 안맞을때 최대 3분까지 Down)

 

 구성도에는 표현되어있지않지만, Router1과 2 사이는 HSRP가 돌고있고, Backbone의 gateway가 해당 VIP로 잡혀있다고 가정했을때, 

Router1이 가지고 있는, ISP1에서 받아온 디폴트라우팅이 삭제되어야,

iBGP로 받아온 디폴트로 보고 Router2를 거쳐 ISP2로 통신을 하지 않을까요? 

 

라우팅이 사라지지않는 이상, Router1은 자신의 Peer가 정상이고, 자신의 라우팅 테이블에 있는 디폴트 라우팅이 정상이라고 생각하여, 

모든 트래픽을 다운된 IP로 보내는 상황이 발생합니다. 여지없이 인터넷 서비스 불가 상황입니다. 

 

이제 본격적으로 설명하겠습니다. 

빠른 Take-over를 위한 두가지 방법!! 드디어 !! 

 

1) Keepalive/hold timer 조정 

 

방금같은 상황에서, keepalive를 5초 Hold timer를 15초로 설정해놓는다면, 최대 15초 안에 Take-over 될겁니다.

180초라는 시간이 hold time expired가 될 때까지 걸리는 시간이며, 라우팅 테이블에서 라우팅이 삭제되는 시간이니,

15초로 줄여버리면  12배나 빨라지는 셈이죠. 

180초에서 15초면 정말 획기적으로 단축한게 아닐까요 ?

 

 2) BFD 설정 

 

자, 우리는 지금 link-Flap에 따른 side-effect를 걱정하기 이전에 가장 빠른 Take-over에 대한 논의를 하고 있다는것 잊으시면 안됩니다. 

위의 구성도 처럼 Serial link이나 한쪽의 Link Down이 양 Peer가 인식하지 못하는 경우,

가장 빠른 방법은 바로 BFD를 포함시키는 것입니다.

 

설정은 간단합니다.  

 

ISP 

int e0/0

 bfd interval 300 min_rx 300 multiple 3 

 

router bgp 10 

 neighbor 10.10.10.2 fall-over bfd

 

 

Router 

int e0/0

 bfd interval 300 min_rx 300 multiple 3 

 

router bgp 65515

 neighbor 10.10.10.1 fall-over bfd

 

설정은 위와 같이 간단합니다. 

연결된 링크의 IP가 있는 부분에다가 BFD설정을 해주는 겁니다. 

bfd config 내에있는 Inteval min_rx, multiple같은 경우는 원하시는 대로 사용하면 되나, 

상대의 interval이 내 min_rx보다 작을 경우, 상대의 Interval이 내의 Min_rx로 조율됩니다.

(나는 더 띄엄띄엄 받을 수 밖에 없고, 쟤는 빨리주고 싶을때, 띄엄띄엄 받고싶은 애한테 맞추는 느낌) 

 

이러니 저러니해도, 같은 도메인안의 장비에서 BFD설정을 해준다면 속편히 값을 맞춰주는게 맘 편할것 같습니다. 

중요한건 'BFD설정을 한다' 니까요. 

 

그리고 bgp config에 특정 neighbor의 fall-over는  bfd에 맡기겠다하는 config를 집어넣어주는 것이죠. 

(BFD는 양 L3 interface에 설정을 해줬다고 Session이 올라오지 않습니다. 설정된 상태에서 '어디'서 써줘야 '어디'와 링크간의 BFD가 정상적으로 동작한다고 볼 수 있습니다. 본건의 '어디'는 BGP) 

 

자 그럼 설정이 끝났겠다, 아까와 마찬가지로 ISP1에서 e0/0을 shutdown시켜보겠습니다. 

 

ISP1의 Log

 

 

Router1의 Log 

 

시간으로만 보겠습니다. 

<ISP1>

13:54:12.062에 ISP1의 BGP로부터 받아온 라우팅이 모두 날아갔습니다. 

13:54:12.062 동일한 시간에 ISP1의 BFD session이 destroyed 되었습니다. 

당연하죠 설정된 인터페이스가 Down 되었는데, 당연한 결과입니다. 

 

<Router1>

13:54:13.134 Router1의 BFD session이 Down되었습니다. (ECHO fail) 

13:54:13.142 BGP 테이블 및 라우팅 테이블에서 삭제되었습니다. 

 

Peer의 다운을 감지하고 정확하게 1초 08정도 걸려서 Fall-over가 되었습니다.

180초에서 1초까지 줄였습니다. 

 

근데 여기서 한가지 궁금증이 생겼습니다. 

Loopback interface를 Local address로 사용했을때도, 중간 링크의 BFD가 과연 먹힐까 하는것이죠. 

 

실제 L3 interface에 설정된 IP가 아닌 양단 ISP1, Router1에 Loopback을 설정하여, 해당 IP를 Local address, Neighbor address로 설정해보겠습니다. (물론 상대의 Loopback address에 대한 라우팅이 있어야하기에, static라우팅을 추가해줬습니다) 

 

*여기서 한가지 안 사실은 eBGP의 Default multihop은 1입니다. 단순 링크였을때는 정상이였던 반면, 

Loopback으로 바꾸고 나서는 ebgp-mulithop을 2보다 큰수로 해서 정상적으로 Neighborship이 생성되었습니다. 

 

정상적으로 셋팅하고나서, BFD neighbor을 확인해보니 아무것도 확인되지않았습니다. 

어찌보면 당연한 결과였는데, 우리가 BFD를 설정한 링크의 IP는 BGP 프로세스의 Local/Peer address와는 무관한 IP입니다. 

그렇기 때문에 링크에 BFD config를 추가한다고 한들,

그 BFD를 이용하는 어떠한 프로세스도 없기때문에 Session이 확인되지 않았습니다.

 

기왕 Loopback으로 설정한 김에 BGP table과 Routing table을 한번 보겠습니다.  

Router1의 BGP table

 

 

Router1의 Routing table

역시 BGP peer(neighbor)로 지정한 IP가 Next hop으로 지정된 것을 볼 수 있습니다. 

 

보통 Loopback address를 BGP Peer IP를 사용하는 경우는 아래와 같습니다. 

 - 링크가 자주 불안한 상황 

 - Loopback IP의 라우팅을 위해, 별도로 EIGRP 혹은 OSPF와 같은 IGP가 돌아가고 있는 경우 
 - RR 환경의 MPLS 인프라( BGP range neighbor 설정하기 용이함 )

 

 

유독 위와같은 상황에서 Loopback address를 이용해서 BGP를 사용하는것이지, 그 외의 상황에서는 어느것을 사용하는지 크게 상관이 없을것같습니다. 

 

다만 이번 세션에서 확인한대로, BFD를 활용한 극단적인 Take-over time 단축을 위해서는 반드시 L3 interface에 설정된 Peer IP로 

Neighbor를 설정해야만 합니다. 

 

보통의 eBGP환경은 1Hop인 상황보다는 Multihop인 경우가 많으며, 아시다시피, Tunnel은 자체적인 Keepalive 프로세스가 돌아가고 있어, BFD설정이 불가하고,,, 라고 생각했으나, Tunnel에 BFD 설정이 가능해져서 상황이 반전되었습니다. 

이거 한 챕터에 끝내고 Security쪽으로 넘어가려고 했는데, 한편 더 작성해야할 것같습니다. 

 

더 흥미로운 주제인 'Tunnel을 활용한 BGP의 기깔나는 Take-over' 한번 해보도록 하겠습니다. 

그것만 하면 좀 심심하니, Range neighbor랑 Security도 섞어서 한번 포스팅 하겠습니다. 

 

 그럼 .. !